GCP to AWS migrations happen for all kinds of reasons. Sometimes it's cost optimization after a surprise billing spike. Sometimes a large enterprise client requires their vendors to run on AWS. Sometimes it's access to a specific service — a Bedrock foundation model, an AWS Marketplace product, or a compliance certification that's only available on one platform. Whatever the reason, if you're planning this migration, know that the path is more nuanced than most guides let on.
We've migrated three production environments from Google Cloud to AWS in the past year. This guide is what we wish we had before we started.
Why Teams Switch from GCP to AWS
AWS remains the dominant cloud platform by market share, and enterprise procurement decisions often follow that gravity. A few drivers we see regularly:
- Enterprise procurement requirements — Large clients with existing AWS Enterprise Agreements want all vendors on the same platform to simplify billing and security reviews.
- AWS-specific services — Amazon Bedrock's model catalog, specific Marketplace offerings, or AWS-native compliance certifications (FedRAMP, HIPAA BAAs) that aren't available on GCP.
- Partner ecosystem depth — AWS's partner and tooling ecosystem is larger, which matters for teams hiring engineers with existing cloud certifications.
- Cost optimization — Depending on your workload mix, one platform may offer materially better pricing. This requires careful analysis, not assumptions.
Service Mapping — What Replaces What
The first thing your team needs is a clear mapping from your current GCP services to their AWS equivalents. Many are near-identical; some require rethinking your architecture.
| GCP Service | AWS Equivalent | Notes |
|---|---|---|
| Cloud Storage | S3 | Near-identical APIs; use gsutil → aws s3 cp |
| BigQuery | Redshift / Athena | BigQuery = serverless; Athena closer for ad-hoc, Redshift for warehouse |
| Cloud Run | ECS Fargate / Lambda | Container workloads vs. functions |
| GKE | EKS | Both managed Kubernetes; EKS has more enterprise tooling |
| Cloud Pub/Sub | SQS / SNS / Kinesis | Match on use case: fan-out vs. streaming |
| Cloud Functions | AWS Lambda | Near-equivalent |
| Cloud SQL | RDS | MySQL/Postgres fully compatible |
| Artifact Registry | ECR | Docker image storage |
The Migration Phases
Every migration is different, but the phases are usually the same. Rushing any of these is how you end up with a production incident at 2am on a Tuesday.
Phase 1: Audit and Inventory
You can't migrate what you haven't mapped. Start by generating a complete inventory of your GCP resources. Tools like CloudQuery make this easy:
# List all GCP resources across projects using gcloud
gcloud asset search-all-resources \
--scope="projects/your-project-id" \
--format="csv(name,assetType,location)" \
> gcp_inventory.csv
# Or use CloudQuery for a structured inventory
cloudquery sync gcp.hcl --no-ansi 2>&1 | tee migration_audit.log
Document every resource, its dependencies, and its traffic patterns. Pay special attention to services with stateful data — databases, object storage, Pub/Sub subscriptions.
Phase 2: Network and IAM Setup in AWS
Before any workload moves, your AWS environment needs to be ready. This means VPCs with correct CIDR blocks (design for future peering), security groups mirroring your GCP firewall rules, IAM roles for each workload, and — critically — a Terraform module that encodes all of this as code. Never click your way through network setup in a migration; you'll make mistakes you can't reproduce.
Phase 3: Data Migration Strategy
Three approaches, each suited to different situations:
- Live migration — Replicate data continuously while both environments run in parallel. Highest complexity, lowest downtime.
- Cutover — Schedule a maintenance window, stop writes, migrate data, flip DNS. Simple, but requires downtime.
- Dual-write — Application writes to both GCP and AWS simultaneously during the transition period. Works well for event-driven systems.
Phase 4: Workload Migration Order
Always migrate stateless services first. They're easiest to test, easiest to roll back, and failure is less catastrophic. Move your API servers, background workers, and scheduled jobs before you touch your databases. Once stateless workloads are validated on AWS, migrate your databases with a tested rollback plan in hand.
Phase 5: DNS Cutover and Traffic Shifting
Use weighted routing in Route 53 to shift traffic gradually — 5%, then 25%, then 50%, then 100%. Monitor your error rates, latency p99, and business metrics at each step. Keep your GCP environment alive for at least two weeks after full cutover in case you need to roll back.
The Parts Nobody Talks About
IAM Mental Model Shift
GCP uses service accounts everywhere — a service account is a Google identity that your workload assumes. AWS has IAM roles, but the mapping isn't 1:1. On AWS, EC2 instances use instance profiles, Lambda functions use execution roles, ECS tasks use task roles, and there's a separate concept of trust policies governing who can assume a role. Teams that don't invest time understanding this distinction end up with either over-permissioned resources or hard-to-debug access-denied errors.
Networking Differences
GCP uses a global VPC model — a single VPC spans all regions. AWS uses a regional VPC model — each VPC lives in one region, and cross-region communication requires VPC peering, Transit Gateway, or the public internet. If your GCP architecture relied on global VPC networking, you'll need to re-architect your network topology for AWS's regional model. This is often the most time-consuming part of a migration.
Cost Surprises
Data egress from GCP is not free, and migrating terabytes of data out of Google Cloud during your migration window can generate a significant unexpected bill. Calculate your egress costs upfront, negotiate with Google if the volume is large enough, and plan your migration window to minimize the data that needs to move in real time.
Tools That Help
A few tools we've found indispensable:
- Terraform — Cloud-agnostic IaC makes the migration dramatically smoother. If you're not already using Terraform, this migration is the forcing function.
- CloudQuery — Open-source cloud asset inventory tool that supports both GCP and AWS. Essential for the audit phase.
- AWS Migration Hub — Tracks migration progress across services in a single dashboard.
- Migrate for Compute Engine — Google's own tool for migrating VMs to other clouds, including AWS.
GCP to AWS migrations are achievable, but they're not a weekend project. The teams that do it well are the ones who treat it as an engineering initiative — with planning, phased execution, and a clear rollback strategy at every step.