Backup, Restore, and Disaster Recovery

There are two ways a workload goes dark. Something breaks, or something is wrong. Multi-AZ, health checks, and Auto Scaling handle the first and are useless against the second, because they faithfully replicate a bad DELETE to every copy in milliseconds. This topic covers the second half: keeping copies of data from before the mistake, restoring them under pressure, and deciding in advance how much outage and how much data loss the business will pay to avoid.

What This Topic Covers

• What an Availability Zone physically is, and the zonal, regional, and global classification that predicts exactly what an AZ failure takes with it
• Sizing a compute tier for the loss of one AZ, static stability, and the single-AZ dependencies (NAT gateways, EFS One Zone, one-subnet load balancers) that quietly undo a multi-AZ design
• Multi-AZ DB instance against Multi-AZ DB cluster against Aurora: replication method, whether the standby serves reads, and failover time
• How EBS snapshots store data incrementally while restoring completely, and why deleting one frees less than you expect
• Crash-consistent against application-consistent backups, and when the difference matters
• Choosing between Amazon Data Lifecycle Manager and AWS Backup, and building plans with lifecycle rules, cross-Region copy, and cross-account copy
• Vault Lock governance mode against compliance mode, and restore testing that measures an RTO instead of assuming it
• RDS point-in-time recovery mechanics, the 5-minute transaction log interval, automated backups against manual snapshots, and the settings every restore silently drops
• Aurora cloning and Backtrack, DynamoDB PITR, and the post-restore checklist a DynamoDB recovery needs
• S3 versioning states, delete markers against version-specific deletes, Object Lock, and what replication refuses to copy
• RTO and RPO as definitions and as decisions, the four disaster recovery strategies, and the data plane rule that decides how you fail over

Why It Matters

SOA-C03 skill 2.2 is where the exam stops asking what a feature does and starts asking what it costs you. A stem gives you an RPO of 15 minutes and a budget that rules out a second running fleet, and four options that all technically work. Picking correctly means knowing that replication buys RPO, pre-provisioned infrastructure buys RTO, and only backups protect against data that is wrong rather than missing. The same reasoning is what separates a recovery that finishes inside the RTO from one that discovers, mid-incident, that the restore built a new endpoint nobody planned to cut over to.