3.1.1.5. Translating Business Requirements to Technical Resiliency
3.1.1.5. Translating Business Requirements to Technical Resiliency
Business stakeholders say "the app must always be available." Your job is to translate that into specific RTO, RPO, and availability targets, then architect accordingly.
Translation framework:
| Business Requirement | Technical Translation | Architecture Pattern |
|---|---|---|
| "Can't afford any downtime" | 99.99%+ availability, RTO < 5 min | Multi-region active-active |
| "A few minutes of downtime is OK" | 99.95%, RTO < 30 min | Multi-AZ with auto-failover |
| "Overnight maintenance window is fine" | 99.9%, RTO < 4 hours | Multi-AZ, manual failover |
| "Can't lose any data" | RPO = 0 | Synchronous replication (RDS Multi-AZ, Aurora) |
| "Losing up to 1 hour of data is acceptable" | RPO < 1 hour | Hourly snapshots or async replication |
Cost escalation: Each step up in availability roughly doubles infrastructure cost. 99.9% → 99.99% might mean adding a second region. 99.99% → 99.999% might mean active-active with real-time replication. Make the cost-availability trade-off explicit to stakeholders.
Well-Architected Framework — Reliability Pillar provides a structured approach: define availability targets, design for failure, test recovery procedures, and automate healing.
Exam Trap: The exam often presents a scenario with a specific RTO/RPO and multiple architecture options at different costs. The correct answer is the cheapest option that meets the requirement — not the most resilient. If RPO is 4 hours and RTO is 8 hours, daily S3 backups with cross-region copy meet the requirement. Active-active multi-region is overkill and the wrong answer.
