クラウドの大規模障害から学ぶ、備えておくこと

クラウドの大規模な障害から学べることは、「事業者の障害は起こり得る」という前提に立ち、自社のシステムが何に頼っているかを知り、頼り先が止まったときの動き方を決めておくことです。クラウドの事業者は、大きな障害の後に、経過と原因と再発の防止策をまとめた報告を公表しています。この記事では、公表された報告だけをもとに、利用者が備えておくことを整理します。

公表された報告から何を読むのか

事業者の報告で読むのは、どの仕組みの不具合が、どの順番で、ほかのサービスに広がったかです。原因の技術の細部より、「頼っている仕組みが止まると、自分では止まっていないはずのものまで動かなくなる」という広がり方が、利用者にとっての学びになります。

AWS は、影響の大きかった障害について、事後の報告（Post-Event Summary）の一覧を公開しています。Microsoft Azure も、状況の履歴のページで過去の障害の振り返りの報告（Post Incident Review）を公開しています。Google Cloud の報告は、下の2025年6月の障害の節で取り上げます。

出典：AWS Post-Event Summaries（AWS）、Azure status history（Microsoft）

2025年10月の AWS の北バージニアのリージョンの障害

2025年10月19日から20日にかけて（米国太平洋夏時間）、AWS の北バージニアのリージョン（us-east-1）で、データベースのサービスである DynamoDB を中心とした障害が起きました。AWS の報告によると、DynamoDB の DNS を管理する自動の仕組みに潜んでいた競合の不具合により、リージョンの窓口の名前に対する DNS の記録が空になりました。

影響は DynamoDB にとどまりませんでした。仮想サーバー（EC2）の起動の仕組みが DynamoDB に頼っていたため、新しいサーバーを起動できない、起動しても通信ができない状態が続きました。負荷分散の仕組み（NLB）でも接続のエラーが起き、Lambda、Amazon Connect、IAM の管理画面へのログインなど、多くのサービスに影響が及びました。報告では、全体の障害は約14時間半に及んだとされています。

AWS は再発の防止策として、該当の DNS の自動の仕組みを世界中で止めて不具合を直すこと、負荷分散の仕組みが障害のときに一度に外せる容量を制限する仕組みを入れること、EC2 の復旧の手順を試す試験を加えることなどを挙げています。

出典：Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region（AWS）

2025年6月の Google Cloud の障害

2025年6月12日（米国太平洋夏時間）、Google Cloud・Google Workspace などで、外部からの API の呼び出しにエラーが増える障害が起きました。Google の報告によると、API の管理を担う Service Control に5月に加えた機能に、適切なエラーの処理がなく、機能を切り替えるスイッチ（フィーチャーフラグ）でも守られていませんでした。そこへ空の項目を含む方針のデータが入り、世界中に数秒で複製されたことで、Service Control が落ちて再起動をくり返しました。

報告では、Google の状況のページや、一部の利用者の監視の道具も Google Cloud の上で動いていたため止まり、最初の公表は不具合が始まってから約1時間後になった、とされています。

Google は再発の防止策として、重要な仕組みへの変更をフィーチャーフラグで守ること、エラーの処理を改めること、再試行の間隔をランダムに広げていく仕組み（指数バックオフ）を使っているかを点検すること、世界中に複製するデータの変更を段階的に広げること、Google Cloud が止まっていても監視と状況の発信を続けられるようにすることを挙げています。

出典：Google Cloud Service Health の障害の報告（2025年6月12日。Google Cloud）

2021年9月の東京のリージョンの Direct Connect の障害

国内の例として、2021年9月2日に、AWS の東京のリージョンで、専用線の接続サービス（Direct Connect）に接続の不安定とパケットの損失が起きました。AWS の報告によると、原因はネットワーク機器の OS に潜んでいた不具合で、7時30分ごろに始まり、13時42分に解消しました。

報告では、影響は東京のリージョンへの Direct Connect の通信に限られ、インターネット経由の接続や、Site-to-Site VPN は影響を受けなかったとされています。そのうえで、Direct Connect の予備として VPN を使っている利用者がいることにも触れています。

出典：Summary of AWS Direct Connect Event in the Tokyo (AP-NORTHEAST-1) Region（AWS）

利用者が備えておくこと

3つの報告から読み取れるのは、障害が1か所から広がること、状況が分かるまでに時間がかかること、復旧にも時間がかかることです。利用者の側では、次の点を確かめておきます。

自社のシステムが頼っているものを知る：自社のシステムが、どのリージョンの、どのサービスに頼っているかを一覧にします。自分で使っていないつもりのサービスでも、使っている機能の裏側で頼っていることがあります。

1つの場所、1本の経路に頼らない：止まると困るシステムは、複数のアベイラビリティゾーンに分けて置き、社内との接続も予備の経路を用意しておくことを検討します。配置の考え方はリージョンとアベイラビリティゾーンで、複数のクラウドを使う考え方はマルチクラウドは必要かで説明しています。

復旧のときに、新しく作る操作に頼りすぎない：AWS の報告では、障害の間、新しいサーバーの起動ができない時間が長く続きました。AWS の Well-Architected は、障害のときにもふだんと同じ動き方を保つ「静的安定性」を勧めています。障害が起きてから資源を新しく起動する方法は、その操作の仕組みと、影響を受けていない場所に十分な資源があることの両方に頼る、と説明されています。

出典：REL11-BP05 Use static stability to prevent bimodal behavior（AWS）

状況を知る手段を、別の経路にも持つ：事業者の状況のページが見られないこともあります。自社の監視を、監視の対象と同じ基盤だけに置かないこと、事業者からの通知を受ける窓口を複数にしておくことを検討します。

判断の基準を事前に決める：事業者の障害のとき、復旧を待つのか、別の場所に切り替えるのか、お客様にいつ知らせるのかを、誰が判断するかを決めておきます。基準と連絡の流れは障害が起きたときの一次対応で、目標の決め方は復旧の目標（RTO・RPO）の決め方と、復旧の訓練で説明しています。

事業者との契約や稼働率の保証で、どこまでが補償の対象になるかは、契約の内容によります。個別の判断は弁護士などの専門家にご確認ください。

当社のご支援

アメリア・テクノロジーのクラウドの構築と運用管理では、いまの構成が何に頼っているかの洗い出し、止まると困るシステムの配置と予備の経路の設計、事業者の障害のときの判断の基準と手順書づくりをご支援しています。事業者の障害の情報は、監視と通知の仕組みで受け、業務への影響と対応を月次の報告でお伝えします。まずは無料のクラウドの自己診断で、いまの備えをおおまかに確かめることもできます。