【初心者向け】AWS WAFとは？仕組み・料金・設定手順をわかりやすく解説

自社のWebサイトやアプリケーションを、巧妙化するサイバー攻撃から守りたいけれど、何から手をつければ良いか分からない、とお悩みではありませんか。そんな課題を解決するのが、AWSが提供する「AWS WAF」です。AWS WAFは、SQLインジェクションやクロスサイトスクリプティングといった一般的な攻撃からWebアプリケーションを保護する、強力かつ柔軟なWebアプリケーションファイアウォールです。しかし、専門用語が多く、仕組みや料金が分かりにくいと感じる方も少なくありません。本記事では、AWS WAFとは何かという基本的な概要から、仕組み、料金体系、具体的な設定手順、他のセキュリティサービスとの違いまで、初心者の方にも分かりやすく徹底的に解説します。

この記事で分かること

AWS WAFの基本的な仕組みと、他のセキュリティサービスとの違い
SQLインジェクションなど、WAFで防御できる代表的なサイバー攻撃
Web ACLやマネージドルールなど、具体的な設定方法と手順
3つの要素からなる料金体系とコストを最適化するポイント

この記事を最後まで読めば、AWS WAFの全体像を掴み、自社の環境に合わせて導入を検討し、Webアプリケーションのセキュリティを効果的に強化するための第一歩を踏み出せます。

AWS WAFとは Webアプリケーションを守る盾

インターネットがビジネスに不可欠となった現代、WebサイトやWeb APIといったWebアプリケーションは常にサイバー攻撃の脅威に晒されています。個人情報の漏洩やサービスの停止といった被害は、企業の信頼を大きく損なう可能性があります。このような脅威からWebアプリケーションを保護するために重要な役割を担うのがWAF（Web Application Firewall）です。

この章では、AWSが提供するクラウド型のWAFサービスである「AWS WAF」について、その基本的な概要と役割を初心者にもわかりやすく解説します。

AWS WAFの概要と役割

AWS WAFは、Amazon Web Services（AWS）が提供する、Webアプリケーションをサイバー攻撃から保護するためのセキュリティサービスです。 WAFは「Web Application Firewall」の略で、その名の通りWebアプリケーションに特化したファイアウォールとして機能します。具体的には、WebアプリケーションへのHTTP/HTTPSリクエストの内容を監視し、SQLインジェクションやクロスサイトスクリプティング（XSS）といった悪意のある攻撃パターンを検出・遮断します。

従来のファイアウォールがネットワークの比較的低い層（レイヤー3/4）でIPアドレスやポート番号に基づいて通信を制御するのに対し、WAFはアプリケーション層（レイヤー7）で通信の中身を詳細に解析する点が大きな違いです。これにより、通常の通信を装った巧妙な攻撃からもアプリケーションを保護することが可能になります。

AWS WAFは、Amazon CloudFront、Application Load Balancer (ALB)、Amazon API GatewayなどのAWSサービスと連携して動作し、これらのサービスを通過するトラフィックをリアルタイムでフィルタリングします。クラウドサービスであるため、専用のハードウェアを用意する必要がなく、初期投資を抑えながら迅速に導入できるというメリットもあります。

以下の表は、AWS WAFと、AWSで利用される他の代表的なセキュリティ機能である「セキュリティグループ」「ネットワークACL」との違いをまとめたものです。

機能	保護対象の階層（OSI参照モデル）	保護対象のリソース	主な役割	ステート
AWS WAF	アプリケーション層（レイヤー7）	CloudFront, ALB, API Gatewayなど	SQLインジェクション、XSSなどWebアプリケーションへの攻撃を防御	-
セキュリティグループ	トランスポート層（レイヤー4）	EC2インスタンス, RDSなど	インスタンス単位でのトラフィック制御（IPアドレス、ポート番号）	ステートフル
ネットワークACL	ネットワーク層（レイヤー3）/ トランスポート層（レイヤー4）	サブネット	サブネット単位でのトラフィック制御（IPアドレス、ポート番号）	ステートレス

このように、それぞれのセキュリティ機能は保護する階層や対象が異なります。AWS WAFは、他のセキュリティ機能と組み合わせることで、より多層的で堅牢なセキュリティを実現するための重要なコンポーネントと言えるでしょう。

AWS WAFで防御できる代表的なサイバー攻撃

AWS WAFは、Webアプリケーションの脆弱性を悪用する様々なサイバー攻撃からシステムを保護します。特に、独立行政法人情報処理推進機構（IPA）が公開している「情報セキュリティ10大脅威」や、Webアプリケーションのセキュリティに関する国際的なコミュニティであるOWASPが提唱する「OWASP Top 10」に含まれる多くの脅威に対応することが可能です。ここでは、AWS WAFが防御できる代表的なサイバー攻撃について解説します。

SQLインジェクション

SQLインジェクションは、Webアプリケーションが想定していない不正なSQL文を注入（インジェクション）し、データベースを不正に操作する攻撃です。攻撃者は、Webサイトの入力フォームやURLのパラメータに悪意のあるSQLコマンドを紛れ込ませることで、データベースに直接アクセスしようと試みます。

この攻撃が成功すると、データベース内に保存されている個人情報や決済情報などの機密情報が窃取されたり、データが改ざん・削除されたりする可能性があります。最悪の場合、Webサイトが乗っ取られ、不正なページに改ざんされるといった甚大な被害につながる恐れがあります。

AWS WAFは、HTTPリクエストに含まれる文字列を検査し、SQLインジェクション特有の悪意のあるSQLパターンを検知してブロックします。これにより、不正なクエリがデータベースに到達するのを未然に防ぎ、情報漏洩やデータ改ざんのリスクを大幅に低減させることができます。

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

クロスサイトスクリプティング（XSS）は、Webページの脆弱性を利用して、悪意のあるスクリプトをユーザーのブラウザ上で実行させる攻撃です。攻撃者は、掲示板やコメント欄など、ユーザーが入力した内容が他のユーザーにも表示される機能に、不正なスクリプトを埋め込みます。そのページを閲覧した他のユーザーのブラウザでスクリプトが実行されてしまい、様々な被害を引き起こします。

具体的な被害としては、ユーザーのCookie情報が盗まれ、アカウントが乗っ取られる「セッションハイジャック」や、偽のログインページに誘導してIDやパスワードを窃取する「フィッシング詐欺」などが挙げられます。

AWS WAFは、リクエストに含まれるパラメータや本文などを検査し、クロスサイトスクリプティングで利用される典型的なスクリプトパターンを検知・ブロックします。これにより、ユーザーのブラウザ上で意図しないスクリプトが実行されるのを防ぎ、安全なWebサイトの閲覧環境を維持します。

悪意のあるBotからのアクセス

インターネット上には、検索エンジンのクローラーのような有益なBotだけでなく、様々な悪意を持ったBotが存在します。 AWS WAFは、これらの悪意のあるBotによる自動化された攻撃からWebサイトを保護する上で非常に効果的です。

悪意のあるBotによる攻撃には、以下のような種類があります。

攻撃の種類	概要と被害
Webスクレイピング	Webサイトのコンテンツや価格情報などを自動的に収集する行為。競合他社による情報収集や、コンテンツの不正利用につながります。
ブルートフォース攻撃（総当たり攻撃）	ログインページに対して、考えられる全てのパスワードの組み合わせを機械的に試行し、不正ログインを試みる攻撃。
リスト型攻撃	他のサービスから漏洩したIDとパスワードのリストを利用して、不正ログインを試みる攻撃。多くのユーザーがパスワードを使い回しているため、成功率が高い傾向にあります。
DDoS攻撃	複数のコンピュータから大量のアクセスを送りつけ、サーバーやネットワークに過剰な負荷をかけてサービスを停止に追い込む攻撃です。

AWS WAFは、これらのBotからの攻撃に対して多角的な防御を提供します。短時間に大量のリクエストを送信してくるIPアドレスを自動的にブロックする「レートベースのルール」や、AWSの脅威インテリジェンスを活用して悪意のあるBotを特定・ブロックするマネージドルール「AWS WAF Bot Control」などを利用することで、Webサイトの可用性を維持し、不正アクセスを防ぎます。

AWS WAFを導入する4つのメリット

AWS WAFは、Webアプリケーションのセキュリティを強化するための強力なツールです。導入することで、主に4つの大きなメリットを享受できます。ここでは、それぞれのメリットについて詳しく解説します。

メリット1：多様なサイバー攻撃からWebアプリケーションを保護

AWS WAFを導入する最大のメリットは、Webアプリケーションを堅牢に保護できることです。SQLインジェクションやクロスサイトスクリプティング（XSS）といった、アプリケーションの脆弱性を悪用する代表的な攻撃を検知し、ブロックします。これにより、個人情報の漏洩やWebサイトの改ざんといった深刻な被害を未然に防ぐことが可能です。

また、AWSやセキュリティベンダーが提供する「マネージドルール」を利用すれば、専門的な知識がなくても、最新の脅威に対応したセキュリティ対策を迅速に実現できます。例えば、WordPressなど特定のアプリケーションを狙った攻撃に特化したルールセットもあり、自社の環境に合わせて柔軟に防御レベルを高めることが可能です。

メリット2：初期費用を抑え、低コストで運用可能

従来のハードウェア型WAFは、高価な専用機器の購入が必要で、導入には多額の初期投資が伴いました。しかし、AWS WAFはクラウド型のサービスであり、ハードウェアの購入が不要なため、初期費用を大幅に抑えることができます。

料金体系は、作成したWeb ACL（ルール群）の数、ルールの数、そして受け取ったリクエスト数に基づく完全従量課金制です。そのため、スモールスタートで始め、ビジネスの成長に合わせてスケールさせることができ、無駄なコストが発生しにくいのが大きな魅力です。

比較項目	AWS WAF（クラウド型）	従来のハードウェア型WAF
初期費用	不要（月額料金のみ）	高額（専用機器の購入費）
運用コスト	従量課金制で変動	固定費（保守・メンテナンス費用）
導入スピード	数クリックで迅速に導入可能	機器の設置や設定に時間がかかる
スケーラビリティ	トラフィックの増減に自動で対応	機器の性能に依存し、拡張が困難

メリット3：数クリックで導入でき、管理・運用の手間を削減

AWS WAFは、AWSが提供する他のサービスとシームレスに連携できる点も大きなメリットです。 Amazon CloudFront、Application Load Balancer (ALB)、Amazon API Gatewayといった既存のAWSリソースに対して、AWSマネジメントコンソールから数クリックで簡単に有効化できます。複雑なネットワーク構成の変更や、新たなソフトウェアのインストールは一切不要です。

これにより、セキュリティ対策を強化するために要する時間と工数を最小限に抑えることができます。また、インフラのメンテナンスやアップデートはAWSが行うため、運用担当者は本来注力すべきアプリケーションのセキュリティ対策やルールのチューニングに集中することが可能です。

メリット4：トラフィックの増減に自動で対応する柔軟性

Webサイトへのアクセスは、キャンペーンやメディア掲載などによって突発的に急増することがあります。ハードウェア型のWAFでは、このような急激なトラフィックの増加に対応できず、サービス全体のパフォーマンス低下を招くボトルネックになる可能性がありました。

その点、AWS WAFはAWSの広大なインフラ上で稼働するため、トラフィックの増減に応じて自動的にスケールします。これにより、大規模なDDoS攻撃を受けた場合でも、安定した保護を提供し続けることが可能です。物理的な機器のキャパシティを気にする必要がなく、ビジネスの機会損失を防ぎます。

導入前に知っておきたいデメリットと注意点

AWS WAFはWebアプリケーションを保護する強力なサービスですが、導入してから「こんなはずではなかった」と後悔しないために、事前に把握しておくべきデメリットや注意点が存在します。ここでは、特に重要な4つのポイントを解説します。

専門知識と運用工数が必要になる

AWS WAFを効果的に活用するためには、導入して終わりではなく、継続的な運用が不可欠です。特に、以下の点において専門的な知識と対応工数が求められます。

ルールのチューニング: 初期設定のままでは、アプリケーションの仕様によって正常な通信をブロックしてしまう「誤検知（フォールスポジティブ）」や、逆に不正な通信を許可してしまう「検知漏れ（フォールスネガティブ）」が発生することがあります。アプリケーションの挙動を理解し、ログを分析しながらルールを最適化していく作業が必要です。
新規脆弱性への対応: 新たな脆弱性が発見された場合、それを悪用した攻撃を防ぐためのルールを迅速に追加・更新する必要があります。セキュリティに関する最新情報を常に収集し、対応し続ける体制が求められます。
ログの監視と分析: AWS WAFが出力するログを定期的に監視し、攻撃の傾向や予兆を分析することで、よりプロアクティブなセキュリティ対策が可能になります。

これらの運用を自社のリソースだけで行うのが難しい場合は、AWS WAFの運用を支援するサードパーティのサービスやマネージドルールを利用することも有効な選択肢となります。

コストが想定以上にかかる可能性がある

AWS WAFは初期費用がかからず、従量課金制のためスモールスタートしやすいのが魅力です。しかし、料金体系が複数の要素で構成されているため、アクセスの増減によってコストが変動し、想定以上になる可能性があります。

料金は主に以下の3つの要素で決まります。

課金要素	内容	料金の目安（東京リージョンの場合）
Web ACL数	作成したWeb ACL（ルールのセット）の数に応じた月額料金です。	$5.00/月
ルール数	Web ACLに追加したルールの数に応じた月額料金です。	$1.00/月
リクエスト数	WAFが処理したWebリクエストの数に応じた料金です。	$0.60/100万リクエスト

上記に加えて、AWS以外のベンダーが提供するマネージドルールを利用する場合は、別途月額利用料やリクエスト数に応じた追加料金が発生します。 DDoS攻撃やBotによる大量アクセスが発生した場合、リクエスト料金が急増する可能性があるため、導入前に自社サイトの平均的なリクエスト数を確認し、コストを試算しておくことが重要です。

誤検知（フォールスポジティブ）のリスク

誤検知とは、正常なユーザーからのアクセスを不正な攻撃と誤って判断し、ブロックしてしまう現象です。 これが発生すると、ユーザーはサービスを利用できなくなり、顧客満足度の低下やビジネス機会の損失に直結する可能性があります。

特に、厳格なセキュリティルールを適用した場合や、アプリケーションの特殊な通信がルールに抵触した場合に誤検知が発生しやすくなります。このリスクを低減するためには、以下の対策が有効です。

COUNTモードでの導入: 新しいルールを適用する際は、まず通信をブロックしない「COUNT（カウント）モード」で動作させます。
ログの分析: COUNTモードで収集したログを分析し、正常なアクセスがブロックされていないかを確認します。
ルールの除外設定: 誤検知が発生しているルールを特定し、特定のIPアドレスやURLパスをルールの対象から除外するなどのチューニングを行います。
BLOCKモードへの移行: 誤検知がないことを十分に確認した上で、ルールを「BLOCK（ブロック）モード」に切り替えます。

このように、段階的にルールを適用し、慎重にチューニングを行うことで、ビジネスへの影響を最小限に抑えながらセキュリティを強化できます。

すべての攻撃を防げるわけではない

AWS WAFは、SQLインジェクションやクロスサイトスクリプティング（XSS）といったWebアプリケーション層（OSI参照モデルの第7層）への攻撃に対して非常に有効です。しかし、WAFだけであらゆるサイバー攻撃を防げるわけではありません。

例えば、ネットワーク層やトランスポート層を狙った大規模なDDoS攻撃や、OS・ミドルウェアの脆弱性を突く攻撃など、WAFの守備範囲外の攻撃も存在します。

そのため、AWS WAFを導入するだけでなく、以下のような他のセキュリティサービスと組み合わせる「多層防御」の考え方が重要になります。

AWS Shield: DDoS攻撃に対するマネージド型の保護サービス。Standardは無料で利用でき、より高度な保護が必要な場合はAdvancedを選択します。
Amazon GuardDuty: AWSアカウントやワークロードに対する脅威を継続的にモニタリングする脅威検出サービス。
AWS Network Firewall: VPCレベルでネットワークトラフィックを制御するマネージド型ファイアウォールサービス。
脆弱性診断サービス: アプリケーション自体に潜む脆弱性を定期的にスキャンし、修正する。

AWS WAFはあくまでセキュリティ対策の一つと位置づけ、他のサービスと適切に組み合わせることで、より堅牢なセキュリティ体制を構築できます。

AWS WAFの仕組みとアーキテクチャ

AWS WAFは、Webアプリケーションをサイバー攻撃から保護するための重要なサービスです。その防御の仕組みを理解するためには、中核となるコンポーネントである「Web ACL」と「ルール」の役割、そしてそれらの関係性を把握することが不可欠です。

基本的なアーキテクチャとして、保護対象のリソース（Amazon CloudFront, Application Load Balancerなど）にWeb ACLを関連付けます。すると、そのリソースへのすべてのHTTP/HTTPSリクエストは、まずAWS WAFに送信され、Web ACLに定義されたルール群によって検査されます。検査結果に基づき、リクエストが許可されるか、ブロックされるかが決まるという流れになっています。

Web ACLとルールの関係性

AWS WAFの防御設定は、主に「Web ACL（ウェブアクセスコントロールリスト）」と、その中に含まれる「ルール」によって構成されます。これらは、Webアプリケーションの盾として機能するための設計図と具体的な指示のような関係にあります。

Web ACLは、AWS WAFを利用する上で最初に作成する、ルールの入れ物となる最も中心的なコンポーネントです。 保護したいAWSリソースに対してどのルールを適用するかを定義するリストであり、リクエストを検査するためのルール群と、どのルールにも一致しなかった場合のデフォルトアクション（ALLOWまたはBLOCK）で構成されます。リクエストが来ると、Web ACL内のルールが優先度の高い順に評価され、いずれかのルールに合致した時点で対応するアクション（許可、ブロックなど）が実行されます。

一方、ルールは、不正なアクセスのパターンを定義する具体的な検査基準です。 例えば、「特定のIPアドレスからのリクエスト」や「リクエスト本文にSQLインジェクションのパターンが含まれる」といった条件（ステートメント）と、その条件に一致した場合のアクション（BLOCK、ALLOW、COUNTなど）をセットで定義します。これらのルールを組み合わせることで、多様な攻撃に対応する精緻な防御策を構築できます。

Web ACL（Web Access Control List）: ルールをまとめるためのリスト。保護対象リソースと関連付けられる。
ルール（Rule）: アクセスを検査するための具体的な条件とアクションのセット。
デフォルトアクション（Default Action）: どのルールにも一致しなかったリクエストを許可（ALLOW）するか拒否（BLOCK）するかを決定する。

マネージドルールとカスタムルールの違い

AWS WAFのルールには、AWSやセキュリティベンダーが提供する「マネージドルール」と、ユーザーが独自に作成する「カスタムルール」の2種類が存在します。それぞれに特徴があり、目的に応じて使い分けることが効果的なセキュリティ対策につながります。

マネージドルール（Managed Rules）

マネージドルールは、AWSやマーケットプレイスで販売されているセキュリティ専門企業が作成・管理する、事前定義済みのルールセットです。 OWASP Top 10のような一般的な脆弱性に対応するルール群や、特定のアプリケーション（WordPressなど）を対象としたルール群などが提供されています。

最大のメリットは、セキュリティの専門知識がなくても、最新の脅威に対応した質の高い防御を迅速に導入できる点です。ルールは提供元によって自動的に更新されるため、新たな脅威にも追従できます。一方で、ルールの中身は公開されておらず、柔軟なカスタマイズが難しいという側面もあります。

カスタムルール（Custom Rules）

カスタムルールは、ユーザーが特定の要件に合わせて自由に作成できるルールです。例えば、「特定の国からのアクセスのみを許可する」「特定のキャンペーン用URL以外へのアクセスを制限する」といった、自社のアプリケーションやビジネスロジックに特化した独自のセキュリティポリシーを実現できます。

非常に柔軟性が高い反面、効果的なルールを作成・維持するためには、アプリケーションの仕様やセキュリティに関する深い知識が求められます。誤った設定は、正規のアクセスをブロックしてしまう「誤検知（フォールスポジティブ）」を引き起こす可能性もあるため、慎重な設計とテストが必要です。

これらの違いをまとめると、以下のようになります。

特徴	マネージドルール	カスタムルール
作成・管理者	AWS / セキュリティベンダー	ユーザー自身
専門知識	不要（ルールの選定知識は必要）	必要
導入の手軽さ	簡単・迅速	設計・テストに工数がかかる
カスタマイズ性	低い（一部カスタマイズ可能）	非常に高い
主な用途	一般的な脅威への広範な対策	アプリケーション固有の要件や特定の脅威への対策

多くの場合、まずはベースラインとしてマネージドルールを導入し、防ぎきれない特定の脅威やアプリケーション固有の要件に対してカスタムルールで補強するというハイブリッドなアプローチが推奨されます。

AWS WAFの保護対象サービス一覧

AWS WAFは、単体で機能するサービスではなく、他のAWSサービスと連携してWebアプリケーションを保護するファイアウォールです。 AWS WAFをアタッチ（関連付け）することで、悪意のあるサイバー攻撃からリソースを守る盾としての役割を果たします。ここでは、AWS WAFが保護できる主要なAWSサービスについて、それぞれの特徴と連携するメリットを詳しく解説します。

保護対象となる代表的なサービスは以下の通りです。

サービス名	概要	AWS WAFを適用する主なメリット
Amazon CloudFront	世界中にコンテンツを高速配信するCDNサービス	ユーザーに最も近いエッジロケーションで攻撃をブロックし、オリジンサーバーへの負荷を軽減。グローバルなDDoS攻撃にも有効。
Application Load Balancer (ALB)	アプリケーション層（レイヤー7）で機能するロードバランサー	VPC内のWebサーバー（EC2インスタンスやコンテナ）に到達する前の不正なトラフィックを検査・ブロック。
Amazon API Gateway	APIの作成、公開、管理を容易にするマネージドサービス	REST APIやHTTP APIを標的としたインジェクション攻撃や不正なリクエストから保護。サーバーレス構成のセキュリティを強化。
AWS AppSync	リアルタイムデータ連携を実現するマネージドGraphQLサービス	GraphQL特有の複雑なクエリを利用した攻撃からAPIを保護。

Amazon CloudFront

Amazon CloudFrontは、世界中に分散配置されたエッジサーバーからコンテンツを配信することで、Webサイトやアプリケーションの表示を高速化するCDN（コンテンツデリバリーネットワーク）サービスです。

AWS WAFをCloudFrontに適用する最大のメリットは、ユーザーに最も近いエッジロケーションで脅威をブロックできる点にあります。攻撃トラフィックがオリジンサーバー（Webサーバー本体）に到達する前に遮断されるため、サーバーの負荷を大幅に軽減し、アプリケーションのパフォーマンス低下を防ぎます。また、世界中に展開されたエッジネットワークを活用することで、大規模なDDoS攻撃に対しても高い防御性能を発揮します。

Application Load Balancer (ALB)

Application Load Balancer (ALB)は、HTTP/HTTPSといったアプリケーション層のトラフィックを、複数のターゲット（EC2インスタンス、コンテナ、IPアドレスなど）に自動的に分散するロードバランシングサービスです。

ALBにAWS WAFを適用すると、VPC（仮想プライベートクラウド）内の保護されたリソース群の手前で、すべてのトラフィックを検査できます。これにより、オリジンサーバーに到達する直前でSQLインジェクションやクロスサイトスクリプティングなどの攻撃をブロックし、内部リソースのセキュリティを強固に保つことが可能です。 CloudFrontを利用しない内部向けのアプリケーションなど、リージョン内で完結するシステムの保護に適しています。

Amazon API Gateway

Amazon API Gatewayは、あらゆる規模のAPIを作成、公開、維持、モニタリング、保護するためのフルマネージドサービスです。サーバーレスアプリケーションやマイクロサービスのバックエンドとして広く利用されています。

API GatewayにAWS WAFを統合することで、APIエンドポイントを直接保護できます。不正なデータ形式のリクエストや、APIの脆弱性を狙った攻撃をブロックし、バックエンドのLambda関数やその他のサービスを安全に保ちます。特に、外部に公開するAPIのセキュリティを確保する上で不可欠な連携と言えるでしょう。

AWS AppSync

AWS AppSyncは、GraphQL APIを簡単に開発できるマネージドサービスで、リアルタイムでのデータ同期やオフラインでのデータ操作を可能にします。

GraphQLは、クライアントが必要なデータを柔軟に要求できる強力なクエリ言語ですが、その柔軟性が悪用されるリスクも伴います。AWS WAFをAppSyncに適用することで、意図的に複雑なクエリを大量に送りつけてリソースを枯渇させるような攻撃からGraphQL APIを保護できます。これにより、リアルタイム性が求められるアプリケーションの可用性とセキュリティを両立させることが可能です。

AWS WAFの料金体系を詳しく解説

AWS WAFは初期費用が不要で、利用した分だけ料金が発生する従量課金制のサービスです。これからAWS WAFの導入を検討する方に向けて、具体的な料金の内訳と、コストを賢く抑えるためのポイントを詳しく解説します。

課金される3つの要素

AWS WAFの料金は、主に以下の3つの要素によって決まります。オプション機能（Bot Controlなど）を利用すると追加料金が発生しますが、基本となるのはこの3点です。料金の詳細はAWS WAFの料金ページで確認できます。

課金要素	料金（米ドル）	説明
Web ACL（ウェブアクセスコントロールリスト）	$5.00/月	Web ACLは、適用するルール群をまとめたものです。1つのWeb ACLを作成するごとに月額料金が発生します。料金は時間単位で按分計算されます。
ルール	$1.00/月/ルール	Web ACL内に作成したルールの数に応じて課金されます。これは、IPアドレスを制限するような自作のカスタムルールだけでなく、AWS Marketplaceで提供されているマネージドルールも対象です。
リクエスト数	$0.60/100万リクエスト	AWS WAFが検査したHTTP(S)リクエストの数に基づいて課金されます。 100万リクエスト単位での計算となります。

これらの基本要素に加え、特定の機能を利用する場合には追加料金が発生します。例えば、悪意のあるBotからのアクセスを制御する「AWS WAF Bot Control」や、不正なアカウント作成を防ぐ「Fraud Control」などの高度なマネージドルールは別途サブスクリプション料金とリクエスト数に応じた追加料金が必要です。

コストを最適化するためのポイント

AWS WAFの料金は柔軟ですが、トラフィック量や設定によっては想定以上のコストになる可能性もあります。ここでは、コストを最適化するための具体的なポイントを4つ紹介します。

ルールの優先順位を調整する
Web ACL内のルールは優先順位の高いものから順に評価されます。例えば、ブロックすることが確定しているIPアドレスからのアクセスを早い段階で遮断するルールを上位に設定すれば、後続の複雑なルール（WCU消費量が多いルール）による評価がスキップされ、処理コストの削減につながります。
必要なマネージドルールのみを適用する
AWSやサードパーティから提供されるマネージドルールは非常に便利ですが、多くのルールが含まれています。自社のアプリケーションの特性やリスクに合わせて、不要なルールグループやルール内の個別のルールを無効化することで、ルール数に応じた月額料金を削減できます。
Amazon CloudFrontを併用する
AWS WAFをAmazon CloudFrontと関連付けて利用する場合、CloudFrontのキャッシュから応答されたリクエストに対してはWAFの検査が実行されません。これにより、WAFが処理するリクエスト数が減少し、結果的にリクエスト料金の削減につながります。
サンプリングとログ記録を活用する
すべてのリクエストを検査するのではなく、一部をサンプリングしてログに記録・分析することで、攻撃の傾向を把握しつつコストを抑えることが可能です。本格的な防御ルールを適用する前に、まずはCOUNT（カウント）アクションでルールの動作をテストし、誤検知がないかを確認することも、不要な通信ブロックによる機会損失を防ぐ上で重要です。

AWS WAFの設定手順・準備すべきこと

AWS WAFの導入は、いくつかのステップに沿って進めることで、初心者の方でもスムーズに設定できます。この章では、AWS WAFを設定するために必要な準備から、基本的なルールの作成、そして運用のためのログ設定まで、一連の流れを分かりやすく解説します。

準備するものと前提条件

AWS WAFの設定を始める前に、以下の準備と前提条件を確認してください。これらを事前に整えておくことで、設定作業を円滑に進めることができます。

AWSアカウント: AWS WAFを利用するためのAWSアカウントが必要です。
保護対象のAWSリソース: AWS WAFで保護したいWebアプリケーションが稼働しているリソース（Amazon CloudFront、Application Load Balancerなど）がすでに構築されている必要があります。
IAM権限: AWS WAFの設定を行うIAMユーザーまたはロールには、AWSWAFV2FullAccessポリシーなど、WAFを操作するための適切な権限が付与されている必要があります。
保護対象リソースの情報: 設定時にリソースを特定するため、対象リソースのARN（Amazon Resource Name）や名前を控えておくとスムーズです。

Web ACLの作成とリソースへの関連付け

AWS WAFの核となるのが「Web ACL（ウェブアクセスコントロールリスト）」です。ここにルールを追加し、保護対象のリソースに関連付けることで、Webアプリケーションの保護が開始されます。まずは、このWeb ACLを作成し、保護したいリソースに紐付ける手順から始めましょう。

AWSマネジメントコンソールにサインインし、サービス検索で「WAF & Shield」を選択します。
AWS WAFのコンソール画面で、保護対象リソースがあるリージョンを選択します。ただし、Amazon CloudFrontを保護する場合は、リージョンを「Global (CloudFront)」に設定する必要があります。
左側のナビゲーションペインから「Web ACLs」を選択し、「Create web ACL」ボタンをクリックします。

「Describe web ACL and associate it to resources」の画面で、以下の項目を入力します。

項目	説明
Web ACL name	Web ACLを識別するための名前を入力します（例: my-application-waf-acl）。
Description - optional	（任意）Web ACLの説明を入力します。
CloudWatch metric name	Amazon CloudWatchで監視するためのメトリクス名です。Web ACL名と同じものが自動で入力されます。
Resource type	保護対象リソースの種類を選択します。「Regional resources」（ALB, API Gatewayなど）または「CloudFront distributions」のいずれかを選択します。

「Associated AWS resources - optional」セクションで「Add AWS resources」をクリックし、保護したいリソース（作成済みのALBなど）を選択して追加します。
設定が完了したら、画面下の「Next」をクリックして次のステップに進みます。

マネージドルールの適用方法

Web ACLを作成したら、次にルールを追加していきます。AWS WAFの大きな特長の一つが、AWSや専門のセキュリティベンダーが提供する「マネージドルール」です。これを利用することで、専門知識がなくても、既知の脆弱性に対する防御策を迅速に導入できます。

ここでは、代表的なAWS提供のマネージドルール「AWS Managed Rules Core rule set (CRS)」を適用する手順を解説します。

Web ACLの作成画面で、「Add rules and rule groups」のステップに進みます。
「Add rules」のドロップダウンから「Add managed rule groups」を選択します。
「AWS managed rule groups」セクションを展開し、利用したいルールグループを探します。例えば、「Core rule set」のトグルをオンにします。
ルールグループを追加すると、その中の個別のルールが表示されます。特定のルールを無効化したり、アクションを「Block」から「Count」に変更したりすることも可能です。最初は誤検知（正常な通信を誤ってブロックしてしまうこと）を避けるため、アクションを「Count」に設定して挙動を確認することをお勧めします。
設定後、「Add rules」ボタンをクリックし、Web ACLにルールを追加します。

IPアドレスでアクセスを制限するカスタムルールの作り方

特定のIPアドレスからのアクセスを許可または拒否したい場合、「カスタムルール」を作成します。例えば、社内ネットワークからのアクセスのみを許可したり、攻撃元と特定されたIPアドレスをブロックしたりする際に利用します。

まず、IPアドレスのリストである「IP set」を作成し、それを利用してルールを作成します。

IP setの作成

AWS WAFのコンソールで、左側のナビゲーションペインから「IP sets」を選択し、「Create IP set」をクリックします。
IP setの名前やリージョンを入力し、「IP addresses」の欄に制限したいIPアドレスをCIDR形式（例: 192.0.2.0/24）で入力します。
「Create IP set」をクリックして作成を完了します。

カスタムルールの作成と適用

Web ACLのルール追加画面に戻り、「Add rules」から「Add my own rules and rule groups」を選択します。
「Rule builder」を選択し、ルール名を入力します。
「If a request」で「matches the statement」を選択します。
Statementの詳細設定で、以下の通り設定します。
- Inspect: Originates from an IP address in
- IP set: 先ほど作成したIP setを選択します。
- IP address to use as the originating address: Source IP address
「Action」で、このルールに一致した場合の動作（Block, Allow, Countなど）を選択します。
「Add rule」ボタンをクリックして、カスタムルールをWeb ACLに追加します。

ログ設定とモニタリング方法

AWS WAFを運用する上で、どのようなリクエストがブロックされたのか、あるいは許可されたのかを記録・監視することは非常に重要です。ログを分析することで、攻撃の傾向を把握したり、誤検知の原因を調査したりできます。

ログの設定

AWS WAFのログは、Amazon S3バケット、Amazon CloudWatch Logs、Amazon Kinesis Data Firehoseのいずれかに出力できます。ここでは、一般的に利用されるS3バケットへの保存方法を説明します。

Web ACLの編集画面で、「Logging and metrics」タブを開きます。
「Logging」セクションで「Enable」をクリックします。
「Type」で「S3 bucket」を選択し、ログの保存先となるS3バケットを指定します。まだバケットがない場合は、表示される手順に従って新規作成できます。
設定を保存すると、Web ACLが検査したリクエストのログが、指定したS3バケットにJSON形式で出力されるようになります。

モニタリング方法

AWS WAFの動作状況は、Amazon CloudWatchでリアルタイムにモニタリングできます。Web ACLを作成すると、許可されたリクエスト数やブロックされたリクエスト数などのメトリクスが自動的にCloudWatchに送信されます。

CloudWatchのコンソールでは、これらのメトリクスをグラフで可視化したり、特定のルールが検知したリクエスト数を監視したりできます。また、急激なリクエスト数の増加やブロック数の増加を検知した場合にアラートを通知するように「CloudWatch Alarm」を設定することで、セキュリティインシデントへの迅速な対応が可能になります。

AWS WAFと他のセキュリティサービスとの比較

AWSは、クラウド環境を保護するために多様なセキュリティサービスを提供しています。それぞれのサービスが異なる役割と防御範囲を持っているため、特性を理解し、目的応じて適切に使い分けることが重要です。ここでは、AWS WAFと混同されやすい「AWS Shield」および「AWS Network Firewall」との違いを詳しく解説します。

AWS WAFとAWS Shield Standard/Advancedの違い

AWS WAFとAWS Shieldは、どちらもAWSリソースを外部の脅威から保護するサービスですが、その主な目的と防御対象となる攻撃の種類が異なります。 AWS WAFがWebアプリケーションの脆弱性を狙った攻撃（OSI参照モデルのレイヤー7）を防ぐのに対し、AWS Shieldは主にDDoS攻撃（レイヤー3、4）からの保護に特化しています。

AWS Shieldには、無料で自動的に適用される「Standard」と、より高度な保護機能を提供する有料の「Advanced」の2つのプランがあります。それぞれのサービスとの違いを以下の表にまとめました。

	AWS WAF	AWS Shield Standard	AWS Shield Advanced
主な目的	Webアプリケーションの脆弱性を悪用する攻撃からの保護	一般的なDDoS攻撃からの基本的な保護	大規模で高度なDDoS攻撃からの包括的な保護
防御対象レイヤー	レイヤー7（アプリケーション層）	レイヤー3（ネットワーク層）、レイヤー4（トランスポート層）	レイヤー3、4、7
防御できる主な攻撃	SQLインジェクション、クロスサイトスクリプティング（XSS）、悪意のあるBotなど	SYNフラッド、UDPリフレクションなどのインフラ層を狙ったDDoS攻撃	Standardの防御に加え、HTTPフラッドなどのアプリケーション層を狙ったDDoS攻撃や、より巧妙な攻撃
料金	有料（従量課金制）	無料（AWSの対象サービス利用時に自動適用）	有料（月額固定料金＋データ転送料金）
特徴	柔軟なカスタムルールを作成可能	追加設定不要で常時保護	24時間365日の専門家（SRT）によるサポート、DDoS攻撃による料金増のコスト保護

重要なのは、AWS WAFとAWS Shieldは競合するサービスではなく、相互に補完しあう関係にあるということです。 SQLインジェクションなどからアプリケーションロジックを守るためにAWS WAFを導入し、同時にDDoS攻撃によるサービス停止を防ぐためにAWS Shieldを有効化することで、多層的な防御が実現でき、セキュリティレベルを大幅に向上させることが可能です。

AWS WAFとAWS Network Firewallの違い

AWS WAFとAWS Network Firewallは、どちらもトラフィックをフィルタリングするファイアウォールサービスですが、保護する対象と設置場所が根本的に異なります。 AWS WAFがCloudFrontやALBといったWebトラフィックの入り口に設置され、HTTP/HTTPSリクエストの内容を検査するのに対し、AWS Network FirewallはVPC（Virtual Private Cloud）の境界に設置され、VPC内外を行き来するすべてのIPトラフィックを監視・制御します。

	AWS WAF	AWS Network Firewall
主な設置場所	Webトラフィックの入り口（CloudFront, ALB, API Gatewayなど）	VPCの境界（サブネット間、インターネットゲートウェイなど）
主な役割	Webアプリケーションの保護	VPCネットワーク全体のトラフィック検査とフィルタリング
検査対象レイヤー	レイヤー7（アプリケーション層）	レイヤー3〜7（ネットワーク層〜アプリケーション層）
検査対象プロトコル	HTTP, HTTPS	TCP, UDP, ICMP, HTTP, HTTPS, ドメイン名など広範囲
主なユースケース	Webサイトへのサイバー攻撃対策 APIエンドポイントの保護悪意のあるBotからのアクセス遮断	VPCからインターネットへの不正な通信のブロックオンプレミス環境との間の通信制御侵入検知・防止システム（IDS/IPS）としての利用

簡単に言えば、AWS WAFは「Webアプリケーションの用心棒」であり、SQLインジェクションのようなWeb特有の攻撃から守ります。一方、AWS Network Firewallは「VPC全体の関所」のような役割を担い、許可されていない通信がVPCに入ってきたり、VPC内から悪意のあるサイトへ通信したりするのを防ぎます。これらも排他的な関係ではなく、Webサーバーが稼働するVPCをNetwork Firewallで保護しつつ、その前段のALBにWAFを適用するといった組み合わせで、より堅牢なセキュリティを実現できます。

AWS WAFに関するよくある質問

ここでは、AWS WAFの利用を検討されている方から多く寄せられる質問とその回答をまとめました。サービスの導入や運用における疑問点を解消するための参考にしてください。

AWS WAFとAWS Shieldの違いは何ですか

AWS WAFとAWS Shieldは、どちらもAWSが提供するセキュリティサービスですが、保護対象となるレイヤー（OSI参照モデル）と防御できる攻撃の種類が異なります。 それぞれの役割を理解し、組み合わせて利用することで、より強固なセキュリティを実現できます。

AWS WAFはWebアプリケーションの脆弱性を狙った攻撃から保護し、AWS ShieldはDDoS攻撃からインフラを保護する役割を担います。

サービス名	保護対象レイヤー	主な防御対象の攻撃	主な特徴
AWS WAF	アプリケーション層（L7）	SQLインジェクション、クロスサイトスクリプティング（XSS）、悪意のあるBotなど	柔軟なカスタムルールを作成可能
AWS Shield Standard	ネットワーク層（L3）トランスポート層（L4）	SYNフラッド、UDPリフレクションなどの一般的なDDoS攻撃	追加料金なしで自動的に有効化
AWS Shield Advanced	ネットワーク層（L3）トランスポート層（L4）アプリケーション層（L7）	大規模で高度なDDoS攻撃	24時間365日の専門家サポート、DDoS攻撃によるコスト増の補填など

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

AWS WAFのマネージドルールを選ぶ際は、まずAWSが提供する「AWS Managed Rules」の利用を検討するのが基本です。 これにより、Webアプリケーションに対する一般的な脅威の多くに、迅速かつ容易に対処できます。

具体的な選び方のポイントは以下の通りです。

ベースラインの保護を確保する: まずは「Core rule set (CRS)」を適用しましょう。これは、OWASP Top 10にも挙げられるような、広く知られた脆弱性を悪用する攻撃パターンをブロックするための基本的なルールセットです。
アプリケーションの特性に合わせる: WordPressやPHP、SQLデータベースなど、お使いのプラットフォームに特化したルールグループを追加で適用します。これにより、特定のミドルウェアを標的とした攻撃への防御を強化できます。
特定の脅威に対応する: 悪意のあるBotによるアクセスを制御したい場合は「Bot Control」、不正なIPアドレスからのアクセスをブロックしたい場合は「Amazon IP reputation list」といった、特定の目的に特化したルールグループの利用を検討します。
サードパーティ製ルールを検討する: AWS Marketplaceでは、F5やImpervaといったセキュリティ専門ベンダーが提供する、より高度で専門的なマネージドルールも利用可能です。独自の脅威インテリジェンスに基づいたルールが必要な場合に選択肢となります。

なお、各ルールにはWCU（Web ACL Capacity Unit）というコストの目安が設定されています。Web ACLごとに利用できるWCUには上限があるため、必要な保護レベルとコストのバランスを考慮して選択することが重要です。

AWS WAFの料金を安く抑える方法はありますか

AWS WAFの料金は、主に「Web ACLの数」「ルールの数」「処理したリクエスト数」の3つの要素で決まります。コストを最適化するためには、これらの要素を意識した工夫が必要です。

Web ACLを共有する: 複数のリソース（CloudFrontディストリビューションやALBなど）で同じセキュリティポリシーを適用できる場合、1つのWeb ACLを共有することで、Web ACLごとの月額料金を削減できます。
不要なルールを見直す: 定期的にルールを見直し、不要になったカスタムルールや、効果の薄いマネージドルールグループを無効化または削除することで、ルールごとの月額料金を削減できます。
CloudFrontキャッシュを活用する: AWS WAFをAmazon CloudFrontと連携させている場合、キャッシュから応答されたリクエストはWAFの検査対象外となり、リクエスト料金が発生しません。キャッシュヒット率を高めることで、WAFのリクエスト料金を効果的に抑制できます。
AWS Shield Advancedに加入する: AWS Shield Advancedを利用すると、AWS WAFの料金が一部含まれるほか、DDoS攻撃によってスパイクした料金に対する補填を受けられる場合があります。大規模なDDoS攻撃のリスクが高いサービスでは、トータルコストを抑えられる可能性があります。

誤検知（フォールスポジティブ）が発生した場合はどうすれば良いですか

誤検知とは、正常なリクエストを悪意のあるものと誤って判断し、ブロックしてしまう現象です。誤検知が発生すると、ユーザーがサービスを正常に利用できなくなるため、迅速な対応が求められます。対応の基本的な流れは以下の通りです。

ログを分析して原因を特定する: まず、AWS WAFのログを分析し、どのリクエストが、どのルールによってブロックされたのかを特定します。ログから、誤検知の原因となったルールID（`terminatingRuleId`）や、リクエスト内のどの部分（`matchedData`）が検知されたかを確認します。
ルールのアクションを「COUNT」に変更する: 原因となったルールを特定したら、そのルールのアクションを「BLOCK」から「COUNT」に変更します。これにより、リクエストのブロックを停止しつつ、引き続き検知ログを収集して影響範囲を調査できます。
例外ルール（許可ルール）を作成する: 調査の結果、特定の通信パターンが安全であると確認できた場合は、その通信を明示的に許可するカスタムルールを作成します。例えば、特定のIPアドレスや、特定のURIパス、特定のヘッダーを持つリクエストを許可するルールを追加します。
ルールの優先度を調整する: 作成した例外ルールは、誤検知を引き起こしたルールよりも高い優先度（小さい数値）に設定する必要があります。 これにより、例外ルールが先に評価され、正常なリクエストがブロックされるのを防ぎます。

誤検知への対応は、セキュリティレベルを維持しつつ、ユーザビリティを損なわないための重要な運用作業です。定期的なログの監視とルールのチューニングを心がけましょう。

AWS WAFはどのような攻撃を防げますか

AWS WAFは、Webアプリケーションの脆弱性を悪用する多様な攻撃を防御できます。特に、独立行政法人情報処理推進機構（IPA）やOWASP（Open Web Application Security Project）が注意喚起している代表的な脅威に対して有効です。

インジェクション攻撃: SQLインジェクションやOSコマンドインジェクションなど、不正な文字列を注入してデータベースやサーバーを不正に操作する攻撃を防ぎます。
クロスサイトスクリプティング（XSS）: 悪意のあるスクリプトをWebページに埋め込み、ユーザーのブラウザ上で実行させる攻撃を防ぎます。
Broken Access Control（アクセス制御の不備）: URLやHTTPメソッドを操作して、権限のない情報や機能へアクセスしようとする攻撃を検知・ブロックします。
悪意のあるBotやスクレイピング: Webサイトのコンテンツを自動的に収集するスクレイピング行為や、脆弱性を探すスキャンツール、総当たり攻撃を試みるBotなどからのアクセスを制限します。
HTTPフラッド攻撃: アプリケーション層に対するDDoS攻撃の一種で、大量のHTTPリクエストを送りつけてサーバーのリソースを枯渇させる攻撃を、レートベースのルールで緩和します。
その他: ディレクトリトラバーサル、ファイルインクルージョン、クロスサイトリクエストフォージェリ（CSRF）など、OWASP Top 10で挙げられる多くの脆弱性を悪用した攻撃に対応しています。

これらの攻撃に対して、AWS Managed Rulesやカスタムルールを組み合わせることで、多層的な防御を実現できます。

まとめ

本記事では、AWS WAFの基本的な概要から、仕組み、料金体系、具体的な設定手順、そして他のAWSセキュリティサービスとの違いに至るまで、初心者の方にもご理解いただけるよう網羅的に解説しました。Webアプリケーションを取り巻く脅威が日々高度化する現代において、AWS WAFがいかに強力で、かつ手軽に導入できるセキュリティ対策であるかがお分かりいただけたかと思います。

この記事の重要なポイントを以下にまとめます。

AWS WAFの役割: SQLインジェクションやクロスサイトスクリプティング（XSS）など、OWASP Top 10に挙げられるような一般的なWebアプリケーションへの攻撃を検知・ブロックする「盾」の役割を果たします。
導入の容易さ: AWSが提供・管理する「マネージドルール」を利用することで、セキュリティの専門家でなくても、ベストプラクティスに基づいた堅牢な保護を迅速に適用できます。
柔軟な仕組みと料金: 保護ルールをまとめた「Web ACL」を、CloudFrontやALBなどのリソースに関連付けるだけで保護が開始されます。料金は利用した分だけ支払う従量課金制のため、コストを抑えながらスモールスタートが可能です。
高いカスタマイズ性: 特定の国からのアクセスを制限したり、特定のIPアドレスをブロックしたりする「カスタムルール」を柔軟に作成でき、ビジネス要件に合わせた独自のセキュリティポリシーを構築できます。

Webサイトやアプリケーションのセキュリティ対策は、もはや「いつかやるべきこと」ではなく、「今すぐやるべきこと」です。AWS WAFを活用すれば、これまでハードルが高いと感じていたWebセキュリティ対策の第一歩を、確実かつ効率的に踏み出すことができます。まずは、この記事で紹介した手順を参考に、テスト環境でマネージドルールを適用することから始めてみてはいかがでしょうか。安全なサービス運用のために、ぜひAWS WAFの導入をご検討ください。