Database High Availability and Disaster Recovery Design

Let us start with the basics. A database is just a structured place where you store data – customer orders, user accounts, product inventory. If that database stops working, your application stops working. High availability (HA) and disaster recovery (DR) are two different strategies to prevent that from happening.

High availability means the database stays up and responds to queries even when individual components fail. Think of it as building redundancy inside one location (an AWS Availability Zone or multiple zones). The system has no single point of failure – if one server crashes, another takes over instantly. The goal is zero downtime and zero data loss.

Disaster recovery is different. DR is what you do when a whole AWS Region (like us-east-1) goes offline because of a natural disaster, a power grid failure, or a human error. DR means you have a standby copy of your database in another AWS Region, and you have a plan to switch traffic to that copy if the main region fails. The goal here is to minimise data loss (measured by Recovery Point Objective, RPO) and downtime (measured by Recovery Time Objective, RTO).

AWS services that help with HA include Amazon RDS Multi-AZ (which creates a standby replica in a different Availability Zone), Amazon Aurora (which replicates data across three Availability Zones by default), and Amazon DynamoDB (which stores data across multiple servers and racks automatically). For DR, you use cross-Region read replicas, automated backups, or snapshot copy to a secondary Region.

The core principle is that you must decide how much data loss you can tolerate (RPO) and how fast you need to recover (RTO). For example, a banking app might require RPO of zero seconds and RTO of 1 minute – meaning you lose zero transactions and are back up in 60 seconds. A blog might tolerate RPO of 24 hours and RTO of 4 hours – meaning losing a day of comments is acceptable and taking four hours to restore is fine.

The most common mistake beginners make is thinking HA and DR are the same thing. They are not. HA keeps you running during small failures (one server, one rack, one zone). DR saves you when a whole region goes down. You need both.

AWS offers specific services for each goal:

You must also design the database for fault tolerance at the application layer. For instance, if your application connects to a single database endpoint and that endpoint fails, the app breaks. So you use a DNS endpoint like an AWS RDS endpoint that automatically points to whichever instance is healthy. Or you use an Elastic Load Balancer for read replicas.

Real-world example: an e-commerce site. They use Amazon RDS Multi-AZ for the order database. When the primary in us-east-1a fails, the standby in us-east-1b takes over within two minutes. No orders are lost because synchronous replication kept the standby identical. Separately, they also copy nightly backups to us-west-2. If a hurricane hits us-east-1, they can restore from the backup in us-west-2 – but they will lose up to 24 hours of orders (RPO = 24 hours) and it will take 6 hours to restore (RTO = 6 hours). That is the difference between HA and DR.

In DBS-C01, you will be asked to choose the right combination of services based on given RPO and RTO numbers. You will also see questions about synchronous vs asynchronous replication, Multi-AZ vs read replicas, and when to use Aurora vs RDS vs DynamoDB.

An IT professional tasked with designing a database for a SaaS company that sells project management software. The company has 50,000 active users and processes thousands of transactions per hour. The CEO demands that the service must never go down for more than 5 minutes (RTO = 5 minutes) and can lose at most 1 second of data (RPO = 1 second). They use Amazon Aurora because it provides synchronous replication across three Availability Zones by default.

Step one: The professional evaluates the current setup. The database is a single Aurora cluster in us-east-1. That is a single region. If the entire region fails, the app dies. So they must add cross-Region DR.

Step two: They create an Aurora Global Database. This sets up a secondary cluster in us-west-2. Data replicates asynchronously from the primary to the secondary – typical lag is under 1 second. This meets the RPO of 1 second because if the primary fails, the secondary will have all data up to about 1 second before the failure.

Step three: They configure an Aurora Auto Scaling policy for read replicas. This ensures that during a spike in traffic, read queries are handled by replicas, keeping the primary from being overloaded. This is not for HA but for performance resilience.

Step four: They write a disaster recovery runbook. The runbook details exactly what happens when a region failure is detected. The steps include:

Step five: They test the DR procedure quarterly. During one test, they discover that the application had hard-coded the old endpoint in configuration files. They fixed that by switching to an Amazon Route 53 endpoint with health checks. Now the app automatically uses the healthy database.

Step six: They also set up automated backups with a retention period of 35 days. These backups are cross-Region copied to us-west-2. That gives them an additional safety net: if both regions somehow become corrupt, they can restore from a snapshot from 6 hours ago.

What the IT professional does daily:

This real-world scenario shows that designing for HA and DR is not a one-time setup. It is an ongoing process of monitoring, testing, and iterating.