Techfirm Cloud Architect Blog

テックファーム株式会社クラウドインフラグループのブログ

AWS WAFでボットからのリクエストを制限するときのTips

AWS AWS WAF

AWSで稼働しているWebサイトへのボットからのリクエストが急増し、サイトパフォーマンスに影響が生じていたため、AWS WAFにBot Controlマネージドルールグループを導入しました。
導入にあたり、いくつか検討・調査した点がありましたので、Tipsとしてまとめます。
なおAWS WAFの導入方法やBot Controlマネージドルールグループの詳細な仕様解説は省きますので、公式ドキュメントをご確認ください。

AIトラフィック分析

AWS WAFの新しいUIに「AIトラフィック分析」機能が提供されています。
Bot Controlマネージドルールグループを導入していなくても、サイトにどのようなボットからリクエストが来ているかを分析できます。
Bot ControlマネージドルールグループはWebACLにルール登録し、リクエストを検査した時点から従量課金が発生しますが、AIトラフィック分析は追加の設定作業や費用なしで利用できます。
事前にボットのリクエスト状況を把握、分析し、どのようにBot Controlマネージドルールグループを適用するかを計画するのに役立ちます。

コスト最適化

Bot Controlマネージドルールグループの利用にはAWS WAFの通常利用料金に追加でルール費用とリクエスト費用が発生します。
このうち、とくにリクエスト費用については、通常のリクエスト料金よりも高くなっており、すべてのリクエストを検査した場合、費用が倍以上になってしまう恐れがあります。
詳しい料金はAWS WAFの料金でご確認ください。

コスト最適化のために以下の事項を考えていきます。

  • 保護レベルの選択
  • プライオリティの設計
  • スコープダウンの設計

保護レベルの選択

Bot Controlには2つの保護レベルがあります。一般的な保護レベル（Common）とターゲットを絞った保護レベル（Targeted）の2種類です。
料金面ではリクエスト料金がTargetedのほうが10倍となっているため、まずはCommonレベルの導入でボットリクエストを制限できないかを検討することをオススメします。

プライオリティの設計

Bot Controlマネージドルールグループより優先度の高いルールによってBlockすることで、余計なリクエスト検査を発生させないようにします。

スコープダウンの設計

検査対象のリクエストの条件を絞り込むことができます。
画像やCSSなどの、画面を構成するための静的ファイルを除外するのが、検査リクエスト数の削減にもっとも効果的です。
また、ボットが頻繁にリクエストしているページや、ボット保護したい機能のURLパスに限定することで、コストを最適化できます。

これらの内容は公式ドキュメントの「BotControlのユースケースの選択と設定」で解説されているので、一読しておくことをオススメします。

ルールバージョンの選択

執筆時点（2026/06/23）ではルールのデフォルトはバージョン1が選択されています。最新はバージョン6が提供されており、登録されているルールが増えていることに加え、検出可能なボットの種類が格段に増えています。
WebACLのルール詳細画面で確認できる、Bot Controlマネージドルールグループがボット判定したときに付与するラベル一覧数を比べてみると、バージョン1が247個に対して、バージョン6は909個となっています。

より多くのボットを判別するためには最新バージョンを選択することをオススメします。

ダッシュボード

ルールの導入後の効果を分析するには、まずはAWS WAFの管理画面で提供されているダッシュボードを利用することをオススメします。
適用しているルールで検知されているリクエストや、ラベル付けされたリクエストを視覚的にグラフで確認できます。

標準で基本的な観点のグラフUIが提供されており、特定のアクションや、特定のルールに限定してグラフ表示を簡単なUI操作で行えます。リクエストの傾向や、効果の出ているルールなどの全体像をつかむのに最適です。
「CloudWatchで表示」のリンクがついているグラフはCloudWatchメトリクスの画面でもグラフ化できるものになっており、時間の詳細な変更や、別メトリクスを追加しての分析、カスタムダッシュボードへの追加などに利用できます。

ラベルを条件にしたWAFログのクエリ

ダッシュボードのメトリクスでは全体像の把握はできますが、リクエストごとに条件付けした分析を行うにはWAFログの分析が必要です。
ログの記録先は、CloudWatchログ、S3、Amazon Data Firehoseの選択肢がありますが、ここでは、S3に保存している場合のAthenaでのログクエリTipsを紹介します。
なお、テーブル定義は公式ドキュメントで提示されているものに準拠します。

Bot Controlマネージドルールグループによって検査されたリクエストはさまざまなラベルがつけられています。
全容はAWSManagedRulesBotControlRuleSetのドキュメントでご確認いただきたいのですが、これらのラベルをクエリ条件にしてボット判定されたリクエストの中身を分析します。

WAFのラベルは、プレフィックスと名前空間（Namespace）、名前で構成されています。
awswaf:managed:aws:bot-control:bot:name:googlebotというラベルを例であげます。
awswaf:managed:aws:bot-control:はBot Controlルールが付与したことを示すプレフィックスです。
bot:name:が名前空間で、ラベルの種類やカテゴリを分類するための文字列です。:で区切られて階層化されています。この場合は、Bot Controlが判定した、ボットの名前を分類する名前空間です。
googlebotがこのラベルの名前にあたります。

クエリ条件のなかでラベル名を扱う場合は以下のような記述になります。

WHERE log_time = '2026/07/01/01/00/00'  -- ログパーティション指定
  AND ANY_MATCH(labels, l ->
    l.name = 'awswaf:managed:aws:bot-control:bot:organization:openai'  -- OpenAI社のボット
  )

名前空間の有無を条件にする場合は、次のように記述します。

WHERE log_time = '2026/07/01/01/00/00'  -- ログパーティション指定
  AND NOT ANY_MATCH(labels, l ->         -- bot判定もシグナル判定もされなかったリクエスト
    l.name LIKE '%:bot-control:bot:%'
    OR l.name LIKE '%:bot-control:signal:%'
  )

まとめ

AWS WAFのBot Controlマネージドルールグループを導入する際のTipsを紹介しました。
Bot Controlは強力なボット対策機能ですが、リクエスト費用が通常より高いため、コスト最適化の設計が重要です。保護レベルの選択・プライオリティ設計・スコープダウンの3点を意識することで、費用を抑えながら効果的なボット対策が実現できます。
また、デフォルトのバージョン1より最新バージョンを選択することで、より多くのボットを検出できます。
導入前にはAIトラフィック分析で事前調査を行い、導入後はダッシュボードやAthenaでのログ分析を活用して効果を継続的に確認することをオススメします。