When you run an application in the cloud, sooner or later something will break. That is not pessimism, it is the law of large numbers: there are many servers, and one of them is bound to fail. In AWS, individual virtual machines fail (they are called instances), sometimes whole datacenters fail (availability zones), and very rarely entire regions go down. Resilience is not about making sure nothing ever breaks, it is about knowing in advance what will happen when something breaks and making sure the user barely notices.

The core idea is simple: the decision about "what to do when it fails" is made ahead of time, on paper and in the architecture, not in a panic at three in the morning during an incident. Disaster recovery (DR) is your plan for when ordinary protection was not enough and you have to restore the system. In this article we will walk through the basic concepts step by step: where to keep copies, how to measure recovery requirements, and what strategies exist.

Availability zones and regions

First, a bit about AWS geography, because you cannot go further without it.

  • Region — a large geographic area, for example Frankfurt or Northern Virginia. Inside a region, your data never leaves its boundaries.
  • Availability Zone (AZ) — a separate physical datacenter (or a cluster of nearby datacenters) within a region. Each region usually has three or more of them. Zones are connected by fast links but are physically separated: a fire or power failure in one zone does not affect the others.

An analogy: a region is a city, and availability zones are different buildings in that city. If the power goes out in one building, work continues in the one next door.

Multi-AZ vs multi-region

There are two levels of protection, and they cost very differently.

Multi-AZ means your resources are duplicated across several availability zones within a single region. It protects against the failure of an entire zone (that same "building"). It is cheap, the latency between zones is tiny, and in most AWS services this protection is built in almost automatically. For example, an Auto Scaling Group spreads servers across different zones, and the RDS database has a Multi-AZ mode that keeps a hot copy in another zone. For more on this basic protection, see the article on scaling and availability. Multi-AZ is done in almost every case — it is a reasonable minimum.

Multi-region is a full copy of the system in another region (another "city"). It protects against the failure of an entire region. This happens very rarely, but when it does, it is a catastrophe. The price for this protection is high: data has to be replicated across hundreds and thousands of kilometers, you have to keep it consistent, and you have to be able to switch traffic between regions. This is done only for truly critical systems where region unavailability is unacceptable — for example, in finance.

A simple rule: multi-AZ for almost everyone, multi-region only when availability requirements genuinely justify it, because cost and complexity rise sharply.

One more important nuance: multi-AZ and multi-region solve different problems and are not interchangeable. Multi-AZ saves you from a hardware failure. Multi-region additionally saves you from a regional catastrophe. But neither one saves you from a logical error — if you accidentally delete a table or ship buggy code, the copy in another zone or region will faithfully repeat both the deletion and the bug. Only backups protect you from situations like that, which we cover below.

RPO and RTO

Before choosing a recovery strategy, you need to answer two questions. They are expressed as two metrics, and these are exactly what people will ask about first when DR comes up.

  • RPO (Recovery Point Objective) — how much data you are willing to lose, measured in time. RPO = 5 minutes means: "if a disaster happens, we accept losing the last 5 minutes of data, no more." This metric determines how often to run backups and replication. Want a smaller RPO — copy data more frequently.
  • RTO (Recovery Time Objective) — how quickly the system must be working again. RTO = 1 hour means: "one hour after the disaster, the service is available again." This metric determines which recovery strategy to choose.

An analogy for RPO and RTO: imagine you are writing a document. RPO is how often you press "Save" (how much work you lose in a crash). RTO is how quickly you can reopen the computer and get back to work after it freezes.

The smaller both numbers, the more expensive the solution. An important point: RPO and RTO are set by the business, not the engineer. The business decides what an hour of downtime and lost data costs, and the engineer then picks an architecture that fits those numbers.

A small example. An online store says: "we cannot lose orders at all, but the store can be down for half an hour without a catastrophe." That means RPO close to zero (we duplicate data continuously) and RTO around thirty minutes (recovery does not have to be instant). Another case — an internal reporting service: "losing a day's data is no big deal, but everything must work by morning." Here RPO is a day and RTO is a few hours — and the solution will be many times cheaper. The same technologies, but different numbers produce a completely different architecture and cost.

The four disaster recovery strategies

AWS defines four main DR strategies. They are ordered by increasing cost: the higher up the list, the cheaper and the slower the recovery; the lower down, the more expensive and the faster.

  1. Backup & restore — you only keep backups. When a disaster strikes, you rebuild the infrastructure from scratch and load data from the backup. The cheapest option, but RTO and RPO are large (hours). Suitable for systems that can afford to wait.

  2. Pilot light — only the very core runs at all times, usually a database replica that continuously receives fresh data. Everything else (application servers, load balancers) is off and only spun up during a disaster. The name refers to the small flame in a gas heater that instantly ignites the main flame. RTO is noticeably lower, the cost is moderate.

  3. Warm standby — a scaled-down but fully live copy of the entire system runs in a standby region. It actually serves something (or is simply ready), and during a disaster it scales up to full size and takes all the traffic. RTO is small, but you pay continuously for the running copy.

  4. Multi-site active-active — full copies of the system run simultaneously in several regions, and both serve users. If one region goes down, traffic simply flows to the other, almost without a pause. RTO is close to zero, but this is the most expensive and complex option: you need to synchronize data between regions in both directions.

To make it more vivid, imagine a backup car in case your main one breaks down. Backup & restore is spare parts in the garage: cheap, but assembling the car takes a long time. Pilot light is a car without wheels, and you buy the wheels when it breaks down. Warm standby is a small economy car, engine running, sitting in the garage, that you can quickly switch to. Active-active is two identical cars driving side by side, and if one stalls you just keep going in the other.

Choosing a strategy is a trade-off between requirements (RPO/RTO) and budget. A common and costly mistake is building active-active where pilot light would have comfortably covered the task.

Backups and testing them

A backup that has never been restored is not a backup, it is a hope. The most common DR failure sounds like this: "we thought we had backups, but we could not restore" — the file was corrupted, permissions were missing, the script was out of date, or the process took ten times longer than expected.

That is why good practice has two parts. The first is regular automatic backups: at a frequency that fits within your RPO, and with the retention period you need. AWS Backup can configure such policies centrally. Here is what running a one-off backup from the command line (AWS CLI) looks like:

aws backup start-backup-job \
  --backup-vault-name production-vault \
  --resource-arn arn:aws:rds:eu-central-1:111122223333:db:orders-db \
  --iam-role-arn arn:aws:iam::111122223333:role/AWSBackupDefaultServiceRole

The second, equally important part is recovery drills. Periodically you need to actually stand up the system from a backup in an isolated environment and check two things: that the data is intact and that you meet your RTO. Only a completed "drill" turns a backup from a line in a report into real insurance.

Where this applies

Resilience and DR are not some separate exotic topic — they are part of the definition of a "production-ready" service, on par with scaling and observability. When an engineer is asked "what happens if a zone or region goes down, and how do we recover," the honest answer rests on exactly these concepts: multi-AZ as the baseline, multi-region when needed, a DR strategy for the given RPO/RTO, and tested backups. Reliability is one of the pillars of the Well-Architected design framework, so understanding DR is useful in any work with the cloud.

Typical beginner mistakes:

  • Assuming AWS "will just save everything anyway." The cloud provides tools, but you configure the backup policy and DR strategy. By default, nobody duplicates your data against disaster for you.
  • Confusing high availability with disaster recovery. Multi-AZ keeps the service alive through small failures, but it is not a substitute for backups: if someone deletes data by mistake, the replica in another zone will honestly repeat that deletion.
  • Building the most expensive option "just in case." Active-active without a real requirement for zero RTO is burned budget. First the RPO/RTO from the business, then the strategy. The money side is worth studying separately — see cost optimization.
  • Never testing the backup. The most frustrating mistake: the plan exists, the copies exist, and at the moment of disaster everything falls apart.

What to learn next: get a feel for how application availability in the cloud works in general — scaling and availability and the basic AWS fundamentals. DR is closely tied to deployment automation: it is convenient to describe all the recovery infrastructure as code so you can stand it up with a single command — take a look at the infrastructure as code fundamentals and the tools Terraform, CloudFormation, CDK. It also helps to understand the storage for the backups themselves — that is covered separately in object storage. And if you deploy to Kubernetes, see how recovery and load failover are handled there — in the Kubernetes: operations section.