そうだね。WAFを設定して、パケットをそのまま捨てるようにすればいいと思うよ。レスポンスのオーバーヘッドも気にしなくて済むし。CloudflareのWAFではこれを「ブロック」って呼んでるみたい。

うん、これをしばらくやってたよ。TikTokのバイトダンス/バイトスパイダーボットが、私のサイトから何百万もの画像リクエストを送ってきてたんだ。何度も何度も止まらなかった。最終的にはCloudinaryに頼んで、関連するユーザーエージェントを全部ブロックしてもらったし、最初はシンガポールを完全にブロックしたよ。これらのAIスクレイピング会社のボットは本当にひどい！もし優しいCloudinaryを使ってなかったら、すごく高いホスティング料金に悩まされてたかも。今はCloudflareで全てのAIボットをブロックして、もう終わりにしてるよ！

これがIPアドレスの範囲だよー - https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-work...

同じような考えで、PoWチェックのanubis[1]がOPにも効くかもしれないね。 [1] https://github.com/TecharoHQ/anubis

この種の考え方は、ボットが非ステルスであることを前提にしてるね。

AWSの顧客はアウトバウンドトラフィックにお金を払わなきゃいけないんだよね。彼らに（またはCloudflareに）大量のトラフィックを送らせる方法はあるのかな？

いいアイデアだね！同じようなニーズで実装してる人もいるみたいだし（ソースコードのユーザーエージェントリストを見てみて）。実装は簡単そうだね。 https://github.com/0x48piraj/gz-bomb/blob/master/gz-bomb-ser...

同じような状況に直面したことがあるよ。考えたのは、悪いデータを与えることだった。うちの場合、彼らが価格データを得るためにサイトをスクレイピングしているのは明らかだった。マスターカタログには数百万のSKUがあって、在庫状況や顧客契約、その他の要因に基づいて動的に価格が設定されてたんだ。それに、関連するクロスセルや代替選択肢のおすすめを商品ページに追加して、ちょっとでも価値を加えようとしてた。これって計算リソースをかなり使うし、スクレイピングの量が多すぎると、時にはDoS攻撃みたいになっちゃうこともあった。リクエストのバーストで埋もれちゃって、インフラが新しい仮想サーバーを立ち上げられないくらいの速さだったんだ。埋もれちゃうと、その負荷から抜け出すのが難しかった。そんな時期にたくさんのことを学んだよ。特に、キューイングや優先順位付けのアプローチが、見た目は良さそうでも、実際には意図しない悪影響を及ぼすことがあるってこと。話し合った戦略の一つは、悪者をブロックするんじゃなくて、来るトラフィックにタグを付けるってことだった。完璧な精度ではできなかったけど、少なくとも実際の顧客には影響を与えないようにできた（ログインしているユーザーなら常にわかるからね）。境界線のケースではデータをキャッシュして、再計算しなくて済むようにできることに気づいたんだ（攻撃してきたのは特にバカなボットで、同じものを何度もリクエストしてきたから）。そこから、データにランダムなファッジファクターを加えることで、攻撃者にとってデータが役に立たない状態にできるかもしれないって考えた。結局、OPが今やっていること、CloudFlareと連携して「攻撃」をできるだけ早く特定して対処することをするようになった。でも、開発者の時間やCFへの支払い、顧客の不満を考えると、かなりのコストがかかったのは間違いない。ちなみに、これがさらにイライラしたのは、攻撃者がうちの競合の契約したサービスだという状況証拠があったから。もし彼らが直接うちに来て話してくれていたら、APIを通じてカタログデータを簡単に取得できるようにして、無駄な計算をしなくて済むようにできたのに。もちろん、彼らは絶対にうちには来ないし、聞かれても認めないだろうから、どうしようもなかった。そんなことがあった時、ここHNで何度も話題に上がった裁判もあった。公的なサイトへのアクセスをブロックするかどうかの問題で、ここでのコンセンサスは「ウェブにサイトを持つなら、リクエストに対応できるようにするのは自分の責任。DoSレベルのトラフィックに耐えられないなら、デザインが悪いのが原因だ」って感じだった。だから、今の態度の変化を見るのは面白いね。

バカな質問だけど、それって自分のボックスのポートも7000個消費しちゃうんじゃないの？