High availability

Key points

• Every tier: load balancer, Auto Scaling group and database must all span several AZs. One single-AZ component makes the whole stack single-AZ.
• ALB requirement: an Application Load Balancer must have at least 2 Availability Zones enabled.
• Static stability: provision enough capacity in the remaining AZs to carry the load without depending on scaling during the failure.
• Zonal shift: Amazon Application Recovery Controller (ARC) moves load balancer traffic away from an impaired AZ with a single action.
• Multi-AZ vs multi-Region: Multi-AZ covers the loss of a data center or an AZ. Losing a whole Region is disaster recovery and needs a second Region.

Key points

• Health checks: configured per target group. Unhealthy targets stop receiving traffic and get it back once healthy.
• Cross-zone: always on at the load balancer level for ALB (can be turned off per target group), off by default for NLB and GWLB.
• Auto Scaling integration: instances launched by the group register in the target group and deregister on termination. Turn on ELB health checks in the group so it replaces instances the load balancer marks unhealthy.
• Internal vs internet-facing: an internet-facing load balancer for the web tier and an internal one for the app tier build a multi-tier design.

Key points

• Target tracking: the recommended policy. Keeps a metric such as average CPU or request count per target at a target value, like a thermostat.
• Step and simple: step adjusts by different amounts depending on the size of the alarm breach. Simple applies one adjustment and waits for a cooldown.
• Scheduled and predictive: scheduled changes capacity at known times. Predictive analyzes up to 14 days of history (at least 24 hours) to forecast the next 48 hours and scales out ahead of cyclical peaks.
• Warm pools: pre-initialized instances kept Stopped, Hibernated or Running to cut scale-out latency for apps with long boot times.
• Lifecycle hooks: hold an instance in a wait state (1 hour by default) to bootstrap it before it enters service or to copy logs before it terminates.
• Instance refresh: replaces instances in a rolling way after a new launch template or AMI.

Key points

• Multi-AZ DB instance: one synchronous standby in another AZ that serves no reads. Failover points the DNS endpoint to the standby, typically in 60 to 120 seconds.
• Multi-AZ DB cluster: a writer and 2 readable standbys in 3 AZs with semisynchronous replication, for RDS for MySQL and PostgreSQL. Failover is typically under 35 seconds.
• Read replicas: asynchronous, up to 15 per source, in the same or another Region. Use them for read scaling, reporting and cross-Region DR by promotion. RDS does not auto scale them.
• Reconnect: applications must reconnect after failover and should not cache DNS for more than 60 seconds.

Key points

• Storage: each write is replicated synchronously to 6 storage nodes across AZs, whatever the number of instances. The volume grows automatically.
• Aurora Replicas: up to 15 readers with lag usually well under 100 milliseconds. The reader endpoint spreads read connections across them.
• Failover: a replica is promoted, typically in less than 60 seconds and often less than 30. Without replicas the writer is recreated, typically in less than 10 minutes.
• Promotion tiers: priority 0 (highest) to 15 decides which replica becomes the writer. Ties go to the largest replica.
• Cluster endpoint: always points to the current writer, so the connection string survives failover.

Key points

• Connection pooling: reuses database connections, so thousands of Lambda invocations or threads do not exhaust the database. Excess requests are queued or throttled instead of failing.
• Failover: keeps client connections open and routes to the new instance, bypassing DNS caches to cut failover time by up to 66% for Aurora Multi-AZ.
• Security: can require IAM authentication from clients and reads database credentials from AWS Secrets Manager.
• No code changes: most applications only switch the endpoint. The proxy lives in the same VPC as the database and is never publicly accessible.

Key points

• Health check types: an endpoint (IP or domain name), other health checks (calculated), or a CloudWatch alarm.
• Active-passive: the failover routing policy answers with the primary record while it is healthy and with the secondary when it is not, e.g. a static S3 website as a maintenance page.
• Active-active: any other routing policy (weighted, latency, geolocation) combined with health checks returns only healthy records.
• Alias records: for AWS targets such as an ALB, set Evaluate Target Health instead of creating a separate health check.
• Private resources: endpoint checks come from the internet, so monitor private resources with a health check on a CloudWatch alarm.

Key points

• Service quotas: many quotas are per account per Region and adjustable through Service Quotas. Raise them before a launch or a failover needs the capacity.
• Throttling: retry with exponential backoff and jitter, cap the number of retries and retry only idempotent operations.
• Immutable infrastructure: never change production in place. Deploy new resources (new AMI, new launch template) and shift traffic with canary or blue/green, keeping the old version for rollback.
• AWS X-Ray: traces requests across services and draws a trace map that shows bottlenecks, latency spikes and errors.
• Legacy apps that cannot change: put them behind an ALB with an Auto Scaling group across AZs, move the database to RDS Multi-AZ with RDS Proxy, and buffer fragile back ends with SQS.