1つの間違ったコマンド、4時間：2017年のAmazon S3の話
2017年2月28日、入力を1つ打ち間違えたコマンドが、AmazonのS3ストレージサービスから意図より多くのサーバーを外し、多くのインターネットサービスを約4時間、遅くしたり止めたりしました。AWS自身の事後報告に沿って振り返り、削除の力を持つツールが備えるべき守りを引き出します。
これは実話ですが、私自身の話ではありません。AWS自身が公表した事後報告（末尾にリンク、直接読みました）に沿って振り返ります。報告はコマンドを実行した人の名前を挙げていないので、私も名前を付けず、その人が何を考えたかも推測しません。
この記事はGitLab 2017の話と1点で違います：これはバックアップが壊れていた話ではなく、1つの打ち間違いで、あまりに多くを外せるツールの話です。記事の時刻は、報告と同じ太平洋時間（PST）です。
先に要点#
- 2017年2月28日の午前9:37、S3チームの権限を持つメンバーが、課金に関わるサブシステムから少数のサーバーを外すコマンドを実行しました。入力の1つの打ち間違いで、意図より多くのサーバーが外れました。
- 外れたサーバーは、S3の中核の2つのシステム、インデックスと配置を支えていました。両方が完全に再起動される必要がありました。
- US-EAST-1のS3は、約4時間17分後の午後1:54にやっと正常に戻りました。
- 注目点：コマンドは作られたとおりに動いたのです。外しすぎを止めるものがなかっただけ。AWS自身のサービス状態の表示板も、S3に依存していました。
- AWSはツールを、よりゆっくり外し、最小を下回って外さないように変えました。
むずかしい言葉をやさしく#
| 用語 | やさしい意味 |
|---|---|
| Amazon S3 | AWSのクラウドのファイル保存サービス。非常に多くのサイトやアプリが使う。 |
| リージョン | ある地域にあるデータセンターのまとまり。US-EAST-1は、AWSの大きなリージョン。 |
| サブシステム | サービスの内部の、1つの仕事をする部分。 |
| インデックスのサブシステム | 保存された各オブジェクトの情報を持つ：どこにあるか。 |
| 配置のサブシステム | 新しいオブジェクトの保存先を選ぶ。インデックスに依存する。 |
| 影響範囲（ブラスト半径） | 1つの障害が、周りをどれだけ壊しうるか。 |
| 手順書（プレイブック） | 運用作業のために用意された手順。 |
1. いつもの運用作業#
その朝、S3チームは、US-EAST-1で遅く動く課金処理をデバッグしていました。権限を持つチームメンバーが、既存の手順書に従い、課金に関わるサブシステムから少数のサーバーを外し、効果があるか見ようとしました。
特に変わったことはありません。サブシステムからサーバーを外すのは、運用者の日常の仕事で、手順書もありました。大事な点です：これは、許された操作で、手順に従い、権限のある人が行ったものでした。
2. 午前9:37：入力の打ち間違い#
報告によると、コマンドは9:37に実行され、入力の1つが間違って入力されました。結果：意図より多くのサーバーが外れました。
報告は、どの入力か、どう間違ったか、なぜかを述べていません。私は推測しません。自信を持って言えるのは、ツールがその値を受け取って実行したことで、「このコマンドは何台を外し、それは安全か」を確かめる関門はなかったということです。
外れたサーバーは、課金のシステムでなく、2つの中核システムのものでした：
- インデックス： リージョン内のすべてのオブジェクトのメタデータと位置の情報を持つ。取得、一覧、書き込み、削除の依頼に必要。
- 配置： 書き込みの依頼で、新しいオブジェクトの保存先を割り当てる。インデックスが正しく動くことに依存する。
それだけの容量が外れると、両方が完全に再起動される必要がありました。
3. 再起動：何年もやっていなかったこと#
これは、報告の中で私が最も考える価値があると思う細部です。AWSは、大きなリージョンで、これらのシステムを何年も完全には再起動していなかったと書いています。その間にS3は大きく成長し、安全な再起動に必要なメタデータの整合性を確かめる安全確認が、再起動を予想より長くしました。
言い換えれば：復旧する力は、今の規模では一度も試されていなかったのです。GitLabの教訓と響き合います：復元を試したことのないバックアップは、使えるか分からず、実際の規模で動かしたことのない再起動の手順は、どのくらいかかるか分かりません。
4. 時系列#
すべて太平洋時間、2017年2月28日、US-EAST-1リージョン。
| 時刻 | 何が起きたか |
|---|---|
| 9:37 | コマンドが実行され、意図より多くのサーバーが外れる |
| 11:37 | サービス状態の表示板で、個別のサービスの状態を再び更新できる |
| 12:26 | インデックスのサブシステムに、取得、一覧、削除を処理できる容量が戻る |
| 午後1:18 | インデックスのサブシステムが完全に復旧 |
| 午後1:54 | 配置のサブシステムの復旧が終わり、S3が正常に動く |
9:37から午後1:54までは約4時間17分です。報告は、各再起動それぞれの所要時間を挙げていません。
5. 誰が影響を受けたか、そして表示板の皮肉な細部#
報告によると、影響を受けたサービスには、S3のコンソール、新しい仮想マシン（EC2）の起動、S3に保存されたスナップショットのデータが要るEBSボリューム、AWS Lambdaがありました。一部のサービスは、中断の間にたまった作業があり、回復に追加の時間が要りました。
皮肉な細部： AWSのサービス状態の表示板の管理コンソールも、S3に依存していました。11:37まで、個別のサービスの状態を更新できなかったので、AWSは、Twitterのアカウントとページ上部の文言で伝えるしかありませんでした。
一般的な教訓（私の推論）：障害を知らせるツールは、壊れているものそのものの上に置かない。
6. 1つの間違ったコマンドが、大きな障害になった理由#
報告から、1つの打ち間違いを4時間の中断に変えた5つの層が見えます。この読み方は私のものです。
| 層 | 報告が示すこと |
|---|---|
| 外しすぎを許すツール | 1つの打ち間違いで、意図より多くが外れ、止める最小がなかった。AWSは後にこの守りを加えた |
| 外すのが速すぎた | AWSは後に、よりゆっくり外すようツールを変えた |
| 大きな影響範囲 | リージョン全体の2つの中核システムで、多くの他のサービスが依存。AWSは後に、独立したセルに分けた |
| 実際の規模で試されていない復旧 | 何年も完全には行っていなかったため、再起動が予想より遅かった |
| 壊れたものに依存する報告ツール | 表示板はS3を使っていた。AWSは後に、複数のリージョンにまたがるよう変えた |
共通点：各層は、単独では妥当で、重なったときだけ障害になります。
7. AWSが直したこと#
報告によると：
- よりゆっくり外す。 容量を外すツールは、より低い速さで外すよう変えられました。
- 最小。 サブシステムを必要な最小容量より下げる削除をすべて遮る仕組みが加わりました。
- 他のツールの見直し。 AWSは、他の運用ツールに、同様の安全確認がないか調べています。
- 影響範囲を小さくし、復旧を短く。 サブシステムを独立したセルに分けます。年内の予定だったインデックスのサブシステムの分割は、前倒しですぐに始められました。
- 複数のリージョンにまたがって動く表示板。
全体として、AWSは誰かが打ち間違えるのを禁じることに重点を置かず、打ち間違いが大きな害を生めないようにすることに重点を置きました。
8. GitLabの話との比較#
2つは「1つの間違ったコマンド」という型を共有しますが、教訓の場所は違います：
| GitLab（2017年1月） | Amazon S3（2017年2月） | |
|---|---|---|
| 間違ったコマンド | 副サーバーでなく主サーバーのデータディレクトリを消した | 入力の打ち間違いで、意図より多くのサーバーが外れた |
| 主な弱点 | バックアップが使えず、データが失われた | 最小のないツール、大きな影響範囲、遅い再起動 |
| 公の場での対応 | 共有文書、ライブ配信、長い事後分析 | 事後報告とツールの変更 |
| 教訓 | 復旧は試されなければならない | 削除の力を持つツールには、関門と最小が要る |
合わせて：間違ったコマンドを打ちにくくし、その結果を小さくする。
9. 私が学ぶこと：外せるツールへの問い#
この部分は私の提案で、AWSの結論ではありません。 外す、消す、止めることができるツールを書く、または使うなら、問います：
- 最小はあるか？ ツールは、システムを安全な水準より下げる操作をすべて遮るか。
- 速度の制限はあるか？ ゆっくり外せば、運用者が間違いに気づく時間ができる。
- 事前の確認はあるか？ 一覧表示のみのモード：外す前に「これはN台を外す」。
- 影響範囲はどれだけか？ 1つの間違ったコマンドで、最大どれだけ壊れるか。
- 実際の規模で復旧を試したか？ システム全体を最後に再起動したのはいつか。
- 障害を知らせるツールは、独立して動くか？
- 危険な操作を、2人目が見られるか？
10. AIがツールを動かせるとき#
この話は2017年ですが、型はとても現代的です：外す力を持つツールが、間違った入力を受け取り、何も止めない。 AIエージェントでは、間違った入力は、誘導された指示から来るかもしれず、エージェントは「何かおかしい」とは感じません。
それがAIアプリのOWASP Top 10の**過剰な権限（LLM06）**です：過剰な機能、過剰な権限、過剰な自律。そこでの対策は、AWSの教訓と重なります：機能を限り、最小限の権限、影響の大きい行動は承認を求める。記事MCPとは何かはヒューズについて述べ、S3の最小こそ、1つのヒューズです。
11. バランスの取れた見方#
- 主な情報源は1つです。 私はAWS自身の報告に拠っており、報告はAWSの立場から書かれています。
- 報告は多くの細部を省いています。 名前も、具体的な打ち間違いの値も、各再起動の所要時間もないので、推測しません。
- 比較と「5つの層」の表は、私の読み方です。
- 障害は10年近く前のことです。 システムは大きく変わりましたが、原因（最小がない、大きな影響範囲、試されていない復旧、壊れたものに依存するツール）は、今もとても身近です。
- コマンドを実行した人がどう感じたかは分かりませんので、記事はそれを描きません。
12. 結論#
1つの打ち間違い、4時間、そしてインターネットの一部が遅くなりました。けれど、AWSが直すと選んだのは、「運用者に打ち間違えるなと言う」ことではありません。間違ったコマンドが外しすぎないようツールを、結果が小さくなるようシステムを直したのです。それが、最も学ぶ価値のある考え方です。
今日の小さな一歩：使っている、外す、または消すことができるツールを1つ見つけ、最小とプレビューのモードがあるか確かめてください。なければ、やることに加えます。
参考資料#
よくある質問
- 2017年2月28日にAmazon S3で何が起きましたか
- AWSの事後報告によると、太平洋時間の午前9時37分、遅い課金処理をデバッグしていたS3チームの権限を持つメンバーが、あるサブシステムから少数のサーバーを外すコマンドを実行しました。入力の打ち間違いで、より多くのサーバーが外れました。US-EAST-1のS3は午後1時54分にやっと正常に戻り、S3に依存する他の多くのサービスが影響を受けました。
- なぜ復旧に4時間かかったのですか
- 外れたサーバーは2つのサブシステムを支えていました：インデックス（S3のすべてのオブジェクトの情報を管理）と配置（新しいオブジェクトの保存先を割り当てる）。それだけの容量を外すと、両方の完全な再起動が必要になりました。AWSは、大きなリージョンでは、これらのシステムを何年も完全には再起動していなかったこと、S3の成長と、メタデータの整合性を確かめる安全確認のせいで、再起動が予想より長くかかったことを述べています。
- AWSはその後、何を直しましたか
- 容量を外すツールを、よりゆっくり外すよう変えました。サブシステムを、必要な最小容量より下げる削除をすべて遮る仕組みを加えました。AWSは、他の運用ツールにも同様の安全確認がないか見直し、サブシステムを独立したセルに分けて影響範囲を小さくし、サービス状態の表示板を、複数のリージョンにまたがって動くように変えています。
- この障害でデータは失われましたか
- 私がAWSの報告で読んだ範囲では、サービスの中断と復旧が書かれており、顧客データの損失は述べられていません。報告にあること以上は、断言しません。