For many years, Amazon’s Elastic Load Balancer (ELB) has been a popular solution for balancing various workloads. Yet this load balancer, which Amazon sometimes refers to as Classic Load Balancer, has its limitations. In fact, there are a few things about AWS ELB that might surprise you.
Operational Visibility From AWS
Machine data holds hidden secrets that deliver true insights about the operational health of your AWS infrastructure. Learn more about operational visibility from AWS today!
1 ) ELB is a Poor Choice for Those Who Require UDP Support
One of the most significant limitations of ELB, or AWS Classic Load Balancer, is that all IP traffic is assumed to be using a TCP port. Although subscribers have been requesting UDP support for several years (as documented on various Internet message boards), ELB continues to support TCP only.
Being that TCP does tend to be more frequently used than UDP, it might be tempting to dismiss this issue as the sort of thing you might want to know for a certification exam, but with little real-world impact. However, there is at least one significant issue that is caused by the ELB’s lack of UDP support.
Syslog is designed to use UDP port 514. For those who might not be familiar with Syslog, it is a logging standard that is used by many applications. The main reason why Syslog is so prevalent is because it is designed to allow for separation between the application that produces the log entry, the reporting engine, and the log storage. Furthermore, Syslog uses a standardized logging format. What this means is that it is possible to build a log that aggregates logging data from multiple sources. Because Syslog is standardized, but also open-ended, it has quickly become a favorite of developers. Unfortunately, Syslog’s dependency on UDP Port 514 rules out using it with AWS ELB.
For more on TCP vs UDP, see our support documentation ›
2) Application Load Balancing
As previously mentioned, AWS has in some places begun referring to ELB as Classic Load Balancer. One of the main reasons for this is that Amazon has released an Application Load balancer, which is sometimes referred to as ALB.
Although some documentation and various blog posts make it sound as though ALB is a replacement for ELB, it really isn’t. Instead, think of Application Load Balancer as a mode or function of ELB. Amazon describes it this way: “Elastic Load Balancing supports two types of load balancers: Application Load Balancers and Classic Load Balancers.” In other words, the ELB service can now provide either classic load balancing services, or it can provide application load balancing services.
Unlike the classic load balancer, the Application Load Balancer works at layer 7 of the OSI stack. As such, the load balancer can be used for application scalability by distributing inbound requests to multiple targets. These targets are often EC2 instances, but other types of targets are also supported.
One of the Application Load Balancer’s most useful features is its ability to evaluate target health. This allows ALB to ensure that it is forwarding requests to targets that are proven to be healthy. Keep in mind that targets can be distributed across AWS regions, so the application load balancer could conceivably be used to protect against a regional outage.
3) The Way that Pricing Works
Although Amazon is completely upfront about the way that it prices its AWS resources, there have been a number of documented instances of unsuspecting admins being caught off guard by sticker shock. As such, it is a good idea to familiarize yourself with ELB pricing prior to use.
Amazon documents its ELB pricing at: https://aws.amazon.com/elastic... is the case for most of the other AWS services, Amazon charges its customers for the EC2 instance on which an ELB runs, as well as the ELB resources that they actually use. Usage pricing is based on two factors—the number of hours (or partial hours) that the load balancer is running, and the number of GB of data transferred through the load balancer. Currently, Amazon bills its customers at a rate of $0.025 per load balancer hour (or partial hour), and $0.008 per GB of data processed by the load balancer. Costs can vary by region.
Amazon uses a slightly different metric for the billing of ALB usage. ALB usage is billed at a rate of $0.0225 per load balancer hour (or partial hour), and $0.008 per LCU hour, although costs can vary by region. LCU stands for Load balancer Capacity Units, and refers to things like new connections, active connections, bandwidth consumption, and rule evaluation.
In spite of ELB’s modest cost, it is important to keep in mind that the rates listed above apply only to the load balancer. AWS subscribers typically incur separate costs related to EC2 instance usage, storage consumption, etc.
Get more details at “Choosing Between an ELB and an ALB on AWS” ›
Additional AWS ELB Resources
- AWS ELB 101
- Tuning Your ELB for Optimal Performance
- Configuring Your ELB Health Check For Better Health Monitoring
- AWS ELB vs. NGINX Load Balancer
Complete visibility for DevSecOps
Reduce downtime and move from reactive to proactive monitoring.