本サイトの記事や画像はAIが公的資料や報道を整理し制作したものです。ただし誤りや不確定な情報が含まれることがありますので、参考の一助としてご覧いただき、実際の判断は公的資料や他の報道を直接ご確認ください。
米Amazon傘下のAWSが10月23日、19日から20日にかけて起きた大規模障害の概要と再発防止策を公表し、謝罪した。主戦場はN. Virginia（us-east-1）。根本原因はDynamoDBのDNS管理で生じた潜在的な競合状態で、誤った空のDNSレコードが適用され、広範な接続断が連鎖したと説明している。
US-EAST-1で何が起きたのか
月曜の午後、開発現場の監視画面に赤が増えた。開始は10月20日 15:49。N. Virginiaの複数サービスでエラー率とレイテンシーが跳ね上がり、認証やAPI呼び出しが不安定になった。復旧の歩みは段階的で、完全な正常化が確認されたのは10月21日 07:01とされる。
16:26にはトリガーがDynamoDBのリージョンエンドポイントに対するDNS解決問題だと特定された。18:24にDNSの是正が行われ、徐々に応答が戻り始めたが、その後はEC2のインスタンス起動系に滞りが生じ、基盤の回復作業は続いたとみられる。
ネットワーク負荷分散のヘルスチェックにも障害が波及し、LambdaやCloudWatchなどで接続障害が広がった。ヘルスチェックの回復は10月21日 01:38。最終復旧後もしばらくは一部サービスでバックログ処理が続いたという。
つながらない理由—DNSと依存の連鎖
AWSは、根本原因がDynamoDBの自動DNS管理に潜む競合状態だったと説明した。DNS Plannerが作る計画をDNS EnactorがRoute 53へ反映する設計の中で、誤って空のDNSレコードがリージョンのサービスエンドポイントに適用された。自動修復も作動せず、接続不可が広がった構図である。
DynamoDBは顧客アプリだけでなくAWS内部のコントロールプレーンにも深く組み込まれている。インスタンス起動系やNLBのヘルスチェックが参照することで、DNS障害が制御系の機能不全を誘発した。外部報道ではNLB監視の不具合を焦点化する見方もあった。
可用性ゾーンを跨いでも、リージョンレベルのDNSや制御系で躓けば影響は避けにくい。冗長化の単位をどこに置くかという設計課題が浮かぶ。今回の足音は、マルチAZだけでは吸収しきれない事象の存在をあらためて示したと映る。
AWSが示した手当てと約束
AWSは再発防止と回復短縮へ複数の変更を進めている。DNS PlannerとDNS Enactorの自動化を世界的に無効化し、競合状態の修正と誤適用を防ぐ保護策を追加するまで再稼働させないという。NLBにはAZフェイルオーバー時の削除容量を抑える速度制御を入れる方針だ。
EC2ではDroplet Workflow Managerの回復ワークフローを検証する追加テストを構築し、既存のスケール試験を補強する。またデータ伝播系のスロットリングを改善し、待機キューの大きさに応じて着信処理をレート制限する仕組みを導入し、高負荷下の健全性を守る狙いである。
これらの説明と謝罪は10月23日に公開された。AWSは影響の大きさを認め、「学びを可用性向上に生かす」との姿勢を示した。現時点で確認されている範囲では、全サービス横断の検証と追加対策の検討を継続しているとされる。
