Migrating from Google Cloud to AWS: Service Mapping and Guide

Teams migrating from Google Cloud Platform to AWS are usually solving a specific problem, not abandoning GCP entirely. The most common drivers: hiring AWS-certified engineers is easier in most markets, a key enterprise customer requires AWS, a specific AWS service (Bedrock, SES, or a compliance certification) is unavailable on GCP, or an acquisition is forcing platform consolidation.

This guide is written for DevOps engineers and engineering managers who need a realistic picture of what changes, what stays the same, and where the genuine complexity lies. We are an AWS Select Tier Consulting Partner — we will be direct about both platforms’ strengths.

GCP to AWS Service Mapping

The BigQuery Decision

BigQuery is the most technically complex part of a GCP-to-AWS migration. It is a single service that does several things at once: it stores data, runs serverless SQL at petabyte scale, handles streaming ingestion, and provides a query interface — all without you managing infrastructure.

AWS splits this across two services:

Amazon Redshift is a provisioned (or serverless) data warehouse. Use it for structured, recurring analytical workloads: BI dashboards, scheduled reports, aggregation pipelines. Redshift Spectrum lets Redshift query S3 data directly without loading it, which partially bridges the gap.

Amazon Athena is serverless SQL on S3. Use it for ad-hoc queries on raw or semi-structured data stored in S3. You pay per query scanned ($5/TB), with no cluster to provision or maintain.

The migration decision: if you use BigQuery mostly for a structured data warehouse with known schemas, Redshift is the primary target. If you use BigQuery heavily for ad-hoc exploration of raw event logs or JSON data, Athena may be a better fit — possibly alongside Redshift for structured layers.

Teams should expect to spend 30–50% of the migration effort on this analytics layer.

Pricing Model Differences

GCP and AWS take different approaches to compute discounts, and the difference matters for budget planning.

GCP Sustained Use Discounts are automatic. Run a VM for more than 25% of a month and GCP starts discounting the excess hours — no commitment required. At 100% utilization, the discount reaches ~30%.

AWS Savings Plans and Reserved Instances require an upfront commitment (1 or 3 years). In return, discounts reach 40–72% off on-demand pricing. If you have predictable baseline capacity, AWS committed pricing beats GCP’s automatic discounts. If your workloads are highly variable, GCP’s no-commitment model can be more efficient.

For teams migrating to AWS, the right approach is: run on-demand for the first 60–90 days to establish a usage baseline, then purchase Savings Plans for the predictable portion of your compute.

Container Migration: GKE to EKS

Kubernetes manifests are portable — your Deployments, Services, and ConfigMaps will work on EKS. The non-portable pieces:

• Node pools: GKE node pools and EKS managed node groups are similar in concept. If you use GKE Autopilot (no node management), the AWS equivalent is EKS with Karpenter, which provisions nodes automatically. Karpenter requires configuration that Autopilot does not.
• Ingress: Replace the GKE Ingress controller with the AWS Load Balancer Controller.
• Storage classes: Replace GCP Persistent Disk CSI driver with the AWS EBS CSI driver for block storage, or EFS CSI driver for shared file storage.
• Workload Identity: Replace GCP Workload Identity with EKS IAM Roles for Service Accounts (IRSA) or EKS Pod Identity.

Plan one to two weeks for the Kubernetes migration if your cluster is medium-sized (20–50 nodes). Larger clusters with many workloads take longer, primarily for testing.

Migration Approach

Phase 1 — Inventory (Week 1): Document all GCP services in use. Map each to the AWS equivalent using the table above. Identify GCP-specific dependencies (Pub/Sub schemas, BigQuery views, GKE Autopilot assumptions).

Phase 2 — Foundation (Week 1–2): Provision AWS VPC, subnets, IAM roles, and ECR repositories using Terraform. Mirror your GCP project/network structure.

Phase 3 — Compute and Containers (Week 2–4): Migrate GKE workloads to EKS. Deploy application containers to ECS Fargate or EKS. Validate networking, secrets management (replace Secret Manager with AWS Secrets Manager), and logging (replace Cloud Logging with CloudWatch Logs or OpenSearch).

Phase 4 — Databases (Week 3–5): Use AWS DMS to replicate Cloud SQL databases to RDS. For Firestore/Datastore workloads migrating to DynamoDB, plan for schema design differences — DynamoDB’s single-table design patterns differ meaningfully from Firestore’s collection/document model.

Phase 5 — Analytics (Week 5–10): Migrate BigQuery datasets to Redshift and/or Athena. This is the longest phase. Migrate transformation pipelines (dbt, Dataform) to work against Redshift. Redirect streaming ingestion from Pub/Sub to Kinesis Data Streams or SQS.

What GCP Does Better

Honest trade-offs worth naming:

• BigQuery simplicity. One service, no sizing decisions, serverless from the start. The Redshift + Athena split requires architectural judgment that BigQuery eliminates.
• GKE Autopilot. Truly zero-node-management Kubernetes. EKS with Karpenter is powerful but requires more operator knowledge.
• Google-native AI models. If your use case specifically requires Gemini models via Vertex AI, that has no AWS equivalent.
• Sustained use discounts without commitment. Useful for variable or unpredictable workloads.

When AWS Wins

• You need access to Bedrock’s multi-model LLM catalog (Anthropic Claude, Meta Llama, Mistral, and more) without managing model endpoints.
• Broader compliance certification coverage, including FedRAMP High and DoD IL5 regions (AWS GovCloud).
• The AWS partner and marketplace ecosystem — more ISVs, more certified engineers, more tooling integrations.
• Graviton instances for Linux compute at lower cost than equivalent GCP instance types.
• SES for high-volume email delivery with no GCP equivalent.

Ready to Migrate?

FactualMinds handles GCP-to-AWS migrations end to end — from infrastructure provisioning and database migration to BigQuery re-architecture and EKS cluster setup.

Talk to our team about your GCP migration or learn more about our AWS Migration service.