从 谷歌云 迁移到 AWS 是一个涉及网络架构重设计、IAM 权限模型转换、存储和数据库服务重新选型的完整平台迁移。
GCP 和 AWS 在核心设计理念上存在很大的差别，直接复制配置在两个平台之间行不通。
在决定是否迁移之前需要了解清楚：如果迁移的主要动机是降低成本，GCP 到 AWS 的迁移几乎一定是错误的方向。
AWS 同等配置的计算实例比 GCP 贵 10–20%，GCP 的持续使用折扣（Sustained Use Discounts）自动应用于运行时长超过月度 25% 的实例，无需承诺。
选择迁移到 AWS 的团队，通常是为了更广泛的服务目录（AWS 200+ 服务 vs GCP 100+ 服务）、更完整的企业合规覆盖（FedRAMP、HIPAA BAA 在 AWS 覆盖 150+ 服务），或者团队的技术栈和人才生态更偏向 AWS 方向。
这些情况不应该迁移
技术社区中有一个来自实际 GCP-to-AWS 迁移项目的建议：如果以下任何一种情况符合你的业务，迁移之前需要认真重新评估。
BigQuery 是核心数据平台时，迁移到 AWS 没有等价替代。Redshift 是最接近的服务，但两者的运维模式完全不同——BigQuery 完全无服务器，按实际扫描的字节量计费，自动扩缩；Redshift 需要预先规划集群规格，定期执行 VACUUM 操作维护查询性能，集群管理工作量明显。如果团队依赖 BigQuery 做复杂分析查询和实时数据仪表板，迁移后的成本和运维负担通常高于迁移前。这种情况的替代方案是使用 BigQuery Omni，让 BigQuery 直接查询存储在 S3 中的数据，而不是把数据迁移到 Redshift。
GKE Autopilot 运行良好时，同样不建议迁移。GKE 是目前最成熟的托管 Kubernetes 服务，GKE Autopilot 模式下节点管理完全由 Google 负责，EKS 即使配合 Karpenter 也需要更多运维介入。GKE Standard 模式的控制平面免费，EKS 每个集群每月收取 $73 的控制平面费用，多集群环境下这个差距相当明显。
Cloud Spanner 是核心数据库的团队，在 AWS 上没有真正的等价服务。DynamoDB 是 NoSQL，数据模型完全不同；Aurora Global Database 是区域性的，无法复制 Cloud Spanner 的全球分布式强一致性。从 Cloud Spanner 迁移到任何 AWS 数据库，本质上是一次数据库重建，而不是迁移。
GCP 与 AWS 核心服务对照
以下是主要服务的对照关系，对照不代表功能完全等价，带有星号的服务存在显著的架构差异需要注意：
| GCP 服务 | AWS 等价服务 | 备注 |
| Compute Engine | Amazon EC2 | 基本等价，实例类型体系不同 |
| GKE | Amazon EKS | K8s manifest 可移植，平台集成需重写 ★ |
| Cloud Run | AWS Fargate / App Runner | 计费模型不同 |
| Cloud Functions | AWS Lambda | 基本等价 |
| Cloud Storage | Amazon S3 | 基本等价 |
| Cloud SQL | Amazon RDS | 基本等价，迁移工具完善 |
| BigQuery | Amazon Redshift | 架构差异极大，建议评估是否迁移 ★★ |
| Cloud Spanner | Aurora / DynamoDB | 无直接等价，需重建 ★★★ |
| Firestore | Amazon DynamoDB | 文档模型差异，需重设计 ★ |
| Cloud Pub/Sub | Amazon SQS + SNS | SQS 负责队列，SNS 负责扇出 |
| Dataflow | Kinesis + AWS Glue | 流处理和 ETL 分别对应 |
| Dataproc | Amazon EMR | 基本等价 |
| Cloud CDN | Amazon CloudFront | 基本等价 |
| Cloud Load Balancing | ALB / NLB | 按需选择七层或四层 |
| Cloud DNS | Amazon Route 53 | 基本等价 |
| Cloud Armor | AWS WAF + Shield | 功能对应 |
| Vertex AI | Amazon SageMaker | 功能对应，生态不同 |
| Cloud VPC | Amazon VPC | 架构差异极大 ★★★ |
| Cloud IAM | AWS IAM | 模型差异极大 ★★ |
三大架构改造难点
一、VPC 网络重设计
网络是 GCP 和 AWS 架构差异最大的地方，也是 80% 的迁移意外来源于此。
GCP 的 VPC 是全局的：创建一个 VPC 后，可以在全球任意地域创建子网，同一 VPC 下不同地域的子网默认可以直接内网通信，不需要任何额外配置。这让跨区域的服务发现和内网路由在 GCP 上非常简单。
AWS 的 VPC 是区域级别的资源：每个 AWS 区域有自己独立的 VPC，不同区域的资源要通过内网通信，必须配置 VPC Peering 或 Transit Gateway，路由表也需要手动维护。把 GCP 的单一全局 VPC 拆分成多个 AWS 区域 VPC，是迁移中最需要时间规划的步骤之一。
关于 AWS VPC 的子网划分、路由表配置和跨 VPC 连接方式，可以参考 AWS VPC 网络配置教程的完整说明。
迁移建议：不要试图把 GCP 的网络设计复制到 AWS，而是从 AWS 的设计理念重新规划。在开始资源迁移前，先用 Terraform 或 CloudFormation 定义完整的 AWS 网络架构（VPC、子网、路由表、安全组），以代码方式固化配置，避免后期运维中出现未文档化的配置偏差。
二、IAM 权限模型迁移
IAM 迁移是整个过程中最容易被低估的工作，经验丰富的迁移团队通常为这一步单独留出 2–3 周。
GCP IAM 采用层级角色模型。权限绑定在资源层级上（组织 → 文件夹 → 项目 → 单个资源），上层的权限向下继承，一个服务账号可以被授予访问不同项目资源的权限，权限逻辑通过层级结构表达。
AWS IAM 采用策略文档模型。所有操作默认拒绝，通过 JSON 格式的策略文档显式授予 Allow 或 Deny，策略附加在 User、Group 或 Role 上，没有隐式继承。
GCP 服务账号（Service Account）在 AWS 的对应物是 IAM Role，通过实例配置文件（Instance Profile）附加到 EC2，或通过 IRSA（IAM Roles for Service Accounts）附加到 EKS Pod。迁移时需要逐一审查 GCP 中所有服务账号的权限绑定，转换为对应的 AWS IAM 策略文档，这个过程不支持自动化工具完全处理，需要人工逐条确认。
关于 AWS IAM 策略结构、角色创建和最小权限原则，可以参考 AWS IAM 权限管理教程。
三、BigQuery 向 Redshift 的迁移判断
这是 GCP 到 AWS 迁移中最复杂的单点，也是最值得单独深思的决定。
BigQuery 的设计是完全无服务器的：用户提交 SQL 查询，BigQuery 自动调度计算资源执行，按扫描的字节量收费（按需计费约 $5/TB），没有集群需要管理，没有索引需要维护，存储和计算完全分离。
Redshift 是传统的集群式数据仓库：需要提前规划节点类型和数量，查询性能取决于集群规格和数据分布，需要定期执行 VACUUM 和 ANALYZE 维护查询效率，扩缩容需要手动操作（Redshift Serverless 选项提供了更多弹性，但计费模型和 BigQuery 仍然不同）。
从 BigQuery 迁移到 Redshift，不只是数据搬运，还需要重新评估查询模式、数据分布策略、表的 SORT KEY 和 DIST KEY 选择，以及 ETL pipeline 的改写。如果分析工作负载复杂，这个迁移的工程量可能超过其他所有服务的总和。
三种迁移策略
对每个需要迁移的 GCP 服务，应该在 Rehost、Replatform 和 Re-architect 三种策略中选择一种：
Rehost（直接迁移）： 将 GCP 工作负载尽量原样搬到 AWS，不改变应用架构。优势是迁移速度快，风险低；代价是无法利用 AWS 原生服务的能力，后续优化空间有限。适合迁移时间紧张、或者该服务未来有计划重写的场景。
Replatform（重新平台化）： 在迁移过程中做少量改造，利用 AWS 的托管能力替代自管理组件。典型例子是把运行在 GCP VM 上的自管理 MySQL 迁移到 Amazon RDS，应用代码不需要修改，但数据库的运维工作量大幅降低。这是性价比最高的策略，在速度和质量之间取得平衡。
Re-architect（重新架构）： 完全利用 AWS 原生服务重新设计应用架构。适合有明确性能或弹性要求、当前架构已经制约业务发展的场景。工程量最大，但长期收益也最高。
实际迁移中，三种策略通常同时存在：核心应用选 Replatform，遗留系统或低优先级服务先 Rehost 上来，只有真正需要的部分才做 Re-architect。
主要迁移工具
AWS Application Migration Service（MGN） 是 Compute Engine 到 EC2 迁移的主要工具。在 GCP 源 VM 上安装轻量级复制 Agent，Agent 持续将磁盘块级数据同步到 AWS，正式切换前可以多次执行测试启动，验证迁移后的 EC2 实例行为是否正常。切换时停止 GCP VM，等待最后一次同步完成后启动 AWS 实例，停机时间通常在数分钟内。
AWS Database Migration Service（DMS） 处理 Cloud SQL 到 RDS 的数据库迁移。DMS 支持持续复制模式，可以在迁移窗口期间让 RDS 实例和 Cloud SQL 保持数据同步，正式切换时只需要将应用的数据库连接串指向 RDS，数据丢失风险极低。Cloud SQL for MySQL 迁移到 Amazon RDS for MySQL 是 DMS 支持最完善的路径，关于 RDS 实例的创建和连接配置，可以参考 AWS RDS 数据库教程。
AWS DataSync 负责 Cloud Storage 到 S3 的数据传输，支持并行传输和断点续传，适合大量文件的批量迁移，同时会验证传输完成后的数据完整性。
AWS Migration Hub 在迁移过程中统一追踪进度，将 MGN、DMS、DataSync 的状态汇聚到一个视图，适合多服务并行迁移的复杂项目。
分阶段迁移执行
第一阶段：资源盘点与依赖梳理（1–2 周）
用 gcloud asset search-all-resources 导出当前 GCP 环境的完整资源清单，覆盖所有 Compute Engine 实例、GKE 集群、Cloud SQL 数据库、Cloud Storage 存储桶、Pub/Sub 主题和 IAM 绑定。梳理服务之间的调用关系、外部 API 集成、VPN 连接和数据流向。依赖梳理是整个迁移中信息量最大的环节，也是后续所有决策的基础。
第二阶段：AWS 环境预置（1–2 周）
在 AWS 目标账号中预置基础设施：VPC 网络和子网、IAM 角色和权限策略、EKS 集群配置（如果有 Kubernetes 工作负载）、RDS 实例、S3 存储桶。建议全部用 Terraform 或 CloudFormation 以代码方式定义，确保环境可以随时重建，避免手动配置导致的配置漂移。
第三阶段：非关键工作负载迁移（2–4 周）
从低风险、低流量的服务开始迁移，验证工具和流程的可靠性，同时让团队积累在 AWS 上运维的经验。内部工具、开发测试环境、批处理任务是典型的第一批迁移对象。每个服务迁移完成后，在 AWS 侧验证功能正常，再切换流量。
第四阶段：数据库和存储迁移（3–6 周）
数据库迁移是风险最高的环节，需要单独规划。使用 DMS 的持续复制功能，在正式切换前将数据延迟控制在秒级，切换窗口应安排在业务低峰时段。Cloud Storage 到 S3 的数据迁移和计算迁移并行进行，先完成存量数据迁移，再切换应用写入到 S3。
第五阶段：正式切换与回滚准备
GKE 迁移到 EKS 是切换阶段工作量最大的部分。Kubernetes 的 YAML manifest 本身大多可以直接使用，但 Ingress 控制器需要从 GKE Ingress 切换到 AWS Load Balancer Controller，Workload Identity 需要替换为 IRSA，存储 CSI 驱动也需要更换。关于 EKS 的节点配置和 Karpenter 自动扩缩设置，可以参考 AWS EKS 完整教程。
正式切换后，GCP 资源不要立即释放，保留至少 30 天，GCP 实例可以缩容到最小规格以节省费用，但不要删除。一旦 AWS 侧出现未预料的问题，可以在数分钟内将流量切回 GCP，这是最直接的回滚方案。
迁移后的成本控制
迁移到 AWS 后，成本优化应该是第一个月的主要工作。新迁移的工作负载通常在按需计费模式下运行，这是最贵的计费方式。观察 2–4 周的实际资源使用模式后，通过 Savings Plans 或 Reserved Instances 锁定稳定工作负载，可以节省 30–72% 的计算成本。EC2 Graviton 实例（ARM 架构）比同等 x86 实例便宜约 20%，对于大多数无特殊架构依赖的应用，切换到 Graviton 是最直接的计算降本手段。
使用 AWS Cost Explorer 和 AWS Compute Optimizer 分析资源利用率，识别过度配置（Over-provisioned）的实例。刚完成迁移的环境通常会保守地选择较大规格，稳定运行后根据实际 CPU 和内存使用率下调规格，可以进一步降低成本。
AWS 账号开通与代理充值
GCP 迁移到 AWS 的完整项目，对账号权重和资源配额的要求相对较高——GPU 实例、高规格 EC2、EKS 节点组都可能在新账号下遇到配额限制，影响迁移进度。通过 AWS 代付 渠道开户，可以获得高权重高配额账号，配额申请通过率更高，同时充值享代理专属折扣（低至 7 折），付款支持 USDT 和对公转账，适合没有海外信用卡或需要企业对公结算的团队，账号免实名、免绑卡，1 分钟极速交付。
