Microsoft 利用 AWS 解決 GitHub AI 容量危機

Microsoft 整合 AWS 容量以穩定 GitHub

Microsoft 正將 Amazon Web Services (AWS) 的容量加入 GitHub 的基礎設施中，以防止因 AI 驅動的程式碼開發活動前所未有的激增而導致的服務中斷。這一戰略轉向發生在「代理開發」（agentic development）工作流——即 AI 代理自主生成程式碼、提交（commits）和拉取請求（pull requests）——使 GitHub 的基礎設施超出了其原定遷移至 Microsoft Azure 的計畫限制。

雖然 Microsoft originally intended to move GitHub fully to Azure by 2027，但機器生成的活動量迫使該公司採用多雲策略以確保彈性與規模。Microsoft 已確認將向多雲基礎設施進行更廣泛的轉向，儘管其官方聲明中並未明確點名 AWS。

代理開發對基礎設施的影響

GitHub 正經歷一條超過傳統有機增長的增長曲線，這主要是由以機器速度而非人類速度運作的 AI 代理所驅動的。

提交量呈指數級增長

GitHub COO Kyle Daigle 表示，commits 的數量預計在 2026 年達到 140 億次，較 2025 年的 10 億次大幅增加。這種規模對平台儲存程式碼、處理 pull requests、更新搜尋索引以及觸發自動化流程的能力造成了直接壓力。

容量需求快速擴張

GitHub CTO Vlad Fedorov 指出，平台的容量需求在短時間內發生了劇烈變化：

• October 2025: GitHub 開始了一項將容量增加 10 倍的計畫。
• February 2026: 公司決定需要針對 30 倍的規模進行設計。

這種加速歸因於在 2025 年 12 月下旬激增的代理開發工作流。儘管做出了這些努力，GitHub 2026 年 5 月的可用性報告指出有九起服務降級事件，其中包括 5 月 4 日因資料庫架構遷移（database schema migration）導致拉取請求、議題（issues）和 Git 操作發生連鎖反應，進而造成重大中斷。

Azure 容量限制與戰略風險

儘管 Microsoft 有龐大的資本支出——計畫在 2026 日曆年度投入約 1,900 億美元——但 Azure 的容量並非無限的資源池。它必須與 OpenAI 的需求、Microsoft Copilot、安全工作負載以及外部 Azure 客戶共同使用。

基礎設施作為瓶頸

Microsoft CFO Amy Hood 表示，公司預計在 2026 年底前都會面臨容量限制。這種內部稀缺性意味著即使是像 GitHub 的戰略資產也必須競爭 GPU、CPU 和儲存資源。使用 AWS 的決定是一種承認，即 AI 基礎設施的內部需求已超過了 Microsoft 自身的雲端部署時程。

AI 原生開發工具的威脅

可靠性問題已從技術上的小麻煩轉變為產品威脅。知名開發者，例如 HashiCorp 共同創辦人 Mitchell Hashimoto，已公開批評 GitHub 的可靠性，表示在經歷重大停機時間後，該平台「不再是一個適合嚴肅工作的地方」。

這份不穩定性為 Cursor 和 Anthropic 的 Claude Code 等 AI 原生開發工具創造了機會。如果 GitHub 無法為 AI 輔助開發維持一個穩定的控制平面（control plane），它將面臨失去高價值維護者與企業用戶的風險，進而損害其網路效應。

行業內「橋接容量」的趨勢

GitHub-AWS 的安排反映了更廣泛的行業趨勢，即超大規模雲端供應商（hyperscalers）向競爭對手購買容量以滿足突發的 AI 需求。

• Google and SpaceX: Google 據報導已同意從 2 ext{026} 年 10 月到 2029 年 6 月，每月向 SpaceX 支付 9.2 億美元以獲取運算容量。

這些交易表明，AI 需求目前正跑在世界最大數據中心規劃與建設週期之前，迫使即使是主要的雲端供應商也必須尋求外部「橋接容量」以維持服務穩定性。