AWS High Availability Architecture: Multi-AZ Design, Failover Patterns & Best Practices
High availability is about designing systems that keep working when parts of them break. On AWS, that means spreading workloads across multiple data centers, removing single points of failure, and letting AWS handle the healing automatically.
What is high availability, in plain English?
Every system fails eventually. Hard drives die. Network switches drop packets. Software crashes. The question is not whether something will fail. It is how much that failure matters to the people using your application.
High availability (HA) is a design goal: build systems so that individual failures do not take the whole thing down. Instead of one server handling all your traffic, you have multiple. Instead of one database, you have a primary and a standby. When something breaks, another component takes over and users experience a brief hiccup rather than a full outage.
In AWS, most of this recovery happens automatically. You configure the architecture once and the services handle failover for you.
Multi-AZ deployment is like running two electrical feeds to a building from two separate substations. If one substation loses power, the building keeps running from the other. The occupants barely notice. The lights might flicker for a second, but nothing shuts down permanently.
What high availability means in AWS
High availability means a system recovers quickly when components fail. The goal is to remove single points of failure (components whose failure would bring down the entire system) and to make recovery automatic rather than manual.
HA is typically measured as an uptime percentage:
- 99.9% (“three nines”): About 8.7 hours of downtime per year
- 99.99% (“four nines”): About 52 minutes per year
- 99.999% (“five nines”): About 5 minutes per year
High availability is not the same as zero downtime. A highly available system may have 30 to 120 seconds of disruption during a failover event. That is acceptable for most applications. True zero-downtime operation (fault tolerance) requires active redundancy at every single layer and costs significantly more to build and operate.
High availability vs fault tolerance vs disaster recovery
These three concepts solve related but different problems.
| Concept | What it means | Typical AWS example |
|---|---|---|
| High availability | Recover quickly from component failures; brief downtime acceptable | Multi-AZ RDS + ALB + ASG across two AZs |
| Fault tolerance | System keeps operating with zero interruption even when components fail | Active-active across AZs with no standby components in the request path |
| Disaster recovery | Restore service after catastrophic events: regional outages, data corruption | Cross-region backups, Route 53 failover routing, tested restore runbooks |
Most web applications target high availability. True fault tolerance requires active redundancy at every layer. Nothing can sit in standby. Everything must actively serve traffic simultaneously. It costs significantly more.
Disaster recovery is a separate concern that involves RTO (Recovery Time Objective: how long before service is restored) and RPO (Recovery Point Objective: how much data loss is acceptable). DR planning matters when the failure scenario is a whole region going down or data getting corrupted, not just a single AZ or instance failing.
How it works in a typical AWS web application
Take a standard three-tier application: a public-facing website, a backend API, and a relational database. Here is what a highly available version looks like on AWS and why each component matters.
Step 1: DNS with Route 53
Users reach your application via a DNS name. Route 53 resolves that name to your load balancer. On its own, Route 53 does not make an app highly available. It routes traffic to whatever you point it at. Its HA contribution comes when you attach health checks and configure failover routing so it automatically stops sending traffic to an unhealthy endpoint.
Step 2: Application Load Balancer across AZs
An Application Load Balancer (ALB) sits in front of your compute layer and spans at least two Availability Zones. Users hit a single DNS name. The ALB distributes requests across healthy instances and automatically stops routing to any instance that fails its health check. If an entire AZ goes down, the ALB routes all traffic to instances in the remaining AZ.
Step 3: Auto Scaling Group across two or more AZs
An Auto Scaling Group (ASG) manages the EC2 instances behind the ALB. Set a minimum of 2 instances, one in each AZ. If an instance becomes unhealthy, the ASG terminates it and launches a replacement automatically. If traffic spikes, the ASG adds more instances to match demand and scales back down when it drops.
Step 4: Database layer with Multi-AZ
RDS with Multi-AZ enabled runs a primary database in one AZ and keeps a synchronous standby replica in a different AZ. Writes are acknowledged only after both the primary and standby confirm them. If the primary instance or its AZ fails, RDS promotes the standby and updates the DNS endpoint automatically. Your application reconnects to the same endpoint with no manual intervention. Failover typically completes within 60 to 120 seconds.
RDS Multi-AZ improves availability, not read performance. The standby replica is not accessible for queries. It exists solely as a failover target. If you need to scale read throughput, that is what Read Replicas are for — they are a separate RDS feature.
Step 5: Health checks and automatic failover
Health checks are the mechanism that ties everything together. Without them, AWS services cannot know when a component has failed.
Configure your ALB with an HTTP health check: something like GET /health that returns 200 only when the application is running correctly and can reach the database. The ALB polls this every 30 seconds. Two consecutive failures remove the instance from the pool. Set health_check_type = "ELB" on the ASG so it uses ALB results (not just EC2 status checks) to decide when to replace instances.
A health check endpoint is like a smoke detector, not a heat sensor. A heat sensor only fires when things are already very hot. A smoke detector catches a problem earlier. A health check that probes your database connection catches a broken app before users start seeing errors, not after.
resource "aws_autoscaling_group" "web" {
min_size = 2
max_size = 10
desired_capacity = 2
vpc_zone_identifier = [aws_subnet.private_az1.id, aws_subnet.private_az2.id]
health_check_type = "ELB"
health_check_grace_period = 300
launch_template {
id = aws_launch_template.web.id
version = "$Latest"
}
}The grace period of 300 seconds gives new instances time to start the application before health checks begin. Without it, instances get replaced in a loop before they have finished booting.
Common single points of failure in AWS
A single point of failure (SPOF) is any component that, if it fails, brings down the whole system. Here are the most common ones and the AWS-native fix for each.
| SPOF | Why it breaks availability | AWS fix |
|---|---|---|
| Single EC2 instance serving all traffic | One failed instance or AZ event takes the app offline | ALB + ASG with minimum 2 instances across 2 AZs |
| Single-AZ RDS database | AZ failure or instance crash means the database is unavailable | Enable RDS Multi-AZ from day one |
| Hardcoded instance IP in app config | Instance replacement changes the IP, breaking connections | Always use the ALB DNS name or RDS endpoint |
| Single NAT Gateway for all private subnets | NAT Gateway AZ failure means all private instances lose outbound access | Deploy one NAT Gateway per AZ with AZ-specific route tables |
| Lambda calling a downstream service with no retry logic | A downstream blip causes cascading failures | Add retry with exponential backoff; use a dead-letter queue for async calls |
| Health check that always returns 200 | A broken app keeps receiving traffic | Health check should verify actual app behavior, including DB connectivity |
Multi-AZ vs Multi-Region
These are two different levels of redundancy with very different cost and complexity trade-offs.
Multi-AZ means deploying resources across two or more Availability Zones within the same AWS Region. AZs are separate physical data centers with independent power, cooling, and networking, connected by low-latency private links (sub-millisecond). Multi-AZ handles the vast majority of real-world failure scenarios: hardware faults, AZ-level power events, software crashes.
Multi-Region means running your application in two or more separate AWS Regions (for example, us-east-1 and eu-west-1). This protects against an entire region becoming unavailable, which does occasionally happen. It also lets you serve users from a geographically closer region, reducing latency.
The trade-offs are significant. Multi-Region adds:
- Cost: roughly double the infrastructure in a second region
- Complexity: cross-region replication introduces latency and consistency challenges that are difficult to reason about
- Operational overhead: deployments, secrets, and configuration must be managed in each region independently
Most workloads need solid Multi-AZ before they need Multi-Region. Get Multi-AZ right first. Only add Multi-Region when you have a hard regulatory requirement, a strict SLA that a single region cannot meet, or genuine global latency requirements. The Multi-Region Architectures page covers the patterns and trade-offs in detail.
When cross-region traffic management is needed, Route 53 failover and latency-based routing is the primary tool for directing users to the right region automatically.
When to use this architecture
Not every application needs the same level of availability. Here is a practical guide by scenario.
Small internal tool or admin panel
A single EC2 instance behind an ALB is probably acceptable. If it goes down for 10 minutes, the impact is limited. Full Multi-AZ is over-engineering for a tool that five people use during business hours.
Customer-facing production app
Deploy across at least two AZs from day one. Use an ALB, an ASG with minimum 2 instances, and RDS Multi-AZ. This covers the most common failure scenarios without excessive cost. Add CloudWatch alarms so you are notified about problems even when auto-healing handles them silently.
App with SLA commitments or regulated data
Consider more aggressive health checks, documented failover runbooks, and clearly defined RTO/RPO targets. This is where disaster recovery planning starts to matter alongside HA architecture.
Global or latency-sensitive application
Evaluate Multi-Region architectures and stateless service design. Stateless services are significantly easier to replicate across regions because there is no shared session state to synchronize between locations.
Common mistakes
- Setting ASG minimum to 1. With a single instance, a failed health check or AZ event leaves you with zero healthy instances until a replacement launches. Always set minimum to at least 2, distributed across different AZs.
- Forgetting the database layer. Teams deploy web servers across AZs but leave RDS in a single AZ. The database becomes the only real SPOF. Enable Multi-AZ on RDS from day one. It roughly doubles the instance cost but eliminates a critical risk.
- Shallow health checks. A health check that returns a static 200 does not verify the app can actually serve requests. Include a lightweight database connectivity check in your
/healthendpoint so a broken DB connection removes the instance from the load balancer pool before users see errors. - Never testing failover. Setting up Multi-AZ and assuming it works is not the same as knowing it works. Use the RDS “Reboot with failover” option periodically to verify your application handles reconnection gracefully and your actual RTO matches your expectations.
- Confusing HA with disaster recovery. Multi-AZ handles instance and AZ failures. It does not protect you from data corruption, accidental deletion, or a full regional outage. Those require a separate DR strategy with tested backup restore procedures and defined RTO/RPO targets.
- Assuming managed means production-ready. RDS, ElastiCache, and other managed services handle infrastructure reliability well, but you still need to enable Multi-AZ, configure backup retention, define maintenance windows, and test your application’s reconnect behavior. “Managed” reduces your operational burden. It does not eliminate your architecture decisions.
Setting up high availability and never testing the failover. When a real outage hits at 2am, you will discover whether your RDS endpoint reconnects cleanly, whether your app handles a brief connection drop, and whether your team knows the runbook. Do not find out for the first time during an incident.
Practical checklist before shipping
Use this before launching a production workload:
- At least two AZs used for compute resources
- ALB (or NLB) in front of compute, no hardcoded instance IPs anywhere in config
- ASG minimum set to 2 or more, with instances spread across AZs
- RDS Multi-AZ enabled (not just automated backups)
- Health checks configured at the ALB level and verified to test real application behavior
- One NAT Gateway per AZ if using private subnets, with AZ-specific route tables
- Failover tested: can your app reconnect cleanly after an RDS failover?
- CloudWatch alarms in place for key metrics: CPU, unhealthy host count, DB connections
- No single-AZ dependencies hidden deeper in the stack (EFS mount targets, ElastiCache clusters)
- Security posture reviewed so HA architecture does not loosen security group rules or IAM permissions
Summary
- High availability means fast recovery from failures. Most apps target HA rather than full fault tolerance, which requires active redundancy everywhere and costs significantly more.
- Eliminate SPOFs at every layer: ALB instead of a single EC2 IP, Multi-AZ RDS instead of single-AZ, ASG with at least 2 instances across different AZs.
- Health checks are what make auto-healing work. Configure them at the ALB and ASG level and make them meaningful, not just static 200 responses.
- Multi-AZ handles the vast majority of real-world failures. Multi-Region is only warranted for strict regulatory, SLA, or global latency requirements.
- Test your failover regularly. A failover setup that has never been tested is a setup you cannot rely on when it matters.
Frequently asked questions
What is high availability in AWS?
High availability means designing a system so it recovers quickly from component failures with minimal user-visible downtime. In AWS, this typically means deploying across multiple Availability Zones, using load balancers, and letting services like RDS and Auto Scaling handle failover automatically.
Is Multi-AZ enough for most applications?
Yes, for the vast majority of production workloads. Multi-AZ removes the most common causes of downtime: hardware failure, AZ-level power or network events, and database crashes. Multi-Region is only justified for very strict SLA requirements or global latency concerns.
What is the difference between high availability and disaster recovery?
High availability keeps a system running during normal operational failures like a failed instance or AZ outage. Disaster recovery (DR) is a broader strategy for restoring service after catastrophic events like regional outages or data corruption. DR involves backup strategies, RTO/RPO targets, and often cross-region failover plans.
Does RDS Multi-AZ improve availability or read performance?
Availability only. The Multi-AZ standby is not accessible for reads. It exists solely as a failover target. If you want to scale read throughput, you need RDS Read Replicas, which are a separate feature from Multi-AZ.
Do I need Multi-Region for a production app?
Probably not at first. Most production applications handle failures adequately with Multi-AZ architecture. Multi-Region adds significant cost, complexity, and data consistency challenges. Start with solid Multi-AZ, then evaluate multi-region if you have a hard regulatory requirement or your uptime SLA cannot be met with a single-region setup.