Cloud SQL to Amazon RDS: the engine-by-engine, near-zero-downtime migration.
Moving off Google Cloud SQL onto Amazon RDS or Aurora is mostly a same-engine database migration, so logical replication or AWS DMS can carry you to a cutover measured in seconds or minutes, not a maintenance weekend. This page walks the MySQL, PostgreSQL and SQL Server paths, the cross-cloud connectivity for the sync, and how GCP data transfer is priced (and when Google waives it).
- Cloud SQL → RDS/Aurora is a homogeneous migration when you keep the same engine (MySQL→MySQL, PostgreSQL→PostgreSQL, SQL Server→SQL Server). That is the easy case: no schema conversion, and you can use the engine's own logical replication or AWS DMS in CDC mode to keep the target in sync until a near-zero-downtime cutover. The hard cases are deliberate engine changes (e.g. Cloud SQL MySQL → Aurora) or version jumps — still very doable, just with more validation.
- The mechanics: stand up the RDS/Aurora target, open private cross-cloud connectivity (VPN or interconnect) between GCP and AWS, do a full load, switch to change-data-capture so the target tracks live writes, validate row counts and checksums, then cut over by repointing the application. DMS handles full-load-plus-CDC; native replication (MySQL binlog / Postgres logical decoding) is often cleaner for like-to-like moves. Budget for GCP egress on the initial dump.
- CloudRoute matches you with one vetted AWS partner who runs the migration end to end. A database move alone is usually small; as part of a wider GCP exit, your matched partner can file MAP funding when the migration qualifies and AWS approves, typically $50K to $150K for startups. Depends on the workload; AWS approves. CloudRoute is free for startups.
IWhy teams move from Cloud SQL to RDS/Aurora — and why it is usually easy
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 and performance as part of a wider move to AWS.
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.
IIEngine-by-engine: MySQL, PostgreSQL, SQL Server
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.
Cloud SQL for MySQL → RDS for MySQL / Aurora MySQL
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.
Cloud SQL for PostgreSQL → RDS for PostgreSQL / Aurora PostgreSQL
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).
Cloud SQL for SQL Server → RDS for SQL Server
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.
IIICross-cloud connectivity for the migration
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.
- Site-to-site VPN (most migrations): An IPsec VPN between a GCP Cloud VPN gateway and an AWS Site-to-Site VPN gateway gives you private, encrypted connectivity in hours, not weeks. Each tunnel sustains roughly 1.25 Gbps; it is the default choice for the majority of Cloud SQL migrations where the database is tens to low-hundreds of GB and the CDC stream is modest.
- Dedicated interconnect (large or long-running): For multi-terabyte databases or migrations where the CDC window runs for weeks, a dedicated connection (AWS Direct Connect on the AWS side, paired with Google Cloud Interconnect / a partner) gives consistent throughput and lower egress rates. More lead time and cost — justified when VPN bandwidth would make the initial load painfully slow.
- Public endpoints + TLS (smallest / quickest): For a small database or a quick proof of migration, you can connect over public endpoints with TLS and IP allow-listing. Simplest to stand up, but you pay standard internet egress and expose the database surface — fine for a pilot, not ideal for the production sync of sensitive data.
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.
IVGCP egress cost — the one line item people forget
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 most Cloud SQL workloads under a couple of terabytes, data transfer is a one-time cost that belongs in the estimate but rarely changes the decision. And if you are leaving the Cloud SQL service entirely, Google's exit program credits that transfer on your final invoice, provided you file an Exit Notice before migrating and follow its timeline. Partial moves do not qualify.
VCutover and validation — getting to near-zero downtime
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:
Before cutover (days ahead)
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).
At cutover (the 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.
After cutover (hours to days)
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.
VICost after the move — Cloud SQL vs RDS vs Aurora
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 commit to Reserved Instances or a Savings Plan once you know your steady-state size (AWS says Savings Plans save up to 72% compared with On-Demand). 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.
VIIWho runs it, and who can fund it
CloudRoute does not run migrations. It matches you with one vetted AWS partner who does, and who can file the funding only partners can request.
MAP runs in three phases. Assess: the partner sizes your Cloud SQL footprint, designs the RDS or Aurora target and estimates timeline and savings. Mobilize: landing zone, cross-cloud connectivity and a pilot migration of one database. Migrate and Modernize: the production cutover.
Partner-filed funding: AWS says MAP helps offset initial migration costs. A single database move is usually small on its own; it most often counts as part of a wider GCP exit. Your matched partner files MAP when the migration qualifies and AWS approves. For startups this is typically $50K to $150K. Depends on the workload; AWS approves. If it does not qualify, the partner still de-risks the cutover, so you are not learning DMS and cross-cloud VPNs during a production switch.
AWS Activate: separate, and you apply yourself. Activate Founders gives self-funded startups $1,000 to start, up to $5,000; Activate Portfolio gives up to $200,000 with the Org ID from your Activate Provider. A consulting partner cannot file Activate. If you are also moving compute (GKE to EKS, Cloud Run to ECS on Fargate) as part of leaving GCP, the same partner can cover it.
| Funding | Who files it | Amount | When it fits |
|---|---|---|---|
| Migration Acceleration Program (MAP) | Your matched AWS partner | $50K to $150K for startups. Depends on the workload; AWS approves. | You are not on AWS yet and want to migrate. |
| AWS Activate Founders | Founder applies | $1,000 to start, up to $5,000 | Self-funded startups with no investor or accelerator behind them. |
| AWS Activate Portfolio | Founder applies | up to $200,000 | Startups backed by a VC firm, accelerator or angel investor that is an AWS Activate Provider. |
Cloud SQL → RDS/Aurora by engine — tools and cutover at a glance
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) |
How a match works (example)
- You tell us about the work
You fill in a short form: what you run today, what you want to move, test or build, your stage and your region.
- We pick one partner
We read your answers and pick one vetted AWS consulting partner that fits the work, the stack and the region. We reply within 24 hours; your matched partner reaches out within 5 business days.
- The partner checks MAP funding
Your matched partner scopes the migration with you. Then it checks whether the move qualifies for MAP (Migration Acceleration Program) funding. MAP is for teams that are not on AWS yet.
- The partner files, AWS decides
If the work qualifies, the partner files the funding request with AWS. AWS reviews it and decides. The amount depends on the workload.
- You pay nothing
CloudRoute is free for startups. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.
AWS Activate credits are separate, and you apply for them yourself. Use Activate Founders if no investor backs you. Use Activate Portfolio with the Org ID or invite from your VC, accelerator, incubator or angel group if it is an Activate Provider. A consulting partner cannot apply for Activate on your behalf.
Common questions
Can I migrate Cloud SQL to RDS with near-zero downtime?
Should I move Cloud SQL to RDS or to Aurora?
Do I need AWS DMS, or can I use native replication?
How much does GCP egress cost to move my database to AWS?
What connectivity do I need between GCP and AWS during the migration?
Will my schema and queries need to change?
How long does a Cloud SQL to RDS/Aurora migration take?
Can AWS fund this migration?
Move off Cloud SQL onto RDS or Aurora without running it yourself
CloudRoute matches you with one vetted AWS partner who runs the Cloud SQL to RDS or Aurora migration end to end and files MAP funding when the wider migration qualifies and AWS approves. CloudRoute is free for startups.