Disaster Recovery preparedness
summary
Chaos engineering is used to simulate real AWS outages to validate DR plans by measuring RPO and RTO and closing the gap between detection and auto recovery for example a 10 minute RTO fails if auto recovery takes 20 minutes. Strategies mapped to numbers include backup and restore (hours to 24h), pilot light (minutes), warm standby (reduced always‑on fleet), and active-active (RPO seconds). Start with host‑level failures, build recurring CI/CD experiments via the CDK pipeline that trigger fault injection, then review postmortems and automate runbooks.
AI-written summary · about
chapters (11)
- 0:00Disaster recovery intro
- 1:04High availability vs DR
- 3:33Defining recovery point and time objectives
- 5:43DR strategies overview
- 6:45Testing recovery importance
- 7:05Resiliency and chaos basics
- 8:29Small chaos experiments
- 9:53Post-mortem reviews
- 12:01Recurring chaos experiments
- 13:24Chaos in CI/CD automation
- 14:06Closing and resources
related talks
14mExpect the unexpected: Building resilience with AWS
32mDisaster recovery strategies for increased resiliency
35mImprove resilience with automated chaos engineering
48mRTO & RPO – Best Practices in Hybrid Architectures
26mImprove application resilience with chaos engineering
41mWays to optimize Cloud Disaster Recovery cost
48mRecover Applications in Minutes with Disaster Recovery
47mBuilding Resilience