AWS Disaster Recovery The Complete Production Guide

We take nightly backups” is not a disaster recovery plan. It’s a data recovery plan, and the difference between the two is the entire subject of this article. A nightly S3 backup tells you that your data exists somewhere. It tells you nothing about how long it takes to get a working application back in front of users, whether your IAM roles and security groups exist in the region you’re restoring into, whether your Terraform state even describes what needs to be rebuilt, or whether anyone on the team has actually run this restore process outside of a slide deck.

AWS spans 33 regions and 105 availability zones, and that geographic redundancy is precisely why “just use a different region” sounds simple and is actually one of the more involved architectural decisions you’ll make. A real disaster recovery plan is a specific, tested, costed answer to two numbers how much data can you afford to lose, and how long can you afford to be down and a concrete architecture built to hit both. This guide covers all four of AWS’s canonical DR patterns end to end, the Route 53 and database mechanics that make failover actually work, the part almost every DR plan forgets (restoring infrastructure, not just data), and how to test any of this before you need it for real.

RTO and RPO: The Two Numbers That Define Everything Else

Before any architecture decision, two numbers have to be agreed on explicitly, in a room with the people who own the budget, because every pattern in this article is a different trade-off between them and cost.

Recovery Time Objective (RTO) is how long the business can tolerate being down. Fifteen minutes and four hours are entirely different engineering problems with entirely different price tags.

Recovery Point Objective (RPO) is how much data loss is acceptable, measured in time. An RPO of five minutes means that in the worst case, you lose the last five minutes of writes. An RPO of 24 hours means you’re accepting that a disaster at 11:59 PM could lose an entire day of transactions.

Neither number should be “zero” by default. Zero RTO and zero RPO are achievable, but they are also the most expensive pattern in this article by a wide margin, and most workloads don’t actually need it a marketing website and a payments ledger have very different honest answers to both questions, and pricing them the same way is how DR budgets get rejected by finance before they get built.

The Four Patterns, and the Spectrum They Sit On

AWS’s own disaster recovery guidance organizes every real world DR architecture into four patterns, ordered along a single spectrum as RTO and RPO requirements tighten, cost and operational complexity increase correspondingly.

The instinct to default to the right-hand side of this spectrum because it sounds safest is exactly the instinct that blows DR budgets. The right question isn’t “what’s the best DR pattern” it’s “what does this specific workload’s RTO/RPO actually require, and which pattern hits that at the lowest cost.” Most organizations end up running two or three different patterns simultaneously across different workloads, not one pattern for everything.

Pattern 1 Backup and Restore

This is the foundation every other pattern builds on, and it’s frequently sufficient on its own for genuinely non-critical workloads with an RTO measured in hours rather than minutes.

AWS Backup handles the mechanics: on a defined schedule, it creates a snapshot at that point in time from the existing snapshot plus all transaction logs up to that point, giving you point-in-time recovery rather than just discrete daily snapshots. The critical configuration decision is where those backups live a backup vault in the same region as the resource it’s protecting doesn’t protect you against a regional failure at all, which is a mistake more common than it should be.

Cross-region backup replication costs roughly $0.03–0.05 per GB per month on top of standard storage pricing genuinely cheap insurance relative to what the other three patterns cost, which is exactly why it’s worth having even for workloads that also run a more sophisticated pattern.

The mistake that turns this pattern from “cheap insurance” into “false confidence” is backing up data without backing up the infrastructure definition needed to actually use it. A database snapshot in us-west-2 is useless without the VPC, subnets, security groups, IAM roles, and application configuration that let something actually connect to it which is why this pattern only works if your infrastructure is defined in Terraform or CloudFormation, versioned, and restorable in the correct dependency order. More on this later, because it’s the single most common gap in real DR plans regardless of which pattern you’re running.

Pattern 2: Pilot Light

Pilot Light keeps the absolute minimum running in the DR region continuously typically just a database replica staying in sync while everything else (compute, load balancers) exists only as infrastructure-as-code, ready to be stood up quickly when needed, rather than pre-provisioned and idle.

The database is almost always the piece kept warm, because a database is the one component that can’t be recreated from a template in minutes it needs time to actually replicate the data. For RDS, this means a cross-region read replica

Replication lag on this replica is your RPO for this pattern, measured continuously, not assumed. Amazon RDS’s cross-Region read replicas use asynchronous replication, and the acceptable range for that lag against your stated RPO is something you monitor actively, not a number you check once during setup and forget

That alarm firing means your actual RPO has silently degraded past what you promised the business this is the kind of drift that a DR plan built once and never monitored will never catch until the disaster itself reveals it.

When failover actually happens, the “light” ignites application tier infrastructure gets stood up from Terraform/CloudFormation in the DR region, and the replica gets promoted to a standalone writable primary

This promotion is a one-way door for that replica once promoted, it’s an independent primary, and re-establishing replication back to the original region requires setting up a fresh replication relationship in the reverse direction, not simply reversing a flag. Plan the failback process with the same rigor as the failover process; it is not the same operation run backwards

Pattern 3: Warm Standby

Warm Standby runs a scaled-down but fully functional version of the complete stack continuously in the DR region not just the database, but the application tier too, typically at a fraction of production capacity, ready to scale up rather than being created from scratch.

This is the pattern where Route 53’s health-check-driven failover routing does most of the operational work, and it’s worth understanding the mechanics precisely rather than treating it as a black box. A public hosted zone with a failover routing policy monitors the primary region’s health continuously, and when the primary becomes unhealthy, DNS answers switch to the DR region’s endpoint automatically no human has to notice the outage and manually repoint anything.

The health check itself needs to verify something meaningful an actual application health endpoint that confirms the app can serve real traffic, not just that a load balancer is technically listening on port 443, since a load balancer can be reachable while the application behind it is completely broken.

For workloads that need tighter recovery orchestration than DNS TTL based failover alone provides, AWS has since released Route 53 Application Recovery Controller with a Region Switch capability a fully managed service specifically for multi-region recovery orchestration, including readiness checks that continuously verify the DR region is actually prepared to take over, not just reachable. For anything beyond the simplest Warm Standby setup, ARC’s readiness checks are worth building in from the start rather than discovering during an actual incident that “warm” standby had quietly drifted out of sync with primary.

Pattern 4: Active-Active

Active-Active runs full production capacity in every region simultaneously, with all regions actively serving live traffic all the time not primary-and-backup, but multiple equal primaries. This is the only pattern on this list that gets you close to zero RTO and zero RPO, and it is also where the real engineering difficulty lives, because it introduces a problem the other three patterns don’t have to solve at all what happens when the same record gets written in two regions within the same second.

This is a data consistency and conflict resolution problem, not an infrastructure problem, and it’s the reason Active-Active is usually reserved for the workloads that genuinely justify its cost and complexity rather than adopted as a default “best” option. Aurora Global Database is AWS’s managed answer for the database layer specifically supporting one primary write region with up to five secondary read regions with sub-second replication lag, or for true multi-writer needs, application-level conflict resolution logic that has to be designed deliberately for your specific data model, because there is no generic solution to “two regions wrote conflicting values to the same row at the same time” that works for every application.

The honest scoping advice here before reaching for Active-Active, verify the actual business requirement justifies it. A large share of workloads that ask for Active-Active actually need Warm Standby’s RTO with slightly better tooling around it, and discovering that during a cost review is a much better time to discover it than during the six-month project to build conflict resolution logic nobody ends up needing.

AWS Elastic Disaster Recovery The Managed Path for Full Server Fleets

For workloads that are harder to decompose into “just the database and the app tier” legacy applications, on-premises servers being protected into AWS, or large EC2 fleets where rebuilding from IaC template isn’t realistic AWS Elastic Disaster Recovery (DRS) provides agent-based, near-continuous block-level replication of entire servers into a low-cost staging area in the target region, launching full recovery instances only when failover is actually triggered.

The mechanic worth understanding precisely, because it’s the part every DRS walkthrough glosses over failover is not the end of the process, it’s the midpoint. After a recovery, your recovered instances are running in the DR region but they are not protected against a subsequent failure until you explicitly start reversed replication back toward the original region, and that reverse replication takes real time and incurs its own cross-region data transfer cost. A team that fails over during an incident and considers the job done has actually left themselves with zero disaster recovery protection for as long as reversed replication hasn’t been started and completed.

The operational discipline this demands: to ensure operational continuity, initialize DRS in advance in both the source and target regions, and conduct regular failover and failback drills not as a one time setup task, but as a standing operational practice, because a DR mechanism that’s only ever tested once during initial setup is a mechanism nobody actually knows how to operate correctly six months later during a real incident.

The Part Every DR Plan Forgets: Restoring Infrastructure, Not Just Data

This deserves its own section because it’s the single most common gap between a DR plan that looks complete on paper and one that actually works during a real incident. Every pattern above assumes that when failover happens, the surrounding infrastructure VPCs, subnets, security groups, IAM roles, KMS keys, secrets either already exists in the DR region or can be created correctly and in the right order. That assumption is frequently wrong in practice.

If your infrastructure is defined in Terraform, the DR region’s infrastructure should be a separate, versioned state file following the state boundary discipline covered in the Terraform modules article earlier in this series not something recreated ad hoc during an actual incident by someone reading old console screenshots. The dependency order matters and needs to be explicit networking before compute, IAM roles before the services that assume them, KMS keys before the encrypted resources that depend on them, secrets before the applications that read them at startup.

The test that actually validates this isn’t “does terraform plan run without errors" it's "can someone who wasn't involved in writing this actually execute a full restore, in order, under time pressure, and get a working environment." That's a meaningfully higher bar, and it's the bar the next section is about.

Testing: The Difference Between a DR Plan and a DR Document

A DR plan that has never been executed is a document, not a plan. This isn’t a moral judgment it’s a practical one, because the gap between “this should work” and “this actually works” is exactly where DR plans fail during real incidents, usually in some small, specific way nobody anticipated a security group rule that only exists in primary, a hardcoded region string in application config, an IAM role trust policy that was never replicated.

The practice that closes this gap is the same game day discipline covered in the chaos engineering article earlier in this series, applied specifically to full regional failover rather than single-service failure injection on a scheduled cadence, actually fail over to the DR region not simulate it, actually do it, for real workloads, on a schedule the team knows about, and measure the real RTO and RPO achieved against what was promised. AWS DRS’s own guidance is explicit that failover and failback drills need to be conducted regularly, not once at initial setup because infrastructure drifts, team knowledge fades, and the only way to know a DR plan still works is to keep proving it does.

The failures that surface during real drills, consistently, are rarely the exciting ones they’re small, specific gaps: a Route 53 health check pointing at the wrong endpoint, a replica that’s been silently lagging past its RPO for weeks because nobody set up the CloudWatch alarm from earlier in this article, an IAM role that exists in Terraform but was never actually applied to the DR region because someone forgot to run terraform apply -target=module.dr_region after the last change. None of these are dramatic failures. All of them are exactly the kind of thing that turns a 15-minute planned RTO into a 4-hour actual outage, discovered at the worst possible time, instead of during a Tuesday afternoon drill.

Choosing the Right Pattern for Each Workload

Most real organizations run a mix of two or three of these across their portfolio, not one pattern applied uniformly and that mix, made deliberately rather than defaulted into, is itself the actual DR strategy, more than any single pattern’s implementation details.

Wrapping Up

Disaster recovery on AWS is not a single architecture to copy it’s a spectrum of four patterns, each a specific, costed trade-off between how much downtime and data loss you can tolerate, and each with mechanics (Route 53 health-check failover, RDS replica promotion, DRS reversed replication) that have to be understood precisely enough to execute correctly under pressure, not just referenced in a runbook nobody has actually run.

The two things that separate a DR plan that works from one that doesn’t are the two things this article spent the most time on restoring infrastructure configuration in the correct dependency order, not just data, and testing the actual failover process regularly rather than trusting a document that’s never been executed. Everything else which pattern, which RTO, which RPO is a decision specific to each workload’s actual business requirements, made deliberately, in a room with the people who own both the risk and the budget.

The organizations that survive a real regional incident well are not the ones with the most sophisticated DR architecture. They’re the ones who tested theirs enough times that the actual incident felt like just another drill.