Amazon Aurora & Read Replicas

Aurora separates the compute layer (the database instances that process SQL) from a shared storage layer that all instances in the cluster read from and write to. The storage volume is a distributed system spread across three Availability Zones (AZs), with six copies of your data (two per AZ). A write is durable once four of six copies acknowledge it, and reads can be served as long as three of six copies are available, which gives Aurora self-healing storage that tolerates the loss of an entire AZ plus one additional copy. Storage grows automatically in 10 GB increments up to 256 TiB (128 TiB on older engine versions), so you never pre-provision disk. Because compute and storage are decoupled, adding a read replica does not copy data; the new instance simply attaches to the existing volume.

An Aurora cluster has one writer instance (primary) that handles reads and writes, plus up to 15 Aurora Replicas that serve read-only traffic. Because replicas share the same storage volume as the writer, replication lag is typically in the low milliseconds, far lower than the asynchronous binary-log replication used by standard RDS read replicas. Aurora provides two managed connection endpoints: the Cluster (writer) Endpoint always points to the current primary, and the Reader Endpoint load-balances connections across all available replicas. If the writer fails, Aurora automatically promotes a replica, usually within about 30 seconds, and you can assign each replica a failover priority tier (tier 0 is promoted first). This combination scales reads horizontally and provides high availability from the same set of instances.

Aurora Serverless v2 is an on-demand capacity mode where Aurora adjusts compute automatically based on load. Capacity is measured in Aurora Capacity Units (ACUs), where each ACU is roughly 2 GB of memory with associated CPU and networking. You set a minimum and maximum ACU range, and Aurora scales in fine-grained increments (as small as 0.5 ACU) in response to demand, often within a fraction of a second. Serverless v2 supports the full Aurora feature set, including read replicas, Multi-AZ, and Global Database, which makes it suitable for production. It fits variable, spiky, or unpredictable workloads, and for development or test fleets where many databases sit idle most of the time. You pay for the ACU-seconds consumed plus storage and I/O.

An Aurora Global Database spans multiple AWS Regions. It has one primary Region that handles writes and up to 10 secondary Regions that are read-only. Replication uses the storage layer and a dedicated infrastructure, so data propagates with typical lag under one second, and it does not consume database compute for replication. Secondary Regions serve low-latency reads to users near them, and in a Regional outage you can promote a secondary to be the new primary, typically within about a minute (switchover, previously called managed planned failover, for routine operations and unplanned failover for disaster recovery). This makes Global Database the standard answer for cross-Region disaster recovery with a low Recovery Point Objective (RPO) and low Recovery Time Objective (RTO), and for serving global read traffic.

Aurora cloning creates a new cluster that shares the source cluster's storage using a copy-on-write protocol. At first the clone references the same data pages as the source, so cloning is fast and consumes almost no additional storage. As either the source or the clone changes data, only the modified pages are copied, and you pay only for that delta. Clones are ideal for spinning up a production-like environment for testing schema changes, running analytics without impacting production, or experimenting safely. Cloning works within an account and across accounts (via AWS Resource Access Manager), and it differs from a snapshot restore, which copies the full dataset and takes longer.