LASSIC Media らしくメディア
AWS WAF/Shieldのコストを最適化する外注の進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- AWS WAF/Shieldの課金はWeb ACL・ルール・リクエスト評価・WCUの4軸で構成され、それぞれに削減アプローチが異なります
- scope-downステートメントでBot Controlなどの高コストルールを特定パスに限定すると、リクエスト評価コストを抑えられます
- ルール棚卸し・配置順序の最適化・CDN統合を組み合わせた最適化には専門知識が必要で、外注によるリスク低減が有効です
目次
AWS WAF/Shieldのコスト最適化とは
AWS WAF/Shieldのコスト最適化とは、Web ACL・ルール・リクエスト評価・WCU（Web ACL Capacity Units）の4つの課金軸を整理し、セキュリティ水準を維持しながら不要な費用を削減する取り組みを指します。*1
WAFのコスト増加は特定のルールに起因することが多く、適切なルール設計なしに拡張を続けると費用が積み上がります。本記事では、AWS公表の料金体系をもとに、セキュリティを落とさずにコストを削減する5つの手法と、外注活用の進め方を整理します。
WAF料金の仕組みと課金ポイントの整理
Web ACL・ルール料金の基礎
AWS WAFの課金はAWS公式料金ページ*1によると、主に4つの要素で構成されています。Web ACL（ウェブアクセスコントロールリスト）1つあたり月額$5.00の固定費用がかかります。さらにルール1つにつき月額$1.00が加算されます。
マネージドルールグループ（AWSが提供する事前設定済みルール集）も同様の課金体系です。Bot Controlなど高機能なマネージドルールグループは月額$10.00（Web ACLあたり）の追加費用が発生します。
複数のリソース（CloudFront・ALB・API Gatewayなど）に同じポリシーを適用する場合、Web ACLを共有できます。共有設計を取り入れると、Web ACL単位のコストを圧縮できます。
リクエスト評価料金とWCUが膨らむ原因
リクエスト評価料金は100万リクエストあたり$0.60です。*1トラフィックが増加するほど費用も増えます。ECサイトやAPIサービスでは月間数億リクエストを超えるケースもあり、評価リクエスト費用がコスト全体の大半を占めることがあります。
WCU（Web ACL Capacity Units）は、WAFが処理するルールの複雑さを示す単位です。*1Web ACL 1つにつき1,500 WCUが基本料金に含まれ、超過分は500 WCUごとに100万リクエストあたり$0.20が追加されます。
正規表現マッチルールや高機能なBot Controlは、他のルールと比べてWCUを多く消費します。適切な上限設計なく追加し続けると、1,500 WCUの上限を超えて追加課金が発生し続けます。
Shield AdvancedとWAFの関係
AWS Shield StandardはすべてのAWSユーザーに無料で提供されており、一般的なDDoS攻撃（ネットワーク層・トランスポート層）を自動的に緩和します。*2
AWS Shield Advancedは月額$3,000（1年契約）の有料サービスです。*2Shield Advancedを契約すると、保護対象リソースに対して月500億リクエスト分までWAFリクエスト評価料金が含まれます。大量トラフィックのサイトでShield Advancedを導入している場合、WAF単体での評価リクエスト費用は実質的にゼロになります。
Shield Advancedの月額$3,000は費用として大きく見えますが、月間数百億リクエストを処理するサービスではWAFのリクエスト評価料金のほうが高くなるケースがあります。コスト全体を比較したうえで導入判断することが重要です。
| 課金要素 | 料金（AWS公表値） | コスト増の原因 | 主な削減アプローチ |
|---|---|---|---|
| Web ACL | $5.00/月 | リソースごとに個別ACLを作成 | 複数リソースでACLを共有する設計 |
| ルール | $1.00/月/ルール | 審査なしで追加し続けた重複ルール | 棚卸しによる不要ルール削除・統合 |
| リクエスト評価 | $0.60/100万リクエスト | 全リクエストに高コストルールを適用 | scope-down/CDNキャッシュ活用 |
| WCU超過 | +$0.20/500WCU/100万リクエスト | 正規表現・Bot Controlの過剰利用 | 高WCUルールの適用範囲限定・見直し |
| Bot Control | $10.00/月（Web ACLあたり） | すべてのパスに一律適用 | scope-downで認証/決済パスのみに限定 |
scope-downステートメントで高コストルールを限定する
Bot Controlを/loginや/checkoutだけに適用する
scope-downステートメント（スコープダウンステートメント）とは、マネージドルールグループやレートベースルールが評価するリクエストの範囲を絞り込む機能です。*3スコープダウンステートメント自体への追加費用は発生しません。
Bot Controlはマネージドルールグループのなかでも高いWCUと月額費用を持ちます。不正ログイン対策を目的とする場合、全リクエストではなく/login・/checkout・/paymentなど認証・決済に関わるパスのみに適用すると、Bot Controlが処理するリクエスト量を大幅に絞れます。
scope-downステートメントで適用対象を限定すると、Bot Controlが評価するリクエスト数が減るため、リクエスト評価料金の削減につながります。スタティックコンテンツや画像のパスはBot Controlの対象外にするだけで、費用の見直し効果が期待できます。
正規表現マッチルールのパス限定
正規表現マッチルール（RegexMatchStatement）はWCUを多く消費するルールの代表例です。複雑な正規表現を使ったルールを広範なパスに適用すると、WCUの超過要因になります。
scope-downステートメントで正規表現マッチルールの適用対象を特定のパス（例：/api/や/admin/）に絞ると、全体のWCU使用量を抑えられます。これにより1,500 WCUの枠内に収められるケースが出てきます。
scope-downの設定はAWSマネジメントコンソールまたはCLI・Terraformで設定できます。設定変更は即時反映されますが、セキュリティ要件の見落としを防ぐためにステージング環境での事前確認が欠かせません。
ルール配置の順序最適化でリクエスト評価コストを削減
低コスト・高ブロック率ルールを先頭に置く
AWS WAFはルールを優先度順（Priority順）に評価します。リストの上位にあるルールが先に評価され、一致してACTIONが決まったリクエストは以降のルールを通過しません。
この仕組みを利用して、WCUが低く攻撃遮断率が高いルールを上位に配置すると、悪意あるリクエストが高コストなルールに到達する前にブロックされます。これがリクエスト評価全体のコスト削減につながります。
例えば既知の攻撃IPをブロックするIPセットルール（WCU消費が少ない）をリストの上位に置き、高WCUのBot Controlを下位に置く構成は、コスト最適化の基本的なアプローチです。
IPレート制限・Geoブロックの活用
レートベースルール（一定時間内のリクエスト数に基づいてブロック）とGeoブロック（地理的制限）は、WCU消費が低く、ノイズとなるリクエストを上流で遮断するのに有効です。
Geoブロックは、サービス対象外の地域からのリクエストをルールリストの最上位で遮断します。日本国内のみを対象としたサービスであれば、海外からの大量アクセスがBot Controlや正規表現ルールに到達する前にブロックされます。
レートベースルールは短時間での大量リクエストを上位で遮断するため、DDoS試みに対してBot Controlが大量評価を行う前に機能します。2つを組み合わせると、高コストルールへ到達するリクエスト量を絞り込めます。
CDN/キャッシュ導入でWAF評価リクエスト自体を削減
CloudFront統合で重複評価を回避
WAFのリクエスト評価料金はWAFが実際に評価したリクエスト数に基づきます。CDN（コンテンツデリバリネットワーク）でキャッシュされたレスポンスを返すリクエストはオリジンサーバーへ届かず、WAFの評価対象外になります。
Amazon CloudFrontとAWS WAFを統合すると、CloudFrontが保持するキャッシュからレスポンスを返す静的コンテンツや変化の少ないAPIレスポンスはWAFを通らないため、評価リクエスト数を削減できます。
キャッシュヒット率が高いほど、WAFが評価する実リクエスト数が減ります。静的ファイル（CSS・JavaScript・画像）はキャッシュ期間を長めに設定し、WAFルールの適用範囲を動的リクエストに絞ることがコスト削減のポイントです。
ただし、キャッシュ設計の誤りはセッション情報の漏えいなどのリスクを伴います。キャッシュコントロールヘッダーの設定やCache-Control: no-storeの適切な指定は、セキュリティ観点から慎重に設計する必要があります。
重複ルール統合とWCU節約の実施手順
棚卸しの進め方
WAFルールの棚卸しは、運用コスト削減の出発点です。まず現在のWeb ACLに含まれるすべてのルールを一覧化し、各ルールのWCU使用量とブロック・許可件数をAWS WAF本体のメトリクス（Amazon CloudWatch連携）で確認します。
ブロック件数がゼロのルールや、他のルールと実質同じトラフィックを対象とした重複ルールは削除候補です。また、マネージドルールグループ内のルールを個別に無効化（ExcludedRule設定）すると、グループ内の不要ルールのWCU消費を抑えられます。
棚卸しの際は各ルールの「設置理由」も記録します。過去のインシデント対応で追加されたルールが放置されているケースでは、現在の脅威環境に照らして再評価するとWCU超過の改善につながります。
WCU超過検知と削減の判断基準
WCUの使用状況はAWS WAFコンソールのWeb ACL詳細画面または CloudWatch メトリクスで確認できます。1,500 WCU（基本料金内の上限）に近づいている場合、超過する前に対策を取ることがコスト増を防ぐポイントです。
削減の判断基準として、以下の順序でアプローチします。まずscope-downで高WCUルールの適用範囲を絞る。次に重複ルールを統合または削除する。それでも1,500 WCUを超える場合は、正規表現ルールの書き直しや、別のルールタイプへの置き換えを検討します。
WCU 1,500超過後の追加課金は「500 WCUごとに100万リクエストあたり$0.20」*1です。トラフィックが多いサービスでは超過 WCU × トラフィック量で費用が積み上がるため、早期対処が費用削減効果を高めます。
内製vs外注：WAF/Shieldコスト最適化に必要なスキルと工数
AWS WAF/Shieldのコスト最適化を内製で進めるには、複数の専門知識と相応の工数が必要です。
必要な専門知識の領域は以下のとおりです。
- AWS WAFのルール評価順序・WCU設計・scope-downステートメントの記述
- CloudWatchメトリクスによるWCU・リクエスト評価量のモニタリング
- Terraform・CloudFormationなどIaCを使ったルール変更管理
- セキュリティ要件との整合確認（変更前後の脅威検証）
- CDNキャッシュ設計とセキュリティヘッダーの整合
これらをカバーする担当者が1〜2名で作業した場合、ルール棚卸しから実装・検証までに複数週間規模の期間を要するケースがあります。担当者がAWS WAFの詳細仕様に不慣れであれば、さらに時間がかかります。
内製対応の主なリスクは2点です。第一に、ルール削除・変更の際に意図せずセキュリティ上のホールを生む可能性があります。WAFルールの誤設定はSQLインジェクションやXSS（クロスサイトスクリプティング）の通過リスクに直結します。第二に、最適化後の継続監視体制が整っていないと、トラフィック増加時に再度WCUが超過しコストが積み上がります。
外注（専門パートナーへの委託）では、AWS WAFの設計・運用実績を持つエンジニアがルール評価・設計変更・検証を担当します。セキュリティ要件を維持したまま最適化を進めるため、内製で発生しがちな設定ミスのリスクを低減できます。
外注で期待できるメリットは主に3点です。
- WAFルール設計の専門知識を即時活用でき、自社エンジニアの学習コストが不要
- 最適化後の継続監視・アラート設計をセットで依頼することで再発を防止
- コスト削減効果を定量的に報告する体制を持つパートナーに任せることで社内説明も容易
委託先を選定する際は、AWSのセキュリティサービス（WAF・Shield・CloudFront）の設計・運用実績、およびコスト最適化を含むFinOps領域の支援経験を確認することが有効です。
まとめ：WAF/Shieldコスト最適化の3つの判断軸
本記事では、AWS WAF/Shieldのコスト最適化について5つの手法と外注活用の進め方を整理しました。要点を3つに集約すると次のとおりです。
第一に、課金は「Web ACL・ルール・リクエスト評価・WCU」の4軸で構成されており、それぞれに削減アプローチが異なります。どの要素がコスト増の原因かをCloudWatchメトリクスで特定することが出発点です。
第二に、scope-downステートメントによる高コストルールの適用範囲限定と、低WCUルールを上位に配置するルール順序最適化が、リクエスト評価費用とWCU超過を抑える実効性の高い手法です。
第三に、内製対応にはWAFルール設計・IaC・CloudWatchモニタリングなど複数の専門知識と工数が必要で、ルール誤設定のリスクも伴います。外注を活用することで、セキュリティ水準を維持しながらコスト削減を進める体制を整えられます。
よくある質問
AWS WAFのWCUが1,500を超えているかどうかはどうやって確認しますか？
Amazon CloudWatchのメトリクスで確認できます。AWS WAFコンソールの「Web ACL」詳細画面から「Web ACL capacity used」メトリクスを参照すると現在のWCU使用量が確認できます。1,500に近い、または超過している場合はアラートを設定しておくと費用増加を早期に検知できます。
Shield Standardで十分なケースはどのような場合ですか？
ネットワーク層・トランスポート層（L3/L4）への一般的なDDoS攻撃対策であれば、Shield Standardで対応できます。*2アプリケーション層（L7）への高度な攻撃や、DDoS攻撃による費用保護（保険的なコストカバー）が必要なサービスにはShield Advancedの検討が有効です。月額$3,000の費用と期待する保護水準を比較して判断することをおすすめします。
scope-downステートメントを設定するとセキュリティが低下しますか？
適切に設計すれば、セキュリティ低下を招かずにコストを削減できます。scope-downは「そのルールを評価するリクエストの範囲を絞る」機能です。例えばBot Controlを/login・/checkoutに限定する場合、その他のパスはBot Controlで評価されません。適用外のパスへのリスクを別のルール（IPレート制限など）でカバーする設計が前提となります。変更前にステージング環境で動作確認することを推奨します。
AWS WAFのコスト最適化を外注する場合、何を依頼先に確認すればよいですか？
確認すべき主なポイントは3点です。第一に、AWS WAFのルール設計・WCU最適化の実績があるかどうか。第二に、最適化後の監視・アラート設計をセットで提供しているか。第三に、コスト削減効果を定量的に報告する体制があるかどうかです。AWSのパートナープログラム認定（APN Partner）の有無も依頼先の技術力の目安になります。
CloudFrontとWAFを統合するとリクエスト評価料金はゼロになりますか？
キャッシュヒットしたリクエストはWAFの評価対象外になりますが、キャッシュされない動的リクエスト（ログインAPIやカート操作など）はWAFで評価されるため、リクエスト評価料金はゼロにはなりません。キャッシュヒット率が高い静的コンテンツ中心のサービスほど削減効果が高く、動的APIがメインのサービスでは効果が限定的になります。実際の削減効果はトラフィック構成によって異なります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Amazon Web Services「AWS WAF 料金」（2024年公表・随時更新）
- *2 出典：Amazon Web Services「AWS Shield 料金」（2024年公表・随時更新）
- *3 出典：Amazon Web Services「AWS WAF デベロッパーガイド：スコープダウンステートメント」（2024年公表・随時更新）
