Inner Workings of the AWS ELB, Part 1

Inner Workings of the AWS ELB, Part 1

Ever wonder what an AWS ELB is made of? This blog post will:

  1. Provide more transparency into AWS ELB for those who rely on AWS technology.
  2. Let ELB users know what they can expect from an Amazon ELB.
  3. Let ELB users know what they can ask Amazon for.

What is an ELB?

Simply stated: an ELB is made up of one (or more) EC2 instances per availability zone, with these instances routing traffic to back-end EC2 instances. While AWS does not publicly document ELB architecture, the following should be convincing:

Behavior of ELB when Availability Zones are Added and Removed:
  1. Create an ELB with only one availability zone (example: us-east-1a)
  2. Run “host” with the ELB’s hostname – notice that only one IP address is returned.
  3. Add a second availability zone to your ELB.
  4. Run host with the ELB’s hostname – notice that two IP addresses are returned.
  5. Add an additional availability zone – you’ll see a third IP address when performing a DNS query of the ELB’s hostname.
Return of DNS Lookup of ELB IP addresses:

Run “dig -x” with the IP addresses of the given instances.

Example: dig -x +short

The return of these requests are the same values as EC2 instance public DNS names.

Example return value:


Amazon’s own Documentation:

Amazon’s own documentation hints at the construction of the ELB – the ELB Concepts page notes “When you register your EC2 instances, Elastic Load Balancing provisions load balancer nodes in all the Availability Zones that has the registered instances.”

How does this help me?

If Amazon Web Service’s ELB’s are made up of EC2 instances in an Auto Scaling Group then you have a good idea of what you can ask the AWS ELB support group for. Examples below:

You can “pre-warm” an ELB to prepare for a flood of traffic:

Let’s say you had a client that was a tech-centered advertising network and you knew that an upcoming Apple announcement was going to generate a large amount of traffic on your servers – knowing this, you could do one of the following:

  1. Call Amazon and request that the ELB be scaled up before this occurred. Note that Amazon documents your ability to request “pre-warming” in their Best Practices in Evaluating Elastic Load Balancing document.
  2. Pre-warm the ELB by gradually scaling up the ELB by sending your own automatically generated traffic.
You could change the EC2 Instance Types that make up an ELB:

Let’s say you knew that your traffic was naturally bursty – enough to overwhelm a small EC2 instance type. You could Amazon support and ask them to change the instance type that comprises your ELB to an instance that offered greater network performance.

You can change the Auto Scaling Policy supporting the ELB:

Again, assuming a situation where you have bursty traffic or you wish to have multiple ELB EC2 instances in each availability zone – you could call Amazon and suggest that you wish for the ELB to bring additional EC2 nodes into service immediately when traffic starts or to always maintain two nodes per AZ. Regarding the “scale up” time period, Amazon’s documentation states that “the time required for Elastic Load Balancing to scale can range from 1 to 7 minutes, depending on the changes in the traffic profile” – particular customers might wish for this time period to be more predictable, or for their ELB to have over-provisioned capacity from the start.


If you use or are implementing Amazon’s ELB, I’d suggest you:

  1. Implement the ELB and back-end instances in the most vanilla manner that meets your needs. The ELB doesn’t provide many tunables and remaining “vanilla” ensures that tunables aren’t needed.
  2. Engage your Amazon Account Manager or support group. In particular the Account Managers I have worked with have been valuable in ensuring predictable ELB implementation.
  3. If you need ELB modifications, ask. The ELB has a very limited API, but a number of parameters are able to be tuned by placed a call to Amazon support.