Memory hook: Traffic can switch faster than data can become safe.
Must remember
Set RPO and RTO for the business operation, then examine every dependency: database, object store, identity, keys, secrets, DNS, images, quotas and deployment artifacts. Multi-AZ availability does not alone provide regional disaster recovery. A standby application with no accessible encryption key or sufficient quota is not ready.
Backup/restore trades lower idle cost for restoration/provisioning time. Pilot light keeps critical state or core capability available while rebuilding/scaling other components. Warm standby maintains a functional reduced-capacity environment. Active-active serves from multiple locations but adds data ownership, conflict and operational complexity. The architecture name is less important than measured recovery behavior.
Aurora Global Database commonly uses cross-Region replication to a secondary Region. A planned switchover coordinates a supported controlled role change; an unplanned failover must account for replication lag and possible data loss. The application must reconnect to the intended writer and avoid sending writes to an old or isolated primary. DynamoDB global-table consistency mode and regional topology affect guarantees; do not assume every configuration provides zero-loss synchronous semantics.
S3 replication, database replicas and synchronized files can reproduce unwanted changes. Retained backups/version history address historical recovery, subject to replication configuration, retention and keys. Cross-account backup isolation protects against a different threat from regional redundancy. Verify supported resource/copy/encryption combinations instead of assuming every AWS Backup feature applies to every service.
Route 53 health-based routing and ARC routing controls can assist controlled traffic movement for appropriate designs. DNS caching means existing clients may not move immediately. Global Accelerator can provide a stable anycast entry point with endpoint health routing, but cannot repair inconsistent application data. ARC zonal shift addresses an AZ impairment, not a complete database cross-Region promotion plan.
Failback is another migration. Reconcile writes, establish replication in the new direction where supported, verify consistency, then switch ownership/traffic in a controlled window. Simply returning DNS to the original Region can create split-brain or discard newer transactions. Run recovery exercises that measure user-visible restoration and data correctness, not merely whether infrastructure creation succeeded.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Cheap recovery with hours of acceptable outage | A tested backup/restore design may fit. |
| Minutes of recovery with reduced standby capacity | Warm standby with validated scaling and dependencies. |
| Fail back after writes in the recovery Region | Reconcile/synchronize data and control writer ownership before switching traffic. |
Traps
- Healthy endpoints do not prove consistent data.
- Asynchronous replication lag matters to RPO.
- A DNS change is not a database conflict-resolution mechanism.
Active recall
1. Why include keys in DR planning?
Recovered encrypted data is unusable without the required key and authorization.
2. What distinguishes warm standby from pilot light?
A functional reduced-capacity environment versus a more limited always-on core requiring additional activation.
3. Why fence the old writer?
To prevent divergent concurrent writes during a partition or failover.
4. What can a replica reproduce that a backup should recover from?
Corruption, destructive changes or unauthorized deletion.
5. What proves a recovery plan?
A realistic exercise meeting business RPO/RTO and data-integrity criteria.