--- title: "クラウドの大規模障害から学ぶ、備えておくこと｜アメリア・テクノロジー株式会社" url: https://www.ameliatechnology.co.jp/blog/lessons-from-cloud-outages/ description: "クラウドの事業者は、大きな障害の後に経過と原因の報告を公表しています。AWS と Google Cloud の公表された報告から、障害がどう広がったのかを整理し、利用者が自社の構成で確かめておくこと、状況を知る手段、判断の基準の決め方を説明します。" updated: 2026-11-14 publisher: "アメリア・テクノロジー株式会社" --- # クラウドの大規模障害から学ぶ、備えておくこと クラウドの事業者は、大きな障害の後に経過と原因の報告を公表しています。AWS と Google Cloud の公表された報告から、障害がどう広がったのかを整理し、利用者が自社の構成で確かめておくこと、状況を知る手段、判断の基準の決め方を説明します。 2026.11.14 [クラウドと運用](https://www.ameliatechnology.co.jp/blog/category/cloud/) 執筆 [石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/)（グループCTO） クラウドと運用（CLOUD & OPERATIONS）のコラム ## この記事の要点 - 公表された報告では、1つの仕組みの不具合が、それに頼るほかのサービスへと広がっていく経過が示されています。自社のシステムが何に頼っているかを知っておくことが出発点です。 - Google Cloud の2025年6月の障害では、事業者の状況のページや一部の利用者の監視の道具も同じ基盤の上にあり、最初の公表まで約1時間かかりました。状況を知る手段を、別の経路にも持っておきます。 - 1つのリージョンや1本の接続にすべてを頼らない構成と、障害のときに誰が何を判断するかを、事前に決めておきます。 クラウドの大規模な障害から学べることは、「事業者の障害は起こり得る」という前提に立ち、自社のシステムが何に頼っているかを知り、頼り先が止まったときの動き方を決めておくことです。クラウドの事業者は、大きな障害の後に、経過と原因と再発の防止策をまとめた報告を公表しています。この記事では、公表された報告だけをもとに、利用者が備えておくことを整理します。 ## 公表された報告から何を読むのか 事業者の報告で読むのは、どの仕組みの不具合が、どの順番で、ほかのサービスに広がったかです。原因の技術の細部より、「頼っている仕組みが止まると、自分では止まっていないはずのものまで動かなくなる」という広がり方が、利用者にとっての学びになります。 AWS は、影響の大きかった障害について、事後の報告（Post-Event Summary）の一覧を公開しています。Microsoft Azure も、状況の履歴のページで過去の障害の振り返りの報告（Post Incident Review）を公開しています。Google Cloud の報告は、下の2025年6月の障害の節で取り上げます。 出典：[AWS Post-Event Summaries（AWS）](https://aws.amazon.com/premiumsupport/technology/pes/)、[Azure status history（Microsoft）](https://azure.status.microsoft/en-us/status/history/) ## 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）](https://aws.amazon.com/message/101925/) ## 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）](https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW) ## 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）](https://aws.amazon.com/message/17908/) ## 利用者が備えておくこと 3つの報告から読み取れるのは、障害が1か所から広がること、状況が分かるまでに時間がかかること、復旧にも時間がかかることです。利用者の側では、次の点を確かめておきます。 **自社のシステムが頼っているものを知る**：自社のシステムが、どのリージョンの、どのサービスに頼っているかを一覧にします。自分で使っていないつもりのサービスでも、使っている機能の裏側で頼っていることがあります。 **1つの場所、1本の経路に頼らない**：止まると困るシステムは、複数のアベイラビリティゾーンに分けて置き、社内との接続も予備の経路を用意しておくことを検討します。配置の考え方は[リージョンとアベイラビリティゾーン](https://www.ameliatechnology.co.jp/blog/region-availability-zone-design/)で、複数のクラウドを使う考え方は[マルチクラウドは必要か](https://www.ameliatechnology.co.jp/blog/multi-cloud-pros-cons/)で説明しています。 **復旧のときに、新しく作る操作に頼りすぎない**：AWS の報告では、障害の間、新しいサーバーの起動ができない時間が長く続きました。AWS の Well-Architected は、障害のときにもふだんと同じ動き方を保つ「静的安定性」を勧めています。障害が起きてから資源を新しく起動する方法は、その操作の仕組みと、影響を受けていない場所に十分な資源があることの両方に頼る、と説明されています。 出典：[REL11-BP05 Use static stability to prevent bimodal behavior（AWS）](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html) **状況を知る手段を、別の経路にも持つ**：事業者の状況のページが見られないこともあります。自社の監視を、監視の対象と同じ基盤だけに置かないこと、事業者からの通知を受ける窓口を複数にしておくことを検討します。 **判断の基準を事前に決める**：事業者の障害のとき、復旧を待つのか、別の場所に切り替えるのか、お客様にいつ知らせるのかを、誰が判断するかを決めておきます。基準と連絡の流れは[障害が起きたときの一次対応](https://www.ameliatechnology.co.jp/blog/cloud-incident-first-response/)で、目標の決め方は[復旧の目標（RTO・RPO）の決め方と、復旧の訓練](https://www.ameliatechnology.co.jp/blog/rto-rpo-and-recovery-drills/)で説明しています。 事業者との契約や稼働率の保証で、どこまでが補償の対象になるかは、契約の内容によります。個別の判断は弁護士などの専門家にご確認ください。 ## 当社のご支援 アメリア・テクノロジーの[クラウドの構築と運用管理](https://www.ameliatechnology.co.jp/service/cloud/)では、いまの構成が何に頼っているかの洗い出し、止まると困るシステムの配置と予備の経路の設計、事業者の障害のときの判断の基準と手順書づくりをご支援しています。事業者の障害の情報は、監視と通知の仕組みで受け、業務への影響と対応を月次の報告でお伝えします。まずは無料の[クラウドの自己診断](https://www.ameliatechnology.co.jp/diagnosis/cloud/)で、いまの備えをおおまかに確かめることもできます。 - クラウド - 障害対応 - 可用性 - BCP ## この記事に出てくる用語 - [クラウド](https://www.ameliatechnology.co.jp/glossary/cloud/) - [AWS（Amazon Web Services）](https://www.ameliatechnology.co.jp/glossary/aws/) - [Microsoft Azure](https://www.ameliatechnology.co.jp/glossary/azure/) - [Google Cloud](https://www.ameliatechnology.co.jp/glossary/google-cloud/) - [リージョンとアベイラビリティゾーン](https://www.ameliatechnology.co.jp/glossary/region-availability-zone/) - [データベース](https://www.ameliatechnology.co.jp/glossary/database/) - [DNS](https://www.ameliatechnology.co.jp/glossary/dns/) - [サーバー](https://www.ameliatechnology.co.jp/glossary/server/) この記事を書いた人 [石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/) グループCTO インターネットの黎明期から、ホスティング事業の立ち上げや、インフラ・セキュリティのプロジェクトに携わってきました。現在は、AWS・Azure へのクラウド移行の支援と、業務アプリケーションの要件定義から実装までを担っています。 このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。 ## あわせて読みたい - [Windowsサーバーと Active Directory を Azure へ移すときの考え方](https://www.ameliatechnology.co.jp/blog/windows-ad-to-azure/) - [Google Cloud を選ぶ場面。データ分析と Google Workspace とのつながり](https://www.ameliatechnology.co.jp/blog/when-to-choose-google-cloud/) - [Well-Architected の柱で、いまの構成を確かめる](https://www.ameliatechnology.co.jp/blog/well-architected-review/) [クラウドと運用のコラムを見る](https://www.ameliatechnology.co.jp/blog/category/cloud/) [コラムの一覧に戻る](https://www.ameliatechnology.co.jp/blog/) ## 次の一歩 ### クラウドの構築と運用を任せる AWS・Microsoft Azure・Google Cloud の設計・構築・移行から、監視・運用・セキュリティまでを一つのチームで受け持ちます。監視は仕組みで24時間365日自動に回し、原因の調査と再発の防止は当社が担います。 [クラウドの構築と運用管理を見る](https://www.ameliatechnology.co.jp/service/cloud/) ### クラウドの状態を、無料で確かめる 15の設問に答えると、構成と管理・権限・守り・障害への備え・費用と体制の5つの分野の点数と、最初に取り組むことをまとめたレポートをその場でお届けします。 [クラウドの自己診断（無料）を受ける](https://www.ameliatechnology.co.jp/diagnosis/cloud/) ## ご関心に合わせて、お選びください。 [情報を集めている方へ会社案内、AI開発の例、セキュリティ診断の報告書の見本をお送りします。資料をダウンロード](https://www.ameliatechnology.co.jp/download/)[課題が見えている方へオンラインで30分、お話をうかがいます。費用はかかりません。無料で相談する](https://www.ameliatechnology.co.jp/contact/)[進め方を決めたい方へ2〜4週間で、優先順位と計画をまとめるAI活用の診断です。診断について見る](https://www.ameliatechnology.co.jp/pricing/#diagnosis) --- 出典：アメリア・テクノロジー株式会社「クラウドの大規模障害から学ぶ、備えておくこと｜アメリア・テクノロジー株式会社」 https://www.ameliatechnology.co.jp/blog/lessons-from-cloud-outages/