Design Resilient Architectures
Disaster Recovery, Durability, and Legacy Resilience
CoreSelect DR strategy, replication, backup, and legacy reliability mechanisms from RPO/RTO and change constraints.
Aligned to the current SAA-C03 exam guide, verified August 16, 2026.
Why this matters
Disaster recovery is a business tradeoff expressed through allowable data loss and restoration time. The architect must map RPO and RTO to data protection, standby capacity, routing, and application dependencies while respecting how much the legacy application can change.
Must Know
- RPO is the maximum acceptable data-loss interval; RTO is the maximum acceptable time to restore service. Translate both before selecting a strategy.
- Backup and restore keeps little or no active standby capacity and has the slowest recovery but lowest steady-state cost.
- Pilot light keeps critical data and core services ready while most application capacity is created during recovery.
- Warm standby runs a reduced but functional copy that scales up during recovery.
- Active-active serves from multiple locations and can provide the shortest interruption, but costs more and requires conflict, routing, and operational maturity.
- Backup protects historical recovery points; replication supplies a current or near-current copy. Neither alone guarantees that the whole application can recover.
- RDS Multi-AZ provides managed high availability and failover; read replicas primarily scale reads. RDS Proxy pools connections and can improve connection resilience, but it is not a DR strategy.
- For applications that cannot be rewritten, improve resilience externally with load balancing, replication, managed migration, shared storage, and automated recovery where compatible.
Compare and Distinguish
- Backup/restore vs pilot light vs warm standby vs active-active: progressively lower RTO usually means more continuously running capacity, cost, and operating complexity.
- Multi-AZ vs cross-Region DR: Multi-AZ handles AZ failures within a Region; a second Region addresses a Region boundary.
- Backup vs replication: backup supplies recovery history; replication supplies a secondary current copy. Use both when logical corruption and fast failover matter.
- RDS Multi-AZ vs read replica: Multi-AZ is synchronous HA/failover; a read replica is mainly asynchronous read scaling and can support specific DR designs.
- RDS Proxy vs ElastiCache: Proxy pools/manages database connections; ElastiCache stores reusable data for lower read latency and offload.
Scenario examples
- Scenario: A test system tolerates a day of data loss and long recovery. Think: backup/restore may satisfy requirements at lowest steady cost.
- Scenario: A customer system needs minutes-level recovery but can scale after failover. Think: warm standby keeps a functional reduced environment.
- Scenario: Global users require near-continuous service and the application supports multi-Region writes. Think: active-active may win, but only after resolving data consistency and routing.
- Scenario: A legacy tier cannot be modified and runs on one instance. Think: improve the surrounding failure boundary with load balancing, replicated/shared state, and automated replacement where compatible.
Exam traps
- The most expensive DR pattern is not automatically required or best.
- A read replica is not synchronous Multi-AZ failover.
- Replication can copy corruption or deletion; retain independent backups.
- RDS Proxy does not make a single database multi-AZ or multi-Region.
- A low RTO plan is incomplete if DNS, secrets, keys, quotas, and dependencies are not ready.
- Durability of stored data does not imply availability of the application.
Key takeaways
- Let RPO and RTO eliminate DR patterns that cannot meet business needs.
- Broader failure boundaries and faster recovery increase cost and operational complexity.
- Combine recoverable history with replication when the threat model needs both.
- Test the complete recovery path, not only data copying.
- Respect minimal-change constraints while removing external single points.
How it works
- Backup plans create retained recovery points; restoration rebuilds usable resources from those points.
- Replication continuously or periodically copies changes according to service semantics.
- Traffic services direct clients to healthy active endpoints or a recovered standby.
- Migration and infrastructure automation help reproduce legacy servers and dependencies in the target environment.
When to use it
- Use backup/restore for lenient objectives, pilot light for core data/services with on-demand scale, warm standby for faster scale-up, and active-active for the strictest supported needs.
- Use Multi-AZ for managed in-Region relational HA and read replicas for read scale or explicit replica-based recovery designs.
- Use Application Migration Service for lift-and-shift server replication when minimal application change is central.
- Use RDS Proxy when connection storms or failover connection handling are the problem.
Security and governance implications
- Encrypt backups and replicas and ensure destination key permissions are recoverable.
- Separate backup administration from production operators where the threat model requires it.
- Protect recovery accounts and Regions with the same identity and network rigor as primary environments.
- Test break-glass access and retain audit evidence for recovery actions.
Operational and diagnostic signals
- If measured RPO is missed, inspect backup frequency, replication lag, failed copies, and write behavior.
- If RTO is missed, time each dependency and activation step instead of only database restore.
- If database clients fail after failover, inspect DNS caching, connection pools, transaction retry, and proxy behavior.
- If legacy recovery fails, inventory hidden local state, licensing, network assumptions, and external dependencies.
More detail
- Recovery time includes detection, decision, infrastructure activation, data readiness, dependency restoration, traffic change, and validation.
- Recovery point depends on the frequency and lag of the chosen protection mechanism, not the label attached to the architecture.
- Active-active requires application and data designs that tolerate concurrent service and possible consistency tradeoffs.
- Legacy reliability improvements should prioritize compatible managed services and automation over a risky forced rewrite.
Ready for the quiz?
- How do RPO and RTO change the DR choice?
- What distinguishes pilot light from warm standby?
- Why is a read replica not the same as Multi-AZ?
- Why might backup and replication both be required?
- What dependencies can invalidate an otherwise sound standby Region?
Related objectives
- D2.2.K4
- D2.2.K9
- D2.2.K11
- D2.2.S5
- D2.2.S6
- D2.2.S7