🌏 閱讀中文版本
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
- Assessment Phase (1-2 weeks)
- Inventory all AWS resources
- Calculate migration and GCP operational costs
- Identify dependencies
- Pilot Migration (2-4 weeks)
- Choose non-critical services for initial migration
- Validate performance and functionality
- Refine migration process
- Batch Migration (4-12 weeks)
- Migrate by service type in batches
- Keep AWS services running as backup
- Gradually switch traffic
- 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
- Use Infrastructure as Code: Terraform for cross-cloud resource management
- Standardize Naming Conventions: Facilitate resource identification and cost tracking
- Enable Detailed Logging: Use Cloud Logging for centralized management
- Implement Cost Monitoring: Set budget alerts to avoid overruns
- Keep Documentation Updated: Record architecture decisions and configuration details
- 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
- Google Cloud for AWS Professionals
- Migrate to Google Cloud
- GCP Pricing Calculator
- Migration to GCP: Getting Started
Related Articles
- AWS Outage Deep Dive: Multi-Cloud Disaster Recovery Strategies for Architects
- AWS, Azure, and GCP Cloud Certifications Complete Comparison Guide (2025 Latest)
- AWS ALB Multi-Instance Deployment Strategy: A Double-Edged Sword for Large Project Architectures
- Blue-Green and Canary Deployments: Modern System Deployment Strategies
- Choosing AWS Container Services: Kubernetes vs Amazon ECS Complete Comparison Guide