AWS

はじめに 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. ...

クラウドサービス、特にAmazon Web Services (AWS) は、現代のデジタル社会に不可欠な基盤です。しかし、その巨大で複雑なシステムは、時として私たちの想像を超える形で障害を発生させ、ビジネスや社会活動に深刻な影響を及ぼします。 2025年10月20日、AWSは再び大規模な障害に見舞われ、多くのサービスが長時間にわたり停止しました。 この出来事は、クラウドへの依存が深化する現代社会において、そのリスクといかに向き合うべきかという課題を改めて浮き彫りにしました。 本記事では、この直近の障害も念頭に置きつつ、特にインパクトが大きかった過去のAWS東京リージョンでの障害を振り返り、そこから得られる教訓を深く掘り下げます。単なるインシデント報告の要約ではなく、これらの経験がクラウド時代のシステム設計やリスク管理に何を問いかけているのかを考察します。 2019年8月 AWS東京リージョン大規模障害：冷却バグがMulti-AZを破った日 2019年8月23日、AWS東京リージョン（ap-northeast-1）で発生した大規模障害は、多くの開発者やインフラ技術者にとって「Multi-AZ構成は万能ではない」という厳しい現実を突きつけました。 発生事象と原因 2019年8月23日午後、東京リージョンの一つのアベイラビリティゾーン（AZ）で、多数のEC2サーバーとそれに付随するEBSボリュームが利用不能に陥りました。 AWSの公式発表によると、原因はデータセンターの冷却制御システムにあったバグでした。このバグにより冷却機能が低下し、サーバー群がオーバーヒート（過熱）を防ぐために自動的にシャットダウンしたのです。これは単一AZ内で発生した物理的な設備の問題でした。 影響：デジタルからフィジカルへ この障害は、ソーシャルゲームから企業の基幹システムまで、幅広いサービスに影響を与えました。特に注目すべきは、その影響がデジタル空間に留まらなかった点です。 物理世界への衝撃：ドコモ・バイクシェアの事例 象徴的だったのが、ドコモ・バイクシェアのサービス停止です。AWS上で稼働していた認証・管理システムが停止した結果、以下の連鎖反応が起きました。 認証・制御システムの停止: 自転車の貸し出しや返却を管理するシステムが機能不全に。 物理的な行動の阻害: ユーザーがアプリで解錠操作をしても、システムからの「解錠コマンド」が自転車のスマートロックに届かない。 社会インフラの麻痺: 結果として、多くのユーザーが自転車を借りることも、利用中の自転車を返却することもできなくなり、移動手段が絶たれるという物理的な影響が発生しました。 この事例は、クラウドがスマートロック、IoTデバイス、モビリティといった物理世界と連携するサービスにおいて、いかに重要な生命線となっているかを痛感させるものでした。 教訓：Multi-AZ神話の崩壊 この障害から得られる最大の教訓は、Multi-AZ構成への過信は禁物であるという点です。なぜ単一AZの障害が、AZをまたいで冗長化していたはずの多くのシステムに影響を与えたのでしょうか。 制御プレーンへの依存: EC2インスタンスの起動や停止、EBSの着脱などを管理する「制御プレーン」の一部は、複数のAZにまたがって共通で稼働しているコンポーネントが存在します。障害が発生したAZの制御機能に問題が波及し、正常なAZの操作にも影響が出た可能性が指摘されています。 不完全な冗長化設計: アプリケーションが、意識しないうちに特定のAZのリソース（例：特定のEBSボリュームやNATゲートウェイ）に依存しているケースがありました。障害が発生したAZのリソースを掴んだまま離さなかったり、フェイルオーバーの仕組みが正しく機能しなかったりした結果、サービス全体が停止しました。 この障害は、インフラ層の冗長化だけでなく、**アプリケーション自身が障害を検知し、自律的に回復する能力（フォールトトレランス）**がいかに重要であるかを浮き彫りにしました。 2021年9月 AWS Direct Connect障害：ネットワークの要が引き起こした連鎖的停止 2021年9月2日の早朝に発生した障害は、企業のオンプレミス環境とAWSを繋ぐ専用線サービス「AWS Direct Connect」が震源地となりました。 発生事象と影響 この障害により、Direct Connectを利用していた多くの企業で、オンプレミス環境とAWS間の通信が不能になりました。 金融機関への打撃: 三菱UFJ銀行やみずほ銀行などで、インターネットバンキングやスマートフォンアプリ、一部ATMが利用できなくなるなど、深刻な影響が出ました。 社会インフラの麻痺: 航空会社の国内線チェックインシステムや、企業の基幹業務（貨物追跡、受発注システムなど）が停止し、経済活動に広範囲な影響を及ぼしました。 教訓：オンプレミスとの接続点のリスク Direct Connectは、安定した広帯域の通信を実現する一方で、障害発生時には**単一障害点（Single Point of Failure）**になり得るというリスクを露呈しました。 この障害からの教訓は、クラウドと外部環境を接続するネットワーク経路の重要性です。対策としては、複数のDirect Connect接続による冗長化や、バックアップとしてのVPN接続を準備しておくことが不可欠となります。 まとめ：過去の障害から学ぶ、これからのクラウド戦略 AWSの過去の障害は、私たちに多くの重要な教訓を与えてくれます。 障害は「起こるもの」と心得る: 100%の可用性を保証するクラウドは存在しません。障害発生を前提としたシステム設計、運用体制、そして組織文化を構築することが最も重要です。 設計原則の再点検: Multi-AZ/Multi-Region: 本当にアプリケーションレベルでAZ障害を乗り越えられる設計になっているか？ フォールトトレランス: サーキットブレーカー、適切なリトライ、フォールバック処理など、アプリケーション自身が回復する仕組みは十分か？ 依存関係の最小化: 特定のコンポーネントやサービスへの依存が、予期せぬボトルネックになっていないか？ 来るべき日に備える: 障害は必ずまた起こります。その日に備え、障害の迅速な検知、原因の切り分け、そして顧客や関係者への透明性のあるコミュニケーション計画を準備しておくことが、信頼を繋ぎ止める鍵となります。 クラウドの恩恵を最大限に享受するためには、そのリスクを正しく理解し、過去の失敗から学び、より堅牢で回復力のあるシステムを構築し続ける努力が不可欠です。