The default three-tier web app: ALB, Auto Scaling, and RDS Multi-AZ
The single most-tested shape on the SAA exam: how a public load balancer, a self-healing compute fleet, and a database with a hot standby combine to survive an Availability Zone failure.
Three tiers, two Availability Zones
This is the reference architecture behind almost every 'design a highly available web app' scenario. It has three tiers laid out across at least two Availability Zones in one Region.
The web/entry tier is an internet-facing Application Load Balancer (ALB) in public subnets. The application tier is a fleet of EC2 instances in private subnets, managed by an EC2 Auto Scaling group. The database tier is Amazon RDS in private database subnets, deployed as Multi-AZ so a synchronous standby sits in a second Availability Zone. Route 53 holds an alias record that resolves the site's name to the ALB. The private subnets have no direct inbound path from the internet, which is the whole point of putting the load balancer in front and the instances and database behind it.
Three-tier topology across two Availability Zones
Trace
The full reference shape in one Region: Route 53 resolves the site name to an internet-facing ALB in the public subnets, which fronts an EC2 Auto Scaling group in the private app subnets, which writes to an RDS Multi-AZ primary in the private database subnets. Public subnets also hold NAT gateways for outbound egress; ACM supplies the ALB's TLS certificate. Nothing in the private subnets has a direct inbound path from the internet.
The ALB spreads Layer 7 traffic and the Auto Scaling group keeps the fleet healthy
The Application Load Balancer operates at Layer 7 (HTTP/HTTPS). It spans the two Availability Zones, runs health checks against its registered targets, and stops sending requests to any instance that fails those checks. Because it terminates HTTP, it can also do host-based and path-based routing and terminate TLS with a certificate from AWS Certificate Manager.
The EC2 Auto Scaling group is what makes the app tier both elastic and self-healing. It maintains a desired capacity of instances spread across the two AZs, launches replacements when an instance fails its health check, and scales the fleet in and out based on CloudWatch metrics (for example, target-tracking on average CPU or on ALB request count per target). The ALB gives you distribution and health-based routing; the Auto Scaling group gives you the right number of healthy instances. Neither one scales the database.
ALB Layer 7 routing plus Auto Scaling self-healing
Trace
The two complementary mechanisms of the app tier. The ALB terminates TLS (cert from ACM), health-checks every registered target, and stops routing to any target that fails; it also publishes RequestCountPerTarget to CloudWatch. The Auto Scaling group watches CloudWatch target-tracking alarms, replaces instances that fail their health checks, and scales the fleet in and out. The ALB decides where a request goes; the ASG decides how many instances exist.
RDS Multi-AZ is for availability, not for scaling reads
In a Multi-AZ deployment, RDS keeps a standby replica in a different Availability Zone and replicates to it synchronously. The standby is not a read endpoint: in the classic Multi-AZ instance deployment you cannot serve reads or writes from it, it exists purely to take over. When the primary fails (instance failure, storage failure, or an AZ disruption), RDS fails over automatically by repointing the database's DNS name (the endpoint CNAME) to the standby, typically within a minute or two. The application keeps using the same endpoint and does not need new connection strings.
The exam trap is to reach for Multi-AZ when the requirement is really about read throughput. Multi-AZ improves availability and durability. To scale read-heavy traffic you add read replicas (a separate feature) or put Amazon ElastiCache in front of the database. Read replicas use asynchronous replication and give you additional readable endpoints; the Multi-AZ standby gives you neither.
Database tier: Multi-AZ for availability vs read scaling
Trace
The exam's key distinction at the data tier. RDS Multi-AZ keeps a synchronous standby that serves no traffic and only exists to fail over: it improves availability and durability, never read throughput. To actually scale reads you add read replicas (asynchronous, additional readable endpoints) or put ElastiCache in front of the primary. The write path and the read-scaling path are deliberately drawn as different flows.
How a single-AZ failure plays out
Trace what happens if Availability Zone A goes down. The ALB, which is health-checking targets in both AZs, simply stops routing to the now-unreachable instances in AZ-a and keeps sending traffic to healthy targets in AZ-b. The Auto Scaling group notices it is below desired capacity and launches replacement instances in the surviving AZ. At the database tier, RDS detects the primary is gone and promotes the AZ-b standby, repointing the endpoint so writes resume against the new primary.
Every tier has its failure handled by a different mechanism: load balancer health checks for distribution, the Auto Scaling group for compute self-healing, and RDS Multi-AZ failover for the database. That separation is why this pattern is the default answer whenever a question asks for high availability across Availability Zones with no single point of failure.
Single-AZ failure: each tier recovers on its own
Trace
AZ-a is impaired. Three independent mechanisms respond automatically: the ALB's health checks stop routing to the unreachable AZ-a targets and keep sending traffic to AZ-b; the Auto Scaling group notices it is below desired capacity and launches replacements in the surviving AZ; and RDS Multi-AZ promotes the AZ-b standby, repointing the database endpoint CNAME so writes resume with no connection-string change. Route 53 and the ALB DNS name are unchanged.
