Aurora isn’t just RDS with a faster engine. AWS re-architected the storage layer from scratch, bolted on a MySQL or PostgreSQL-compatible query layer, and charges a premium for it. Whether that premium is justified depends on your workload, your availability requirements, and how much you actually need what Aurora offers versus what standard RDS already handles well.
Most teams default to Aurora because it sounds better. Some of them are overpaying. Others would save money by switching to Aurora because of how its storage and replication model works. The answer isn’t universal, and the marketing doesn’t help.
What Aurora Actually Is
Standard RDS runs MySQL or PostgreSQL on an EC2 instance with EBS storage attached. It’s the same database engine you’d run yourself, wrapped in managed infrastructure. Aurora is fundamentally different.
Aurora separates compute from storage. The query processing layer speaks MySQL or PostgreSQL wire protocol, but underneath, the storage engine is a distributed, log-structured system purpose-built by AWS. Your data is automatically replicated to six copies across three Availability Zones. Storage scales automatically up to 128TB without downtime or manual intervention.
This architecture changes several things:
- Writes go to the storage layer, which handles replication independently of the query engine
- Crash recovery is continuous, not a lengthy replay of WAL/redo logs on restart
- Read replicas share the same storage, so replication lag is typically under 20ms and often single-digit milliseconds
The trade-off is that Aurora is a proprietary AWS service. You can’t run it on-premises or on another cloud provider. Your MySQL or PostgreSQL application code works unchanged, but you’re locked into AWS’s storage layer with no escape hatch beyond a standard dump-and-restore migration.
Performance Claims vs Reality
AWS markets Aurora as delivering 5x the throughput of standard MySQL and 3x the throughput of standard PostgreSQL. These numbers come from specific benchmark configurations that emphasize Aurora’s strengths.
In practice, the performance advantage varies significantly by workload type.
Write-heavy workloads see the most improvement. Aurora’s distributed storage handles concurrent writes more efficiently than a single EBS volume. For applications doing thousands of writes per second, 2-3x throughput improvement over standard RDS is realistic. The gap widens as write concurrency increases.
Read-heavy workloads with proper indexing see marginal improvement. If your queries are hitting indexes efficiently and your working set fits in memory, the bottleneck is compute, not storage. Aurora’s storage advantages don’t help much here. You might see a 10-20% improvement, sometimes less.
Mixed workloads benefit from Aurora’s ability to handle reads and writes simultaneously without the contention you see on a single EBS volume. This is where most production applications land, and a 1.5-2x improvement is a reasonable expectation.
Large table scans and analytics benefit from Aurora’s parallel read capabilities. If you’re running reporting queries that scan significant portions of tables, Aurora’s distributed storage can serve data faster than a single EBS volume.
The honest summary: Aurora is meaningfully faster for write-heavy and mixed workloads, marginally faster for read-heavy workloads, and the “5x” marketing number is an upper bound you probably won’t hit.
Aurora’s Storage Architecture
Aurora’s storage is genuinely impressive from an engineering standpoint. Six copies of your data across three AZs means you can lose an entire AZ plus one additional node and still serve reads. You can lose an entire AZ and still serve writes.
Storage auto-scales in 10GB increments up to 128TB. You never provision storage, never resize volumes, never worry about running out of disk space at 3am. For databases that grow unpredictably, this eliminates an entire category of operational incidents.
Backup is continuous. Aurora continuously backs up data to S3 in real-time, with no performance impact and no backup windows. Point-in-time recovery works to any second within your retention period (up to 35 days), and restores are fast because they don’t replay transaction logs the way traditional restores do.
Aurora also offers Backtrack (MySQL-compatible only), which lets you rewind your database to a previous point in time without restoring from backup. Accidentally deleted a table? Backtrack to 30 seconds ago. This isn’t a replacement for backups, but it handles a class of human errors that would otherwise require a full restore.
Aurora Serverless v2
Aurora Serverless v2 adds auto-scaling compute on top of Aurora’s auto-scaling storage. Instead of choosing an instance size, you set a minimum and maximum capacity in Aurora Capacity Units (ACUs). Each ACU provides roughly 2GB of RAM and corresponding CPU.
The scaling is granular, adjusting in 0.5 ACU increments, and fast enough for most workloads. It handles the nightly batch job that needs 4x your normal compute, the traffic spike from a marketing campaign, and the weekend lull when your database barely does anything. Unlike the original Serverless v1 (which paused and resumed with noticeable cold-start delays), v2 scales smoothly without connection drops.
Pricing works like this: you pay per ACU-hour consumed. At $0.12/ACU-hour (us-east-1 pricing), a database running at 4 ACUs costs about $0.48/hour or roughly $350/month. The minimum is 0.5 ACU.
Serverless v2 makes sense when your workload is genuinely variable. If your database consistently needs 8 ACUs, a provisioned Aurora instance at the equivalent size will cost less. But if your usage swings between 2 ACUs at night and 16 ACUs during peak hours, Serverless v2 avoids paying for peak capacity 24/7.
You can also mix provisioned and Serverless v2 instances within the same Aurora cluster. A common pattern: provisioned writer instance for predictable baseline load, Serverless v2 read replicas that scale up during peak traffic and scale down overnight. This gives you cost efficiency on both ends.
One limitation: Serverless v2 doesn’t scale to zero. You always pay for at least the minimum ACU setting. For development databases that sit idle most of the time, this still costs $30-40/month. The original Aurora Serverless v1 could scale to zero but had other significant limitations and is being deprecated.
RDS Strengths
Standard RDS has real advantages that Aurora doesn’t match.
Lower baseline cost. A db.r6g.large on RDS costs roughly $175/month on-demand. The Aurora equivalent costs about $210/month, a 20% premium before you factor in storage pricing differences. With Reserved Instances, RDS pricing drops further, and the absolute dollar savings increase with instance size.
Simpler mental model. RDS is MySQL or PostgreSQL running on managed infrastructure. The behavior is predictable because it’s the same engine. Aurora’s storage layer introduces subtle differences: some monitoring metrics behave differently, certain edge cases around storage behave unlike standard MySQL/PostgreSQL, and debugging performance issues sometimes requires understanding Aurora-specific internals.
Standard engine compatibility. RDS runs actual MySQL and PostgreSQL. Aurora runs a compatible query layer. The compatibility is excellent for most applications, but edge cases exist. Certain extensions, specific replication configurations, and some low-level engine behaviors differ. If you need guaranteed byte-for-byte compatibility with community MySQL or PostgreSQL, RDS provides that.
Easier migration path. Moving off RDS to another provider (Google Cloud SQL, Azure Database, self-hosted) is a standard database migration. Moving off Aurora requires the same migration, but you lose Aurora-specific features in the process. If multi-cloud or exit strategy matters to you, RDS keeps your options open.
Reserved Instance savings. Both Aurora and RDS support Reserved Instances, but the absolute savings are larger with RDS because you’re reserving more expensive resources (including the standby in Multi-AZ). A 1-year partial upfront RI typically saves 30-40% over on-demand pricing for both services. For predictable workloads, RIs close the gap between Aurora and RDS costs significantly.
Cost Comparison
Aurora’s pricing structure differs from RDS in ways that can make it cheaper or more expensive depending on your situation.
Compute: Aurora instances cost about 20% more than equivalent RDS instances. A db.r6g.xlarge costs roughly $420/month on Aurora vs $350/month on RDS (on-demand, us-east-1).
Storage: RDS charges for provisioned storage (you pick a size and pay for it whether you use it or not). Aurora charges for consumed storage at $0.10/GB/month. If you provision 500GB on RDS but only use 100GB, you’re paying for 500GB. Aurora charges for 100GB. Conversely, if you use every byte of your provisioned RDS storage, RDS storage pricing ($0.115/GB/month for gp3) is comparable to Aurora’s.
I/O: Aurora charges for I/O operations ($0.20 per million requests). RDS with gp3 storage includes 3,000 IOPS baseline for free, with provisioned IOPS available. For I/O-heavy workloads, Aurora’s I/O costs can add up quickly. Aurora I/O-Optimized eliminates per-request charges for a 30% storage price increase, which is often worth it for busy databases.
High availability: RDS Multi-AZ doubles your compute cost (you’re running a standby instance). Aurora’s replication is built into the storage layer, so you get multi-AZ durability without paying for a standby instance. If you need HA, Aurora can actually be cheaper than RDS Multi-AZ despite the higher per-instance cost.
Approximate monthly costs for a common configuration:
# 4 vCPU, 32GB RAM, 500GB data, Multi-AZ
RDS Multi-AZ (db.r6g.xlarge):
Compute: $700/month (2x instances)
Storage: $57/month (500GB gp3)
Total: ~$757/month
Aurora (db.r6g.xlarge):
Compute: $420/month (single writer)
Storage: $50/month (500GB at $0.10/GB)
I/O: $40-200/month (varies by workload)
Total: ~$510-670/month
For HA configurations, Aurora often costs less. For single-AZ deployments where you don’t need HA, RDS is cheaper.
One thing to watch: Aurora’s I/O costs are hard to predict before you run the workload. Some teams have been surprised by I/O bills that pushed Aurora well past RDS pricing. If you’re evaluating Aurora, run a realistic load test and monitor VolumeReadIOPs and VolumeWriteIOPs CloudWatch metrics to estimate I/O costs before committing. Or just use Aurora I/O-Optimized from the start if your workload is write-heavy.
High Availability and Failover
Aurora’s failover is faster. When the primary instance fails, Aurora promotes a read replica in about 30 seconds. If no replica exists, Aurora creates a new instance in under 10 minutes. The storage layer is unaffected by compute failures because it’s independent.
RDS Multi-AZ failover takes 60-120 seconds. The standby instance has a full copy of the data on its own EBS volume, and the DNS endpoint flips to point to it. This works well but is slower and requires running a full standby instance.
Aurora also supports Global Database for disaster recovery across AWS regions. The primary region replicates to up to five secondary regions with typical lag under one second. Failover to a secondary region promotes it to a full read/write cluster. RDS offers cross-region read replicas, but the promotion process is manual and slower.
For applications where 30 seconds vs 120 seconds of downtime matters, Aurora’s failover model is a genuine advantage. For most applications, both are acceptable.
Read Replicas
This is where Aurora’s architecture shines. Aurora read replicas share the underlying storage volume with the primary instance. Creating a replica takes minutes and doesn’t require copying data. Replication lag is typically under 20ms because replicas read from the same storage, they’re just applying redo log entries to update their buffer cache.
RDS read replicas use standard asynchronous replication. Data is streamed from the primary to each replica, which means each replica has its own copy of the data. Replication lag varies, typically 100ms to several seconds depending on write volume. Creating a replica requires a full copy of the data, which takes time proportional to database size.
If you need multiple read replicas, Aurora is meaningfully better. Less lag, faster replica creation, and no storage overhead per replica. Aurora supports up to 15 read replicas; RDS supports up to 5 for MySQL and 5 for PostgreSQL.
Aurora also provides a reader endpoint that automatically load-balances connections across all read replicas. RDS requires you to implement your own load balancing across replica endpoints, whether through application logic, a proxy, or DNS round-robin. For applications scaling reads across multiple replicas, this built-in load balancing simplifies the architecture.
When to Choose Aurora
Pick Aurora when at least two or three of these apply:
- Write-heavy workloads that benefit from Aurora’s distributed storage
- Applications requiring fast failover where 30 seconds matters vs 120 seconds
- Databases with unpredictable growth where auto-scaling storage eliminates capacity planning
- Read-replica-heavy architectures where shared storage reduces cost and lag
- High availability requirements where Aurora’s built-in multi-AZ is cheaper than RDS Multi-AZ
- Variable workloads suited to Aurora Serverless v2
When to Choose RDS
Stick with RDS when these describe your situation:
- Cost-sensitive deployments where the 20% compute premium isn’t justified
- Stable, predictable workloads that don’t need auto-scaling
- Single-AZ setups where HA isn’t required
- Standard engine compatibility matters for extensions, tools, or migration flexibility
- Simple architectures without read replicas where Aurora’s storage advantages don’t apply
- Multi-cloud strategy where avoiding AWS lock-in is a priority
The Bottom Line
Aurora is not universally better than RDS. It’s a different architecture with different strengths, and the pricing model means it can cost more or less depending on your specific usage pattern.
Start with RDS if your workload is straightforward, your database is under 500GB, you don’t need read replicas, and you want to keep costs predictable. Standard RDS handles the vast majority of production workloads without any issues. You can always migrate to Aurora later with minimal downtime using an Aurora read replica of your RDS instance, which AWS makes relatively painless.
Move to Aurora when you need what Aurora specifically provides: faster failover, shared-storage read replicas, auto-scaling storage, or Serverless v2 for variable workloads. The HA cost advantage alone justifies Aurora for many production databases that require multi-AZ deployments.
Don’t choose Aurora because it sounds better. Choose it because the architectural differences solve a specific problem you actually have. And if you’re already on Aurora and wondering whether you’re getting your money’s worth, check your I/O costs, replica count, and HA configuration. Those are the three factors that determine whether Aurora’s premium is paying for itself.