Post Syndicated from Peter Garnepudi original https://aws.amazon.com/blogs/architecture/three-business-decisions-that-define-your-dr-success/
Part 1 of 3
A disaster recovery (DR) strategy is only as strong as the business decisions behind it. The architecture and failover mechanisms matter, but they execute against targets that you define. In our experience facilitating enterprise DR exercises, the difference between teams that meet their recovery targets and teams that don’t often comes down to three decisions made (or deferred) before the first architecture diagram: what you’re actually recovering, what the business needs from that recovery, and what your dependencies allow you to commit to.
This post helps you validate whether your current approach accounts for each one. It draws on a pattern from a real engagement where revisiting these decisions turned a missed recovery target into a successful test four months later.
This is Part 1 of a three-part series. It walks through those three decisions and shows how to make them before you choose an architecture pattern. Part 2 covers progressive validation testing. Part 3 covers how to run a DR readiness engagement. The approach builds on the AWS Resilience Lifecycle Framework and the AWS Resilience Analysis Framework.
Define the recovery boundary
The first decision is drawing the line around what “recovered” means. You cannot meaningfully define a recovery time objective (RTO) until you specify precisely what you need working for you to consider that objective met.
The Resilience Lifecycle Framework defines a business function as the end-to-end capability a user depends on (completing a transaction, filing a report, accessing an account). A single business function often spans multiple applications, accounts, and teams. When you set a recovery target at the application level without accounting for the shared services that the application calls, you might define the boundary too narrowly to deliver the capabilities your users require.
Here’s a pattern we observed in a DR exercise for a large enterprise customer. The customer tested dozens of applications across many AWS accounts. Each application had its own failover automation, and each one failed over correctly. But a shared authentication platform (running in a separate account, managed by a different team) used Amazon Route 53 simple routing pointed at the primary AWS Region. It had no health checks and no failover configuration. Because the team didn’t include it in the recovery scope, the platform remained in the primary Region while everything else moved. The result: Most of the downstream applications that depended on it couldn’t authenticate users. Although the team had successfully failed over the applications themselves, the business function (user login, transaction, confirmation) did not work. This single boundary gap, not the individual application architectures, was the primary driver of the missed recovery target.
The solution involved redefining the recovery scope rather than changing the architecture. The organization redefined recovery boundaries around business functions (what capabilities must you deliver to your users?) rather than individual applications (is this service running?). That single change pulled the shared authentication platform inside the scope and helped the team discover the dependency. A business impact analysis is the structured starting point for this work.
Anchor the target to business consequence
The second decision is settling what recovery means in terms the business owns. Business stakeholders strengthen RTO and recovery point objective (RPO) when they help set them. In organizations where these targets are defined by engineering alone, they can become disconnected from what the business actually tolerates. A 4-hour RTO means something different for a payments platform that clears interbank settlement than it does for an internal reporting dashboard, even when both share the same database engine and replication setup.
In the same engagement, the business carried a contractual recovery commitment of 5 hours. The business treated it as a firm commitment to their regulator. The engineering team treated it as a stretch goal based on the architecture’s theoretical capability. Neither side had validated whether 5 hours was achievable given the dependency chain. That disconnect only became visible when the first exercise took 9–11 hours. The target had never been tested against the actual recovery path, and the business stakeholder who owned the penalty had never been asked whether the engineering team’s assumptions matched theirs.
RPO is a statement about data loss. For a payments platform clearing interbank settlement, an RPO of 5 minutes might still be too wide if those minutes contain transactions that can’t be reconstructed. The question for the business owner is: Which records must survive a Regional impairment, and can you prove they will? The business owner uses that framing to decide whether asynchronous replication (with its window of in-flight data loss) is acceptable. The alternative is synchronous writes, with the latency cost that comes with them.
RTO is a statement about downtime tolerance. A 4-hour recovery time is a technical figure until someone attaches a consequence to each hour. For regulatory filings, the fourth hour might mean a missed deadline with financial penalties. For a storefront, every minute carries lost orders.
The AWS Resilience Lifecycle Framework recommends defining objectives around business outcomes directly (for example, the percentage of successful orders maintained when a component degrades). A service-level agreement (SLA) is a contract with a financial penalty. A service-level objective is a target you manage toward. Raising an SLA doesn’t make an application more resilient.
The output of this decision is a recovery requirement stated in language the business recognizes and engineering can build against: the function, the consequence of losing it, the data that must survive, and the tolerable downtime before the consequence lands.
Account for the dependency chain
The third decision is confirming that your recovery target accounts for everything in the critical path, not just the components you own. Your application recovers only as fast as its slowest dependency. If a service you call takes 4 hours to recover in the recovery Region, your achievable RTO is 4 hours regardless of your own architecture.
In the same engagement, one customer-facing application had committed to a 1-hour recovery target and had the architecture to meet it on its own. But it called a shared identity service, owned by a different team, to validate every user session. That identity service carried a 4-hour recovery target. No matter how fast the customer-facing application recovered, users couldn’t do anything until the identity service came back. The application’s real, achievable RTO was 4 hours, set entirely by a dependency its own team didn’t own and hadn’t accounted for when they committed to 1 hour.
This is why the dependency chain, not the application in isolation, defines the commitment you can make. Identify and document every service your business function calls, note the recovery target each one holds, and set your own target against the slowest link you depend on. Where another team owns a dependency, its recovery target becomes a commitment you need from them, in writing, not an assumption. The AWS Fault Isolation Boundaries whitepaper helps you reason about which dependencies hold during a Regional impairment, and which introduce risk. The distinction that matters is what your runbook asks a service to do. Reading existing data keeps working during an impairment: existing credentials still authenticate, and existing DNS records still resolve. Changing things is what carries risk, because creating or modifying AWS Identity and Access Management (IAM) roles and Route 53 records runs through control planes that live in a single Region. A recovery path that only reads existing state holds up. One that must create or change resources mid-event might not. That’s the case for settling those changes ahead of time.
Where you can, reduce the chain itself. When you pre-provision and run a dependency in the recovery Region before the event, you reduce how many services need to recover before you can restore your application. The shorter the chain of things that must recover in sequence, the closer your achievable target gets to the one you want to commit to.
Where to start
Start your validation by examining one business function. Assess whether: Is the recovery boundary drawn around the full user journey, including shared services in other accounts? Has a business stakeholder confirmed the consequence-per-hour attached to the current RTO and RPO? Does the target account for every dependency in the path, including global endpoints and any runbook step that assumes resource creation during failover?
If you can answer yes to all three with evidence, your targets are well-founded. If any answer is uncertain, you’ve identified where to focus next. In Part 2, we cover how to validate your answers through progressive testing that closes the distance between a controlled exercise and real-world readiness.