When AWS launched RDS, they took existing database engines (MySQL, PostgreSQL, Oracle) and ran them on managed EC2 infrastructure. That solved ops burden — no more patching, backups are handled — but the database architecture itself was unchanged. It was still designed for single-server, spinning-disk-era assumptions.

Amazon Aurora is a cloud-native relational database built from scratch at AWS, designed to resolve the architectural limitations of traditional databases. It is fully MySQL and PostgreSQL compatible — your SQL works, your drivers work, your ORMs work. But underneath, everything is different.

Most people think Aurora is just “RDS but faster”. That is wrong and will cost you exam marks. The difference is architectural:

Every Aurora deployment is called a DB cluster. A cluster has two completely independent layers: the compute layer (DB instances that run the MySQL or PostgreSQL engine) and the storage layer (the shared distributed volume that all compute instances read and write). These two layers scale independently of each other.

The Aurora cluster volume is divided into 10 GB segments called protection groups. Each protection group is replicated six times across three AZs. This granularity means that if a disk fails, only the corresponding segments need to be repaired — not the entire database. Aurora performs this repair continuously in the background, peer-to-peer between storage nodes, without involving the compute layer at all.

Aurora uses a quorum-based write model. When the writer commits a transaction, it does not write data pages to storage — it writes only redo log records to the 6 storage nodes. The write is acknowledged when 4 of 6 nodes confirm receipt. Storage nodes reconstruct data pages from log records locally. This is why Aurora writes are so fast — less data moves over the network.

Aurora exposes several DNS endpoints. Knowing which to use for which workload is critical for exam questions:

With RDS, you opt into high availability by enabling Multi-AZ, which provisions a separate standby instance. With Aurora, HA is the default state. The 6-copy storage model exists for every Aurora cluster regardless of whether you add readers or not. There is no “single-AZ Aurora” at the storage level.

When the writer instance fails, Aurora promotes one of the existing reader instances to become the new writer. Because storage is shared, the promoted reader already has the complete dataset — it just switches its mode. This is why Aurora failover is so much faster than RDS.

Aurora supports up to 15 read replicas per cluster — three times more than RDS. Because all replicas share the same underlying cluster volume, adding a replica means provisioning new compute only. No data is copied. No extra storage cost per replica. The reader is live and serving traffic within minutes.

The Aurora reader endpoint is a single DNS address that automatically distributes incoming connections across all available reader instances using connection-level load balancing. You point your read traffic at one endpoint and Aurora handles the distribution — no application-side logic needed.

Aurora Aurora Auto Scaling automatically adds or removes reader instances based on a CloudWatch metric — typically CPU utilization or connections per instance. You define minimum and maximum replica counts and a target metric value. Aurora scales replicas up during traffic spikes and removes them during quiet periods.

Aurora Parallel Query pushes the computation of scans, joins, and aggregations down to the Aurora storage layer, running in parallel across thousands of storage nodes. Instead of pulling all data up to the compute instance to process it, the storage layer does the work where the data lives. This dramatically reduces the data transferred to the compute instance and speeds up analytical queries significantly.

══════════════════════════════════════════ -->

Aurora Serverless v2 is a configuration for Aurora DB instances where compute capacity scales automatically based on actual workload demand — in fractions of a second. Instead of choosing a fixed instance class (db.r6g.large), you define a minimum and maximum ACU range. Aurora scales within that range continuously without any downtime.

Serverless v2 is ideal for Lambda-based architectures where traffic is bursty and unpredictable. Pairing with RDS Proxy gives you connection pooling on top of auto-scaling compute — neither Lambda connection exhaustion nor wasted idle compute.

Aurora always runs inside a VPC. A DB subnet group spanning at least 2 AZs is required — Aurora uses all three AZs for its storage regardless of where the compute instances sit. Best practice: place compute in private subnets, with Security Groups allowing only your app tier to reach the Aurora port.

Aurora backups work differently from RDS. Because the storage layer continuously logs all changes to S3 in the background, Aurora does not have a traditional backup window. The backup process never interrupts the cluster and causes zero performance impact — on any instance, in any configuration.

Aurora Backtrack is an Aurora-exclusive feature that lets you rewind your running database to a previous point in time in place — without creating a new cluster. Instead of restoring a snapshot (which creates a new endpoint), Backtrack reverses the cluster volume itself within seconds. This is powerful for accidental schema drops or data corruption.

Aurora Global Database replicates an entire Aurora cluster to up to 5 secondary read-only regions using dedicated replication infrastructure at the storage layer — not over the public internet. Replication lag is typically under 1 second. In a disaster, any secondary can be promoted to a full primary in under 1 minute.

Aurora Machine Learning lets you call Amazon SageMaker and Amazon Comprehend endpoints directly from SQL statements. The ML inference happens without moving data out of Aurora — the storage layer coordinates with SageMaker in the background and returns the prediction as a query result.