Skip to main content

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.

◈ DIAGRAM
ap-south-1a → Copy 1, Copy 2
ap-south-1b → Copy 3, Copy 4
ap-south-1c → Copy 5, Copy 6
Can tolerate: 2 AZ failures without data loss
1 AZ failure without losing write availability
Self-healing: corrupted blocks detected and repaired from other copies automatically

Writer and Reader Endpoints

TEXT
Writer Endpoint: always points to the current primary instance
Reader Endpoint: automatically load balances across all read replicas

When 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.

TEXT
Primary region (ap-south-1): all writes
Secondary region (ap-southeast-1): reads served locally, sub-second lag
DR event: promote secondary to primary in <1 min, RPO <1 second

Aurora 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.

Remember

Aurora'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.