Amazon Aurora
AWS cloud-native relational database compatible with PostgreSQL and MySQL. 5x faster than MySQL, storage auto-grows to 128 TB, and data is stored in 6 copies across 3 Availability Zones automatically.
Aurora is AWS's cloud-native relational database engine — PostgreSQL and MySQL compatible, rebuilt from the ground up for cloud scale and performance. Your existing drivers, queries, and tools work without changes.
Aurora vs Standard RDS
| Feature | RDS MySQL | Aurora MySQL |
|---|---|---|
| Performance | Baseline | 5x faster |
| Storage growth | Manual, up to 64 TB | Auto-grows 10 GB at a time to 128 TB |
| Storage copies | 2 (primary + Multi-AZ) | 6 copies across 3 AZs automatically |
| Replica lag | Seconds | Under 10 milliseconds |
| Failover time | 60-120 seconds | Under 30 seconds |
| Read Replicas | Up to 5 | Up to 15 |
| Cost | Baseline | ~20% higher |
Aurora Storage Architecture
Aurora automatically stores 6 copies of your data across 3 Availability Zones. This happens automatically with zero configuration.
ap-south-1a → Copy 1, Copy 2ap-south-1b → Copy 3, Copy 4ap-south-1c → Copy 5, Copy 6 Can tolerate: 2 AZ failures without data loss 1 AZ failure without losing write availabilitySelf-healing: corrupted blocks detected and repaired from other copies automaticallyWriter and Reader Endpoints
Writer Endpoint: always points to the current primary instanceReader Endpoint: automatically load balances across all read replicasWhen the primary fails and a replica is promoted, the Writer Endpoint automatically updates — your application just reconnects to the same DNS name and reaches the new primary.
Aurora Serverless v2
Scales in fine-grained increments (0.5 ACU steps) in seconds. Scales to near-zero when idle. Development databases that only run during business hours can save 60-80% compared to provisioned instances.
Aurora Global Database
Up to 10 secondary read-only regions. Replication lag under 1 second. Promote a secondary to primary in under 1 minute for disaster recovery.
Primary region (ap-south-1): all writesSecondary region (ap-southeast-1): reads served locally, sub-second lagDR event: promote secondary to primary in <1 min, RPO <1 secondAurora Database Cloning
Creates a full copy of your production cluster in minutes using copy-on-write. No data is actually duplicated until you write to the clone. Production is completely unaffected. Perfect for testing schema migrations against real production-sized data.
RememberAurora's 6 copies across 3 AZs cannot be disabled — it is the architecture. This is why Aurora recovers from failures in under 30 seconds while standard RDS Multi-AZ takes 60-120 seconds. The storage layer is always redundant regardless of whether you enable Multi-AZ.
Frequently Asked Questions
How does Aurora achieve better performance than stock MySQL or PostgreSQL?
Aurora decouples compute from storage: the storage layer is a distributed, log-structured system spread across multiple Availability Zones that only ships redo log records over the network instead of full data pages, cutting network I/O dramatically compared to traditional replication. Storage also auto-heals and auto-scales in 10GB increments up to 128TB without any manual provisioning or downtime.
When would you choose RDS for MySQL/PostgreSQL over Aurora?
Aurora costs more per hour than equivalent RDS instances and only supports PostgreSQL/MySQL compatibility — no Oracle or SQL Server. For smaller workloads, dev/test environments, or budget-constrained projects where you don't need Aurora's scaling headroom or read-replica performance, standard RDS is often the more cost-effective choice. Aurora earns its premium at higher scale, especially read-heavy workloads with many replicas.