RDS to Aurora: when it is worth it and how to move without a long outage

"Should we move to Aurora?" is asked as a performance question and is usually a cost and operations question. The honest answer depends on four numbers you can measure this week.

When Aurora wins

You need more than one read replica and you need them fast. Aurora replicas share the storage layer, so replica lag is typically milliseconds rather than the seconds you get from RDS asynchronous replication, and adding one does not copy the data. If your read scaling story involves five replicas, Aurora is straightforwardly better.

Failover time matters. Aurora fails over in roughly 30 seconds; Multi-AZ RDS takes one to two minutes. If that gap has business meaning, it is a real argument.

Your storage is growing and you do not want to manage it. Aurora storage grows automatically in 10GB increments up to 128TB, and you pay for what you use rather than what you provisioned. On RDS, over-provisioned gp3 volumes are a classic silent cost.

You have a bursty workload. Aurora Serverless v2 scales capacity in fine increments and is genuinely good for staging environments, internal tools and workloads with a quiet night. Be careful with it as a production primary for steady load, where provisioned instances are cheaper.

When RDS stays

Steady, predictable load on a single instance. Aurora charges for I/O on the standard configuration, and a write-heavy workload can make that line larger than the instance itself. Aurora I/O-Optimized removes the I/O charge for a higher instance price and is worth pricing if I/O is above roughly 25 percent of your Aurora bill — but if you are on RDS today with predictable load, the move may cost more.

You need a Postgres or MySQL extension or version Aurora does not support. Check your extension list before anything else. This kills more Aurora migrations than cost does.

Your database is small. Under a few hundred GB with modest traffic, RDS Multi-AZ on gp3 is simpler and cheaper, and the operational differences barely show.

The migration that keeps downtime short

For Aurora MySQL and Aurora PostgreSQL from the matching RDS engine, the path is the same and it is the one to use:

1. Create an Aurora read replica of the RDS instance. AWS does this natively. It takes hours on a large database and has no impact on the source beyond replication load.
2. Wait for replica lag to reach zero and stay there through a peak period. Watch AuroraReplicaLag, not the console summary.
3. Test against the replica. Point a copy of your application at it read-only and run your slowest queries. Aurora's planner is close to but not identical to the source engine; the queries that regress are almost always the ones with the most complex joins.
4. The cutover window. Stop writes at the application layer — a maintenance flag, not a firewall rule — wait for lag zero, promote the Aurora replica, repoint the application via DNS or a stored connection string, resume writes. Done carefully this is 30 to 60 seconds.
5. Keep the old instance running, stopped but not deleted, for a week. The rollback plan is "repoint back", and it only exists if the source is still there.

For cross-engine or cross-version moves, Database Migration Service with ongoing replication is the tool, and you should budget several times more testing. DMS handles the data; it does not handle sequences, custom types, or your stored procedures gracefully.

What to check afterwards

• Parameter groups. Aurora defaults are not RDS defaults. Compare your tuned parameters explicitly; max_connections in particular is computed differently.
• Backups and retention. Aurora backups are continuous with point-in-time restore, but backtrack (MySQL only) is a separate feature you have to enable, and it is the fastest way to undo a bad migration script.
• The reader endpoint. Send read traffic to it deliberately from the application, or you have paid for replicas that do nothing.
• Cost, one month later. Re-run the comparison with real I/O numbers, and switch to I/O-Optimized if the maths says so.

Database moves are the part of a cloud engagement where rollback planning earns its keep, and where we spend most of the testing budget.

What to do this week

Pull four numbers from CloudWatch for your main RDS instance: write IOPS, storage used versus provisioned, replica lag, and the p99 of your slowest query. Those four decide the Aurora question before anyone opens a pricing calculator.