ハクソク

世界を動かす技術を、日本語で。

2025年8月21日のCloudflareインシデント

277日前原文(blog.cloudflare.com)

概要

2025年8月21日、 Cloudflare と AWS us-east-1 間のネットワーク混雑により、高遅延やパケットロスが発生 影響は Cloudflare と AWS us-east-1 間のトラフィックに限定 単一顧客からの急激なトラフィック増加が主因 ネットワーク容量不足と一部機器の障害も影響 再発防止策として ネットワーク強化 と 顧客ごとのトラフィック管理 を実施予定

AWS us-east-1とCloudflare間で発生したネットワーク混雑障害の概要

  • 2025年8月21日16:27 UTC、 AWS us-east-1 経由の顧客から Cloudflare への大量リクエストが発生
  • このトラフィック急増により、 Cloudflare と AWS us-east-1 間の直結ピアリングリンクが飽和
  • AWS側が混雑緩和のため BGP広告の引き下げ を実施し、トラフィックの迂回が発生
  • 迂回先のネットワーク接続も飽和し、パフォーマンスが大幅に低下
  • 問題発生時、直結リンクの一部が既存障害で半分の容量しか使えず、 DCI （Data Center Interconnect）も増強前の状態だった

障害の詳細な経緯

  • 2025-08-21 16:27 UTC ：単一顧客のトラフィック急増、影響開始
  • 16:37 UTC ：AWSが混雑したPNI（Private Network Interconnect）のBGP広告を引き下げ
  • 16:44 UTC ：Cloudflareネットワークチームが内部混雑を検知
  • 17:22 UTC ：BGP広告引き下げの影響でドロップトラフィック増加
  • 19:05 UTC ：該当顧客のレート制限により混雑緩和
  • 19:27 UTC ：追加のトラフィックエンジニアリングで混雑完全解消
  • 20:18 UTC ：影響終了

障害の影響

  • 高遅延、 パケットロス、 低スループット が発生
  • Cloudflareのエッジルーターで優先度の高いパケットも継続的にドロップ
  • サービスレベル目標（SLO）を下回るリクエスト増加
  • 混雑解消後もBGP広告の正常化作業により一部で遅延継続

原因分析

  • 単一顧客 によるトラフィック集中がネットワーク容量を超過
  • 既存障害で一部リンクが半容量運用
  • DCIの増強が未実施で容量不足
  • AWSとCloudflareのBGPトラフィック制御が相互に影響し合い、混乱を助長

再発防止策

  • 顧客ごとのトラフィックが他顧客に影響しない 顧客分離設計 の強化
  • ネットワーク容量の即時増強（DCIアップグレードの加速）
  • CloudflareとAWS間でのBGPトラフィックエンジニアリングの調整強化
  • 顧客ごとにネットワークリソースを割り当て、上限超過時は自動で他顧客への影響を遮断する 新管理システム の設計・導入
  • 手動対応の自動化による障害対応力の向上

結論と今後の方針

  • 今回の障害は ネットワーク混雑管理の不十分さ が原因
  • 顧客への影響を深く反省し、 ネットワーク強化 と 顧客ごとのトラフィックコントロール を推進
  • Cloudflareは引き続き安全・高速なインターネットを目指し、再発防止策を徹底
  • 詳細や今後の取り組み、採用情報はCloudflare公式サイトを参照

Hackerたちの意見

あるテナントのキャッシュヒットトラフィックがCloudflareのインターコネクト容量をオーバーフローさせるなんて、すごいことだね。

└

意外と多くのインターネットリンクの容量が低いことに驚くかも。小規模なネットワークでは10Gbpsが普通なんだ。言い換えると、小規模から中規模のISPは、ほとんどのピアリングパートナーに対して10Gbpsしか持ってないかもしれない。通常、トラフィックは分散していて、いろんな場所から来て、いろんな場所に行くから、各リンクは部分的にしか使われてない。でも、異常なパターンがあると特定のリンクが埋まっちゃうんだ。10Gbpsは今や古い技術で、実際のISPなら40Gbpsや100Gbpsを手に入れるのは簡単だと思うよ。リンクごとに数百ドルでね。でも、最初は最も利用されているリンクにそれを展開するだろうし、ピアリングパートナーもそれを支払えるし、十分なトラフィックを交換している場合だけだね。だから、最小の接続は通常10Gbpsになる。10Gbps未満は、ポイントツーポイントのピアリングを正当化するには小さすぎるから。もし家に10Gbpsの光ファイバーがあったら、君一人でそのリンクを混雑させることができるよ。今、これはCloudflareがaws-east-1に話しているから、そこには大量の容量があるはずだし、たぶん少なくとも8x100以上はあるだろうね。でも、AWSは800台のサーバーを数時間で立ち上げて、大規模な並列タスクを実行できる環境だから、誰かが最終的に800Gbpsのトラフィックを同じ場所に作り出したってのは驚くことじゃないよ。実際、もっと頻繁に起こってもおかしくないと思う。もしかしたら、AWSがデータ転送に高額な料金を取っているからかもしれないね。800Gbpsは1秒あたり5〜9ドルだし。

└

これが事件の始まりだったんだよね。Cloudflareが主要なピアへのBGPルートの取り下げに正しく反応しなかったこと、二次ルートの容量が未解決の問題で減少していたこと、基本的な迷惑なレート制限を手動でやらなきゃいけなかったことが、事態を長引かせたんだ。彼らは巨大なピアリングパイプを作って、あとは運を天に任せてる感じだね。多分、これがうまくいくのに慣れすぎちゃって、劣化した「二次」リンクが本来よりずっと長く残っちゃうんだろうね。典型的な「スイスチーズ」スタイルの失敗だよ。

AWSのus-east-1が他のプロバイダーをダウンさせてるみたい。

誰かCloudflareに言ってくれない？AWSのBGP広告は自動化されてるし、混雑したネットワークが直接BGPの撤回を引き起こしてるって。自動システムが混雑を検知してトラフィックを減らすためにそうなったんだよ。

└

DCI PNIのBGPルートが手動で設定されてたとしても驚かないよ。これが最も直接的で重要な接続の一つだからね。Cloudflareがこの事件の時にAWSで何が起こったかを直接知ってなかったら驚くよ。AWSの撤回アプローチは通常はうまくいくと思う。これによって接続が飽和しなくなるはずだから。ただ、半分の容量のリンクを通るルーティングが起こったのは本当に不運だね。

└

ブログ記事を読む限り、彼らはそのことをよく理解しているみたい。CloudflareとAWSは、この問題が起きている間、Chimeでつながってたんじゃないかな。どちらもリスクが大きいしね。

結局、一人のやつが速いマシンで「pnpm install」を呼び出してたってことになるんじゃないかな。

└

もう2015年のジョークはやめようよ。

このシステムは顧客ごとにネットワークリソースを割り当て、予算を作成します。予算を超えると、顧客のトラフィックがプラットフォーム上の他の誰かのサービスを劣化させるのを防ぎます。 実際にはこれがどう機能するの？ もし一人のクライアントがエッジルーターのキューをオーバーフローさせてたら、もう詰んでるってことじゃない？ そのクライアントからのパケットを全部落としたとしても、どのクライアントに属しているかを判断するためにパケットを処理する必要があるよね？ なんとかシャッフルシャーディングをして、一人のクライアントがいくつかのIPプレフィックスに属して、そのクライアントが問題を起こしたらBGPを使ってそのプレフィックスを撤回して、実質的にそのクライアントのネットワークルートをブラックホールにすることができるかもしれないね。シャッフルシャーディングがうまくいけば、問題のあるクライアントだけが問題を抱えることになるし、同じプレフィックスの他のクライアントは他のプレフィックスにシャーディングされるだろう。

└

もしかしたら、ホスト側でクライアントのフローを落としてるのかもね。

└

考えすぎじゃない？Cloudflareごとにレート制限を設けるだけで、かなり改善されると思うよ。

└

これは負荷軽減だけど、通常は何らかの加重平均に基づいて、自分のクォータを乱用している人に偏ってる。メリットは、ソケットを開いたままにしたり、計算やリソースを使ったりすることなく、すぐにエッジで切り捨てられることだね。通常、効果が出るまでに30秒から1分かかる。

└

この特定のケースでは、クライアントからのリクエストが過負荷を引き起こしたわけじゃない。リクエストへのレスポンスが原因だったんだ。だからCloudflareはレスポンスを送信しないようにして、問題を防げる。確かにこれですべてのケースが解決するわけじゃないけど、このケースは防げたはずだよ。

└

そのクライアントからのパケットをすべて切り捨てても、どのクライアントに属するかを判断するためにパケットを処理する必要があるの？ 現代のLinuxでは、計算を一切行う前にドライバの最下層でトラフィックを切り捨てるためのBPF-XDPプログラムを書くことができるよ。ドライバがrxリングバッファに新しいパケットを受け取った後に最初に行うことのほとんどは、あなたのプログラムをそれらに対して実行することなんだ。

AWSでは、特定の顧客が潜在的なバグや容量不足を引き起こして障害が発生するというパターンが確かにあったね。ポストモーテムでは、顧客ごとの可視性と対策を開発することが推奨されることが多かったよ。

記事の二つ目の図が理解できなくて困ってる。指向グラフは理解できるけど、これは薄い横線があって、両方向に矢印が出てるんだ。これらの線はノードじゃなくて仕切りみたいに見えるから、どう解釈すればいいのかわからない。

└

これは、AmazonとCloudflareの責任の境界を示す意図があると思う。彼らのネットワークデバイスをつなぐ光ファイバーの部分についてね。線を続けて、間に点線の区切りを入れた方がわかりやすかったんじゃないかな。

本当に長期的な対策は、別のAWSリージョンに移ることだね。us-east-1はあらゆるスケーリングの課題に悩まされてるみたい。

└

Cloudflareと他のAWSリージョンとの間に、より多くの容量があるとか、より破壊的なCloudflareの顧客がそのリージョンを使っていないという証拠は何もないよ。

事件は、単一の顧客からのトラフィックの急増が原因で、CloudflareのリンクがAWS us-east-1をオーバーロードした結果だった。これはネットワークの混雑イベントで、攻撃やBGPハイジャックではない。事件が起こるまで、誰もそのことを知らなかった。それが現在のネットワーク管理の最前線だよ、Cloudflareに任せよう。

どの顧客がこれを引き起こしたのか気になるな…

└

それが本物のトラフィックなのか、設定ミスなのか、攻撃トラフィックなのかも気になる。

└

おそらくBrazeだと思う。彼らは顧客がユーザーごとにデータをプッシュしたりプルしたりできるようにしていて、全ての顧客がサンドボックスにいると思う。彼らもこの事件の影響を受けたみたい。