「セキュリティグループとNACLで十分だと思っていたのに、特定ドメインへの通信だけ遮断してほしい、という要件が出てきて困っている」――クラウド移行後のインフラエンジニアから、こういう相談をよく受けます。
AWS WAFはHTTP/HTTPSに特化したL7フィルタリングですが、DNS通信の制御やSMTP・FTPといった非HTTPトラフィックのフィルタリングはカバーしていません。そこで登場するのが AWS Network Firewall です。
この記事では、AWS Network Firewallの仕組みと、WAF・セキュリティグループとの役割分担、ステートフルルールの設計、IDS/IPS機能の活用方法を、オンプレのUTM/NGFWと比較しながら解説します。
AWS Network Firewallとは?(WAF・セキュリティグループとの違い)
オンプレ環境では、境界防御としてUTM(Unified Threat Management)やNGFW(Next Generation Firewall)を置いていたと思います。クラウドでは、その役割がいくつかのサービスに分散しています。
| サービス | 動作レイヤー | 主な役割 | オンプレ相当 |
|---|---|---|---|
| セキュリティグループ | L4(EC2単位) | インスタンスへの通信許可 | ホストベースファイアウォール |
| ネットワークACL | L3/L4(サブネット単位) | サブネット間のIP・ポートフィルタ | ルーターACL |
| AWS WAF | L7(HTTP/HTTPS) | SQLi・XSS・ボット対策 | WAFアプライアンス |
| AWS Network Firewall | L3~L7(全プロトコル) | ドメイン制御・IDS/IPS・プロトコル検査 | UTM / NGFW |
AWS Network Firewallの特徴は次の3点です。
・ステートフル検査: TCP/UDPセッションを追跡し、戻り通信を自動で許可します(オンプレNGFWと同じ考え方)
・ドメインリスト制御: DNS SNI・HTTPホストヘッダーを使って「example.com」への通信だけ許可・拒否が可能
・Suricataルール互換のIDS/IPS: オープンソースのSuricataルール構文をそのまま使えるため、既存の脅威インテリジェンスを流用できます
AWS Network Firewallのアーキテクチャ(どこに置くか)
1. ファイアウォールエンドポイントの配置
AWS Network Firewallは、VPC内に ファイアウォールエンドポイント(インターフェースエンドポイント)を作成し、そこにトラフィックを引き込む仕組みです。オンプレのインラインUTMと同じ発想です。
代表的な構成は「ファイアウォール専用サブネット」を各AZに配置するパターンです。
# 代表的な構成イメージ Internet Gateway ↓ ファイアウォールサブネット(AZ-a) ← AWS Network Firewall エンドポイント ↓ パブリックサブネット(ALB / NAT Gateway) ↓ プライベートサブネット(EC2 / RDS)
ルートテーブルを操作してインターネット方向のトラフィックをエンドポイント経由に通します。これを 「Ingress Routing」 と呼び、VPCのルートテーブル設定で実現します。
2. ステートレスルール vs ステートフルルール
AWS Network Firewallには、処理レイヤーが異なる2種類のルールがあります。
・ステートレスルール: パケット単体を判断(オンプレのACLに相当)。IPアドレスとポートで許可・拒否・ステートフルルールへ転送を決める
・ステートフルルール: TCPセッションを追跡し、ドメイン名・プロトコル・Suricataシグネチャで判断。実務ではほぼこちらがメイン
現場での使い分けとしては、ステートレスルールで「明らかに不要なプロトコル(例:SMB/445)を先に落とす」→ ステートフルルールで「許可するドメインリストを管理する」という2段構えが定番です。
3. IDS/IPS機能(Suricataルール互換)
AWS Network Firewallのステートフルルールエンジンは、SuricataのIDS/IPSルール構文に完全対応しています。たとえば、既知のC2(コマンド&コントロール)サーバーへの通信を検知・遮断するルールをそのまま持ち込めます。
# Suricataルール例(既知マルウェアC2へのDNS通信を遮断) drop dns $HOME_NET any -> any 53 (msg:"ET MALWARE Known C2 Domain"; dns.query; content:"malicious-domain.com"; nocase; sid:1000001; rev:1;)
AWS Managed Threat Signaturesと呼ばれるAWS管理の脅威シグネチャも利用でき、独自ルールと組み合わせて使えます。
AWS Network Firewallの設定手順
1. ファイアウォールの作成
AWSコンソール →「VPC」→「ネットワークファイアウォール」→「ファイアウォールの作成」で進みます。作成時に指定するのは以下の項目です。
・名前: 任意(例: production-firewall)
・VPC: 保護対象のVPCを選択
・サブネット: ファイアウォール専用サブネットを各AZから1つずつ指定
・ファイアウォールポリシー: 新規作成 or 既存ポリシーを選択
2. ルールグループの定義
ファイアウォールポリシーに「ルールグループ」をアタッチします。ルールグループは「ドメインリスト」「標準ステートフルルール」「Suricataルール」の3形式に対応しています。
ドメインリストによる制御(許可リスト方式)は、最もシンプルで実務でよく使われます。
# AWS CLI でドメインリスト型ルールグループを作成する例 aws network-firewall create-rule-group --rule-group-name "allow-domain-list" --type STATEFUL --capacity 100 --rules-source '{ "RulesSourceList": { "Targets": [".amazonaws.com", ".github.com", ".ubuntu.com"], "TargetTypes": ["HTTP_HOST", "TLS_SNI"], "GeneratedRulesType": "ALLOWLIST" } }'
3. ルートテーブルの更新(Ingress Routing設定)
エンドポイントを作成しただけではトラフィックは通りません。インターネットゲートウェイのルートテーブルと、パブリックサブネットのルートテーブル両方を変更する必要があります。
・IGWのIngress Routeテーブル: パブリックサブネットのCIDR → ファイアウォールエンドポイントへ
・パブリックサブネットのルートテーブル: 0.0.0.0/0 → ファイアウォールエンドポイントへ(IGWの代わりにFWEPを経由させる)
この設定を間違えると通信が全断するため、本番環境では必ずステージング環境で検証してから適用してください。
料金の仕組み(コスト感覚)
AWS Network Firewallの料金は、2026年6月時点(東京リージョン ap-northeast-1)で以下のとおりです。
| 課金項目 | 単価 |
|---|---|
| ファイアウォールエンドポイント(AZごと) | $0.395/時間 |
| 検査トラフィック | $0.065/GB |
AZごとにエンドポイントが必要な点が重要です。マルチAZ構成(2AZ)で常時稼働した場合、エンドポイントだけで月額約$570(2AZ × $0.395 × 24時間 × 30日)かかります。
トラフィックが少ない検証環境では、単一AZで起動してコストを抑えるのが現実的です。本番環境では高可用性のためにマルチAZ配置が必須です。
応用・実務Tips
現場でAWS Network Firewallを運用していると、いくつかの定番パターンに行き着きます。
・許可リスト(Allowlist)方式でゼロトラストを実現: デフォルト拒否 + 明示的な許可ドメインリストの組み合わせが最もセキュアです。「とりあえず全通し」から始めると後で絞り込みが大変なので、最初から絞る設計を推奨します
・Amazon CloudWatch Logsとの連携: ファイアウォールのフローログと警告ログをCloudWatch Logsに送り、異常通信のアラートを設定します
・AWS Firewall Managerとの組み合わせ: AWS Organizationsでマルチアカウント環境を運用している場合、AWS Firewall Managerを使うと全アカウントに同一ポリシーを一元適用できます
・段階的導入(モニタリングモード): 最初はActionを「PASS」で設定してアクセスログだけ取り、何が通っているか把握してから「DROP」に切り替える方法が安全です
Linuxサーバーの通信制御(iptables・nftables)の経験がある方は、ステートフルルールの概念はすんなり理解できると思います。Linuxネットワーク設定の基礎については、姉妹サイトLinuxMaster.JPで詳しく解説しています。
よくあるトラブルと対処法
・設定後に通信が全断した: ルートテーブルの向き先が誤っている可能性が高いです。IGWのIngress RouteとパブリックサブネットのルートテーブルをFWEP経由に変更したか確認してください
・ドメインリストで許可したのに通信が通らない: HTTPSの場合はSNIを、HTTPの場合はHostヘッダーを使います。サブドメインまで許可したい場合は「.amazonaws.com」(先頭にドット)の形式で指定します
・Suricataルールが期待通りに動かない: ステートフルルールの評価順序と、デフォルトアクション(DROP / ALERT)の設定を確認します。ALERT設定でログに出力されているかを先に確認するのが定石です
・コストが予想より高い: AZごとのエンドポイント料金を見落としているケースが多いです。また、検査トラフィックにはNAT Gatewayを通るアウトバウンド通信も含まれます
本記事のまとめ
| やりたいこと | 使うサービス | オンプレ相当 |
|---|---|---|
| EC2単位の通信制御(ポート・IP) | セキュリティグループ | ホストFW |
| HTTPSのSQLi・ボット対策 | AWS WAF | WAFアプライアンス |
| VPC境界でのドメイン制御・IDS/IPS | AWS Network Firewall | UTM / NGFW |
| DDoS緩和 | AWS Shield | Anti-DDoS機器 |
AWS Network Firewallは「セキュリティグループとWAFだけでは届かない部分」を担うサービスです。特にドメインレベルの通信制御とIDS/IPS機能は、オンプレのUTM/NGFWに近い感覚で使えます。料金はエンドポイント固定費が高めなので、本番環境でのマルチAZ配置コストを事前に試算してから導入を決めましょう。
VPC境界のセキュリティ設計、どこまで考えていますか?
クラウド実務に役立つ「Cloud Security」カテゴリの記事を他にもまとめています。あわせて読みたい関連記事はこちらからどうぞ。
