Amazon Aurora is AWS's MySQL-compatible managed database engine designed for institutional-scale workloads. For public-sector institutions running RDS for MySQL, the migration to Aurora is one of the more common database operations we execute as part of managed cloud operations engagements. The technical work is well-supported by AWS tooling. The operational discipline that makes the cutover succeed under audit is the part worth getting right.
This post is a reference for what RDS for MySQL to Aurora migration looks like in public-sector contexts.
Why Institutions Migrate
Three benefits drive RDS for MySQL to Aurora migrations.
Performance and durability. Aurora replicates data across three Availability Zones automatically, with up to fifteen Aurora Replicas for read scaling and replica lag typically under 20 milliseconds. For institutional workloads with read-heavy traffic patterns (academic catalog browsing, public-facing services), the read scaling is materially valuable.
Higher availability. Aurora's storage is decoupled from compute, providing storage durability independent of instance state. Failover between Aurora instances is faster than RDS for MySQL Multi-AZ failover, typically under 30 seconds.
Operational integration. Aurora integrates with other AWS services (CloudWatch, Lambda, IAM database authentication) more deeply than RDS for MySQL. For workloads using AWS-native operational tooling, the integration reduces operational friction.
The cost is comparable to RDS for MySQL on equivalent instance sizes, sometimes higher depending on storage and I/O patterns. For public-sector workloads, the durability and performance benefits typically justify the cost.
What Migration Actually Looks Like
The migration pattern AWS supports natively: create an Aurora read replica from the RDS for MySQL source, let it catch up, promote it to a writer, and cut over.
Step 1: Create the Aurora cluster as a read replica. From the RDS Management Console, select the source RDS for MySQL instance and choose Create Aurora read replica. AWS provisions the Aurora cluster, takes a snapshot of the source, and restores into Aurora. This phase takes minutes to several hours depending on source database size.
Step 2: Validate replication. Aurora establishes binlog replication from the source. Monitor the AuroraBinlogReplicaLag metric in CloudWatch; when it reaches near zero, replication is current. For larger databases, this validation phase is meaningful operational discipline.
Step 3: Application cutover preparation. Update application connection strings to use a CNAME pointing to the source. The CNAME indirection is what makes cutover a configuration change rather than a code change. If applications already use the database endpoint directly, plan a brief code-update or configuration-update window.
Step 4: Stop writes on the source. Set the read_only parameter on the RDS for MySQL parameter group to 1. The setting takes effect immediately without instance reboot. Verify Seconds_Behind_Master is 0 to confirm all writes have replicated.
Step 5: Promote Aurora. Select the Aurora cluster, choose Promote read replica from Instance actions. Aurora takes a few minutes to complete the promotion. Once complete, Aurora is the writer.
Step 6: Update CNAME to point at Aurora. Application traffic now flows to the new Aurora endpoint. The cutover is complete.
The technical sequence is reliable. The operational discipline around it is what matters.
Operational Discipline for Public-Sector Cutover
For institutional workloads under audit or with explicit downtime requirements, four operational practices around the migration matter.
Pre-migration validation. Test the migration in a non-production environment with a current snapshot of the source database. Validate that the application performs correctly against Aurora. Confirm that any MySQL-specific features used by the application are supported in Aurora's compatibility model.
Documented cutover plan with rollback. The cutover plan documents the steps, the validation checkpoints, and the rollback procedure if something fails. Rollback in this context means reverting to the source RDS for MySQL, which is still available and replicating in reverse if configured. Practice the rollback before relying on it.
Compliance documentation. For workloads under FedRAMP, HIPAA, or specific compliance frameworks, the database change is a system change requiring documented change management. The change ticket, the impact analysis, the cutover evidence, and the post-cutover validation all become audit artifacts.
Post-cutover validation. Confirm that the Aurora cluster is operating as expected: query performance matches or exceeds the source, replication to read replicas is healthy, automated backups are running, monitoring alarms are configured. Until validated, the migration is not done.
What Can Go Wrong
Three failure modes show up in RDS for MySQL to Aurora migrations.
MySQL feature incompatibility. Aurora is wire-compatible with MySQL 5.6 and 5.7 (and current versions support 8.0). Specific MySQL features (some storage engines, certain replication patterns, specific plugin configurations) may not be supported in Aurora. Pre-migration validation in a non-production environment catches these.
Performance regression for specific query patterns. Aurora's performance profile differs from RDS for MySQL in specific ways. Most workloads see improvement; some specific query patterns can regress. Performance testing against representative workloads in non-production validates the migration.
Connection string updates that miss applications. The CNAME indirection works for applications that use the CNAME. Applications hardcoded to the source endpoint do not see the cutover. Pre-migration discovery of all connection strings prevents the surprise.
When Aurora Is Not the Right Answer
For specific workloads, Aurora may not be the right destination.
- Workloads with very low traffic that do not benefit from Aurora's performance characteristics may run more cost-effectively on standard RDS
- Workloads using MySQL features Aurora does not support need to either change architecture or stay on RDS for MySQL
- Workloads with strict regional residency constraints that exceed Aurora's availability may need RDS for MySQL configured per the institution's residency policy
The decision filter is workload-specific. Most institutional workloads benefit from Aurora; some do not.
Frequently Asked Questions
What is the typical downtime for an RDS for MySQL to Aurora migration?
For most workloads, less than five minutes of write downtime during the cutover. The Aurora cluster is created and replicating before the cutover; the actual cutover is the read-only mode on source plus the Aurora promotion. Read traffic can continue throughout the migration.
Does Aurora support all MySQL features?
Aurora is wire-compatible with MySQL 5.6, 5.7, and 8.0. Some MySQL features (specific storage engines like MyISAM for stored data, specific replication topologies) are not supported. Pre-migration validation against a non-production Aurora cluster identifies feature incompatibilities.
How does Aurora pricing compare to RDS for MySQL?
Per-hour instance pricing is similar. Aurora has different storage and I/O pricing models. Workloads with high I/O volume can see Aurora cost more than RDS for MySQL; most workloads see similar or modestly higher cost in exchange for better durability and performance characteristics.
Should public-sector workloads on Aurora use Aurora Serverless?
For workloads with variable demand and idle periods, Aurora Serverless v2 is operationally compelling. For steady-state workloads, provisioned Aurora is typically more cost-effective. The decision depends on the workload's traffic pattern, not on policy.