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

Copying data from AWS to Google Cloud is the easy part. The work is in the differences: how IAM is modelled, how networks are scoped, which managed services have a close equivalent and which need a rewrite. This post covers the order that works in practice: inventory, mapping, landing zone, moving each layer, cutover and cleanup.

Start with an inventory

List everything that runs and everything it talks to. AWS Resource Explorer, AWS Config and the Cost and Usage Report grouped by service give a quick picture per account. For VM fleets, Google Cloud Migration Center can collect inventory (with its discovery client or a file import) and produce Compute Engine sizing and cost estimates.

For each workload decide one of four things:

• Rehost: move the VM as it is.
• Replatform: same code, managed target (EC2 with MySQL to Compute Engine with Cloud SQL, EKS to GKE).
• Refactor: rewrite parts that depend on AWS-only services (Lambda triggers, Step Functions, DynamoDB access patterns).
• Retire: switch it off instead of moving it.

While you are at it, grep the code and IaC for hard-coded ARNs, amazonaws.com endpoints, region names and AWS SDK calls. That list is your real refactoring backlog.

AWS to Google Cloud service mapping

Differences that cause most of the surprises

Projects instead of accounts. The unit of isolation is a project, grouped into folders under an organization. Billing, quotas and APIs are per project.

IAM is policy-on-resource. You grant a role to a principal on an organization, folder, project or resource, and grants inherit downwards. There are no IAM policies attached to users in the AWS sense. Workloads use service accounts. During the migration, workloads still in AWS can call Google APIs without keys through Workload Identity Federation with AWS as the identity provider.

The VPC is global. One VPC spans all regions, subnets are regional. Firewall rules live on the VPC and target network tags or service accounts. There are no security groups attached to network interfaces.

Quotas are low on new projects. Request CPU, IP address and GPU quota increases early, not on cutover day.

Build the landing zone first

Create the organization structure, projects, Shared VPC, logging sinks and org policies with Terraform before moving any workload. Then connect the clouds: HA VPN between a Cloud Router and AWS virtual private gateways or Transit Gateway is the quick option, Cross-Cloud Interconnect gives dedicated bandwidth. That private link carries database replication and lets half-migrated systems talk to each other.

Move each layer

VMs. Migrate to Virtual Machines supports AWS as a source. It snapshots the EBS volumes, replicates them into Google Cloud, lets you start test clones, and on cut-over does a final sync and creates the Compute Engine instance with the guest adapted for Google Cloud. It is agentless. If the VMs are already built from Packer images or configuration management, rebuilding on Compute Engine is often cleaner than copying disks. For one-off disk images, use the image import feature of Migrate to Virtual Machines; the older gcloud compute images import tool reached end of life in July 2025.

Containers. Copy images to Artifact Registry, for example with crane copy or skopeo copy. Kubernetes manifests mostly carry over. What changes is everything AWS-specific around them: IRSA or EKS Pod Identity becomes Workload Identity Federation for GKE, the AWS Load Balancer Controller becomes GKE Gateway or Ingress, gp3 storage classes become pd-balanced or Hyperdisk.

Object storage. Use Storage Transfer Service for anything beyond a few hundred gigabytes. It runs incremental re-syncs, so you can copy in bulk weeks ahead and catch up at cutover:

gcloud transfer jobs create s3://my-app-assets gs://my-app-assets \
  --source-creds-file=aws-role.json \
  --overwrite-when=different

The details (federated role, validation, the reverse direction) are in Transferring Data Between AWS S3 and Google Cloud Storage.

Databases. Database Migration Service replicates RDS and Aurora MySQL or PostgreSQL continuously into Cloud SQL or AlloyDB, then promotes the target at cutover. See Migrating MySQL and Amazon RDS to Cloud SQL. Redshift data moves to BigQuery with the BigQuery Data Transfer Service.

Serverless and messaging. Lambda functions become Cloud Run functions or Cloud Run services. The handler code usually needs small changes, the triggers need real work: S3 events become Cloud Storage triggers through Eventarc, SQS consumers become Pub/Sub subscriptions with different ack and retry semantics.

Secrets. Copy them to Secret Manager, then rotate them once the AWS copies are no longer needed.

Cutover with minimal downtime

1. Lower DNS TTLs a few days ahead so the switch propagates in minutes.
2. Keep data in sync: scheduled Storage Transfer Service runs for buckets, continuous DMS jobs for databases.
3. Run the Google Cloud stack in parallel and test it with internal users or synthetic traffic.
4. If the application can run against a single database across clouds, Route 53 weighted records can shift a small share of traffic first. With one writer per database that only works over the private link and with the latency it adds, so many teams switch in one step instead.
5. At the window: stop writes, wait for replication lag to reach zero, run a last storage sync, promote the database, switch DNS.
6. Watch error rates, latency and logs closely for the first hours.

Decide in advance what triggers a rollback and how writes made on Google Cloud after cutover would be carried back. Keep the AWS side intact and read-only until that window has passed.

Decommission

Take final snapshots or exports of anything you might need later, then delete resources in AWS from the top down: DNS, load balancers, compute, databases, storage, networking. Data transfer out of AWS is billed by AWS. When you leave AWS completely, AWS Support can approve credits for the final data transfer out; request it before the bulk copy, not after.

Checklist

• Inventory, dependency map and a rehost, replatform, refactor or retire decision per workload.
• Service mapping with owners for every item that needs a rewrite.
• Landing zone in Terraform, quotas raised, HA VPN or Interconnect to AWS.
• VMs with Migrate to Virtual Machines, containers to Artifact Registry and GKE.
• Buckets with Storage Transfer Service, databases with Database Migration Service.
• Lowered TTLs, write freeze, final sync, promote, DNS switch, rollback plan.
• Final exports, then delete AWS resources.