Elastic Load Balancing (ELB) for Traffic Distribution
In the world of cloud computing, high availability and fault tolerance are non-negotiable. As your application grows, a single server (EC2 instance) will eventually struggle to handle thousands of simultaneous requests. This is where Elastic Load Balancing (ELB) comes into play. ELB automatically distributes incoming application traffic across multiple targets, such as Amazon EC2 instances, containers, IP addresses, and Lambda functions.
By using ELB, you ensure that no single server becomes a bottleneck, and your application remains available even if one or more servers fail. This lesson covers the core concepts, types of load balancers, and practical implementation strategies for the AWS Solutions Architect path.
How Elastic Load Balancing Works
ELB acts as the single point of contact for clients. It receives incoming traffic and routes it to healthy targets based on predefined rules and algorithms. Here is a simplified flow of how traffic moves through an ELB environment:
[ Internet / Users ]
|
v
[ Elastic Load Balancer ]
|
+-------> [ Target Group A: EC2 Instance 1 (Healthy) ]
|
+-------> [ Target Group A: EC2 Instance 2 (Healthy) ]
|
+-------X [ Target Group A: EC2 Instance 3 (Unhealthy - Traffic Skipped) ]
The ELB continuously performs Health Checks. If an instance fails a health check, the load balancer stops sending traffic to it until it becomes healthy again. This ensures a seamless experience for the end-user.
Types of Elastic Load Balancers
AWS provides four types of load balancers, each designed for specific use cases. Choosing the right one is a common requirement for the AWS Certified Solutions Architect exam.
1. Application Load Balancer (ALB)
Operating at Layer 7 (Application Layer) of the OSI model, the ALB is best suited for HTTP and HTTPS traffic. It is "content-aware," meaning it can route traffic based on the content of the request, such as URL paths (e.g., /api vs /images) or host headers.
- Use Case: Microservices, container-based applications, and web applications.
- Features: Supports WebSockets, HTTP/2, and path-based routing.
2. Network Load Balancer (NLB)
Operating at Layer 4 (Transport Layer), the NLB is designed for high-performance applications where extremely low latency is required. It handles TCP, UDP, and TLS traffic and can scale to millions of requests per second.
- Use Case: Gaming applications, video streaming, and high-throughput TCP traffic.
- Features: Provides static IP addresses and can handle volatile traffic patterns.
3. Gateway Load Balancer (GWLB)
The GWLB operates at the IP Layer (Layer 3). It is used to deploy, scale, and manage third-party virtual appliances such as firewalls, intrusion detection systems, and deep packet inspection systems.
4. Classic Load Balancer (CLB)
This is the legacy load balancer that operates at both Layer 4 and Layer 7. While still available, AWS recommends using ALB or NLB for modern cloud architectures.
Practical Example: Path-Based Routing with ALB
Imagine you have an e-commerce website. You want traffic for your product catalog to go to one set of servers and traffic for the checkout process to go to another. You can achieve this using a single Application Load Balancer.
Rule 1: If URL path is "/products/*" -> Route to Target Group: Product-Servers
Rule 2: If URL path is "/checkout/*" -> Route to Target Group: Checkout-Servers
Default: Route to Target Group: Main-Website-Servers
In this scenario, the ALB examines the URL string and makes an intelligent routing decision, reducing the need for complex logic within your application code.
Key Features of ELB
- Sticky Sessions (Session Affinity): Ensures that a user is consistently routed to the same backend instance for the duration of their session. This is useful for applications that store session data locally on the server.
- SSL Termination: The load balancer can handle the decryption of HTTPS traffic, reducing the CPU load on your backend EC2 instances.
- Cross-Zone Load Balancing: Distributes traffic evenly across all registered instances in all enabled Availability Zones, ensuring better fault tolerance.
- Integration with Auto Scaling: ELB works perfectly with
amazon-ec2-auto-scalingto ensure that as new instances are launched, they are automatically registered with the load balancer.
Common Mistakes to Avoid
- Incorrect Security Group Configuration: A common error is forgetting to allow the Load Balancer's security group to communicate with the EC2 instances' security group. The instances must allow inbound traffic from the ELB on the application port.
- Ignoring Health Check Paths: If you set a health check to a page that requires authentication or doesn't exist, the ELB will mark all instances as unhealthy and stop routing traffic.
- Using ALB for Non-HTTP Traffic: Attempting to use an ALB for pure TCP traffic (like a database connection) will fail. Use an NLB for those scenarios.
Real-World Use Cases
1. Blue-Green Deployment: You can use ELB to shift traffic from an old version of your application (Blue) to a new version (Green) by simply updating the target groups. This allows for zero-downtime updates.
2. Microservices Architecture: In a microservices environment, different teams manage different services. An ALB can route traffic to different services (containers or Lambda functions) based on the request path.
Interview Notes for Solutions Architects
- ALB vs NLB: Remember that ALB is for Layer 7 (HTTP/HTTPS) and supports complex routing rules. NLB is for Layer 4 (TCP/UDP) and is optimized for extreme performance and static IPs.
- Internal vs External: An "Internet-facing" ELB has a public DNS name and routes traffic from the internet. An "Internal" ELB routes traffic within your VPC (e.g., from a web tier to a database tier).
- High Availability: Always deploy your load balancer across multiple Availability Zones to ensure that the load balancer itself does not become a single point of failure.
Summary
Elastic Load Balancing is a foundational component of AWS infrastructure. It provides the "glue" that connects your users to your compute resources while ensuring reliability and scalability. By understanding the differences between ALB, NLB, and GWLB, you can design architectures that are both cost-effective and highly performant. As you move forward in the aws-cloud-mastery course, remember that ELB is almost always used in conjunction with auto-scaling-groups to build truly elastic applications.