同一サブネット内のEC2通信はAWS Network Firewallを通らない話

■  はじめに

こんにちは、佐野（マナティ）です！

突然ですが、AWS Network Firewallを導入した環境で、こんなふうに思っていないでしょうか。

「VPC内の通信を検査・制御できるようになった。EC2間の通信もすべてチェックされるし、これで安心！」

…そう思っていませんでしょうか？

一見すると正しそうですが、ここには見落としやすいポイントがあります。

実は、同一サブネット内のEC2同士の通信はNetwork Firewallを経由しません。

この仕様を知らないまま設計や試験を進めると、「Network Firewallで制御しているつもりが、実はSecurity Groupでしか制御されていなかった」ということが起こり得ます。

本記事では、なぜ同一サブネット内の通信がNetwork Firewallを通らないのか、通信制御の各層の役割、そして設計や試験で意識すべきポイントを整理したいと思います！

■  目次 

1. 1. はじめに
   2. なぜ通らないのか：VPCルーティングの仕組み
   3. 通信経路の違い
   4. 通信制御の3層構造
   5. 設計への影響
   6. 試験の観点設計への影響
   7. まとめ
   8. 参考

■  なぜ通らないのか：VPCルーティングの仕組み

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は経由しません。

■ 通信制御の3層構造

AWSの通信制御は、大きく3つの層で構成されています。

それぞれ適用される範囲が異なります。

● Network Firewall

• VPCレベルの通信検査エンジン
• Stateful / Statelessルールで通信をフィルタリング
• ドメインフィルタリングにも対応
• 適用範囲：異なるサブネット間、外部への通信（ルートテーブルでエンドポイントを経由させた場合）

● Security Group

• ENI（ネットワークインターフェース）単位のフィルタ
• ステートフル（戻りの通信は自動で許可される）
• 適用範囲：すべての通信（同一サブネット内を含む）

● Network ACL

• サブネット単位のフィルタ
• ステートレス（戻りの通信も明示的に許可が必要）
• 適用範囲：サブネットに出入りする通信
• 同一サブネット内の通信には適用されない

● 通信パターン別の制御層

ポイントは、同一サブネット内の通信はSecurity Groupでしか制御されない ということです。

■ 設計への影響

● Security Groupの送信元指定は/32単位で実施する

同一サブネットに複数のEC2が配置されている場合、CIDR単位でSecurity Groupの送信元を指定すると、意図しない通信も許可してしまいます…

そのため、特定のEC2からの通信のみ許可したい場合は/32 単位で指定する必要があります！

/24指定ではサブネット内の全EC2が許可されますが、/32指定では意図したEC2のみに絞り込めます。

● Network Firewallで検査したい場合はサブネットを分ける

どうしてもEC2間の通信をNetwork Firewallで検査したい場合は、EC2を別々のサブネットに配置する設計を検討してください。

同一サブネット内にいる限り、Network Firewallのルールは適用されません。

● Network Firewallがあるから大丈夫ということではない…

重要なのは、「この通信はどの層で制御されているか」を把握することです。

Network Firewallを導入していても、同一サブネット内の通信には効きません。Security Groupのルール設計が不十分であれば、そこが穴になります。

■ 試験の観点設計への影響

試験で「通信が正しく許可/拒否されていること」を確認するとき、何で制御されているかによって確認方法が変わります。

● Security Groupで制御されている通信の確認

1. Security Groupのインバウンド/アウトバウンドルールを確認

2. Test-NetConnection でTCP疎通を確認

Windows ServerのEC2でSecurity GroupやWindows Firewallの確認・修正手順を詳しく知りたい方は、こちらの記事も参考にしてください！

参考：

AMIコピーで作成したAmazon EC2でTCP通信できない？Windows Firewallの落とし穴と対処法

● Network Firewallで制御されている通信の確認

1. Network Firewallのルールグループを確認
2. Test-NetConnection でTCP疎通を確認
3. 必要に応じてNetwork Firewallのログを確認（通過/ドロップの記録）

試験項目を設計する際に「この通信はどの層で制御されているか」を明記しておくと、試験の目的が明確になり、結果の判断もしやすくなります！

■ まとめ  

同一サブネット内のEC2同士の通信は、VPCのlocalルートで処理されるため、AWS Network Firewallを経由しません。通信制御はSecurity Groupのみで行われます。

個人的には、Network Firewallを導入した環境で「全通信が検査されている」と思い込みがちなところが怖いと感じています。設計段階で「この通信がどの層で制御されているか」を意識しておくだけで、セキュリティの見落としや試験の抜け漏れを防げると思います！

■ 参考

• VPC のルートテーブル - Amazon VPC ユーザーガイド
• AWS Network Firewall の仕組み
• Security Group の基本 - Amazon VPC ユーザーガイド
• Network ACL - Amazon VPC ユーザーガイド
• AWS Network Firewall のデプロイモデル