Day 10: Elastic Load Balancing and Auto Scaling – Handling Traffic Automatically
Day 10 of my 90-day AWS challenge: how load balancers spread traffic across servers, how Auto Scaling adds and removes EC2 instances on demand, and how the two work together for a highly available application.
Recap of Day 9
Yesterday I learned how CloudWatch monitors metrics and triggers alarms. Today those ideas come together: when traffic grows, AWS can spread it across servers and add more of them automatically.
The problem
A single EC2 instance is a single point of failure. If it crashes, the app goes down. If traffic spikes, it slows down. If traffic is low, I'm paying for capacity I don't need.
Elastic Load Balancing (ELB)
ELB distributes incoming traffic across multiple targets, such as EC2 instances, in one or more Availability Zones. It also checks the health of each target and stops sending traffic to unhealthy ones.
| Type | Works at | Best for |
|---|---|---|
| Application Load Balancer (ALB) | Layer 7 (HTTP/HTTPS) | Web apps, path-based and host-based routing |
| Network Load Balancer (NLB) | Layer 4 (TCP/UDP) | Very high performance and low latency |
| Gateway Load Balancer (GWLB) | Layer 3 | Third-party virtual security appliances |
Key ELB concepts
- Listener: checks for connection requests on a port and protocol, e.g. HTTP on port 80
- Target group: the set of targets that receive the traffic
- Health check: a periodic request that decides whether a target is healthy
Auto Scaling
An Auto Scaling group (ASG) keeps the right number of EC2 instances running.
| Concept | What it is |
|---|---|
| Launch template | Defines what to launch: AMI, instance type, key pair, security group |
| Minimum | The fewest instances that must always run |
| Desired | The number the group tries to maintain right now |
| Maximum | The most instances the group is allowed to launch |
Scaling policies
- Target tracking: keep a metric near a target, e.g. average CPU at 50%
- Step scaling: add or remove a set number of instances as an alarm crosses different thresholds
- Scheduled scaling: scale at known times, e.g. before a daily traffic peak
Auto Scaling uses CloudWatch metrics and alarms to decide when to scale, which connects directly to what I learned on Day 9.
How they work together
- Users send requests to the load balancer
- The load balancer spreads them across instances in multiple Availability Zones
- The Auto Scaling group adds instances when load rises and removes them when it falls
- Unhealthy instances are replaced automatically
The result is an application that is highly available and cost-efficient.
What I practiced today
- Created a launch template for a small EC2 instance
- Created an Auto Scaling group across two Availability Zones with min 1, desired 1, and max 2
- Created an Application Load Balancer with a target group and health check
- Added a target tracking policy based on average CPU
- Deleted the Auto Scaling group and load balancer afterwards
Key takeaways
- Load balancing gives availability, and Auto Scaling gives elasticity
- Use at least two Availability Zones so one failure does not take the app down
- Load balancers are billed by the hour, so delete practice ones to avoid charges
Up next: Day 11
Amazon Route 53 and CloudFront: DNS and content delivery.
Learning AWS too? Follow along and share what you're building. #90DaysOfAWS
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article