Current Limitations of the Amazon ELB

If you are using Amazon ELB for handling production workloads for your SaaS/PaaS customers, you would have encountered the below limitations with Amazon Elastic Load Balancers

• No iRULES mapping - If you have worked with F5 load balancers, you would already be familiar with iRules (https://devcentral.f5.com/articles/irules-101-01-introduction-to-irules). It allows for inspecting the incoming packets and execute rules that can allow for redirection of traffic. Today, ELB is not "application aware", which means that the load balancing feature is pretty basic and can only do "round-robin" balancing (as opposed to weighted load balancing etc). The options to send the traffic to a particular instance based on the client-ip header do not exist. NOTE - The good news is that Amazon ELB team is working on a potential solution with high priority and should be available before end of this year. 

• No Fixed IP for ELB - There are situations where your customer might outbound traffic from their firewall to access only certain ip addresses on port 80 or 443. ELB's today have a domain name and have public ip addresses (could be multiple if ELB is available across zones). If the below public ip's are whitelisted in the corporate firewall, then these ip addresses will change when ELB's are scaled out or rebooted for maintenance. NOTE - Amazon's workaround for today is to whitelist the entire CIDR block of EC2 addresses (which includes ELB addresses - https://aws.amazon.com/blogs/aws/aws-ip-ranges-json/). The other option is to pre-warm the ELB's to estimate the load and then whitelist upto 10 public ip addresses for the 10 ELB instances.

***********

$ host Test-ELB-669438560.us-east-1.elb.amazonaws.com

Test-ELB-669438560.us-east-1.elb.amazonaws.com has address 107.23.x.x

Test-ELB-669438560.us-east-1.elb.amazonaws.com has address 54.236.x.x

***********

• No Mutual Authentication for SSL - One of the nice features of the ELBs is that they can be made as the SSL termination point instead of your reverse proxy or application. There are several benefits of this approach including reduced configuration on the application/reverse proxies. However, the downside is that currently we cannot perform mutual authentication as part of the SSL handshake, i.e., we cannot perform client certificate verification, which is necessary to make sure that only valid clients are accessing the application. NOTE - Amazon indicated that they are aware of this limitation and working on a potential solution before the end of this year.