COLUMN

1. AWS WAF レートベースルールの基本

1-1. AWS WAFとは

AWS WAFは、アプリケーション層（レイヤー7）での不正アクセスを検知・遮断できるマネージド型ファイアウォールサービスです。

ALB、API Gateway、CloudFrontなどと統合して使用でき、OWASP Top 10への対策や、カスタムルールによる柔軟な制御が可能です。

1-2. レートベースルールとは

レートベースルールは一定時間内のリクエスト数をカウントし、そのレートがしきい値を超えた場合にトリガーされるルールです。

例えば「5分間に1000リクエスト」というしきい値を設定すると、AWS WAFは各クライアント（デフォルトではIPアドレス単位）のリクエスト数を5分間集計し、超過した場合にそのクライアントからの追加リクエストをブロックします。

このブロックはしきい値を下回ると自動的に解除されます。

1-3. 通常ルールとの違い

通常のWAFルールが各リクエスト単体の内容（ヘッダーやURI文字列など）に対して即時に許可/ブロックを判定するのに対し、レートベースルールは過去一定時間内の累積リクエスト数を基準に判定を行う点が大きな違いです。

1-4. 利用する際の主なメリット

メリットとしては以下のようなことが挙げられます。

• DDoS攻撃やスクレイピングを迅速に検出・遮断
• 設定がシンプルで即効性が高い
• ALB/CloudFrontと連携して展開可能

AWSの情報セキュリティ対策に関するお問い合わせはこちら！

2. レートベースルールの内部動作と設定のポイント

2-1. 内部動作

AWS WAFはレートベースルールの内部でスライディングウィンドウ集計によるアルゴリズムを用いています。

デフォルトでは直近5分間のリクエストを対象にレートを算出しますが、実際にはより最近のリクエストに重みを置きつつレートを再評価しています。

そのため厳密に設定値ピッタリで動作するわけではなく、若干の誤差を含め「近い値」でレート制限が掛かる設計です

例えば5分間1000リクエストの制限を設定しても、実際には1000ちょうどでなくおよそその前後でブロックが開始・解除されることがあります。

この緩やかな評価により、WAFは効率的かつ大規模な攻撃対策に最適化されています。

ただし、レートベースルールはあくまでアプリの可用性保護が目的であり、ミリ秒単位の厳密なQPS制御には向いていません。

2-2. 設定のポイント

レートベースルールは他のルールといくつか技術的に異なる点があります。

2-2-1. ステートフルな判定

通常のWAFルール（例えば文字列マッチやIPマッチ条件）は各リクエストを独立に評価するステートレスな処理ですが、レートベースルールは内部に状態を保持し、一定期間のリクエスト数を累積して評価するステートフルな処理です。

このため、AWS WAF内部では対象ごとにカウンタを管理し、しきい値超過時にその対象のリクエストをブロックする仕組みになっています。

結果として、通常ルールより処理負荷（WCUコスト）が高く設定されています。

（レートベースルール1つあたり基本2 WCU、カスタム集計キーを追加すると1つにつき+30 WCU）

2-2-2. 自動ブロックと解除

レートベースルールがしきい値を超えたIPアドレスなどをブロックすると、しばらくの間そのIPアドレスをブロックし続けます。

しかし、対象のリクエストレートが低下すると自動でブロックを解除します。

この自動管理はWAFが内部的に行うため、「何分ブロックするか」といった設定項目は存在しません。

また、AWS WAFでは同時にブロックできるIPアドレスは最大で1万件程度という内部上限があります。

極端に分散した攻撃（1万以上のIPから少しずつ攻撃されるケース）では、それ以上のIPアドレスはブロック対象に入りきらない可能性があります。この制限は通常のシナリオでは問題になりにくいですが、超大規模DDoSではWAF単体でなく他の対策（AWS Shieldやネットワークレベルの制御）との併用も検討が必要です。

2-2-3. 集計キーの柔軟性

レートベースルールはIPアドレス単位での集計が基本でしたが、AWS WAFv2では集計キーをカスタマイズ可能になりました。

カウントを集計する単位をIPアドレス以外にも設定でき、ヘッダ値、クッキー値、クエリパラメータ、HTTPメソッドなどをキーにしたり、複数の要素を組み合わせた合成キーで集計することも可能です。

例えば「クライアントのAPIキーごとに1分間に100リクエストまで」といった制限も、APIキーを表すHTTPヘッダを集計キーに指定することで実現できます。

さらに高度な使い方として、別のルールで付与したラベルをキーにすることも可能で、任意の条件でマーキングしたトラフィックに対してレート制限を適用する、といったシナリオにも対応します。

この柔軟性は通常のWAFルールにはない、レートベースルール独自の強みとなっています。

AWSの情報セキュリティ対策に関するお問い合わせはこちら！

3. しきい値設計の考え方と主なユースケース

レートベースルールを効果的に使うには、「どのくらいのレートでブロックするか」（しきい値）の設計が重要です。

高すぎるしきい値では攻撃を防げず、低すぎると通常ユーザーまで誤ブロックしてしまいます。

ここでは代表的なユースケースごとに適切なしきい値設計や活用方法を解説します。

3-1. 大量リクエストによるDDoS攻撃対策

3-1-1. しきい値設定の目安

アプリケーションの正常時のトラフィックを把握し、そのピークより十分高い値を設定します。

例えば通常のピークが5分間に数百リクエストなら、しきい値を2000リクエスト程度に設定するのは有効な設定かと思います。

AWS公式のセキュリティブログでも「5分間に2000リクエスト」のブランケットルールは多くのHTTPフラッド攻撃に対する強力な抑止策であり、実際にこのルールが予め有効化されていればAWSの情報セキュリティ対応チームへのエスカレーションを要さず自動ブロックされ、支援が必要なかった可能性を示唆しています。

The three most important AWS WAF rate-based rules

重要なのは、通常の正規ユーザーがそのしきい値に達していないかを検証することです。

高トラフィックをさばく公開Webサイトでは2000/5分でも低すぎる可能性があり、例えば1万/5分（毎秒33リクエスト程度）など規模に応じて調整します。

一方、小規模サービスでは500/5分でも十分かもしれません。

3-1-2. ポイント

DDoS防御用のしきい値は多少余裕を持たせ、一斉大量アクセスのみを排除することを狙います。

ブランケットルールで一次的に大洪水を食い止めつつ、詳細ルールで漏れた攻撃を拾う多層防御が望ましいです。

また攻撃が明らかな場合はルールアクションをBlockではなくCAPTCHAにする手もあります。

CAPTCHAを挟めば、人間の正規ユーザーは手間をかければ先に進める一方、ボットは突破しづらくなります。

DDoSのような過剰アクセスではCAPTCHA連打も困難になるため、有効な緩和策となるでしょう。

3-2. スクレイピングやボットによる大量アクセス制御

3-2-1. しきい値設定の目安

対象ページの性質によります。

例えばログインページの場合、通常ユーザーが5分間に10回以上ログイン試行することは考えづらいでしょう。

このためログインURIには「5分間に10リクエスト」程度の低いしきい地を設定し、ブルートフォース攻撃やクレデンシャルスタッフィングを試みるボットを封じます。

また検索APIやデータエクスポート機能などサーバー負荷が高い操作については、通常ユーザーの利用頻度を考慮しつつしきい値を決めます。

例えば検索APIならユーザーが連続で検索するにしてもせいぜい数十回/分でしょうから「1分間に20～30回」などと設定します。

3-2-2. スクレイピング対策の注意

スクレイピングボットはIPアドレスを頻繁に変えてきたり、分散して低頻度アクセスを装ったりする場合があります。

このような分散ボットには単純なIPアドレス単位のレート制限だけでは効果が限定的です。

その場合、AWS WAFのマネージドルール(Bot Control) の活用や、異常な振る舞い検知と連携した対策も検討しましょう

レートベースルールは「明らかに多すぎる」アクセスの切り捨てが本領なので、分散型の低頻度スクレイピングは別の検知ロジックとの組み合わせが有効と考えています。

3-3. APIエンドポイントの保護

3-3-1. しきい値設定の目安

提供しているAPIの性質と利用プランに依存します。

例えば無料プランのAPIキーは1分あたり60リクエストまで、有料プランは1秒あたり10リクエストまでなど、サービスのSLAに合わせて調整します。

AWS WAF単体ではミリ秒単位の制御は難しいため、5分あたりの粒度で現実的な数字を設定しましょう。

また、API Gatewayなど他のサービスが用意するスロットル機能も並用して、WAFでは一歩手前の粗めの制限をかける設計も考えられます。

3-3-2. 補足

API保護ではレート制限に加え、異常なパターン検出（例: 通常は発生し得ないAPI操作の組み合わせ）や認証・認可の適切な実装も重要です。

レートベースルールは過剰リクエストという観点では強力ですが、不正なペイロードそのものの検知は別途SQLインジェクションルールやカスタムルールに委ねる必要があります。

包括的なAPIセキュリティ対策の一部として位置付けると良いでしょう。

AWSの情報セキュリティ対策に関するお問い合わせはこちら！

4. レートベースルール運用中のトラブル対応

実際にレートベースルールを導入した後、運用中に起こり得るトラブルとその対処法について解説します。

4-1. 正常ユーザーの誤ブロックが発生した場合

4-1-1. しきい値の緩和

まずは本当に誤ブロックかどうか、ログを確認します。

ブロックされたリクエストのhttpRequest.clientIpやURIを見て、正当な利用なのに引っかかっていればしきい値を上げることを検討します。

一時的な対処としてルールをCOUNTモードにして様子を見るのも有効です。

COUNTモードにすればブロックせずカウントだけするので、ユーザー影響を止めつつログ収集できます。そのログから適切なしきい値を再設定し、再度Blockに戻します。

4-1-2. スコープダウンの活用

誤ブロックが特定のリクエストに偏っている場合、レートベースルールにスコープダウン条件を追加するのも手です。

例えば「画像ファイルへのアクセスは頻度が高くても問題ないが、APIへのアクセスは制限したい」という場合、スコープダウンで「*.png」や「*.jpg」など画像パスを除外することができます。これにより本当に守りたい対象だけカウントするよう絞り込み、誤ブロックを減らせます。

4-1-3. ホワイトリストの適用

特定の重要ユーザーやモニタリングシステムなど、レート制限から除外すべきIPが明確な場合は、先に許可ルールを置いてそのIPアドレスを無条件許可する方法があります。

AWS WAFではルールは上から順に評価されるため、レートベースルールより上位に「自社オフィスのIPアドレスはAllow」といった静的IP許可ルールを入れておけば、そのIPアドレスはレート制限にかかりません。ただし攻撃に悪用される恐れがないか慎重に判断しましょう。

4-1-4. CAPTCHA/Challengeの活用

ブロックではなくCAPTCHAやChallenge（ブラウザ検証）アクションを使うことで、完全遮断せずに人間ユーザーには突破口を与えることもできます。

もし誤ブロックが懸念されるルールなら、初期段階ではBlockではなくCAPTCHAを選び、ユーザーには多少手間をかけてもらって通過してもらう運用も考えられます。

4-2. クライアントIPの誤認識による問題

4-2-1. Forwarded IPの設定確認

WAFのレートベースルール設定を確認し、集計キーが「IPアドレス（ヘッダ経由）」になっているか（CloudFront経由の場合）見直します。

設定漏れであれば速やかにX-Forwarded-Forを指定して有効化します。

設定変更後はWAFカウントがリセットされ保護が緩む点に注意ですが、問題が致命的な場合は背に腹は代えられません。

4-2-2. 二重プロキシ環境

複数段のプロキシを経由してX-Forwarded-Forヘッダに複数IPが入るケースでは、WAFはヘッダの先頭（最初）のIPアドレスを使います。

通常最初が元クライアントですが、環境によっては順序が異なることもあります。その際はアプリケーション全体でXFFの扱いを統一し、必要ならファイアウォール等で独自ヘッダにIPアドレスを入れるなどの対策も検討してください。

AWSの情報セキュリティ対策に関するお問い合わせはこちら！

5. 運用上の工夫とAWS公式ベストプラクティス

最後に、AWS公式ドキュメントやベストプラクティスに基づいた運用上の留意点をまとめます。

5-1. 段階的導入

いきなりBlock運用にせず、まずはCountアクションで導入しログ分析→しきい値調整→問題なさそうならBlockに切り替えという段階的な適用が望ましいでしょう。

これにより誤ブロックのリスクを最小化できます。

5-2. 定期的なログ分析としきい値見直し

トラフィックパターンは時間とともに変化します。

定期的（月次や四半期など）にWAFログを分析し、現在のしきい値が適切かをチェックしましょう。

例えば新サービス開始でトラフィックが増えた場合、以前はしきい値内だった正規ユーザーが超えるようになるかもしれません。

ログやサンプルレポートで誤検知がないか確認しつつしきい値を調整し、問題なければBlockに切り替える運用を目指しましょう。

5-3. 複数レイヤーでの防御

レートベースルールは非常に有用ですが、単一の対策に過信しないことも重要です。

AWS WAFには他にもGeo制限、IPセット、Managed Rulesによる既知攻撃パターン遮断など多彩な機能があります。

レートベースルールで量的防御をしつつ、他ルールで質的防御（SQLiやXSSなど内容面の防御）を組み合わせ、総合的に防御力を高めましょう。

5-4. CloudFrontとの併用

CloudFrontが使えるならWAFと組み合わせてエッジでブロックするのが理想的です。

これは性能面・情報セキュリティ面双方のメリットがあります。

CloudFrontの利用が難しい場合でも、ALBでWAFを適用しつつ、Shield AdvancedでL3/L4の対策を講じるなど、多層防御のアーキテクチャを検討してください。

5-5. 限界の認識

AWS WAFレートベースルールは万能ではありません。

先にお伝えした1万IPを超える超分散攻撃には対応しきれないことがあり、30秒程度の短時間バーストはすり抜けることもあります。

これらの限界を理解した上で、必要に応じて対策（例えばAWS Shield Advancedの自動拡張ルールや、アプリ側での流量制御）も組み合わせてください。

AWSの情報セキュリティ対策に関するお問い合わせはこちら！

6. まとめ

AWS WAFのレートベースルールについて、内部動作の仕組みから設定のポイント、しきい値設計、そして運用時のトラブル対応やベストプラクティスまでを解説しました。

レートベースルールは、DDoS攻撃や不審な大量アクセスからWebアプリケーションを守る上で非常に有効な機能です。

ただし、その効果を最大限に発揮するには、しきい値のチューニングや運用設計の工夫が欠かせません。

「どのレートでブロックすべきか？」「誤検知が出たときはどうするか？」といった実運用上の課題に向き合いながら、自社のトラフィック特性や情報セキュリティ要件に合わせたルール設計が求められます。

適切に設計・運用されたWAFルールは、目立つことなく、しかし確実にアプリケーションを守ってくれる存在になります。

ぜひみなさんの環境に最適なレートベースルールの活用を進めてみてください。