Database high availability options on AWS

AWS’s managed database services sit on a spectrum. At one end the service handles elasticity and availability for you and gives you little control over the engine or its topology; at the other you run the engine yourself on EC2 and control everything, including the patching.

DynamoDB  →  Aurora  →  RDS  →  Database on EC2
◄──────── more managed          more control ────────►

High operational efficiency, less control. AWS manages availability and scaling. Engine internals and architecture are largely fixed. Operations are simple.
Low operational efficiency, maximum control. You choose everything, and you patch the OS, tune the engine, and build the failover yourself.

Pick the most managed option that meets the requirement, and move left along the spectrum only when a specific requirement forces it.

DynamoDB

The most operationally efficient option, and NoSQL only.

How it achieves availability. Data is distributed across partitions automatically, and each partition is replicated synchronously across three Availability Zones within the Region. There is no failover to configure and no standby to size — high availability is the default state of a table, not a deployment option.

Beyond one Region. Global tables replicate a table to additional Regions with multi-active read and write, which is the mechanism behind the fastest recovery objectives in a multi-Region design.

In practice. Choose the capacity mode (on-demand or provisioned with auto scaling), enable point-in-time recovery, watch for hot partitions, and design the key schema so that traffic spreads.

Amazon Aurora

The strongest high-availability story for relational data, with low operational overhead.

How it achieves availability. The storage layer is separated from compute and replicates six copies of the data across three Availability Zones. Read replicas in other Availability Zones can be promoted automatically when the writer fails, and because the storage is shared there is no data copy to wait for during promotion.

Beyond one Region. Aurora Global Database extends a cluster to one primary Region and up to five secondary Regions, replicating at the storage level with low latency. A secondary Region can be promoted when the primary is impaired.

In practice. Deploy the writer and at least one reader in different Availability Zones, set failover priorities on the readers, and enable a global database only when the recovery objective needs a second Region.

Amazon RDS

Good availability with more of the topology exposed to you, and more work for multi-Region.

Multi-AZ deployment. The primary replicates synchronously to a standby in another Availability Zone, and RDS fails over to it automatically. In the classic Multi-AZ instance deployment the standby serves no traffic — it exists for failover, not for read scaling. (The Multi-AZ DB cluster deployment adds two readable standbys, at the cost of a narrower set of supported engines and versions.)

Cross-Region read replicas. An asynchronous replica in another Region gives a warm standby for disaster recovery. Promotion is a deliberate action, not an automatic one, and the RPO is whatever the replication lag was at the moment of failure.

Snapshots. Automated and manual snapshots go to S3 and can be copied across Regions. This is the cheapest option and the slowest: RTO is however long a restore takes, and RPO is the gap since the last snapshot.

In practice. Choose deliberately between these three — they are not alternatives to each other so much as different points on the RTO/RPO curve — and monitor replica lag if you are quoting an RPO based on it.

Amazon Redshift

Multi-AZ deployment is the current answer for Redshift high availability and has been generally available since November 2023. It runs compute in two Availability Zones behind a single endpoint, serves queries from both, and continues on the surviving Availability Zone if one fails. AWS states an RPO of zero for this configuration and raises the Redshift SLA from 99.9% to 99.99%. It is available on RA3 and RG node types.

Older material — including AWS’s own documentation and much of the training market before 2024 — describes Redshift Multi-AZ as a preview and recommends a multi-node cluster in a single Availability Zone as the practical HA answer instead. That advice is now out of date; a multi-node cluster protects against node failure, not against Availability Zone failure.

Storage. RA3 nodes use Redshift Managed Storage, which persists data in S3 and lets compute be provisioned in either Availability Zone against the same data. Single-node clusters have no in-Region redundancy and are restored from an S3 snapshot after a failure.

In practice. Choose a node type that supports Multi-AZ if availability matters, enable Multi-AZ, keep automated snapshots with cross-Region copy for the disaster-recovery case, and monitor cluster health.

Choosing

By data model. NoSQL access patterns that you can design a key schema around: DynamoDB. Relational with an availability requirement: Aurora. Relational with an engine, version or feature Aurora does not support: RDS. Analytical warehouse: Redshift.

By availability requirement. Decide first whether the requirement is Regional or global, what the RTO and RPO are, and whether failover must be automatic. Those three answers usually eliminate most of the options before cost is considered.

By operations. Weigh the management overhead against the control you actually need, not the control you might one day want. Self-managing an engine on EC2 is a real cost, paid every month, in exchange for flexibility most workloads never exercise.