タグ: outage

Cloudflareで大規模障害が発生 ― 世界的なインターネットインフラの脆弱性が再び顕在化

2025年11月18日、インターネットサービスの基盤を提供するCloudflare社で、世界的規模の障害が発生しました。CloudflareはCDN（コンテンツデリバリーネットワーク）やDNS、セキュリティサービスを手掛け、多数の企業やオンラインサービスの可用性を支える存在です。そのため、本障害はSNSやクラウドサービス、暗号資産取引所を含む幅広いサービスで影響が確認され、インターネット全体に少なからぬ混乱をもたらしました。

発生状況と影響範囲

障害は英国時間11時30分頃から多発的に報告されました。
モロッコなど複数地域でウェブサイトへアクセス不能となり、HTTP 500系エラーが多くのサイトで表示されました。

影響が確認された主なサービスは以下の通りです。

  • X（旧Twitter）：多くのユーザーでアクセス障害。
  • OpenAIサービス：部分的な不具合が発生。
  • 暗号資産関連の複数フロントエンド：一時的な機能停止。

Cloudflareユーザーだけではなく、同社のダッシュボードやAPIにも障害が及び、顧客側では対応が困難な状況が続きました。

原因に関する推測

Cloudflareは「複数顧客に影響を与える問題を認識しており調査中」と公式ステータスで発表しています。
障害と同日にデータセンター保守作業が予定されていたとの報道もありましたが、それが直接原因かは現時点で特定されていません。

エンジニア・ビジネス視点での論点

今回の障害は、以下のような重要な示唆を与えます。

第一に、「単一インフラ依存リスク」です。Cloudflareは世界中のウェブアクセスにおけるクリティカルパスとなっており、その障害が短時間でも経済的影響は甚大になり得ます。

第二に、障害伝播の速さと範囲です。アプリケーション側に問題がなくても、インフラ層の障害がサービス停止に直結します。近年はAPI連携による依存関係が増加しており、下層の停止が上層の連鎖停止を引き起こしやすくなっています。

第三に、顧客コミュニケーション体制の重要性です。運営側は、サービス状況を迅速に通知できるステータスページやSNS発信を整備しなければ、追加の混乱と信用失墜を招くおそれがあります。

企業に求められる今後の対策

本件を踏まえて検討すべき事項は明確です。

  • マルチCDN／フェールオーバー設計
    単一プロバイダ障害時にも最低限の機能を維持する構成を準備すること。
  • 監視と自動切替の強化
    エラー率上昇時に自動でバックアップルートへ切替できる運用を整備すること。
  • 障害インシデント対応手順整備
    社内外へ迅速に状況共有できる体制を確実に持つこと。

インターネットに依存したビジネスが当たり前となった現在、「可用性」は競争力の中核です。障害が発生した際にどれだけ被害を抑え、信頼を維持できるかが企業価値を左右します。

おわりに

Cloudflareの大規模障害は、世界的なWebサービスが共通して依存するインフラの脆弱性を改めて示すものとなりました。障害が長期化していることから、復旧後には詳細な原因説明と再発防止策が公表されることが想定されます。企業側としてはその内容を的確に把握し、自社のインフラ設計や運用体制に反映させることが重要です。

一方で、この種の障害がもたらすもう一つの懸念として、「依存関係の露呈」が挙げられます。どのサイトやアプリケーションがどのインフラサービスに依存しているかは、通常は意図的に秘匿される場合も多いですが、障害時には影響サービスが一斉に停止することで、その依存構造が半ば強制的に可視化されてしまいます。これは、攻撃者が次の標的を選定する際の手掛かりとなる可能性があるため、セキュリティ上のリスクが高い現象といえます。

つまり、障害の原因究明と対策強化はもちろん、サービス依存情報が露出することを前提としたリスク管理も今後は求められます。冗長構成の導入と併せて、障害時の情報公開方針、攻撃面の拡大抑止といった観点からの対策も総合的に検討することが、企業のレジリエンス維持につながります。

参考文献

Microsoft Azureで大規模障害発生 ― Microsoft 365やXboxにも影響、原因は構成変更ミス

日本時間2025年10月30日午前1時頃からMicrosoft Azureで大規模な障害が発生しました。これにより、Microsoft Azure、Microsoft 365、Minecraft、XboxなどのMicrosoftが提供する製品やサービスだけでなく、Starbucks、costco、Krogerといった大手企業のシステムにも波及しました。

Microsoftの発表によると、「Azure Front Door（AFD）における誤った構成変更（inadvertent configuration change）」が原因とのことで、この設定変更が DNS ルーティングに影響を与え、Azure Portal や関連サービスにアクセス不能状態を引き起こしたものと見られています。

発生から対応までを時系列に並べると以下のようになります。

  1. 2025年10月30日 午前1時頃（日本時間）
    障害発生を確認
  2. 2025年10月30日 04:19（日本時間）
    「last known good configuration（直前の正常構成）」のデプロイが完了し、ノード復旧を開始し、「今後4時間以内に完全復旧を見込む」と告知
  3. 2025年10月30日 08:20（日本時間）
    Azure側が「recovery to happen by 23:20 UTC（＝8:20 JSTまでに復旧見込み）」と明記
  4. 2025年10月30日 09:40（日本時間）
    最終更新で「AFDサービスが98%以上の可用性を回復し、完全復旧を9:40 JSTに見込む」と発表

日本では、発生した時間自体は深夜ですが、回復に午前9時過ぎまでかかったため、朝一でメールを受信しようとしたらメールが受信できないなどの影響を受けた方もいたかと思います。

クラウド障害のインパクトの大きさ

先日のAWSの障害もDNSに起因するものでした。

AWSで大規模障害 ― マルチAZ構成でも防げなかった理由と今後の対策

DNSで障害が起きるとネットワークを前提としたシステムは非常に脆いことがわかります。加えて、クラウドベンダーが提供して責任を持つ部分であるため、DNSで障害が起きると複数のサービスに影響がおよび、それらのサービスを使用している複数の企業が影響を受けます。

この点については、各企業ごとに対策することが難しい場合が多いです。クラウド上でシステムを運用しているならマルチクラウドという選択肢はあるにはあります。ただし、コストとトレードオフになるため、事業規模によっては選択肢できない場合もあります。

また、IaaSではなくPaaSサービスを利用している場合はそういった選択肢も難しい場合があります。例えば、Microsoft 365で障害が起きた場合、他のベンダーでメールサービスを継続するということは不可能です。インフラを管理しないことに対するトレードオフでもあるので、どうしても障害を起こしたくないのであればインフラを管理する必要がありますが、クラウドベンダー並の可用性を実現できる企業は数えるほどしかないでしょう。

もう一つはこれが誤設定によるものであるという点です。過去に発生した大規模障害においても、誤った設定を適用した場合や操作ミスといった単純ミスによるものであったことがありました。これはMicrosoft Azureに限ったものではなく、他のクラウドベンダーでも起きています。

具体的な内容については公表されていないので想像になりますが、本当にただの凡ミスだったかもしれません。もしかすると、想定していなかった挙動だったのかもしれません。いずれにせよ、本当のところはわからないので一方的に「テストをしていないのではないか」と断ずるのは総計です。実際、DNS周りは想定しない挙動をする場合があるので、本番同等の環境を用意するのは現実的ではないため、テスト環境では問題ないことを確認した上で適用したが、予想しない挙動を示していたのかもしれません。

おわりに

以前のAWSの障害、今回のAzureの障害から言えるのは、

  • 代替の選択肢を持つこと
  • バックアップを3-2-1ルール取得し、復元できることを定期的に確認しておくこと

が重要であるということです。

代替の選択肢を持つというのは、メールの例で言えばメールが唯一の連絡手段になってしまうとメールが使用できなくなったときに業務が完全にとまってしまうので、それ以外の手段を持っておくというです。メールの例でいえば、電話やチャットなど複数の手段があるのが普通だと思いますのでそれほど問題ありません。しかし、空港での搭乗手続きが完全に電子化され、手動での搭乗手続きの手段が失われていたらどうでしょうか？ゲート搭乗機に障害が発生すると運休せざるを得なくなってしまいます。そういった意味では電子化は優れた選択肢である一方でそこに障害が発生したときに、人間の手による代替ができるようになっていることが重要です。

前述の話は機能に障害が発生した場合ですが、データにアクセスできなくなる場合やロストする場合について対策が必要です。古典的な手段ではありますが、現代でも有効な3-2-1ルールに則って、3つのデータコピーを保持し、2種類の異なるメディアに保存し、そのうち1つをオフサイト（地理的に離れた場所）に保管することは非常に有効です。

ただし、いくらバックアップが無事だといってもそこから復元できなければ意味がありません。バックアップを用意していても、いざ復元しようとしたら戻せなかったということは今に始まった話ではなく昔からずっと起きている話です。古くはテープにバックアップしたけどそこから復元できなかったなどということはよくある話ですし、2020年にはバックアップに不備があり障害が起きたときにバックアップから復元できずに売買停止が起きたこともありました。

避難訓練と同じで、災害発生時のマニュアル確認のための訓練やバックアップから復元できるかのリハーサルは義務付けられているものを除くと行っていないケースが多いように思います。日常的にテスト環境を構築するのにバックアップを使っているという場合であればバックアップ自体は使用可能だt思いますが、高度に自動化されている場合は手動でもできるのかといった点や3-2-1ルールに則ってバックアップが完全に失われないかなどを見直すことも重要です。

「愚者は経験に学び、賢者は歴史に学ぶ」とはよく言ったもので、こういった他社の事例からもしっかりと教訓を得ることは重要です。

参考文献

AWSで大規模障害 ― マルチAZ構成でも防げなかった理由と今後の対策

2025年10月20日（日本時間）、Amazon Web Services（AWS）において大規模なサービス障害が発生しました。障害は主に米国東部リージョン（US-EAST-1）で発生し、世界中の多くのオンラインサービスやアプリケーションが一時的に停止しました。

本稿では、今回の障害の概要と影響範囲、マルチAZ構成を採用していても防げなかった理由、そして今後の設計指針について整理します。

障害の概要

AWS公式ステータスによれば、障害はUS-EAST-1リージョンにおける複数サービス（DynamoDB、Lambda、API Gateway、STSなど）で発生し、エラー率の急上昇およびレイテンシの増大が確認されました。

この影響により、Snapchat、Fortnite、Signal、Perplexity、Alexaなど、多数の世界的サービスが同時にダウンしました。AWSはその後「主要な根本原因を特定し、主要機能は緩和された（fully mitigated）」と発表していますが、一部では依然として遅延やキュー残りが発生していると報じられています。

マルチAZ構成でも防げなかった理由

AWSが推奨するマルチAZ構成は、高可用性を実現するための基本的な冗長化手法です。しかし今回の障害では、マルチAZ構成を採用していても影響を受けたケースが確認されました。その理由は、障害のレイヤーが「AZ内」ではなく「リージョン全体」に及んでいたためです。

制御プレーン障害が発生

今回の障害は、個別のデータセンターやハードウェア障害ではなく、AWSの制御プレーン（サービス間のAPI、認証、ルーティングなど）に影響したとみられています。

その結果、各AZの物理的な可用性は保たれていても、API呼び出しやリソース管理を行う中核部分が機能しなくなり、アプリケーションレベルでの可用性が確保できなくなりました。

マルチAZ構成の限界

マルチAZ構成は、AZ単位の停電・ネットワーク断などに対しては効果的ですが、制御プレーンや内部ネットワーク層に障害が発生した場合には対応できません。

このため、同一リージョン内の冗長化では「論理的単一障害点（Single Point of Failure）」が残るという設計上の限界が明確に浮き彫りになりました。

今後の対策と設計指針

今回の障害を踏まえると、ランニングコストと求める耐障害性のバランスをどう考えるかが構成設計の分岐点となります。冗長化を強化するほど可用性は向上しますが、運用コストや構成の複雑さも増大します。以下では、代表的な構成パターンと考慮点を整理します。

マルチAZ構成＋別リージョンでのコールドスタンバイ構成

平常時は単一リージョンで稼働させ、障害時にのみ別リージョンの環境を立ち上げる方式です。コストを抑えつつ大規模障害に備えられますが、復旧までに数時間単位のダウンタイムが発生します。

  • メリット：低コストで広域障害への備えが可能
  • デメリット：RTO（復旧時間目標）が長く、人的操作が必要

マルチAZ構成＋別リージョンでのウォーム／ホットスタンバイ構成

別リージョンにも一定のリソースを常時稼働させておき、障害時に迅速に切り替える構成です。ウォームは部分稼働、ホットは完全稼働を指します。コストと可用性のバランスを柔軟に調整できます。

  • メリット：自動フェイルオーバーが可能でRTOを短縮できる
  • デメリット：維持コスト・設計複雑度が上昇

マルチリージョン構成

複数リージョンで同時稼働させるアクティブ／アクティブ構成です。トラフィック分散や地理的冗長化に優れ、リージョン全体の障害にも耐えられますが、最も高コストかつ複雑です。

  • メリット：最高水準の可用性と応答性能を確保
  • デメリット：整合性維持とコストが大きな課題

マルチクラウド構成

AWS単独ではなく、GCPやAzureなど複数のクラウドを併用する構成です。ベンダー依存リスクを分散できますが、各クラウドのAPI差異・運用統合コストが課題になります。

  • メリット：クラウド全体の障害に対する強靭性を確保
  • デメリット：開発・運用の複雑化、スキル要求の増大

災害対策設計（DR: Disaster Recovery）の最低要件

いずれの構成を採る場合でも、最低限、別リージョンでサービスを再開できるDR設計を持つことが不可欠です。データバックアップ、DNSフェイルオーバー、クロスリージョンレプリケーションなど、迅速に代替リージョンへ切り替える仕組みを整備しておくべきです。

おわりに

今回のAWS障害は、クラウド基盤における高可用性設計の限界を改めて浮き彫りにしました。マルチAZ構成は依然として有効な手法であるものの、それだけで「クラウドは止まらない」と断言することはできません。過去にはAzureやGoogle Cloud Platform（GCP）でも大規模な障害が発生しており、大手クラウドベンダーであっても絶対的な安心・安全が保証されるわけではありません。

また、ランサムウェア被害の事例では、バックアップ自体が無事であったにもかかわらず、復旧がうまくいかなかったケースも報告されています。したがって、単にバックアップを取得するだけでなく、少なくとも年に一度はバックアップからの復旧訓練を実施し、実際に復元できることを検証することが重要です。

今回の事象は、制御プレーンやサービス間依存を含むリージョン単位の障害リスクを前提とした設計、およびバックアップ運用の実効性確保の重要性を改めて認識させるものとなりました。

参考文献

モバイルバージョンを終了