CoursesAWS DevOps Engineer ProfessionalResilience & incident response

HA & DR automation

Self-healing, backup, tested failover, RTO/RPO.

Advanced30 min · lesson 14 of 15

Reliability at the professional level means automating high availability and disaster recovery, not just designing for it. The DevOps engineer codifies resilience so recovery is repeatable and meets defined objectives.

HA by default, DR by design

High availability is the baseline: Auto Scaling groups across multiple AZs behind load balancers, Multi-AZ databases, and health checks that replace unhealthy resources automatically — self-healing that absorbs component and AZ failures without intervention. Disaster recovery addresses larger events (a Region impairment) and is chosen against RTO (how long you can be down) and RPO (how much data loss is acceptable). Strategies range from backup-and-restore (cheapest, slowest) through pilot light and warm standby to multi-site active-active (fastest, most expensive). Crucially, at the professional level you automate the DR failover — codified in IaC and runbooks with data replicated ahead of time — so recovery is a repeatable, tested procedure rather than a frantic manual rebuild.

codify HA and automated DR
# HA baseline (the default): self-healing, multi-AZ, automated.
# Auto Scaling across AZs + ALB health checks → replace unhealthy instances
# RDS/Aurora Multi-AZ → automatic failover to standby
#
# DR (automated failover), chosen by RTO/RPO:
# AWS Backup → centralized, policy-based backups (meet RPO)
# cross-Region replication (Aurora Global, S3 CRR, DynamoDB global tables)
# Route 53 health-check failover + IaC/runbook → promote DR Region (meet RTO)
# ↑ REHEARSE the failover; untested DR is not DR.

Backup, replication, and testing

Meeting RPO depends on backup and replication: AWS Backup gives centralized, policy-based backups across services, and cross-Region replication (Aurora Global Database, S3 Cross-Region Replication, DynamoDB global tables) keeps a warm copy of data ready in the DR Region. Meeting RTO depends on how quickly you can bring that capacity online, which is why you automate the failover and rehearse it — the first real failover should never be during an actual disaster. Chaos engineering (AWS Fault Injection Service) deliberately injects failures to validate that your HA and DR actually work before a real incident tests them. Automating resilience and proving it through testing is what separates a design that looks reliable from one that is.

Automated resilience
high availability
multi-AZ + Auto Scaling
self-healing baseline
health checks
replace unhealthy automatically
disaster recovery
backup + replication
meet RPO (AWS Backup, CRR)
automated, tested failover
meet RTO; rehearse it
HA is the self-healing default; DR is codified, data-replicated, and rehearsed failover measured against RTO/RPO.
Untested DR is a false promise
A disaster-recovery plan that has never been exercised usually fails when finally needed — stale runbooks, replication gaps, broken permissions. Automate the failover, test it on a schedule, measure actual RTO/RPO against targets, and use fault injection to validate resilience before a real event does.