1.3 Design Reliable and Resilient Architectures
Official task mapping
SAP-C02 task 1.3: Recovery objectives and backup knowledge; recovery strategy and restore validation. This lesson applies the official task to an original design exercise; it is not an exhaustive exam syllabus.
Prerequisites
Review RDS availability, S3 recovery and business continuity. Be able to explain the relevant failure boundary and access/cost model before choosing a service.
Recovery model
RTO measures acceptable restoration time; RPO measures acceptable data loss. Availability within a Region does not automatically satisfy recovery from a Region outage. Select backup/restore, pilot light, warm standby or multi-site according to measured recovery steps and budget, not an assumed universal time table.
Backups preserve recovery points; replication alone can propagate accidental deletion or corruption. Validate encryption keys, identities, network/DNS dependencies, quotas and deployable artifacts in the recovery environment. AWS Backup organizes supported resource protection; recovery still needs tested application consistency and access.
Elastic Disaster Recovery uses continuous block-level replication for supported servers and recovery launches. It does not eliminate application validation, source-write fencing or infrastructure charges.
DR strategies and availability patterns
| Strategy | Kept ready | Work at recovery | Main trade-off |
|---|---|---|---|
| Backup/restore | Recovery points and deployable definitions | Restore data and provision stack | Lower standby spend, longer recovery path |
| Pilot light | Critical replicated core | Launch/scale application dependencies | Smaller steady footprint, more recovery steps |
| Warm standby | Functioning reduced-capacity stack | Scale and redirect traffic | More steady cost, testable running service |
| Multi-site | Active deployments | Route/fence/reconcile failures | Highest consistency and operations complexity |
These are relative design patterns, not guaranteed RTO/RPO numbers. A pilot light’s critical core can differ by application; do not insist every architecture literally has one running database and all other servers off.
Scale-out adds instances and suits partitionable/stateless work; scale-up changes resource capacity and may require a restart for the service/configuration. Neither recovers lost data. Supported EC2 recovery handles qualifying system failures and is distinct from application/OS repair or ASG replacement. Verify what identifiers, addresses and instance-store data are preserved.
AWS Backup centralizes supported protection, with feature/resource-specific cross-Region/cross-account support. Vault Lock can protect retention but must be designed carefully; immutable protection is not a substitute for restore testing.
Recovery calculation
Suppose detection/authorization takes 15 minutes, data restoration 90, provisioning 25, validation 30 and traffic cutover 10: total RTO estimate is 170 minutes. A four-hour target leaves 70 minutes of margin, not proof the measured recovery will fit. If the latest validated recovery point is two hours old, a one-hour RPO is still violated regardless of fast provisioning. Test both clocks and critical dependency access.
Scenario and rationale
A payroll system needs a four-hour RTO and one-hour RPO for regional disruption, but cannot afford a fully running second stack. Compare periodic application-consistent backups with pilot-light replication and infrastructure-as-code recovery. Select the least costly strategy whose restore, scaling, DNS and validation steps fit the objectives.
Reject active/active solely because it has the shortest theoretical RTO: conflict handling and full duplication may be unnecessary. Reject daily-only backups for the stated one-hour RPO. Do not call a successful backup job a successful recovery test.
Practice drill
Build a timed recovery worksheet: detect, authorize, restore data, launch dependencies, validate, redirect traffic and resume writes. Sum the durations and check the oldest acceptable recovery point. Add a simulated unavailable KMS key and a quota shortfall; specify corrective controls. Document a tabletop test and, only with approval, a sandbox restore.
References
- Official Domain 1 task guide
- Disaster recovery strategies
- AWS Backup restore testing
- Elastic Disaster Recovery
Return to Domain 1. The drill is proposed study work, not a claim of a completed deployment.
Across the wiki
- High Availability — high availability (Kubernetes)
- Availability — high availability (Architecture)
- SLOs and Error Budgets — high availability (DevOps)
- AKS Cluster Tiers, High Availability Control Plane, and Private Cluster Architecture — high availability (Azure)