半泽和莉娜“上云用哪家？”这个问题我被人问过无数次。每次开会，只要有人提出来，大概率会陷入一场没有结论的争辩：AWS粉说服务全，Azure粉说企业友好，GCP粉说技术先进。吵到最后往往是老板拍板，或者干脆以“反正都差不多”收场。
我做基础设施这行十年，三朵云都重度用过，从个人项目到上千台规模的集群都接触过，可以负责任地说：它们之间的差距，不是功能清单上的勾勾叉叉，而是底层理念和适用场景的巨大分岔路。这篇文章从我用过的真实感受出发，把AWS、Azure、Google Cloud这三家巨头掰开揉碎聊一遍，帮你搞清楚为什么选它、它适合谁，以及最容易被忽略的成本和坑。
1. 三朵云背后的不同基因，决定了它们擅长什么
看一个云厂商，不要只看它今天有什么产品，要先看它是什么出身。基因这个东西，会渗透到产品设计、计费逻辑、文档风格甚至工单回复速度里。三大厂商的起点完全不同，所以它们演化的方向也完全不同。
1.1 AWS：电商仓库里长出来的基础设施之王
AWS 是 2006 年从亚马逊电商内部长出来的。当年亚马逊为了支撑自己的商城业务，积累了海量分布式系统经验，后来把这套能力打包成云服务卖给别人。所以 AWS 的第一性原理是“可靠地提供基础设施”，它默认用户是懂网络、懂架构、懂运维的工程师，给你一大堆零件，让你自己拼。
这种基因带来的结果是：AWS 的功能覆盖度全球第一，几乎所有你能想到的云服务它都有，甚至你没想到的它也有。计算、存储、网络、数据库、AI、IoT、游戏、卫星地面站，密密麻麻几千个服务。好处是任何需求都能找到对应产品，坏处是学习曲线极其陡峭，控制台密密麻麻，新手打开就是一脸茫然。AWS 的文档也一样，功能写得很全，但你要找“我到底该用哪个”的答案，往往要查半天。
AWS 的另一面是它的生态成熟度。最早做云，意味着有最多的人踩过坑，最多的第三方工具兼容它，最多的初创公司跑在它上面。这种网络效应非常恐怖，后面两家想追，很难在短期内追平。
1.2 Azure：跟着企业软件习惯走的集成型云
Azure 是微软 2010 年推出的，起点跟 AWS 完全不一样。微软的骨子里是企业软件公司，Windows Server、Active Directory、SQL Server、Exchange、SharePoint，这些东西铺在全球大大小小的公司机房。Azure 的定位不是“给极客玩的积木”，而是“让现有企业平滑上云的桥”。
所以 Azure 最大的优势是跟微软企业生态的整合。如果你公司已经深度使用 Active Directory 做统一身份认证，那接入 Azure 几乎是顺理成章的事——你在 Azure 里可以直接复用现有的身份体系、权限策略、组策略，不需要像在 AWS 上那样重新搭一套权限模型。如果你有大量 Windows Server 和 SQL Server 的存量授权，用 Azure 还能通过混合权益省下真金白银。
Azure 的另一个特点是混合云做得最成熟。企业上云不是非黑即白，很多大公司会有一半系统留在自己的机房，另一半放到云端。Azure 提供了从本地到云端的完整路径，让你可以渐进式迁移，而不是一步到位。对传统IT团队来说，这种“不用推翻重来”的安心感很重要。
1.3 GCP：工程师文化倒逼出来的技术驱动型云
Google Cloud 是三者中最晚商业化的，2011 年才对外正式提供服务，但它背后是 Google 内部用了二十多年的基础设施。Google 的基因是搜索引擎，这意味着它必须处理海量数据、超大规模分布式系统、毫秒级响应，所以 GCP 在数据处理、容器调度、机器学习这些领域，技术底蕴非常深。
Kubernetes 就是 Google 发明的，现在全世界跑容器编排基本都离不开它，而 GCP 上的 GKE 服务自然有“亲儿子”优势。BigQuery 作为云原生数仓，性能强得离谱，用过的数据工程师几乎没有说不好的。机器学习平台 Vertex AI 把训练、部署、监控整个流程串起来，对算法团队非常友好。
GCP 比较吃亏的地方在于：全球区域覆盖没前两家广，尤其在传统企业密集的市场里，本地数据中心资源相对少；企业级销售和支持体系也不如 AWS 和 Azure 成熟。它的用户画像非常鲜明——工程师文化浓厚的互联网公司、数据驱动型的团队、AI 创业公司，这些人一旦用上 GCP，往往会形成强烈的品牌忠诚度。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心产品线对比：不是在比功能，是在比设计哲学
很多人做云选型时喜欢拉一张功能对比表，逐项打钩。坦白说这个思路是错误的，因为三大厂商在核心产品上早就没有“你有我没有”的差距了，真正的差距在于同一个功能背后的设计理念和适用场景。我挑几个最常见的领域来说。
2.1 计算资源：EC2、Azure VM 和 Compute Engine 怎么选
AWS EC2 是云服务器的代名词，机器类型多得离谱，从通用的 t 系列、计算优化的 c 系列，到内存优化的 r 系列、GPU 加速的 p 系列，应有尽有。它还自研了 Graviton 系列 ARM 芯片，性价比在 arm 实例上确实能做得很低。
Azure 的虚拟机跟 EC2 从功能上几乎一一对应，但有几个差异化点：一是跟 Windows 生态的融合，比如 Windows 授权、活动目录域控这些，Azure 天然无缝；二是混合权益，如果你已经有微软软件许可，可以省很大一笔钱；三是它在 Windows 容器和 SQL Server 上的支持是最顺的。
Google Compute Engine（GCE）最大的不同是它的网络和调度做得极其细腻。举个例子，GCE 的在线迁移（Live Migration）会在你不知不觉中把虚拟机从一台物理机搬到另一台，不用重启，业务无感。AWS 虽然也有类似能力，但触发场景和保证程度没有 GCP 那么强。对于银行、交易所这类不能中断的业务，这个能力非常加分。
2.2 对象存储和数据库：S3、Blob Storage、Cloud Storage 的隐形隔阂
对象存储三家里都有，AWS S3 是事实标准，几乎所有第三方工具、开源项目、大数据生态都默认支持 S3 API。哪怕你在 Azure 或 GCP 上，很多工具依然可以直接连 S3 兼容接口，这会省很多适配工作。
Azure Blob Storage 跟微软自家的数据湖、Power BI、Azure SQL 生态结合得最紧密。如果你已经在用微软全家桶做数据分析和报表，把数据放 Blob 是最少折腾的路径。GCP 的 Cloud Storage 跟 BigQuery 之间的数据流转是光速体验，几行命令就能把 PB 级数据导进数仓，这种顺手程度是 GCP 用户最舍不得换平台的原因之一。
数据库层面更有意思。AWS Aurora 兼容 MySQL 和 PostgreSQL，性能比官方版本提升数倍，是 AWS 数据库的王牌；Azure SQL Database 跟 SQL Server 同源，DBA 上手零成本；Google Spanner 则是全球分布式关系型数据库，支持跨地域强一致，这种能力在另外两家还没有能完全对打的产品。所以如果业务天然要求全球多活，Spanner 是很差异化的考虑。
2.3 容器与 Kubernetes：GKE 值得被单独表扬
容器化已经是现代应用的主流，而 Kubernetes 就是容器编排的默认答案。三朵云都提供托管 K8s 服务：AWS 的 EKS、Azure 的 AKS、Google 的 GKE。坦白讲，如果只看 K8s 本身的使用体验，GKE 是三家里最舒服的，毕竟是 Google 亲儿子，版本演进跟上游最同步，升级策略也最温和。AWS EKS 的生态最大，第三方工具和文档最多，但早期升级体验一直被吐槽，现在好一些了。Azure AKS 的优势在于 Windows 容器节点池的支持，如果你的服务里混着 Linux 和 Windows 容器，AKS 是唯一能顺畅跑完整体的方案。
这里有个容易被忽略的点：托管 K8s 不等于“不用运维了”。实际上你需要管理节点池、网络插件、存储驱动、监控告警，每一层都有云厂商自己的一套配置方式。选哪家不只是选 K8s 按钮，而是选周边配套是否顺手。
3. 算账这件事，别只看单价表
云服务商的定价页面永远做得像迷宫，每家都恨不得让你觉得“按小时租好便宜”，结果月底账单出来直接傻眼。我见过太多团队选云时只盯着计算实例的单价，完全没考虑流量费、存储读写费、负载均衡费、日志存储费，最后被账单教育做人。所以这里专门聊聊账单逻辑差异。
3.1 计费模型完全不同，省钱的姿势也不一样
AWS 的核心折扣机制从最早的预留实例演化成了现在的 Savings Plans，你可以承诺 1 年或 3 年的每小时消费额，换取折扣。另外就是 Spot 实例，可以用很低的价格抢闲置算力，但可能被随时回收，适合跑批处理、CI 等无状态任务。
Azure 的计价有一个杀手锏叫混合权益（Hybrid Benefit），如果你已经有微软的软件授权，可以带到 Azure 上按基础费率算，这一点对老微软用户来说价值极大。Azure 同样有 Spot 实例，叫 Azure Spot Virtual Machines，逻辑跟 AWS 差不多。
GCP 的计费逻辑最有意思：它有两个自动折扣机制。持续使用折扣——你一个月内跑得越久，折扣越高，不需要预付费，自动生效；承诺使用折扣——你承诺用 1 年或 3 年，同样能拿折扣，而且不需要一次性预付。这种“不用先掏钱就有折扣”的模式，对小团队非常友好。
3.2 真正的大头：流量费和隐藏费用
很多人的认知误区是“云的价格等于虚拟机单价”。实际上在一个流量稍大的业务里，出口流量费（Egress）往往是账单中最失控的一项。三家都有流量费用，但定价、计费阶梯和免费额度差别很大。跨地域传输、分发的场景下，流量费甚至可能超过计算费。这不是危言耸听，我做过一个视频处理项目，每月出口流量接近 50TB，月底看账单才发现流量费占了快六成。
此外还有一些不起眼的小项：弹性公网 IP 不用也收费、快照存储费、负载均衡每小时费用、跨可用区流量费。这些每一项看着都不贵，但堆多了就是一笔不小的预算。我建议任何项目上线前，都把“网络拓扑图 + 流量预估 + 实例类型 + 存储量”做成一个表格，逐项算一遍，而不是只盯着计算单价。
3.3 比价实例：同一个中等 Web 服务差多少
我给你一个我实际做过的粗略算例：一个跑在香港或新加坡区域的中等规模 Web 服务，4 核 16G 内存，系统盘 50G SSD，每月流量 1TB，加上一个托管的 PostgreSQL 数据库，三家的月度账单差距在 5% 以内。但如果你把数据库换成一个极端情况——比如读写都特别频繁或者需要跨区域复制，账单差距就会拉到 15%-20%，而且不同云各擅胜场。
所以比价最靠谱的方法不是看官网单价，而是把你要用的所有服务列成清单，用官方 Pricing Calculator 分别算一下，最后再乘以一个 1.2 到 1.3 的系数作为“实际可能超出”的预留。这个系数是经验值，别问我是怎么知道的。
4. 生态、认证和混合云：选云等于选一条职业路线
很多技术负责人只看技术指标和价格，忽略了一个软性因素：生态的成熟度会影响你的招聘、培训、排查问题的效率，甚至未来跳槽时团队成员的竞争力。这部分往往才是最大的长期成本。
4.1 生态圈和 Marketplace：找别人现成方案的能力
AWS Marketplace 历史最久、产品最多，从操作系统镜像到数据库中间件，从安全工具到数据集成，几乎任何你想用的软件都能在里面找到现成版本，点几下就能部署到你的账号里。Azure Marketplace 跟微软自家的生态深度绑定，很多微软系的 SAS 产品集成非常顺。GCP Marketplace 数量少一些，但质量普遍不错，尤其在大数据和 AI 领域的第三方工具。
这个差异在真实项目里很实际：如果团队里没人写过某个组件的部署脚本，从 Marketplace 里一键拉起一个带厂商维护的镜像，能省掉一个星期的折腾。而 Marketplace 的选择广度，直接决定了哪些场景能做到“开箱即用”。
4.2 认证体系和人才储备：招人时你会有切肤之痛
AWS 认证是全球最普及的云认证，市场上持有 AWS 证书的工程师最多，招人最容易。如果你在招聘网站上发一个“AWS 运维工程师”，收到的简历数量会明显多于“GCP 运维工程师”。Azure 认证在传统企业 IT 圈子认可度高，尤其适合那些做微软系统运维转型上云的人。GCP 认证的市场声量相对小，但数据工程、机器学习方向的认证含金量很高，持有者普遍更对口大数据技术栈。
这件事对团队的影响是长期的。选了冷门云，初期招人难，后续文档和社区案例也少，遇到问题得自己啃官方文档，排查速度会慢。我并不是让你因此避开 GCP，而是建议在做决定前，先看看你所在区域的人才池长什么样。
4.3 混合云与多云：三家的姿势各不相同
企业完全上云很美好，但现实是大量企业会保留一部分本地机房。AWS 的方案是 Outposts，把 AWS 的硬件整机放进你自己的机房，让你在本地也能用 AWS 的控制台和 API，体验和公有云一致。Azure 的方案是 Azure Stack Hub 和 Azure Arc，你可以把 Azure 的服务延伸到本地甚至其他云上，管得最“宽”。Google 的 Anthos 则主打多云管理，可以在一套控制台上统一管理跑在 GCP、AWS、Azure 和本地机房的 Kubernetes 集群。
从实际经验来看：如果公司铁了心走混合云路线，Azure 是最成熟的路径，尤其是那些已经用 System Center、Hyper-V 的团队，迁移成本最低。如果只是想有一个控制面统一管理多个云上的容器环境，Anthos 是灵活度最高的选择。
5. 真实业务场景下，我的选型建议
很多人问“到底哪个云最好”，我的标准答案永远是“看你是什么样的团队、什么样的业务”。这里给出几个常见场景的决策思路，不是唯一正确解，但应该能覆盖大部分团队的需求。
5.1 从零开始的初创项目：优先 AWS
不是说 AWS 技术最领先，而是对初创团队来说，踩坑成本最低。几乎所有你能遇到的坑，都有人在 Stack Overflow 上问过并有解决方案。招人容易，文档丰富，第三方工具兼容性最强。哪怕是实习生，上手速度也会比其他云快很多。初创项目最重要的事情是快速迭代，把时间花在研究冷门云的权限模型上，不值得。
5.2 微软技术栈很重的公司：闭眼选 Azure
如果你公司内部有大量 Windows Server、Active Directory、SQL Server，或者业务依赖 Office 365、SharePoint、Dynamics 这些微软产品，那 Azure 基本是唯一理性选择。它能复用你已有的身份体系、许可授权、运维习惯，迁移的平滑度比 AWS 和 GCP 好一个量级。强扭着用 AWS，也不是不行，但你会发现自己得把 Windows 团队重新训练一遍，隐性成本极高。
5.3 数据分析和 AI 是核心的项目：认真考虑 GCP
如果你们的产品本质是“用数据获利”，比如推荐系统、大数据报表、用户画像、机器学习预测，那 GCP 值得认真考虑。BigQuery 的查询性能和易用性，Vertex AI 的模型生命周期管理，加上 GKE 的原生体验，这套组合在数据驱动场景里几乎没有对手。很多公司是先在 AWS 上跑业务，然后才把数据平台搬到 GCP，就是因为数据侧的体验差异太明显。
5.4 强监管行业：先去拉合规清单，而不是看性能
金融、医疗、教育这类强监管行业，选云之前必须把合规需求列成清单，去三家官网逐项核对。三家的合规认证数量都很多，但覆盖范围各有侧重。有些认证 AWS 有而 Azure 没有，有些认证 GCP 刚拿到而别的云早就拿到了。这个东西不能拍脑袋，合规不过 = 业务不能上线，再好的技术优势也得往后放。
6. 我实际踩过的坑，提前帮你避开
最后这部分我掏点压箱底的经验。三大厂商我都做过生产系统，遇到过一些非常典型的坑，写出来希望大家别重复交学费。
6.1 权限模型差异巨大，别用 AWS 的思维玩另外两家
AWS 的权限核心是 IAM 策略，语法非常灵活但也非常容易绕晕。Azure 的权限模型跟 Active Directory 强绑定，组织架构、条件访问策略是一套完全不同的玩法。GCP 的权限模型相对清晰，用角色绑定、继承授权，但如果你习惯了 AWS 的“一切皆策略”，刚转过去会莫名奇妙找不到某个权限设置。
我见过最惨的案例是：一个团队在 AWS 上很熟练，换到 GCP 后照搬 AWS 的“最小权限”思路，结果 GCP 项目层级继承没处理好，权限被一层一层吞掉，最后服务直接挂掉。跨云迁移前，一定要花时间重新学习目标云的权限模型，而不是靠经验硬套。
6.2 配额限制比你想的更严格，必须提前申请
很多人以为云资源是无限量的，实际上每个账号都有大量默认配额。CPU 核数、公网 IP 数量、存储容量、API 请求频率都有配额。如果你有一个突发流量活动，或者计划批量创建实例，默认配额很可能不够用。
这个坑我踩过两次。一次是上线当天发现某区域 CPU 配额只有 40 核，业务需求是 200 核，紧急提工单也没用，只能眼睁睁看着活动延后。另一次是一段脚本在 GCP 上创建多个存储桶，触发 API 频率限制，结果部分任务静默失败，排查到半夜才找到原因。经验是：任何一个新项目上线前，预估未来一个月可能需要的最大资源量，提前 2 周把配额申请提交上去。配额通过了不扣钱，但续不上就是事故。
6.3 跨云迁移，比想象中麻烦，提前做好解耦
很多人觉得从一个云迁到另一个云，不就是重新部署一遍吗？真没有那么简单。专有数据库服务、消息队列、对象存储上的数据迁移，都会给你造成巨大的痛苦。数据库如果用了 AWS Aurora 或 GCP Cloud Spanner 这样的托管服务，导出迁移会非常费劲，尤其是数据量大时，光导出就要一整天，中间还不能停业务。
所以我建议：如果你有跨云迁移的可能性，核心业务层尽量使用开源通用的技术栈，比如 Kubernetes + PostgreSQL + Kafka + MinIO 这种组合；把非核心的部分再用云厂商的托管服务加分。这样即便未来想换云，重部署成本可控。当然，如果确定一辈子不换，那完全可以尽情拥抱各家托管服务，谁用好谁的。
再分享一个小技巧：无论你最终选哪家，第一步一定是开两个账号，一个生产环境专用，一个自己折腾测试用。别在生产账号里做实验，也别把测试资源混在生产环境里。我在三朵云上都这么干，被账单和事故教育过之后，才真正认识到这个习惯有多重要。