Behind the Scenes with Amazons Elastic Load Balancer (ELB)
- April 20, 2014
We published a post a few months ago titled “Must-know Facts About AWS ELB” in which we explored some of the peculiarities of Amazon’s Elastic Load Balancer. We thought we’d go a bit deeper into the details of what the ELB is to better understand its limitations and appreciate the engineering behind it. So, what are the requirements for the ELB? For starters, it needs to be able to scale from a setup with almost no data to managing the data to a large website.
To manage this requirement, the ELB actually consists of multiple load balancers. As the requirements increase, more load balancers are brought up to help manage the load. In other words, the ELB is autoscaling to the demand. However, the problem with autoscaling the ELB is that there is no way to manage the load coming down to it. Managing this incoming load is done at the DNS lookup level. Each load balancer instance has its own IP address registered in the DNS service on Amazon’s side. Amazon will return different IP addresses to different queries. This is also why Amazon only provides a DNS for the ELB, because a static IP address does not exist that can be used instead.
This requirement for autoscaling the ELB and changing the DNS explains why the ELB isn’t as reactive to change as we’d like it to be. DNS records have a longer lifetime and cannot handle rapid changes. In some scenarios, they can even cause problems for the client-side, which is why the ELB isn’t immediately reactive to change.
Until a few months ago, the ELB did not support cross-zone load balancing. What this meant was that the number of load-balanced instances in each availability zone needs to be close to equal. Otherwise, instances in some of the availability zones would be underutilized, and the other availability zones would have performance issues from overutilization. This is because when Amazon first introduced the ELB, the load balancers in each availability zone would only know about the instances in their own availability zone. With cross-zone ELB, the load balancers are able to route traffic to other availability zones when it makes sense.
An interesting consequence of the IP-based setup of the ELB is that special care needs to be taken when load testing. If the TTL (Time To Live) is high for the DNS lookups done by your load-tested, then all ELB DNS lookups will resolve to the same IP. This won’t give an accurate measure of the system’s ability to handle the load. So, if doing load-testing from the same instance, it may make sense to alter the TTL for the DNS lookup. Or even better, use multiple instances with multiple IP addresses geographically located at different places when performing load-testing to get a more representative view of the world.
We hope this post provided you with a deeper insight into the working of the ELB and helped you understand its behavior under different conditions. If you’d like an expert assessment of your infrastructure, please contact us at info@flux7.com or visit us at www.flux7.com. We can help you get set up with AWS best practices.
Sign-up for the Flux7 Blog for industry and cloud news.
To manage this requirement, the ELB actually consists of multiple load balancers. As the requirements increase, more load balancers are brought up to help manage the load. In other words, the ELB is autoscaling to the demand. However, the problem with autoscaling the ELB is that there is no way to manage the load coming down to it. Managing this incoming load is done at the DNS lookup level. Each load balancer instance has its own IP address registered in the DNS service on Amazon’s side. Amazon will return different IP addresses to different queries. This is also why Amazon only provides a DNS for the ELB, because a static IP address does not exist that can be used instead.
This requirement for autoscaling the ELB and changing the DNS explains why the ELB isn’t as reactive to change as we’d like it to be. DNS records have a longer lifetime and cannot handle rapid changes. In some scenarios, they can even cause problems for the client-side, which is why the ELB isn’t immediately reactive to change.
Until a few months ago, the ELB did not support cross-zone load balancing. What this meant was that the number of load-balanced instances in each availability zone needs to be close to equal. Otherwise, instances in some of the availability zones would be underutilized, and the other availability zones would have performance issues from overutilization. This is because when Amazon first introduced the ELB, the load balancers in each availability zone would only know about the instances in their own availability zone. With cross-zone ELB, the load balancers are able to route traffic to other availability zones when it makes sense.
An interesting consequence of the IP-based setup of the ELB is that special care needs to be taken when load testing. If the TTL (Time To Live) is high for the DNS lookups done by your load-tested, then all ELB DNS lookups will resolve to the same IP. This won’t give an accurate measure of the system’s ability to handle the load. So, if doing load-testing from the same instance, it may make sense to alter the TTL for the DNS lookup. Or even better, use multiple instances with multiple IP addresses geographically located at different places when performing load-testing to get a more representative view of the world.
We hope this post provided you with a deeper insight into the working of the ELB and helped you understand its behavior under different conditions. If you’d like an expert assessment of your infrastructure, please contact us at info@flux7.com or visit us at www.flux7.com. We can help you get set up with AWS best practices.
Sign-up for the Flux7 Blog for industry and cloud news.
Subscribe to our blog
