Most DR plans fail at the dependency, not the workload
Teams diligently replicate their own application across regions, then depend on a single-region managed identity service, DNS zone, or secrets store that was never in scope for the DR exercise. The outage doesn't hit the workload you tested; it hits the shared dependency nobody drew on the diagram.
A resilience review needs a full dependency trace, not just an application inventory — including the control-plane services your deployment pipeline itself depends on, which is the layer most commonly forgotten.
Choose the failure mode deliberately, per workload
Not every workload justifies active-active cost and complexity. A defensible pattern tiers workloads into three bands: active-active for revenue-critical paths, warm-standby with tested automated failover for important-but-tolerant workloads, and accepted-downtime-with-fast-restore for the rest — explicitly documented, not left to default to whatever the team happened to build.
The failure is not having a lower tier. The failure is not deciding, so that the actual tier is discovered for the first time during the outage itself.
Rehearse the failover, not just the architecture
An untested failover procedure is a hypothesis, not a plan. Game-day exercises that actually trigger regional failover (in a controlled, scheduled way) surface the stale runbooks, expired credentials and undocumented manual steps that a tabletop exercise never catches.
Treat the first real game day as expected to fail partially — that's the point. A clean first run usually means the test wasn't realistic enough.
Your resilience plan is only as strong as the one shared dependency you forgot to trace.MNB Cloud Practice
Key actions
- Trace full dependency graphs, including control-plane services
- Explicitly tier workloads into active-active, warm-standby, accepted-downtime
- Document the chosen tier per workload, not just the default
- Run scheduled game-day failover exercises, not tabletop-only reviews