AWS WAFのレート制限について

AWS WAFのレート制限は、主にレートベースルールを使って実現する機能です。

一定時間内に、特定の条件に一致するリクエスト数を集計し、設定した上限を超えたリクエストに対して、Count、Block、CAPTCHA、Challengeなどのアクションを適用できます。

たとえば、同一IPアドレスから短時間に大量のアクセスが発生した場合や、ログインページに対して不自然に多いPOSTリクエストが送られている場合に、AWS WAFで自動的に検知・制御できます。

AWS WAFのレート制限は、単純に「サイト全体のアクセス数を制限する機能」ではありません。

IPアドレス、URIパス、HTTPメソッド、ヘッダー、Cookie、クエリ文字列などを使って、条件ごとに細かく集計できる点が特徴です。

そのため、DDoS的な大量アクセス対策だけでなく、ログイン試行、スクレイピング、APIの過剰利用、検索ページへの集中アクセスなど、さまざまな場面で活用できます。

AWS WAFのレート制限でできること

AWS WAFのレート制限を使うと、特定の条件に一致するリクエストに対して、一定時間あたりのアクセス数を制御できます。

たとえば、同一IPアドレスから短時間に大量のリクエストが来た場合にブロックできます。

ログインページやAPIエンドポイントなど、特定のURLだけを対象に制限することもできます。

HTTPメソッドがPOSTのリクエストだけを対象にすれば、通常のページ閲覧を巻き込まずに、ログイン試行やフォーム送信だけを制御しやすくなります。

また、IPアドレス、URIパス、HTTPメソッド、ヘッダー、Cookieなどを組み合わせて、より細かい単位でリクエストを集計できます。

最初はリクエストをブロックせず、Countで記録だけを行い、影響範囲を確認してからBlockやChallengeに切り替える運用も可能です。

さらに、CAPTCHAやChallengeを使えば、正規ユーザーのアクセスを完全に遮断せず、不審な自動アクセスをふるいにかけることができます。

レートベースルールの基本構造

AWS WAFのレートベースルールは、主に以下の要素で構成されます。

Evaluation window

Evaluation windowは、AWS WAFがどのくらいの時間を対象にリクエスト数を数えるかを決める設定です。

現在のAWS WAFでは、60秒、120秒、300秒、600秒を選択できます。

デフォルトは300秒です。

つまり、1分、2分、5分、10分のいずれかの時間範囲で、条件に一致するリクエスト数を集計します。

注意したいのは、Evaluation windowは「AWS WAFが何秒ごとにチェックするか」ではないという点です。

これは、AWS WAFが評価時にどれだけ過去にさかのぼってリクエスト数を見るかを指定する設定です。

Rate limit

Rate limitは、Evaluation window内で、1つの集計インスタンスごとに追跡するリクエスト数の上限です。

たとえば、IPアドレスで集計する場合は、各IPアドレスごとにRate limitが適用されます。

URIパスで集計する場合は、各URIパスごとにRate limitが適用されます。

Evaluation windowを300秒、Rate limitを1,000にした場合、5分間で1,000リクエストを超えた集計インスタンスに対して、指定したアクションが適用されます。

現在のAWS WAFでは、Rate limitの最小値は10です。

API仕様上の最大値は2,000,000,000です。

ただし、実務では最大値よりも、通常時のアクセス量と異常アクセスの差をログで把握し、適切なしきい値を決めることが重要です。

Request aggregation

Request aggregationは、何を単位にリクエスト数を集計するかを決める設定です。

代表的な集計単位には、IPアドレス、Forwarded IP、ASN、HTTPヘッダー、Cookie、クエリ引数、クエリ文字列、URIパス、HTTPメソッド、ラベル名前空間、JA3フィンガープリント、JA4フィンガープリントなどがあります。

単純にIPアドレスごとに制限することもできますし、IPアドレスとURIパスを組み合わせて、特定のIPが特定のパスに大量アクセスしている場合だけを制限することもできます。

複数の集計キーを組み合わせた場合は、それぞれの値の組み合わせごとに別々に集計されます。

Scope-down statement

Scope-down statementは、レート制限の対象となるリクエストを絞り込む条件です。

たとえば、サイト全体ではなくログインページだけを対象にしたい場合、ログインページに一致するURIパスだけを集計対象にできます。

また、APIだけ、検索ページだけ、POSTリクエストだけ、特定国からのアクセスだけといったように、対象範囲を細かく指定できます。

Scope-down statementを使わずにサイト全体へ強いレート制限をかけると、通常ユーザーのアクセスまで巻き込む可能性があります。

そのため、実務では守りたいエンドポイントごとに対象を絞る設計が重要です。

Action

Actionは、しきい値を超えたリクエストに対してAWS WAFが実行する処理です。

主なアクションには、Count、Block、CAPTCHA、Challengeがあります。

Countは、リクエストをブロックせず、条件に一致したことだけを記録します。

新しいルールを導入する際は、まずCountで影響範囲を確認するのが安全です。

Blockは、しきい値を超えたリクエストをブロックします。

CAPTCHAは、対象リクエストに対してCAPTCHAを要求します。

Challengeは、ブラウザにチャレンジを実行させ、自動化されたアクセスを抑制するために使われます。

Evaluation windowの考え方

Evaluation windowは、レート制限の反応速度や検知の性質に影響します。

短いEvaluation windowは、短時間の急激なアクセス増加に反応しやすい一方で、通常ユーザーの一時的な操作集中にも反応しやすくなります。

長いEvaluation windowは、継続的な大量アクセスを検知しやすい一方で、短時間のスパイクにはやや緩やかに反応します。

60秒

60秒は、短時間の急激なアクセス増加に反応しやすい設定です。

ログイン試行、APIの短時間連打、検索機能への瞬間的な大量アクセスなどに向いています。

一方で、通常ユーザーの操作が一時的に集中した場合も検知しやすくなるため、しきい値を低くしすぎると誤検知の可能性があります。

120秒

120秒は、1分より少し余裕を持たせつつ、短時間の異常アクセスにも対応しやすい設定です。

ログインやAPI保護で、60秒では少し厳しすぎる場合に検討できます。

急激な攻撃を見たいが、ある程度の通常操作も許容したい場合に使いやすい評価ウィンドウです。

300秒

300秒は、AWS WAFのデフォルトの評価ウィンドウです。

5分間のアクセス数をもとに判定するため、一般的なWebサイトの異常アクセス対策やスクレイピング対策で使いやすい設定です。

まずは300秒でCount運用を行い、ログを見ながら調整する方法が実務では扱いやすいです。

600秒

600秒は、10分間の継続的な高負荷アクセスを検知しやすい設定です。

短時間のスパイクよりも、長く続くスクレイピングや継続的な大量アクセスを抑えたい場合に向いています。

ただし、長い時間で集計する分、レートが下がった後も制限が続くように見える場合があるため、運用時にはログを見ながら調整する必要があります。

Rate limitを決めるときの考え方

Rate limitは、実際のアクセス状況を確認したうえで決めるのが基本です。

いきなり低い値でBlockを設定すると、正規ユーザー、社内ユーザー、監視サービス、外部連携サービス、検索エンジンクローラーなどを誤って制限してしまう可能性があります。

Rate limitは集計インスタンスごとの上限

Rate limitは、Web ACL全体の合計リクエスト数に対する上限ではありません。

どのように集計するかによって、Rate limitが適用される単位は変わります。

IPアドレスで集計する場合は、IPアドレスごとの上限になります。

URIパスで集計する場合は、URIパスごとの上限になります。

IPアドレスとURIパスを組み合わせる場合は、IPアドレスとURIパスの組み合わせごとの上限になります。

この点を理解していないと、「サイト全体で1,000リクエストを超えたら制限される」と誤解してしまう可能性があります。

まずはCountで様子を見る

新しいレート制限ルールを作る場合は、最初からBlockにするのではなく、まずCountで運用するのがおすすめです。

Countであれば、しきい値を超えたリクエストを記録しながら、実際のアクセスは止めません。

その状態でAWS WAFログやCloudWatch Metricsを確認し、どのIP、どのURI、どの時間帯でしきい値を超えているのかを分析します。

Countで十分に確認してから、Block、CAPTCHA、Challengeなどのアクションに切り替えるほうが安全です。

通常時の最大値を把握する

しきい値を決めるには、通常時のリクエスト量を把握する必要があります。

IPアドレスごとの5分間リクエスト数、ログインページへのPOST回数、APIエンドポイントごとのアクセス数、検索ページへのアクセス頻度などを確認します。

通常ユーザーの最大値と、明らかに不審なアクセスの差が見えてくると、適切なしきい値を決めやすくなります。

逆に、ログを見ずにしきい値を決めると、通常アクセスを攻撃と誤判定したり、攻撃アクセスを十分に抑えられなかったりする可能性があります。

しきい値はエンドポイントごとに考える

サイト全体に同じしきい値を適用するのは、あまり安全ではありません。

トップページ、商品一覧ページ、検索ページ、ログインページ、API、管理画面では、正常なアクセス頻度が大きく異なります。

特に検索ページやAPIは、通常ユーザーでも短時間に複数回アクセスする場合があります。

一方で、ログインページへのPOSTは、通常であれば短時間に大量発生しにくいリクエストです。

そのため、特に守りたいエンドポイントごとにルールを分けて、個別にしきい値を設定するのが実務的です。

Request aggregationの設計ポイント

AWS WAFのレート制限では、何を基準に集計するかが非常に重要です。

同じRate limitでも、集計キーの選び方によって制限の効き方は大きく変わります。

IPアドレスで集計する場合

最も基本的なのは、IPアドレスごとの集計です。

同一IPアドレスから大量のリクエストが来た場合に制限できるため、単純な大量アクセスや雑なクローラー対策に向いています。

ただし、企業ネットワーク、学校、公共Wi-Fi、モバイルキャリア、VPN、プロキシ環境では、複数の正規ユーザーが同じIPアドレスに見えることがあります。

そのため、IPアドレス単位の制限を厳しくしすぎると、複数の正規ユーザーをまとめて制限してしまう可能性があります。

Forwarded IPで集計する場合

Forwarded IPは、X-Forwarded-Forなどのヘッダーに含まれるIPアドレスを使って集計する方法です。

CloudFront、ALB、リバースプロキシなどを経由している構成では、AWS WAFが直接見る送信元IPが、実際のクライアントIPではない場合があります。

そのような場合に、Forwarded IPを使うことで、実クライアントIPに近い値をもとにレート制限できることがあります。

ただし、ヘッダーは構成によって扱いが変わります。

また、信頼できない経路から送られてくるヘッダーは改変される可能性があります。

そのため、Forwarded IPを使う場合は、WAFログで期待どおりのIPアドレスが使われているかを確認することが重要です。

URIパスで集計する場合

URIパスを集計キーにすると、パスごとにリクエスト数を集計できます。

たとえば、ログインページ、検索ページ、商品詳細ページ、APIエンドポイントなど、それぞれのパスごとにアクセス数を把握できます。

ただし、URIパスだけで集計すると、すべてのユーザーのアクセスがパス単位でまとまります。

そのため、特定ユーザーや特定IPからの大量アクセスを識別する用途には向かない場合があります。

実務では、URIパス単独よりも、IPアドレスとURIパスを組み合わせるほうが使いやすいことが多いです。

HTTPメソッドで集計する場合

HTTPメソッドを集計キーにすると、GET、POST、PUT、DELETEなどのメソッドごとに分けて集計できます。

ログイン試行、フォーム送信、API更新処理などでは、POSTリクエストだけを対象にすることで、通常のページ閲覧を巻き込みにくくなります。

特にログインページでは、GETによるページ表示とPOSTによる認証試行を分けて考えることが重要です。

Headerで集計する場合

HTTPヘッダーを集計キーにすると、User-Agent、APIキー、独自ヘッダーなどをもとに集計できます。

APIクライアントごと、アプリバージョンごと、特定のUser-Agentごとにアクセス傾向を見たい場合に便利です。

ただし、User-Agentなどのヘッダーは簡単に偽装される可能性があります。

また、指定したヘッダーが存在しないリクエストは、想定どおりに集計されない可能性があります。

そのため、Headerを集計キーに使う場合は、ヘッダーの有無や値のばらつきをログで確認する必要があります。

Cookieで集計する場合

Cookieを集計キーにすると、セッションIDや特定のCookie値をもとに集計できます。

IPアドレスだけでは同一ユーザーを識別しにくい場合や、セッション単位でアクセス頻度を見たい場合に役立ちます。

ただし、Cookieが存在しないリクエストや、Cookieが削除・変更されたリクエストの扱いには注意が必要です。

また、Cookieベースの制御は、アプリケーションのセッション設計と密接に関係します。

AWS WAFだけで完結させるのではなく、アプリケーション側の制御と組み合わせて考えると安全です。

Query argumentやQuery stringで集計する場合

Query argumentやQuery stringを使うと、URLのクエリパラメータをもとに集計できます。

検索キーワード、商品ID、ページ番号、APIパラメータなどを基準にしたアクセス傾向を見たい場合に使えます。

ただし、クエリパラメータは値の種類が非常に多くなりやすいため、集計が細かく分散する可能性があります。

また、攻撃者がクエリパラメータをランダムに変えると、同じアクセスパターンでも別々の集計インスタンスとして扱われる可能性があります。

そのため、Query argumentやQuery stringを集計キーに使う場合は、目的を明確にして設計する必要があります。

JA3・JA4フィンガープリントで集計する場合

JA3やJA4フィンガープリントは、TLSクライアントの特徴をもとにした識別情報です。

IPアドレスやUser-Agentだけでは識別しづらい自動化アクセスやBot対策で活用できる場合があります。

ただし、JA3やJA4だけに依存するのではなく、URIパス、IPアドレス、Challenge、Bot Controlなどと組み合わせて使うほうが安全です。

Botやスクレイピングへの対策では、単一の指標だけで判断するよりも、複数の条件を組み合わせて段階的に制御することが重要です。

複数の集計キーを組み合わせる場合

AWS WAFでは、複数の集計キーを組み合わせることができます。

たとえば、IPアドレス、URIパス、HTTPメソッドを組み合わせた場合、それぞれの値の組み合わせごとに別々に集計されます。

つまり、同じIPアドレスからのアクセスでも、ログインページへのPOSTと、商品一覧ページへのGETは別々の集計対象になります。

この仕組みにより、より細かくレート制限を設計できます。

組み合わせるメリット

複数の集計キーを組み合わせると、制限対象をより細かく分けられます。

たとえば、IPアドレスだけで制限すると、同じIPからの通常閲覧とログイン試行がまとめてカウントされます。

一方で、IPアドレスとURIパスを組み合わせると、どのIPがどのパスに大量アクセスしているのかをより正確に捉えられます。

さらにHTTPメソッドを組み合わせれば、GETとPOSTを分けて制御できます。

組み合わせすぎるデメリット

集計キーを増やせばよいというものではありません。

キーを増やすほど集計が細かく分散し、1つの集計インスタンスあたりのリクエスト数が少なくなる場合があります。

その結果、本来検知したい異常アクセスが、複数の集計インスタンスに分散して検知されにくくなる可能性があります。

また、カスタム集計キーを増やすとWCUも増えます。

AWS WAFの設計では、精度とコスト、運用しやすさのバランスを考えることが重要です。

カスタム集計キーの上限

カスタム集計キーは複数組み合わせられますが、API仕様上は最大5個までです。

キーを増やすほど細かく制御できますが、WCUが増え、集計も分散します。

そのため、実務では必要最小限のキーを選ぶのが基本です。

Scope-down statementの使い方

Scope-down statementは、AWS WAFのレート制限を安全に運用するうえで非常に重要です。

対象範囲を絞らずにサイト全体へ強い制限をかけると、通常ユーザーの閲覧や静的ファイルの読み込みまで巻き込む可能性があります。

そのため、ログイン、API、検索、管理画面など、守りたい場所に絞って設計することが重要です。

ログインページだけを対象にする

ログインページは、総当たり攻撃や認証情報の詰め込み攻撃の対象になりやすい場所です。

そのため、ログインページへのPOSTリクエストだけを対象にレート制限を設定すると、通常のページ閲覧を巻き込まずにログイン試行を抑制できます。

ログインページでは、誤検知すると正規ユーザーがログインできなくなるため、最初はCountで運用し、慎重にしきい値を調整するのが安全です。

APIだけを対象にする

APIエンドポイントは、短時間に大量アクセスされるとアプリケーションやデータベースへの負荷が高くなります。

API配下のURIパスだけを対象にし、IPアドレスやURIパス単位で集計すると、特定APIへの過剰アクセスを検知しやすくなります。

ただし、APIによって正常なアクセス頻度は異なります。

認証API、検索API、一覧取得API、更新APIでは、許容すべきリクエスト数が変わります。

そのため、API全体に一律の制限をかけるより、重要なAPIごとに分けて設計するほうが安全です。

検索ページだけを対象にする

検索ページは、スクレイピングや高負荷なクエリの対象になりやすいページです。

検索ページだけを対象にレート制限をかけることで、通常閲覧への影響を抑えつつ、高負荷なアクセスを制御できます。

検索ページでは、BlockだけでなくChallengeやCAPTCHAを使うことも検討できます。

自動化アクセスを抑えながら、人間のユーザーには通過手段を残せるためです。

商品一覧や記事一覧を対象にする

ECサイトの商品一覧ページやメディアサイトの記事一覧ページは、スクレイピングの対象になりやすい場所です。

これらのページに対して、IPアドレスとURIパスを組み合わせたレート制限を設定すると、特定のクライアントによる大量巡回を検知しやすくなります。

ただし、正規の検索エンジンクローラーや比較サイト、外部連携サービスなどがアクセスする場合もあるため、ログを見ながら慎重に調整する必要があります。

管理画面だけを対象にする

管理画面は、通常ユーザーがアクセスしない領域です。

そのため、通常ページよりも厳しめのレート制限を設定しやすい場所です。

管理画面への不審なアクセスが多い場合は、レート制限だけでなく、IP制限、認証強化、多要素認証などと組み合わせると効果的です。

静的ファイルを除外する

サイト全体を対象にレート制限する場合、CSS、JavaScript、画像ファイルなどの静的ファイルを含めると、通常ユーザーでもリクエスト数が増えやすくなります。

1ページを表示するだけでも、HTML、CSS、JavaScript、画像、フォント、API通信など、複数のリクエストが発生するためです。

そのため、必要に応じて静的ファイルを除外し、HTMLページやAPIなど、本当に守りたいリクエストだけを対象にすることが重要です。

Actionの選び方

レート制限に引っかかったリクエストに対して、どのアクションを使うかは慎重に決める必要があります。

同じルールでも、Countにするのか、Blockにするのか、CAPTCHAやChallengeにするのかで、ユーザーへの影響は大きく変わります。

Count

Countは、検証段階で最も安全なアクションです。

リクエストを止めずに、ルールに一致したかどうかを確認できます。

新しいレート制限ルールを作る場合は、まずCountで運用し、ログを見てからBlockやChallengeに切り替えるのが基本です。

Countを使うことで、どのIP、どのURI、どのUser-Agent、どの時間帯でしきい値を超えているのかを確認できます。

Block

Blockは、条件に一致したリクエストを拒否するアクションです。

明らかに不正なアクセス、攻撃的なリクエスト、通常ユーザーが到達しないような異常なアクセスに対して有効です。

ただし、誤検知した場合は正規ユーザーを直接止めてしまいます。

そのため、事前にCountで影響を確認してから使うのが安全です。

CAPTCHA

CAPTCHAは、ユーザーにCAPTCHAを要求するアクションです。

自動化されたアクセスを抑制しつつ、人間のユーザーには通過手段を提供できます。

ただし、ユーザー体験に影響するため、すべてのページで安易に使うのではなく、ログイン、検索、フォーム送信など、必要な場所に絞って使うのがよいです。

Challenge

Challengeは、ブラウザにチャレンジを実行させるアクションです。

人間のユーザーには比較的目立ちにくく、自動化されたBotや簡易的なスクリプトを抑制できる場合があります。

スクレイピング対策やBot対策では、いきなりBlockするよりもChallengeのほうが実務上扱いやすいケースがあります。

CAPTCHAとChallengeの注意点

CAPTCHAやChallengeは、しきい値を超えたすべてのリクエストを常に止め続けるものではありません。

有効なトークンを持たないリクエストにはCAPTCHAやChallengeが課されますが、有効なトークンを持っているリクエストは、BlockされずにWeb ACLの評価が継続される場合があります。

そのため、CAPTCHAやChallengeは「完全に遮断する」機能というより、「自動化アクセスをふるいにかける」ための機能として考えるとよいです。

完全に止めたいアクセスに対してはBlockを使い、人間とBotを分けたい場面ではCAPTCHAやChallengeを検討します。

Count allを使う場合の注意点

AWS WAFには、Count allという集計方法もあります。

Count allは、個別のIPアドレスやURIパスごとではなく、条件に一致するリクエスト全体を1つの集計単位として数える方法です。

たとえば、特定のキャンペーンページ全体へのアクセスが急増した場合に、全体のリクエスト数を基準に制限できます。

Count allではScope-down statementが必須

Count allを使う場合、Scope-down statementは必須です。

Scope-downなしでCount allを使う構成は選べないため、必ず対象範囲を明確に絞ったうえで設定します。

たとえば、キャンペーンページ、特定API、特定フォームなど、対象を明確にしたうえでCount allを使うのが安全です。

Count allが向いているケース

Count allは、特定の条件に一致するリクエスト全体をまとめて制御したい場合に向いています。

たとえば、キャンペーンページへのアクセスが全体として急増した場合や、特定のAPI全体の負荷を抑えたい場合に使えます。

一方で、特定のIPアドレスや特定ユーザーの過剰アクセスを抑えたい場合には、IPアドレスやCookieなどを使った集計のほうが適しています。

Forwarded IPを使う場合の注意点

AWS WAFでIPアドレス単位のレート制限を行う場合、WAFがどのIPアドレスを見ているかを確認する必要があります。

CloudFront、ALB、リバースプロキシなどを経由している構成では、AWS WAFから見える送信元IPが、必ずしも実際のクライアントIPとは限りません。

構成によって見えるIPが変わる

AWS WAFをCloudFrontに関連付けているのか、ALBに関連付けているのか、あるいは手前に別のプロキシがあるのかによって、送信元IPやForwarded IPの扱いは変わります。

そのため、設定前にWAFログを確認し、期待どおりのIPアドレスで集計できているかを見ることが重要です。

「IPアドレスごとに制限しているつもりだったが、実際にはプロキシのIPで集計されていた」という状態になると、多数の正規ユーザーをまとめて制限してしまう可能性があります。

X-Forwarded-Forの扱いに注意する

実クライアントIPを取得するために、X-Forwarded-Forなどのヘッダーを使うことがあります。

ただし、ヘッダーは構成によって値が異なり、場合によってはクライアント側で改変される可能性もあります。

Forwarded IPを使う場合は、信頼できるプロキシやロードバランサーを経由していること、ヘッダーの値が期待どおりであることを確認する必要があります。

また、ログ上で実際にどのIPが集計に使われているかを確認してから、本番でBlockを有効化するのが安全です。

WCUの考え方

AWS WAFでは、ルールやWeb ACLの容量をWCUという単位で管理します。

WCUはWeb ACL Capacity Unitの略で、ルールを実行するために必要な処理容量を表します。

レート制限の設計では、細かい条件を増やすほどWCUが増える点に注意が必要です。

レートベースルールの基本WCU

レートベースルールの基本WCUは2です。

ただし、カスタム集計キーを使う場合は、集計キー1つごとに30 WCUが追加されます。

また、Scope-down statementを使う場合は、その条件に必要なWCUも加算されます。

カスタム集計キーを増やすとWCUも増える

IPアドレスだけで集計する単純なレートベースルールは軽量です。

一方で、URIパス、HTTPメソッド、ヘッダー、Cookieなどのカスタム集計キーを追加すると、その分WCUが増えます。

細かい制御ができる一方で、Web ACL全体のWCU上限やコスト面も考慮する必要があります。

実務では、「細かくしすぎて運用しづらくなる」こともあります。

最初はシンプルなルールから始め、ログを見ながら必要に応じて集計キーを追加する方法が安全です。

AWS WAFのレート制限は厳密な秒間制御ではない

AWS WAFのレート制限で特に重要なのは、厳密な秒間リクエスト数制御ではないという点です。

たとえば、「1秒あたり10リクエストを超えた瞬間に必ず止める」といった用途には向いていません。

AWS WAFは、最近のリクエスト傾向をもとに現在のリクエストレートを評価し、設定した上限の近くで制限を適用します。

そのため、しきい値を超えた瞬間に完全に一致して制限されるわけではありません。

可用性保護に向いた機能

AWS WAFのレート制限は、可用性保護、攻撃緩和、異常トラフィック抑制に向いた機能です。

短時間に大量のリクエストが発生してアプリケーションへ負荷がかかる前に、WAF側で一定の制御を行えます。

特に、Webアプリケーションの前段で広く防御したい場合に有効です。

厳密な利用回数管理には向かない

AWS WAFのレート制限は、課金や契約プランに関わるような厳密な利用回数管理には向きません。

たとえば、ユーザーIDごとに1日1,000回まで、契約プランごとに1分100回まで、APIキーごとに正確な使用量を管理するといった用途では、アプリケーション側やAPI Gatewayなどの仕組みを使うべきです。

AWS WAFは、アプリケーションの前段で異常トラフィックを抑えるための機能として考えるとよいです。

検知や解除には遅延がある

AWS WAFのレート制限では、検知や解除に多少の遅延があります。

高いリクエストレートが続いてから制限が始まることもあります。

また、リクエストレートが下がった後もしばらく制限が続くことがあります。

そのため、AWS WAFのレート制限は、リアルタイムで完全に正確な制御をするものではなく、一定の幅を持った防御機能として理解しておく必要があります。

設定変更時の注意点

レートベースルールの設定を変更すると、そのルールのカウントがリセットされる場合があります。

対象になる設定には、Evaluation window、Rate limit、Request aggregation、Forwarded IP configuration、Scope of inspectionなどが含まれます。

カウントがリセットされると、最大で1分ほどレート制限が一時的に停止する可能性があります。

本番環境での変更は慎重に行う

本番環境で頻繁にレート制限設定を変更すると、一時的に制限が緩む可能性があります。

特に攻撃中にしきい値を調整する場合、変更直後にカウントがリセットされ、一定時間レート制限が効きにくくなることがあります。

そのため、本番環境では変更内容を事前に検討し、可能であればCountで検証してから本番適用するのが安全です。

設定変更後はログを確認する

設定変更後は、AWS WAFログやCloudWatch Metricsを確認し、想定どおりにルールが動作しているかを確認します。

どの集計インスタンスがしきい値を超えているのか、正規ユーザーが巻き込まれていないか、BlockやChallengeの対象が意図どおりかを確認することが重要です。

実務でよく使う設計パターン

AWS WAFのレート制限は、目的ごとにルールを分けて設計するのが基本です。

サイト全体に一律で強い制限をかけるよりも、攻撃されやすい場所や負荷が高くなりやすい場所に絞って設計するほうが安全です。

サイト全体の異常アクセス対策

サイト全体に対して、IPアドレスごとのレート制限を設定するパターンです。

単一IPアドレスからの大量アクセス、簡易的なクローラー、雑な攻撃トラフィックへの対策として有効です。

ただし、サイト全体を対象にすると、静的ファイルや通常閲覧も含まれるため、しきい値を低くしすぎないことが重要です。

また、企業ネットワークやモバイルキャリアのように、複数ユーザーが同じIPアドレスに見える環境も考慮する必要があります。

ログインページ保護

ログインページは攻撃対象になりやすいため、個別にレート制限を設定するのがおすすめです。

URIパスをログインページに絞り、さらにHTTPメソッドをPOSTに限定すると、通常のページ表示を巻き込まずにログイン試行だけを制御しやすくなります。

アクションは、最初はCountで様子を見て、その後Challenge、CAPTCHA、Blockを検討します。

ログインページでは、誤検知すると正規ユーザーがログインできなくなるため、慎重な調整が必要です。

APIエンドポイント保護

APIは、短時間に大量アクセスされるとアプリケーションやデータベースに大きな負荷がかかります。

API配下のURIパスを対象にして、IPアドレスやURIパス単位で集計すると、特定APIへの過剰アクセスを検知しやすくなります。

ただし、APIによって正常なアクセス頻度は異なります。

検索API、認証API、一覧取得API、更新APIでは、適切なしきい値が変わります。

そのため、API全体に一律の制限をかけるより、重要なAPIごとにルールを分けるほうが安全です。

スクレイピング対策

商品一覧ページ、検索ページ、記事一覧ページなどは、スクレイピングの対象になりやすい場所です。

スクレイピング対策では、IPアドレス、URIパス、User-Agent、JA3、JA4、Challengeなどを組み合わせて設計します。

いきなりBlockすると正規ユーザーや検索エンジンに影響する可能性があるため、まずはCountで確認し、その後ChallengeやCAPTCHAを検討するのがよいです。

管理画面保護

管理画面は、通常ユーザーがアクセスしない領域です。

そのため、管理画面へのアクセスに対しては、通常ページよりも厳しめの制限を設定できます。

ただし、管理者が固定IPからアクセスできる場合は、IP制限や許可リストと組み合わせるほうが効果的です。

レート制限は、管理画面保護の一部として使うのがよいです。

よくある失敗

AWS WAFのレート制限では、設定を誤ると正規ユーザーに影響が出る可能性があります。

特に、対象範囲、しきい値、集計キー、アクションの選び方には注意が必要です。

サイト全体に低すぎる制限をかける

サイト全体に対して低いしきい値を設定すると、通常ユーザーでも制限に引っかかる可能性があります。

Webページでは、HTMLだけでなく画像、CSS、JavaScript、フォント、API通信など複数のリクエストが発生します。

特に、SPA、ECサイト、メディアサイト、管理画面、検索機能のあるサイトでは、1人のユーザーでも短時間に多くのリクエストを送ることがあります。

NATや共有IPを考慮しない

IPアドレス単位の制限では、複数のユーザーが同じIPアドレスとして見えるケースがあります。

企業、学校、公共Wi-Fi、マンション回線、モバイルキャリア、VPNなどでは、正規ユーザーがまとめて制限される可能性があります。

そのため、IPアドレス単位のしきい値は、実際のトラフィックを見ながら慎重に決める必要があります。

ログイン対策のつもりで全体を制限する

ログイン試行を防ぎたい場合は、ログインページやログインAPIだけを対象にすべきです。

サイト全体に厳しい制限をかけると、通常閲覧や静的ファイルの読み込みまで巻き込む可能性があります。

ログイン対策では、Scope-down statementを使って、対象をログイン処理に絞ることが重要です。

Forwarded IPの設定を誤る

プロキシやロードバランサーを経由している環境では、AWS WAFが見ているIPアドレスが実クライアントIPではない場合があります。

その状態でIPアドレス単位のレート制限を設定すると、すべてのユーザーが同一IPとして扱われる可能性があります。

設定後は必ずWAFログを確認し、期待どおりのIPで集計されているか確認することが重要です。

いきなりBlockで本番適用する

新しいレート制限ルールをいきなりBlockで本番適用すると、誤検知によって正規ユーザーを止めてしまう可能性があります。

まずはCountで運用し、ログを見ながら調整したうえで、Block、CAPTCHA、Challengeに切り替えるのが安全です。

集計キーを増やしすぎる

細かく制御しようとして集計キーを増やしすぎると、集計が分散しすぎて、検知したい異常アクセスを捉えにくくなる場合があります。

また、カスタム集計キーを増やすほどWCUも増えます。

集計キーは、目的に応じて必要最小限にすることが重要です。

AWS WAFと他のレート制限機能の使い分け

AWS WAFのレート制限は、アプリケーションの前段で異常トラフィックを抑える用途に向いています。

一方で、すべてのレート制限をAWS WAFだけで実現すべきではありません。

目的に応じて、API Gateway、アプリケーション側の制御、AWS Shieldなどと使い分けることが重要です。

AWS WAFが向いている用途

AWS WAFは、攻撃的な大量アクセス、Botによるアクセス、スクレイピング、ログイン試行、特定エンドポイントへの集中アクセスなどを抑える用途に向いています。

アプリケーションに届く前に制御できるため、サーバーやアプリケーションの負荷軽減にも役立ちます。

Webアプリケーション全体を広く守る防御層として使いやすいのが特徴です。

API Gatewayが向いている用途

API Gatewayの使用量プランやスロットリングは、API利用者ごとの制御に向いています。

APIキー単位、プラン単位、利用契約単位で制限したい場合は、AWS WAFよりもAPI Gateway側の機能が適しています。

特に、APIの利用回数や契約プランに関わる制御では、AWS WAFだけに頼らないほうが安全です。

アプリケーション側実装が向いている用途

ユーザーID単位、契約プラン単位、課金単位、会員ランク単位など、アプリケーションの内部情報をもとにした厳密な制御は、アプリケーション側で実装する必要があります。

たとえば、ログインユーザーごとの利用回数、会員プランごとのAPI制限、課金対象となるリクエスト数の管理などは、AWS WAFではなくアプリケーション側で正確に管理するべきです。

Redisなどを使って、ユーザーごとのリクエスト数を正確に管理する方法もあります。

AWS Shieldとの使い分け

大規模DDoS対策では、AWS WAFだけでなくAWS Shield Advancedとの併用も検討します。

AWS WAFはL7、つまりHTTPリクエストレベルの制御に強く、Shieldはより広いDDoS保護に向いています。

大規模な攻撃への備えが必要な場合は、AWS WAFのレート制限だけでなく、ShieldやCloudFront、アプリケーション側の設計も含めて多層防御を考えることが重要です。

実務でのおすすめ運用手順

AWS WAFのレート制限を安全に導入するには、段階的に進めるのが重要です。

いきなりBlockを有効化するのではなく、ログを確認しながら、対象範囲やしきい値を調整していくべきです。

まずログを有効化する

最初にAWS WAFログを有効化します。

ログを見ないまましきい値を決めると、通常アクセスと異常アクセスの区別がつきません。

IPアドレス、URIパス、HTTPメソッド、ヘッダー、ラベル、アクション、タイムスタンプなどを確認できる状態にしておきます。

Countルールを作成する

次に、いきなりブロックせず、Countアクションでレートベースルールを作成します。

この段階では、実際のユーザーには影響を与えず、どのリクエストがしきい値を超えるかを確認します。

Count運用によって、正規ユーザーや外部サービスが誤って制限対象になりそうかどうかを事前に把握できます。

ログを分析する

Countで記録されたログを確認し、しきい値を超えているアクセスが正規ユーザーなのか、不審なアクセスなのかを判断します。

自社IP、監視ツール、外部連携サービス、検索エンジンクローラーなどが含まれていないかも確認します。

ログ分析では、IPアドレスだけでなく、URIパス、HTTPメソッド、User-Agent、国、時間帯なども確認すると、より適切な設計につながります。

Scope-downとしきい値を調整する

ログをもとに、対象範囲やしきい値を調整します。

サイト全体で広すぎる場合は、ログイン、API、検索ページなどに対象を絞ります。

しきい値が低すぎる場合は引き上げ、逆に不審アクセスを十分に捉えられていない場合は引き下げます。

また、必要に応じて静的ファイルを除外したり、特定の正規サービスを許可したりすることも検討します。

BlockやChallengeに切り替える

影響範囲に問題がないことを確認したら、必要に応じてBlock、CAPTCHA、Challengeに切り替えます。

完全に遮断したい場合はBlock、Botをふるいにかけたい場合はChallenge、ユーザー確認を入れたい場合はCAPTCHAを検討します。

切り替え後もログを確認し、正規ユーザーに影響が出ていないかを継続的に監視することが重要です。

AWS WAFのレート制限で特に重要な注意点

AWS WAFのレート制限を正しく使うには、いくつかの重要な注意点を押さえておく必要があります。

厳密な利用回数制御には向かない

AWS WAFは、正確なリクエスト数を保証するための機能ではありません。

課金、契約プラン、ユーザー単位の利用制限など、厳密な制御が必要な場合は、API Gatewayやアプリケーション側の実装を使うべきです。

AWS WAFは、あくまでWebアプリケーションの前段で異常トラフィックを抑える防御機能として考えるのが適切です。

最初はCountで検証する

本番環境では、最初からBlockを使うのはリスクがあります。

必ずCountで検証し、ログを確認してから制限アクションに切り替えるのが安全です。

特にログインページや購入フローなど、ユーザー行動に直結する場所では慎重な検証が必要です。

対象範囲を絞る

サイト全体に強い制限をかけると、通常ユーザーを巻き込む可能性があります。

ログイン、API、検索、商品一覧、管理画面など、守りたい場所に絞って設計することが重要です。

Scope-down statementを適切に使うことで、誤検知のリスクを下げながら効果的に制御できます。

集計キーの存在有無に注意する

Header、Cookie、Query argumentなどを集計キーに使う場合、その値が存在しないリクエストは期待どおりに評価されない可能性があります。

たとえば、特定のCookieを集計キーにしている場合、そのCookieを持たないリクエストは想定した集計に含まれない可能性があります。

そのため、期待どおりに制限できているか、必ずログで確認する必要があります。

Forwarded IPは必ずログで確認する

プロキシやロードバランサーを経由している場合、WAFが見ているIPが実クライアントIPとは限りません。

IPアドレス単位でレート制限する場合は、WAFログで実際の値を確認することが重要です。

特に、X-Forwarded-Forなどのヘッダーを使う場合は、ヘッダーの信頼性と構成を確認したうえで設定する必要があります。

設定変更時の一時停止に注意する

レートベースルールの設定を変更すると、カウントがリセットされ、最大で1分ほどレート制限が一時的に停止する可能性があります。

攻撃中や高負荷時に設定を変更する場合は、この挙動を理解しておく必要があります。

本番環境では、変更後にログとメトリクスを確認し、意図どおりに制限が再開しているかを確認することが大切です。

まとめ

AWS WAFのレート制限は、一定時間内のリクエスト数を集計し、設定したしきい値を超えたリクエストに対して、Count、Block、CAPTCHA、Challengeなどのアクションを適用する機能です。

Evaluation windowは、60秒、120秒、300秒、600秒から選択でき、デフォルトは300秒です。

Rate limitは、Evaluation window内で、1つの集計インスタンスごとに追跡するリクエスト数の上限です。

最小値は10で、API仕様上の最大値は2,000,000,000です。

Request aggregationでは、IPアドレス、Forwarded IP、ASN、URIパス、HTTPメソッド、Header、Cookie、Query、JA3、JA4などを使って集計できます。

複数の集計キーを組み合わせる場合は、値の組み合わせごとに別々に集計されます。

実務では、サイト全体に一律で厳しい制限をかけるのではなく、ログインページ、API、検索ページ、管理画面など、守りたいエンドポイントごとにScope-downして設計するのが安全です。

また、AWS WAFのレート制限は、厳密な秒間リクエスト制御ではありません。

可用性保護、攻撃緩和、スクレイピング対策、Bot対策などには有効ですが、課金や契約プランに関わる正確な利用回数制御には、API Gatewayやアプリケーション側の実装を併用する必要があります。

導入時は、まずCountで検証し、WAFログを確認しながら、しきい値、集計キー、Scope-down statement、アクションを段階的に調整することが重要です。

以上、AWS WAFのレート制限についてでした。

最後までお読みいただき、ありがとうございました。