WAFってどうやってつけるの？WAFの作成手順からAWSファイアウォール全体像まで深ぼってみた

Posted at 2026-06-13

どーも！shihopowerです！
今回はAWS WAFをはじめとするファイアウォールについてお話します。

SAP対策でWAFに関する練習問題に出会ったのですが、「WAFって何者？どう使うの？」状態だったので、AWS公式ドキュメントをもとに徹底的に調べてみました。
そしてどうせなら「AWS上のファイアウォールって他に何があるの？」というところまで広げて、全体像を俯瞰してみました。
セキュリティグループやネットワークACLとの違いも整理できたので、AWSのネットワークセキュリティを体系的に理解したい方にも参考になると思います！

この記事で参照しているのはAWS公式ドキュメントのみです。

🚀 忙しい人向けの要約

AWS WAFはアプリケーション層（L7）で動作するWebファイアウォール。SQLインジェクション・XSSなどのWeb攻撃を防ぐ
WAFを使う際は 最初にCountモードで様子見 → ログで誤検知を確認 → Blockに切り替える のが公式推奨手順
AWSには複数のファイアウォールサービスがあり、この記事では主要な6つを解説する
セキュリティグループ（インスタンス単位・ステートフル）とネットワークACL（サブネット単位・ステートレス）は別物
Network FirewallはVPC境界全体をL3〜L7で守る。DNS FirewallはDNSクエリを制御して情報漏洩を防ぐ
これらは**多層防御（Defense in Depth）**の考え方で組み合わせて使うのがAWSの推奨

この記事を書いたきっかけ（練習問題との出会い）
そもそもWAFとは？
WAFの使い方・設定手順
- 3-1. Web ACLの作成
- 3-2. AWSリソースへの関連付け
- 3-3. ルールの追加
- 3-4. CountモードでテストしてからBlockへ切り替える理由（←ここが核心）
セキュリティグループ・ネットワークACLとの違い
- 4-1. セキュリティグループ
- 4-2. ネットワークACL
- 4-3. 公式の比較表
AWSファイアウォール全体像
- 5-1. AWS Network Firewall
- 5-2. Route 53 DNS Firewall
- 5-3. AWS Shield
全サービスまとめ比較表
おわりに・参考リンク

1. この記事を書いたきっかけ

SAP対策で以下のような問題に出会いました（内容を要約しています）。

問題：
あるWebアプリをApplication Load Balancerの背後のEC2フリートでホスティングしている。AWS WAF Web ACLを使ってセキュリティを強化したい。正当なトラフィックに悪影響を与えないようにするには、Web ACLをどう設定すべきか？

選択肢（抜粋）：

A. ルールのアクションをCountに設定 → ログで誤検知を分析 → ルールを修正 → Blockに変更

C. 最初からBlockに設定し、マネージドルールグループのみを使用する

正解はAです。最初から「Block」にしてしまうと、正当なトラフィックをブロックしてしまうリスクがあるから……ということは何となくわかりました。でも「なぜCountから始めるのか」「そもそもWAFはどう使うのか」が全然わかっていなかったので、公式ドキュメントを読み込んで整理しました。

2. そもそもWAFとは？

AWS公式ドキュメントによると、

AWS WAF は、エンドユーザーがアプリケーションに送信する HTTP・HTTPS リクエストを監視し、コンテンツへのアクセスを制御するWebアプリケーションファイアウォールです。
（AWS WAF Developer Guide）

WAFが保護できるリソースは以下の通りです。

Amazon CloudFront ディストリビューション
Amazon API Gateway REST API
Application Load Balancer（ALB）
AWS AppSync GraphQL API
Amazon Cognito ユーザープール
AWS App Runner サービス
AWS Verified Access インスタンス
AWS Amplify

WAFでできることを一言でいうと、「IPアドレスやリクエストの中身（SQLコード、スクリプト、文字列など）に基づいてリクエストを許可・ブロック・カウントする」ことです。

WAFで設定できる基本動作

動作	説明
Allow	指定した条件以外のリクエストをすべて許可
Block	指定した条件以外のリクエストをすべてブロック
Count	リクエストをカウントするだけ（許可もブロックもしない）
CAPTCHA / Challenge	ボット検証を実施する

3. WAFの使い方・設定手順

公式ドキュメントが推奨するWAFの使用手順は以下の通りです。

STEP 1  WAFの概要理解（保護対象リソースの確認）
    ↓
STEP 2  Web ACLの作成（リソースタイプ・リージョン選択）
    ↓
STEP 3  ルールの追加（カスタムルール or マネージドルールグループ）
    ↓
STEP 4  AWSリソース（ALBなど）へWeb ACLを関連付け
    ↓
STEP 5  Countモード + ログ有効化でテスト・誤検知を修正
    ↓
STEP 6  問題なければBlockモードへ切り替えて本番運用

3-1. Web ACLの作成

Web ACL（Web Access Control List）がWAFの中核です。

作成時には以下を設定します。

リソースタイプ：「Amazon CloudFrontディストリビューション」または「リージョナルリソース（ALBなど）」
リージョン：リージョナルリソースの場合は、Web ACLをリソースと同じリージョンに配置する必要があります（CloudFrontは us-east-1 固定）

3-2. AWSリソースへの関連付け

注意点が2つあります。

1つのWeb ACLを複数のリソースに関連付けることは可能
ただし、各AWSリソースに関連付けられるWeb ACLは1つのみ

3-3. ルールの追加

ルールには大きく2種類あります。

カスタムルール（自分で定義）

以下の条件でリクエストを検査できます。

条件の種類	説明
IPアドレス	リクエスト元のIPアドレス
地理的条件	リクエスト元の国
文字列一致	リクエスト内の特定の文字列、正規表現パターン
リクエストサイズ	リクエストの長さ
SQLインジェクション	SQLコードが含まれるリクエスト
クロスサイトスクリプティング	XSSスクリプトが含まれるリクエスト

マネージドルールグループ（AWSや Marketplace が提供する既製品）

AWSが事前に設定したルールセットです。自社の特定ニーズに対応できない場合もある点は要注意です。

3-4. Countモードでテストしてから Blockへ切り替える理由（←ここが核心！）

ここが今回の問題の正解につながるポイントです。

公式ドキュメントには以下のように明記されています。

本番トラフィックへのデプロイ前に、ステージング・テスト環境でテストとチューニングを行い、その後 Countモードで本番トラフィックに対してルールのテストとチューニングを行ってから有効化することを推奨します。
（Testing and tuning your AWS WAF protections）

なぜCountから始めるのか？

WAFのルールアクションには3段階あります。

アクション	性質	動作
Count	非終端アクション	リクエストをカウントするだけ。ブロックしない。残りのルールの評価を継続する
Allow	終端アクション	リクエストを保護対象リソースへ転送する
Block	終端アクション	リクエストをブロックする（デフォルトはHTTP 403を返す）

最初からBlockに設定してしまうと、誤検知（正当なトラフィックへの誤マッチ）が起きたとき即座にサービス影響が出ます。

Countモードから始めることで、「このルールは実際にどのリクエストにマッチするのか」をブロックせずに観察できます。

推奨フロー（公式準拠）

① ルールアクションを Count に設定
        ↓
② WAFログを有効化
        ↓
③ ログ・メトリクスを分析し、誤検知を確認
   （CountアクションのルールはnonTerminatingMatchingRulesに記録される）
        ↓
④ 誤検知を回避するようルールを調整・修正
        ↓
⑤ ルールが正しく機能していると確認できたら Block に変更

また、WAFログを有効にすると以下の送信先にトラフィック詳細を記録できます。

Amazon CloudWatch Logs ロググループ
Amazon S3バケット
Amazon Data Firehose デリバリーストリーム

4. セキュリティグループ・ネットワークACLとの違い

WAFを調べていて、ふと思いました。「ファイアウォールってWAFだけじゃないよな。セキュリティグループやネットワークACLも確かそうだったはず……」。ということで、ついでにそちらも整理してみました。

4-1. セキュリティグループ（インスタンスレベル）

セキュリティグループは、関連付けられたリソース（EC2インスタンスなど）に到達・送出されるトラフィックを制御します。
（Amazon VPC User Guide - Security groups）

ステートフルであることが最大の特徴です。

セキュリティグループはステートフルです。インスタンスからリクエストを送信すると、そのレスポンストラフィックはインバウンドのセキュリティグループルールに関係なく許可されます。
（同上）

つまり「行きのルールを許可したら、帰りは自動的に許可される」という動作です。

また、セキュリティグループのルールは**「許可」のみ**設定でき、明示的な「拒否」ルールは設定できません。

4-2. ネットワークACL（サブネットレベル）

ネットワークACLは、サブネットレベルで特定のインバウンド・アウトバウンドトラフィックを許可またはブロックします。
（Amazon VPC User Guide - Network ACLs）

セキュリティグループとの最大の違いはステートレスであることです。

ネットワークACLはステートレスです。以前に送受信されたトラフィックの情報は保存されません。たとえば特定のインバウンドトラフィックを許可するACLルールを作成しても、そのトラフィックへのレスポンスは自動的には許可されません。
（同上）

つまり「行きを許可しても、帰りは別途ルールで許可する必要がある」ということです。

また、ネットワークACLはルールを番号の小さいものから順番に評価し、最初にマッチしたルールが適用されます（以降は評価されません）。

さらに、セキュリティグループと異なり「拒否」ルールも設定できます。

4-3. 公式の比較表

AWS公式ドキュメントが提供している比較表を日本語でまとめます。

（参照：Infrastructure security in Amazon VPC）

特性	セキュリティグループ	ネットワークACL
動作レベル	インスタンスレベル	サブネットレベル
スコープ	関連付けられたすべてのインスタンスに適用	関連付けられたサブネット内の全インスタンスに適用
ルール種別	許可ルールのみ	許可・拒否ルールの両方
ルール評価	全ルールを評価してから判断	番号昇順で評価・最初のマッチで決定
戻りトラフィック	自動的に許可（ステートフル）	明示的に許可が必要（ステートレス）
追加料金	なし	なし

4-4. 公式の推奨使い分け

セキュリティグループをVPCへのネットワークアクセス制御の主要な仕組みとして使用してください。ネットワークACLは必要に応じてステートレスな粗粒度のネットワーク制御を補助的に追加する目的で使用します。
（Infrastructure security in Amazon VPC）

5. AWSファイアウォール全体像

WAFとセキュリティグループ・ネットワークACLの違いがわかったところで、AWSにはほかにどんなファイアウォール関連サービスがあるか俯瞰してみます。

⚠️ 注意：「AWSのファイアウォールは全部で○種類」とAWS公式が定義しているわけではありません。ここでは主要なサービスを取り上げます。サードパーティ製（Palo Alto Networks Cloud NGFW、Fortigate CNFなど）もAWS Marketplace経由で利用可能です。

5-1. AWS Network Firewall（VPC境界・L3〜L7）

AWS Network Firewall は、Amazon VPC向けのステートフルなマネージド型ネットワークファイアウォールおよび侵入検知・防御サービスです。インターネットゲートウェイ、NAT ゲートウェイ、VPN、Direct Connect を経由するトラフィックを含む、VPC境界のトラフィックをフィルタリングできます。
（What is AWS Network Firewall?）

セキュリティグループ・ネットワークACLが「VPC内のリソース単位・サブネット単位の制御」であるのに対し、Network FirewallはVPCの境界全体を守るイメージです。

主なユースケース：

既知のAWSサービスドメインや特定IPからのトラフィックのみ通過させる
悪意があると判明しているドメインへのアクセスをブロックする
VPCに出入りするトラフィックの**ディープパケットインスペクション（DPI）**を実施する
ポートに関係なくHTTPSなどのプロトコルをステートフルに検出・フィルタリングする

また、ステートレスルールはネットワークACLに似た動作を、ステートフルルールはセキュリティグループに似た動作をします。

5-2. Amazon Route 53 Resolver DNS Firewall（DNS層）

DNS Firewallは、VPC内のアプリケーションからRoute 53 VPC Resolverを通過するアウトバウンドDNSクエリのフィルタリングを提供します。
（Using DNS Firewall to filter outbound DNS traffic）

主な目的はDNSエクスフィルトレーションの防止です。

DNSエクスフィルトレーションとは、攻撃者がVPC内のアプリケーションを侵害し、DNSルックアップを使ってVPC外の制御下にあるドメインへデータを送り出す手法です。

DNS Firewallを使うと：

悪意があると分かっているドメインへの名前解決をブロック（ブラックリスト方式）
信頼するドメインのみに名前解決を許可（ホワイトリスト方式）

の2つのアプローチが取れます。

Network Firewallはネットワーク層・アプリケーション層のトラフィックをフィルタリングしますが、Route 53 VPC Resolverが行うDNSクエリは可視化できません。そのためDNS制御にはDNS Firewallが必要です。
（同上）

5-3. AWS Shield（DDoS保護）

厳密にはファイアウォールではなくDDoS保護サービスですが、セキュリティ文脈でセットで語られることが多いので紹介します。

AWS Shield StandardとAWS Shield Advancedは、ネットワーク層・トランスポート層（L3・L4）およびアプリケーション層（L7）における分散型サービス拒否（DDoS）攻撃に対する保護を提供します。
（How AWS Shield and Shield Advanced work）

Shield Standard：すべてのAWSユーザーに追加費用なしで自動的に提供されます。

Shield Advanced：有償の上位プランです。DDoS攻撃・ボリューメトリックボット・脆弱性悪用などの外部脅威からアプリケーションを保護します。WAFとの統合により、アプリケーション層のDDoS自動緩和も可能です。

6. 全サービスまとめ比較表

サービス	守る対象	OSI層	ステート	主な用途	追加料金
セキュリティグループ	インスタンス（EC2など）	L3/4	ステートフル	インスタンス単位のアクセス制御	なし
ネットワークACL	サブネット	L3/4	ステートレス	サブネット境界のトラフィック制御	なし
AWS WAF	ALB・CloudFrontなど	L7（アプリ）	ステートフル	Web攻撃（SQLi・XSS等）の防御	あり
AWS Network Firewall	VPC境界全体	L3〜L7	両方	DPI・IPS・URLフィルタリング	あり
Route 53 DNS Firewall	DNSクエリ（VPC内）	DNS層	—	悪意あるドメインへの名前解決ブロック	あり
AWS Shield	AWS全体	L3/4/7	—	DDoS攻撃からの保護	Standard:なし / Advanced:あり

多層防御のイメージ

インターネット
    ↓
[ AWS WAF ] ← L7：Web攻撃（SQLi・XSS・HTTPフラッド）を検査
    ↓
[ AWS Shield ] ← L3/4/7：DDoS攻撃を緩和
    ↓
VPC境界
[ AWS Network Firewall ] ← L3〜L7：VPC全体の入出力トラフィックを深く検査
    ↓
サブネット境界
[ ネットワークACL ] ← L3/4：サブネット単位で粗粒度の制御（ステートレス）
    ↓
インスタンス
[ セキュリティグループ ] ← L3/4：インスタンス単位で細粒度の制御（ステートフル）
    ↓
EC2 / Webアプリケーション

※ DNS Firewallは上記の流れとは別に、VPC内のDNSクエリ（アウトバウンド）を制御

7. おわりに・参考リンク

WAFの「Countから始めてBlockへ移行する」という手順は、一見遠回りに見えますが、正当なトラフィックへの悪影響を避けるための公式推奨プロセスです。試験の選択肢を見るとき、「最初からBlockはリスクがある」という感覚が持てると正解が見えてきます。

また、「ファイアウォール＝WAFだけ」ではなく、レイヤーごとに異なるサービスが多層防御を担っているという俯瞰的な視点を持てると、AWSのネットワークセキュリティ全体が整理されてくると思います。

参考リンク（すべてAWS公式ドキュメント）

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up