Elastic Load Balancing & Auto Scaling Groups

AWS CLF-C02 — Domain 3: Cloud Technology & Services

Scalability & High Availability Concepts

Scalability

Scalability means an application can handle greater loads by adapting. There are two types:

Type	Description	Example
Vertical Scaling (Scale Up/Down)	Increase the size of the instance (more CPU, RAM). Has a hardware limit.	Upgrade from `t2.micro` to `t2.large`. Common for non-distributed systems like databases (RDS, ElastiCache).
Horizontal Scaling (Scale Out/In)	Increase the number of instances. No hardware limit.	Add more EC2 instances behind a load balancer. Implies a distributed system.

High Availability

Running your application in at least 2 Availability Zones
Goal: survive an AZ failure / data center loss
Goes hand-in-hand with horizontal scaling
ELB and ASG both support multi-AZ deployments

Key Point:

Elasticity = the ability to auto-scale based on demand (scale out when load increases, scale in when load decreases). This is a key cloud advantage over traditional infrastructure.

Elastic Load Balancing (ELB) Overview

A managed load balancer — AWS handles upgrades, maintenance, and high availability
Distributes incoming traffic across multiple targets (EC2 instances, containers, IPs, Lambda functions)
Provides a single point of access (DNS) for your application
Performs health checks on targets — only sends traffic to healthy instances
Provides SSL/TLS termination for your websites
Spans multiple AZs for high availability
Separates public traffic from private traffic

Load Balancer Types

Type	Layer	Protocol	Key Features	Use Cases
Application Load Balancer (ALB)	Layer 7 (Application)	HTTP, HTTPS, WebSocket	Path-based & host-based routing, fixed hostname, can see client IP (X-Forwarded-For), targets: EC2, ECS, Lambda, IP addresses	Web applications, microservices, container-based apps
Network Load Balancer (NLB)	Layer 4 (Transport)	TCP, UDP, TLS	Ultra-low latency (~100ms vs 400ms for ALB), handles millions of requests/sec, static IP / Elastic IP per AZ, targets: EC2, IP addresses, ALB	Extreme performance, gaming, IoT, real-time streaming
Gateway Load Balancer (GWLB)	Layer 3 (Network)	IP Protocol (GENEVE on port 6081)	Deploy, scale, and manage 3rd-party network virtual appliances. Single entry/exit for all traffic. Transparent to applications.	Firewalls, intrusion detection/prevention systems (IDS/IPS), deep packet inspection, payload manipulation

Exam Tip:

"HTTP/HTTPS traffic routing?" → ALB. "Ultra-low latency, TCP/UDP, static IP?" → NLB. "Network appliances (firewall, IDS)?" → GWLB. The old Classic Load Balancer (CLB) is deprecated — don't pick it on the exam.

Health Checks

ELB regularly checks the health of registered targets
Health checks use a protocol (HTTP, TCP, etc.), a port, and a path (e.g., /health)
If a target fails health checks, ELB stops sending traffic to it
Target must respond with HTTP 200 (OK) to be considered healthy
Configurable: interval, timeout, healthy/unhealthy thresholds

Key Point:

Health checks are critical for ensuring high availability. An unhealthy instance is automatically removed from the load balancer's target pool. No manual intervention needed.

Advanced ELB Features

Sticky Sessions (Session Affinity)

Ensures that a client is always redirected to the same target instance
Works with ALB and NLB (CLB deprecated)
Uses a cookie with an expiration date
Use case: ensure the user doesn't lose session data
May cause uneven load distribution across instances

Cross-Zone Load Balancing

Distributes traffic evenly across all registered instances in all AZs
Without cross-zone: traffic is distributed evenly across AZs, not instances
ALB: Always enabled (free)
NLB & GWLB: Disabled by default (charges apply if enabled)

SSL/TLS Termination

Load balancer can handle SSL/TLS encryption/decryption (offloading from EC2)
Uses an SSL certificate managed via AWS Certificate Manager (ACM)
Supports SNI (Server Name Indication) — allows multiple SSL certs on one load balancer (ALB & NLB only)
Traffic between ELB and EC2 can be HTTP (within VPC, internal)

Exam Tip:

"How to manage SSL certificates for your load balancer?" → AWS Certificate Manager (ACM). "How to host multiple HTTPS sites on one ALB?" → SNI (Server Name Indication).

Auto Scaling Groups (ASG)

Automatically scale out (add instances) to match increased demand
Automatically scale in (remove instances) to match decreased demand
Ensure a minimum and maximum number of instances running
Automatically register new instances with a load balancer
Replace unhealthy instances automatically
Free to use (you only pay for the underlying EC2 instances)

ASG Configuration

Setting	Description
Launch Template	Defines instance configuration: AMI, instance type, key pair, security groups, user data, IAM role, EBS volumes
Minimum Capacity	Minimum number of instances that must always be running
Desired Capacity	Number of instances you want running (ASG tries to maintain this)
Maximum Capacity	Maximum number of instances the ASG can scale to

Key Point:

ASG uses a Launch Template (recommended) or Launch Configuration (legacy) to know what kind of EC2 instances to launch. The ASG respects min/desired/max capacity settings.

ASG Scaling Policies

Policy Type	Description	Example
Target Tracking Scaling	Set a target metric value and ASG adjusts to maintain it. Simplest to set up.	"Keep average CPU utilization at 40%"
Simple / Step Scaling	Add/remove instances based on CloudWatch alarm thresholds. Step scaling allows different actions at different thresholds.	"When CPU > 70%, add 2 instances. When CPU < 30%, remove 1 instance."
Scheduled Scaling	Scale based on known usage patterns at specific times.	"Increase min capacity to 10 at 5 PM on Fridays" (for a known traffic spike)
Predictive Scaling	Uses machine learning to predict future traffic and schedule scaling ahead of time.	AWS analyzes historical patterns and pre-provisions instances before demand arrives.

Common Scaling Metrics

CPUUtilization: Average CPU usage across instances
RequestCountPerTarget: Number of requests per target on ALB
Average Network In/Out: If your app is network-bound
Custom Metrics: Push custom metrics to CloudWatch and scale on them

Exam Tip:

"Easiest way to maintain CPU at a target value?" → Target Tracking Scaling. "Scale based on known schedule?" → Scheduled Scaling. "ML-based scaling before demand?" → Predictive Scaling. Remember: ASG + ELB = scalable & highly available architecture.

Architecture Summary

A well-architected, scalable, and highly available setup typically includes:

Multiple AZs for high availability
ELB (ALB/NLB) to distribute traffic across AZs
ASG to automatically adjust the number of EC2 instances
Health checks to replace unhealthy instances
Launch Template to define instance configuration

Key Point:

ELB + ASG is the foundational architecture pattern for scalable, fault-tolerant applications on AWS. The load balancer handles traffic distribution, and the ASG handles capacity management.