What's changed: In-scope coverage: added auto scaling (EC2 Auto Scaling), app integration (MQ/Step Functions/AppSync/AppFlow), migration/transfer (Application Migration Service/DMS/DataSync/Transfer Family/Snow Family), and hybrid connectivity (Direct Connect/Site-to-Site VPN/Client VPN/Transit Gateway/PrivateLink) across sections
2.1High Availability and Scaling
Understand designing architectures that are resilient and scale with demand by combining multiple Availability Zones (multi-AZ), Elastic Load Balancing, and Auto Scaling.
Resilient design starts with eliminating single points of failure. Spread across multiple Availability Zones (AZs), distribute load with ELB, and adjust capacity with Auto Scaling.
2.1.1The core HA pattern
- Regions and AZs: a region is a geographic area containing multiple physically isolated Availability Zones (AZs); spreading across AZs survives one AZ failure.
- Elastic Load Balancing (ELB): distribute traffic to healthy targets; ALB (L7, HTTP/S), NLB (L4, ultra-fast), GWLB.
- Auto Scaling: automatically add/remove instances (scale out/in) with demand or failures; replaces unhealthy instances via health checks.
The rule for resilient design is to eliminate single points of failure (SPOFs). The classic pattern places an ELB plus an Auto Scaling group across multiple AZs. The ELB sends traffic only to healthy instances, and Auto Scaling adjusts capacity for load or failures. A common mix-up: "scale out/in (horizontal: change count)" vs "scale up/down (vertical: bigger/smaller instance)"—the cloud favors horizontal. Also, high availability (minimize downtime) vs fault tolerance (keep functioning during failures) are related but distinct. At the data layer, RDS Multi-AZ auto-fails over to a synchronous standby (availability), while read replicas scale reads (performance).
| Mechanism | Role | Note |
|---|---|---|
| Multi-AZ | Survive an AZ failure | Removes SPOF |
| ELB | Distribute to healthy targets | ALB(L7)/NLB(L4) |
| Auto Scaling | Auto-adjust count | Horizontal scaling |
| RDS Multi-AZ | Auto failover | Availability (not perf) |
| Read replica | Scale reads | Performance (not HA) |
Scenario: designing for availability and scale. Place the web tier as an ALB + Auto Scaling group across two AZs, scaling out automatically on traffic spikes. Use RDS Multi-AZ for auto failover on an AZ failure, and add read replicas if reads are heavy. The service then survives a single AZ or instance failure.
Watch the mix-ups: (1) scale out/in (horizontal: count) vs scale up/down (vertical: size). (2) RDS Multi-AZ = availability (auto failover) vs read replica = read performance—opposite aims. (3) ELB routes only to healthy targets (health checks). (4) High availability (minimize downtime) vs fault tolerance (keep functioning) are distinct.
Q. RDS Multi-AZ vs read replica? Multi-AZ is availability (auto failover to a synchronous standby); read replicas scale reads (asynchronous copies). Q. Scale out vs up? Out = more instances (horizontal); up = bigger instance (vertical). Q. ALB vs NLB? ALB is L7 (HTTP/S, path-based routing); NLB is L4 (ultra-low latency, high throughput).
The multi-AZ + ELB + Auto Scaling pattern is the classic HA design on SAA. Also know RDS Multi-AZ = availability vs read replica = read performance and horizontal (out) vs vertical (up) scaling.
2.1.2Other key in-scope services (auto scaling)
The core of horizontal scaling is Amazon EC2 Auto Scaling. It automatically adjusts the number of EC2 instances with demand or failures, keeps a target count (desired/min/max), and replaces unhealthy instances. Spreading it across multiple AZs preserves capacity in another AZ during an AZ outage. Choose it for variable workloads that need both cost efficiency and availability, and combine it with ELB health checks.
2.1.3Section summary
- Eliminate SPOFs: multi-AZ + ELB + Auto Scaling (horizontal scaling)
- RDS Multi-AZ = auto failover (availability) / read replica = read scaling (performance)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Which design keeps a service running even if one Availability Zone fails?
Q2. Which automatically adjusts the number of EC2 instances with demand/failures?
Q3. Which RDS configuration provides HA with automatic failover on primary failure?