Aws-S3 on Tarragonhttps://tarrragon.github.io/blog/tags/aws-s3/Recent content in Aws-S3 on TarragonHugo -- gohugo.iozh-TWTarragon (CC BY 4.0)Thu, 07 May 2026 00:00:00 +0000AWS S3 2017 US-EAST-1 Service Disruptionhttps://tarrragon.github.io/blog/backend/08-incident-response/cases/aws-s3/2017-us-east-1-service-disruption/Thu, 07 May 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/08-incident-response/cases/aws-s3/2017-us-east-1-service-disruption/<p>2017 年 AWS S3 us-east-1 事故的核心教訓是：內部操作工具若能快速移除共享子系統容量，單一命令輸入錯誤就會變成區域級控制面事故。這類事故的第一責任是限制操作 blast radius，再把恢復順序與通訊入口從受影響依賴中拆出。</p> <h2 id="事故摘要">事故摘要</h2> <p>AWS 在 2017-02-28 發生 Amazon S3 Northern Virginia（US-EAST-1）服務中斷。官方摘要指出，S3 團隊當時正在排查 billing system 進度偏慢問題；9:37AM PST，一位授權 S3 團隊成員依既有 playbook 執行命令，原本只要移除少量 billing 相關子系統 server，但其中一個輸入值錯誤，導致移除的 server set 比預期大。</p> <p>被移除的 server 同時支援 S3 的 index subsystem 與 placement subsystem。index subsystem 管理該 region 內所有 S3 object 的 metadata 與位置資訊，GET、LIST、PUT、DELETE 都依賴它；placement subsystem 負責新 object 的 storage allocation，PUT 還需要它才能運作。這兩個子系統被迫完整重啟，導致 S3 API 在重啟期間無法正常服務。</p> <h2 id="判讀訊號">判讀訊號</h2> <table> <thead> <tr> <th>訊號</th> <th>事故中代表什麼</th> <th>第一波決策價值</th> </tr> </thead> <tbody> <tr> <td>GET / LIST / PUT / DELETE 同時異常</td> <td>index subsystem 已成為共同故障點</td> <td>優先判斷 metadata / index 層，而非單一 API</td> </tr> <tr> <td>PUT 恢復晚於 GET / LIST / DELETE</td> <td>placement subsystem 仍未完成恢復</td> <td>對外通訊要分操作類型描述恢復狀態</td> </tr> <tr> <td>EC2 launch、EBS snapshot、Lambda 受影響</td> <td>S3 是多服務共享依賴</td> <td>incident scope 需要擴到 dependent services</td> </tr> <tr> <td>Service Health Dashboard 更新受阻</td> <td>狀態頁管理入口依賴受影響服務</td> <td>立即切到獨立通訊路徑</td> </tr> <tr> <td>重啟時間超過預期</td> <td>大型子系統多年未完整重啟與驗證</td> <td>回寫 recovery rehearsal 與 cell partition</td> </tr> </tbody> </table> <h2 id="事故路徑">事故路徑</h2> <ol> <li>S3 團隊排查 billing system 進度偏慢問題。</li> <li>授權成員依既有 playbook 執行移除少量 server 的操作命令。</li> <li>命令輸入值錯誤，移除的 server set 比預期大。</li> <li>被移除容量同時支援 index subsystem 與 placement subsystem。</li> <li>兩個子系統需要完整重啟，S3 API 在重啟期間無法正常服務。</li> <li>依賴 S3 的其他 AWS 服務在 US-EAST-1 同步受影響。</li> <li>AWS 先用 AWS Twitter feed 與 Service Health Dashboard banner text 溝通，直到 SHD individual service status 可以更新。</li> <li>index subsystem 先恢復足夠容量，再逐步恢復 GET / LIST / DELETE；placement subsystem 完成後，PUT 才恢復正常。</li> </ol> <p>這條路徑顯示：事故起點是內部操作工具缺少數量與容量下限保護，外部流量尖峰在此無關。真正放大事故的是共享子系統、區域依賴與通訊入口對同一服務的依賴。</p> <h2 id="可回寫控制面">可回寫控制面</h2> <table> <thead> <tr> <th>控制面</th> <th>這次事故暴露的缺口</th> <th>回寫方向</th> </tr> </thead> <tbody> <tr> <td>操作工具安全閘門</td> <td>單一輸入錯誤可快速移除過多容量</td> <td>對 remove / drain 類操作加速率、數量與 minimum capacity guardrail</td> </tr> <tr> <td>Shared subsystem blast radius</td> <td>billing 操作影響 index 與 placement</td> <td>對共享子系統建立 dependency map 與 blast radius review</td> </tr> <tr> <td>Recovery rehearsal</td> <td>大型子系統多年未完整重啟，恢復時間超過預期</td> <td>把 index / placement 類核心子系統納入定期 restart / restore rehearsal</td> </tr> <tr> <td>Cell partition</td> <td>大型 region 子系統恢復成本過高</td> <td>把核心子系統拆成較小 cell，降低單次恢復範圍</td> </tr> <tr> <td>Status page dependency</td> <td>SHD 管理入口依賴受影響服務</td> <td>將 incident communication 工具跨 region 與跨依賴部署</td> </tr> <tr> <td>Operation decision log</td> <td>事中需要記錄重啟順序與 API 恢復差異</td> <td>在 decision log 中分別記錄 index、placement 與 dependent services 狀態</td> </tr> </tbody> </table> <h2 id="下一步路由">下一步路由</h2> <ul> <li>觀測證據包： <a href="https://tarrragon.github.io/blog/backend/04-observability/observability-evidence-package/" data-link-title="4.20 Observability Evidence Package" data-link-desc="把 log、metric、trace、audit 與資料品質限制包成可交接證據">4.20 Observability Evidence Package</a></li> <li>實驗安全邊界： <a href="https://tarrragon.github.io/blog/backend/06-reliability/experiment-safety-boundary/" data-link-title="6.20 Experiment Safety Boundary" data-link-desc="定義 chaos、load test、DR drill 的 [blast radius](/backend/knowledge-cards/blast-radius/)、停止條件與權限約束">6.20 Experiment Safety Boundary</a></li> <li>穩態與恢復完成： <a href="https://tarrragon.github.io/blog/backend/06-reliability/steady-state-definition/" data-link-title="6.22 Steady State Definition" data-link-desc="在 chaos 與 failover 前先定義系統應維持的穩定狀態與可接受退化">6.22 Steady State Definition</a></li> <li>事故通訊： <a href="https://tarrragon.github.io/blog/backend/08-incident-response/incident-communication/" data-link-title="8.4 事故通訊與狀態更新" data-link-desc="建立內外部通報節奏與狀態更新格式">8.4 Incident Communication</a></li> <li>止血與回復： <a href="https://tarrragon.github.io/blog/backend/08-incident-response/containment-recovery-strategy/" data-link-title="8.3 止血、降級與回復策略" data-link-desc="把短期止血與正式回復拆成可執行步驟">8.3 Containment / Recovery Strategy</a></li> <li>事中決策紀錄： <a href="https://tarrragon.github.io/blog/backend/08-incident-response/incident-decision-log/" data-link-title="8.19 Incident Decision Log" data-link-desc="把事中假設、決策、證據、回退條件與責任人留下可復盤紀錄">8.19 Incident Decision Log</a></li> <li>證據回寫流程： <a href="https://tarrragon.github.io/blog/backend/08-incident-response/incident-evidence-write-back/" data-link-title="8.22 Incident Evidence Write-back" data-link-desc="把事故證據、決策與復盤結論回寫到 observability、reliability 與 runbook">8.22 Incident Evidence Write-back</a></li> </ul> <h2 id="引用源">引用源</h2> <ul> <li><a href="https://aws.amazon.com/message/41926/">Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region</a></li> </ul>2017 年 AWS S3 us-east-1 事故的核心教訓是：內部操作工具若能快速移除共享子系統容量，單一命令輸入錯誤就會變成區域級控制面事故。這類事故的第一責任是限制操作 blast radius，再把恢復順序與通訊入口從受影響依賴中拆出。

事故摘要

AWS 在 2017-02-28 發生 Amazon S3 Northern Virginia（US-EAST-1）服務中斷。官方摘要指出，S3 團隊當時正在排查 billing system 進度偏慢問題；9:37AM PST，一位授權 S3 團隊成員依既有 playbook 執行命令，原本只要移除少量 billing 相關子系統 server，但其中一個輸入值錯誤，導致移除的 server set 比預期大。

被移除的 server 同時支援 S3 的 index subsystem 與 placement subsystem。index subsystem 管理該 region 內所有 S3 object 的 metadata 與位置資訊，GET、LIST、PUT、DELETE 都依賴它；placement subsystem 負責新 object 的 storage allocation，PUT 還需要它才能運作。這兩個子系統被迫完整重啟，導致 S3 API 在重啟期間無法正常服務。

判讀訊號

訊號 事故中代表什麼 第一波決策價值
GET / LIST / PUT / DELETE 同時異常 index subsystem 已成為共同故障點 優先判斷 metadata / index 層，而非單一 API
PUT 恢復晚於 GET / LIST / DELETE placement subsystem 仍未完成恢復 對外通訊要分操作類型描述恢復狀態
EC2 launch、EBS snapshot、Lambda 受影響 S3 是多服務共享依賴 incident scope 需要擴到 dependent services
Service Health Dashboard 更新受阻 狀態頁管理入口依賴受影響服務 立即切到獨立通訊路徑
重啟時間超過預期 大型子系統多年未完整重啟與驗證 回寫 recovery rehearsal 與 cell partition

事故路徑

  1. S3 團隊排查 billing system 進度偏慢問題。
  2. 授權成員依既有 playbook 執行移除少量 server 的操作命令。
  3. 命令輸入值錯誤，移除的 server set 比預期大。
  4. 被移除容量同時支援 index subsystem 與 placement subsystem。
  5. 兩個子系統需要完整重啟，S3 API 在重啟期間無法正常服務。
  6. 依賴 S3 的其他 AWS 服務在 US-EAST-1 同步受影響。
  7. AWS 先用 AWS Twitter feed 與 Service Health Dashboard banner text 溝通，直到 SHD individual service status 可以更新。
  8. index subsystem 先恢復足夠容量，再逐步恢復 GET / LIST / DELETE；placement subsystem 完成後，PUT 才恢復正常。

這條路徑顯示：事故起點是內部操作工具缺少數量與容量下限保護，外部流量尖峰在此無關。真正放大事故的是共享子系統、區域依賴與通訊入口對同一服務的依賴。

可回寫控制面

控制面 這次事故暴露的缺口 回寫方向
操作工具安全閘門 單一輸入錯誤可快速移除過多容量 對 remove / drain 類操作加速率、數量與 minimum capacity guardrail
Shared subsystem blast radius billing 操作影響 index 與 placement 對共享子系統建立 dependency map 與 blast radius review
Recovery rehearsal 大型子系統多年未完整重啟，恢復時間超過預期 把 index / placement 類核心子系統納入定期 restart / restore rehearsal
Cell partition 大型 region 子系統恢復成本過高 把核心子系統拆成較小 cell，降低單次恢復範圍
Status page dependency SHD 管理入口依賴受影響服務 將 incident communication 工具跨 region 與跨依賴部署
Operation decision log 事中需要記錄重啟順序與 API 恢復差異 在 decision log 中分別記錄 index、placement 與 dependent services 狀態

下一步路由

引用源

]]>