Google Cloud to AWS: the service-by-service migration.

IWhat a GCP to AWS migration is, and is not

Teams usually leave Google Cloud because their customers or partners standardise on AWS, they want AWS's service breadth, or they are consolidating after an acquisition. The work breaks down the same way each time.

It is three problems stacked together: a service mapping (mechanical for most of the stack), a data move (shaped by transfer costs and by BigQuery), and an identity and networking re-author (GCP projects and AWS accounts are built differently).

It is not a rewrite. A container on GKE runs unchanged on EKS. What changes is the plumbing: where secrets come from, how a service authenticates to a database, how queues are consumed, and how the infrastructure is described in code. Plan it as "remap the platform, keep the app."

Most workloads land as Rehost (containers move as they are) or Replatform (swap a managed service for its AWS equivalent). BigQuery and anything leaning on a GCP-only feature get Refactored. Retiring unused services cuts both scope and transfer cost.

IIThe GCP to AWS service map

For the services that carry the most weight, here is the AWS target and what actually changes. The full table is further down.

GKE to EKS. Manifests, Helm charts and images are portable. Workload Identity becomes IAM Roles for Service Accounts (IRSA) or EKS Pod Identity, the GKE ingress becomes the AWS Load Balancer Controller, Autopilot capacity becomes managed node groups or Karpenter, and image references move to ECR.

Cloud Run to ECS on Fargate. The closest "container in, URL out" option for new AWS customers is Amazon ECS Express Mode, which creates the Fargate service, load balancer and scaling for you. (App Runner closed to new customers on April 30, 2026.) Fargate keeps at least one task running; if you depend on scale-to-zero, Lambda with a container image is the closer fit.

Cloud SQL to RDS or Aurora. Same engine on both sides, so no schema conversion. AWS DMS supports Cloud SQL for MySQL and PostgreSQL as sources: a full load, then ongoing change data capture (CDC) so RDS stays in sync while you test. For PostgreSQL CDC, turn on logical decoding on Cloud SQL first. Cutover is a short pause to drain changes and repoint the connection string.

GCS to S3. Buckets map to buckets; GCP IAM bindings become S3 bucket policies plus IAM. Move data with AWS DataSync (pulls from GCS) or Google's Storage Transfer Service (pushes to S3).

Cloud Functions to Lambda. The handler signature and trigger wiring change; the logic in the middle is portable.

Pub/Sub to SNS, SQS and EventBridge. Most Pub/Sub use is "publish once, fan out to several subscribers, each with its own backlog". On AWS that is one SNS topic with one SQS queue per consumer. Use EventBridge when you need content-based routing.

Dataflow to Glue or EMR. Batch Beam pipelines are usually re-authored in Glue (PySpark) or run on EMR. Streaming jobs map to Amazon Managed Service for Apache Flink.

Firestore to DynamoDB. Both are serverless NoSQL, but the data models differ, so you redesign around access patterns. Real-time listeners are rebuilt on DynamoDB Streams with AppSync or WebSockets.

IIIBigQuery has no drop-in equivalent

BigQuery is the service most likely to slow the migration. AWS answers it with a combination rather than one product.

A modelled warehouse (governed tables, BI dashboards, scheduled transforms) lands on Amazon Redshift, or Redshift Serverless for the no-cluster feel. Ad-hoc SQL over raw files lands on Amazon Athena over Parquet in S3, with the AWS Glue Data Catalog as the metastore. Most estates use both.

Two jobs: translate the SQL (BigQuery has its own functions and array and struct handling, so port and test queries rather than copy them), and move the data (export tables to Parquet in GCS, transfer to S3, then COPY into Redshift or register in Glue for Athena). Parquet is the format both targets want and it compresses well.

A few dashboards and dozens of tables is a short port. Hundreds of scheduled queries, UDFs and BI dependencies make it the critical path of the whole migration. Scope it as its own workstream.

IVNetworking and IAM: where the models differ

If the service map is the easy part, identity and networking are what you rebuild. Translating GCP concepts one-for-one produces a fragile AWS design.

• GCP project to AWS account: Use a multi-account setup from day one (AWS Organizations and Control Tower), with separate accounts per environment and workload. Do not recreate one big project as one big account.
• Service account to IAM role: GCP attaches service accounts to workloads. On AWS, workloads assume IAM roles for short-lived credentials: an instance profile, ECS task role, Lambda role, or IRSA for pods. Avoid long-lived keys.
• Global VPC to regional VPC: GCP VPCs are global with regional subnets. AWS VPCs are regional with subnets per Availability Zone. Cross-account links use Transit Gateway or PrivateLink instead of Shared VPC.
• Firewall rules to security groups and NACLs: Security groups are stateful and attach to network interfaces; NACLs are stateless at the subnet edge. Translate tag-based rules into security-group references.
• Org policies to SCPs: Service Control Policies enforce org-wide limits. Set them up in the landing zone. Secret Manager becomes AWS Secrets Manager and Cloud KMS becomes AWS KMS, with access granted through the IAM roles above.

VData transfer out of GCP, and how to avoid paying it

Moving data out of Google Cloud is billed per GB. On a data-heavy estate it is a real number, so plan it before you start. AWS does not charge for data coming in.

Google's exit program. Google offers free data transfer when you exit a Google Cloud service entirely. You submit an Exit Notice before migrating, start within the set initiation period, finish in the migration period, then file a Completion Notice; the transfer cost is credited on your final invoice for that service. Partial moves do not qualify, and the agreement for the service you leave ends.

If you do not use the program (for example, you keep part of a service on GCP), cut the bill three ways: export to Parquet or gzip instead of raw CSV or JSON, move only what you still need, and do one clean pass instead of repeated re-syncs.

Tools: AWS DataSync or Google's Storage Transfer Service for objects, AWS DMS for databases, and, for datasets too large for the network, AWS Data Transfer Terminal (AWS Snowball Edge is no longer open to new customers).

VIThe phased cutover plan

A clean cutover is boring on purpose: run both clouds in parallel, sync data continuously, validate, then switch in a short, rehearsed window with a tested rollback.

VIIRe-platforming the IaC, and the gotchas

Infrastructure code does not port; it gets re-authored. If you already use Terraform, you keep Terraform and swap providers.

Swap the google provider for aws and re-express resources: google_container_cluster becomes an EKS module, google_sql_database_instance becomes aws_db_instance or aws_rds_cluster, google_storage_bucket becomes aws_s3_bucket. State does not migrate; you build fresh AWS state. Cloud Build becomes CodePipeline and CodeBuild (or your GitHub Actions pointed at AWS), Artifact Registry becomes ECR, and Cloud Monitoring and Logging become CloudWatch.

• Do not copy the network design: GCP's global VPC habits make a poor AWS design. Use regional VPCs, Transit Gateway and a proper multi-account layout.
• Budget for the IAM re-author: Every workload needs its own role and least-privilege policy. It is real work, not find-and-replace.
• BigQuery and Firestore are workstreams: Give them their own plans and timelines. They are usually the critical path.
• Plan data transfer up front: Decide early whether you will use Google's exit program, because it has to be filed before the move.
• Keep rollback real until the soak passes: Leave GCP running and replication reversible for a defined window.

VIIIWho runs the migration, and who can fund it

Everything above is doable in-house. Most teams do not, because it pulls senior engineers off product for months.

A vetted AWS partner matched to your stack (Kubernetes-heavy, data-heavy, your Region) can run the GKE to EKS cutover, the DMS database move, the GCS to S3 transfer, the IAM and networking re-author and the Terraform re-platform, with you reviewing rather than executing.

Partner-filed funding: the AWS Migration Acceleration Program (MAP) helps offset initial migration costs across its Assess, Mobilize and Migrate and Modernize phases. Your matched partner files it when the migration qualifies and AWS approves. For startups this is typically $50K to $150K. Depends on the workload; AWS approves. MAP covers AWS-side work, not Google's data transfer charges.

AWS Activate: 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 VC, accelerator or angel group, if it is an Activate Provider. A consulting partner cannot file Activate for you.