Migrating from Google Cloud to AWS: Service Mapping, Tools and Cutover

A move from Google Cloud to AWS follows the same shape as any cloud migration: inventory, mapping, landing zone, data sync, cutover. The specific traps in this direction are the global VPC that has to be split into regional VPCs, project-level IAM that has to become account and role design, and Google-only services such as BigQuery and Pub/Sub that have no one-to-one equivalent.

Inventory and decide per workload

Export what exists before planning anything. Cloud Asset Inventory lists every resource across the organization:

gcloud asset search-all-resources --scope=organizations/123456789012 \
  --format="table(assetType,name,location)" > gcp-inventory.txt

Billing export to BigQuery shows which services actually matter by spend. For each workload choose rehost, replatform, refactor or retire, and grep code and IaC for googleapis.com, project IDs and Google client libraries. On the AWS side, AWS Transform covers discovery and wave planning; it replaced Migration Hub and Application Discovery Service, which closed to new customers in November 2025.

Google Cloud to AWS service mapping

Differences to design for

Accounts, not projects. Use AWS Organizations with separate accounts per environment and per team, set up with Control Tower or your own Terraform. Human access goes through IAM Identity Center, not IAM users.

IAM is identity-based. Instead of granting a role on a resource, you attach policies to roles and assume them. Service accounts become IAM roles for EC2 instance profiles, Lambda execution roles or EKS pod identities.

Networks are regional. A Google VPC spans regions. In AWS you need one VPC per region, subnets per Availability Zone, and Transit Gateway or VPC peering between them. Tag-based firewall rules become security groups attached to network interfaces.

Temporary cross-cloud access. During the move, workloads still in Google Cloud can call AWS without access keys: create an IAM role that trusts accounts.google.com as a web identity provider and call AssumeRoleWithWebIdentity with the service account's ID token.

Landing zone and connectivity

Build the AWS accounts, VPCs, logging and guardrails before moving workloads. Then connect the clouds with HA VPN from a Cloud Router to an AWS virtual private gateway or Transit Gateway, or with Cross-Cloud Interconnect for dedicated bandwidth. Database replication should run over that link, not over the internet.

Move each layer

VMs. AWS Application Migration Service (MGN) supports Compute Engine VMs as source servers. You install the replication agent on each VM, it replicates block devices continuously into a staging area in AWS, and you launch test instances before the real cutover. The source VMs need outbound TCP 443 to the MGN endpoint and TCP 1500 to the replication servers.

Containers. Copy images to ECR with crane copy or skopeo copy. Replace GKE-specific parts: Workload Identity annotations, GKE Ingress or Gateway (use the AWS Load Balancer Controller), pd-balanced storage classes (use the EBS CSI driver with gp3).

Cloud Storage. AWS DataSync in Enhanced mode copies from Cloud Storage to S3 without an agent, using an HMAC key and the XML API. rclone and gcloud storage rsync work for smaller sets. Details in Transferring Data Between AWS S3 and Google Cloud Storage.

Databases. AWS DMS supports Cloud SQL for MySQL and Cloud SQL for PostgreSQL as sources, with a full load followed by change data capture. For MySQL, enable automated backups and point-in-time recovery on the Cloud SQL instance so binary logs exist. For PostgreSQL, set the cloudsql.logical_decoding flag to on. Create the target RDS or Aurora instance yourself, with the same major version or newer.

BigQuery. Export tables to Cloud Storage as Parquet, copy them to S3, then COPY into Redshift or query them in place with Athena:

bq extract --destination_format=PARQUET \
  'my-project:analytics.events' 'gs://my-export-bucket/events/*.parquet'

SQL dialects differ. The AWS Schema Conversion Tool supports BigQuery as a source for Redshift, which helps with schemas and simple queries; scheduled queries and views still need review by hand.

Pub/Sub. Map each topic to SNS with SQS subscriptions for fan-out, or to Kinesis or MSK for ordered streams. Check ordering keys, retention and dead-letter settings one by one.

Cutover

1. Lower DNS TTLs a few days before.
2. Keep storage and databases in sync until the window: repeated DataSync task runs and a running DMS task with CDC.
3. Run the AWS stack in parallel and test it with real requests.
4. At the window: stop writes, wait for DMS latency to drop to zero, run a last DataSync execution, switch application configuration to the AWS endpoints, switch DNS.
5. Keep Google Cloud intact and read-only until the rollback window has passed. Write down beforehand what triggers a rollback and how writes made on AWS would get back.

Data transfer costs

Google Cloud bills the data leaving it. Google offers free data transfer for customers leaving Google Cloud entirely, after an application to Google Cloud Support is approved, and the move then has to finish within a limited window. Apply when the plan is ready, not before.

Checklist

• Asset inventory and billing export, decision per workload.
• AWS accounts, VPCs per region, Identity Center, guardrails.
• HA VPN or Cross-Cloud Interconnect between the clouds.
• VMs with Application Migration Service, images to ECR, EKS manifests adjusted.
• Buckets with DataSync, Cloud SQL with AWS DMS, BigQuery via Parquet exports.
• Lowered TTLs, write freeze, final sync, DNS switch, rollback plan.
• Final exports, then shut down Google Cloud projects.