AWS S3大障害（2017）— 1つのタイポ

何が起きたか（日時・影響範囲）

2017年2月28日午前（米太平洋時間、PST）、Amazon S3 の us-east-1（北バージニア）リージョンでオブジェクト操作 API が約4時間応答不能になりました。発端は障害ですらありません。S3 課金システムの処理遅延をデバッグしていた権限ある S3 チームのメンバーが 9:37、確立済みプレイブックに沿い「課金処理が使うサブシステムのサーバーを少数切り離す」コマンドを実行した際、入力値の1つを誤り（いわゆるタイポ）、意図をはるかに超えるサーバーを削除しました。外れたサーバー群は、課金とは別のインデックスとプレースメントの2サブシステムを支えていました。

影響は S3 に閉じず、同リージョンで S3 に依存する S3 コンソール、EC2 の新規インスタンス起動、スナップショット読み出しを要する EBS、Lambda に波及し、S3 を配信基盤に使う世界中のサービスが停止・劣化しました。

タイムライン

時刻はすべて 2月28日の PST です。

• 9:37 — コマンド実行。両サブシステムが容量不足に陥り、フル再起動を要する状態に
• 発生〜11:37 — AWS サービスヘルスダッシュボード（SHD）の個別ステータスが更新不能。Twitter の @AWSCloud とバナー文で告知
• 12:26 — インデックスが十分な容量を回復し、GET・LIST・DELETE の処理を再開
• 13:18 — インデックスが全面復旧
• 13:54 — プレースメントが復旧し PUT も正常化。依存サービスは滞留分を消化しつつ順次回復

根本原因の技術解説

S3 リージョン内部の要は、次の2つのサブシステムです。

容量削除そのものは S3 開始以来の日常運用で、両サブシステムはかなりの容量喪失に顧客影響ほぼゼロで耐える設計です。しかし今回は削除量が許容範囲を超え、双方がフル再起動を要しました。決定的だったのは所要時間です。AWS 自身が「大規模リージョンで両サブシステムを完全再起動したのは数年ぶり」と認めており、その間に S3 は急成長し、プロセス起動とメタデータ整合性を検証する安全チェックが想定を大幅に超えました。事後、ツールには次のガードレールが入りました。

# 改修後のガードレールの考え方（擬似コード）
if requested_removal > current_capacity - min_required_capacity:
    reject("最低容量を下回る削除は実行しない")
else:
    remove_slowly(requested_removal)  # 一括ではなく低速に切り離す

なぜ防げなかったか

横にスクロール

手順は守られていました。実行者は権限を持ち、コマンドは確立済みプレイブック由来です。破られたのは「人間は正しい値を入力する」という暗黙の前提で、ツールには削除量のレート制限も最低容量チェックもなく、パラメータ1つの誤りの影響範囲が事実上無制限でした。もう1つは復旧時間の想定劣化です。部分的な容量喪失への耐性は検証済みでも、フル再起動という経路は数年間実地で試されておらず、サービスの成長分だけ所要時間が静かに伸びていました。

教訓（原則として一般化）

• 運用ツールにガードレールを内蔵する: 破壊的操作には最低容量・レート制限・妥当性チェックをツール側で強制し、安全性を人の注意力に置かない。AWS は他の運用ツールも同様に監査した
• セル分割でブラスト半径と復旧時間を縮める: サービスを小さなセルに分割すれば、最大規模のサブシステムでも復旧プロセスを丸ごとテストできる。AWS はインデックスの追加分割を前倒しした
• 復旧時間はサービスの成長とともに再検証する: フェイルオーバーだけでなくフル再起動も定期的に演習し、想定復旧時間を実測で更新する
• 通知・監視経路の依存を分離する: ステータスページや監視系は監視対象と独立に動く構成にする

共有基盤で障害がどう波及するかの前提はクラウドを、安全な変更管理・運用自動化の原則はDevOpsを参照してください。

一段で言うと

1つの入力ミスが世界最大級のストレージを約4時間止めましたが、AWS の総括はタイポした個人を責めていません。誤入力を無害化できなかったツール、規模に追随していなかった復旧時間の想定、監視対象に依存した通知経路——直したのはこのシステム側の3点です。ヒューマンエラーは前提条件であって根本原因ではない。この事故が業界に残した最大の教訓です。