Disaster recovery

Key points

• RTO: the maximum acceptable delay between the interruption and the restoration of service. How long can we be down.
• RPO: the maximum acceptable time since the last data recovery point. How much data can we lose.
• Cost trade-off: lower RPO and RTO cost more in resources and complexity. If recovery costs more than the loss, skip it unless regulation requires it.
• Replication is not backup: continuous replication also copies corruption and malicious deletes, so keep point-in-time backups too.
• Multi-AZ first: AZs are far enough apart that most disasters hit only one, so a Multi-AZ design may already cover much of the risk.

Key points

• Backup and restore: back up data, AMIs and infrastructure as code, then rebuild everything in the recovery Region after the event.
• Pilot light: data is replicated live and core infrastructure exists, but application servers are switched off and are started and scaled out on failover.
• Warm standby: a scaled-down but fully working copy can serve traffic at once. Failover only scales it up.
• Multi-site active/active: every Region serves traffic. Hot standby is the active/passive variant at full scale.
• Data plane failover: fail over with data plane operations such as Route 53 health checks or ARC routing controls, not control plane changes.

Key points

• Backup plans: schedule, retention and transition to cold storage, assigned to resources by tags.
• Cross-Region copy: copy rules send each recovery point to a vault in the DR Region, on a schedule or on demand.
• Cross-account copy: copies to vaults in other accounts of the same AWS Organizations organization protect against a compromised account. Restore after copying into the target account.
• Vault Lock: WORM protection. Governance mode can be removed with IAM permissions. Compliance mode becomes immutable after a grace time of at least 72 hours, even for the root user and AWS.
• Audit Manager: built-in controls and daily reports show whether backups meet policy.

Key points

• Targets: RPO of seconds and RTO of minutes.
• Staging area: data lands in a staging subnet with affordable storage and minimal compute. Full-capacity instances launch only for drills or recovery.
• Point in time: recover from the latest state or from an earlier point, e.g. before a ransomware infection.
• Failback: once the primary site is fixed, replicate back and fail back when ready.
• Scope: applications and databases running on servers, not managed services such as RDS. It follows the pilot light pattern.

Key points

• Requirements: versioning on source and destination and an IAM role that lets S3 replicate. Object Lock on the source requires Object Lock on the destination.
• New objects only: live replication copies objects written after the rule exists. Use S3 Batch Replication for existing objects, failed ones and replicas of replicas.
• Deletes: delete markers are not replicated by default with current rules, and deleting a specific version is never replicated, which shields the copy from malicious deletes.
• S3 Replication Time Control: replicates most objects in seconds with a 15-minute SLA, plus metrics and events for late objects.
• CRR vs SRR: CRR for compliance distance, lower latency and DR. SRR for log aggregation, prod to test copies and data sovereignty inside one Region.

Key points

• Aurora Global Database: 1 primary Region and up to 10 read-only secondary Regions, storage-level replication typically under 1 second. A secondary can take over writes in less than 1 minute.
• Switchover vs failover: switchover moves the primary with no data loss for planned operations. Failover recovers from an outage of the primary Region.
• Write forwarding: secondary Aurora clusters can forward write statements to the primary.
• DynamoDB global tables: multi-active, every replica takes reads and writes. Multi-Region eventual consistency (default) resolves conflicts by last writer wins, multi-Region strong consistency is the other mode. 99.999% availability SLA.
• RDS cross-Region read replicas: asynchronous, promoted by hand during DR, which takes a few minutes and includes a reboot.

Key points

• Incremental: only changed blocks are saved. AWS does not back up volumes on its own, so schedule snapshots.
• Cross-Region copy: copy completed snapshots and AMIs to the DR Region. The first copy to a Region is full, later ones can be incremental.
• Data Lifecycle Manager: automates creation, retention and deletion of snapshots and EBS-backed AMIs, including copies to other Regions or accounts, at no additional cost.
• Fast snapshot restore: volumes created from the snapshot are fully initialized at creation, without first-read latency. Billed per snapshot per AZ per hour.
• Recycle Bin: restores accidentally deleted snapshots, volumes and EBS-backed AMIs before their retention period ends.

Key points

• Route 53 failover routing: health checks switch DNS answers to the DR Region automatically, a data plane operation.
• ARC routing controls: on/off switches backed by Route 53 health checks for a manually initiated, scripted failover.
• Global Accelerator: static anycast IPs in front of endpoints in several Regions. Health checks reroute traffic without DNS caching delays.
• Service quotas in the standby Region: raise them in advance so a pilot light or warm standby can scale to production size.
• Infrastructure as code: CloudFormation (StackSets across accounts and Regions) and golden AMIs copied to both Regions rebuild the environment consistently. Test the plan regularly.