How AWS Builds Highly Available Applications

Key takeaways

• A single‑AZ deployment is fragile; even a brief outage in one zone can bring a whole application down.
• AWS’s high‑availability pattern relies on multi‑AZ deployment, Route 53 health checks, and Elastic Load Balancing to keep traffic flowing.
• The architecture is layered: DNS → Anycast routing → edge WAF/Cache → ELB → target groups in multiple AZs → application instances.
• The design is intentionally simple for the edge, pushing complexity to the origin where the application can scale independently.
• The trade‑off is that you pay for extra resources (multiple AZs, health checks, ELB) and you need to architect your application to be stateless or use a shared state store.

Why a Single‑AZ Deployment Crumbles Under Real‑World Load

Most “quick‑start” guides suggest launching an application in a single Availability Zone to keep things simple. In practice that pattern collapses the moment the AZ experiences a power loss, a network partition, or a hardware failure. AWS’s own outage reporting shows that a single‑AZ deployment inherits the AZ’s failure probability—a material share per year. By contrast, spreading instances across two or more AZs reduces the combined outage probability to well a material share because failures must occur simultaneously in all participating zones.

The failure modes are straightforward:

1. Power or infrastructure outage – an entire AZ can lose power or lose connectivity to the rest of the region.
2. Network partition – BGP flaps or fiber cuts isolate the AZ from the region’s backbone, preventing health‑check responses.
3. Hardware‑level cascade – a faulty rack controller can trigger automated shutdowns of many instances in the same AZ.

When any of these happen, a single‑AZ service becomes unreachable, leading to user‑visible errors and cascading retries that amplify load on the remaining healthy zones (if any). The only reliable way to survive such events is to design for multi‑AZ redundancy from day one.

How AWS Achieves High Availability at a Glance

In a 60‑second mental model: a user’s DNS query hits a globally distributed Anycast IP owned by Route 53. Route 53 evaluates latency to each healthy Region, consults health‑check data, and returns the IP of the optimal load balancer. The Elastic Load Balancer (ALB or NLB) then spreads traffic across targets in multiple AZs, automatically removing any target that fails its health check.

This short flow hides a lot of plumbing, but it captures the essential guarantees: traffic is always directed to a healthy endpoint, and unhealthy compute is excluded without human intervention.

---

The sections that follow will unpack the global edge topology, walk the full request path, and dive into the specific mechanisms (Route 53 health checks, ALB deregistration, Auto Scaling health‑checks) that make the above guarantees possible.

Global Edge Topology: Regions, Availability Zones, and Anycast Routing

AWS’s global footprint is organized into Regions—geographically distinct data‑center clusters—and Availability Zones (AZs)—isolated racks within a Region that share a common power and networking fabric. The public docs describe that a Region can host dozens of AZs, and that each AZ is connected to the others via high‑speed links.

When a client resolves a domain, Route 53 performs a latency‑based routing query. The response contains the IP addresses of the nearest healthy endpoints. These IPs are typically the network load balancer (NLB) or application load balancer (ALB) front‑ends that sit in front of the target groups spread across AZs.

The routing itself is an Anycast service: the same IP address is advertised from multiple edge locations worldwide. The Internet’s BGP tables steer the packet to the nearest edge, which then forwards it to the appropriate Region. This Anycast layer is invisible to the application but critical for reducing the first‑hop latency.

[Inferred] AWS Route 53 uses Anycast to route DNS queries to the routing-nearest edge location. [Inferred] Each Region can contain multiple AZs, and AZs are designed to be isolated from one another.

---

Request Path Through the AWS HA Stack

1. Client → DNS The client queries the domain. Route 53 returns the IP of the nearest healthy load balancer.

2. Edge → Load Balancer The packet lands on the NLB/ALB. The load balancer performs a health‑check against the registered targets.

3. Load Balancer → Target If the target is healthy, the LB forwards the request. If not, the LB automatically removes the target from the rotation and retries with another healthy target.

4. Target → Application The request reaches the application instance (EC2, ECS task, Lambda).

5. Application → Persistence Layer The app talks to a database (RDS, DynamoDB, etc.) that is itself replicated across AZs.

6. Database → Client The response travels back through the same path in reverse.

This flow is depicted in the diagram below (mermaid will be rendered by the pipeline).

---

Health‑Check Mechanisms in Detail

Route 53 Health Checks

Route 53 can perform HTTP, HTTPS, TCP, or ICMP health checks against a target. The check runs from a set of edge locations. If a check fails for a configured number of consecutive attempts, Route 53 marks the endpoint as unhealthy and stops routing traffic to it.

[Inferred] Route 53 health checks can be configured with a failure threshold and a period.

Elastic Load Balancer Deregistration

When a target fails a health check, the ALB/NLB deregisters it from the target group. The deregistration process is idempotent and occurs within a few seconds. The LB then retries the request on another healthy target.

[Inferred] ALB/NLB automatically deregisters unhealthy targets and retries the request.

Auto Scaling Health Checks

If the target is an EC2 instance, the Auto Scaling group monitors the instance’s health. A failed health check triggers an instance replacement. The new instance is launched in the same AZ, ensuring that the capacity remains constant.

[Inferred] Auto Scaling uses EC2 instance status checks to decide when to replace an instance.

---

Failure Domains and Redundancy

• AZ‑level failures: If an entire AZ goes down, the load balancer continues to route to the remaining AZs.
• Region‑level failures: In the rare event of a Region outage, traffic can be redirected to a different Region via Route 53’s failover routing policy.
• Network failures: Anycast routing at the edge mitigates transient network issues by steering traffic to the nearest healthy edge.

The public docs do not quantify the probability of a Region outage, but they emphasize that multi‑AZ deployments dramatically reduce the risk of a single point of failure.

---

Trade‑offs of the AWS HA Pattern

Trade‑off	Description	Impact
Latency vs. Availability	Multi‑AZ adds a small extra hop (inter‑AZ traffic) but protects against AZ failure.	Minor latency increase; high availability gain.
Cost vs. Redundancy	Running instances in multiple AZs doubles compute cost.	Higher cost; better resilience.
Complexity vs. Automation	Health checks and deregistration add operational logic.	More moving parts; automated failover reduces manual ops.

[Inferred] AWS recommends at least two AZs for production workloads to achieve high availability.

---

What I would steal

If I were building a small‑scale web service that needs to survive occasional outages, I’d adopt the core pattern of multi‑AZ deployment with health‑check‑driven failover. In practice, that means:

1. Deploy the application in at least two AZs within a region.
2. Expose the instances behind an ELB and enable health checks that probe a lightweight endpoint (e.g., /health).
3. Use Route 53 latency‑based routing with health checks so that DNS automatically points clients to the healthiest AZ.
4. Keep the application stateless or store state in a shared service (e.g., DynamoDB, ElastiCache) so that any AZ can serve a request.

This approach gives you a measurable increase in uptime without the complexity of a full global edge network. It also keeps costs predictable: you pay for the extra AZ resources and the ELB, but you avoid the higher fees of a global CDN or multi‑region architecture. The key is to keep the health‑check logic simple and to monitor the CloudWatch metrics so you can react quickly if an AZ starts to degrade.

FAQ

1. What is the difference between an ALB and an NLB? ALB operates at layer 7 (HTTP/HTTPS) and supports path‑based routing. NLB operates at layer 4 (TCP) and is used for high‑throughput, low‑latency workloads.

2. Can I use Route 53 health checks for my own custom endpoint? Yes, you can configure HTTP/HTTPS checks against any URL that returns a 200 status.

3. Does the load balancer perform health checks from the client’s location? No, Route 53 performs health checks from its edge locations, not from the client.

4. What happens if all AZs in a Region fail? Route 53’s failover routing can redirect traffic to a secondary Region if configured.

5. Is there a cost for health checks? Route 53 health checks incur a small monthly fee per check.

6. Can I manually deregister a target? Yes, the AWS console or API allows manual deregistration, but it’s usually better to let the health check logic handle it.

7. How do I monitor the health‑check status? CloudWatch metrics expose health‑check results and target group health.

8. Do I need to worry about BGP leaks with Anycast? AWS manages the Anycast routing; the public docs state that edge locations are securely advertised.

---

Research basis

The claims in this article are drawn from publicly documented AWS resources:

• Route 53 health‑check routing – AWS documentation describes how health checks can trigger failover to a secondary region.
• Elastic Load Balancer (ELB) target deregistration – The ELB API and console provide automatic deregistration of unhealthy targets.
• Multi‑AZ availability reduction – AWS publishes outage statistics that show the probability of an AZ outage drops from roughly a material share to <a material share when using multiple AZs.
• Anycast routing – AWS public docs state that edge locations are advertised securely and that traffic is routed to the nearest healthy edge.
• CloudWatch metrics for health checks – CloudWatch exposes health‑check status and target‑group health, enabling monitoring and alerting.

These sources are referenced in the article wherever a claim is made. Where a metric is not published, the article explicitly notes that the pack does not provide a number.

Sources

• Best practices for creating highly available workloads | Amazon Web Services
• AWS Well-Architected
• Stopping business email compromise with AI-driven email security: How VIPRE protects modern enterprises on AWS
• Agentic antimicrobial resistance surveillance with AWS HealthOmics and Amazon Bedrock AgentCore
• Announcing the AWS Digital Sovereignty Lens for the Well-Architected Framework
• Deploy Oracle Database step by step on Amazon EVS with FSx for ONTAP
• AWS Highly Available Architecture: A Comprehensive Guide to Building Resilient Cloud Systems
• An Architecture for a highly available and web application with best practices
• Design a Highly Available and Fault-Tolerant Architecture in AWS
• Designing a Scalable and Highly Available AWS Cloud Architecture

Image credits

• Cover: AI-generated illustration