こんにちは、佐野（マナティ）です！
突然ですが、AWS Network Firewallを導入した環境で、こんなふうに思っていないでしょうか。
「VPC内の通信を検査・制御できるようになった。EC2間の通信もすべてチェックされるし、これで安心！」
…そう思っていませんでしょうか？
一見すると正しそうですが、ここには見落としやすいポイントがあります。
実は、同一サブネット内のEC2同士の通信はNetwork Firewallを経由しません。
この仕様を知らないまま設計や試験を進めると、「Network Firewallで制御しているつもりが、実はSecurity Groupでしか制御されていなかった」ということが起こり得ます。
本記事では、なぜ同一サブネット内の通信がNetwork Firewallを通らないのか、通信制御の各層の役割、そして設計や試験で意識すべきポイントを整理したいと思います！
VPCのルートテーブルには、削除できない localルート（VPC CIDR → local）が存在します。
同一サブネット内のEC2同士の通信は、宛先IPがこのlocalルートに一致するため、VPC内部で直接ルーティングされます。Network Firewallのエンドポイントはルート上に存在しないので、経由しません。
一方、VPC外部への通信は 0.0.0.0/0 のデフォルトルートに一致し、そこにNetwork Firewallのエンドポイントが設定されていれば経由するようになっています。
■ 通信経路の違い
通信パターンによって、Network Firewallを経由するかどうかが変わります。
パターンA：異なるサブネット間（Network Firewall 経由）
異なるサブネットに配置されたEC2間の通信は、ルートテーブルの設定次第でNetwork Firewallを経由させることができます。この場合、Network Firewallのルールで通信が検査されます。
パターンB：同一サブネット内（local ルート直接）
同一サブネット内のEC2同士の通信は、localルートで処理されます。Network Firewallを経由しないため、通信制御は Security Groupのみで行われます。
パターンC：VPC Endpoint経由の通信
Amazon S3やAmazon DynamoDBへのGateway Endpoint経由の通信は、ルートテーブルのプレフィックスリストで直接ルーティングされます。これもNetwork Firewallは経由しません。
AWSの通信制御は、大きく3つの層で構成されています。
それぞれ適用される範囲が異なります。
|
通信パターン |
NW Firewall |
Security Group |
Network ACL |
|
同一サブネット内 EC2 ↔ EC2 |
- |
○ |
- |
|
異なるサブネット間 EC2 ↔ EC2 |
○ |
○ |
○ |
|
EC2 → インターネット |
○ |
○ |
○ |
|
EC2 → S3（Gateway Endpoint） |
- |
○ |
- |
ポイントは、同一サブネット内の通信はSecurity Groupでしか制御されない ということです。
同一サブネットに複数のEC2が配置されている場合、CIDR単位でSecurity Groupの送信元を指定すると、意図しない通信も許可してしまいます…
そのため、特定のEC2からの通信のみ許可したい場合は/32 単位で指定する必要があります！
/24指定ではサブネット内の全EC2が許可されますが、/32指定では意図したEC2のみに絞り込めます。
どうしてもEC2間の通信をNetwork Firewallで検査したい場合は、EC2を別々のサブネットに配置する設計を検討してください。
同一サブネット内にいる限り、Network Firewallのルールは適用されません。
重要なのは、「この通信はどの層で制御されているか」を把握することです。
Network Firewallを導入していても、同一サブネット内の通信には効きません。Security Groupのルール設計が不十分であれば、そこが穴になります。
試験で「通信が正しく許可/拒否されていること」を確認するとき、何で制御されているかによって確認方法が変わります。
1. Security Groupのインバウンド/アウトバウンドルールを確認
2. Test-NetConnection でTCP疎通を確認
Windows ServerのEC2でSecurity GroupやWindows Firewallの確認・修正手順を詳しく知りたい方は、こちらの記事も参考にしてください！
参考：
AMIコピーで作成したAmazon EC2でTCP通信できない？Windows Firewallの落とし穴と対処法
1. Network Firewallのルールグループを確認
2. Test-NetConnection でTCP疎通を確認
3. 必要に応じてNetwork Firewallのログを確認（通過/ドロップの記録）
試験項目を設計する際に「この通信はどの層で制御されているか」を明記しておくと、試験の目的が明確になり、結果の判断もしやすくなります！
同一サブネット内のEC2同士の通信は、VPCのlocalルートで処理されるため、AWS Network Firewallを経由しません。通信制御はSecurity Groupのみで行われます。
個人的には、Network Firewallを導入した環境で「全通信が検査されている」と思い込みがちなところが怖いと感じています。設計段階で「この通信がどの層で制御されているか」を意識しておくだけで、セキュリティの見落としや試験の抜け漏れを防げると思います！