A GCP→AWS migration is mostly a mapping exercise plus a data-egress problem. This page gives you the full service map (GKE→EKS, Cloud SQL→RDS/Aurora, BigQuery→Redshift/Athena, Pub/Sub→SNS/SQS/EventBridge, and the rest), the networking and IAM model differences that trip teams up, what GCP egress actually costs you on the way out, a phased cutover plan, and how to re-platform your Terraform. The kicker: on a qualifying migration, AWS MAP funds the work and a vetted partner runs it — often at little-to-no cost to you.
Teams leaving Google Cloud usually do it for one of four reasons: AWS is where their enterprise customers and partners already are, they want the breadth of AWS's managed services, they're consolidating after an acquisition, or AWS credits and MAP funding make the economics obvious. Whatever the reason, the work decomposes the same way.
A GCP→AWS migration is three problems stacked on top of each other. The first is a compute and managed-service mapping — almost every GCP primitive has a direct AWS counterpart, so this is mechanical for 80% of your stack. The second is a data-movement problem, dominated by GCP egress pricing and by the fact that BigQuery has no single drop-in AWS equivalent. The third is an identity and networking re-author, because GCP's project-and-IAM model and AWS's account-and-IAM model are different enough that you rebuild rather than translate.
It is not a rewrite. The application code that runs in a container on GKE runs unchanged in a container on EKS; a Python service on Cloud Run runs unchanged on App Runner or ECS Fargate. What changes is the platform plumbing around the code: where secrets come from, how the service authenticates to a database, how a queue is consumed, how an object is read from storage, and how the whole thing is described in infrastructure-as-code. Plan the migration as "remap the platform, keep the app," and the scope stays honest.
The 7 Rs framework AWS uses still applies. Most GCP→AWS workloads land in Rehost (containers move as-is) or Replatform (you swap a managed service for its AWS equivalent and adjust config — Cloud SQL becomes RDS, Pub/Sub becomes SNS+SQS). A smaller set get Refactored selectively after cutover, typically the data layer (BigQuery) and anything that leaned on a GCP-specific feature with no clean analog. Retire and Retain still happen — half of most migrations is discovering services nobody needs anymore.
The rest of this page walks the map service by service, then the networking and IAM differences, then the egress math, then the cutover plan and the IaC re-platform, and finally the gotchas that cost teams a week each if they hit them blind.
This is the core of the migration. For each GCP service you run, here is the AWS equivalent and the one thing that actually changes when you move. The full table is in the comparison section below; this is the narrative for the services that carry the most weight.
GKE → EKS. This is the cleanest move in the whole migration. Your Kubernetes manifests, Helm charts, and container images are portable. What changes: the GKE-specific bits — Workload Identity becomes IAM Roles for Service Accounts (IRSA) on EKS, the GCE ingress controller becomes the AWS Load Balancer Controller (ALB/NLB), GKE Autopilot capacity becomes either managed node groups or Karpenter for autoscaling, and Cloud DNS/Container Registry references repoint to Route 53 and ECR. Most teams stand up the EKS cluster, push images to ECR, re-apply manifests with the controller annotations swapped, and are running in days.
Cloud Run → App Runner or ECS Fargate. Cloud Run's "give me a container, I'll give you a URL and autoscaling-to-zero" model maps to App Runner almost exactly — same mental model, same serverless containers. If you need more networking control, VPC integration, or you're already running EKS/ECS, put the service on ECS Fargate instead. The one behavioral difference to design for: Cloud Run scales to zero by default; App Runner can pause but bills differently, and Fargate does not scale to zero — for spiky low-traffic services, App Runner is the closer fit.
Cloud SQL → RDS or Aurora. Postgres and MySQL on Cloud SQL move to the same engine on Amazon RDS, or to Aurora (Aurora PostgreSQL / Aurora MySQL) if you want the higher-throughput, faster-failover storage engine. This is a homogeneous migration (same engine on both sides), so AWS Database Migration Service (DMS) with ongoing change-data-capture replication handles it with a near-zero-downtime cutover: replicate continuously, then flip the connection string in a short window. No Schema Conversion Tool needed for like-to-like engines.
GCS → S3. Object storage is a near-perfect mapping. Buckets become buckets; the access model changes from GCP IAM bindings to S3 bucket policies + IAM. Move the data with AWS DataSync or the Storage Transfer Service (Google's service can push to S3, AWS's can pull from GCS) — and mind the egress cost, covered below. Repoint your SDK from the GCS client to the S3 client; if your code already speaks the S3 API via an abstraction, this is a config change.
Cloud Functions → Lambda. Event-driven functions map to AWS Lambda. The handler signature changes (GCP's function signature vs. Lambda's event/context), and the trigger wiring changes (a GCS-triggered function becomes an S3-event Lambda; a Pub/Sub-triggered function becomes an SNS/SQS/EventBridge-triggered Lambda). The business logic in the middle is portable. Budget a small rewrite per function for the entry point and the IAM execution role.
Pub/Sub → SNS + SQS + EventBridge. This is the one that surprises people, because Pub/Sub is a single product and AWS splits its job across three. Fan-out pub/sub topics become SNS; durable work queues with a single consumer group become SQS; event routing with content-based rules and schema becomes EventBridge. Most Pub/Sub usage is "publish once, fan out to N subscribers, each with its own backlog" — which on AWS is the canonical SNS→SQS fan-out pattern (one SNS topic, one SQS queue per consumer). Map each topic to that pattern and the semantics line up.
Dataflow → Glue or EMR. Apache Beam pipelines on Dataflow move to AWS Glue (serverless Spark for ETL) or EMR (managed Spark/Hadoop for heavier or more custom jobs). Beam itself can run on a Spark runner, but most teams re-author the transform in Glue/PySpark rather than carry the Beam runner — it's usually less work than it looks for standard ETL. Streaming Beam jobs map to Kinesis Data Analytics / Managed Service for Apache Flink.
Firestore → DynamoDB. Both are serverless NoSQL with on-demand scaling, so the operational model matches well. The data-modeling change is real: Firestore's document/collection model and DynamoDB's single-table partition-key/sort-key model are different, so you redesign the access patterns rather than copy the schema. For real-time listeners (a Firestore strength), you rebuild on DynamoDB Streams + AppSync/WebSockets. This is the NoSQL equivalent of the BigQuery problem — plan for a data-modeling pass, not a dump-and-restore.
Eight of the nine core services are a clean 1:1 remap. The two that need real design work are BigQuery (no single equivalent — it becomes Redshift for the warehouse + Athena for ad-hoc query over S3 + Glue for the catalog/ETL) and Firestore (document model → DynamoDB single-table). Scope those two as their own workstreams and the rest of the migration stays mechanical.
BigQuery is the single service most likely to slow a GCP→AWS migration, because there is no one AWS product that does what it does. BigQuery is a serverless, separation-of-storage-and-compute warehouse with a generous SQL dialect, and AWS answers it with a combination rather than a single box.
The mapping depends on how you use BigQuery. If you run it as a classic data warehouse — modeled tables, BI dashboards, scheduled transforms — the destination is Amazon Redshift (and Redshift Serverless if you want the no-cluster-management feel closest to BigQuery). If you mostly run ad-hoc SQL over raw files and value not managing a warehouse at all, the destination is Amazon Athena querying Parquet/ORC in S3, with the AWS Glue Data Catalog as the metastore. Most real estates use both: Redshift for the modeled, governed layer and Athena for exploration and log-scale data.
The migration itself has two parts. The SQL needs translation — BigQuery's Standard SQL is close to ANSI but has its own functions (e.g., array and struct handling, APPROX_* functions, date/time semantics), so queries and views get ported and tested rather than copied. The data needs to move: export BigQuery tables to Parquet in GCS, transfer to S3, then either COPY into Redshift or register in the Glue catalog for Athena. Parquet matters here for two reasons — it's the efficient columnar format both Redshift and Athena want, and it compresses well, which directly reduces the egress bill on the way out of GCP.
Be honest about effort. A handful of dashboards and a few dozen tables is a one-to-two-week port. A mature BigQuery estate with hundreds of scheduled queries, UDFs, materialized views, and downstream BI dependencies is a multi-month workstream and the critical path of the whole migration. This is exactly the kind of scope where a MAP-funded partner earns their keep: AWS's modernization funding is designed to cover analytics re-platforming, so the warehouse move is often the most heavily funded part of the engagement.
If the service map is the easy 80%, the identity and networking model is the part you re-author. GCP and AWS made different structural choices here, and trying to translate GCP concepts one-for-one into AWS produces a fragile result. Rebuild on AWS idioms instead.
Projects vs. accounts. GCP organizes resources into projects under an organization, and a single VPC can be shared across projects (Shared VPC). AWS organizes resources into accounts under AWS Organizations, and the strong recommendation is multi-account: separate accounts per environment (prod/staging/dev) and per workload, wired together with a landing zone (AWS Control Tower) and centralized via Organizations SCPs. The mental shift is "a GCP project becomes an AWS account," and the network is connected across accounts rather than shared from one.
VPC and networking. Core concepts line up — VPC, subnets, routes, firewall rules → security groups + NACLs — but the differences bite. GCP VPCs are global with regional subnets; AWS VPCs are regional, scoped to one region, with subnets per Availability Zone. GCP firewall rules are network-wide and tag-based; AWS security groups are stateful and attach to ENIs, with NACLs as the stateless subnet-level layer. Cross-VPC/cross-account connectivity that you'd do with VPC Peering or Shared VPC in GCP is typically done with AWS Transit Gateway or PrivateLink. Cloud NAT becomes NAT Gateway; Cloud Load Balancing becomes ELB (ALB/NLB); Cloud DNS becomes Route 53; Cloud CDN becomes CloudFront.
IAM is the big one. GCP IAM grants roles (collections of permissions) to members on a resource hierarchy, and inheritance flows down the org→folder→project→resource tree. AWS IAM is built from policies (JSON documents) attached to users, groups, and roles, with resource-based policies on many services and SCPs as org-wide guardrails. The single most important pattern to internalize: where GCP uses service accounts attached to workloads, AWS uses IAM roles assumed by workloads — an EC2 instance profile, an ECS task role, a Lambda execution role, or IRSA for EKS pods. There are no long-lived keys in the good design; workloads assume roles and get short-lived credentials. Re-author every service account as the corresponding IAM role and you've done the hard part of the identity migration.
Secrets and config. Secret Manager → AWS Secrets Manager (or SSM Parameter Store for plain config). Cloud KMS → AWS KMS. The patterns match; what changes is that access is granted through the IAM roles above rather than through GCP IAM bindings on the secret.
The migration's sleeper cost is data egress. Google charges to move data out of GCP to the internet (and to other clouds), and on a data-heavy estate that one-time exfil is a real number you should price before you start, not discover on the invoice.
GCP general-internet egress runs roughly $0.08–$0.12 per GB in the common tiers (it steps down at volume and varies by destination region; treat these as representative 2026 ranges, not a quote). AWS, importantly, does not charge for data ingress — bringing data in is free — so the egress cost is entirely a GCP-side, one-time expense for the migration window. The practical implications:
On a multi-terabyte move, the math is straightforward and sometimes uncomfortable. Exfiltrating 10 TB at ~$0.10/GB is on the order of $1,000; 50 TB is on the order of $5,000; a large BigQuery + GCS estate in the hundreds of terabytes is a five-figure one-time cost. You reduce it three ways: (1) compress on the wire — export to Parquet/gzip rather than raw CSV/JSON, which routinely cuts volume 3–5×; (2) migrate only what you need — the Retire/Retain triage from phase one directly removes egress GB; and (3) time it as one clean pass rather than repeated re-syncs, each of which re-bills egress.
For the mechanics, use AWS DataSync (it can pull from GCS) or Google's Storage Transfer Service (it can push to S3) for object data, and DMS for databases. For genuinely enormous datasets where even compressed transfer over the network is impractical, AWS Snowball is the physical-shipping fallback, though for most GCP→AWS moves the network path with compression is the right call. The honest planning note: model the egress cost up front as a discrete line item, because it is one of the few migration costs that AWS credits and MAP funding do not erase — MAP funds the AWS-side work, not Google's egress charge. Compression and triage are your levers there.
A clean GCP→AWS cutover is boring on purpose. You run both clouds in parallel, sync data continuously, validate against production traffic, then flip in a short, rehearsed window with a tested rollback. Here is the sequence most CloudRoute-routed migrations follow.
Inventory every GCP service, the data volumes, and the dependencies between them — this is where AWS Application Discovery Service and Migration Hub earn their place. Produce the service map (the table below, specialized to your estate), the egress estimate, and the 7-Rs decision for each workload. Under MAP, this Assess phase is typically funded by AWS and often comes at no cost — it doubles as the TCO/readiness business case.
Stand up the AWS landing zone (Control Tower, multi-account, networking, SSO, guardrails) and migrate one low-risk workload end to end as a pilot — typically a stateless service plus its database. This proves the EKS/ECS path, the DMS replication, and the IAM role model on something real before you touch the crown jewels. MAP's Mobilize phase credits a meaningful share of this work.
Start continuous replication early: DMS with CDC for databases keeps RDS/Aurora in lockstep with Cloud SQL while you work; DataSync moves GCS→S3 incrementally. Bring workloads over in dependency order, run them in parallel against production reads, and validate data integrity and latency. The longer you can run parallel and watch real traffic, the lower the cutover risk.
The actual flip is small because the data is already synced: stop writes briefly (or use a dual-write/queue-drain pattern for near-zero downtime), let replication catch the final delta, repoint DNS in Route 53 to the AWS endpoints, and verify. Keep GCP warm and the DMS replication reversible for a defined window so rollback is a DNS change, not a re-migration. Decommission GCP only after the soak period passes clean.
Your infrastructure-as-code does not port; it gets re-authored. The good news is that the discipline carries over — if your GCP estate is already in Terraform, the migration is "swap the provider and rebuild the resources," not "learn IaC from scratch."
If you run Terraform, you keep Terraform: you swap the google provider for the aws provider and re-express resources against AWS types — google_container_cluster becomes an EKS module, google_sql_database_instance becomes aws_db_instance/aws_rds_cluster, google_storage_bucket becomes aws_s3_bucket, and so on. The state does not migrate; you build fresh AWS state. This is also the natural moment to adopt sane module structure and remote state in S3 + DynamoDB locking if you haven't already. If you used GCP Deployment Manager or gcloud scripts, the equivalent target is Terraform or CloudFormation/CDK — most teams standardize on Terraform for portability.
Re-platform the CI/CD at the same time: Cloud Build pipelines become CodePipeline/CodeBuild or your existing GitHub Actions/GitLab runners pointed at AWS, pushing images to ECR instead of Artifact Registry, and deploying to EKS/ECS. Observability moves too — Cloud Monitoring/Logging (the former Stackdriver) becomes CloudWatch (plus Managed Grafana / OpenSearch if you want richer dashboards). Wire these up in the landing-zone phase so every migrated workload lands into a working pipeline and a working dashboard rather than a bare account.
Everything above is the honest engineering. The reason most teams don't run it themselves is the same reason they don't run their own SOC 2 audit — it's a specialized, time-boxed project that pulls senior engineers off product for months. CloudRoute's job is to make it someone else's project, and to make AWS pay for most of it.
The mechanism is the AWS Migration Acceleration Program (MAP). On a qualifying migration — one with a meaningful AWS-spend commitment after you land — AWS funds the Assess phase (the TCO and readiness assessment, often free), credits a share of the Mobilize phase (landing zone + pilot), and credits a large share of the Migrate & Modernize phase (the production cutover and the BigQuery/Firestore modernization). The partner who does the work is paid through MAP. Net effect: for qualifying migrations, you move from GCP to AWS at little-to-no cost, with the analytics re-platform — usually the most expensive part — among the most heavily funded.
CloudRoute routes you to a vetted AWS partner matched to your stack (Kubernetes-heavy, data-heavy, region) who runs the GKE→EKS cutover, the DMS database migration, the GCS→S3 transfer, the IAM/networking re-author, and the Terraform re-platform — with you reviewing rather than executing. We don't do the migration ourselves and we don't take a fee from you; the partner is paid via MAP, and CloudRoute is paid by the partner. You don't see an invoice from us.
The honest framing matters: MAP funding applies to qualifying migrations only — typically those with a real post-migration AWS spend commitment. If your migration doesn't qualify for MAP, CloudRoute is still useful as a vetted-partner referral that de-risks the cutover — you get a partner who has done dozens of GCP→AWS moves instead of doing your first one live. The MAP funding ties directly to the broader AWS credits picture; see the credits cluster for how the funding pools fit together.
You keep ownership of architecture decisions, the cutover go/no-go, and the final AWS account. The partner runs the execution — EKS stand-up, DMS replication, S3 transfer, IAM re-author, Terraform re-platform, and the rollback plan. On qualifying migrations, AWS MAP funds the partner. Cross-link: $100K AWS credits and AWS POC funding explained for the funding mechanics; AWS landing zone for the account foundation.
The reference table for the whole migration. For each GCP service, the AWS equivalent and the migration tool or pattern you use to move it. The two starred rows are the ones with no clean drop-in equivalent — scope them as their own workstreams.
| GCP service | AWS equivalent | Migration tool / pattern | Difficulty |
|---|---|---|---|
| GKE (Kubernetes) | EKS | Re-apply manifests; Workload Identity → IRSA; ECR for images | Low |
| Cloud Run | App Runner / ECS Fargate | Same container; App Runner for scale-to-zero parity | Low |
| Compute Engine (VMs) | EC2 | AWS Application Migration Service (MGN), agent-based rehost | Low |
| Cloud SQL (Postgres/MySQL) | RDS / Aurora | DMS with CDC (homogeneous — no SCT needed) | Low–Med |
| BigQuery ★ | Redshift + Athena + Glue | Export to Parquet → S3 → COPY/catalog; port SQL | High |
| Cloud Storage (GCS) | S3 | DataSync (pull) or Storage Transfer Service (push) | Low |
| Cloud Functions | Lambda | Re-author handler + trigger wiring; portable logic | Med |
| Pub/Sub | SNS + SQS + EventBridge | SNS→SQS fan-out per consumer; EventBridge for routing | Med |
| Dataflow (Beam) | Glue / EMR (+ Flink for streaming) | Re-author transforms in Glue/PySpark | Med–High |
| Firestore ★ | DynamoDB | Redesign to single-table; Streams + AppSync for realtime | High |
| Cloud Spanner | Aurora / DynamoDB | Depends on access pattern; relational → Aurora | Med–High |
| Memorystore | ElastiCache (Redis/Memcached) | Snapshot/restore or warm-fill | Low |
| Secret Manager | Secrets Manager / SSM | Re-create secrets; grant via IAM roles | Low |
| Cloud KMS | AWS KMS | Re-encrypt with new CMKs | Low |
| Cloud DNS / CDN / LB | Route 53 / CloudFront / ELB | Recreate zones + distributions; DNS flip at cutover | Low |
| Cloud Build | CodePipeline / CodeBuild | Repoint pipelines; push to ECR | Low–Med |
| Cloud Monitoring/Logging | CloudWatch (+ Grafana/OpenSearch) | Re-instrument; rebuild dashboards/alerts | Low–Med |
| IAM (roles/service accounts) | IAM (policies/roles) | Re-author: service account → assumed IAM role | Med |
Situation: Largest customers were AWS-standardized and pushing for AWS residency; the team also wanted off GCP egress-heavy billing and onto AWS for the managed-service breadth. The blocker was the BigQuery estate — 200+ scheduled queries and the BI layer — plus a 45-engineer team with zero spare capacity to run a migration and a hard "no extended downtime" requirement.
What CloudRoute did: Routed within 24 hours to a US-East partner with a Kubernetes + data-warehouse migration track record. Partner ran the MAP Assess (AWS-funded, $0 to the customer) and produced the service map + egress estimate (~38 TB, cut to ~11 TB on the wire via Parquet/gzip + Retire triage). Mobilize stood up a Control Tower landing zone and piloted one GKE service + its Cloud SQL DB to EKS + Aurora. Migrate phase: DMS CDC kept Aurora in lockstep with Cloud SQL for the parallel run; GCS→S3 via DataSync; Pub/Sub→SNS/SQS fan-out; Dataflow re-authored into Glue; BigQuery → Redshift Serverless (modeled layer) + Athena over S3 (ad-hoc). IAM re-authored service-account-by-service-account into IRSA + task roles; Terraform re-platformed from the google to the aws provider.
Outcome: Production cutover on a single 40-minute write-pause window in week 13; rollback held reversible through a two-week soak, then GCP decommissioned. AWS MAP funded the assessment and credited a large share of the migration + the BigQuery modernization — the partner was paid through MAP, and the customer's out-of-pocket migration cost was effectively the GCP egress bill (~$1.1K after compression) plus internal review time. CloudRoute's commission was paid by the partner; the customer paid CloudRoute $0.
cutover window: 40 min · timeline: 13 weeks · data moved: 11 TB (from 38 TB) · MAP-funded share: majority of migrate + modernize · cost to customer: ~$1.1K egress + review time
CloudRoute routes you to an AWS partner who runs the GKE→EKS cutover, the DMS database move, the GCS→S3 transfer, and the BigQuery re-platform. On qualifying migrations, AWS MAP funds the work — you pay little-to-no cost. No procurement, no first-migration-live risk.