从 谷歌云 迁移到 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，是迁移中最需要时间规划的步骤之一。
迁移建议：不要试图把 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 策略文档，这个过程不支持自动化工具完全处理，需要人工逐条确认。
三、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 驱动也需要更换。
正式切换后，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 节点组都可能在新账号下遇到配额限制，影响迁移进度。
通过 代理商 渠道开户，可以获得高权重高配额账号，配额申请通过率更高，同时充值享代理专属折扣（低至 7 折），付款支持 多货币 和对公转账，适合没有海外信用卡或需要企业对公结算的团队，账号免实名、免绑卡，1 分钟极速交付。
