Deployment and Migration
Deployment choices
Know the difference between a Multi-AZ deployment (synchronous standby, automatic failover, no read traffic) and read replicas (asynchronous, readable, promotable). Aurora Global Database replicates at the storage layer to secondary Regions with typically sub-second lag and a one-second RPO, which is the answer for cross-Region disaster recovery or low-latency global reads. Aurora Serverless v2 scales capacity in fine ACU increments and fits variable or unpredictable load better than pausing serverless v1. RDS Blue/Green Deployments give you a staged environment for major version upgrades with managed switchover. RDS Custom exists for engines needing OS-level access.
Migration mechanics
For heterogeneous moves, AWS SCT converts the schema and code objects (stored procedures, views, synonyms), while DMS moves the data. DMS handles homogeneous migrations too. The standard low-downtime pattern is full load plus ongoing CDC replication, then cutover once replication lag reaches zero. Validate row counts and checksums before cutover, and keep the source writable only until the switch.
Traps
SCT does not migrate data; DMS's built-in conversion is shallow and does not replace SCT for procedural code. DMS Serverless removes replication-instance sizing decisions but does not change the CDC workflow. Undersized replication instances and LOB settings cause slow or failed loads. For very large databases, native dump/restore over the network is slower and less resumable than DMS. Parameter groups must match engine family and are applied on reboot for static parameters.
Rule of thumb
"Minimal downtime, different engine" → SCT + DMS full load with CDC. "Same engine, version upgrade with rollback" → Blue/Green. "Cross-Region DR with seconds of data loss" → Aurora Global Database.