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

2025年8月22日原文(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ごとにレート制限を設けるだけで、かなり改善されると思うよ。

Hacker Newsで議論の続きを見る

ハクソク