High Availability Architectures

High availability (HA) ensures a system remains operational despite component failures. The foundation of AWS HA is Multi-AZ deployment, distributing resources across multiple Availability Zones within a region. Each AZ is an isolated data center with independent power, cooling, and networking.

Multi-AZ EC2: Deploy instances across at least 2 AZs behind an Application Load Balancer. If AZ-A fails, the ALB routes traffic to AZ-B automatically. Auto Scaling Groups (ASGs) span multiple AZs and replace unhealthy instances. Configure the ASG to maintain desired capacity across all AZs.

Health checks are the mechanism for detecting failures. ALB health checks verify that instances respond on the expected port with an expected status code. If an instance fails health checks for the configured threshold, the ALB stops routing traffic and ASG terminates and replaces it. Health check configuration matters: too aggressive causes false positives during brief load spikes; too lenient allows failed instances to receive traffic.

Auto-recovery replaces failed EC2 instances automatically. ASG with health check replacement terminates unhealthy instances and launches replacements. For EBS-backed instances, the ASG can preserve the instance configuration (AMI, user data, block device mappings) and launch identical replacements. This creates self-healing infrastructure that recovers from hardware failures without human intervention.

Multi-AZ RDS: Enable Multi-AZ on RDS instances. AWS maintains a synchronous standby replica in another AZ. If the primary fails, RDS automatically fails over to the standby. The failover typically completes in 60 to 120 seconds. The endpoint remains the same, so applications reconnect without configuration changes.

Concrete example: A web application runs 4 instances across 2 AZs behind an ALB. Each AZ has 2 instances. The ASG maintains a minimum of 4 instances. If an AZ fails, ASG launches 2 new instances in the remaining AZ to restore capacity. Total downtime: zero for users because the ALB immediately routes to healthy instances.

Application Load Balancer (ALB) distributes HTTP/HTTPS traffic across targets (EC2, containers, IP addresses) within a region. ALB performs path-based routing (/api to backend-servers, /static to CDN-servers), host-based routing (api.example.com vs www.example.com), and weighted routing for canary deployments. Health checks ensure traffic only reaches healthy targets.

Network Load Balancer (NLB) operates at Layer 4 (TCP/UDP) for ultra-low latency and millions of requests per second. NLB preserves source IP addresses, supports static IP addresses, and handles sudden traffic spikes better than ALB. Use NLB for gaming servers, financial trading, or IoT workloads requiring raw performance.

Route 53 DNS failover provides geographic redundancy. Create a primary record pointing to the ALB in us-east-1 and a secondary record pointing to the ALB in us-west-2. Route 53 health checks monitor the primary endpoint. If the primary fails health checks, Route 53 returns the secondary endpoint, routing traffic to the healthy region.

Health check configuration: Route 53 health checks probe your endpoint from multiple locations. Configure the check type (HTTP, HTTPS, TCP), the interval (30 seconds for standard, 10 seconds for fast), the failure threshold (3 consecutive failures before failover), and the regions to check from. Use HTTPS health checks to verify SSL certificate validity.

Latency-based routing routes users to the region with the lowest latency. A user in Tokyo is routed to the Tokyo endpoint; a user in New York to the New York endpoint. Combine with health checks so users are only routed to healthy regions.

Weighted routing distributes traffic by percentage. Send 90% to the stable version and 10% to the new version for canary testing. Adjust weights gradually as confidence grows. Combine with health checks so traffic shifts away from unhealthy endpoints.

Active-active deploys identical infrastructure in multiple locations, all serving traffic simultaneously. Both the us-east-1 and us-west-2 deployments handle user requests. This pattern maximizes resource utilization and provides the best failover characteristics because the standby is already warm and serving traffic.

Active-active benefits: No capacity is wasted on idle standbys. Failover is instant because the surviving site is already handling traffic. Load is distributed across sites, improving overall performance for geographically distributed users. The pattern scales naturally by adding more active sites.

Active-active challenges: Data synchronization is complex. Both sites need access to the same data, requiring multi-master databases, shared storage (EFS, S3), or eventual consistency models. Conflict resolution is required when the same data is modified in both sites simultaneously. The deployment complexity is higher.

Active-passive keeps one site handling all traffic (active) while the other (passive) stands by for failover. The passive site receives data replication but no user traffic. When the active site fails, traffic shifts to the passive site.

Active-passive benefits: Simpler data model because only one site writes data. Lower cost because the passive site can be smaller or use cheaper resources. Simpler deployment because there's no need for multi-master conflict resolution.

Active-passive challenges: The passive site wastes resources sitting idle. Failover takes longer because the passive site needs to warm up (load caches, establish connections, scale up). If the passive site has been idle for months, it may have configuration drift that causes issues during failover.

Choosing between patterns: Use active-active for globally distributed user bases requiring the best latency and availability. Use active-passive for cost-sensitive workloads or those with complex data consistency requirements. For many workloads, a middle ground works: active-warm-standby keeps the passive site minimally scaled and warmed but not serving production traffic.