AWS Elastic Load Balancer (ELB) – Call Me Maybe

When is a load balancer not really a load balancer?

When it’s an AWS Elastic Load Balancer (Classic ELB or ALB.)

Although it’s been well-documented for at least 6 years, it’s still not well-known that one side of a Classic ELB (or ALB) does load balancing, but the other side doesn’t have a VIP, or static IP address, which most users expect.

The reasons AWS decided on no static VIP are:

  1. AWS is likely using round-robin DNS to implement ELBs under the hood, although with options like “sticky” and health-checking
  2. AWS doesn’t want users to rely on permanent IP addresses for “AWS internal network management reasons”
  3. AWS didn’t care about end-user expectations, otherwise they would have called it a “HLB” (Half Load Balancer)
  4. AWS can tweak their own services to consume the output of ELB’s, like endpoints.

The problems with not having a static VIP are:

  1. client programs (browsers, Java applications, k8s, etc.) that connect to an ELB will have apparent random connect failures and have to resolve the endpoint per connection request periodically when the ELB changes the addresses
  2. client programs cannot cache DNS if they want reliable connections, a significant performance problem
  3. ELB addresses cannot be whitelisted in firewalls
  4. ELBs typically return several IP addresses, similar to round-robin DNS, which some applications don’t expect
  5. in network engineering terms, ELBs don’t support TCP Layer 3, which is immensely unhelpful
  6. without a VIP, designing static architectures is fruitless – how can you guarantee 5×9’s when devices are changing without any advance notification? ie. you’re “painted into a corner”
  7. if traffic ramps up quickly, the ELB topology will scale by returning a varying list of IP addresses in a short amount of time
  8. connections are broken by ELB, introducing corruption into stateful applications like middleware and orchestration software.

Additional problems with ELBs are:

  1. even when expecting multiple IPs, ELBs randomize them, causing cache misses. You must also have a distributed session manager if you don’t use “sticky.”
  2. the default is to break the connection on change, not to drain the connection first.

By now, you’re likely horrified as you see your 5×9’s rapidly disappear in the rear-view mirror. 🙂

For most users, the lack of that static IP disqualifies Classic ELBs and ALBs from any HA architecture design.

Solutions if your client program is expecting a static VIP are:

  1. Network Load Balancers (NLB’s) (introduced in 2017) support an EIP
  2. use EIPs (note that replacing a server in your farm will require binding an EIP in some cases, which may take up to 120 seconds. So you really should start with n+1 servers at all times.)
  3. EIPs to HAProxy
  4. third-party solutions like F5.

Lame workarounds:

  1. AWS has an article on combining NLB+ALB+Lambda to track IP address changes
  2. manually monitor ELB changes and restart your apps, preferably automatically
  3. tell your browser users to retry failed requests, or close their browser and reopen it, whenever they see errors.


  1. Route53 DNS ALIAS and CNAMEs only help if your client program doesn’t cache lookups. I don’t know why AWS documentation erroneously says that ALIAS will somehow help with ELB’s, as client programs cache lookups.

AWS High Availability Patterns : DNS Load Balancing Tier
GCE: Network Load Balancing (uses a static IP as expected)

This entry was posted in Cloud, Tech. Bookmark the permalink.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.