前两年我帮团队做过好几次云平台选型评估每次讨论到最后都会落回同一个问题上到底是把业务放在 AWS还是 Azure还是 Google Cloud。而不管怎么对比最终绕不开的那家永远是 AWS。这个结论不单靠市场份额也不单靠产品名称而是靠整个行业里工程师的共识、生态体系的丰富度、以及一家公司从初创到上市整个过程中云资源消耗的“默认路径依赖”共同堆出来的。这篇文章我想以从业者的视角把国外主流云计算服务商盘一遍AWS 为什么能持续领跑全球云市场Azure 和 Google Cloud 各自手里的牌是什么中小团队和国内开发者要接入 AWS 时哪些坑可以避开以及在真实的故障场景下“云依赖风险”到底该怎么理解。尽量写得实在一些不堆概念所有结论都从我实际用过的场景出发。1. 全球云市场的真实版图AWS、Azure、Google Cloud三分天下1.1 先看数据市场份额从来不是玄学聊云计算市场绕不开机构数据。Synergy Research 最近几个季度的统计口径基本稳定AWS 在全球云基础设施服务市场的份额长期维持在 30% 左右微软 Azure 在 20% 上下Google Cloud 大概 11% 到 12%。三者加起来超过 60%剩下才是 IBM Cloud、Oracle Cloud、阿里云在海外市场的份额以及一堆区域性云厂商。要注意的是不同机构统计口径差异很大。有的只算 IaaSPaaS有的把 SaaS 也纳进去还有的把托管私有云也算上所以云厂商排名在不同报告里偶尔会微调。但第一名的位置从来没有悬念无非是领先幅度是 10 个点还是 15 个点的问题。这种“垄断级”的领先优势不是靠某个爆款产品砸出来的而是十几年积累的结果。1.2 AWS 领跑的核心要素先发、广度、生态的三重叠加AWS 能坐上头把交椅有三个原因缺一不可。第一个是先发优势。2006 年 AWS 推出 S3 和 EC2 的时候微软还在卖光盘Google 还在研究怎么让广告收入翻倍。AWS 用十年时间抢跑等于把“云计算”这个词的定义权握在了自己手里。等到 2008 年 Azure 正式发布、2011 年 Google Compute Engine 上线时AWS 已经在全球建好了十几个区域沉淀出了最完整的安全合规认证体系也教育了一整代开发者。第二个是服务的广度与深度。AWS 目前对外提供的服务超过 200 项从底层的计算、存储、网络到中层的数据库、容器、大数据再到上层的 AI 平台、物联网、媒体服务基本覆盖了一个软件公司能想象到的所有技术需求。而且这不是“每样都有但每样都浅”那种覆盖很多服务单拿出来都能在细分市场排到前三。比如 Lambda 开启了 Serverless 时代Aurora 兼容 MySQL 和 PostgreSQL 却做到了商业数据库的性能S3 的持久性设计高达 11 个 9。这种广度意味着做架构设计的时候绝大多数场景不需要引入外部供应商。第三个是生态体系的放大效应。AWS Marketplace、合作伙伴网络、认证体系、以及全球各地数以万计的 AWS 解决方案架构师和技术社区组成了一个极其庞大的“飞轮”。一个公司如果用了 AWS招人更容易问题上 Google 一搜就有答案第三方工具几乎都做了原生集成。这种生态一旦滚起来客户迁移成本极高后来者很难通过降价去追赶。1.3 “领跑”之外的真实变化市场从增量转向存量这几年云市场有一个非常明显的趋势整体增速放缓了用户的预算变得更加务实。前几年“无脑上云”的论调少了很多很多公司开始把部分工作负载迁回自建机房或采用混合云架构。这种背景下AWS 领跑的行业地位没变但增长逻辑变了。增长点从“首次上云”变成了“AI 带动的新计算需求”和“企业存量业务深度优化”。所以你会发现 AWS 近两年在生成式 AI 上动作非常密集从自研芯片 Trainium/Inferentia到模型托管平台 Bedrock再到企业级 AI 助手 Amazon Q本质上都是在为下一个十年的增长找引擎。这也是为什么我始终觉得判断云厂商的前景不能只看历史份额还得看它能不能持续押对新赛道。2. AWS 的护城河到底在哪从计算存储基本盘到生成式AI的增量2.1 计算与存储的基本盘EC2 和 S3 依然是压舱石就算 AWS 再推出几百个新服务EC2 和 S3 依然是它最核心的两个压舱石。EC2 的优势不在于“能开一台虚拟机”而在于实例类型极为丰富从通用型、计算优化型、内存优化型到 GPU 实例、ARM 架构的 Graviton 实例再到各种裸金属实例任何工作负载几乎都能找到匹配的规格。尤其是 Graviton 系列性价比比同档 x86 实例高不少我已经见过不少团队把无状态服务整体迁到 Graviton 上成本立省 20% 左右。S3 看起来只是个对象存储但它在耐久性和设计哲学上做成了行业标杆。S3 的 11 个 9 持久性设计意味着如果存储 1 亿个对象平均一万年才可能丢一个。它不是靠玄学而是靠多可用区冗余存储、checksum 校验和自动修复机制堆出来的。很多人忽略的是 S3 还有一整套生命周期管理、版本控制、对象锁、存储桶策略体系这些能力让 S3 不仅能存数据还能做数据合规管理。2.2 真正让 AWS “黏人”的管理面与运维体系的深度很多人只看到 AWS 的计算和存储却忽略了它最“黏人”的部分——管理面的深度。IAM 权限体系的细粒度控制VPC 网络隔离的灵活度CloudWatch 监控告警的成熟度CloudFormation/Terraform 对基础设施即代码的支持这些才是真正决定一个团队能否长期高效运维的关键。举一个例子。IAM 里你可以做到“某个用户在某个时间段内、从某个 IP 段、对某个特定 S3 桶前缀、只允许执行 GetObject 操作”这种细粒度权限策略在很多云平台上要么做不了要么做起来非常别扭。再比如 VPC 里的安全组、网络 ACL、子网路由表、NAT 网关、VPC Endpoint组合起来可以构建出极其灵活且安全的网络拓扑。一旦团队习惯了这种控制力再切换到别的平台会明显感觉到“少了很多东西”。2.3 生成式 AI 时代的新王牌Bedrock 和全栈 AI 服务矩阵AWS 过去两年在 AI 领域的动作一句话概括就是“不想像 GPU 短缺时代那样把命运绑在单一的模型和芯片上”。它的思路是做全栈底层有自研芯片 Trainium 和 Inferentia中间有 SageMaker 做训练和微调上层有 Bedrock 提供模型托管服务。我在实际项目里用得最多的是 Bedrock。它最大的价值在于把 API 兼容做得非常统一同一个接口可以切换 Anthropic Claude、Meta Llama、Mistral 等多个模型避免了团队被单个模型厂商锁定的问题。配合开源生态里的 litellm可以直接用 OpenAI 风格的接口调用 Bedrock 上的 Claude迁移成本极低。下面是一个简化示例import os from litellm import completion os.environ[AWS_ACCESS_KEY_ID] 你的AK os.environ[AWS_SECRET_ACCESS_KEY] 你的SK os.environ[AWS_REGION_NAME] us-east-1 response completion( modelbedrock/anthropic.claude-3-5-sonnet-20240620-v1:0, messages[ {role: user, content: 用一句话向产品经理解释什么是冷启动延迟} ] ) print(response[choices][0][message][content])用 litellm 的好处是上层代码完全不用改只需要把 model 参数从gpt-4o换成bedrock/anthropic.claude-3-5-sonnet-...底下的鉴权和请求细节都被封装掉了。这个套路很适合已经有 OpenAI 接口代码、想尝试 Claude 模型的团队花十几分钟就能跑通。2.4 从相关热词里看到的信号AWS 仍是很多人的“默认实验场”我注意到最近的网络热词里出现了不少与 AWS 相关的学习类关键词比如头歌云计算、hello docker、Hadoop 搭建、云计算运维等等。这说明一个问题在高校和培训机构的教学体系里AWS 仍然是被用来演示“什么是云计算”的默认实验场。从学习者的角度看这种选择有一个实际好处——AWS 对新用户的优惠和免费套餐覆盖很广而且官方文档极其详尽遇到问题基本都能搜到。很多人在学校用 AWS 跑通第一个 Docker 容器、搭起第一个 Hadoop 集群工作之后进了企业自然也会优先选择自己熟悉的平台。这种“教育市场”的转化路径是 AWS 长期领跑一个非常隐蔽但又极其重要的原因。3. 挑战者们手里的牌Azure 的企业渗透与 Google Cloud 的 AI 原生3.1 Azure靠“企业 IT 亲戚圈”硬生生挤进决赛圈Azure 的崛起路径和 AWS 完全不同。AWS 是从互联网初创公司起家的Azure 则是从微软庞大的企业级客户体系中长出来的。很多传统企业已经有几十年的微软产品使用史桌面系统是 Windows办公是 Office 365身份认证是 Active Directory。在这种环境下IT 负责人选择 Azure 几乎是一种惯性行为因为 Azure 和微软全家桶的集成做得最顺滑。Azure 有几个产品确实做得很有竞争力。比如 Azure DevOps 与 GitHub微软收购后的深度整合Azure SQL Database 在 SQL Server 兼容性上的无缝迁移Azure Stack 提供的混合云方案。还有一点很关键微软在 AI 时代的布局与 OpenAI 的深度合作、Copilot 全产品线渗透让 Azure 在 AI 赛道上拿到了独特的位置。如果你本来就是微软技术栈Azure 的学习曲线会平缓很多。3.2 Google Cloud技术基因最强但企业服务是短板Google Cloud 在技术圈的口碑一直不错尤其是 Kubernetes、BigQuery、Dataflow 这些数据和大数据组件用过的团队基本都回不去。BigQuery 这种无服务器数仓查询 TB 级数据几秒钟出结果运维负担几乎为零在数据分析场景中非常能打。但 Google Cloud 在企业服务层面的短板也很明显。它的客户支持响应速度一直被海外社区吐槽销售团队对传统企业的理解深度不如微软产品线的迭代节奏也不如 AWS 那么“皮实”。换句话说Google Cloud 是一辆操控体验极好的跑车但售后服务网点没 AWS 那么多。对十几个人以内的技术团队来说Google Cloud 用起来很爽但到了几百人规模需要大量企业级支持的时候差距就会体现出来。3.3 其他玩家Oracle、IBM、“偏科生”的生存之道除了前三名海外云市场还有一些“偏科生”活得很好。Oracle Cloud 的杀手锏是数据库很多企业已经是 Oracle 数据库的重度用户再顺手用它的 OCIOracle Cloud Infrastructure跑 Web 层作为一个互补云存在。IBM Cloud 则在金融和政府行业有独特的合规优势另外红帽 OpenShift 的混合云方案让它在传统企业里有固定市场。Snowflake 这类数据云平台严格来说不是云基础设施厂商但它们在某些领域数据共享、跨云分析确实抢走了一部分云厂商的增量。3.4 选型对照什么样的业务更适合哪家为了让这些结论更直观我整理了一个选型对照表按业务形态快速定位业务形态更适合的平台核心理由互联网初创、全球化业务AWS服务全社区大MVP 阶段不用纠结选型微软生态重度依赖的传统企业Azure和 AD、Office、SQL Server 集成最顺数据分析、机器学习实验Google CloudBigQuery 和 Vertex AI 体验确实顶级国有企业、金融合规场景Azure / IBM合规认证体系全面Oracle 数据库存量业务Oracle Cloud同厂商兼容性最好这不是说每个场景只有一个正确答案但按照这个思路去做初筛至少不会犯特别离谱的方向性错误。4. 不是没有翻车的时候从一次大规模中断看云依赖风险的边界4.1 社区里那场被广泛讨论的中断Kiro 事件是怎么回事前几天社区里讨论最多的一起事件就是 Kiro 导致的 AWS 大规模中断。这类故障的典型特征是在某个相对底层的依赖组件上出了问题比如 DNS 解析、区域控制平面或者认证服务当它抖动时大面积区域内的服务调用都会跟着超时。当时很多受影响用户的直观感受是“AWS 控制台打不开我的 API 也挂了。”但事后看故障报告会发现负载均衡、对象存储这类数据平面的服务其实在线反而是控制台、API 网关、云监控这类管理平面的入口先瘫了。这提示了一个容易被忽略的事实云平台的“可用性”不是一个整体概念控制面和管理面可能比数据面更脆弱。4.2 故障中的真实表现控制面崩了不代表数据全没很多人一听说 AWS 大规模中断第一反应是“我的数据是不是丢了”。实际上S3 的持久性设计已经保证了数据不会因为这类区域性故障丢失EC2 上的虚拟机和 EBS 卷的数据也都还在。真正受影响的是“我能不能访问控制台去操作它们”。这说明一个问题云厂商的故障保护通常优先保证数据面和服务运行状态而管理面用户可以操作的入口在极端情况下的性能会被降级。这个设计其实是一种取舍管理面承担着高并发的请求转发和权限校验一旦下游某个组件抖动很容易形成雪崩。AWS 后来通常会通过限流、缓存、降级等方式恢复管理面在架构层面也会做多单元隔离。但对普通用户来说更实际的教训是别把控制台当成唯一操作入口尽可能为关键操作准备 API 脚本或基础设施即代码这样即便控制台不可用也能通过 CLI 执行部分恢复操作。4.3 从故障里学到的架构教训别把鸡蛋放在一个篮子里围绕这类故障业界讨论最多的其实是“多云架构”到底值不值得做。我的看法相对务实对绝大多数中小团队来说为了应对“某朵云一年一次的大规模故障”而搞一套多云架构成本太高分布式系统本身的复杂度会吃掉所有收益。更合理的做法是在“单云但多区域架构”上做冗余。AWS 在全球有 30 多个区域每个区域内有多个可用区。一个设计良好的系统把主备节点部署在不同可用区里已经能覆盖绝大多数物理故障。如果业务对可用性要求更高再考虑跨区域容灾。数据备份方面S3 跨区域复制是成本极低的兜底方案RDS 跨区域只读副本也是常见的降级策略。这些方案都能在不引入第二朵云的情况下把故障影响范围控制住。4.4 成本与可用性的权衡中小企业别把“高可用”做成豪华配置很多人一谈高可用就上全套多可用区、跨区域复制、蓝绿发布、自动扩缩容、混沌工程......结果就是架构复杂度飙升半天发不上一个版本。我见过太多团队把高可用做成了“为了高可用而高可用”最后维护成本比故障损失还大。从成本角度来说不同业务对可用性的需求完全不一样。一个内部 OA 系统和一个面向全球用户的支付网关对 RTO/RPO 的要求是两个极端。中小企业应该做的是“成本可控的恢复能力”而不是“全年无故障”。核心数据定期自动备份关键服务多可用区部署数据库做主从切换这已经能覆盖 90% 的故障场景。剩下的 10%等业务真的做到那个体量再补也不迟。5. 国内开发者接入 AWS 的实操手册从账号开通到Mac客户端再到大模型调用5.1 准备工作账号、权限、区域选择一坑一坑避我接触过不少从国内开始用 AWS 的开发者遇到的第一批坑基本都集中在账号和区域上。注册 AWS 账号时一定要绑定一张状态正常的国际信用卡虚拟卡有一定概率过不了验证。注册时填写的地址信息要和信用卡账单地址保持基本一致否则风控模型会判定异常。注册完成后第一件事是开启 Root 账号的 MFA多因素认证。很多人嫌麻烦结果账号被盗后开矿机一晚上账单跑到几千美元这种新闻在社区里出现过很多次。然后是区域选择。如果业务目标用户在全球优先选择 us-east-1弗吉尼亚、us-west-2俄勒冈、ap-southeast-1新加坡、ap-northeast-1东京这些常用区域。需要注意的是不同区域的服务开放情况不完全一样有些新功能只在少数区域上线选区域前要去官方文档看一眼可用区列表。对中国大陆业务有合规需求的场景可以关注 AWS 在北京和宁夏由中国合作伙伴运营的区域但这套体系和全球区域在账号体系上是分开的不能直接用同一个账号登录这一点很多人第一次都会踩坑。5.2 客户端工具Mac 上安装和配置 AWS CLI无论你用控制台的频率多低AWS CLI 都建议装上。命令行操作对日常运维和自动化脚本是刚需。在 Mac 上安装 AWS CLI 最简单的方式是用 Homebrewbrew install awscli aws --version安装完成后需要配置 Access Key。先去 IAM 控制台创建一个新的 IAM 用户而不是直接用 Root 账号的密钥。把 Access Key ID 和 Secret Access Key 保存好后在终端执行aws configure按提示输入 Access Key ID、Secret Access Key、默认区域比如 ap-northeast-1即东京区域以及默认输出格式一般填 json。配置完成后可以用一条命令验证aws sts get-caller-identity这条命令会返回当前身份对应的账号 ID 和 ARN看到正确信息就说明环境配好了。Mac 上装完 CLI 后还有个实用小技巧建议用aws configure --profile dev的方式为不同环境比如个人开发环境和公司生产环境配置不同 profile然后操作时通过--profile dev指定。这样可以避免不小心在错误环境里执行清理命令。5.3 用 Bedrock 跑通一个生成式 AI 接口Bedrock 是 AWS 面向生成式 AI 应用的一站式平台。它和直接调用 OpenAI API 的区别在于它把多个模型厂商的模型集中在同一个托管环境里做的是“模型路由器 统一网关”的生意。开通 Bedrock 之后首先要做的是在 Bedrock 控制台的 Model access 页面里申请你要用的模型访问权限比如 anthropic.claude-3-5-sonnet。这个申请通常实时生效但需要手动点一下。拿到权限后最舒服的方式就是用 litellm 这种统一接口库。前面已经给过一个简单示例这里补充一下 boto3 原生调用 Bedrock Converse API 的方式import boto3 import json bedrock boto3.client(bedrock-runtime, region_nameus-east-1) response bedrock.converse( modelIdanthropic.claude-3-5-sonnet-20240620-v1:0, messages[ { role: user, content: [{text: 用一句话解释什么是可用区}] } ] ) print(response[output][message][content][0][text])两种方式我都在生产环境里用过。litellm 的优点是切换模型方便如果后面想换回 OpenAI 的模型只需要改一行代码。boto3 原生调用则更轻量依赖少适合对运行时体积敏感的 Lambda 函数。5.4 把成本控制在看得见的地方预算告警与账单分析AWS 的计费逻辑对新手来说最怕的不是用了贵的服务而是忘了关资源。一个没关的 EC2 实例、一个被流量打爆的 NAT Gateway、一个忘记清理的 S3 桶都能在月底账单上给你一个惊喜。建议所有新账号都做两件事。第一件在 Billing 控制台创建 Budget设置月度预算比如 100 美元并配置超过 50%、80%、100% 的预算阈值时发送邮件告警。第二件给所有生产资源打上标签比如EnvironmentProduction、Projectxxx。标签系统在月底看账单分摊成本时极其好用可以按项目维度拉出每个业务线到底烧了多少钱。还有一些容易被忽略的省钱细节。开发环境的 EC2 实例建议用 Stop 而不是 Terminate降低误删数据风险测试环境可以只在工作日期间定时启动和停止S3 的存储类别可以按访问频率设置生命周期规则把冷数据自动转成 Standard-IA 或 Glacier能省不少钱。6. 关于云厂商选型我把踩过的坑和判断标准一次性说清6.1 选云厂商之前先问自己三个问题我帮团队做选型咨询时从来不先聊技术对比而是先问三个问题第一你的核心用户群体在哪里数据合规要求是什么第二你的团队最熟悉哪套技术栈学习成本能不能被接受第三你最怕的是丢数据、宕机还是成本失控按优先级排序。这三个问题的答案不同最优解完全不同。比如一个面向东南亚的社交产品优先考虑的是区域覆盖、CDN 延迟和当地合规AWS 新加坡区域和 Lightsail/CDN 的组合就很合适。一个完全面向国内客户、以低代码开发为主的团队可能更适合国内云平台。一个重度依赖 Kubernetes 且对数据仓库要求高的团队Google Cloud 的 GKE 和 BigQuery 会明显提升研发效率。6.2 我的个人选型经验不同阶段用不同策略从创业公司的视角看云选型其实是一个动态决策过程。0 到 1 阶段我强烈建议选择生态最完善的那个平台也就是 AWS原因很简单——踩坑时搜到的资料最多社区答案最全这在人手紧缺的早期极其重要。产品真正跑起来、有了稳定收入之后再考虑是否要引入第二云或多云策略这时候有成本也有精力做精细化管理。我见过太多团队在 0 到 1 阶段就执着于“比价”和“极致成本优化”结果把大量时间花在云架构的拧巴优化上反而耽误了业务迭代。云平台的差价比不上业务早一天上线带来的收益这个账一定要算清。6.3 学 AWS 的最佳路径从一个小项目啃到基础设施即代码关于学习路径我建议不要一上来就考认证或者刷视频课而是从小项目入手。比如用 EC2 部署一个简单的 Web 服务然后用 S3 CloudFront 托管静态资源再用 Lambda API Gateway 做一个无服务器接口最后尝试用 Terraform 把这些资源全部用代码重新部署一遍。整个过程走完AWS 的 IAM 权限模型、网络隔离、计算存储的基本概念、基础设施即代码的套路就都串起来了。很多人学了 AWS 但还是“只会点控制台”本质上是没理解 AWS 的架构核心不是某个具体按钮而是 IAM 权限边界 VPC 网络拓扑 服务间访问链路的组合关系。用 Terraform 重建一遍 AWS 资源比在控制台点一百遍鼠标都更能帮你理解它内部的工作方式。6.4 最后分享一个极易踩坑的点别被“主流”带着走写了这么多 AWS 的领先优势最后我想反过来泼一盆冷水。选云平台最忌讳的就是单纯因为“AWS 是主流”所以无脑选 AWS。等账单涨到失控、等某个 SQL Server 兼容性问题难缠、等团队里没人会写 IAM 策略时你会发现“主流”这个词不会帮你解决任何实际问题。我的建议是主流的成熟平台确实是所有选项里最稳妥的起点但在项目起步阶段认真想一想团队的技术背景、业务的数据走向、预算的敏感度这三个变量再去做决定。云平台只是工具你的业务模型和团队能力才是最终的决定因素。这一点比记住任何市场份额数字都重要。