AWS 到 GCP 架構轉換完整指南：服務對應、遷移策略與實踐
前言
在當今多雲策略盛行的時代，從 AWS 遷移到 Google Cloud Platform (GCP) 是許多企業面臨的技術挑戰。本文將深入探討兩個平台的服務對應關係、網路架構差異、IAM 權限管理轉換，並提供實際的遷移步驟與程式碼範例。
為什麼要從 AWS 遷移到 GCP？
企業考慮從 AWS 遷移到 GCP 的主要原因包括：
- 成本優化：GCP 提供持續使用折扣 (Sustained Use Discounts)，無需預先承諾
- 數據分析優勢：BigQuery 提供強大的數據倉儲和分析能力
- Kubernetes 原生支援：GKE (Google Kubernetes Engine) 是業界最成熟的 Kubernetes 服務
- 機器學習工具：TensorFlow、Vertex AI 等 AI/ML 工具整合更完善
- 全球網路基礎設施：Google 的專用網路提供更低延遲
核心服務對應表
運算服務
| AWS 服務 | GCP 對應服務 | 主要差異 |
|---|---|---|
| EC2 (Elastic Compute Cloud) | Compute Engine | GCP 提供自定義機器類型，可精確調整 CPU/記憶體比例 |
| Lambda | Cloud Functions / Cloud Run | Cloud Run 支援容器，更靈活 |
| ECS (Elastic Container Service) | GKE (Google Kubernetes Engine) | GKE 是完全託管的 Kubernetes |
| Elastic Beanstalk | App Engine | App Engine 有標準和彈性環境兩種選擇 |
儲存服務
| AWS 服務 | GCP 對應服務 | 主要差異 |
|---|---|---|
| S3 (Simple Storage Service) | Cloud Storage | GCP 提供更簡化的儲存類別 |
| EBS (Elastic Block Store) | Persistent Disk | GCP 的 Persistent Disk 可動態調整大小 |
| EFS (Elastic File System) | Filestore | 兩者都是完全託管的 NFS |
資料庫服務
| AWS 服務 | GCP 對應服務 | 主要差異 |
|---|---|---|
| RDS (Relational Database Service) | Cloud SQL | Cloud SQL 支援 MySQL, PostgreSQL, SQL Server |
| DynamoDB | Firestore / Bigtable | Firestore 適合文件型資料，Bigtable 適合大量時序資料 |
| Aurora | Cloud Spanner | Cloud Spanner 是全球分散式 SQL 資料庫 |
| Redshift | BigQuery | BigQuery 是無伺服器資料倉儲，按查詢計費 |
網路服務
| AWS 服務 | GCP 對應服務 | 主要差異 |
|---|---|---|
| VPC (Virtual Private Cloud) | VPC Network | GCP VPC 是全球性的，不限於單一區域 |
| Route 53 | Cloud DNS | 兩者都是託管 DNS 服務 |
| CloudFront | Cloud CDN | Cloud CDN 整合 Google 全球網路 |
| Direct Connect | Cloud Interconnect | 提供專用網路連接 |
| ELB (Elastic Load Balancer) | Cloud Load Balancing | GCP 提供全球負載平衡 |
網路架構轉換：VPC 與防火牆規則
AWS VPC vs GCP VPC 架構差異
AWS VPC：
- VPC 限定在單一區域 (Region)
- 子網路 (Subnet) 限定在單一可用區 (Availability Zone)
- Security Groups 針對單個實例，Stateful（有狀態）
- Network ACL 針對整個子網路，Stateless（無狀態）
GCP VPC：
- VPC 是全球性資源，跨越所有區域
- 子網路是區域性資源，但可跨越該區域內的所有區 (Zones)
- 防火牆規則在 VPC 層級設定，套用至所有實例
- 使用網路標籤 (Network Tags) 來精確控制規則適用範圍
防火牆規則轉換範例
AWS Security Group 範例：
# AWS CLI - 建立 Security Group
aws ec2 create-security-group
--group-name web-server-sg
--description "Allow HTTP and HTTPS traffic"
--vpc-id vpc-1234567890abcdef0
# 允許 HTTP (port 80) 從任何 IP
aws ec2 authorize-security-group-ingress
--group-id sg-1234567890abcdef0
--protocol tcp
--port 80
--cidr 0.0.0.0/0
# 允許 HTTPS (port 443) 從任何 IP
aws ec2 authorize-security-group-ingress
--group-id sg-1234567890abcdef0
--protocol tcp
--port 443
--cidr 0.0.0.0/0
GCP Firewall Rules 對應範例：
# GCP - 建立防火牆規則（使用網路標籤）
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
# 建立 VM 實例時指定網路標籤
gcloud compute instances create web-vm
--zone=asia-east1-a
--machine-type=n1-standard-1
--tags=web-server
運算實例轉換
從 AWS EC2 遷移到 GCP Compute Engine
AWS EC2 啟動範例：
# 啟動 AWS EC2 實例
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 對應範例：
# 啟動 GCP Compute Engine 實例
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
機器類型對應與成本比較
| AWS 實例類型 | vCPU | 記憶體 | GCP 對應 | 成本差異 |
|---|---|---|---|---|
| t3.medium | 2 | 4 GB | n1-standard-2 | GCP 約低 10-15% |
| m5.large | 2 | 8 GB | n1-highmem-2 | 類似價格 |
| c5.xlarge | 4 | 8 GB | n1-highcpu-4 | GCP 約低 20% |
IAM 權限管理轉換
AWS IAM vs GCP IAM 架構差異
AWS IAM：
- 使用 Policies（策略）定義權限
- 可附加到 Users、Groups、Roles
- 支援 Inline Policies 和 Managed Policies
- 使用 ARN (Amazon Resource Name) 識別資源
GCP IAM：
- 使用 Roles（角色）定義權限集合
- 權限直接綁定到資源（專案、資料夾、組織）
- 使用 Service Accounts 進行應用程式身份驗證
- 採用階層式權限繼承（組織 → 資料夾 → 專案 → 資源）
IAM 策略轉換範例
AWS IAM Policy（允許讀取 S3）：
{
"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（對應權限）：
# 授予 Service Account 讀取 Cloud Storage 權限
gcloud projects add-iam-policy-binding my-project-id
--member="serviceAccount:my-app@my-project-id.iam.gserviceaccount.com"
--role="roles/storage.objectViewer"
# 或針對特定 Bucket
gsutil iam ch
serviceAccount:my-app@my-project-id.iam.gserviceaccount.com:objectViewer
gs://my-bucket
資料庫遷移：從 AWS RDS 到 GCP Cloud SQL
遷移步驟
步驟 1：使用 Database Migration Service
# 在 GCP 建立 Cloud SQL 實例
gcloud sql instances create mydb-instance
--database-version=MYSQL_8_0
--tier=db-n1-standard-2
--region=asia-east1
--network=default
--no-assign-ip
# 建立資料庫
gcloud sql databases create mydb
--instance=mydb-instance
# 建立使用者
gcloud sql users create myuser
--instance=mydb-instance
--password=mypassword
步驟 2：從 AWS RDS 匯出資料
# 在 AWS RDS 建立快照
aws rds create-db-snapshot
--db-instance-identifier mydb
--db-snapshot-identifier mydb-snapshot-20240114
# 匯出到 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
步驟 3：傳輸到 GCP 並匯入
# 從 S3 複製到 Cloud Storage
gsutil -m cp -r s3://mydb-exports gs://mydb-migration/
# 匯入到 Cloud SQL
gcloud sql import sql mydb-instance
gs://mydb-migration/export.sql
--database=mydb
儲存遷移：從 AWS S3 到 GCP Cloud Storage
使用 Storage Transfer Service
# 建立 Cloud Storage Bucket
gsutil mb -c standard -l asia-east1 gs://my-gcp-bucket/
# 使用 Storage Transfer Service（透過 GCP Console 或 API）
# 或使用 gsutil 直接複製
gsutil -m cp -r s3://my-aws-bucket/* gs://my-gcp-bucket/
# 設定 Bucket 權限
gsutil iam ch
serviceAccount:my-app@my-project-id.iam.gserviceaccount.com:objectViewer
gs://my-gcp-bucket
負載平衡器轉換
從 AWS ALB 到 GCP HTTP(S) Load Balancer
GCP HTTP Load Balancer 設定：
# 1. 建立實例群組
gcloud compute instance-groups managed create web-ig
--base-instance-name=web
--size=3
--template=web-template
--zone=asia-east1-a
# 2. 建立健康檢查
gcloud compute health-checks create http web-health-check
--port=80
--request-path=/health
# 3. 建立後端服務
gcloud compute backend-services create web-backend
--protocol=HTTP
--health-checks=web-health-check
--global
# 4. 將實例群組加入後端服務
gcloud compute backend-services add-backend web-backend
--instance-group=web-ig
--instance-group-zone=asia-east1-a
--global
# 5. 建立 URL Map
gcloud compute url-maps create web-map
--default-service=web-backend
# 6. 建立 HTTP Proxy
gcloud compute target-http-proxies create web-proxy
--url-map=web-map
# 7. 建立轉發規則（配置外部 IP）
gcloud compute forwarding-rules create web-forwarding-rule
--global
--target-http-proxy=web-proxy
--ports=80
遷移策略建議
階段式遷移
- 評估階段（1-2 週）
- 盤點所有 AWS 資源
- 計算遷移成本與 GCP 營運成本
- 識別依賴關係
- 試點遷移（2-4 週）
- 選擇非關鍵服務先行遷移
- 驗證效能與功能
- 調整遷移流程
- 批次遷移（4-12 週）
- 按服務類型分批遷移
- 保持 AWS 服務運行作為備援
- 逐步切換流量
- 優化階段（持續）
- 調整資源配置
- 啟用 GCP 特有功能
- 成本優化
常見問題 FAQ
Q1: 遷移過程中如何確保零停機？
A: 使用雙向同步策略：
- 資料庫使用 DMS (Database Migration Service) 進行即時複寫
- 使用 DNS 流量切換（Route 53 → Cloud DNS）
- 先切換讀取流量，確認無誤後再切換寫入流量
Q2: AWS 和 GCP 的網路延遲差異大嗎？
A: 實測顯示：
- 同區域內延遲相近（1-2ms）
- GCP 的全球網路在跨區域通訊時延遲通常較低（因使用 Google 專用光纖）
- 建議使用 Cloud Interconnect 連接地端
Q3: 成本會有多大差異？
A: 根據工作負載不同：
- 運算成本：GCP 通常低 10-30%（因為持續使用折扣）
- 儲存成本：類似，但 GCP 的 Nearline/Coldline 較便宜
- 資料傳輸：GCP 的 Egress 費用通常較低
- 建議使用成本計算器實際試算
Q4: 需要重寫程式碼嗎？
A: 取決於使用的服務：
- 基礎設施層（VM, Storage）：無需改程式碼
- PaaS 服務（Lambda → Cloud Functions）：需要調整
- 資料庫層：若使用標準 SQL，影響較小
- 建議使用 Terraform 管理基礎設施，方便跨雲部署
Q5: 如何處理 AWS 特有服務（如 DynamoDB）？
A: GCP 對應方案：
- DynamoDB → Firestore (文件型) 或 Bigtable (寬列型)
- 需要調整資料模型與查詢邏輯
- 建議使用資料抽象層（DAO Pattern）降低遷移影響
最佳實踐建議
- 使用 Infrastructure as Code：Terraform 管理跨雲資源
- 標準化命名規範：便於資源識別與成本追蹤
- 啟用詳細日誌：使用 Cloud Logging 集中管理
- 實施成本監控：設定預算警報，避免超支
- 保持文檔更新：記錄架構決策與配置細節
- 定期演練災難恢復：確保備份與恢復流程正常
總結
從 AWS 遷移到 GCP 是一個系統性工程，需要詳細規劃與測試。關鍵成功因素包括：
- 深入理解兩個平台的架構差異
- 制定清晰的遷移計畫與時程
- 使用適當的工具與服務（DMS, Storage Transfer Service）
- 採用階段式遷移策略，降低風險
- 持續優化資源配置與成本
透過本文的服務對應表、程式碼範例與最佳實踐，你可以更有信心地完成 AWS 到 GCP 的架構轉換。
參考資源
- Google Cloud for AWS Professionals
- Migrate to Google Cloud
- GCP Pricing Calculator
- Migration to GCP: Getting Started