RDS and Aurora are both managed relational database services on AWS. Aurora is marketed as the next generation — and in many ways it is. But the decision to migrate an existing RDS instance to Aurora is rarely straightforward, and “Aurora is better” is not a sufficient reason to do it.
Here’s what actually differentiates them, when Aurora is worth it, and what a migration involves.
What they are
Amazon RDS is a managed service that runs standard database engines: MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server. AWS handles OS patching, backups, and Multi-AZ failover. You choose an instance class and a storage allocation.
Amazon Aurora is a cloud-native database engine AWS built from scratch, with MySQL and PostgreSQL compatibility. It uses a distributed storage layer that separates compute from storage, replicates data across 3 Availability Zones automatically, and handles many operational concerns differently than standard RDS.
Aurora comes in two deployment modes: provisioned (dedicated instances, like standard RDS) and serverless v2 (capacity scales automatically between a minimum and maximum ACU).
Where Aurora has a genuine advantage
Storage auto-scaling. Aurora storage grows automatically as your data grows, up to 128 TiB. With standard RDS, you provision storage upfront and can auto-scale it, but Aurora’s storage management is more seamless and its I/O architecture is optimized differently.
Faster failover. Aurora Multi-AZ failover typically completes in under 30 seconds for reader promotion. Standard RDS Multi-AZ failover involves starting a new primary from a standby — typically 60–120 seconds of downtime. For applications with availability SLAs, this matters.
Read replicas with shared storage. Aurora read replicas share the same underlying storage volume as the primary. Replication lag is typically under 100ms. Standard RDS read replicas replicate via binlog and can lag significantly under write load.
Aurora Serverless v2. If your workload has variable or unpredictable traffic, Serverless v2 scales compute in fine-grained increments (0.5 ACU steps). You don’t over-provision for peak, and you don’t under-provision for bursts. This is Aurora-specific — there’s no equivalent in standard RDS.
Global Database. Aurora Global Database supports cross-region replication with sub-second latency, enabling fast regional failover or read replicas in other continents. No equivalent in standard RDS.
Where standard RDS is still the right choice
Cost at small scale. Aurora provisioned is typically 20–30% more expensive than equivalent RDS instances for the same compute. For a small database on a db.t3.medium, the dollar difference is minimal, but Aurora’s minimum viable configuration (especially for HA) is higher cost than RDS’s equivalent.
Engine-specific requirements. If you’re running Oracle or SQL Server, Aurora isn’t an option — it’s MySQL and PostgreSQL only. If your application has engine-specific features that require vanilla MySQL 8.x or PostgreSQL 16.x behavior, test compatibility before committing to Aurora.
Simplicity. If you have a simple, low-traffic database with no HA requirement, standard RDS is straightforward and well-understood. Aurora adds architectural complexity (storage layer, cluster endpoints, writer/reader endpoint routing) that may not be worth it for a single dev database.
Legacy applications. Some older ORMs and connection libraries don’t handle Aurora cluster endpoint routing correctly (always connecting to the writer endpoint, not using reader replicas). This is edge-case but real — test your application against Aurora before migrating.
The cost comparison
Aurora I/O costs are worth modeling carefully. Aurora charges per I/O operation against the distributed storage layer. For write-heavy workloads, this can significantly increase costs compared to RDS with provisioned IOPS.
Aurora I/O-Optimized pricing mode (enabled per cluster) trades higher per-instance cost for unlimited I/O included — better for I/O-intensive workloads, worse for read-heavy ones.
Before migrating:
- Look at your current RDS IOPS in CloudWatch (
ReadIOPS,WriteIOPS) - Estimate Aurora I/O cost using the AWS pricing calculator
- Compare against your current RDS storage + IOPS cost
For many production databases, Aurora ends up similar or slightly cheaper when you include the failover and read replica benefits. For others, RDS is cheaper.
How to migrate
The lowest-risk migration path is using AWS Database Migration Service (DMS):
- Create the Aurora cluster (matching engine version — MySQL or PostgreSQL)
- Take a full snapshot of the RDS instance or use DMS for full load
- Set up DMS continuous replication (CDC) to keep Aurora in sync
- Test your application against the Aurora endpoint
- Switch the application connection string to the Aurora cluster writer endpoint during a maintenance window
- Monitor for a few days before decommissioning RDS
For PostgreSQL specifically, pg_dump / pg_restore is often simpler than DMS for smaller databases.
The snapshot restore method is faster but involves downtime: stop writes, take a snapshot, restore to Aurora, update connection strings. Works well for databases where you can afford a maintenance window.
Watch for: schema differences that matter at the Aurora engine version (Aurora MySQL 3.x is MySQL 8.0-compatible, Aurora PostgreSQL 15/16 are compatible with those versions — not necessarily the exact minor version you’re running). Test thoroughly in staging before production.
When to seriously consider Aurora
If any of these apply, Aurora is worth a proper evaluation:
- You need fast automatic failover (sub-30-second) for availability SLAs
- Your read traffic is heavy and you want to scale reads without complex replication lag management
- You have unpredictable traffic spikes and want Serverless v2 auto-scaling
- You’re building a multi-region application and need Aurora Global Database
- Your database is growing fast and you want seamless storage scaling
If none of these apply and you’re running a standard web application database, standard RDS will serve you well.
When to bring in help
Database migrations carry risk. A failed cutover or an application incompatibility discovered in production is expensive. If you’re migrating a business-critical database, it’s worth having an architect review the plan before you execute.
I’ve done RDS-to-Aurora migrations as part of infrastructure modernization engagements, and I can help you model the cost impact, test compatibility, and plan the cutover sequence to minimize risk.
Contact me or email nick@coldsmokeconsulting.com.
Nick Allevato is an AWS Certified Solutions Architect Professional with 20 years of infrastructure experience. He runs Cold Smoke Consulting, an independent AWS consulting practice.