AWS WAFの基本。「入れただけ」で終わらせない運用のポイント

WebアプリケーションをAWSで公開した瞬間から、世界中のボットや攻撃者からのアクセスが始まります。しかし、ALBやCloudFrontだけではアプリケーション層への攻撃は防げません。本記事では、アプリケーション層（L7）への攻撃を防ぐAWS WAFの基本概念から導入手順・運用上の注意点を体系的に解説します。

目次

• AWS WAFとは？基本概念と仕組みを解説
  • ファイアウォール・IPS・IDS・WAFの違い
  • AWS WAFが保護できるリソース一覧
  • AWS WAFの基本、WebACL・ルール・アクションの関係
    • WebACL
  • 料金体系
• 外部公開システムにAWS WAFが特に重要な理由
  • AWSのセキュリティ共有責任モデルとWAFの位置づけ
  • AWS WAFが防げる攻撃・防げない攻撃
• AWS WAFに必須のルール設定。マネージドルールとカスタムルールの使い分け
  • マネージドルール
    • ▼代表的なマネージドルール
  • カスタムルール
• AWS WAFの導入・設定の流れ
  • Step1. WebACLの作成
  • Step2. ルールの適用
  • Step3. WebACLをリソースに関連付ける
  • Countモードで検証してからBlockへ移行する
• よくあるAWS WAFの運用課題
• AWS WAF運用効率化サービスのWafCharm

AWS WAFとは？基本概念と仕組みを解説

AWS WAF（Web Application Firewall）は、AWSが提供するクラウド型のWebアプリケーションファイアウォールです。WebサイトやAPIに届くHTTP/HTTPSリクエストをリアルタイムで検査し、不正な通信をブロックすることでWebアプリケーションをサイバー攻撃から保護します。

ファイアウォール・IPS・IDS・WAFの違い

一般的なファイアウォールは、IPアドレスやポート番号を基準にネットワーク層（L3/L4）での通信を制御するものです。しかし、WebアプリケーションへのアクセスはHTTP/HTTPSという正規の通信経路を通じて行われるため、従来のファイアウォールでは攻撃かどうかの判別ができません。

IPS（不正侵入防止システム）やIDS（不正侵入検知システム）もネットワーク層での対策が中心であり、Webアプリケーション固有の脆弱性を突く攻撃への対処には限界があります。

AWS WAFは、アプリケーション層（L7）で動作し、HTTP/HTTPSの通信内容そのものを詳細に検査します。リクエストのURL・ヘッダー・ボディ・クエリパラメータなどを分析し、攻撃パターンに一致する通信だけを検知・遮断し、SQLインジェクションやクロスサイトスクリプティング（XSS）など、Webアプリケーションの脆弱性を突くサイバー攻撃を防ぎます。

AWS WAFが保護できるリソース一覧

AWS WAFは以下のAWSリソースと連携して動作します。

これらのリソースに対してAWS WAFをAWS管理画面コンソールから有効化するだけで導入が完了するため、追加のハードウェアやソフトウェアは不要です。

AWS WAFの基本、WebACL・ルール・アクションの関係

AWS WAFは「WebACL（アクセスコントロールリスト）」「ルール（シグネチャ）」「アクション」という3つの要素で構成されています。

WebACL

WebACL（Web Access Control List）は、複数のルールをまとめて管理するための入れ物です。作成したWebACLを保護対象のリソース（ALBやCloudFrontなど）に関連付けることで、AWS WAFが機能し始めます。1つのリソースに関連付けられるWebACLは1つだけです。
また、WebACLには「WCU（Web ACL Capacity Units）」という容量の上限があります。追加料金なしで使用できるのは1,500WCUまでで、ルールの種類や複雑さによって消費するWCUが異なります。

ルール（シグネチャ）
ルールとはシグネチャとも呼ばれ、「どのようなリクエストを検知するか」を定義するものです。
IPアドレス・送信元の国・URLのパス・リクエストボディの内容など、さまざまな条件（ステートメント）を組み合わせて作成します。ルールには評価順序（プライオリティ）があり、数字が小さいルールから順番に評価されます。

BlockまたはAllowのアクションが確定した時点で評価は終了し、それ以降のルールは評価されません。ただし、Countはこの限りではなく、一致しても評価は継続され後続のルールが引き続き適用されます。（アクションについては後述します）
許可リストを高いプライオリティに設定するなど、評価順序を意識した設計が誤検知防止に直結します。

アクション
アクションは、設定したルールの条件に一致したリクエストに対して、どのように処理するかを定義するものであり、主要な3種類を紹介します。

アクション	内容
Allow	リクエストを許可する
Block	リクエストを遮断する
Count	リクエストを記録するのみで、通信は素通りさせる（検証用途）

ここで注意が必要なのがCountアクションです。Countは「検知しているだけで攻撃は素通りしている」状態であり、WAFとして機能しているように見えても実際には保護されていません。
Countはあくまで導入時の検証用途で使うものであり、検証完了後は必ずBlockへ切り替える必要があります。この点については後述のセクションで詳しく解説します。

料金体系

AWS WAFは従量課金制で、主に以下の3つの要素で料金が決まります。

※ 料金はリージョンにより異なる場合があります。最新の料金はAWS公式の料金ページをご確認ください。

課金要素	料金
WebACL	WebACLあたり 5ドル／月
ルール	1ルールあたり 1ドル／月
リクエスト数	100万リクエストあたり 0.6ドル

初期費用・最低利用料金はなく、利用した分だけの課金となります。なお、Bot ControlやAccount Takeover Prevention（ATP）などの高度なマネージドルールを利用する場合は上記に加えて追加料金が発生します。

外部公開システムにAWS WAFが特に重要な理由

Webアプリケーションをインターネットに公開するということは、世界中のあらゆるユーザからのアクセスを受け入れる状態になることを意味します。これは正規のユーザだけでなく、悪意を持った攻撃者からのアクセスも同様に受け入れることになります。

引用：株式会社サイバーセキュリティクラウド2026年2月公開『Webアプリケーションへのサイバー攻撃検知レポート』

実際、外部公開されたWebアプリケーションに対しては、公開直後から自動化されたスキャンツールやボットによる攻撃が始まるケースが珍しくありません。
弊社が2026年2月に公開したWebアプリケーションへの攻撃検知レポートでも、Webスキャンと呼ばれる脆弱性探索行為は最も多く、不特定多数の公開されたWebアプリケーションの弱点を探索しする活動が活発に行われていることが確認されています。

「自社のサービスは規模が小さいから狙われない」という認識は誤りであり、攻撃が効率化・自動化されているからこそ、セキュリティ対策が手薄な中小規模のサービスほど攻撃の標的になる可能性も高まるため、外部公開しているサイト・Webアプリケーションにとって、WAFの重要性は高いと言えるでしょう。

なぜAWS移行・クラウド移行時にWAFの検討が重要であるか
オンプレミス環境ではネットワーク入口に設置された物理的なWAFアプライアンスがWebアプリケーションを保護していることがほとんどです。
しかしAWSへ移行する際、これらの保護はそのまま引き継がれません。

EC2インスタンス上にサードパーティ製の仮想WAFを構築する道もありますが、それでは運用管理や可用性の設計は引き続きユーザ側が担わなければなりません。
クラウド移行後に同等のセキュリティ水準を維持するには、AWS WAFをはじめとするクラウドネイティブなセキュリティサービスを改めて設計・導入する必要があります。
この考え方を整理したのが「AWSのセキュリティ共有責任モデル」です。

AWSのセキュリティ共有責任モデルとWAFの位置づけ

参考：AWS 責任共有モデル

AWSはセキュリティに関して「責任共有モデル」を採用しています。AWSがデータセンターや物理インフラのセキュリティを責任を持って管理する一方、AWS上で動作するアプリケーションやデータの保護はユーザ側の責任となります。

つまり、ALBやCloudFrontを通じて公開したWebアプリケーションをサイバー攻撃から守ることはユーザー自身の責務であり、AWS WAFの導入はその責任を果たすための重要な手段のひとつです。

AWSでWebアプリケーションを公開する際、多くの場合ALB（Application Load Balancer）やCloudFrontを経由してトラフィックを受け付ける構成をとります。
これらのサービス自体にはL7レベルのアクセス制御機能は備わっておらず、AWS WAFを明示的に関連付けない限り、アプリケーション層への攻撃は素通りしてしまいます。
その結果、以下のような攻撃に晒されるリスクがあります。

リスク	具体的な被害
情報漏えい	SQLインジェクションによるDBの不正取得・個人情報流出
サイト改ざん	マルウェア埋め込み・フィッシングページへの転用
サービス停止	DDoS攻撃による過負荷・サーバーダウン
アカウント乗っ取り	ブルートフォース攻撃による不正ログイン

AWS WAFが防げる攻撃・防げない攻撃

AWS WAFはアプリケーション層（L7）への攻撃を防御するサービスです。SQLインジェクションやクロスサイトスクリプティング（XSS）など、HTTPリクエストの内容を悪用した攻撃が主な防御対象となります。

一方、ネットワーク層・トランスポート層（L3/L4）への大規模なDDoS攻撃はAWS WAFの担当範囲外です。これらはAWS Shield Standardが自動的に対処します。
AWS Shield StandardはすべてのAWSユーザに追加料金なしで自動適用されており、ユーザ側での設定は不要です。

AWS環境のDDoS対策を詳しく解説

AWS WAFに必須のルール設定。マネージドルールとカスタムルールの使い分け

AWS WAFは攻撃を防御する定義書であるルールの設定がないと機能しません。一方で自力でルールを構築し、運用することには高いハードルがあります。
そこで、よく使われるのが、マネージドルールと呼ばれる事前に用意されたルールセットです。

マネージドルール

マネージドルールとは、あらかじめ専門家によって定義・管理されているルールセットです。ユーザーはルールの中身を一から作成することなく、選択して適用するだけで主要な攻撃への対策を講じることができます。

▼代表的なマネージドルール

ルールセット名	主な用途
Core Rule Set（CRS）	XSS・ローカルファイルインクルージョン（LFI）など一般的な攻撃への基本防御
Known Bad Inputs	既知の悪意あるリクエストパターンのブロック
SQLデータベース	SQLインジェクション攻撃への特化対応
WordPressアプリケーション	WordPress固有の脆弱性への対応
Amazon IP レピュテーションリスト	悪意あるIPアドレスからのアクセス制御
Bot Control	ボットの検知・制御

これらのマネージドルールを自社の環境に合わせて組み合わせて活用することがAWS WAF運用では必要になります。

マネージドルールの活用は、誰でも利用しやすい形でルールセットを安価に導入できることはメリットではありますが、以下のようなデメリットもあります。

• ルールがブラックボックス：ルールの詳細内容は非公開のため、何を根拠に検知しているかをユーザが確認できない
• ルールのカスタマイズができない：全ユーザが共通のルールを使用するため、自社環境に合わせた調整が不可能
• 誤検知のリスク：ルールをカスタマイズできないため、自社アプリケーション固有の正常な通信をブロックしてしまうケースがある

このようなデメリットを解消するため、カスタムルールがあります。

カスタムルール

カスタムルールは、ユーザが自社のアプリケーションや環境に合わせて独自に作成するルールです。マネージドルールが「汎用的な共通ルール」であるのに対し、カスタムルールは「自社専用のオーダーメイドルール」と言えます。

カスタムルールとマネージドルールの組み合わせを通じて、誤検知や特定のIPアドレスのアクセス制御など自社独自のセキュリティ対策を構築していくことが望ましいといえます。

AWS WAFの導入・設定の流れ

AWS WAFの導入は大きく3つのステップで進めます。追加のハードウェアやソフトウェアは不要で、AWSマネジメントコンソールから設定が完結します。

Step1. WebACLの作成

AWSマネジメントコンソールのWAF管理画面から「Web ACLの作成」を選択します。
設定する主な項目は名前・リージョン・デフォルトアクションの3つです。

リージョンの設定には注意が必要であり、ALB・API Gateway向けはリソースと同一リージョン、CloudFront向けはus-east-1（バージニア北部）を選択する必要があります。

デフォルトアクションは、不特定多数のユーザがアクセスする一般的なWebサービスであればAllowを選択するブロックリスト型が基本です。

WebACLにはWCU（Web ACL Capacity Units）という容量の上限があります。1,500WCUまでは基本料金に含まれ、超過分は500WCUごとに追加料金が発生します。

上限は5,000WCUで、2023年4月のアップデートにより申請不要で利用できるようになりました。必要なルールを見極めた設計でWCUを無駄なく使うことが重要です。

Step2. ルールの適用

WebACL作成後、マネージドルールとカスタムルールを追加します。前述の通り、自社環境に応じて複数のマネージドルールを組み合わせつつ、必要に応じてカスタムルールを加えるのが基本です。
この時点ではすべてのルールをCountモードで設定することを強く推奨します。
詳細は後述します。

Step3. WebACLをリソースに関連付ける

作成したWebACLを保護対象のリソース（CloudFront・ALB・API Gatewayなど）に関連付けることで設定が完了します。関連付けた時点でAWS WAFが有効になります。

Countモードで検証してからBlockへ移行する

レートベースルールとは、一定時間内に同一の識別子（IPアドレス・ヘッダー・URIなど）をもつリクエスト数を監視し、設定した閾値を超えた場合に自動的にBlock（またはCount）するルールです。

通常のユーザが短時間に大量のリクエストを送信することは考えにくいため、閾値を超えたIPアドレスはDDoS攻撃やブルートフォース攻撃（パスワードの総当たり攻撃）を行っている可能性が高いと判断できます。レートベースルールはこうした攻撃を自動的に検知・遮断する、シンプルかつ効果的な対策です。

レートベースルールは他のルールをBlockモードに変更した後に設定することが望ましいです。その理由は以下の2つです。

• 自社環境にとって適切なトラフィックの閾値データを見極めるため
• 誤検知のリスクが他のルールよりも高いため

閾値の設定を誤ると何らかのキャンペーン施策やセールなど正常な集中的アクセスのリクエストをブロックしてしまう可能性が高いためです。
Countモードで収集したログから通常時のアクセス量を把握した上で閾値を設定することを推奨します。

よくあるAWS WAFの運用課題

上述したように、AWS WAFの導入自体はAWSコンソール上で完結しますが、自社の環境に適したルールの選定に加えて、継続的な「運用」もセキュリティ対策には重要な要素です。
特に、日々変化するサイバー攻撃手法をキャッチアップして反映する「ルールの更新」や誤検知が発生した際の原因の切り分け、アプリケーション側または、WAFのルールの変更など都度細かい調整が必要となります。

多くの企業でセキュリティ専任人材を抱えることが難しい中、このAWS WAFの「運用」がハードルとなり、開発や他の業務に支障をきたすことが多々ございます。

WafCharm（ワフチャーム）はこういったAWS WAFの運用課題の解決をご支援するサービスです。

AWS WAF運用効率化サービスのWafCharm