Modern web applications designed to scale use load balancing to direct app traffic to multiple back-end services....
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
This type of architecture automatically redirects clients to healthy resources, and it can also help spawn new back-end services, if needed.
In 2016, seven years after Elastic Load Balancing (ELB) debuted, AWS introduced the Application Load Balancer (ALB), providing two ELB services for scaling web apps. The original ELB service, renamed Classic Load Balancer (CLB), still has a few uses involving legacy applications, older AWS accounts and protocol choices. The newer ALB adds a host of features, finer grained control over scalability and it is expected to reduce costs for most implementations. AWS also provides a migration tool to facilitate users' upgrade to ALB.
Why stick with classic load balancing?
AWS accounts created prior to 2013 may only support Elastic Compute Cloud (EC2)-Classic instances. An EC2-Classic infrastructure shares networking resources across different AWS accounts. Newer accounts default to an Amazon Virtual Private Cloud (VPC) inside EC2-VPC instances. This creates a virtual private network between the various applications in an enterprise account. ALB doesn't support EC2-Classic networks. But even if an enterprise decides against migrating to ALB, it's still a good practice to migrate instances to a VPC to reduce the possibility of attacks.
Most modern web applications use HTTP or HTTPS for communication. But, in some cases, applications communicate with lower level protocols, such as transmission control protocol and secure sockets layer, for performance or management reasons. These applications will not work with Application Load Balancer.
Web applications often use sticky sessions to bind a client to a specific server instance through the load balancer. Application-generated cookies facilitate this process in many cases. This works in CLB, but is not directly supported in ALB. A developer can configure ALB to support sticky sessions using load balancer-generated cookies at the target group level. This provides more flexibility, but requires a rewrite for older apps.
Why choose ALB?
Application Load Balancer should be considered the default choice for new projects because of its improved cost structure, greater flexibility and better monitoring when compared to CLB. For these same reasons, enterprises should evaluate migrating legacy ELB implementations to ALB. This is straightforward for simple web applications, but larger ones that rely on many different services will take some time to configure and transition to ALB.
ALB costs about 10% less than CLB for comparable usage. ALB enables more efficient deployments that can reduce the number of load balancers required, leading to additional savings. Fewer load balancers in an application deployment reduces monitoring complexity and management costs.
Content-based routing improves flexibility
Application Load Balancer supports content-based routing, which allows it to read HTTP headers and route requests to different back-end services accordingly. Developers can use this approach to build applications composed of multiple microservices that scale independently, and to enable communication between multiple instances of services within Docker containers that run on a single EC2 instance.
CLB directs traffic via port mapping, which creates challenges when different Docker instances of a service run on a single EC2 instance. ALB also supports better integration with the Amazon EC2 Container Service.
Content-based routing makes it possible to map traffic across multiple availability zones with fewer load balancers. This helps improve infrastructure resiliency at a low cost.
ALB can also provide better metrics with content-based routing. ALB assesses the health of services at the port level for improved monitoring of microservices running on a single EC2 instance. This helps improve Auto Scaling rules in response to the load on each service. ALB also includes several new CloudWatch metrics, such as overall traffic, number of active connections and connection rate per hour. These features allow operations engineers to monitor and associate health checks with a target group.
New protocol support
Application Load Balancer supports two new protocols: WebSocket and HTTP/2. With WebSocket, developers can easily set up longer running sessions between services, and also between services and mobile devices. WebSocket is more efficient than classic HTTP connections, which were initially designed only for short-lived interactions. Developers often overcome this limit with heartbeat messages to keep the connection alive, but this workaround adds network overhead and increases power consumption on mobile devices.
HTTP/2 is the long-awaited update to the older HTTP/1.1 protocol commonly used for web applications. It makes it easier for developers to send multiple requests between a client and server over a single connection via a binary format, which reduces network traffic. But its default mode uses lower case headers, which can be a problem when the client and server are improperly configured.
ELB has a competitor in the form of NGINX
Get granular control with ALB
If you're using ELB, use these workarounds for better performance