Moving off Google Cloud SQL onto Amazon RDS or Aurora is mostly a homogeneous database migration — same engine, new managed platform — which means logical replication and AWS DMS can carry you to a cutover measured in seconds, not a maintenance weekend. This page walks the MySQL, PostgreSQL, and SQL Server paths, the cross-cloud connectivity you set up for the sync, how GCP egress is priced, and how an AWS MAP-funded partner runs the whole thing at little-to-no cost.
Most Cloud SQL → RDS migrations are driven by one of three things: consolidating onto AWS where the rest of the stack already lives, escaping Cloud SQL's scaling ceiling for write-heavy or high-connection workloads, or capturing Aurora's price/performance and the MAP funding that comes with a committed AWS migration.
Google Cloud SQL is a competent managed database, but it is a single-writer, vertically-scaled service for MySQL and PostgreSQL (read replicas help reads, not writes), and its SQL Server offering trails AWS's on instance and licensing flexibility. Teams that have outgrown a single primary, or that want Aurora's decoupled storage layer, distributed read replicas, Aurora Serverless v2 autoscaling, and global database for cross-region DR, tend to land on RDS or Aurora as the destination.
The reason this migration is usually low-risk is that it is homogeneous: you are moving the same database engine from one managed host to another. Cloud SQL for MySQL is just MySQL; RDS for MySQL and Aurora MySQL speak the same wire protocol and run the same SQL. The schema does not change, application queries do not change, and the migration reduces to copying data and keeping it in sync until you flip the connection string. That is a fundamentally different exercise from a heterogeneous migration like Oracle → Aurora PostgreSQL, where the Schema Conversion Tool (SCT) and query rewrites dominate the effort.
The practical question is which destination — RDS or Aurora — and whether to keep the exact engine or change it during the move. Keeping the engine identical (Cloud SQL MySQL → RDS MySQL) is the safest like-for-like path and the fastest to validate. Moving Cloud SQL MySQL → Aurora MySQL is still homogeneous from the application's perspective (Aurora MySQL is wire-compatible) but introduces Aurora's storage and replication model, so you validate performance characteristics more carefully. The rest of this page assumes you are keeping the engine family and choosing RDS-vanilla or Aurora as the managed flavor.
If you searched "cloud sql to rds" or "cloud sql to aws," you are almost certainly in the homogeneous band. The next section maps your specific engine to its destination and the right replication tool.
The migration tool and the cutover technique differ by engine. Pick your row and the rest of the playbook specializes to it. All three paths share the same skeleton — full load, change-data-capture, validate, cut over — but the native replication mechanics differ.
A note on the choice between RDS-vanilla and Aurora at the destination: RDS for MySQL/PostgreSQL/SQL Server runs the community or commercial engine on managed EC2 with EBS storage — closest to a like-for-like Cloud SQL replacement. Aurora (MySQL- and PostgreSQL-compatible only) re-implements the storage layer for higher throughput and faster replicas, and is usually the better long-term home for MySQL and PostgreSQL workloads. SQL Server has no Aurora equivalent, so it lands on RDS for SQL Server.
Destination: Aurora MySQL for most production workloads (better write throughput, up to 15 low-lag read replicas, Serverless v2); RDS for MySQL when you want the vanilla engine or a specific minor version.
Replication path: Native MySQL binary-log (binlog) replication is the cleanest like-to-like option — enable binary logging on Cloud SQL, take a consistent dump (mysqldump --single-transaction or a Cloud SQL export), load it into the target, then start replication from the recorded binlog coordinates so the target tails live writes. Alternatively, AWS DMS in full-load + CDC mode reads the binlog and applies changes continuously; DMS is the better choice when you are also changing version or want managed monitoring.
Watch for: matching the source character set/collation, ensuring every table has a primary key (DMS CDC needs one to apply changes reliably), and Cloud SQL's managed users/grants which you recreate on RDS. GTID-based replication simplifies failover but confirm both sides agree on GTID mode.
Destination: Aurora PostgreSQL for production (decoupled storage, fast clones, global database); RDS for PostgreSQL for vanilla-engine parity or specific extension needs.
Replication path: PostgreSQL native logical replication via publications/subscriptions is the recommended near-zero-downtime route for like-to-like moves — Cloud SQL supports the logical-decoding setup (set the appropriate flags / replication slot), you create a PUBLICATION on the source and a SUBSCRIPTION on the target, and the target streams changes after the initial copy. AWS DMS with CDC also works and is convenient when version-upgrading or transforming. For very large databases, a pg_dump/pg_restore initial load followed by logical replication catch-up is common.
Watch for: sequences are not advanced by logical replication — bump them on the target at cutover. Large objects, materialized views, and certain extensions need a plan. Confirm the target Postgres version supports the extensions Cloud SQL had enabled (PostGIS, pg_stat_statements, etc.) and that DDL changes are handled (logical replication does not replicate schema changes automatically).
Destination: RDS for SQL Server (no Aurora equivalent). Choose License Included to fold the SQL Server license into the hourly rate, or Bring Your Own Media via a covered licensing path where eligible.
Replication path: SQL Server is the most involved of the three. The pragmatic route is native backup/restore — back up the Cloud SQL database to a file, stage it in Amazon S3, and restore into RDS for SQL Server using the rds_restore_database stored procedure — then capture the delta. AWS DMS supports SQL Server as a source for ongoing CDC, but transactional replication and CDC on managed SQL Server have prerequisites (recovery model, CDC enabled, no unsupported data types) you validate up front. For modest databases, a short maintenance window with backup/restore is often simpler than chasing true zero downtime.
Watch for: SQL Agent jobs, linked servers, and server-level objects do not travel with a database backup — inventory and recreate them. Confirm edition parity (Standard vs Enterprise features) and that no features in use are unsupported on RDS for SQL Server.
Keeping the same engine (MySQL→MySQL, Postgres→Postgres, SQL Server→SQL Server) means no schema conversion — the hard part of database migration disappears. If you are deliberately re-engineering (e.g. SQL Server → Aurora PostgreSQL to drop license cost), that is a heterogeneous migration: add the AWS Schema Conversion Tool and query-rewrite effort. Most Cloud SQL → RDS moves are homogeneous and should be kept that way unless license savings justify the conversion work.
For DMS or native replication to stream changes from Cloud SQL into RDS/Aurora, the two clouds need a private, reliable path between them for the duration of the migration. You set this up once, run the sync over it, and tear it down (or keep it) after cutover.
There are three connectivity tiers, in increasing order of cost and reliability. Pick based on data volume and how long the sync window is.
Whichever tier you choose, the DMS replication instance (or your replication tooling) lives in the AWS VPC and connects to Cloud SQL across that private path. Lock down both sides: Cloud SQL authorized networks / private IP on the GCP side, security groups and NACLs on the AWS side, and TLS in transit end to end. The AWS partner CloudRoute matches you to sets this up as the first step of the Mobilize phase, before any data moves.
The initial full load copies your entire database out of Google Cloud, and Google charges for data leaving its network. This is usually the single migration-specific cost worth modeling, and it is almost always smaller than people fear.
GCP network egress to the internet / other clouds is priced per GB and tiers down with volume — representative 2026 rates land roughly in the $0.08–$0.12/GB range for the first tier (confirm current pricing for your region and destination at migration time). The math is straightforward: a 200 GB database costs on the order of $16–$24 to egress once; a 1 TB database, well under $150. The ongoing CDC stream is comparatively tiny — it carries only the changes (the binlog / WAL delta), a small fraction of the base size per day.
Two ways to keep egress modest: compress the initial dump before it crosses the wire (mysqldump/pg_dump piped through compression, or compressed export files), and prefer a dedicated interconnect for very large databases since inter-cloud egress over a partner interconnect is cheaper per GB than internet egress. Inbound data transfer into AWS is free, so the cost is entirely on the GCP side.
The honest takeaway: for the overwhelming majority of Cloud SQL workloads — anything under a couple of terabytes — egress is a one-time cost that belongs in the estimate but rarely changes the decision. Where it does matter is multi-terabyte databases, and that is exactly where a dedicated interconnect and a partner-run plan pay off.
The whole point of full-load-plus-CDC is that when you cut over, the target is already a live, continuously-updated copy of the source. Cutover then becomes a short, scripted sequence rather than a copy-everything-now maintenance window.
A homogeneous Cloud SQL → RDS/Aurora cutover, run properly, takes the application offline for seconds to a few minutes — the time to drain in-flight transactions, confirm the target has caught up to the source, and repoint connection strings. Here is the sequence the partner follows:
Full load completes and CDC is running with low, stable replication lag. You validate continuously: row counts per table, checksums on sampled tables, and spot-checks of recent writes appearing on the target. Application configuration is staged so the connection string can flip via an environment variable or secret, not a redeploy. A rollback plan is written: if validation fails post-cutover, you point back at Cloud SQL (still live and, ideally, still receiving writes via reverse replication for a brief window).
Stop writes to the source (put the app in read-only or maintenance for the brief window), let CDC drain the last transactions until source and target are at parity, advance any sequences/identity columns on the target, repoint the application to the RDS/Aurora endpoint, and bring the app back up. Smoke-test the critical write and read paths immediately.
Keep Cloud SQL running but idle as a fallback for a defined window (commonly 24–72 hours). Watch RDS/Aurora performance metrics, error rates, and slow-query logs under real traffic. Once you are confident, decommission Cloud SQL, tear down the cross-cloud VPN, and stop the DMS replication instance. Final step: confirm backups/automated snapshots and the right Multi-AZ / read-replica topology are in place on the AWS side.
The data copy is the easy 80%. The remaining 20% — proving the target is byte-for-byte correct, that sequences and auto-increment values are aligned, that no rows were dropped on a table without a primary key, that application behaviour is identical — is where migrations succeed or fail. Build row-count and checksum validation into the runbook and do not cut over until it is green. A partner who has done this dozens of times brings the validation harness with them.
Migration cost is one-time; the platform bill is forever. For most teams the destination question (RDS vs Aurora, on-demand vs reserved/committed) matters more to the long-run economics than the migration itself.
RDS-vanilla pricing is closest to Cloud SQL's mental model: you pay for the instance, the storage, and the I/O / backups, and you can cut 30–50% off compute with Reserved Instances or a Savings Plan once you know your steady-state size. Aurora prices compute similarly but charges storage and I/O on a consumption model (storage grows automatically; I/O is per-request, or flat with Aurora I/O-Optimized for I/O-heavy workloads), and Aurora Serverless v2 scales capacity to load so you stop paying for idle headroom. The right comparison is not sticker rate but total cost at your actual utilization.
Where AWS frequently comes out ahead of Cloud SQL: read-heavy workloads (Aurora's up-to-15 low-lag replicas vs Cloud SQL's read replicas), spiky workloads (Serverless v2 autoscaling), and committed steady workloads (Reserved Instances / Savings Plans, which Cloud SQL's committed-use discounts only partially match). Where it is roughly a wash: a small, steady single-instance database — both clouds are competitive, and the migration is justified by consolidation rather than raw price.
CloudRoute does not run migrations itself — it routes you to a vetted AWS partner who does, and structures the engagement so AWS's Migration Acceleration Program (MAP) funds the work. For qualifying migrations, that means the assessment is free and AWS credits a large share of the migration cost.
MAP runs in three phases. Assess is a TCO and readiness review — the partner sizes your Cloud SQL footprint, designs the RDS/Aurora target, and estimates timeline and savings; AWS typically funds this phase, so it is usually free to you. Mobilize stands up the AWS landing zone, the cross-cloud connectivity, and a pilot migration of one database to prove the runbook. Migrate & Modernize executes the production cutover. AWS provides credits/funding scaled to the migration size across these phases, paid through the partner via the AWS Partner Network — so the customer pays $0–low.
The honest framing: MAP funding is meaningful but conditional. It applies to migrations with a qualifying scope — generally a committed post-migration AWS spend (for databases, usually a few thousand dollars a month of projected RDS/Aurora consumption and up). Below that threshold, or for a one-off small database, MAP may not apply — in which case CloudRoute is still a vetted-partner referral that de-risks the cutover with an expert who has run dozens of these moves. Either way you are not learning DMS, binlog coordinates, and cross-cloud VPNs on the job during a production cutover.
MAP funding ties into AWS's broader credit programs: a Cloud SQL migration frequently comes bundled with general-purpose AWS credits for the surrounding workload — see the credits cluster (the $100K Activate Portfolio tier, and how proof-of-concept funding works) for how those stack on top. If you are also moving compute (GKE → EKS, Cloud Run → ECS/App Runner) as part of leaving GCP, the same partner and MAP engagement cover it.
The destination and replication tool depend on your source engine. This is the routing table the partner uses on the Assess call to pick your path.
| Cloud SQL source | Recommended AWS target | Primary replication tool | Near-zero-downtime? | Schema conversion? |
|---|---|---|---|---|
| Cloud SQL for MySQL | Aurora MySQL (or RDS MySQL) | Native binlog replication or DMS (full-load + CDC) | Yes — CDC keeps target live to cutover | None (homogeneous) |
| Cloud SQL for PostgreSQL | Aurora PostgreSQL (or RDS PostgreSQL) | Native logical replication (pub/sub) or DMS CDC | Yes — logical replication streams changes | None (homogeneous) |
| Cloud SQL for SQL Server | RDS for SQL Server | Native backup→S3→restore + DMS CDC for delta | Short window typical; CDC possible with prereqs | None (homogeneous) |
| Cloud SQL MySQL → Aurora PostgreSQL | Aurora PostgreSQL | AWS SCT + DMS (full-load + CDC) | Possible — more validation | Yes (heterogeneous — by choice) |
| Cloud SQL SQL Server → Aurora PostgreSQL | Aurora PostgreSQL (license savings) | AWS SCT + DMS (full-load + CDC) | Possible — most effort of any path | Yes (heterogeneous — by choice) |
Situation: GCP-native from day one but the rest of the new infra roadmap (data platform, Bedrock-based features) was landing on AWS. Wanted to consolidate onto AWS without a multi-hour maintenance window on the customer-facing PostgreSQL database, and was nervous about cross-cloud data transfer cost and the SQL Server-style "backup and pray" cutover they had read about. Internal team had never run a cross-cloud database migration.
What CloudRoute did: Routed within 24 hours to an EU-region partner with a database-migration track record. MAP Assess (free) sized the footprint and confirmed qualification. Mobilize stood up the landing zone and a site-to-site VPN between GCP and AWS, then piloted the 140 GB MySQL DB to Aurora MySQL via DMS full-load + CDC. Production PostgreSQL moved to Aurora PostgreSQL using native logical replication: full load over the VPN, logical-replication catch-up, continuous row-count + checksum validation. GKE → EKS was scoped as a follow-on under the same MAP engagement.
Outcome: PostgreSQL cut over in a ~90-second write-pause window; MySQL in under a minute. Total GCP egress for both initial loads: ~$78. Migration timeline: 6 weeks from Assess to final decommission. AWS MAP funded the assessment in full and credited ~50% of the migration cost; CloudRoute's commission was paid by the partner — the customer's out-of-pocket migration cost was negligible.
engagement window: 6 weeks · cutover downtime: <90s (Postgres), <60s (MySQL) · GCP egress: ~$78 · MAP funding: assessment free + ~50% of migration · cost to customer: low/$0
CloudRoute routes you to a vetted AWS partner who runs the Cloud SQL → RDS/Aurora migration end to end and, for qualifying workloads, funds it through AWS MAP. Near-zero-downtime cutover. Customer pays $0–low.