Backup and Disaster Recovery

When redundancy inside a region was not enough

The last 2 lessons covered redundancy inside a single AWS Region: spreading instances and databases across Availability Zones so that 1 data center's failure doesn't take the whole system down. That protects against a hardware failure or a power outage. It does nothing if a bad deployment corrupts a database table, or if an entire geographic region goes dark, the exact gap the regions-and-Availability-Zones lesson flagged earlier in this course. This lesson is about the plan for exactly that: when the failure is bigger than AZ-level redundancy was ever built to absorb.

Two questions before any recovery plan: how much data, how long down

Every disaster recovery plan starts by answering 2 separate questions, and mixing them up is the most common mistake teams make.

Recovery Point Objective (RPO) bounds acceptable data loss. It answers "how much data can we afford to lose," measured as the maximum acceptable time between now and the last point you could recover from. An RPO of 15 minutes means your backups or replication have to run at least that often, or you risk losing more than the business can tolerate.

Recovery Time Objective (RTO) bounds acceptable downtime. It answers "how long can we be down," measured as the maximum acceptable delay between an outage starting and service being restored. An RTO of 1 hour means the entire recovery process, detecting the failure, standing up infrastructure, restoring data, has to finish inside that hour.

An e-commerce order database with a 15-minute RPO and a 1-hour RTO is promising 2 very different things: at most 15 minutes of lost orders, and at most 1 hour before the store is taking orders again. Meeting both takes deliberate engineering, and meeting them more tightly always costs more.

Backups: the foundation under every strategy

No disaster recovery strategy works without reliable backups underneath it. AWS Backup centralizes that work across services, EC2, RDS, DynamoDB, EFS, and more, through backup plans: policies that define schedules and retention. A typical plan might pair a daily rule, backing up every night and keeping each backup for 1 month, with a monthly rule, backing up once a month and keeping that copy for a full year. Resources get assigned to a plan simply by tagging them, and backups can copy automatically to a different AWS Region on the same schedule, which is what turns a routine backup into the raw material a disaster recovery strategy can actually use.

The 4 disaster recovery strategies, cheapest to most expensive

With backups as the foundation, the question becomes how much infrastructure you keep running in a secondary location, and readiness costs money whether or not disaster ever strikes.

Backup and restore rebuilds everything, data and infrastructure, from scratch after a disaster is declared, usually through Infrastructure as Code, which is why it takes the longest but costs the least day to day. Pilot light keeps the data layer continuously replicated but leaves the rest of the stack dark, needing to be switched on and scaled before it can serve traffic. Warm standby goes further, keeping a smaller version of the entire application already running, so recovery means scaling an existing deployment up rather than deploying one for the first time. Multi-site active/active removes the switching step entirely: more than 1 Region is already handling production traffic, so a Region-level failure just means rerouting requests away from the Region that can't serve them.

Worked example: matching the strategy to the requirement

An internal reporting dashboard can tolerate several hours of downtime and losing up to a day of data without hurting the business in any measurable way; backup and restore is not just acceptable here, it's the correct engineering choice, since paying for a warmer strategy would be spending money the requirement never asked for. A payment-authorization service is the opposite case: a minute of downtime or any lost transaction is unacceptable, which justifies the cost and complexity of multi-site active/active. Neither team is wrong. Each has matched the strategy to the RTO and RPO the business actually needs, which is the entire point of having 4 strategies instead of reaching for the most expensive one by default.

Boundary: backup and restore versus pilot light

These 2 are the pair most often confused, because both keep your data safe in a second Region and both look, from the outside, like "we have backups somewhere else." The difference is what happens to compute. Backup and restore has no infrastructure standing by at all; everything gets provisioned from Infrastructure as Code only after a disaster is declared. Pilot light keeps a minimal core, often just the data tier, continuously live and replicating, while the rest of the stack (application servers, for instance) stays completely dark until failover triggers it. That single difference, whether anything besides data is already there waiting, is what separates the cheapest strategy from the next one up.

Active-active reappears, at a larger radius

Multi-site active/active is not a new idea introduced for disaster recovery specifically. It's the active-active redundancy pattern from the previous lesson, where every replica serves traffic simultaneously, stretched from the scale of Availability Zones inside 1 Region to the scale of entire Regions. The mechanism is the same; only the geography and the stakes are bigger.

Misconception: backups alone are not a disaster recovery plan

It's tempting to treat "we have automated nightly backups in a second Region" as the same thing as "we have a disaster recovery plan." It isn't. A backup that has never been restored from is a hypothesis about how recovery would go, not evidence that it will. A real plan has a documented, rehearsed restore procedure and a known RTO that leadership has actually signed off on as acceptable. Backups are necessary for every one of the 4 strategies above; they are sufficient for none of them on their own.

Exam cues: matching a scenario to a strategy

Where this leaves you

Choosing a disaster recovery strategy is choosing a point on a dial between steady-state cost and recovery speed, not searching for a single best answer; the right point is wherever the business's actual RTO and RPO land, no more expensive than that. Backups make every strategy possible, but only a tested restore procedure turns them into an actual plan. The next lesson closes out this topic by asking a different question: how do you actually find out a failure happened at all, and what does a cloud provider's SLA really promise when it does?