AWS to GCP Architecture Migration Complete Guide: Service Mapping, Migration Strategy & Implementation

🌏 閱讀中文版本


AWS to GCP Architecture Migration Complete Guide: Service Mapping, Migration Strategy & Implementation

Introduction

In today’s multi-cloud era, migrating from AWS to Google Cloud Platform (GCP) is a technical challenge many enterprises face. This article explores service mapping between both platforms, network architecture differences, IAM permission management conversion, and provides practical migration steps with code examples.

Why Migrate from AWS to GCP?

Key reasons for enterprises migrating from AWS to GCP:

  • Cost Optimization: GCP offers Sustained Use Discounts without upfront commitments
  • Data Analytics Advantage: BigQuery provides powerful data warehousing and analytics capabilities
  • Native Kubernetes Support: GKE (Google Kubernetes Engine) is the industry’s most mature Kubernetes service
  • Machine Learning Tools: Better integration with TensorFlow, Vertex AI, and other AI/ML tools
  • Global Network Infrastructure: Google’s dedicated network provides lower latency

Core Service Mapping Table

Compute Services

AWS Service GCP Equivalent Key Differences
EC2 (Elastic Compute Cloud) Compute Engine GCP offers custom machine types for precise CPU/memory ratio adjustment
Lambda Cloud Functions / Cloud Run Cloud Run supports containers, more flexible
ECS (Elastic Container Service) GKE (Google Kubernetes Engine) GKE is fully managed Kubernetes
Elastic Beanstalk App Engine App Engine offers standard and flexible environments

Storage Services

AWS Service GCP Equivalent Key Differences
S3 (Simple Storage Service) Cloud Storage GCP provides simplified storage classes
EBS (Elastic Block Store) Persistent Disk GCP Persistent Disk supports dynamic resizing
EFS (Elastic File System) Filestore Both are fully managed NFS

Database Services

AWS Service GCP Equivalent Key Differences
RDS (Relational Database Service) Cloud SQL Cloud SQL supports MySQL, PostgreSQL, SQL Server
DynamoDB Firestore / Bigtable Firestore for document data, Bigtable for large-scale time-series data
Aurora Cloud Spanner Cloud Spanner is globally distributed SQL database
Redshift BigQuery BigQuery is serverless data warehouse, pay-per-query

Network Services

AWS Service GCP Equivalent Key Differences
VPC (Virtual Private Cloud) VPC Network GCP VPC is global, not region-limited
Route 53 Cloud DNS Both are managed DNS services
CloudFront Cloud CDN Cloud CDN integrates with Google’s global network
Direct Connect Cloud Interconnect Provides dedicated network connectivity
ELB (Elastic Load Balancer) Cloud Load Balancing GCP offers global load balancing

Network Architecture Migration: VPC and Firewall Rules

AWS VPC vs GCP VPC Architecture Differences

AWS VPC:

  • VPC limited to single region
  • Subnets limited to single Availability Zone
  • Security Groups per instance, Stateful
  • Network ACL per subnet, Stateless

GCP VPC:

  • VPC is global resource, spans all regions
  • Subnets are regional, span all zones in region
  • Firewall rules set at VPC level, apply to all instances
  • Use Network Tags for precise rule targeting

Firewall Rules Conversion Example

AWS Security Group Example:

# AWS CLI - Create Security Group
aws ec2 create-security-group 
  --group-name web-server-sg 
  --description "Allow HTTP and HTTPS traffic" 
  --vpc-id vpc-1234567890abcdef0

# Allow HTTP (port 80) from any IP
aws ec2 authorize-security-group-ingress 
  --group-id sg-1234567890abcdef0 
  --protocol tcp 
  --port 80 
  --cidr 0.0.0.0/0

# Allow HTTPS (port 443) from any IP
aws ec2 authorize-security-group-ingress 
  --group-id sg-1234567890abcdef0 
  --protocol tcp 
  --port 443 
  --cidr 0.0.0.0/0

GCP Firewall Rules Equivalent:

# GCP - Create firewall rules (using network tags)
gcloud compute firewall-rules create allow-http 
  --network=default 
  --allow=tcp:80 
  --source-ranges=0.0.0.0/0 
  --target-tags=web-server

gcloud compute firewall-rules create allow-https 
  --network=default 
  --allow=tcp:443 
  --source-ranges=0.0.0.0/0 
  --target-tags=web-server

# Create VM instance with network tag
gcloud compute instances create web-vm 
  --zone=asia-east1-a 
  --machine-type=n1-standard-1 
  --tags=web-server

Compute Instance Migration

From AWS EC2 to GCP Compute Engine

AWS EC2 Launch Example:

# Launch AWS EC2 instance
aws ec2 run-instances 
  --image-id ami-0c55b159cbfafe1f0 
  --instance-type t3.medium 
  --key-name my-key-pair 
  --security-group-ids sg-1234567890abcdef0 
  --subnet-id subnet-1234567890abcdef0 
  --associate-public-ip-address 
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=web-server}]'

GCP Compute Engine Equivalent:

# Launch GCP Compute Engine instance
gcloud compute instances create web-server 
  --zone=asia-east1-a 
  --machine-type=n1-standard-2 
  --image-family=ubuntu-2004-lts 
  --image-project=ubuntu-os-cloud 
  --boot-disk-size=50GB 
  --boot-disk-type=pd-standard 
  --network-interface=network=default,subnet=default 
  --metadata=ssh-keys="user:$(cat ~/.ssh/id_rsa.pub)" 
  --tags=web-server 
  --labels=environment=production,app=web

IAM Permission Management Migration

AWS IAM vs GCP IAM Architecture Differences

AWS IAM:

  • Uses Policies to define permissions
  • Can attach to Users, Groups, Roles
  • Supports Inline and Managed Policies
  • Uses ARN (Amazon Resource Name) for resource identification

GCP IAM:

  • Uses Roles to define permission sets
  • Permissions bound directly to resources (projects, folders, organizations)
  • Uses Service Accounts for application authentication
  • Hierarchical permission inheritance (Organization → Folder → Project → Resource)

IAM Policy Conversion Example

AWS IAM Policy (Allow S3 Read):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket/*",
        "arn:aws:s3:::my-bucket"
      ]
    }
  ]
}

GCP IAM Binding (Equivalent Permission):

# Grant Service Account Cloud Storage read permission
gcloud projects add-iam-policy-binding my-project-id 
  --member="serviceAccount:my-app@my-project-id.iam.gserviceaccount.com" 
  --role="roles/storage.objectViewer"

# Or for specific Bucket
gsutil iam ch 
  serviceAccount:my-app@my-project-id.iam.gserviceaccount.com:objectViewer 
  gs://my-bucket

Database Migration: From AWS RDS to GCP Cloud SQL

Migration Steps

Step 1: Create Cloud SQL Instance

# Create Cloud SQL instance in GCP
gcloud sql instances create mydb-instance 
  --database-version=MYSQL_8_0 
  --tier=db-n1-standard-2 
  --region=asia-east1 
  --network=default 
  --no-assign-ip

# Create database
gcloud sql databases create mydb 
  --instance=mydb-instance

# Create user
gcloud sql users create myuser 
  --instance=mydb-instance 
  --password=mypassword

Step 2: Export Data from AWS RDS

# Create snapshot in AWS RDS
aws rds create-db-snapshot 
  --db-instance-identifier mydb 
  --db-snapshot-identifier mydb-snapshot-20240114

# Export to S3
aws rds start-export-task 
  --export-task-identifier mydb-export 
  --source-arn arn:aws:rds:us-east-1:123456789012:snapshot:mydb-snapshot-20240114 
  --s3-bucket-name mydb-exports 
  --iam-role-arn arn:aws:iam::123456789012:role/rds-s3-export-role 
  --kms-key-id arn:aws:kms:us-east-1:123456789012:key/abcd1234-a123-456a-a12b-a123b4cd56ef

Step 3: Transfer to GCP and Import

# Copy from S3 to Cloud Storage
gsutil -m cp -r s3://mydb-exports gs://mydb-migration/

# Import to Cloud SQL
gcloud sql import sql mydb-instance 
  gs://mydb-migration/export.sql 
  --database=mydb

Storage Migration: From AWS S3 to GCP Cloud Storage

Using Storage Transfer Service

# Create Cloud Storage Bucket
gsutil mb -c standard -l asia-east1 gs://my-gcp-bucket/

# Use gsutil to copy directly
gsutil -m cp -r s3://my-aws-bucket/* gs://my-gcp-bucket/

# Set Bucket permissions
gsutil iam ch 
  serviceAccount:my-app@my-project-id.iam.gserviceaccount.com:objectViewer 
  gs://my-gcp-bucket

Migration Strategy Recommendations

Phased Migration

  1. Assessment Phase (1-2 weeks)
    • Inventory all AWS resources
    • Calculate migration and GCP operational costs
    • Identify dependencies
  2. Pilot Migration (2-4 weeks)
    • Choose non-critical services for initial migration
    • Validate performance and functionality
    • Refine migration process
  3. Batch Migration (4-12 weeks)
    • Migrate by service type in batches
    • Keep AWS services running as backup
    • Gradually switch traffic
  4. Optimization Phase (Ongoing)
    • Adjust resource allocation
    • Enable GCP-specific features
    • Cost optimization

Frequently Asked Questions

Q1: How to ensure zero downtime during migration?

A: Use bidirectional sync strategy:

  • Use DMS (Database Migration Service) for real-time database replication
  • Use DNS traffic switching (Route 53 → Cloud DNS)
  • Switch read traffic first, then write traffic after verification

Q2: Are there significant network latency differences between AWS and GCP?

A: Based on real-world testing:

  • Similar latency within same region (1-2ms)
  • GCP’s global network typically has lower latency for cross-region communication (due to dedicated Google fiber)
  • Recommend using Cloud Interconnect for on-premises connectivity

Q3: How much cost difference can be expected?

A: Varies by workload:

  • Compute costs: GCP typically 10-30% lower (due to sustained use discounts)
  • Storage costs: Similar, but GCP’s Nearline/Coldline are cheaper
  • Data transfer: GCP egress fees typically lower
  • Recommend using cost calculator for actual estimates

Q4: Is code rewriting necessary?

A: Depends on services used:

  • Infrastructure layer (VM, Storage): No code changes needed
  • PaaS services (Lambda → Cloud Functions): Requires adjustments
  • Database layer: If using standard SQL, minimal impact
  • Recommend using Terraform for infrastructure management, easier cross-cloud deployment

Q5: How to handle AWS-specific services (like DynamoDB)?

A: GCP alternatives:

  • DynamoDB → Firestore (document) or Bigtable (wide-column)
  • Requires adjusting data model and query logic
  • Recommend using data abstraction layer (DAO Pattern) to reduce migration impact

Best Practice Recommendations

  1. Use Infrastructure as Code: Terraform for cross-cloud resource management
  2. Standardize Naming Conventions: Facilitate resource identification and cost tracking
  3. Enable Detailed Logging: Use Cloud Logging for centralized management
  4. Implement Cost Monitoring: Set budget alerts to avoid overruns
  5. Keep Documentation Updated: Record architecture decisions and configuration details
  6. Regular Disaster Recovery Drills: Ensure backup and recovery processes work

Conclusion

Migrating from AWS to GCP is a systematic engineering effort requiring detailed planning and testing. Key success factors include:

  • Deep understanding of architectural differences between platforms
  • Clear migration plan and timeline
  • Using appropriate tools and services (DMS, Storage Transfer Service)
  • Adopting phased migration strategy to reduce risk
  • Continuously optimizing resource allocation and costs

Through this article’s service mapping tables, code examples, and best practices, you can more confidently complete your AWS to GCP architecture migration.

Reference Resources

Related Articles

Leave a Comment