テクノロジー 2026.11.13

AWS WAFとは？仕組み・料金・設定手順から運用のコツまで現役AWSエンジニアが解説

KANADE

「自社のWebサイトにWAFを入れたいけれど、AWS WAFって結局なにができるの？」「料金が読みにくくて、月にいくらかかるのか見当がつかない」。そんな疑問を持ってこのページにたどり着いた方は多いのではないでしょうか。

AWS WAF（Web Application Firewall）は、Webアプリケーションを狙った攻撃をブロックしてくれるAWSのセキュリティサービスです。簡単に導入でき、初期費用もかかりません。ただし「入れただけ」で安心できるわけではなく、料金の仕組みや運用のコツを知らないと、想定外のコストが出たり、正常なアクセスまでブロックしてしまったりします。

この記事では、AWS WAFの仕組み・料金・設定手順を、これから導入を検討している方に向けてわかりやすくまとめました。加えて、「ログの見方」「403エラーがWAF起因かどうかの切り分け」「まずCountモードで様子を見る運用」といった、実際に手を動かして初めてわかる実務のポイントまで踏み込みます。

1. AWS WAFとは？Webアプリを狙う攻撃を防ぐ「検問所」
2. AWS WAFで防げる攻撃・防げない攻撃
3. AWS WAFの仕組み｜Web ACL・ルール・アクションの関係
4. AWS WAFはどこに設置する？保護対象リソースと構成図
5. AWS WAFの料金体系【日本円の目安つき】
6. AWS WAFの設定手順｜4ステップで導入する
7. AWS WAFのログの見方と運用のコツ
8. AWS WAFとAWS Shieldの違いは？
9. AWS WAFに関するよくある質問（FAQ）
まとめ
参考リンク
関連記事

監修：KANADE
■保有資格
AWS Certified Cloud Practitioner / AWS Certified AI Practitioner / AWS Certified Solutions Architect - Associate / AWS Certified Developer - Associate / AWS Certified Machine Learning Engineer - Associate / AWS Certified SysOps Administrator - Associate / AWS Certified Data Engineer - Associate / AWS Certified DevOps Engineer - Professional / AWS Certified Solutions Architect - Professional / AWS Certified Security - Specialty / AWS Certified Database - Specialty / AWS Certified Data Analytics - Specialty / AWS Certified Machine Learning - Specialty / AWS Certified SAP on AWS - Specialty / AWS Certified Advanced Networking - Specialty / AWS Authorized Instructors
食品業界からIT業界未経験でALHへ入社。AWS環境上で稼働するシステムインフラの設計から運用保守を担当。

運営元：ALH株式会社
ALH株式会社は、AWSパートナーネットワーク（APN）において、以下の認定を取得しているAWSパートナー企業です。
◆ AWS 1000 APN Certification Distinction
AWS認定資格の取得数が1,000件を超えたパートナーに与えられる認定
◆ AWS Training Partner
AWS公認の研修トレーニングを提供できるパートナー認定

◆ AWS Select Tier Services Partner
AWSサービスの構築・運用において一定の実績を持つパートナー認定

1. AWS WAFとは？Webアプリを狙う攻撃を防ぐ「検問所」

AWS WAFとは、Webアプリケーションへのアクセスを検査し、SQLインジェクションやクロスサイトスクリプティングといった攻撃、悪意のあるBotからのアクセスをブロックできるAWSのマネージドサービスです。サーバーの前段に「検問所」を置き、あらかじめ決めたルールに合わない通信を防ぐイメージです。

WAFは「Web Application Firewall（ウェブアプリケーションファイアウォール）」の略で、その名のとおりWebアプリケーション層（通信の第7層）に特化した防御を担います。従来はハードウェア機器やソフトウェアとして自前で用意する必要がありましたが、AWS WAFはAWSのマネージドサービスとして提供されるため、機器の購入や保守は不要です。使った分だけ課金される従量課金制で、小さく始められる点が大きな特徴です。

1-1. ファイアウォール・IDS/IPSとの違いは？

違いは、守る「階層」です。通信は役割ごとに層が分かれており、それぞれの防御装置が見ている場所が異なります。

防御の種類	主に見る層	役割	空港にたとえると
ファイアウォール	ネットワーク層（L3/L4）	IPアドレスやポート番号で通信を許可・遮断	搭乗ゲートで「パスポート（どこから来たか）」を確認
IDS/IPS	ネットワーク〜アプリ層	不正な通信パターンを検知（IDS）・遮断（IPS）	監視カメラと警備員。不審な動きを見つけて通報する（IDS）/その場で取り押さえる（IPS）
WAF	アプリケーション層（L7）	Webアプリ特有の攻撃（SQLi・XSSなど）を検査・遮断	手荷物検査で「持ち物の中身」まで確認

ファイアウォールが「送信元IPやポート」という宛名レベルで通信をふるいにかけるのに対し、WAFはリクエストの中身（URLのパラメータやフォームの入力値など）まで踏み込んで検査します。たとえば正規のIPアドレスから届いたリクエストでも、そのなかに不正なSQL文が仕込まれていればWAFは弾けます。ここがファイアウォールとの決定的な違いです。

そのため、この3つは「どれか1つあればよい」ものではなく、役割の異なる防御を重ねる（多層防御）という考え方で組み合わせるのが基本です。

1-2. AWS WAFはクラウド型？アプライアンス型との違い

WAFには大きく分けて「アプライアンス型（自社に機器を設置）」「ソフトウェア型（サーバーにインストール）」「クラウド型（サービスとして利用）」の3種類があります。AWS WAFはこのうちクラウド型に分類されます。機器の調達も、OSやミドルウェアのメンテナンスも不要で、AWSマネジメントコンソールから設定するだけで使い始められます。

一方で、AWS WAFはAWSのサービス（CloudFrontやALBなど）に紐づけて使う設計のため、「AWS環境で完結している構成」に向いています。オンプレミスと組み合わせたハイブリッド構成や、複数のクラウドをまたいで一元管理したい場合は、サードパーティのクラウド型WAFのほうが合うケースもあります。

2. AWS WAFで防げる攻撃・防げない攻撃

AWS WAFが得意とするのは、Webアプリケーション層を狙った攻撃の防御です。代表的なものを押さえておきましょう。逆に「WAFでは防げない領域」もあるため、そこも確認が必要です。

2-1. SQLインジェクション

Webフォームやパラメータに不正なSQL文を注入し、データベースを不正操作する攻撃です。会員情報やクレジットカード情報の抜き取り、データの改ざん・削除につながる、被害の大きい代表的なものです。AWS WAFはリクエストに含まれる典型的なSQL文のパターンを検知し、ブロックできます。

2-2. クロスサイトスクリプティング（XSS）

Webページに悪意のあるスクリプトを埋め込み、閲覧したユーザーのブラウザ上で実行させる攻撃です。Cookieの盗取による「なりすまし」や、偽の入力フォームによる情報詐取などが起こります。AWS WAFはスクリプトタグなど不正なコードのパターンを検知してブロックします。

2-3. 悪意のあるBot・レイヤー7のDDoS攻撃

大量のアクセスを自動で送りつけ、サービスを停止させたり情報を収集したりするBotやDDoS攻撃にも対応できます。AWS WAFには、同一IPから一定時間内に届いたリクエスト数がしきい値を超えたら遮断する「レートベースルール」があり、アプリケーション層（L7）へのDDoSや総当たり攻撃（ブルートフォース）を緩和できます。さらに、より高度なBot対策として有料の「Bot Control」も用意されています（料金は第5章参照）。

2-4. AWS WAFで「防げない」攻撃もある

ここは見落とされがちですが重要です。AWS WAFはあくまでWebアプリケーション層の防御であり、万能ではありません。次のようなものはWAF単体ではカバーできません。

ネットワーク層（L3/L4）の大規模なDDoS攻撃：これはAWS Shieldの領域です（第8章で解説）
正規の認証情報を使った不正ログイン：IDとパスワードが正しければ、通信自体は「正常」に見えます
アプリケーション自体の設計上の脆弱性やロジックの穴：根本対策はアプリの改修が必要です
WAFの検査対象外の経路からの侵入

WAFは「入れれば安全」ではなく、セキュリティ対策の一部を担う存在です。AWSには「責任共有モデル」という考え方があり、クラウド基盤の安全はAWSが、その上で動かすアプリやデータの守りは利用者が担います。WAFは後者を助けるための有力な選択肢の1つ、と捉えるのが正確です。

3. AWS WAFの仕組み｜Web ACL・ルール・アクションの関係

AWS WAFは「Web ACL」「ルール」「アクション」という3つの要素で構成されています。簡単に言うと、「Web ACLという入れ物にルールを入れ、ルールに一致した通信へアクションを実行する」という構造で、この関係さえつかめば、設定画面で迷わなくなります。

3-1. Web ACL（ウェブアクセスコントロールリスト）

Web ACLは、複数のルールをまとめる「入れ物」です。これを保護したいリソース（CloudFrontやALBなど）に関連付けることで、そのリソースに届くリクエストがWAFの検査を通るようになります。Web ACLには、どのルールにも一致しなかったリクエストをどう扱うか（許可するか/ブロックするか）を決める「デフォルトアクション」も設定します。

3-2. ルールとルールグループ

ルールは「どんなリクエストを・どう扱うか」を定義する検査条件です。「送信元がこのIPなら」「URLにこの文字列が含まれていたら」といった条件（ルールステートメント）と、一致したときの動作（アクション）がセットになります。

複数のルールをまとめて再利用できるようにしたものが「ルールグループ」です。AWSが提供する「マネージドルールグループ」もこの形で提供されます。

3-3. マネージドルールとカスタムルールの使い分け

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

種類	内容	向いている場面
マネージドルール	AWSやセキュリティベンダーが用意した、攻撃パターンに対応済みのルール群。最新の脅威に合わせてAWS側が更新してくれる	まず基本的な防御をすぐ整えたいとき。導入で最初に選ぶ定番
カスタムルール	利用者が自分で条件を組む独自ルール。特定IPの許可・拒否、特定パスへのアクセス制限など	自社の要件に合わせて細かく制御したいとき

実務では、マネージドルールで土台を固めつつ、自社独自の要件はカスタムルールで補うという組み合わせが基本です。

3-4. アクションの種類（Allow・Block・Count・CAPTCHA・Challenge）

ルールに一致したリクエストへの動作（アクション）は、次の5つから選びます。この使い分けが運用の肝になります。

Allow（許可）：リクエストを通す
Block（ブロック）：リクエストを遮断する
Count（カウント）：ブロックはせず、一致した件数だけ記録する
CAPTCHA：画像認証などのパズルを出し、人間かどうかを確認する
Challenge：ブラウザに静かな検証を行い、正規のブラウザかを確認する

このなかで、導入初期に特に活躍するのがCountです。いきなりBlockにすると正常なアクセスまで遮断してしまう恐れがあるため、まずCountで「もしブロックしていたら何件引っかかっていたか」を観察してから本番のBlockに切り替える、という進め方が定石です（第6章・第7章で具体的に解説します）。

4. AWS WAFはどこに設置する？保護対象リソースと構成図

AWS WAFは単体では動かず、必ず何らかのAWSリソースに関連付けて使います。どこに紐づけられるのか、AWS公式ドキュメントに記載された対応リソースを整理します。

4-1. AWS WAFを関連付けられるリソース一覧

区分	リソース
グローバル	Amazon CloudFront ディストリビューション
リージョン	Application Load Balancer（ALB）
リージョン	Amazon API Gateway REST API
リージョン	AWS AppSync GraphQL API
リージョン	Amazon Cognito ユーザープール
リージョン	AWS App Runner サービス
リージョン	Amazon Bedrock AgentCore Gateway
リージョン	AWS Verified Access インスタンス
リージョン/グローバル	AWS Amplify

出典：AWS公式ドキュメント「Resources that you can protect with AWS WAF」

なお、CloudFrontに関連付ける場合は、Web ACLを米国東部（バージニア北部/us-east-1）リージョンで作成する必要があります（画面上は「Global（CloudFront）」と表示されます）。AWS Amplifyに関連付ける場合も、Web ACLはGlobal（CloudFront）で作成します。さらに、Web ACLだけでなく、そのWeb ACLが使うIP setやルールグループなどの部品もすべてus-east-1で作成しておく必要があります。ここは初心者がつまずきやすいポイントなので覚えておくとよいでしょう。

4-2. どこに置くのがよい？CloudFrontとALBの使い分け

代表的なのはCloudFront（AWSのCDN）に置く構成とALB（ロードバランサー）に置く構成です。

CloudFrontに置く：世界中のエッジロケーションで、ユーザーにより近い場所で攻撃を防ぎ、静的コンテンツ配信やグローバル展開に向く
ALBに置く：特定リージョンで動くアプリケーションの手前で防御し、オリジン（サーバー）に近い位置で細かく制御しやすい

一般的には、CloudFront → ALB → アプリケーションサーバーという構成で、より外側のCloudFront側にWAFを置くことで、攻撃をなるべく手前で遮断できます。

5. AWS WAFの料金体系【日本円の目安つき】

AWS WAFの基本料金は「Web ACLの数」「ルールの数」「処理したリクエスト数」の3つで決まります。初期費用や最低利用期間はなく、使った分だけの従量課金です。

※本セクションの料金情報は2026年9月時点のAWS公式ページを参考にしています。料金は予告なく変更される場合があります。利用前には必ずAWS公式料金ページで最新情報をご確認ください。（出典：AWS WAF公式料金ページ）

5-1. 課金される3つの基本要素

課金対象	料金（USD）
Web ACL	5.00 USD/月（1つあたり）
ルール	1.00 USD/月（1ルールあたり）
リクエスト	0.60 USD/100万リクエスト

Web ACLとルールは「持っているだけ」で月額（1時間で案分）がかかり、リクエスト料金は「処理した通信量」に応じてかかる、という二階建ての構造です。

※ルール料金は、自分で作成したカスタムルールと、AWSやベンダーが提供するマネージドルールグループの両方が対象です。マネージドルールグループは、中に何個のルールが入っていても「1ルールグループ＝1.00 USD/月」として計算されます。

5-2. Bot Control・アカウント保護などの追加料金

より高度な機能を使う場合は、上記に加えて追加料金がかかります。

機能	料金（USD）
Bot Control（高度なBot対策）	・サブスクリプション10.00 USD/月（Web ACLごと）＋ Common（一般的なBot）検出は1.00 USD/100万リクエスト（最初の1,000万リクエストは無料）・Targeted（高度なBot）検出は10.00 USD/100万リクエスト（最初の100万リクエストは無料）
Fraud Control（ATP/アカウント乗っ取り防止と、ACFP/不正アカウント作成防止）	ATP・ACFPそれぞれ10.00 USD/月（Web ACLごと）＋リクエスト料金は最上位の段階で1,000 USD/100万リクエスト（利用量に応じて700→400→200→50 USDへ段階的に下がる）
CAPTCHA	4.00 USD/分析する試行1万回
Challenge	0.40 USD/提供されるレスポンス100万回

※Allow（許可）、Block（ブロック）、Count（カウント）は追加料金なし

5-3. 料金シミュレーション例

イメージをつかむために、シンプルな構成で試算してみます。Web ACLを1つ、ルールを5つ設定し、月間1,000万リクエストを処理した場合の試算です。なお、ルール料金はカスタムルールだけでなくマネージドルールグループも1つあたり月1.00 USDの対象です（AWSマネージドルールのコアルールセットを1つ追加すれば、それも1ルール分としてカウントされます）。

Web ACL：5.00 USD
ルール：1.00 USD × 5 = 5.00 USD
リクエスト：0.60 USD × 10（＝1,000万÷100万）= 6.00 USD
合計：約16.00 USD/月

このように、小規模なサイトであれば日本円で月千円前後〜数千円程度から始められます。ただし追加機能のコストは幅が大きく、Bot Controlなら数十ドル単位、ログイン・登録フローを守るATPやACFPは検査するリクエスト数によって数百ドル以上に達することもあるため、守りたい対象と経路を絞ることをおすすめします。

5-4. コストを抑えるポイント

不要なルールは持たない：ルールは1つにつき月額がかかります。使っていないルールは削除しましょう
Web ACLを使い回す：1つのWeb ACLは複数のリソースに関連付けられます。用途が同じなら共通化するとWeb ACL料金を節約できます。なお、CloudFrontに関連付けたWeb ACLは、ALBやAPI Gatewayなど他のリソースタイプには関連付けできません。CloudFront用とリージョンリソース用は別々に用意する点に注意しましょう
追加機能は必要な範囲に絞る：Bot ControlやATPは効果的ですが、常時すべて有効にするとコストがかさみます。守りたい対象を明確にして選びましょう
ルールの複雑さ（WCU）に注意する：Web ACLには既定で1,500 WCU（ルールの処理容量を表す単位）という上限があり、複雑なルールを積み上げてこれを超えると、500 WCUごとに0.20 USD/100万リクエストが加算されます。ルールを足すときは数だけでなく容量も意識しましょう
本文検査の範囲を広げすぎない：リクエスト本文の検査上限は、ALB・AppSyncが8KB固定、CloudFrontなどは既定16KB（最大64KBまで拡張可。超過分は追加料金あり）です。大きなファイルをやり取りするAPIでは、この差が請求に大きく響きます

6. AWS WAFの設定手順｜4ステップで導入する

AWS WAFの導入は、大きく「Web ACLを作る → ルールを入れる → リソースに紐づける」という流れになります。ここではマネジメントコンソールでの基本的な設定手順を、初めての方向けに整理します。

6-1. Step1｜Web ACLを作成する

AWSマネジメントコンソールで「WAF & Shield」を開き、Web ACLを新規作成します。このときリージョンの選択に注意が必要です。CloudFrontを守るなら「Global (CloudFront)」を、ALBやAPI Gatewayを守るなら対象リソースと同じリージョンを選びます。

6-2. Step2｜マネージドルールを適用する

まずはAWSマネージドルールを追加するのがおすすめです。「AWS Managed Rules」のなかから、多くのケースで基本となる「Core rule set（コアルールセット）」や、SQLインジェクション対策の「SQL database」などを選んで追加します。これだけで、代表的な攻撃への基本的な守りが整います。

6-3. Step3｜IP制限などのカスタムルールを追加する（任意）

特定のIPアドレスだけ許可したい（ホワイトリスト）、あるいは特定のIPを拒否したい（ブラックリスト）といった要件があれば、IP setを作成してカスタムルールで制御します。たとえば「管理画面へのアクセスは社内IPのみ許可する」といった設定は、この方法で実現できます。

6-4. Step4｜Web ACLをリソースに関連付ける

作成したWeb ACLを、守りたいリソース（CloudFrontディストリビューションやALBなど）に関連付けます。これで実際にリクエストの検査が始まります。関連付けをして初めてWAFが機能する点を忘れないようにしましょう。

6-5. 【重要】いきなりBlockにしない｜まずCountモードで検証する

ここが実務で最も大切なポイントです。マネージドルールを入れたら、最初はアクションを「Count」にして様子を見ることを強くおすすめします。いきなりBlockにすると、正常なアクセスまで誤ってブロックしてしまい（誤検知/フォールスポジティブ）、サイトが正しく表示されなくなるリスクがあるためです。

Countモードで数日〜数週間ログを観察し、「本当に攻撃だけが引っかかっているか」「正常な通信を巻き込んでいないか」を確認してから、Blockへ切り替える。この一手間が、安全な導入と後々のトラブル回避につながります。

7. AWS WAFのログの見方と運用のコツ

AWS WAFは「入れて終わり」ではなく、ログを見ながら育てていくサービスです。ここでは、導入後に必ずぶつかる「ログの確認」「誤検知への対処」「403エラーの切り分け」という3つの実務ポイントを解説します。

7-1. ログはどこに出す？どう見る？

AWS WAFのログは、Amazon CloudWatch Logs・Amazon S3・Amazon Data Firehoseのいずれかに出力できます。まずはCloudWatch Logsに出しておくと、コンソール上で検索・確認しやすく、導入初期の観察に向いています。

ログには、リクエストごとに「どのルールに一致したか」「アクションは何だったか（許可・ブロック・カウント）」「送信元IP」「URI」などが記録されます。ブロックされたリクエストを見て、それが本当に攻撃なのか、正常な通信を巻き込んでいないかを判断するのが、ログ確認のいちばんの目的です。

また、WAFのログは1リクエストごとに記録されるため量が多くなりがちで、CloudWatch LogsやS3側の取り込み・保存料金がWAF本体の料金を上回ることもあります。導入初期は全件ログを出して観察し、運用が安定したらブロックしたリクエストだけに絞る、といった調整でコストを抑えられます。

▼CloudWatchの機能と料金はこちら

Amazon CloudWatchとは？現役AWSエンジニアが機能・料金・使い方を徹底解説

2026.8.18

7-2. 誤検知（フォールスポジティブ）への対処

マネージドルールの効果は大きいですが、まれに正常なアクセスを攻撃と誤認してブロックしてしまうことがあります。たとえば、記事投稿フォームで特定の記号を含む文章を送ったら、SQLインジェクションと誤検知された、といったケースです。

対処の基本は次の流れです。

ログで「どのルールが」「どのリクエストを」ブロックしたか特定する
それが誤検知だと確認できたら、そのルールだけを一時的にCountに戻す、または対象リクエストを許可する例外ルールを追加する
必要に応じてルールの適用範囲を調整する

いきなりルール全体を無効化するのではなく、問題のあるルールだけをピンポイントで調整するのがコツです。

7-3. 「403エラーが出た」はWAFが原因？確認方法

導入後によくある問題が「サイトで403 Forbiddenエラーが出るようになったがWAFのせい？」というものです。403の原因はWAFとは限らないため、次の手順での確認が必要です。

WAFのログ（またはCloudWatchのメトリクス）を確認する：該当時刻に、そのIP・URIへのリクエストが「Block」で記録されていれば、WAFが原因の可能性が高い
一時的に該当ルールをCountに変えて再現するか見る：Countにして403が消えれば、そのルールが原因と分かる
どのルールにも記録がない場合：403の原因はWAF以外（サーバー側のアクセス制御、S3のバケットポリシー、CloudFrontの設定など）を疑う

「WAFのログに該当リクエストのBlock記録があるか」を最初にチェックする。これが遠回りに見えて最短の確認方法です。

7-4. まず入れるべきマネージドルールは？

「マネージドルールが多すぎて、どれを選べばいいかわからない」場合、最初の一手としては、AWSマネージドルールの「Core rule set（コアルールセット）」から始めるのが無難です。一般的なWeb攻撃に幅広く対応した基本セットで、多くのサイトで土台になります。そのうえで、自社のアプリの性質（SQLを多用する、特定の言語環境で動くなど）に合わせて、対応するマネージドルールを足していくのがおすすめです。

いずれの場合も、追加したら必ずCountで検証してからBlockへ、の原則は変わりません。

8. AWS WAFとAWS Shieldの違いは？

ひと言でいうと、AWS WAFは「アプリケーション層の攻撃」対策、AWS Shieldは「DDoS攻撃」対策です。名前が似ていて混同されやすいですが、守る対象が異なります。

※本セクションの料金情報は2026年9月時点のAWS公式ページを参考にしています。料金は予告なく変更される場合があります。利用前には必ずAWS公式料金ページで最新情報をご確認ください。（出典：AWS Shield公式料金ページ）

項目	AWS WAF	AWS Shield Standard	AWS Shield Advanced
主な役割	SQLi・XSS・BotなどL7攻撃の防御	ネットワーク層（L3/L4）のDDoS自動防御	大規模・高度なDDoS防御＋専門サポート
料金	従量課金（第5章参照）	無料（全AWS利用者に自動適用）	3,000 USD/月（1年契約）＋データ転送料
DDoS対策	L7のレート制限は可能	L3/L4を自動で防御	L3/L4/L7を包括的に防御
こんな人に	Webアプリの脆弱性攻撃を防ぎたい	基本的なDDoS防御があれば十分	大規模サービスで手厚いDDoS対策が必要

ポイントは、Shield StandardはすべてのAWS利用者に無料で自動適用されていることです。つまり、基本的なネットワーク層のDDoS防御はすでに働いている状態です。そのうえで、Webアプリ層の攻撃を防ぎたいならAWS WAFを、より大規模で高度なDDoSに備えたいならShield Advancedを追加で検討する、という対応になります。

なお、AWS Shield AdvancedとAWS WAFは組み合わせて利用することも想定されており、Shield Advancedのサブスクリプションには以下のWAF関連特典が含まれています。

L7 DDoS保護マネージドルールの提供：アプリケーション層を保護するAWSマネージドルールグループへ追加料金なしでアクセス可能
月間500億件までのWAF利用枠：保護対象リソースに対するWAFリクエストは、支払者ID（組織全体）ごとに1か月あたり最大500億件まで追加料金なしで利用可能

※月間500億件を超えたリクエストについては、通常のAWS WAF料金表に準じた超過料金が発生します

9. AWS WAFに関するよくある質問（FAQ）

Q1. AWS WAFは無料で使えますか？

いいえ、AWS WAFは有料です。ただし初期費用や最低利用期間はなく、Web ACL 5.00 USD/月、ルール1.00 USD/月、リクエスト0.60 USD/100万件といった従量課金です。小規模なサイトなら月千円前後〜数千円程度から始められます。無料で使えるのは、DDoS防御の「AWS Shield Standard」のほうです。

Q2. AWS WAFのマネージドルールはどれを選べばいいですか？

まずはAWSマネージドルールの「Core rule set（コアルールセット）」から始めるのがおすすめです。一般的なWeb攻撃に幅広く対応した基本セットで、多くのサイトの土台になります。そのうえで、自社アプリの性質に合わせてSQLインジェクション対策などを追加していくとよいでしょう。適用したら必ずCountモードで検証してからBlockに切り替えてください。

Q3. AWS WAFを入れたら403エラーが出ました。原因ですか？

WAFが原因とは限りません。まずWAFのログを確認し、該当リクエストが「Block」で記録されているかを見てください。記録があればWAFが原因の可能性が高く、該当ルールを一時的にCountに変えて403が消えるかで切り分けられます。ログに記録がなければ、サーバー側のアクセス制御など、WAF以外の原因を疑います。

Q4. AWS WAFとAWS Shieldはどちらを入れるべきですか？

守りたい対象で決めます。Webアプリの脆弱性攻撃（SQLi・XSSなど）を防ぎたいならAWS WAF、大規模なDDoS攻撃に備えたいならAWS Shield Advancedです。なお、基本的なDDoS防御「Shield Standard」は無料で全利用者に自動適用されているため、多くのケースではまずWAFの導入から検討すれば十分です。

Q5. AWS WAFの設定は難しいですか？専門知識は必要ですか？

基本的な導入（マネージドルールを適用してリソースに紐づけるまで）は、コンソールから数クリックで完了できます。ただし、誤検知を減らしながら安定運用するには、ログを読んでルールを調整する運用の知識が必要です。導入自体は簡単でも、「入れただけ」で放置せず、Countモードでの検証やログ確認を継続することが、実効性のあるセキュリティにつながります。

まとめ

AWS WAFは、Webアプリケーションを狙う攻撃を防ぐAWSのマネージドWAFです。最後に要点を整理します。

AWS WAFとは：SQLインジェクション・XSS・悪意のあるBotなど、アプリケーション層（L7）の攻撃を検査・遮断するクラウド型WAF
仕組み：「Web ACL（入れ物）→ ルール（検査条件）→ アクション（Allow/Block/Count/CAPTCHA/Challenge）」の3層構造
設置場所：CloudFront・ALB・API Gatewayなどに関連付けて使う（単体では動かない）
運用のコツ：いきなりBlockにせず、まずCountで検証。ログを見て誤検知を調整しながら育てる
Shieldとの違い：WAFはアプリ層攻撃、ShieldはDDoS対策。Shield Standardは無料で自動適用済み

「入れれば安全」ではなく、ログを見て育てるセキュリティであること。これがAWS WAFを実務で活かす最大のポイントです。導入自体は難しくありませんが、運用まで見据えて設計することで、はじめて本当の守りになります。