EC2から外へ出る通信を「GitHubとAWSのAPIだけ」に絞りたい。宛先IPが変わり続けるため、セキュリティグループでは書けません。AWS Network Firewallは、こうしたドメイン単位の制御や侵入防止をVPCの経路上で引き受けるマネージド型のファイアウォールです。この記事では、ルートテーブルの書き換え方、ルールの役割分担、AWS CLIでドメイン許可リストを作る手順、東京リージョンの料金、セキュリティグループやWAFとの使い分けと見送る条件を整理します。単価と仕様は2026年9〜10月時点の公式情報です。
まとめ：AWS Network Firewallの要点と導入判断を先に押さえる
- AWS Network Firewallは、VPCを通るトラフィックをL3〜L7で検査するマネージドなステートフルファイアウォールで、可用性とスケーリングはAWS側が受け持つ。
- 専用のファイアウォールサブネットにエンドポイントを置き、ルートテーブルを書き換えて通信をそこへ通す構成をとる。
- ルールはステートレス（5タプルの高速判定）とステートフル（Suricata互換の検査・ドメイン制御）の2層で、既存Suricataルールを持ち込める。ただし一部キーワードは非対応。
- セキュリティグループやネットワークACLがインスタンス・サブネット単位の許可制御なのに対し、Network FirewallはVPC全体の集中防御と侵入防止を担う。L7のHTTP保護はWAFの領分で、両者は役割が別。
- 料金はエンドポイントの時間課金（東京で1AZ時間0.395ドル）とデータ処理（1GB0.065ドル）が主体。少数のVPCで単純な許可制御しか要らないなら、セキュリティグループで足りて見送りが妥当な場面もある。
AWS Network Firewallとは：VPCを守るマネージドなネットワーク防御
AWS Network Firewallの中核は、VPCという境界を通る東西・南北のトラフィックを一箇所で検査し、許可・遮断・警告を判断する点にあります。公式の開発者ガイドは、VPC向けのステートフルなマネージド型ネットワークファイアウォールおよび侵入検知・防止サービスと位置づけています。
セキュリティグループとネットワークACLでは書けない制御の範囲
セキュリティグループ（ENI単位）とネットワークACL（サブネット単位）は、送信元・宛先・ポートといった単純な条件しか書けず、通信の中身やドメイン名で止める制御はできません。
Network Firewallを挟むと、フローの状態を追ったうえで「このドメインへの通信だけ許す」「この攻撃シグネチャに一致したら破棄する」という判断が可能になります。これはIDS・IPSの考え方をVPCに持ち込んだもので、検知と防止の違いはIDS・IPSとは？違い・仕組み・種類とファイアウォール/WAFとの使い分けで整理しています。
アプライアンスの冗長化・パッチ運用を手放せる点とマネージド型の制約
ファイアウォールの実体はAWSがマネージドで運用し、トラフィック量に応じて自動でスケールするため、アプライアンスの冗長化やパッチ適用を自前で抱えずに済みます。その代わり、検査エンジンの細かな調整や独自プラグインの追加はできず、ルールの容量（キャパシティ）やポリシーあたりのルールグループ数にはクォータがかかります。
ファイアウォールサブネットとエンドポイントで通信を検査する構成
Network Firewallは、検査専用の小さなサブネットを各アベイラビリティーゾーンに1つ用意し、そこにファイアウォールエンドポイントを配置する構成をとります。実際のトラフィックがこのエンドポイントを必ず経由するように、ルートテーブルで経路を書き換える設定が必要です。公式のアーキテクチャ例には、単一VPC・NATゲートウェイ併用・Transit Gateway集約などの型がまとまっています。
IGW・NAT・ワークロードの4つのルートテーブルを書き換える手順
もっとも採用例が多いのは、インターネットゲートウェイとNATゲートウェイを併用する型です。外向き通信は「ワークロード→NAT→ファイアウォール→IGW」の順に流れ、戻りは逆順になります。1AZぶんの経路は次の4枚で表せます。
| ルートテーブル | 宛先 | ターゲット |
|---|---|---|
| ワークロードサブネット | 0.0.0.0/0 | NATゲートウェイ |
| NATサブネット | 0.0.0.0/0 | FWエンドポイント |
| ファイアウォールサブネット | 0.0.0.0/0 | インターネットGW |
| IGWエッジ関連付け | NATサブネットのCIDR | FWエンドポイント |
見落としやすいのは4枚目です。IGWにルートテーブルをエッジ関連付けしないと、戻り通信がファイアウォールを経由せずNATへ直行します。NATゲートウェイの役割そのものはAWS NATゲートウェイとは？役割とインターネットゲートウェイの違いで確認できます。
非対称ルーティングで検査が素通りする失敗パターンと複数AZ設計
経路制御を怠るとトラフィックがエンドポイントを素通りし、ルールを書いても何も検査されません。設計の勘所は、行きと帰りが同じエンドポイントを通る対称的な経路を確保することです。ステートフル検査は往復の両方が通って初めて成立します。
可用性のため、本番ではエンドポイントを複数AZに分散させ、各AZのサブネットが自ゾーンのエンドポイントを向くように設計します。エンドポイントはAZごとに課金対象となるため、この冗長化の粒度がそのまま費用に効いてきます。
Transit Gateway接続とセカンダリエンドポイントで検査点を集約する方式
複数VPCを持つ組織では、検査専用VPCを1つ作り、各VPCの通信をTransit Gateway経由でそこへ集める形が定石です。AWS CLIのcreate-firewallには、VPCとサブネットを指定する従来の引数に加えて--transit-gateway-idと--availability-zone-mappingsがあり、Transit Gatewayに直接アタッチする作り方も選べます。
もう1つの選択肢が、1つのファイアウォールを複数VPCへ関連付けるセカンダリエンドポイントを使う方式です。追加分は通常より安い別単価で、VPC数が少ないうちは構成も単純です。
ステートレスとステートフルのルールグループとSuricata互換ルール
ルールは2階層で構成し、ファイアウォールポリシーに束ねてファイアウォールへ割り当てます。
ステートレスで一次判定しステートフルへ転送する2段構成の流れ
最初に通るのがステートレスルールグループで、送信元・宛先IP、ポート、プロトコルの5タプルをパケット単位で高速に判定します。ここで即座に通す・破棄するを決め切れる通信を捌き、判断を保留した通信だけを次のステートフル検査へ渡すのが基本の流れです。次のステートフルルールグループは、通信フローの状態（接続の確立や方向）を踏まえた検査を行い、ここでSuricata互換のシグネチャやドメインリストが効きます。
| ルールグループ | 検査単位 | 主な用途 |
|---|---|---|
| ステートレス | パケット単位（5タプル） | 高速な許可・破棄の一次判定 |
| ステートフル | フロー単位（接続状態） | Suricata検査・ドメイン制御 |
実務ではステートレス側にルールをほとんど書かず、既定アクションをaws:forward_to_sfe（ステートフルへ転送）にして、判定をステートフル側へ寄せる構成が扱いやすいでしょう。ステートレスでpassした通信はステートフル検査を通らないため、両方に似たルールを書くと意図しない抜け道ができます。
ドメインリストでSNIとHostヘッダーを見て外向き通信を絞る仕組み
ステートフルルールの書き方は3通りあります。1つ目はドメインリストで、許可または拒否したい宛先ドメインを列挙する方式です。公式ドキュメントによれば、HTTPSではTLSハンドシェイクのSNI、HTTPではHostヘッダーから宛先名を取り出し、DNSの逆引きは行いません。先頭に.を付けた.example.comはサブドメインまで一致します。
SNIは送信側が自由に書ける値なので、偽装への備えが要るならIPベースのルールを併用します。また、検査対象は既定で「ファイアウォールを置いたVPCのCIDR」からの通信だけです。Transit Gatewayで他VPCの通信を集める場合は、ルールグループのHOME_NETに他VPCのCIDRを足さないとドメイン制御が効きません。2つ目は5タプルベースの標準ルール、3つ目がSuricata構文の生ルールです。
Suricata互換ルールで使えないキーワードと持ち込み時の確認点
Suricata構文の生ルールでは、Emerging Threatsなど既存のルールセットを取り込めます。ただし制約と注意点のページに、dataset・datarep、iprep、ファイル抽出、Luaスクリプト、しきい値指定（thresholding）、SCTPなどの非対応が列挙されています。指定できるアクションもpass・drop・reject・alertの4種だけです。
公式ドキュメントが参照するSuricataのユーザーガイドは、2026年10月時点で8.0.3系でした。構文の読み方はSuricataとは？導入からルール作成・IPSモード運用までにまとめています。SNIで特定ドメインを止める生ルールは次のとおりです。
drop tls $HOME_NET any -> $EXTERNAL_NET any (msg:"block example.com"; flow:to_server,established; tls.sni; content:"example.com"; endswith; nocase; sid:1000101; rev:1;)flow:to_server,establishedを付けないTCPルールは、SuricataがIPのみのルールとして扱い、各方向の最初のパケットしか評価しない点にも注意が要ります。
厳格な評価順序とDrop establishedを既定にする理由と注意点
ルールの評価順序は、アクション順（pass→drop→reject→alertの優先）と厳格順序（ルールグループの優先度と記述順）の2方式です。評価順序のページは厳格順序を推奨しています。厳格順序ではドメインの許可リストが「一致しない通信を拒否する」動きをしないため、既定アクションにaws:drop_establishedを選び、許可に一致しない確立済み通信を落とす構成にします。
判定アクションはpass（通過）、drop（破棄）、reject（破棄してTCPリセット）、alert（記録のみ）から選びます。まずはalertで実トラフィックを観測してからdropへ切り替えると、正規通信を巻き込む事故を避けられます。
AWS CLIでファイアウォールを作成しドメイン許可リストを試す手順
既存VPCで外向きHTTPSを許可ドメインだけに絞る最小手順です。ファイアウォールサブネットは作成済みとし、IDは自分の環境の値に置き換えてください。
許可ドメインのルールグループとファイアウォールポリシーを作る
まずドメイン許可リストのルールグループを作ります。create-rule-groupには容量（capacity）の指定が必須で、あとから増やせないため余裕を持たせます。
# allow-domains.json
{
"RuleVariables": { "IPSets": { "HOME_NET": { "Definition": ["10.0.0.0/16"] } } },
"RulesSource": {
"RulesSourceList": {
"Targets": [".amazonaws.com", "github.com", ".githubusercontent.com"],
"TargetTypes": ["TLS_SNI", "HTTP_HOST"],
"GeneratedRulesType": "ALLOWLIST"
}
},
"StatefulRuleOptions": { "RuleOrder": "STRICT_ORDER" }
}
aws network-firewall create-rule-group \
--rule-group-name allow-egress-domains --type STATEFUL --capacity 100 \
--rule-group file://allow-domains.json続いて、全件をステートフルへ転送し、許可に一致しない確立済み通信を落とすポリシーを作ります。
# policy.json
{
"StatelessDefaultActions": ["aws:forward_to_sfe"],
"StatelessFragmentDefaultActions": ["aws:forward_to_sfe"],
"StatefulEngineOptions": { "RuleOrder": "STRICT_ORDER" },
"StatefulDefaultActions": ["aws:drop_established", "aws:alert_established"],
"StatefulRuleGroupReferences": [
{ "ResourceArn": "arn:aws:network-firewall:ap-northeast-1:111122223333:stateful-rulegroup/allow-egress-domains", "Priority": 100 }
]
}
aws network-firewall create-firewall-policy \
--firewall-policy-name egress-policy --firewall-policy file://policy.jsonルールグループとポリシーのRuleOrderが食い違うと作成時にエラーになります。両方をSTRICT_ORDERで揃えてください。
ファイアウォール本体の作成とエンドポイントIDを経路へ反映する
ポリシーを指定してファイアウォールを作り、AZごとに払い出されたエンドポイントIDを取り出して、前掲のルートテーブルへ書き込みます。エンドポイントの準備には数分かかるため、状態がREADYになってから経路を切り替えます。
aws network-firewall create-firewall \
--firewall-name egress-fw --vpc-id vpc-0abc1234 \
--firewall-policy-arn arn:aws:network-firewall:ap-northeast-1:111122223333:firewall-policy/egress-policy \
--subnet-mappings SubnetId=subnet-0fw1a,IPAddressType=IPV4 SubnetId=subnet-0fw1c,IPAddressType=IPV4
# AZごとのエンドポイントIDを確認する
aws network-firewall describe-firewall --firewall-name egress-fw \
--query "FirewallStatus.SyncStates.*.Attachment.[SubnetId,EndpointId,Status]" --output table
# NATサブネットの既定ルートをファイアウォールエンドポイントへ向ける
aws ec2 replace-route --route-table-id rtb-0nat1a \
--destination-cidr-block 0.0.0.0/0 --vpc-endpoint-id vpce-0fw1aIGWのエッジ関連付けにも、NATサブネットのCIDR宛てのルートを足します。
アラートログをCloudWatch Logsへ送りalertからdropへ切り替える
ログ設定では、アラート・フロー・TLSの3種類のログを、S3、CloudWatch Logs、Data Firehoseへ送れます。種類ごとに同じ宛先も別の宛先も選べますが、記録されるのはステートフルエンジンへ転送した通信だけです。ステートレスでpassやdropを決めた通信はログに残りません。ここでは種類ごとにコマンドを分け、まずアラートログだけを有効にします。
aws network-firewall update-logging-configuration --firewall-name egress-fw \
--logging-configuration '{"LogDestinationConfigs":[{"LogType":"ALERT","LogDestinationType":"CloudWatchLogs","LogDestination":{"logGroup":"/anfw/egress-fw/alert"}}]}'運用開始直後は、既定アクションをaws:alert_establishedだけにして数日観測し、ログに出た正規の宛先を許可リストへ足してからaws:drop_establishedを加える順序が安全です。IPとポートの流れを広く眺めたいときは、VPC Flow Logsとの使い分けをNetwork Flow MonitorとVPC Flow Logsの使い分けで整理しています。
セキュリティグループ・ネットワークACL・WAFとの違いと使い分け
混同されやすい3つとの違いを、検査するレイヤーと適用範囲で整理します。無料の標準フィルターであるセキュリティグループとネットワークACLに対し、Network Firewallは有料の集中防御レイヤーという位置づけです。
| 機能 | 検査レイヤー | 適用範囲 |
|---|---|---|
| Network Firewall | L3〜L7 | VPC全体 |
| セキュリティグループ | L3・L4 | ENI（インスタンス） |
| ネットワークACL | L3・L4 | サブネット |
| WAF | L7（HTTP） | CloudFront・ALB |
WebアプリケーションのHTTPリクエストをSQLインジェクションやクロスサイトスクリプティングから守るのは、あくまでL7のWAFの役割です。ネットワーク層の攻撃遮断とWebアプリ保護は別レイヤーの防御であり、詳しくはWAFとは？仕組み・ファイアウォール／IPS・IDSとの違いで線引きを確認してください。ファイアウォールという概念そのものの種類や仕組みを押さえたい場合はファイアウォールとは？仕組み・種類とWAF・UTMとの違いが土台になります。なお、通信を止めるNetwork Firewallに対し、不審な振る舞いを検知して知らせる役割はAmazon GuardDutyが担い、両者は遮断と検知で補完し合う関係です。
AWS Network Firewallの料金：エンドポイント時間課金とデータ処理課金
課金は「ファイアウォールエンドポイントの稼働時間」と「エンドポイントを通過したデータ量」の2本立てが基本で、初期費用はありません。
東京リージョンの時間・データ処理単価とTLS検査・脅威防御の追加課金
次の表は、AWSのPrice List API（2026年9月11日公開版）から取得した東京リージョンの単価です。米国東部もエンドポイントとデータ処理は同額でした。見積もりの前に公式の料金ページで最新値を確かめてください。
| 課金対象 | 東京の単価 |
|---|---|
| ファイアウォールエンドポイント | 1AZ時間0.395ドル |
| データ処理 | 1GB0.065ドル |
| セカンダリエンドポイント | 時間0.158ドル |
| TLS検査エンドポイント | 時間1.095ドル |
| Active Threat Defense | 1GB0.005ドル |
TLSの中身まで検査するAdvanced Inspectionは、公式料金ページで「エンドポイント時間料金への追加」と説明されており、データ処理の追加はありません。旧版で載せた0.489ドルはアイルランドの例示で、東京はAPI上1.095ドルです。脅威インテリジェンスを使うActive Threat Defenseは、処理量あたりの課金が上乗せされます。
NATゲートウェイ料金の免除条件とAZ数・通過データ量に応じた月額の試算例
費用設計で効いてくるのは、エンドポイントがAZ単位の時間課金である点です。1つのエンドポイントを常時稼働させるだけで月およそ284ドル（0.395ドル×720時間）が積み上がり、2AZ冗長なら約569ドル、3AZならその3倍が固定費になります。ここに通過量ぶんが上乗せされ、月1,000GBなら65ドルの追加です。
一方、公式料金ページには、同じ経路上にNATゲートウェイを置く場合、エンドポイント1時間につきNATゲートウェイ1台ぶんの時間料金とデータ処理料金が免除されるという記載があります。前掲のIGW＋NAT構成はこの条件に当てはまるため、NATを先に使っている環境では実質の上乗せが見かけより小さくなります。
AWS Network Firewallを導入すべき条件と見送る判断の基準
導入を勧められるのは、次の条件が揃うときです。第一に、複数のサブネットやVPCをまたぐ通信を一箇所で検査し、外向き通信を許可ドメインだけに絞り込みたいこと。第二に、PCI DSSや社内規程でネットワーク層の侵入防止（IPS）とログ取得が求められること。第三に、Suricataの検知ルールを持ち込んで、セキュリティグループでは書けないシグネチャベースの遮断をかけたいことです。複数アカウント構成なら、Transit Gatewayで通信を集約し、その中央に検査VPCを置く設計が定石で、全体像はAWS Transit Gatewayとは｜仕組み・VPC Peeringとの違い・料金で確認できます。
一方で見送りが妥当な場面もはっきりしています。単一VPCで通信要件が単純なら、セキュリティグループとネットワークACLだけで足り、月数百ドルの固定費を払ってまでエンドポイントを常駐させる意味は薄いでしょう。外向き制御が「特定のIPだけ許可」で済むならNATゲートウェイとルート制御で代替できますし、守りたい対象がWebアプリのHTTP層に閉じるならWAFの導入が先です。また、非対応キーワードを多用する既存Suricataルールに依存している場合は、書き換えの工数を見積もってから判断します。VPC設計そのものから見直したい、あるいは自社の要件でNetwork Firewallが本当に要るのか切り分けたい段階なら、要件整理から構築・運用までAWSインフラ構築の支援サービスで相談し、過剰な防御レイヤーを抱え込む前に必要性を見極めるのが近道です。
よくある質問
AWS Network Firewallの検討時によく寄せられる質問を、2026年10月時点の公式情報をもとにまとめました。
AWS Network FirewallとセキュリティグループはどちらもFWですが何が違いますか？
セキュリティグループはENI単位で送信元・宛先とポートを許可する無料の基本フィルターで、通信の中身までは見ません。AWS Network FirewallはVPC全体を対象に、フローの状態やドメイン名、Suricataシグネチャで検査する有料の集中防御です。両者は排他ではなく、基本の許可制御をセキュリティグループが、侵入防止とドメイン制御をNetwork Firewallが担うよう重ねて使います。
AWS Network FirewallとWAFはどう使い分けますか？
WAFはCloudFrontやALBの手前でHTTPリクエストを検査し、SQLインジェクションなどWebアプリ層の攻撃を防ぐL7の防御です。Network Firewallはネットワーク層（L3〜L4中心、一部L7）でVPCを通る通信全般を検査します。守る対象がWebアプリのHTTPならWAF、VPCの通信全体や外向き制御ならNetwork Firewallと、レイヤーで切り分けます。
AWS Network Firewallの料金はどのくらいかかりますか？
2026年9月時点の東京リージョンで、ファイアウォールエンドポイントが1AZあたり時間0.395ドル、通過データが1GBあたり0.065ドルです。1エンドポイントの常時稼働で月およそ284ドルが固定費になり、AZを増やすとその分だけ増えます。TLS検査などは追加課金、同じ経路のNATゲートウェイ料金は免除という条件もあるため、公式の料金ページで確かめてください。
既存のSuricataルールはそのまま使えますか？
ステートフルルールグループはSuricata互換の構文に対応しており、Emerging Threatsのような既存ルールセットの多くは修正なしで動きます。ただしdatasetやiprep、Luaスクリプト、しきい値指定などは非対応で、アクションもpass・drop・reject・alertに限られます。まずはalertアクションで観測し、正規通信を巻き込まないと確認してからdropへ切り替える運用が安全です。
トラフィックがファイアウォールを通らないのはなぜですか？
ほとんどの原因はルートテーブルの設定漏れです。Network Firewallはエンドポイントを経由させて初めて検査するため、サブネットのルートテーブルとインターネットゲートウェイのエッジ関連付けの両方を、ファイアウォールエンドポイント向けに書き換える必要があります。行きと帰りで別の経路を通る非対称ルーティングになっていると検査が成立しないため、対称な経路を確保してください。
関連記事
- ファイアウォールとは？仕組み・種類とWAF・UTMとの違い：Network Firewallの土台となるファイアウォールの概念と種類を整理
- WAFとは？仕組み・ファイアウォール／IPS・IDSとの違い：L7のWeb保護とネットワーク層防御の線引き
- Suricataとは？導入からルール作成・IPSモード運用まで：Network Firewallのステートフル検査が互換とするエンジンの基礎
- Amazon GuardDuty：通信を遮断するNetwork Firewallと補完し合う脅威検出サービス
- AWS Transit Gatewayとは｜仕組み・VPC Peeringとの違い・料金：複数VPCの通信を集約して検査点を1箇所にまとめる設計
