はじめに

2025/10/20のAWSの大規模障害から、2日目の朝が過ぎ、色々と見えてきました。ITmediaの記事によれば、原因や経緯は以下のように説明されています。

AWSによれば、今回の障害は「リージョンのDynamoDBサービス（注：AWSのデータベースサービス）エンドポイントのDNS解決の問題」が原因だったという。同社は20日午後6時ごろに問題を解決したものの、今度はDynamoDBに依存するEC2インスタンスの起動システムに問題が発生。対応するうちにトラフィックを分散する「Network Load Balancer」にも問題が生じ、再びDynamoDBなど複数サービスに影響したため、EC2インスタンスの起動など一部サービスの操作を一時的に抑制して復旧に当たったとしている。

DNSのSPoF化

とはいえ、この事実はかなりな、ナンセンスさを内包しています。本来、DNSは冗長な権威サーバー群によって提供され、キャッシュも活用されるため、単一のサーバーやソフトウェアがダウンしてもシステム全体は生き残るように設計されています。しかし、AWSの報告は、DynamoDBというクリティカルな内部サービスのDNS解決が、特定の脆弱なコンポーネントに集中し、それが停止することで、誰も住所を見つけられない状態、すなわち　「内部の単一障害点（SPOF）」　になっていたことを示しています。

認証基盤への影響の軽視

DynamoDBの停止は、IAMなど認証基盤の裏側にも影響しました。この認証基盤がDNSに依存していた、あるいはDNSが停止した時のフェイルオーバー（切り替え）の仕組みが不十分だったこともナンセンスです。

AWSは、 「誰がアクセスしているか」 という最も重要な制御システムを、DNSという単一障害のリスクから十分に隔離できていなかったことになります。

復旧時の二次災害（NLBの問題）

さらにナンセンスなのは、DNS問題を解決した後、今度はNLB（Network Load Balancer）の設計が、回復したDynamoDBへのリトライ・ストームに耐えきれず、再びサービスに影響を与えた点です。

これは、AWSのエンジニアが 「自社のトラフィック分散機構が、自社のサービスから発生する負荷（リトライ）で崩壊する」 という最悪のシナリオを十分に想定できていなかったことを示唆しています。

秘伝のたれ：文書化されない知識の蔓延

今回のAWS大規模障害、特に 「内部DNSの設計ミス」と「DynamoDBとNLBの連鎖崩壊」という「話にならなすぎる」原因は、巨大なクラウドインフラ内部に「文書化されていない秘伝のたれ（Undocumented Tribal Knowledge）」 が横行していることの、動かぬ証拠です。「秘伝のたれ」とは、特定のエンジニアやチームだけが知っている、システムの機能に不可欠だが公式には文書化されていない知識、調整、あるいは非標準的な設定を指します。

実際に、The Registerの記事に目を覆いたくなるような記述があります。

“It’s always DNS” is a long-standing sysadmin saw, and with good reason: a disproportionate number of outages are at their heart DNS issues. And so today, as AWS is still repairing its downed cloud as this article goes to press, it becomes clear that the culprit is once again DNS. But if you or I know this, AWS certainly does.

And so, a quiet suspicion starts to circulate: where have the senior AWS engineers who’ve been to this dance before gone? And the answer increasingly is that they’ve left the building — taking decades of hard-won institutional knowledge about how AWS’s systems work at scale right along with them.

AWSほどの巨大組織が急速に成長・肥大化する過程で、新しいサービスやエンジニアが増える一方で、 「なぜこの設定が必要なのか」「このコンポーネントを動かすと何が壊れるのか」といった暗黙知（秘伝のたれ） が共有されず、システムがブラックボックス化した結果と言えます。

構造的な問題を回避するために

この構造的な問題を回避するには、組織的な知識の「再獲得」 が必要です。単なる精神論ではなく、具体的な仕組みとして導入しなければなりません。

1. 徹底したドキュメンテーション文化

全ての設計、変更、設定には、その理由（Why）を明記することを義務付けるべきです。「とりあえず動くから」という設定は技術的負債の温床となります。コードレビューと同様に、ドキュメントレビューも徹底し、第三者が読んでも理解できる状態を維持することが不可欠です。

2. SRE（Site Reliability Engineering）原則の導入

Googleが提唱するSREは、信頼性をソフトウェアエンジニアリングの問題として捉え、解決するアプローチです。SLO（Service Level Objective）を設定し、エラーバジェット内で開発を行うことで、信頼性と開発速度のバランスを取ります。また、トイル（手作業）を徹底的に自動化し、人間が介在するミスを減らすことも重要です。

3. 障害対応訓練（ゲームデー）の定期実施

「計画された障害」を意図的に起こし、システムがどのように振る舞うか、そして対応チームがドキュメントやツールを頼りに正しく動けるかを確認する訓練です。これにより、「秘伝のたれ」に頼らない復旧プロセスを確立し、未知の障害に対する対応能力を高めることができます。

4. 知識共有の仕組み化

ペアプログラミング、モブプログラミング、社内勉強会、RFC（Request for Comments）文化などを通じて、個人の持つ暗黙知をチームの形式知へと変換する努力が求められます。特に、シニアエンジニアが持つ経験や知識をいかに若手に継承していくかが、組織の持続可能性を左右します。

まとめ：クラウド利用者が得るべき教訓

今回の障害は、AWSという巨大なクラウドプロバイダーでさえ、基本的な設計原則を見失い、組織的な課題を抱えている可能性を示唆しています。我々クラウド利用者は、以下の点を再認識する必要があります。

  • クラウドは魔法の箱ではない: クラウドの裏側にも、人間が設計・運用する複雑なシステムが存在し、障害は起こり得る。
  • 単一障害点のリスク評価: 特定のリージョンやサービスに依存しすぎていないか、自社のシステム構成を再評価する。
  • マルチクラウドやハイブリッドクラウドの検討: ミッションクリティカルなシステムにおいては、単一のプロバイダーに依存しないアーキテクチャの検討も重要になる。

結局のところ、「秘伝のたれ」に頼るシステムは、いつか必ず破綻します。文書化と知識共有を徹底し、属人性を排除する地道な努力こそが、真に堅牢なシステムを築く唯一の道と言えるでしょう。