Disaster Recovery — RTO & RPO

Your entire AWS region goes down. Power failure, fiber cut, malicious actor, hurricane. How long until your service is back? How much data did you lose? These two questions have formal names: RTO (Recovery Time Objective) and RPO (Recovery Point Objective). Every serious system has explicit numbers for both, agreed with the business, and architecture designed to meet them.

"We have backups" is not a DR plan. "Our RTO is 1 hour, RPO is 5 minutes, tested quarterly via region failover" is.

• RTO — Recovery Time Objective. How long until the service is back up after disaster strikes. "Within 1 hour."
• RPO — Recovery Point Objective. How much data loss you can tolerate. "At most 5 minutes of writes lost."

They're orthogonal. You can have low RTO + high RPO ("we're back fast but lost a day of orders") or high RTO + low RPO ("we lost zero data but were down 12 hours"). Most businesses want both low — and pay for it.

Cost scales steeply. Match tier to business impact:

• Backup & restore — internal tools, dev environments, low-stakes apps. Most startups have only this and don't realize.
• Pilot light — moderate-importance services where 1-hour downtime is annoying but not lethal.
• Warm standby — most B2B SaaS, e-commerce. 15-minute RTO is what enterprise customers expect.
• Multi-site active-active — payments, healthcare, financial trading, any system whose downtime makes the news. Pay 2×.

The forcing function: SLA. If you sell 99.99% uptime (52 min/year), warm standby barely qualifies. If you sell 99.999% (5 min/year), only active-active works.

The plan is a document with these sections:

1. Service inventory — every component, its tier, RTO/RPO, dependencies. Everything that's not on this list is implicitly RTO=∞.
2. Trigger conditions — what events cause DR activation. "Region health-check failure for > 5 min" → declare incident.
3. Decision authority — who calls the failover. Specific named people + 24/7 contact.
4. Failover runbook — step-by-step. Tested. The 3am person should not need to think.
5. Communication plan — status page, customer email templates, leadership escalation.
6. Data validation — how do we verify the DR region's data is intact post-failover.
7. Failback procedure — once primary recovers, how to come home. Often more dangerous than the original failover.
8. Test cadence — quarterly minimum. Annual full-region failover.

Critical: untested DR doesn't exist. The first time you fail over should not be in a real disaster. Game-day drills find the broken assumptions before they bite — pair this with chaos engineering.

Payment gateway demands the strictest RTO/RPO. Stock exchange and trading platforms run multi-region active-active. E-commerce checkout + inventory uses warm standby with sub-minute RPO. Distributed logging trades higher RPO (hourly) for lower cost.