High availability and disaster recovery are the safety nets that keep a system running when things break — servers crash, power goes out, or a whole data centre burns down. For the SOA-C02 exam, you must understand how AWS lets you spread your application across multiple physical locations so that a single failure cannot take you offline.
Jump to a section
Your neighbourhood community garden, with its raised beds and a single tap at the far end. Every morning, you fill your watering can from that tap and carry it to your tomato plants. If the tap breaks, you are hauling buckets from your kitchen sink three blocks away, and your tomatoes wilt by Tuesday. That single tap is a "single point of failure."
Now imagine a smarter garden. Two taps are installed at opposite ends of the garden, each connected to a separate underground pipe that comes from two different water mains under the street. If one main is dug up by a construction crew, the other tap still flows. That is "Multi-AZ" (Availability Zone) resilience — your plants (your application) stay watered even when one water source fails.
Now take it further. Your garden association also stores a spare set of seeds and a backup watering schedule in a locked shed three towns over. If a tornado flattens your entire neighbourhood (a whole AWS Region failure), you drive to that shed, plant the spare seeds, and start over in the new town. That is "Multi-Region" disaster recovery. The garden is never truly lost; you always have a plan to rebuild elsewhere.
High availability (HA) and disaster recovery (DR) are two related but distinct strategies for making sure an application stays online or comes back online quickly after a failure. Think of HA as the design that prevents downtime in the first place, and DR as the plan you execute when a catastrophe is too big for HA to handle.
AWS data centres are grouped into Availability Zones (AZs). An AZ is one or more physical data centres with independent power, cooling, and networking. A single AWS Region, such as us-east-1 (Northern Virginia), contains multiple AZs — typically three or more. Because each AZ is isolated from the others, a fire or flood in one AZ does not affect the others. This is the foundation of HA.
A common HA pattern is to run your application on two Amazon EC2 (Elastic Compute Cloud) instances — virtual servers — one in AZ-A and one in AZ-B. In front of them, you place an Application Load Balancer (ALB). The ALB automatically sends incoming traffic to the healthy instance. If the instance in AZ-A fails, the ALB routes all traffic to AZ-B. Users experience zero interruption. This is called an active-passive setup (one active, one on standby) or active-active (both handle traffic simultaneously).
Disaster recovery goes beyond a single AZ failure. It prepares for the loss of an entire AWS Region. AWS has over 30 Regions worldwide, each composed of multiple AZs. To survive a regional disaster, you replicate your data and infrastructure to a second Region, perhaps eu-west-1 (Ireland) if your primary is us-east-1. There are several DR strategies, each with different cost and recovery time:
Backup and Restore: You regularly take snapshots of your data (e.g., Amazon RDS database snapshots) and store them in Amazon S3 (Simple Storage Service) in another Region. When disaster strikes, you restore from the snapshot and rebuild the infrastructure. This is cheapest but slowest — recovery can take hours.
Pilot Light: You keep a minimal copy of your infrastructure running in the DR Region — just the core database and a few config files. When disaster hits, you "light the pilot" by launching the full application stack around that database. Recovery takes minutes.
Warm Standby: You run a scaled-down but fully functional version of your application in the DR Region all the time. In a disaster, you scale it up to full capacity. Recovery is faster than pilot light.
Multi-Site Active-Active: You run the full application in both Regions, with traffic split between them. This is the most expensive but offers near-zero downtime and nearly instant recovery.
To make all this work, AWS provides key services. Amazon Route 53 is a DNS (Domain Name System) service that can route users to the nearest healthy Region using routing policies like failover or latency-based routing. AWS CloudFormation lets you define your entire infrastructure as code (a template file), so you can recreate it exactly in a DR Region with a single command. AWS Backup centralises backup policies across services.
The Recovery Point Objective (RPO) is the maximum acceptable age of data you lose. If your RPO is 15 minutes, you can only tolerate losing 15 minutes of data. Recovery Time Objective (RTO) is the maximum acceptable time to restore service. If your RTO is 1 hour, your DR plan must have the app running again within 60 minutes. These two metrics drive every HA/DR decision.
Before AWS, companies had to build their own secondary data centres, duplicate all hardware, and maintain expensive standby infrastructure. This was cost-prohibitive for all but the largest organisations. AWS's pay-as-you-go model makes DR affordable for startups as well. You only pay for what you replicate, and only during a disaster do you pay for running the full DR environment.
Identify Single Points of Failure
Map out every component of the application: compute (EC2), database (RDS), storage (S3), DNS (Route 53), and load balancer. Anything that exists as a single copy is a point of failure. For example, one EC2 instance or one RDS instance without a standby. This step determines what needs redundant copies.
Design Multi-AZ High Availability
Deploy at least two copies of each critical component in different Availability Zones within the same region. Place EC2 instances behind an Application Load Balancer. Configure RDS as Multi-AZ (creates a standby in another AZ). This ensures automatic failover if one AZ fails. The load balancer continuously health-checks each instance and stops sending traffic to unhealthy ones.
Set Recovery Objectives (RPO and RTO)
Define, in minutes or hours, how much data the business can lose (RPO) and how quickly the service must be restored (RTO). These numbers drive every subsequent decision. For example, an RPO of 5 minutes means you need near-real-time replication. An RTO of 1 hour means your automation must be fast.
Choose and Implement a Disaster Recovery Strategy
Select one of the four strategies (Backup & Restore, Pilot Light, Warm Standby, Multi-Site) based on the RPO and RTO from step 3. Implement data replication to a second region using AWS services — for example, S3 Cross-Region Replication for files, RDS cross-Region read replicas for databases, or AWS Backup for snapshots. Document the runbook for failover procedures.
Automate Failover and Testing
Use Route 53 failover routing policy to automatically switch DNS traffic to the DR region when the primary region health check fails. Write a CloudFormation template to launch the full DR environment. Schedule quarterly DR tests: actually fail over, measure RTO and RPO, fix gaps, and update the template. Regular testing is the only way to ensure the plan works under pressure.
A mid-sized e-commerce company, ShopGlobal, sells handmade goods online. They run on AWS in the us-east-1 Region (N. Virginia). Their application uses a single EC2 instance for the web server and an Amazon RDS MySQL database for inventory and orders. One day, a major construction crew accidentally severs a fibre line feeding one of the AZs in us-east-1. The EC2 instance (in that AZ) goes offline. The site goes down for 45 minutes before an engineer manually launches a new instance. ShopGlobal loses $12,000 in sales and damages their reputation.
After this, the CTO demands a redesign. Here is what the operations team does, step by step:
Step 1: Assess existing architecture. They identify single points of failure: one EC2 instance, one database instance, no load balancer.
Step 2: Deploy an Application Load Balancer. They create an ALB and configure a target group with the existing EC2 instance. They then launch a second EC2 instance in a different AZ (us-east-1b) and register it with the same target group. The ALB performs health checks every 30 seconds (a ping to the application's /health endpoint).
Step 3: Migrate the database to Multi-AZ RDS. They take a final snapshot of the existing RDS instance, then restore it as a Multi-AZ deployment. This creates a synchronously replicated standby in a different AZ. If the primary database crashes, RDS automatically fails over to the standby — the application only sees a brief DNS change.
Step 4: Set up cross-Region backup. They create an AWS Backup plan that takes daily snapshots of the RDS database and stores them in an S3 bucket in us-west-2 (Oregon). They also back up the ALB configuration and EC2 AMIs (Amazon Machine Images) to us-west-2.
Step 5: Build a CloudFormation template. They write a YAML template that defines the entire stack: VPC, subnets, ALB, EC2 instances, security groups, RDS instance. This template is stored in an S3 bucket in a third Region (eu-west-1).
Step 6: Test the disaster recovery plan quarterly. Every three months, the ops team runs a "game day" where they simulate a us-east-1 outage. They deploy the CloudFormation template in us-west-2, restore the latest RDS snapshot, update Route 53 DNS records to point to the new ALB, and measure RTO and RPO. The first test takes 2 hours; after optimising, they get it down to 30 minutes.
Step 7: Implement proactive monitoring. They set up Amazon CloudWatch alarms that alert engineers if any single AZ has zero healthy hosts for more than five minutes. They also use AWS Trusted Advisor to check for single points of failure.
The real-world result: six months later, a massive storm causes a power outage across multiple AZs in us-east-1. ShopGlobal's Multi-AZ configuration keeps the database alive, and the ALB routes traffic away from affected AZs. The site stays up. Later, when a software bug corrupts the database, they restore from the last snapshot in us-west-2 within 45 minutes. The investment in DR pays for itself in avoided losses.
The SOA-C02 exam tests HA and DR heavily in domain 2.1. Expect around 8-12 questions on these topics. Many questions present a scenario and ask you to identify the cheapest or fastest solution that meets given RPO and RTO requirements.
Specific concepts the exam loves:
Multi-AZ vs. Multi-Region: Understand that Multi-AZ protects against an AZ failure, while Multi-Region protects against a region failure. Questions will test if you know when to use each.
RDS Multi-AZ: This is synchronous replication — data is written to both the primary and standby before the write is acknowledged. It is for HA, not for scaling reads.
RDS Read Replicas: These are asynchronous and can be promoted to a standalone DB in a disaster, but they are primarily for read scaling, not instant failover.
Route 53 routing policies: Know failover routing (for active-passive DR), latency-based routing (for multi-Region active-active), geolocation routing (compliance), and weighted routing (canary deployments).
Disaster recovery strategies: You must memorise the four strategies (Backup & Restore, Pilot Light, Warm Standby, Multi-Site) and their typical RTO/RPO ranges.
The difference between RTO and RPO: Traps often swap the definitions. RTO is time to restore, RPO is data loss.
Common traps:
Choosing a Multi-AZ read replica when the question needs a Multi-AZ standby (the read replica does not provide automatic failover).
Suggesting an EC2 instance in a single AZ without a load balancer (that is a single point of failure).
Forgetting that cross-Region replication has higher latency and higher cost than same-Region replication.
Selecting "pilot light" when the question requires near-zero RTO (should be warm standby or multi-site).
Exam tip: When you see a scenario with an RTO of 5 minutes and an RPO of 1 minute, you must choose Multi-Site active-active. When the question says "budget is the primary concern" and RTO is 4 hours, Backup & Restore is usually correct.
Memorise this: the default answer for many HA questions is "deploy in two or more Availability Zones behind a load balancer." That is the formula the exam expects for high availability at the compute layer.
High availability uses multiple Availability Zones within a single region to survive an AZ failure without downtime.
Disaster recovery uses a second AWS Region to survive a full region failure, with strategies ranging from Backup & Restore (cheap, slow) to Multi-Site (expensive, fast).
Recovery Point Objective (RPO) measures the maximum tolerable data loss, while Recovery Time Objective (RTO) measures the maximum tolerable downtime.
RDS Multi-AZ provides automatic failover with synchronous replication; it is for high availability, not for scaling read traffic.
A load balancer combined with EC2 instances in multiple AZs is the standard pattern for compute-layer high availability.
CloudFormation templates and infrastructure as code let you rebuild your entire environment in a disaster recovery region with a single command.
Route 53 DNS failover routing policy automatically directs users to a healthy region when the primary region becomes unhealthy.
The correct disaster recovery strategy for a given scenario depends on balancing cost, RTO, and RPO — the exam tests this trade-off directly.
These come up on the exam all the time. Here's how to tell them apart.
Multi-AZ
Operates within a single AWS Region across multiple Availability Zones.
Synchronous replication (e.g. RDS Multi-AZ) provides near-zero data loss (RPO seconds).
Automatic failover is handled by AWS services (ALB health checks, RDS DNS flip).
Multi-Region
Spans two or more geographically separate AWS Regions.
Asynchronous replication (e.g. S3 CRR, RDS cross-Region read replicas) introduces replication lag (RPO minutes to hours).
Failover requires manual or automated DNS changes (e.g. Route 53 failover policy).
Recovery Point Objective (RPO)
Measures the maximum acceptable age of data that can be lost.
Expressed in time (seconds, minutes, hours) — lower is better.
Drives decisions on replication frequency and sync vs. async.
Recovery Time Objective (RTO)
Measures the maximum acceptable time to restore service.
Expressed in time (seconds, minutes, hours) — lower is better.
Drives decisions on standby infrastructure readiness and automation.
RDS Multi-AZ (Standby)
Provides automatic failover for high availability.
Synchronous replication — writes are committed on both primary and standby before acknowledgement.
Can only be promoted during a failover (not for read scaling).
RDS Read Replica
Provides read scaling by offloading SELECT queries.
Asynchronous replication — slight lag (seconds to minutes) between primary and replica.
Can be promoted to a standalone database manually (for DR or blue/green deployments).
Pilot Light DR
Runs only a minimal core (database, config) in the DR region.
Longer RTO (10-30 minutes) because you must launch compute resources on failover.
Lower cost because compute instances are not running continuously.
Warm Standby DR
Runs a scaled-down but fully functional copy of the application in the DR region.
Shorter RTO (1-10 minutes) because only scaling up is needed.
Higher cost because some compute and database resources run 24/7.
Mistake
Multi-AZ RDS read replicas provide automatic failover, so I can use them instead of Multi-AZ standby.
Correct
Multi-AZ standby is a synchronous replica that provides automatic failover; a read replica is asynchronous and must be manually promoted, causing downtime.
Both involve a second database, so beginners conflate them. But read replicas are for read traffic, not for HA failover.
Mistake
If I run my EC2 instance in two Availability Zones, I have achieved high availability.
Correct
Two EC2 instances across AZs only gives HA if a load balancer or DNS failover automatically routes traffic away from the failed instance. Without that, you still have a single point of failure at the routing layer.
People think 'spreading' alone is enough, but without automation, traffic still goes to the dead instance.
Mistake
Disaster recovery is only needed for natural disasters like earthquakes or floods.
Correct
A disaster can be a human error (accidentally deleting a database), a software bug, a ransomware attack, or a configuration mistake that corrupts data. DR covers any event that requires restoring service from another region.
The word 'disaster' makes learners think of extreme events, but in cloud, the most common disasters are operator errors.
Mistake
A Recovery Point Objective (RPO) of zero means the system is always available with no downtime.
Correct
RPO of zero means zero data loss — every write is synchronously replicated before the write is confirmed. It does not guarantee zero downtime; the application might still be unavailable during failover.
The word 'zero' suggests perfection, but RPO and RTO are separate measures of data loss and downtime, often confused.
Mistake
Multi-Region active-active is the best choice for every application because it gives the highest availability.
Correct
Active-active across regions is the most expensive and complex. Many applications can tolerate a few minutes of downtime (RTO of 10-30 minutes), making Warm Standby or Pilot Light more cost-effective.
Beginners assume 'more is better', but exam questions test cost-awareness. The 'best' answer depends on budget and RTO/RPO.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Multi-AZ means running resources across multiple Availability Zones inside one region to survive an AZ failure. Multi-Region means using two or more geographic regions to survive a full region failure, which is part of disaster recovery.
Yes. Multi-AZ RDS creates a synchronous standby in a different AZ. If the primary fails, RDS automatically flips the DNS to the standby within about 60 seconds. Your application just reconnects.
Backup and Restore is the cheapest because you only store snapshots in the secondary region and do not run any live infrastructure there. But it has the highest RTO because you must rebuild everything from the backup.
Choose Pilot Light if you can tolerate an RTO of 10-30 minutes, because you only keep a small core (database, config) running. Choose Warm Standby if you need an RTO under 10 minutes, because you run a scaled-down but fully functional copy of the app that can be scaled up quickly.
A failover policy lets you designate a primary and a secondary resource (like two load balancers in different regions). Route 53 health checks monitor the primary; if it fails, DNS automatically returns the secondary's IP address, directing users to the DR region.
Multi-AZ protects only within one region. A disaster that takes out the whole region (earthquake, power grid failure, human error deleting all the data) requires a different plan. Testing proves your cross-region failover works before a real emergency.
You've just covered High Availability and Disaster Recovery Strategies — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?