企业选择海外云服务时，最容易犯的错误，是先比较品牌，再寻找使用理由。更有效的顺序是先确定业务负载、目标地区、数据边界、团队能力和预算约束，再判断 AWS、Azure、Google Cloud（GCP）各自适合承载什么。
云平台没有脱离业务场景的“绝对最好”。真正重要的是：目标地区能否稳定交付、架构是否可治理、团队是否能长期维护，以及成本是否能被持续解释。
一、先建立云服务选型的业务输入
不要从产品功能清单开始。选型会议至少要先回答以下八个问题：
- 核心用户在哪些国家和地区，哪些区域对时延最敏感
- 工作负载是网站、应用后端、游戏、数据平台、AI 推理，还是混合形态
- 峰值和日常流量相差多少，是否存在活动、版本发布或广告投放带来的突发增长
- 数据能否跨境，是否有驻留、隐私、审计或行业合规要求
- 现有系统使用哪些数据库、中间件、身份体系与第三方服务
- 团队熟悉虚拟机、容器、Serverless 还是托管数据服务
- 可接受的恢复时间目标（RTO）和恢复点目标（RPO）是多少
- 预算看月度账单，还是看包含人力、迁移和运维的总拥有成本
这些输入会直接改变答案。例如，同样是出海应用，全球内容分发、实时游戏后端、企业协作系统和批量 AI 任务，对区域、网络、计算、数据库和承诺用量的要求完全不同。
二、用六个维度比较 AWS、Azure 与 GCP
| 维度 | 重点检查 | 选型动作 |
|---|---|---|
| 区域与网络 | 用户所在区域、跨区连接、CDN、专线、出入口费用 | 以真实用户时延和数据流向做测试，不只看区域数量 |
| 计算与弹性 | 虚拟机、容器、Serverless、GPU、弹性伸缩 | 用峰值负载和启动速度验证，而不是只看单价 |
| 数据服务 | 关系型数据库、缓存、对象存储、分析与消息系统 | 先确认兼容性、迁移窗口、备份和跨区能力 |
| AI 与开发生态 | 模型、MLOps、数据工具、DevOps、开发者体验 | 用一条真实业务链路做 PoC，检查权限和日志 |
| 安全与治理 | 身份、组织层级、策略、密钥、日志、合规 | 在业务资源上线前先建设 Landing Zone |
| 费用与支持 | 计费模型、承诺用量、技术支持、账单明细 | 同时比较资源价、网络费、运维人力和退出成本 |
AWS 的服务覆盖面与生态通常适合复杂、异构或需要精细组合的工作负载；Azure 对已有 Microsoft 身份、办公和企业技术栈的组织往往更顺手；GCP 在数据分析、云原生和 AI 工作负载上常具有较强的一体化体验。这些只是起点，不应替代针对具体区域和具体应用的验证。
三、按业务场景，而不是按品牌做初筛
场景 1：全球网站与移动应用
重点不是把一台服务器搬到海外，而是让域名、CDN、对象存储、API、数据库和监控组成完整链路。检查静态内容命中率、动态请求时延、跨区数据库写入、灰度发布与故障切换。
场景 2：游戏、直播和实时互动
需要重点验证用户到接入点的网络质量、状态同步、房间或会话调度、峰值扩容速度和反作弊数据链路。平均时延不能替代 P95、P99 和丢包率。
场景 3：企业系统与数据平台
身份与权限、私网连接、日志审计、数据分层和备份恢复优先级更高。若企业已经依赖特定目录、数据库或 BI 工具，迁移和技能成本可能比基础资源价格更重要。
场景 4：AI 训练、推理与多模型应用
需要分别评估 GPU 或加速资源可用性、模型接入方式、吞吐和限流、数据边界、推理成本、监控以及模型替换能力。不要把模型 API 的单次调用价格等同于完整应用成本。
四、单云、多云与混合云怎么判断
| 架构 | 适合情况 | 主要风险 |
|---|---|---|
| 单云优先 | 团队较小、需要快速交付、业务尚在验证 | 过度依赖单一服务、退出成本不透明 |
| 主云 + 备选能力 | 核心业务集中，少数区域或模型需要补充 | 治理边界不清、重复建设 |
| 多云 | 合规、区域覆盖、客户要求或明确容灾需求 | 成本、权限、监控和人才复杂度显著上升 |
| 混合云 | 本地系统无法一次迁移，或数据必须留在本地 | 网络、身份、数据一致性和运维难度 |
多云不是把同一套系统平均放到三个平台。合理的多云通常有清晰边界，例如主业务在一个平台、特定地区使用另一个平台、AI 模型通过统一网关接入，并保留可迁移的数据和接口层。
五、用总拥有成本看账单，而不是只看单价
建议把成本拆成六类：
- 计算、存储、数据库等基础资源
- 公网、跨区域、跨可用区和 CDN 流量
- 日志、监控、备份、安全与技术支持
- 迁移、改造、测试与停机窗口
- 日常运维、FinOps 和人员培训
- 厂商绑定、数据导出与未来退出成本
云上成本治理要在架构阶段开始。资源必须有业务、环境、团队、成本中心等标签；测试与生产要隔离；预算、异常告警和账单分摊要可执行；承诺用量应建立在稳定基线之上，而不是用长期承诺掩盖闲置资源。
六、一个可执行的 100 分选型表
| 评估项 | 建议权重 | 评分证据 |
|---|---|---|
| 区域、网络与用户体验 | 20 | 真实地区压测、P95/P99、丢包、跨区流量路径 |
| 工作负载适配 | 20 | PoC 性能、弹性、数据库兼容与开发效率 |
| 安全、合规与治理 | 20 | 身份模型、组织策略、日志、数据边界和审计 |
| 可靠性与恢复 | 15 | 多可用区、备份、恢复演练、RTO/RPO |
| 三年总拥有成本 | 15 | 资源、网络、支持、人力、迁移和退出成本 |
| 团队能力与支持 | 10 | 技能匹配、服务响应、文档和长期运营能力 |
评分必须附证据，不能只写“好、一般、差”。当两个方案总分接近时，应优先选择团队能够治理、监控和持续优化的方案。
七、30 天概念验证建议
第 1 周：定义基线
完成应用依赖图、数据分类、目标区域、性能基线、预算边界和验收指标。
第 2 周：建设最小 Landing Zone
配置组织与项目结构、身份权限、网络、密钥、日志、预算和基础安全策略。不要直接在个人账号下堆生产资源。
第 3 周：迁移一条真实链路
选择可控但有代表性的业务，从入口、服务、数据库、监控到备份跑通闭环，并注入一次故障验证告警与恢复。
第 4 周：复盘与决策
比较性能、稳定性、部署效率、权限操作、账单可读性和支持响应，输出选择结论、差距清单与后续迁移波次。
八、上线前检查清单
- 云账号、组织、项目和账单主体归属企业
- 管理员、开发、运维和审计权限分离
- 生产、测试和个人实验环境隔离
- 日志、监控、预算和异常费用告警已启用
- 备份、跨区恢复和回滚流程完成演练
- 域名、证书、密钥和第三方依赖有责任人
- 已记录资源标签、架构图和变更流程
- 已确认网络出口、跨区和数据导出费用
- 已为突发流量准备配额与扩容路径
- 已保留迁移和退出所需的数据、接口与文档
官方框架参考
- AWS Well-Architected Migration Lens
- Microsoft Cloud Adoption Framework
- Google Cloud Well-Architected Framework
- Google Cloud Landing Zone 设计
如果需要结合目标国家、系统依赖、云账单和 AI 资源制定选型方案，可通过海外云与 AI 模型服务提交业务信息，由团队协助完成云咨询、账号与资源交付、架构验证及持续成本优化。
