AWS WAF Bot Control 入門ガイド: 基本的なボットから高度な脅威までを防ぐ活用術

1. はじめに

Webアプリケーションを運用していると、ある日突然サーバー負荷が急上昇することがあります。調査してみると、人間のユーザーではなく、自動化されたボットによる大量アクセスが原因だった、というケースは珍しくありません。

ボットは大きく分けて次の2種類です。

善良なボット

GoogleやBingの検索エンジンのクローラー、FacebookやX（旧 Twitter）のSNSクローラーなど、サービス運営上むしろ必要なボット

悪意のあるボット

不正ログインの試行、スクレイピング、価格情報の盗用、サーバーリソース枯渇を狙ったツールなど

こうしたボットアクセスは、次のような影響をもたらします。

パフォーマンス問題

RDS（データベース）のCPU使用率が100%に張り付き、レスポンスが極端に悪化する

情報セキュリティリスク

総当たり攻撃や脆弱性スキャンによる不正アクセスや情報漏えいのリスクが増大する

コスト増大

急場しのぎのスケールアップやスケールアウトで、RDSやEC2の月額費用が膨らむ

AWS WAF Bot Controlは、こうしたボットアクセスを検知・制御を目的とした、AWS WAFが提供するマネージドルールグループです。AWS WAFのWeb ACLに AWSManagedRulesBotControlRuleSet を追加することで、CloudFront、Application Load Balancer、API Gateway、AppSyncの前段でボットトラフィックを管理できます。

本記事では、Bot Control の基本的な仕組みから、実践的な導入ステップ、料金・ROI、運用時のベストプラクティスまでを一通り解説します。

AWS WAF の導入や運用のお悩みにセキュリティエンジニアがおこたえします！

2. AWS WAF Bot Controlの技術的特徴と検知メカニズム

AWS WAF Bot Controlは、次のような機能を持つマネージドルールグループです。

• 代表的なボット（検索エンジン、SNS、HTTPライブラリ、AIボットなど）をカテゴリ別に自動識別
• 検知結果を ラベル としてリクエストに付与
• ラベルを条件にしたカスタムルールでAllow/Block/Count/CAPTCHA/Challengeを選択可能
• ラベルごとのCloudWatchメトリクスやWAFログで詳細な分析が可能

Bot Controlには後述するCommon（共通）とTargeted（ターゲット）の2つの検査レベルがあり、必要に応じて使い分けることで、コストと防御力のバランスを取れます。

2-1. Bot Controlが付与するラベルの仕組みと活用方法

Bot Controlの大きな特徴は、検出したボットに対して詳細なラベルを付与することです。ラベルは awswaf:managed:aws:bot-control: をプレフィックスに持ち、CloudWatchメトリクスやWAFログにも出力されます。

代表的なラベルは次の3系統です。

1. ボット名ラベル

形式

awswaf:managed:aws:bot-control:bot:name:<bot_name>

例:

awswaf:managed:aws:bot-control:bot:name:googlebot awswaf:managed:aws:bot-control:bot:name:facebookexternalhit

用途

特定のボットだけ個別に許可・ブロックしたいときに利用

2. カテゴリラベル

形式

awswaf:managed:aws:bot-control:bot:category:<category>

例:

awswaf:managed:aws:bot-control:bot:category:search_engine awswaf:managed:aws:bot-control:bot:category:social_media awswaf:managed:aws:bot-control:bot:category:http_library awswaf:managed:aws:bot-control:bot:category:ai

用途

検索エンジン系は許可、HTTPライブラリ由来は制限など、カテゴリ単位でまとめて制御

3. 検証ステータスラベル

形式

awswaf:managed:aws:bot-control:bot:verified

意味

IPの逆引きDNSなどによってAWSが正規のボットと検証できた場合に付与されるラベル

Bot Controlではさらに、ボットの提供元組織を表すbot:organizationや、クラウド事業者、ブラウザ自動化拡張（Seleniumなど）の有無を示すsignalラベルなども追加されています。

ラベルを組み合わせることで、例えば次のような制御が可能です。

• 検索エンジンかつverifiedなボットは全面的に許可
• bot:category:social_mediaかつverifiedではないボットはブロック
• bot:name:facebookexternalhitだけ特定パスでブロック

また、スコープダウンステートメントを併用すれば、特定のURIパス、特定ヘッダーを持つリクエストのみをBot Controlの対象にすることもできます。

2-2. CommonレベルとTargetedレベルの技術的な違い

Bot ControlのマネージドルールグループAWSManagedRulesBotControlRuleSetにはCommon（共通）とTargeted（ターゲット）の2つの検査レベルがあります。いずれもWCU (Web ACL Capacity Unit) の消費量は50です。各レベルの違いは以下のようになります。

Common（共通）レベル

• User-Agent、HTTPヘッダー、TLSフィンガープリントなどの静的な情報にもとづくボット検知
• 検索エンジン、SNSクローラー、HTTPライブラリ、各種クローラーなどをカテゴリ別に識別
• Self-identifyする一般的なボットを中心に検出し、ラベル付けと一部のブロックを実施
• Bot Controlの中ではコストが低く、検査は比較的軽量

Targeted（ターゲット）レベル

• Commonの全ルールに加えて、self-identifyしない高度なボット向けの検知を追加
• ブラウザの挙動検査、フィンガープリント、行動ヒューリスティクス、トークン再利用検知などを実施
• AWS WAFのトークン（aws-waf-token）を利用し、同一トークンが短時間に多数の IPやASN、国から使い回されていないかを検査
• 機械学習（ML）を用いた協調的なボット活動の検知（TGT_ML_* ルール）
• 必要に応じて、ChallengeやCAPTCHAを自動的に適用

Targetedレベルでは、AWS WAFのJavaScript/モバイルSDKやChallenge/CAPTCHAを通じてトークンを取得し、そのトークンをもとにブラウザの整合性や自動化の有無を判断します。これにより、単純なHTTPクライアントだけでなく、ブラウザエミュレーションを行う高度なボットも検知できます。

料金については後述しますが、Targetedはリクエスト課金がCommonより約10倍高額となるため、まずCommonで全体を可視化し、ログインページや高負荷APIなど一部のエンドポイントにだけTargetedを深堀りして適用する構成が現実的です。

2-3. Bot Controlで検知できるボットカテゴリの詳細

Bot Control はボットを用途ごとのカテゴリに分類します。以下、代表的なカテゴリを紹介します。

各リクエストにはさらにverified/unverifiedの区別も付きます。

verifiedボット

IPの逆引きDNSなどにより本物のGooglebotなどと検証されたもの

unverifiedボット

User-Agentなどからボットと推定されるものの、発信元IPが正規であると確認できないもの

verifiedを優先的に許可しつつ、unverifiedのみ制御することで、SEOやSNSプレビューへの影響を抑えつつ防御を強化できます。

AWS WAF の導入や運用のお悩みにセキュリティエンジニアがおこたえします！

3. 実戦的なBot Control導入アプローチ

3-1. STEP1: Performance InsightsとCloudWatchによる現状分析

導入前に、現在どの程度ボットから影響を受けているのかを定量的に把握します。

RDS Performance Insightsでの分析

RDSのPerformance Insightsを使うと、データベースレベルのボトルネックを可視化できます。特に次の指標を確認します。

平均アクティブセッション (Average Active Sessions; AAS)

同時実行セッション数の平均値

トップ SQL

負荷の高い SQL クエリ

Wait イベント

ロック待ちや I/O 待ちなどの待機理由

ボットによる負荷が疑われる場合、特定時間帯だけAASが急上昇し、同じクエリが大量に実行されているケースが多く見られます。

CloudWatch メトリクスの活用

ALB、EC2インスタンス、CloudFrontディストリビューションなどを対象に、アプリケーションの振る舞いをCloudWatchで確認します。一例を以下に示します。

• (ALB) RequestCount：単位時間あたりのリクエスト数
• (ALB) TargetResponseTime：レスポンスタイム
• (EC2) CPUUtilization：CPU 使用率
• (CloudFront) CacheHitRate：キャッシュヒット率

RequestCountのスパイクや CacheHitRateの低下、CPU使用率の上昇などを合わせて見ることで、どのレイヤーでボットの影響が出ているかを推定できます。

3-2. STEP2: カウントモードでの安全な導入と影響評価

本番環境にBot Controlを適用する場合は、最初からBlockとせず、まずCountモードで挙動を確認します。

Override rule group actionの設定手順

1. AWS WAFコンソールで対象のWeb ACLを選択
2. Rulesタブでルールを追加→AWS マネージドルールグループを選択
3. Bot Controlを選択

   

4. ルールオーバーライドですべてのルールアクションをオーバーライドで Count を選択してルールを追加

   

この設定により、Bot Controlはボットを検知してもブロックせず、ラベル付けとログ出力のみを行います。

検証期間中の確認ポイント

1〜2 週間程度の検証期間を設け、次を確認します。

• ボット検知率：全リクエストのうちボットと判定されたものの割合
• カテゴリ別内訳：search_engine、social_media、http_library、aiなど、どのカテゴリが多いか
• 誤検知の有無：正規ユーザーや監視ツールなどが過剰にマッチしていないか

WAFコンソールのSampled requests画面で、User-AgentやIP、ラベルを確認し、誤検知を洗い出します。

3-3. STEP3: ラベルベースの精密なブロック戦略

Count モードで傾向を把握したら、ラベルを使った段階的なブロックに移行します。

特定ボットのブロック例：facebookexternalhit

例として、Facebookのクローラーfacebookexternalhitが特定の動的APIを大量に叩き、DB負荷の原因になっているケースを考えます。

まずCloudFront標準ログをAthenaで分析します。

/* CloudFront標準ログのクエリ例 */

SELECT
   COUNT(1) AS request_count,
   cs_uri_stem,
   cs_user_agent,
   SUM(time_taken) AS total_time
FROM 
   cloudfront_standard_logs
WHERE 
   cs_user_agent LIKE '%facebookexternalhit%'
   AND date = '2025/11/14'
GROUP BY 
   cs_uri_stem, 
   cs_user_agent
ORDER BY 
   request_count DESC
LIMIT 20;

例えば/api/heavy-endpointだけ極端にアクセスが多いと判明した場合、そのパスに対するfacebookexternalhitのアクセスだけをブロックするカスタムルールを作成します。

# CloudFormation テンプレート抜粋（イメージ）BlockFacebookCrawlerRule:
 Type: AWS::WAFv2::RuleGroup
 Properties:
   Capacity: 10
   Scope: CLOUDFRONT
   Rules:
     - Name: BlockFacebookOnSpecificPath
       Priority: 100
       Action:
         Block: {}
       Statement:
         AndStatement:
           Statements:
             - ByteMatchStatement:
                 SearchString: '/api/heavy-endpoint'
                 FieldToMatch:
                   UriPath: {}
                 TextTransformations:
                   - Priority: 0
                     Type: NONE
                 PositionalConstraint: STARTS_WITH
             - LabelMatchStatement:
                 Scope: LABEL
                 Key: awswaf:managed:aws:bot-control:bot:name:facebookexternalhit

このようにパスとボット名の組み合わせで条件を絞ることで、SNS共有に必要なクローラーは残しつつ、DBに負荷をかける特定エンドポイントだけをピンポイントに抑制できます。

AWS WAF の導入や運用のお悩みにセキュリティエンジニアがおこたえします！

4. 料金最適化とROI向上のための実践テクニック

4-1. コスト構造の整理とシミュレーション

まず Bot Controlを含めたAWS WAFの料金構造を改めて整理します。

基本料金構造（WAF全体）

Bot Controlの料金

本表は2025年11月時点の料金に基づいています。最新の情報はAWS公式ドキュメントをご確認ください。

月額料金シミュレーション例（Bot Control部分のみ）

月間100,000,000リクエストのサイトで、一つのWeb ACLにBot Controlを有効化した場合について、Bot Control部分のみを試算します。

• Commonのみを適用する場合
  • サブスクリプション: 10 USD
  • リクエスト課金:
    • 総リクエスト 100（百万単位）
    • 無料枠 10（百万単位）
    • 課金対象 90 × 1 USD = 90 USD
  • 合計（Bot Control 部分）: 約 100 USD / 月
• Targetedのみを適用する場合
  • サブスクリプション: 10 USD
  • リクエスト課金:
    • 総リクエスト 100（百万単位）
    • 無料枠 1（百万単位）
    • 課金対象 99 × 10 USD = 990 USD
  • 合計（Bot Control 部分）: 約 1,000 USD / 月

これに加えて、Web ACL、ルール、WAF全体のリクエスト料金が追加されます。

4-2. 費用対効果を最大化する設定パターン

1. 高負荷エンドポイントへの選択的適用

Bot Control を全パスに適用すると、リクエスト課金が膨らみます。DBアクセスの多いAPIなど、影響の大きい一部パスだけをBot Controlの対象に絞ると、コストと効果のバランスが取りやすくなります。

以下はBot Control の検査対象を /api/ 以下のパスに限定するためのWeb ACLのルール例です。

{
 "Name": "BotControlForAPI",
 "Priority": 100,
 "Statement": {
   "AndStatement": {
     "Statements": [
       {
         "ByteMatchStatement": {
           "SearchString": "/api/",
           "FieldToMatch": { "UriPath": {} },
           "PositionalConstraint": "STARTS_WITH",
           "TextTransformations": [
             { "Priority": 0, "Type": "NONE" }
           ]
         }
       }
     ]
   }
 },
 "OverrideAction": { "None": {} },
 "VisibilityConfig": {
   "SampledRequestsEnabled": true,
   "CloudWatchMetricsEnabled": true,
   "MetricName": "BotControlForAPI"
 }
}

2. CommonとTargetedのハイブリッド構成

AWS公式ドキュメントでも紹介されていますが、AWSManagedRulesBotControlRuleSetを2つのステートメントに分け、CommonとTargetedを別々にスコープする方法があります。

Common

すべてのトラフィックに適用し、ボット可視化と基本的なブロックを担当

Targeted

ログインページや高負荷 API など一部エンドポイントだけに JSON エディタでスコープダウンして適用

3. RDSスペックダウンによるコスト削減効果

ボットトラフィックを抑制できると、RDSのスペックダウンでインフラコストを下げられる場合があります。

例：

• 変更前: db.r5.2xlarge（8 vCPU, 64 GiB） → 約 1,152 USD / 月
• 変更後: db.r5.xlarge（4 vCPU, 32 GiB） → 約 576 USD / 月
• 差額: 約 576 USD / 月の削減

本例では、Bot Controlに100USD程度かかっても、トータルで400USD以上の削減を見込むことが出来ます。Bot Controlを純粋なセキュリティコストではなく、インフラコスト削減のための投資と捉えると判断しやすくなります。

AWS WAF の導入や運用のお悩みにセキュリティエンジニアがおこたえします！

5. トラブルシューティングと運用ベストプラクティス

5-1. 誤検知への対処法

Bot Control運用で最も避けたいのは、正規アクセスの誤ブロックです。次の順番で対処します。

1. 善良なボットの確実な許可

検索エンジンや SNS クローラーなど、ビジネス上重要なボットは確実に許可しておきたいところです。verified ラベルとカテゴリを組み合わせた許可ルールを最初に評価させると安全です。

以下の設定例は、Bot Controlが付与したラベルを使って検証済みの検索エンジン／SNSクローラーを必ず許可するためのカスタムルールです。Priority: 1のようにBot Controlのブロック系ルールよりも高い優先度で評価されるようにしておくことで、search_engine や social_media カテゴリに属する verified なボット（Googlebot や Facebook クローラーなど）が誤ってブロックされるのを防ぎます。

AllowVerifiedBots:
 Priority: 1
 Action:
   Allow: {}
 Statement:
   AndStatement:
     Statements:
       - LabelMatchStatement:
           Scope: LABEL
           Key: awswaf:managed:aws:bot-control:bot:verified
       - OrStatement:
           Statements:
             - LabelMatchStatement:
                 Scope: LABEL
                 Key: awswaf:managed:aws:bot-control:bot:category:search_engine
             - LabelMatchStatement:
                 Scope: LABEL
                 Key: awswaf:managed:aws:bot-control:bot:category:social_media

2. カスタム例外ルールの作成

自社監視ツールや提携先の API アクセスなど、ボットに見えるが実際には正規のアクセスについては、IPセットやカスタムヘッダーで除外します。

3. CAPTCHAによる柔軟な対応

完全なBlockではなく、まずCAPTCHAを挟んで確認する選択肢もあります。

5-2. 継続的な改善サイクルの構築

Bot Control は、一度設定して終わりではなく、継続的にチューニングしていく前提のサービスとなっています。

定期レビューで押さえるポイント

週次・月次などの定期レビューを実施し、次の観点を確認します。

1. ボットカテゴリ別トレンド

• search_engine/social_media/http_library/aiなどのリクエスト数推移
• スパイクの有無、新しいボット名の出現

2. ブロック率とユーザー影響

• 全体トラフィックに対するBlock/CAPTCHA/Challengeの割合
• ユーザーからの問い合わせ内容に変化がないか

3. パフォーマンス指標

• RDS AAS、レスポンスタイム、CPU使用率の推移
• Bot Control導入前後でどの程度改善したか

CloudFormationによる設定管理

Bot Controlの設定は、コンソールで直接変更すると履歴管理が難しくなるため、CloudFormationやCDKでコード管理しておくと安全です。

5-3. 恒久対策と暫定対策の使い分け

Bot Controlは非常に強力ですが、あくまでもアプリケーション外での対応となります。長期的には、アプリケーション・DB 側の改善と組み合わせることが重要です。

アプリケーションレベルの最適化

• 重いSQLのチューニング、インデックス設計の見直し
• アプリケーションキャッシュやCloudFrontキャッシュの強化
• AP のレート制限（トークン単位・IP 単位など）の導入

インフラレベルの対策

• CloudFrontによる静的コンテンツ配信とキャッシュ強化
• Auto Scalingによるスパイク吸収
• Read ReplicaやAuroraのリードスケール機能の利用

6. まとめ

本記事ではAWS WAF Bot Controlを紹介し、その仕組みと具体的な活用方法を一通り整理しました。

Bot Controlの価値

• ラベルベースの柔軟な制御で、善良なボットと悪意のあるボットを切り分けて扱える
• CommonとTargeted の 2 段階で、コストと防御力のバランスを調整できる
• CloudFront、ALB、API Gateway、AppSync などの既存リソースとシームレスに統合できる

成功のポイント

1. 段階的な導入

まずCountモードで1〜2週間程度検証を行い、誤検知やトラフィックの傾向を把握してからBlockを有効化する

2. 継続的な監視とチューニング

WAF Analytics、CloudWatch、RDS Performance Insightsを用いた定期レビューでルールを見直す

3. 恒久対策との組み合わせ

Bot Controlによる即効性のある防御と、アプリケーション・DB最適化やキャッシュ戦略といった恒久対策を併用する

投資効果（ROI）

Bot Controlの月額費用は、RDSやEC2のスペックダウンで容易に回収できるケースが多く、セキュリティ向上とインフラコスト削減を同時に実現しやすいサービスです。

ボットアクセスによる負荷や情報セキュリティリスクは今後も増加が予想されます。まずは Countモードで現状を見える化し、その結果をもとに段階的にブロックやCAPTCHA、Targetedレベルを組み合わせるところから始めてみてください。

AWS WAF の導入や運用のお悩みにセキュリティエンジニアがおこたえします！

• Amazon Web Services（AWS）およびその他のAWS 商標は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。