>
>
公開日
最終更新日
AWS WAFはWebアプリケーションの脆弱性を狙うL7攻撃を検知・遮断するセキュリティサービスです。
社内向け・顧客向けを問わず、Webサイト、API、会員機能を公開していると、SQLインジェクション、クロスサイトスクリプティング、不正ログイン、スクレイピングなどへの対応が必要になります。一方で、WAFを有効化しただけでは安全な運用にはなりません。誤検知の確認、ルールの調整、ログ分析、従量課金の監視まで含めて設計する必要があります。
この記事では、AWS WAFの基本構成と対応リソースを確認したうえで、料金の具体例、AWS WAF運用でつまずきやすい点、運用体制別の選定基準を解説します。導入可否だけでなく、導入後に継続して管理できるかを判断する材料として活用してください。
AWS WAFとは
AWS WAFとは、WebアプリケーションへのHTTP・HTTPSリクエストを検査し、定義した条件に基づいて許可、監視、ブロックするマネージド型WAFです。
本記事のポイント
AWS WAFはL7層のWeb攻撃対策であり、ネットワーク層の防御だけでは補えない通信内容を検査します。
基本料金はWeb ACL、ルール数、検査リクエスト数で決まり、Bot Controlなどの追加機能では費用が増えます。
本番遮断の前にCountモードで正常通信への影響を確認すると、誤検知による障害を減らせます。
ログ解析と24時間対応を社内で継続できない場合は、AWS WAFの運用支援サービスやSaaS型WAFを比較します。
WAFはWeb Application Firewallの略称で、アプリケーション層、つまりL7層の通信を対象にします。IPAが公開する「安全なウェブサイトの作り方」ipa.go.jpの第1章は、SQLインジェクション、OSコマンド・インジェクション、クロスサイト・スクリプティングなど11種類の脆弱性を取り上げています。WAFはアプリケーション改修だけでは防ぎ切れない攻撃を、リクエストの入口で制御する仕組みです。
対応リソースと配置
AWS WAFはAmazon CloudFront、Application Load Balancer、Amazon API Gateway、AWS AppSyncなど、AWS上で公開する主要なWebリソースと関連付けて利用します。Web ACLを作成し、保護対象のリソースへ関連付けることで、そのリソースに届くリクエストをルール順に評価します。複数のWebサービスを保護する場合は、サービスごとに求める許可条件や例外条件が異なるため、Web ACLを共用する範囲を先に決めます。
AWS Shieldとの役割分担
AWS WAFはアプリケーション層の不正リクエスト対策を担い、すべてのDDoS攻撃を単独で防ぐサービスではありません。ネットワーク層やトランスポート層のDDoS対策はAWS Shield、コンテンツ配信とオリジン負荷の分散はCloudFront、認証後の不正利用対策はアプリケーション側で担当します。大量アクセスを受けるサービスでは、レートベースルールだけに依存せず、これらを分けて設計します。
総務省は、令和7年版情報通信白書soumu.go.jpにおいて、2024年の日本のパブリッククラウドサービス市場が前年比26.1％増の4兆1,423億円に達したと紹介しています。クラウド上で公開する業務システムが増えるほど、インフラ設定とWebアプリケーション防御を別々に管理せず、公開経路ごとに保護状況を棚卸しする必要があります。
▶ 関連記事: SQLインジェクション（SQL injection）の仕組みと対策｜2025年最新の国内被害事例も解説
▲ AWS WAFがWebリクエストを検査し、正常通信と攻撃通信を判定・処理する配置構成
AWS WAFの主な機能と保護対象
AWS WAFでは、Web ACLにルールを組み合わせ、脆弱性を悪用する通信、不正なボット、過剰なリクエストを条件別に制御します。
カスタムルールとレートベースルール
カスタムルールでは、送信元IPアドレス、国や地域、URI、HTTPヘッダー、クエリ文字列、リクエスト本文などを条件にできます。たとえば管理画面へのアクセスを社内VPNのIPアドレスに限定したり、公開不要なパスへのアクセスを遮断したりできます。レートベースルールは、一定期間に同一の識別子から届くリクエスト数を基準として制限する機能です。ログイン試行の連打や単純なスクレイピングへの対策に使えますが、分散元IPを使う攻撃や正規利用者を装うアクセスには別の条件も必要です。
マネージドルールとボット対策
AWS Managed Rulesは、既知の脆弱性パターンや一般的な不正リクエストに対応するためのルール群です。すべてを独自ルールで作るより初期設定を短縮できますが、業務固有のURL、パラメーター、ファイルアップロードの仕様まで理解してくれるものではありません。適用後に正常なAPI通信が遮断される可能性を前提に、段階的に評価します。
Bot Controlは、検索エンジンなどの正当なボットと、悪質な自動アクセスを分類して制御するための追加機能です。CloudFrontのアクセスログを有効にしただけで不正ボットを自動遮断するわけではありません。Bot Control、カスタムルール、ログ分析、遮断条件の見直しを組み合わせて初めて運用になります。
IPセットと外部脅威情報
IPセットを使うと、許可または拒否したいIPアドレスやCIDRをルールから参照できます。外部の脅威情報を反映したい場合は、外部フィードを取得してIPセットを更新する自動処理を別途構成します。AWS WAFが外部リストを直接取り込み続ける機能として扱うと、更新停止やライセンス違反、正規利用者の誤遮断を見落とします。フィードの提供条件と更新失敗時の扱いを確認できる場合だけ、自動連携の対象にします。
AWS WAFの主なメリットと導入効果
AWS WAFの利点は、AWSの公開リソースと統合しながら、ルール、ログ、設定変更を同じ運用基盤で扱える点です。
クラウド統合によるデプロイ
専用アプライアンスの調達や設置をせず、CloudFront、ALB、API GatewayなどにWeb ACLを関連付けて保護を開始できます。新しい公開サービスを追加する際も、既存のルール設計を基に適用範囲を検討できます。ただし、関連付け忘れは保護漏れになります。サービス公開の承認フローに「Web ACLの関連付け」と「WAFログの出力先」を含めると、構成漏れを発見しやすくなります。
ルール設計の柔軟性
IP制限、地域制限、URI制御、マネージドルール、レート制限を組み合わせることで、サービスの利用形態に合わせた防御を作れます。管理画面、会員ログイン、公開API、コンテンツ配信では、必要な保護が同じではありません。全サービスに同じ遮断ルールを一律適用するより、保護対象ごとに守る業務と許容できるアクセスを文書化してからルールを設計するほうが、例外設定の増加を抑えられます。
ログの可視化とIaC管理
AWS WAFのログはCloudWatch Logs、Amazon S3、Amazon Kinesis Data Firehoseへ出力でき、AthenaやSIEMで分析できます。JSON形式のログには、どのルールに一致したか、許可・遮断・Countのどの処理になったかなどが記録されます。CloudFormationやTerraformなどのInfrastructure as CodeでWeb ACLを管理すれば、コンソール上の手作業変更を減らし、変更履歴をレビュー可能な状態にできます。
矢野経済研究所は、国内サイバーセキュリティ市場が2026年度に前年度比9.0％増の2兆1,220億円になると予測しています。防御機能を増やすだけでなく、設定変更を記録し、検知結果を改善へ戻せる運用基盤まで整備することが費用対効果を左右します。
AWS WAFの料金体系と月額試算
AWS WAFの料金は、Web ACL、ルール、検査リクエストを基本として計算し、Bot Controlなどの追加機能とログ保存費用を別に見積もります。
公開料金の基本単価では、Web ACLは1つ当たり月額5.00ドル、ルールは1つ当たり月額1.00ドル、検査リクエストは100万件当たり0.60ドルです。Web ACLやルールを作成して保護対象に関連付けている場合、リクエストが少なくても月額要素は発生します。「使わない限り費用はかからない」と考えると、検証環境の放置コストを見落とします。
試算例 | 前提 | 基本料金の計算 | 月額の基本料金 |
|---|---|---|---|
限定公開サービス | Web ACL 1個、ルール5個、月間500万リクエスト | 5ドル＋5ドル＋3ドル | 13ドル |
高トラフィックサービス | Web ACL 1個、ルール10個、月間1億リクエスト | 5ドル＋10ドル＋60ドル | 75ドル |
ボット対策を追加する場合 | 上記にBot Controlを追加 | 基本料金にBot Controlの月額料金と対象リクエスト料金を加算 | 利用条件により変動 |
表はWeb ACL、通常ルール、リクエスト処理だけを用いたドル建ての単純試算です。為替、税、マネージドルール、ログ保管、データ分析基盤の費用は含めていません。予算申請では、この基本料金と周辺サービスの費用を分けて記載すると、アクセス増加時にどこが増額したかを追跡できます。
Bot Controlと追加費用
Bot ControlはWeb ACLごとに月額10.00ドルの追加料金が発生します。悪質性の高いターゲット型ボット対策（Targeted Bot Control）を有効にする場合は、無料枠の100万リクエストを超えた分に対して100万リクエスト当たり10.00ドルが加算されます（Common Bot Controlは無料枠1,000万リクエスト・超過分100万リクエスト当たり1.00ドルで、単価はAWS WAF公式料金ページの記載値です。リージョン、利用レベル、料金改定により条件が変わるため、AWSマネジメントコンソールの料金ページで適用前に対象条件を確認します）。たとえば月間1億リクエストをすべて対象として試算すると、超過99百万リクエスト分だけで990ドルの追加要素になります。ボット対策を有効にする前に、対象パスをログから絞り込めるなら、全面適用より費用と誤遮断の両方を抑えられます。
WCUと料金確認の対象
WCUはルールが消費する処理容量の単位です。Web ACLでは1,500 WCUまで追加料金なしで利用でき、1つのWeb ACLの上限は5,000 WCUです。複数のマネージドルールや複雑な条件を追加して1,500 WCUを超える設計になる場合は、追加費用と上限の両方が判断に影響します。料金条件は変更されるため、導入時には対象リージョンと利用予定のマネージドルールを含め、AWSマネジメントコンソールまたはAWS公式料金ページで最新の単価を確認します。単価が変わっている場合は試算結果も変わります。単価が変更されている場合、試算結果も変わります。
AWS WAF運用における誤検知対策とログ分析
AWS WAF運用では、遮断ルールをいきなり本番適用せず、Countモードで影響を測定してからブロックへ切り替えます。
Countモードでは、条件に一致した通信を遮断せずにログへ記録します。ラベルの付与はルール側の設定やマネージドルールグループの仕様に依存しており、Countアクションを指定するだけで常に自動付与されるわけではありません。適用するルールグループのラベル仕様はAWSドキュメントの各マネージドルールグループのリファレンスページで確認できます。これにより、新しいマネージドルールや独自ルールが、実際には正規ユーザーの操作、バッチ連携、API通信に一致していないかを確認できます。正常通信を止める誤検知は、セキュリティ機能の問題ではなく、業務要件とルール条件のずれとして扱います。
本番適用までの運用フロー
保護対象、公開URL、管理画面、外部連携元IP、障害時の連絡先を一覧化します。
Web ACLとログ出力先を準備し、マネージドルールと候補ルールをCountモードで適用します。
WAFログをAthenaまたはSIEMで分析し、URI、送信元、ルールID、誤検知の業務影響を確認します。
業務上必要な通信は、対象URIや条件を限定した例外ルールへ分離します。
遮断へ切り替えた後も、ブロック件数、上位URI、急増した送信元、料金を定期監視します。
誤検知を防ぐ判断チェックリスト
遮断候補のリクエストが、画面操作や外部連携の正規通信ではないとログで判定できていますか。
例外は送信元IPだけで広く許可せず、URI、HTTPメソッド、認証状況などで限定できていますか。
ログの保存期間、閲覧権限、障害時に確認する担当者を決めていますか。
レート制限のしきい値は、平常時と繁忙時のアクセス件数を基に設定していますか。
ルール更新前後の設定差分をIaCまたは変更記録で追跡できますか。
実際の設定作業では、Web ACLのルール優先順位（数値が小さいほど先に評価される）、AWS Managed Rulesの代表的なルールグループ（AWSManagedRulesCommonRuleSet、AWSManagedRulesSQLiRuleSet等）、レートベースルールのしきい値を決める際の基準としてCloudFrontアクセスログから算出した平常時・繁忙時のリクエスト数を事前に把握しておくと、運用開始後の調整コストを減らせます。よくある失敗は、Countモードを省略して広範囲のマネージドルールを即時ブロックにすることです。決済、ログイン、ファイル送信など停止時の影響が大きいパスは、まずCountの検知結果を業務部門と照合します。監査ログを取得できるなら限定検証に進み、ログを確認する担当と手段を用意できないなら、先に運用監視の体制を整えます。
▲ 誤検知による正常通信の遮断を防ぐAWS WAFの段階的導入フェーズ
AWS WAF導入・自社運用における課題と注意点
AWS WAFは導入しやすい一方で、ルールの有効性、誤検知、ログ分析、緊急時の判断を継続的に担える体制がなければ防御品質が下がります。
誤検知とチューニング負担
マネージドルールを適用しても、独自パラメーターやAPI仕様に合わせた例外調整は残ります。例外をWeb ACLの先頭で広く許可すると、攻撃通信まで通す穴になります。例外は対象URI、HTTPメソッド、必要な条件に絞り、例外ルールにも期限と見直し担当を設定します。ルールを追加するほど安全になるわけではなく、意図と検知根拠を説明できないルールは削減対象です。
ログ解析と緊急対応の専門性
WAFログはJSON形式で出力されるため、遮断理由を調べるにはログ項目、HTTP通信、アプリケーション仕様を横断して読む力が必要です。深夜や休日にログイン障害が起きた場合、誰がルールを戻し、誰が業務部門へ連絡するかを決めていないと、遮断解除の判断が遅れます。AWSサポートプラン（Developer・Business・Enterprise等）の対応言語や対応時間はプランごとに異なります。日本語での個別緊急対応（ルールの差し戻しや業務部門への連絡代行など）については、AWSサポートページでプランごとの対応範囲を確認し、カバーされない範囲はパートナー企業のMSPや外部運用支援サービスの契約範囲と分けて整理します。
従量課金と大量アクセス
攻撃やボットによって検査リクエストが増えると、AWS WAFのリクエスト料金や追加機能の利用料金も増えます。レートベースルールは有効な対策の一つですが、DDoS対策全体を代替しません。急激なアクセス増加を検知する費用アラート、WAFのブロック数監視、CloudFrontやShieldを含む多層防御を組み合わせます。WCUが1,500を超える設計では容量と料金条件を確認します。単一リソースに複数のWeb ACLを重ねて適用することはできないため、WCUを削減する方法はルール数・複雑さを整理するか、保護対象を別リソースに分けてそれぞれに独立したWeb ACLを関連付ける設計変更が選択肢になります。
AWS WAFの運用アプローチ比較
AWS WAFの選定では、機能差よりも、誤検知を調査してルールを更新する責任を誰が持つかで運用方式を決めます。
運用アプローチ | ルール設計・変更 | ログ分析 | 費用の考え方 | 判断に向く条件 |
|---|---|---|---|---|
AWS WAFの完全自社運用 | 社内で設計、検証、変更します。 | 社内の情シスまたはセキュリティ担当が担います。 | AWS利用料と社内運用コストを管理します。 | AWS、Web、ログ分析の担当者と障害対応手順を社内で確保できる場合です。 |
AWS WAFの自動運用サービス | 自動適用や運用支援の範囲を契約条件で決めます。 | 事業者と社内で役割を分担します。 | AWS利用料に加えてサービス利用料が発生し、料金は要問合せです。 | AWSの構成を維持しながら、ルール運用の負荷を減らしたい場合です。 |
SaaS型クラウドWAF | 提供事業者の管理画面やポリシーで設定します。 | 提供機能と運用契約により異なります。 | 月額・年額・通信量課金などの条件はサービスごとに異なり、料金は要問合せです。 | AWS以外を含む公開環境を一元管理したい場合です。 |
国内企業の導入事例
ecbeingは、PCI DSS v4.0におけるWebアプリケーション保護の要件への対応を背景にAWS WAFを採用した事例を公開しています出典：aws.amazon.com。カード情報を扱うEC基盤においては、監査要件、ログ証跡、変更管理への対応が伴うケースが多く、WAFの導入範囲と合わせて検討される傾向があります。
サイバーセキュリティクラウドは、マイナビがAWS WAF自動運用サービスのWafCharmを導入した事例を公開しています出典：cscloud.co.jp（2020年7月30日）。自社運用か支援サービスかを検討する際の比較軸としては、ルールの自動適用可否のほか、誤検知時の連絡経路、例外設定の承認者、障害対応時間といった項目が挙げられます。
公開経路の設計を整理することで、セキュリティ対策とクラウドコストの管理を一体的に進めやすくなる場合があります。WAFの導入検討と合わせて、CloudFrontやALBなどの公開リソース構成を棚卸しすると、保護対象の関連付け漏れと不要なコストを同時に発見できます。
AWS WAF導入判断の基準
AWS上の公開リソースを保護し、ログ確認とルール変更を継続できるならAWS WAFを導入候補にし、運用体制が不足するなら支援サービスを含めて比較します。
まず、インターネットから到達できるCloudFront、ALB、API Gateway、AppSyncと、それぞれが扱う業務データを一覧化します。IPAは令和7年度に複数業界・規模の中小企業126社を対象として、IT資産を把握し攻撃ポイントを特定するASM診断を実施しました。WAFの導入判断でも、先に公開資産を把握しなければ、保護対象の関連付け漏れを発見できません。
導入前の判断項目
保護対象の公開リソースとURLを特定し、Web ACLを関連付ける対象を決めます。
SQLインジェクション、XSS、不正ログイン、スクレイピングなど、業務上優先する脅威を定めます。
平常時と繁忙時のリクエスト数から、基本料金と追加機能の費用を試算します。
Countモードのログを誰が確認し、遮断への切替を誰が承認するかを決めます。
夜間・休日の障害時に、ルール変更と業務連絡を実行できる体制があるかを確認します。
上記で、保護対象、ログ確認者、緊急時の変更権限を社内で定められるなら、限定したWeb ACLから検証を開始します。いずれかを定められず、公開サービスの停止影響が大きいなら、運用支援の対応範囲を比較してから導入範囲を決めます。料金だけで方式を決めると、誤検知対応の人件費や障害時の判断遅延が見積もりから漏れます。
▲ 自社の体制と要件に合わせた最適なWAF運用アプローチの選定フロー
まとめ
AWS WAFは、CloudFront、ALB、API Gatewayなどの前段でL7層のリクエストを検査し、Web攻撃、不正ボット、過剰アクセスへの防御を補うサービスです。基本料金はWeb ACL、ルール、リクエスト数で決まり、Bot Controlやログ保管の費用も別途検討します。
導入効果を得るには、ルールを追加することよりも、Countモードでの検証、ログ分析、例外の限定、障害時の判断体制を整えることが先です。明日から着手するなら、まず公開中のAWSリソースとWeb ACLの関連付け状況を一覧化し、保護されていない公開経路がないかを確認します。その結果を基に、完全自社運用、運用支援サービス、SaaS型WAFのどれが体制に合うかを比較します。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
