2025年6月12日、Cloudflareは、Workers KV、WARP、Access、Gateway、Images、Stream、Workers AI、Turnstile、Challenges、AutoRAG、Zaraz、およびCloudflareダッシュボードの一部を含む重要なサービスに影響を与える重大なサービス障害を経験しました。
この障害は2時間28分間続き、影響を受けたサービスを使用しているCloudflareのすべてのお客様に世界的な影響を与えました。この障害の原因は、Workers KVサービスが使用する基盤ストレージインフラストラクチャの障害によるものです。これは、多くのCloudflare製品と重大な依存関係にあり、影響を受けたサービス全体の設定、認証、アセット配信が依存していました。このインフラストラクチャの一部はサードパーティのクラウドプロバイダーによって支えられており、本日障害が発生し、当社のKVサービスの可用性に直接影響を与えました。
この障害について深くお詫び申し上げます。これは当社の失敗であり、この障害の直接的な原因（またはトリガー）はサードパーティベンダーの障害でしたが、当社が選択した依存関係とそれに基づくアーキテクチャの選択方法について、当社に最終的な責任があります。
これは攻撃やその他のセキュリティイベントの結果ではありません。このインシデントによるデータの損失はありませんでした。Cloudflare Magic TransitおよびMagic WAN、DNS、キャッシュ、プロキシ、WAF、および関連サービスは、このインシデントの直接的な影響を受けませんでした。
原則として、Cloudflareは独自のプラットフォームビルディングブロックを用いてサービスを設計・構築しており、そのためCloudflareの多くの製品はWorkers KVサービスに依存して構築されています。
以下の表は、ユーザーへの影響、操作の失敗、観察されたエラー率の増加など、影響を受けたサービスの詳細を示したものです：
製品/サービス | 影響 |
|---|
Workers KV
| Workers KVでは、リクエストの90.22%が失敗しました。キャッシュされていないキーと値のペアで、Workers KVのオリジンストレージバックエンドから値を取得する必要がある場合、レスポンスコード503または500でリクエストが失敗しました。 残りのリクエストは、Workers KVのキャッシュ（ステータスコード200および404）から正常に処理されたか、当社の期待される制限および/またはエラーバジェットの範囲内でエラーが返されました。 これは、Workers KVに保存されているデータに影響を与えませんでした。 |
Access
| Accessは、Workers KVを使用して、アプリケーションとポリシーの設定およびユーザーのID情報を保存します。 インシデント中、Accessはセルフホスト型、SaaS、インフラストラクチャを含むすべてのアプリケーションタイプで、IDベースのログインが100%失敗しました。また、WARPやGatewayなどの他のサービスでユーザーID情報を利用できませんでした。Accessは、ポリシー設定やユーザーのIDを正常に取得できない場合、フェイルクローズするように設計されています。 コマンドログが有効なアクティブインフラストラクチャアプリケーションのSSHセッションは、Workers KVの依存関係によりログを保存できませんでした。 AccessのクロスドメインID管理システム（SCIM）サービスも、ユーザー情報の保存をWorkers KVとDurable Objects（KVに依存）に依存していたため、影響を受けました。このインシデント中、Workers KVの更新失敗により、ユーザーIDが更新されませんでした。これらの失敗により、IDプロバイダーに500エラーが返されることになります。一部のプロバイダーは手動で再同期を行う必要があるかもしれませんが、ほとんどのお客様は、IDプロバイダーの再試行ロジックにより、AccessのSCIMサービスが復旧した際に即座にサービスが復旧したと考えられます。 サービス認証に基づくログイン（例：サービストークン、Mutual TLS、およびIPベースのポリシー）とバイパスポリシーには影響がありませんでした。また、Accessポリシーの編集や変更が失われることもありませんでした。 |
Gateway
| このインシデントは、IPv4、IPv6、DNS over TLS（DoT）、DNS over HTTPS（DoH）を含むほとんどのGateway DNSクエリに影響を与えませんでした。 ただし、2つの例外がありました。 IDベースのルールを使用したDoHクエリが失敗しました。この問題は、Gatewayが必要なユーザーのID情報を取得できなかったために発生しました。 一部のユーザーに対して認証済みのDoHが中断されました。有効な認証トークンを持つアクティブなセッションのユーザーは影響を受けませんでしたが、新しいセッションを開始したり、認証トークンを更新する必要があるユーザーは実行できませんでした。 Gatewayプロキシ、エグレス、TLS復号化のユーザーは、トラフィックを接続、登録、プロキシ、または記録できませんでした。 これは、最新のID情報とデバイスポスチャー情報を取得するためにWorkers KVに依存していたことによるものです。これらのアクションはそれぞれ、Workers KVへの呼び出しを必要とし、利用できない場合、Gatewayはトラフィックが顧客設定のルールをバイパスしないようにフェイルクローズするように設計されています。 |
WARP
| WARPクライアントは、AccessとWorkers KVに依存しているために影響を受けました。WARPクライアントは、デバイスの登録と認証に必要です。その結果、インシデント中に新しいクライアントは接続やサインアップができませんでした。 Gatewayプロキシを経由した既存のWARPクライアントユーザーセッションは、Gatewayが必要なポリシー評価を実行できなかったため、中断が発生しました。 さらに、WARP緊急切断オーバーライドは、基盤となる依存関係にあるWorkers KVの障害により利用できなくなりました。 コンシューマー向けWARPは、Zero Trust版と同様に散発的な影響を受けました。 |
ダッシュボード
| ダッシュボードのユーザーログインと既存のダッシュボードセッションのほとんどが利用できませんでした。これは、Turnstile、DO、KV、およびAccessに影響を与える障害が原因でした。ログイン失敗の具体的な原因は次の通りです。 Standardログイン（ユーザー/パスワード）：Turnstileが利用不可のため失敗しました。 Google（OIDC）でのサインイン：KVの依存関係の問題により失敗しました。 SSOログイン：Accessに完全依存しているため失敗しました。 このインシデント中、Cloudflare v4 APIは影響を受けませんでした。 |
ChallengesとTurnstile
| Cloudflare ChallengesとTurnstileを支えるChallengeプラットフォームは、Workers KVとDurable Objectsに依存しているため、インシデント期間中にsiteverify API呼び出しの失敗率とタイムアウト率が高くなりました。 このようなインシデントや障害が発生した場合に備えて、これらの呼び出しを無効にするためにキルスイッチを設置しています。エンドユーザーが進行を妨げられることがないように、緩和策としてこのキルスイッチを有効にしました。特に、このキルスイッチが有効な間、Turnstileのsiteverify API（発行されたトークンを検証するAPI）は有効なトークンを複数回引き換えることができ、悪意のある攻撃者が以前に有効だったトークンを使用してバイパスしようとする攻撃の可能性が生じ得ます。 Turnstileのボット検出機能に影響はありませんでした。チャレンジを解決しようとするボットは、チャレンジに失敗したとみなされるため、トークンを受け取ることはありません。 |
ブラウザ分離
| ポリシー評価がGatewayに依存していたため、リンクベースの分離を使用する既存のブラウザ分離セッションが影響を受けました。 Cloudflare Accessに依存しているため、新しいリンクベースのブラウザ分離セッションを開始できませんでした。Gatewayが開始したすべての分離セッションは、Gatewayの依存関係により失敗しました。 |
Images
| Cloudflare Imagesへのアップロードは、インシデント期間中に影響を受け、ピーク時には失敗率が100%に達しました。 画像配信全体の成功率は約97%に低下しました。Image Transformationsは大きな影響を受けず、Polishには影響がありませんでした。 |
Stream
| インシデント期間中、動画プレイリストを提供できなかったため、Streamのエラー率が90%を超えました。Stream Liveのエラー率は100％でした。 動画のアップロードには影響がありませんでした。 |
Realtime
| Realtime TURN（Traversal Using Relays around NAT）サービスはKVを使用しており、大きな影響を受けました。インシデントの間の、エラー率はほぼ100%でした。 Realtime SFUサービス（選択的転送ユニット）は、既存の接続は維持されましたが、新しいセッションを作成することができませんでした。これにより、影響期間中、通常のトラフィックが20%に減少しました。 |
Workers AI
| インシデントの間、Workers AIへのすべての推論リクエストが失敗しました。Workers AIは、AIリクエストの設定とルーティング情報を世界中に配布するためにWorkers KVに依存しています。 |
PagesおよびWorkersアセット
| Cloudflare PagesおよびWorkersアセット（HTML、JavaScript、CSS、imagesなど）によって提供される静的アセットは、Workers KVに保存され、キャッシュされ、リクエスト時に取得されます。この期間中、Workers アセットの全リクエストに対する平均エラー率が約0.06%増加しました。 インシデントの間、Pagesのエラー率は約100%に達し、すべてのPagesビルドが完了できませんでした。 |
AutoRAG
| AutoRAGは、インデックス作成時のドキュメント変換とベクトル埋め込みの生成の両方にWorkers AIモデルを使用し、クエリと検索にはLLMモデルを使用しています。Workers AIに依存しているため、インシデント期間中、AutoRAGは利用できませんでした。 |
Durable Objects
| SQLiteベースのDurable Objectsは、Workers KVと同じ基盤ストレージインフラストラクチャを共有しています。インシデント期間中の平均エラー率は22%でピークに達し、サービスが回復し始めると2%に低下しました。 従来のキーバリューストレージを使用するDurable Object 名前空間は影響を受けませんでした。 |
D1
| D1データベースは、Workers KVおよびDurable Objectsと同じ基盤ストレージインフラストラクチャを共有しています。 Durable Objectsと同様に、インシデント期間中の平均エラー率は22%でピークに達し、サービスが回復し始めると2%まで低下しました。 |
Queuesおよびイベント通知
| プッシュや消費を含むQueuesのメッセージ操作は、インシデント期間中、利用できませんでした。 Queuesは、KVを使用して、各Queuesを、キューに入れられたメッセージを含む基盤となるDurable Objectsにマッピングします。 イベント通知はその基盤となる配信メカニズムとしてQueuesを使用します。 |
AI Gateway
| AI GatewayはWorkers上に構築されており、クライアント設定と内部設定をWorkers KVに依存しています。インシデント期間中、AI Gatewayのリクエストのエラー率は依存関係が回復するまで97%のピークに達しました。 |
CDN
| 自動トラフィック管理インフラは運用可能でしたが、影響期間中は効率が低下していました。特に、Zero Trustクライアントからの登録リクエストが、障害の影響で大幅に増加しました。 リクエストの増加により、Cloudflareのいくつかの拠点で追加の負荷がかかり、自動トラフィック管理が応答しました。こうした状況に対応するため、システムは受信CDNトラフィックを近くの拠点に再ルーティングし、お客様への影響を軽減しました。トラフィックの一部が想定通りに再ルーティングされなかったため、調査中です。この問題の影響を受けたCDNリクエストは、遅延の増加、HTTP 499エラー、またはHTTP 503エラーが発生する可能性があります。影響を受けたCloudflareサービスエリアには、サンパウロ、フィラデルフィア、アトランタ、ローリーが含まれています。 |
Workers / Workers for Platforms
| WorkersとWorkers for Platformsは、アップロードにサードパーティのサービスを利用しています。インシデント期間中、Workersの全体的なエラー率は全リクエストの約2%のピークに達しました。Workers for Platformsでは、同期間中に全体的なエラー率がリクエスト全体の約10%のピークに達しました。 |
Workersビルド（CI/CD）
| 18:03 UTCから、WorkersのビルドはAccessのダウンにより、新しいソースコード管理のプッシュイベントを受信できませんでした。 インシデント期間中、新規Workersビルドの100%が失敗しました。 |
Browser Rendering
| Browser Renderingは、ブラウザインスタンスインフラストラクチャのためにブラウザ分離に依存しています。 REST APIおよびWorkers Browser Binding経由のリクエストは、インシデント期間中に100%の影響を受けました。 |
Zaraz
| インシデント中、リクエストの100%が影響を受けました。Zarazはエンドユーザートラフィックを処理する際に、WebサイトのWorkers KV設定に依存しています。同じ依存関係により、この期間中Zaraz設定の更新を保存する試みは成功しませんでしたが、当社の監視では影響を受けたのは1人のユーザーのみであることを示しています。 |
Workers KVは、当社が「コアレス」と呼ぶサービスとして構築されています。つまり、世界中の各拠点で独立してサービスが実行されるため、単一障害点が存在しないということです。しかし、現在、Workers KVはデータの正確な情報源を提供するために中央データストアに依存しています。そのストアの障害により、Cloudflare全体のサービスで使用されるKVネームスペースへのコールドリードおよび書き込みが完全に停止しました。
Workers KVは、中央ストアのために、より耐障害性の高いインフラストラクチャへの移行が進行中です。残念ながら、このインシデント中にカバレッジのギャップが露呈しました。Workers KVは、KVのバックエンドを再設計し、Cloudflare R2への移行を含め、データの一貫性の問題（元のデータ同期アーキテクチャが原因で発生した）を防ぎ、データレジデンシー要件のサポートを改善するために、ストレージプロバイダーを削除しました。
当社では、Cloudflareサービスを可能な限り自社のプラットフォーム上で構築することを原則として掲げており、Workers KVも例外ではありません。当社の内部および外部サービスの多くは、通常の状況下で、サービスチームが独自のストレージサービスを構築しようとする代わりに、可能な限り堅牢なサービスを提供するのに役立つWorkers KVに大きく依存しています。この場合、Workers KVの障害による連鎖的な影響が問題を悪化させ、影響範囲を大幅に広げました。
初期影響、調査、根本原因、修復を含む、インシデントのタイムラインの詳細は以下のとおりです。
ストレージインフラストラクチャに対するWorkers KVのエラー率。インシデント期間中、KVへのリクエストの91％が失敗しました。
リクエストが成功したCloudflare Accessの割合。Cloudflare AccessはWorkers KVに直接依存しており、Workers KVの可用性を経時的に測定するための優れたプロキシとして機能します。
参照されるタイムスタンプはすべて協定世界時（UTC）です。
時間 | イベント |
|---|
2025年6月12日 17時52分 | インシデント開始
Cloudflare WARPチームは、新しいデバイスの登録失敗が発生し始めたため、これらの障害の調査を開始し、インシデントを宣言します。 |
2025年6月12日 18時05分 | Cloudflare Accessチームは、エラー率の急増によりアラートを受信しました。 複数のサービスのサービスレベル目標が目標を下回り、それらのチームにアラートをトリガーします。 |
2025年6月12日 18時06分 | 複数のサービス固有のインシデントは、共通の原因（Workers KVが利用不可）を特定することで、単一のインシデントに統合されます。インシデントの優先度がP1にアップグレードされました。 |
2025年6月12日 18時21分 | 影響の深刻さが明確になったため、インシデントの優先度がP1からP0に引き上げられました。 |
2025年6月12日 18時43分 | Cloudflare Accessは、Workers KVエンジニアリングチームと協力して、別のバックエンドデータストアに移行することで、Workers KVへの依存を解消するためのオプションを模索し始めました。これは、ストレージインフラストラクチャがダウンし続けた場合に備えて、先を見越して行われたものです。 |
2025年6月12日 19時09分 | Zero Trust Gatewayは、IDまたはデバイスポスチャーの状態を参照するルールを段階的に低下させることで、Workers KVへの依存を解消する作業を開始しました。 |
2025年6月12日 19時32分 | Accessとデバイスポスチャーは、サードパーティのサービスが復旧するまで、IDとデバイスポスチャーのリクエストを強制的にドロップして、Workers KVの負荷を軽減します。 |
2025年6月12日 19時45分 | Cloudflareのチームは、代替のバックエンドデータストアに対してWorkers KVのリリースをデプロイし、重要なサービスがそのストアに設定データを書き込む方法を模索し続けています。 |
2025年6月12日 20時23分 | ストレージインフラストラクチャが回復し始めると、サービスも回復し始めます。キャッシュを再構築するサービスの流入による、無視できないエラー率とインフラストラクチャのレート制限を引き続き観察します。 |
2025年6月12日 20時25分 | サードパーティのサービスが復元されると、AccessとデバイスポスチャーのWorkers KVを呼び出す機能が復元されます。 |
2025年6月12日 20時28分 | 影響終了
サービスレベル目標がインシデント発生前のレベルに戻ります。Cloudflareのチームは、依存システムの復旧中にサービスが低下しないよう、システムを監視し続けています。 |
| インシデント終了
Cloudflareのチームは、影響を受けたすべてのサービスが通常の機能に戻ったことを確認しています。サービスレベル目標のアラートが復旧しました。 |
Workers KVとストレージインフラストラクチャに依存するサービスの耐障害性を向上させるための対策を直ちに講じています。これには、このインシデントの結果として当社が加速させている既存の計画された作業も含まれます。
これには、当社が所有していないストレージインフラへの単一依存を避けるための取り組みを含む、いくつかのワークストリームが含まれており、重要なサービス（Access、Gateway、WARPを含む）を復旧する能力の向上も含まれます。
特に：
（積極的に進行中）：Workers KVのストレージインフラストラクチャ内の冗長性を改善し、単一プロバイダーへの依存を解消するための作業を前倒ししています。インシデントの期間中、当社ではインシデントが継続した場合に備えて、重要なKVネームスペースを独自のインフラストラクチャに移行し、バックフィルする作業を開始しました。
（積極的に実行中）：このインシデントの影響を受けた個々の製品の短期的な影響範囲の修復を行い、各製品がサードパーティとの依存関係を含む単一障害点によって引き起こされるサービスの損失に耐えられるようにします。
（積極的に進行中）：ストレージインフラストラクチャのインシデント中にネームスペースを段階的に再有効化できるツールを実装中です。これにより、キャッシュが再設定された際に、当社のインフラストラクチャに対するサービス拒否のリスクを冒すことなく、AccessやWARPなどの主要な依存関係を生じさせることができます。
このリストは網羅的ではありません。当社のチームは、今後このようなインシデントを軽減するために、短期（即時）および長期の両方で設計上の決定を再検討し、必要なインフラストラクチャの変更を評価し続けています。
これは深刻な障害であり、大小を問わず、多くの組織や機関が、Webサイト、アプリケーション、zero trust、ネットワークインフラストラクチャの保護や運用に私たちを頼っていることを理解しています。 繰り返しになりますが、私たちはこのような影響を深くお詫びするとともに、サービスの耐障害性の改善に向けて鋭意作業中です。