Load Balancing & Auto Scaling

Elastic Load Balancing and Auto Scaling are real, deliberately paired AWS services — announced together on 23 October 2008 and launched together on 18 May 2009. This chapter covers both, and the real, standard high-availability pattern they form when combined with the multi-AZ architecture from Chapter 1.

Three Real Load Balancer Types

AWS's original Classic Load Balancer operates at Layer 4 (transport layer) — routing purely by IP and port, with no awareness of HTTP content. Two real, more capable successors followed:

• Application Load Balancer (ALB) — launched 11 August 2016, operating at Layer 7 (application layer). ALB can route by URL path or HTTP header — sending /api traffic to one backend and /mobile to another — and performs fine-grained, per-port health checks, making it the real standard choice for microservices and container-based applications.
• Network Load Balancer (NLB) — launched 7 September 2017, staying at Layer 4 but engineered for real, extreme scale and speed: AWS's own internal testing measured over 3 million requests per second at 30 Gbps before exhausting test resources. NLB provides one real static IP address per Availability Zone and preserves the original client source IP untouched — properties ALB doesn't offer — making it the real fit for long-running connections, gaming, IoT, and anything needing a fixed, hardcodable IP.

Health Checks

A load balancer periodically sends a real, configured health-check request to each registered target (an EC2 instance, a Lambda function, an IP address) and routes new traffic only to targets currently reporting healthy. An instance that starts failing its own health checks is automatically removed from rotation — no manual intervention needed — and automatically added back once it starts passing again.

Auto Scaling Groups

An Auto Scaling Group (ASG) maintains a real, defined range of running instances — a minimum, a maximum, and a desired capacity — launching new instances from a template when capacity needs to grow, and terminating instances when it needs to shrink. Real, common scaling policies include:

• Target tracking — e.g. "keep average CPU utilization at 60%"; the ASG automatically adds or removes instances to hold that target.
• Step scaling — add or remove a specific number of instances once a real metric crosses a defined threshold.
• Scheduled scaling — proactively scale capacity up or down at known, predictable times (e.g. before a real daily traffic peak).

An ASG also directly replaces an unhealthy instance the moment a health check (whether the ASG's own, or the attached load balancer's) reports it as failed — the same self-healing principle Chapter 3's own EC2 coverage never had a mechanism for on its own.

The Real High-Availability Pattern

Combining everything so far into one real, standard architecture: an Auto Scaling Group spreads its own instances across multiple Availability Zones within a Region (Chapter 1), a load balancer sits in front distributing traffic only to the healthy ones (this chapter), and the ASG automatically replaces any instance that fails, or scales the whole group up or down as real demand changes. No single instance failure, and no single AZ failure, takes the application down.

ALB vs. NLB at a Glance

Hands-On Exercises