AWSのファイアウォールはどれを選ぶ？セキュリティグループ、WAF、AWS Network Firewallの役割と使い分けを解説

クラウド環境の利用が急速に拡大する中で、AWS（Amazon Web Services）上においても、ネットワーク侵入や情報漏えいなどのセキュリティ脅威が年々高度化しています。

こうした状況に対応するためには、単一の防御ではなく多層的なファイアウォール設計が不可欠です。AWSでは「セキュリティグループ」「ネットワークACL（Access Control List）」「WAF（Web Application Firewall）」「Network Firewall」など複数の防御サービスが提供されており、それぞれが異なるレイヤーで通信を制御・可視化します。

本記事では、これらの各サービスの役割を整理し、どのような場面で使い分けるべきかを解説します。

人手不足解消・業務効率化・コスト削減を叶える！今から始めるAWS完全ガイド

AWSで利用できるファイアウォールサービスとは
セキュリティグループとネットワークACLの違い
AWS WAFとAWS Network Firewallの機能と使い分け
ファイアウォール設計と運用のベストプラクティス
- セキュリティレイヤごとの最適な構成設計
- ログ監視・可視化による継続的な運用改善
まとめ

AWSで利用できるファイアウォールサービスとは

ここでは、代表的なファイアウォールサービスとそれぞれの役割を説明していきます。

クラウド環境におけるセキュリティ対策の重要性

クラウドサービスの利用拡大とともに、インターネット経由のアクセス、マルチアカウント環境、第三者接続など、攻撃対象や経路が多様化しています。このような環境では、従来のオンプレミス網だけで済ませていたセキュリティ対策ではカバーしきれないリスクが顕在化します。

例えば、クラウド基盤を運用するにあたって、サービス提供者と利用者でセキュリティ上の責任分担を行う「責任共有モデル」が存在し、利用者側が設定・運用を担う部分での防御が必須です。

クラウドではまた、ネットワーク構成やリソースの改変が動的に行われるため、防御の抜け穴が生まれやすく、運用ミスや設定漏れが情報漏えいや侵入につながるケースも増えています。

こうした背景から、クラウド環境では「境界を守る」「内部を監視する」という複数の層にわたる防御姿勢を持つことが重要であり、AWSを利用する際にも主体的なセキュリティ設計が必要です。

AWSにおけるファイアウォールの基本的な考え方

AWS環境においてファイアウォールを設計する際には、まず「どのレイヤーを、誰が、どう守るか」を構築時点で明確にすることが重要です。

AWSでは、インフラ基盤の提供者（AWS）と利用者（ユーザー）がそれぞれ守る範囲を役割分担しており、利用者はネットワーク設定、アクセス制御、監視・ログ取得などを担います。

この責任共有モデルを踏まえて、防御を「ネットワーク層（VPC内通信やインターネット接続）」「ホスト・インスタンス層」「アプリケーション層（Webアプリケーション等）」という複数のレイヤーに分けて対策を講じることが有効です。

AWSに必要なセキュリティ対策とは？ AWSの責任共有モデルの解説 | TOKAIコミュニケーションズ AWSソリューション

例えば、VPC間通信やインターネットへの接続口を制御する仕組み、インスタンスごとの通信制御、Webアプリケーション固有の攻撃を防ぐ仕組みなどを重ねて設計することで、単一の防御が破られても次のレイヤーでカバー可能となります。

AWSで利用できる代表的なファイアウォールサービス一覧

AWSが提供する主要なファイアウォールサービスには、それぞれ用途と適用範囲が異なります。

まず、セキュリティグループはインスタンス単位で通信の許可・拒否を設定できるステートフルな制御です。次に、ネットワークACLはサブネット単位での通信制御を担うステートレス型の防御策です。

さらに、AWS WAF（Web Application Firewall）はWebアプリケーションに対してHTTP／HTTPSレベルで不正リクエストをブロックするために用いられ、SQLインジェクションやXSSといったアプリケーション層の脅威に対応可能です。

最後に、AWS Network FirewallはVPC全体を対象にパケットレベル・プロトコルレベルでの深い検査やドメイン／プロトコル制御が可能で、ネットワークの入口・出口を守る役割を担います。これらを整理して理解することで、環境に応じてどのサービスをどこに配置すべきかを判断しやすくなります。

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

ここでは、「 Security Group（セキュリティグループ）」の特徴を詳しく解説し、次に「 Network ACL（ネットワークACL）」の仕組みを説明します。

項目	セキュリティグループ (Security Group)	ネットワークACL (NACL)
適用単位	インスタンス／ネットワークインターフェース単位	サブネット単位
ステート性	ステートフル（通信の応答も自動許可）	ステートレス（応答通信も別途許可が必要）
ルールの種類	許可ルールのみ（明示的な拒否ルールは設定不可）	許可・拒否ルール両方設定可能
適用順序・評価方法	全ルールを評価して許可可否を判定	ルール番号の昇順で評価され、最初にマッチしたルールで決定
デフォルト動作	インバウンド全拒否、アウトバウンド全許可が初期設定	デフォルトではインバウンド・アウトバウンド共に全許可（カスタムでは暗黙拒否）
主な用途・推奨場面	各インスタンスへのきめ細かな通信制御	サブネット全体に共通の通信制御をかけたい場合の補助防御
運用・管理観点	設定数が少ない小規模環境に適し、リソースごとの粒度で管理可能	複数インスタンスにまたがる一括制御や緊急遮断用途に有効

セキュリティグループ（Security Group）の特徴

「セキュリティグループ」は、インスタンス単位で適用される仮想ファイアウォールです。設定できるルールは「許可（Allow）」のみで、自動的に応答トラフィックも許可されるステートフル（stateful）な動作となっています。

例えば、インスタンスにポート 22（SSH）へのアクセスを許可するルールを作ると、そのインバウンド通信に対応するアウトバウンド通信も別途ルールを設定しなくとも戻り通信が通ります。

また、デフォルトのセキュリティグループでは「すべてのインバウンド通信を拒否」し、「すべてのアウトバウンド通信を許可する」設定になっており、利用者が必要な通信を明示して許可する構造です。

設定例として、Webサーバー用インスタンスに「インバウンドTCPポート80および443を0.0.0.0/0から許可」「アウトバウンドは任意設定」とすることで、外部HTTP/HTTPSアクセスを可能にしつつ、インスタンス単位で通信制御を維持できます。

このようにセキュリティグループは、リソースごとのきめ細かなアクセス制御に適しており、インスタンスを対象とした通信可否の最前線で活用されます。

ネットワークACL（NACL）の特徴

一方「ネットワークACL（Network ACL）」は、サブネット単位に適用されるアクセス制御リストで、サブネット内のすべてのインスタンスに自動的に影響を及ぼす仮想ファイアウォールです。

適用範囲がサブネットであるため、より広域な防御レイヤーとして機能します。主な特徴としては、以下のような点があります。

ステートレス（stateless）であるため、インバウンド通信を許可しても、その応答となるアウトバウンド通信を別途明示的に許可しなければ通りません。
「許可（Allow）」および「拒否（Deny）」の両方のルールが設定可能です。これにより、特定IPアドレスやプロトコルを明示的に遮断する制御が可能です。
ルールは番号付きで順序評価され、最も低い番号から順に処理されます。いずれのルールにもマッチしなければ最終的に拒否される「暗黙の拒否」が働きます。

例えば、サブネット内に配置した複数のインスタンスに共通の通信制限（インターネットへのアウトバウンドを制限など）をかけたい場合に、ネットワークACLを設定して広域に制御をかける運用が考えられます。

どちらを使うべき？効果的な使い分けのポイント

運用上のポイントとしては、まずはセキュリティグループをベースとして個々のリソースに対するアクセス制限を設定するのが効果的です。

さらに、必要に応じてネットワークACLを補助的に配置して「大域的なサブネットアクセス制御」「特定プロトコル／IPの遮断」などを実現する「多層防御」が有効です。実際、AWSのベストプラクティス資料でもこの2つを併用してDDoS耐性を高める手法が紹介されています。

また、構成を複雑化させ過ぎると運用負荷が高まるため、「デフォルト設定 → 必要最小限制限 →ログ／監視による改善」という段階的な導入も推奨されます。

AWS WAFとAWS Network Firewallの機能と使い分け

AWSには、アプリケーション層からネットワーク層までをカバーできる複数のファイアウォールサービスが存在します。ここでは、Webアプリケーションを守る「AWS WAF」と、VPC全体を保護する「AWS Network Firewall」のそれぞれの役割と機能を整理し、最後に両者を組み合わせた多層防御の考え方を解説します。

項目	AWS WAF	AWS Network Firewall
適用範囲	Webアプリケーション／API単位	VPC全体・サブネット単位
対象レイヤー	アプリケーション層（L7）	ネットワーク層〜トランスポート層（L3〜L7）
主な保護対象	SQLインジェクション、XSS、ボット攻撃など	不審なIP／ドメイン通信、マルウェア通信、VPC内部横展開
設定ルール	マネージドルール＋カスタムルール	ステートレス／ステートフルルール
導入ポイント	ALB、CloudFront、API Gateway等に統合	VPC Gateway EndpointやTransit Gateway経由で適用
特徴	Web攻撃に特化した高度なHTTP／HTTPS制御	VPC全体の脅威検知・トラフィック制御に対応
運用目的	外部公開アプリの防御	内部ネットワーク全体の監視・防御

AWS WAFで実現できるWebアプリケーション保護

AWS WAF（Web Application Firewall）は、アプリケーション層（OSI 第7層）で動作するマネージド型のファイアウォールです。

WebサイトやAPIに対して、悪意あるリクエストを検出・遮断する役割を持ちます。主にHTTP／HTTPS通信を対象とし、SQL インジェクションやクロスサイトスクリプティング（XSS）などの代表的な攻撃からWebアプリケーションを保護します。

WAFの大きな特徴は、AWSが提供する「マネージドルール（Managed Rules）」を活用できる点です。これにより、一般的な攻撃パターンを自動的に検知・防御でき、利用者は自社システムに合わせて追加ルールを柔軟に設定することも可能です。

AWS CloudFront、ALB（Application Load Balancer）、API Gatewayなどに簡単に統合できる点も実用的といえます。したがって、外部公開されるWebサービスやAPIを対象に、迅速かつ継続的に防御を更新したい場合に効果を発揮します。

AWS Network FirewallによるVPC全体の防御

AWS Network Firewallは、VPC（Virtual Private Cloud）全体のトラフィックを対象に通信制御を行うマネージド型ネットワークファイアウォールです。
従来のセキュリティグループやネットワークACLでは対応が難しかった「VPC内の横方向（East-West）通信」や「VPC外部との通信（North-South）」を詳細に可視化・制御できます。

このサービスは、ステートフル／ステートレス両方のルールを設定でき、パケットレベルでの深い検査やドメイン・プロトコル単位での通信制御が可能です。また、脅威インテリジェンスフィードを利用すれば、既知の悪性IPやドメインとの通信を自動的に遮断できます。

特に、マルチVPC構成や企業全体のハイブリッドクラウド環境など、ネットワーク構造が複雑な場合に有効で、セキュリティグループではカバーできない範囲の防御を提供します。

併用で強化する多層防御アーキテクチャ

AWS WAFとAWS Network Firewallは、適用レイヤーや対象が異なるため、併用することで多層的な防御（Defense in Depth）を実現できます。

WAFはアプリケーション層の攻撃防御を担当し、Network FirewallはVPC全体のトラフィック監視・制御を行うことで、異なる種類の脅威に対応します。例えば、WAFで外部からのWeb攻撃を防ぎ、Network FirewallでVPC内の異常通信や不審なアウトバウンドを検知・遮断する構成です。

このように組み合わせることで、従来のセキュリティグループやネットワークACLでは難しかった内部脅威の検知やゼロデイ攻撃への早期対応も可能になります。

ファイアウォール設計と運用のベストプラクティス

ここでは、まず「セキュリティレイヤごとの最適な構成設計」を説明し、その後「ログ監視・可視化による継続的な運用改善」の重要性を解説します。

セキュリティレイヤごとの最適な構成設計

クラウド環境で堅牢な防御体制を築くには、各ファイアウォールの役割を明確化し、レイヤごとに適切な構成を整えることが鍵です。

例えば、ネットワーク入口（インターネット⇔VPC）には「入口ファイアウォール」、VPC内部通信（サブネット⇔サブネット）には「内部ファイアウォール」、そしてインスタンスやアプリケーション単位には「インスタンス／アプリケーション防御」を割り当てるという設計が有効です。

入口で大量の未知攻撃をブロックし、内部に侵入された場合でもさらに横展開を防ぐという多層防御（Defense in Depth）のアプローチが、 AWS Network Firewall のベストプラクティスガイドでも推奨されています。

また、設計段階では次のようなポイントを押さえておくことが望ましいです。

各レイヤーで適用対象・粒度・制御方法を整理
役割毎に責任分担を明確化（例：ネットワークチーム／アプリケーションチーム）
ゼロトラストの考え方を反映し、信頼できる内部通信にも防御を敷く

これにより、単一の防壁が突破された際にも次の防御層が機能する、堅牢な構成が実現できます。

ログ監視・可視化による継続的な運用改善

防御設計を組んだあとでも、そのまま放置していては、変化する脅威や設定の退化に対応できません。ここで重要になるのが、運用時における「ログの取得・可視化・分析」です。

例えば、Amazon CloudWatch や VPC Flow Logs を活用すれば、トラフィックの傾向変化や異常通信をリアルタイムに把握できます。

実際の運用の中では、次の流れが効果的です。

日次／週次でファイアウォールの拒否／許可ログを確認し、意図しない通信がないか検査
異常な通信パターン（例：大量のアウトバウンド接続、未知のプロトコル）を抽出し、ルール改善に反映
定期的に設計時想定と実通信のギャップをレビューし、ルールの過剰／過少をチューニング

この「設計→実運用→改善」のサイクルを回すことで、防御性能を長期にわたって維持・強化することが可能です。

まとめ

クラウド環境を安全に運用するには、レイヤごとに最適なファイアウォールを配置し、継続的に監視・改善することが欠かせません。

AWSでは、外部攻撃対策に「WAF」、内部通信制御に「Network Firewall」、細かなアクセス制御に「セキュリティグループ」「ネットワークACL」を組み合わせることで多層防御を実現できます。

ただし、要件定義や運用設計には専門知識が必要です。AWS導入やセキュリティ設計に不安がある場合は、TOKAIコミュニケーションズのAWS導入支援サービスを活用することで、設計から運用までを一貫してサポートしてもらうことができ、安心してクラウド活用を進められます。まずはお気軽にご相談ください。

TOKAIコミュニケーションズ AWS導入支援

導入のお問い合わせはこちら

AWSやAmazon WorkSpacesの導入から接続回線、運用・保守まで何でもお任せください。

お問い合わせ