Cloudflareが​現在、​大規模な​世界的障害に​直面しており、​DNS解決、​CDNトラフィック、​その​他複数の​主要ネットワークサービスに​影響が​出ています。​この​問題は​ 2025年11月18日の​早朝に​発生し、​OpenAI、​X、​Canvaを​はじめと​する​多くの​大規模プラットフォームに​広く​影響しました。​Cloudflareが​復旧作業を​進めている​間、​ウェブサイトは​読み込みの​遅延、​エラーメッセージ、​または​完全に​応答しない​状況が​見られます。​本記事では、​現在起きている​ことと​ウェブサイトを​稼働させ続ける​ために​今すぐできる​対処法を​解説します。​ Cloudflare に​今何が​起きているのか Cloudflareは、​2025年11月18日午前 6時40分​（米東部​時間）​ごろに​始まった​大規模な​世界的障害を​調査していると​発表しました。​この​障害に​より、​複数地域で​エラー率が​急増。​ユーザーからは​HTTP500エラー、​API呼び出しの​失敗、​Cloudflareダッシュボードへ​アクセスできないなど、​多数の​報告が​寄せられています。​Reuters、​AP News、​Tom’s Hardwareに​よると、​Cloudflareの​CDNや​プロキシに​依存している​多くの​サイトが​読み込めなくなりました。​OpenAI、​X、​Canva などの​主要サービスでも、​タイムアウトや​コンテンツの​欠落、​Cloudflareの​challengeページに​誘導される​エラーが​目立ちました。​ Cloudflareの​CEOは​異常な​トラフィックと​CPU 使用率の​急上昇が​プライマリ・セカンダリ両方の​システムに​影響を​与えたと​説明しています。​Financial Times に​よれば、​Cloudflareの​ネットワークは​世界の​ウェブトラフィックの​20% 以上を​扱っている​ため、​その​影響範囲は​非常に​広範です。​一部の​地域では​回復の​兆しが​見られる​ものの、​完全に​安定するまで​断続的な​障害が​続く​可能性が​あります。​ な​ぜ​多くの​サービスが​同時に​停止したのか 今回の​障害は​Cloudflareの​グローバルネットワークの​複数の​基盤レイヤーに​影響しています。​その​ため、​互いに​無関係な​多くの​サービスが​同時に​ダウンしています。​地域ごとに​程度は​異なる​ものの、​多くの​障害は​次の​ 4 分野に​集約されます。​ 特に​大きな​影響が​見られる​サービス: DNS解決 ドメインが​解決されず、​NXDOMAINや​SERVFAILが​断続的に​発生。​サーバーが​稼働していても、​ウェブサイトが​表示されなくなります。​ CDNと​エッジ配信 読み込みの​遅延、​コンテンツ欠落、​522/523エラーなどが​発生し、​エッジロケーションが​正常に​応答しない​状況が​続きます。​ APIと​Workers レイテンシ増加、​実行失敗、​リクエストの​ドロップなど、​Cloudflareの​コンピュートやルーティング層の​不安定さが​影響します。​ Zero Trustと​Email Routing 認証や​アクセス制御、​メール​書き換えが​不安定に​なり、​ログイン遅延や​メール遅配が​発生します。​ これらの​障害に​より、​バックエンドが​正常でも​ウェブサイトが​「落ちている」ように​見える​ケースが​多数発生しています。​API が​正常に​動作しなくなったり、​エッジ性能の​低下で​サイト全体が​遅くなったりする​ため、​Cloudflareを​基盤と​している​企業では、​顧客アクセスや​社内業務が​大きく​妨げられる​可能性が​あります。​ ウェブサイトを​稼働させ続ける​ための​緊急対策 Cloudflareに​依存している​ウェブサイトや​ API は、​復旧を​待たずに​自力で​オンライン状態を​取り戻すことができます。​以下は、​Cloudflare の​不安定な​レイヤーを​避け、​重要な​トラフィックを​迂回させる​ための​手順です。​ 1. Cloudflare DNSを​使用している​場合 一時的に​ Cloudflare DNS を​切り​替える​ことで、​多くの​サイトは​すぐに​復旧できます。​ 対応方​法: ドメインレジストラ​（GoDaddy、​Namecheap、​MatBao、​PAVietnam など）の​デフォルトネームサーバーへ​戻す または​Amazon Route 53 に​切り替える​ A、​AAAA、​CNAME、​MX、​TXT など、​既存の​ DNSレコードを​そのまま​再設定する​ これに​より、​安定した​ DNSに​切り​替わり、​Cloudflareが​復旧するまで​安全に​サイトを​稼働できます。​ 2. Cloudflare Proxy または​CDNを​利用している​場合 Cloudflare の​オレンジクラウド​（プロキシ）は、​大規模障害時に​最も​影響が​出やすい​部分です。​ 次の​対応が​有効です: プロキシを​OFF に​して​「DNS Only」に​変更する​ または​別の​DNSプロバイダ経由で​サーバーの​IPを​直接指す​ これに​より​Cloudflareの​エッジを​完全に​迂回し、​オリジンサーバーへ​直接アクセスできるようになります。​ 3. Workers、​Email Routing、​Zero Trust に​依存している​場合 これらの​サービスも​不安定に​なる​可能性が​あります。​ 一時的な​回避策: 元の​メールプロバイダ​（Google Workspace、​Microsoft 365 など）の​MXへ戻す APIは​Workersを​経由せず、​バックエンドへ​直接ルーティング Cloudflareに​依存する​Zero Trustポリシーは​一時停止 注意点 DNS反映には​数分から​最大1時間かかる​場合が​あります Cloudflareの​ゾーンを​削除しない​こと​（復帰が​複雑に​なります）​ トラフィックの​多い​サイトは、​切り​替え後​すぐに​負荷テストを​推奨 将来の​障害に​防ぐ方​法 Cloudflare は​通常は​非常に​信頼性が​高い​ものの、​このような​単一障害点に​よる​大規模な​影響が​起こり得ます。​DNS、​CDN、​セキュリティ、​APIなどを​Cloudflareに​集中させている​企業は、​継続性を​重視した​設計が​必要です。​ DNS冗長化の​構築 DNSは​障害時に​最も​影響が​出やすい層です。​複数の​DNSプロバイダを​併用する​ことで、​どちらかが​落ちても​ドメインを​解決できます。​ 信頼できる​DNSプロバイダ: Amazon Route 53 Google Cloud DNS NS1 Akamai DNS Made Easy マルチDNS構成に​より、​いずれかの​ネットワークに​不安定さが​発生した​場合でも、​トラフィックを​即座に​切り替える​ことが​可能に​なります。​ 複数の​CDNを​併用する​ Cloudflareに​依存している​部分が​多い​ほど、​障害時の​影響は​大きくなります。​静的アセットや​トラフィックの​一部を​他の​CDN に​逃が​す設計が​効果的です。​ 例: Fastly、​AWS CloudFront、​Akamai 障害を​前提とした​設計 現代の​アプリケーションは、​プロバイダーが​予期せず​障害を​起こす​可能性を​前提に​設計する​必要が​あります。​耐障害性の​高い​アークテクチャは、​重要な​サービスを​複数の​レイヤーに​分散させ、​特定の​ベンダーへの​全面的な​依存を​避ける​ものです。​ 実践的な​改善策: 緊急時に​備えて、​直接IPアクセス経路を​確保する​ Cloudflare外に​静的資産の​コピーを​保存する​ エラーが​急増した​際に​トラフィックを​切り​替えられる​ヘルスチェックを​使用する​ コア認証や​重要な​APIを​単一の​プロキシ経由で​ルーティングしない​ 事前に​準備を​整える​ことで、​世界規模の​障害が​顧客や​社内業務に​影響を​及ぼすリスクを​低減できます。​ まとめと​Haposoftサポートできる​こと 今回の​Cloudflare 障害は、​最も​信頼される​インターネットプロバイダーで​さえ、​大規模な​障害を​経験する​可能性が​ある​ことを​改めて​示しています。​DNS、​CDN、​セキュリティプロキシなどの​コアレイヤーが​停止すると、​その​影響は​数分以内に​数百万の​ユーザーや​企業に​波及します。​最良の​防御策は​事前の​準備です：冗長化、​フェイルオーバールーティング、​耐障害性の​高い​インフラ構築。​ もし現在も​ウェブサイトや​システムに​問題が​発生している​場合、​または​将来的に​同様の​障害を​避けたい​場合、​Haposoftは​すぐに​サポートに​入る​ことが​可能です。​ Haposoftが​今すぐ​ウェブサイトの​安定化を​サポートします 弊社チームは​以下の​対応を​支援いたします： ドメインの​Cloudflare DNSからの​切り​替え Route 53または​レジストラでの​DNSレコード再設定 Cloudflareプロキシの​迂回および​トラフィックの​サーバーへの​直接ルーティング Cloudflareの​完全復旧を​待たない​APIアクセスおよび​メールフローの​回復 プロセス全体を​丁寧に​サポートし、​ウェブサイトを​できるだけ早く​オンラインに​戻す​お手伝いを​いたします。​ Haposoftの​AWSソリューションで​信頼性を​向上 緊急対応に​留まらず、​Haposoftは​エンドツーエンドの​AWSコンサルティングを​提供し、​より​強固で​耐障害性の​高い​システム構築を​支援します。​弊社の​AWSサービスには​以下が​含まれます： マルチDNSおよび​マルチリージョンアーキテクチャの​設計 Route 53の​ヘルスチェックおよび​フェイルオーバールーティング設定 高​可用性CDN代替と​しての​CloudFront導入 重要サービスの​耐障害性AWSインフラへの​移行 モニタリング、​アラート、​DR​（災害復旧）​設計 もし​今日のような​障害に​耐えられる​プラットフォームを​構築したい​場合、​Haposoftは​主要プロバイダーに​障害が​発生しても​オンラインを​維持できる​クラウドアーキテクチャの​設計を​サポートいたします。

2025年10月20日、​Amazon Web Services​（AWS）の​米国東部​（バージニア北部）​リージョン​「us-east-1」で​大規模な​障害が​発生し、​EC2、​S3、​Cognito、​SageMakerなど​60以上の​サービスが​停止しました。​世界中の​企業や​アプリケーションに​影響が​及び、​クラウドアーキテクチャや​監視体制、​リカバリ戦略の​見直しが​求められる​事態と​なりました。​ 障害の​概要 2025年10月20日、​AWSの​米国東部​（バージニア北部）​リージョン​「us-east-1」で​大規模な​障害が​発生しました。​us-east-1は​AWSの​グローバルネットワークに​おいて​最も​利用が​集中し、​依存度の​高い​リージョンの​一つです。​本件は​数時間に​わたり基盤となりクラウドインフラを​寸断し、​世界中で​数百万の​ユーザーおよび​数千の​依存プラットフォームに​影響を​与えました。​ AWSに​より、​障害の​原因は​EC2環境内の​ネットワークロードバランサーの​健全性を​監視する​内部​サブシステムの​不具合に​起因する​ものです。​この​障害が​DNS解決エラーを​引き起こし、​DynamoDB、​Lambda、​S3など​複数の​主要サービス間の​通信が​停止しました。​結果と​して、​多数の​APIが​タイムアウトや​エラーを​返し、​広範囲に​わたる​接続障害が​発生しました。​ 影響は​EC2、​S3、​RDS、​CloudFormation、​Elastic Load Balancing、​DynamoDBなど、​60以上の​サービスが​数時間に​わたり​部分的または​完全に​利用不能と​なりました。​AWSは​本件を​「複数サービスに​影響する​運用障害​（Multiple Services Operational Issue）」と​して​分類します。​暫定的な​回避策を​適用した​後、​完全復​旧までに​ほぼ1日を​要しました。​ 発生時刻と​影響範囲 項目 詳細 発生日時 2025年10月20日 07:11 UTC​（約 UTC+7 14:11）​ 完全復​旧日時 10:35 UTC​（約 UTC+7 17:35）​頃、​一部​遅延は​その​後も​継続 影響リージョン us-east-1​（米国バージニア北部）​ 影響サービス数 64以上​（コンピューティング、​ストレージ、​ネットワーク、​データベース層など）​ 影響レベル 高​（グローバルな​APIトラフィックに​影響する​複数サービス障害）​ ステータス 同日夜​（UTC+7）までに​主要サービスは​回復 障害発生中、​Snapchat、​Fortnite、​Zoom、​WhatsApp、​Duolingo、​Ringなどの​主要オンラインサービスで​機能停​止や​性能低下が​報告されました。​ 影響を​受けた​主な​AWSサービス 障害は​複数層に​波及し、​特に​基盤インフラに​おいて​影響が​顕著でありました。​ カテゴリ サブ領域 影響サービス コアインフラ コンピュート/サーバーレス AWS Lambda, Amazon EC2, Amazon ECS, Amazon EKS, AWS Batch ストレージ/データベース Amazon S3, Amazon RDS, Amazon DynamoDB, Amazon ElastiCache, Amazon DocumentDB ネットワーク/セキュリティ Amazon VPC, AWS Transit Gateway, Amazon CloudFront, AWS Global Accelerator, Amazon Route 53, AWS WAF AI/データサービス 機械学習 Amazon SageMaker, Amazon Bedrock, Amazon Comprehend, Amazon Rekognition, Amazon Textract データ処理 Amazon EMR, Amazon Kinesis, Amazon Athena, Amazon Redshift, AWS Glue ビジネス系サービス 通信 Amazon SNS, Amazon SES, Amazon Pinpoint, Amazon Chime ワークフロー Amazon EventBridge, AWS Step Functions, Amazon MQ, Amazon API Gateway セキュリティ認証 AWS Secrets Manager, AWS Certificate Manager, AWS Key Management Service (KMS), Amazon Cognito 複数の​層が​順次障害を​起こした​ことで、​サービス間の​依存関係が​断裂し、​顧客は​デプロイ、​認証、​データ処理などの​基本機能を​複数リージョンに​わたって​行えない​状況に​陥りました。​ 障害が​クラウド運用に​与えた​影響 us-east-1 が​ダウンした​とき、​影響は​一部の​サービスにとどまらず、​システム全体に​広がりました。​ コアシステムが​次々と​障害を​起こし、​それらに​依存する​すべての​サービスが​ 動作の​遅延、​タイムアウト、​または​ 不整合な​データの​返却を​引き起こしました。​ その​結果、​近年の​AWSで​最も​大規模な​連鎖的障害の​一つ​ が​発生しました。​ 1. 連鎖的障害の​発生 複数サービスに​またがる​障害が​発生した​ことで、​依存システム間に​連鎖的な​障害が​生じました。​Cognito、​RDS、​S3と​いった​主要コンポーネントが​同時に​停止した際、​これらに​依存する​他サービスが​例外を​発生させ、​処理の​タイムアウトを​引き起こしました。​多くの​本番環境では、​1つの​API呼び出しの​失敗が​全体の​ワークフロー崩壊に​つながり、​リトライ処理が​さらなる​負荷を​生み出して​システム全体​へ​障害が​拡大しました。​ 2. データ​整合性の​問題 ​今回の​障害では、​複数サービス間で​データ​整合性の​乱れが​確認されました。​RDSと​ElastiCache間の​連携が​途絶した​ことで​キャッシュの​無効化問題が​発生し、​DynamoDB Global Tablesでは​リージョン間の​レプリケーション遅延が​生じました。​また、​S3や​CloudFrontでは​エッジロケーションから​不整合な​アセットが​返却され、​古い​コンテンツの​配信や​データ同期の​破損が​見られました。​ 3. 認証・認可の​不安定化 Cognito、​IAM、​Secrets Manager、​KMSなどの​認証基盤が​影響を​受け、​ログイン、​トークン更新、​データ復号処理が​停止。​結果と​して、​計算リソースが​正常でも​ユーザー認証が​行えない​ケースが​多発しました。​ 4. 業界別影響事例 Eコマース：注文処理や​支払い​APIが​タイムアウト。​確認メール送信の​失敗に​より​決済フローに​支障。​ SaaS／アプリ：Cognito認証の​停止で​ログイン不能。​Snapchat、​Slack、​Fortniteなどで​影響。​ メディア／配信：CloudFrontや​S3遅延に​よる​再生停止や​遅延。​ データ分析／AI：Glueや​SageMakerの​ジョブ中断に​より​ETL処理や​推論処理が​失敗。​ 業務ツール：Zoomや​Canvaなども​一時​的に​性能低下。​ 本件は、​同一リージョン内の​「マルチAZ」​構成のみでは​十分な​耐​障害性を​確保できない​ことを​示しました。​重要ワークロードは​リージョン間フェイルオーバーや​独立した​認証・​データ経路の​設計が​必要であります。​ 主な​教訓と​対策 今回の​us-east-1リージョン障害では、​クラウド運用に​おける​既知の​信頼性ギャップが​改めて​浮き彫りと​なった。​具体的には、​単一リージョンへの​依存、​分離層​（Isolation Layer）の​不足、​そして​事後対応型の​監視体制などが​挙げられます。​以下では、​より​高い​可用性を​実現する​ための​主要な​教訓と​実践的アプローチを​整理します。​ 1. 単一リージョン依存の​回避 最大の​教訓の​ひとつは、​単一リージョンに​依存した​構成はもは​や許容できません。​多くの​開発チームは​長年に​わたり、​us-east-1を​「標準的な​稼働拠点」と​して​扱ってきました。​サービスの​豊富さや​コストの​優位性、​応答速度などの​理由からです。​しかし、​その​利便性が​裏目に​出た形で、​当該リージョンが​停止した​際には​多くの​システムが​連鎖的に​停止しました。​ 対策と​しては、​複数リージョンに​またがる​冗長構成の​設計が​必要です。​アクティブな​ワークロードを​少なくとも​2リージョンで​稼働させ、​重要データを​非同期で​複製し、​リージョン障害時に​自動で​フェイルオーバーできるルーティング設計を​行うことが​推奨されます。​これに​より、​稼働時間の​確保だけでなく、​企業の​信用・法令遵守・事業継続性の​保護に​もつながります。​ 2. サーキットブレーカーと​サービスメッシュに​より​障害分離 今回の​障害では、​1つの​依存サービスの​停止が​全体に​波及する​脆弱性が​明らかと​なりました。​サービス間の​結合​度が​高い​場合、​1つの​障害が​リトライの​集中や​タイムアウトを​引き起こし、​結果​的に​全体を​巻き込むことがあります。​ このような​事態を​防ぐには、​サーキットブレーカー​（Circuit Breaker）​パターンを​活用し、​一定回数の​エラーを​検知した​時点で​不安定な​サービスへの​呼び出しを​一時停止する​仕組みを​導入する​ことが​有効です。​また、​AWS App Meshや​Istioなどの​サービスメッシュを​併用する​ことで、​こうした​回復ポリシーを​マイクロサービス全体に​統一的に​適用でき、​アプリケーションコードを​変更せずに​耐障害性を​強化できます。​ 3. 段階的劣化​（Graceful Degradation）の​設計 システムの​一部が​停止しても、​全体を​停止させない​設計が​重要であります。​重要機能のみを​維持し、​優先度の​低い​機能を​一時的に​停止させる​ことで、​完全停止を​回避できます。​ その​ためには、​事前に​フェールバック​経路を​用意する​ことが​求められます。​データベースが​利用できない​場合には​キャッシュを​活用し、​書き込みが​失敗した​場合には​読み取り専用モードに​切り替えるなど、​柔軟な​制御が​有効であります。​これに​より、​ユーザー信頼と​サービス継続性を​保つことができます。​ 4. 可​観測性​（Observability）と​プロアクティブな​監視強化 多くの​チームが​障害を​把握したのは、​監視ツールではなく​ユーザーからの​報告でありました。​これに​より​対応が​遅れ、​復旧までに​多くの​時間を​要します。​ 問題を​防ぐには、​AWS標準の​CloudWatchだけに​依存せず、​Prometheus、​Grafana、​Datadogなど​外部​ツールと​組み合わせ、​メトリクス・トレース・ログを​横断的に​分析する​ことが​重要です。​また、​アラートは​静的閾値ではなく​異常検知ベースで​発報される​べきであり、​監視データは​障害リージョン外に​保持しておく​必要が​あります。​ 5. 自動復旧と​耐障害性テストの​実装 今回の​障害では、​手動対応に​依存する​ことの​非効率さも​浮き彫りに​なりました。​広範囲な​障害時には、​人手に​よる​復旧では​時間が​かかり、​影響が​拡大します。​ 信頼性の​高い​システムでは、​問題を​自動検出し、​即座に​復旧ワークフローを​実行できる​仕組みが​必要であります。​CloudWatchアラームや​Step Functions、​内部ヘルスチェックを​活用し、​自動再起動や​スタンバイDB昇格、​トラフィックの​再ルーティングを​自動化する​ことが​推奨されます。​さらに、​これらの​自動化は​継続的に​検証・​改善していく​べきです。​ 加えて、​定期的な​「Chaos Testing​（障害シミュレーション）」の​実施に​より、​実際の​障害発生時に​復旧ロジックが​機能するかを​確認する​ことが​有効です。​ 今後の​行動計画 今後​30日以内​ 単一リージョンに​集中している​ワークロードを​洗い出し、​依存状況を​整理 外部からの​レイテンシ・エラー率・​可用性監視を​導入 インシデント対応手順書​（プレイブック）の​整備 小規模フェイルオーバーテストの​実施 今後​3〜6か​月 重要ワークロードの​マルチリージョン展開 重要データの​非同期レプリケーション導入 自動復旧・フォールバック​動作の​テスト 自己修復型ワークフローの​部​分導入 今後​6〜12か​月 ベンダー・リージョンリスク低減の​ための​マルチクラウド・ハイブリッド構成の​検討 レイテンシに​敏感な​用途向けに​エッジコンピューティングを​活用 AIを​活用した​異常検知・​自動アラート機能の​強化 技術面と​業務面を​含む包括的な​事業継続計画​（BCP）の​策定 Haposoftは、​AWS環境に​おける​信頼性設計・テスト・スケーリング支援に​おいて、​長年の​実務経験を​有しています。​ 今回のような​障害を​踏まえ、​インフラの​耐障害性を​高めたい​企業に​対して、​当社エンジニアが​設計・検証・運用の​各段階で​技術的支援を​提供する​ことが​可能です。​ クラウド障害は​避けられないが、​重要なのは​「発生時に​どれだけ準備が​できていますか」。​Haposoftは、​事前の​備えと​継続的な​改善を​通じて、​より​堅牢で​信頼性の​高い​システム基盤の​構築を​支援しています。​ 結論​ 今回の​AWS us-east-1リージョン障害は、​クラウドシステムの​脆弱性を​改めて​示しました。​完全な​無停止は​現実的では​ありませんが、​事前準備と​設計上の​工夫に​よって​被害を​最小限に​抑える​ことは​可能です。​ クラウド障害は​今後も​発生し得るが、​重要なのは​「どれだけ​備えられていますか」。​継続的な​改善と​検証こそが、​信頼性を​構築する​鍵と​なります。