微软正在借用亚马逊云服务（AWS）的算力来支撑GitHub的运行——不是因为Azure不够强，而是AI编码代理的暴增速度超出了微软的迁移计划。
据Business Insider援引知情人士消息，2025年底以来GitHub上的AI代理开发活动急剧攀升，平台频繁出现服务降级。微软原本计划在2027年前将GitHub全部迁移至自己的Azure云，但现在不得不临时租用竞争对手AWS的容量来消化溢出的负载。微软发言人确认了“多云策略”，但没有点明AWS，称“自2025年底以来代理开发活动出现不可思议的激增”，正在加速Azure迁移的同时探索多云方案以获取弹性和规模。
为什么微软宁愿用对手的云
2018年微软以75亿美元收购GitHub时，CEO萨提亚·纳德拉的承诺是：GitHub保持开发者第一、开放平台、可部署到任何云。八年后，这个承诺变成了GitHub自己的基础设施选择——当平台出现大规模中断时，运营风险比“给AWS送钱”的面子问题更紧迫。
数据可以说明压力有多大。GitHub首席运营官Kyle Daigle在4月写道，2026年平台的代码提交量预计将达到140亿次，而2025年仅为10亿次。这个量级不仅意味着存储和版本控制，还意味着每次提交都可能触发检查、合并请求、搜索索引、自动化工作流和协作通知。GitHub CTO Vlad Fedorov在4月的可用性更新中透露，2025年10月团队开始执行容量提升10倍的计划，到2026年2月已经意识到需要按30倍规模来设计。他在5月的报告中提到，Azure上承载的巨石架构流量已从2月的8%升至40%，Git流量达30%，仓库复制达99%，但有效容量在四个月内仅翻了一番以上。
问题不仅是算力。GitHub需要一边迁移、分片和加固一个成熟的协作平台，一边应对AI工具生成的大量机器操作冲击老旧共享系统。5月发生的9起故障中，包括一次因数据库表模式迁移引发的连锁中断，波及了拉取请求、议题、Actions、Webhook和Git操作。
可靠性正在成为产品威胁
对GitHub来说，最致命的不是单纯的服务停机，而是割裂开发者工作流。当拉取请求、合并代码、运行持续集成这些核心操作卡住时，开发者不会把它看作云容量问题，而是认为“GitHub不行了”。
HashiCorp联合创始人、Ghostty终端模拟器创建者Mitchell Hashimoto在4月公开表示，在使用平台18年后计划迁离GitHub，原因是GitHub“不再适合严肃工作”，每天被封锁数小时。他的离开很有信号意义：类似HashiCorp创始人这样的高信号开源维护者，其行为会带动大量开发者。如果这些用户开始把GitHub的可靠性视为税负，竞争对手无需在网络效应上完全超越，只需要在GitHub做不好的工作流上做到足够可靠。
Business Insider同时报道，GitHub面临来自Cursor、Anthropic的Claude Code等AI工具的竞争。微软内部去年末的一次会议讨论了如何改造GitHub以应对这些产品。这意味着平台停摆的后果已经变了：GitHub不再是简单的代码托管站，而是微软AI辅助软件开发的“控制面”。一次宕机就可能让开发者转向对手。微软租用AWS，是这一轮AI军备竞赛中基础设施层面最直白的妥协。
编注：信源为Business Insider专访及GitHub官方可用性报告，材料聚焦基础设施瓶颈与多云策略，未涉及财务成本与合同条款。