Inbound / Outbound Network Flow設計

1. 最初に必要なフローを4要素で固定する

ルールを先に作るのではなく、必要な通信を送信元 / 宛先/ プロトコル / ポートで定義します。

「プライベートサブネットだから安全」「同じVPCだから許可」といった位置情報ではなく、必要なフローそのものを起点にします。

2. 必要なフローと実際のルート経路を分けて考える

同じ送信元 / 宛先でも、実際のルート経路によって通過する制御や利用できるルール表現が変わります。

必要なフロー
アプリケーションA → アプリケーションB : TCP 443

候補経路 1
アプリケーションA ─────────────→ アプリケーションB

候補経路 2
アプリケーションA → 検査 → アプリケーションB

ルートテーブルは「通信を許可するセキュリティポリシー」ではなく、パケットがどこを通るかを決めます。したがってセキュリティルールは、選択された実際のルート経路と整合している必要があります。

3. インバウンド / アウトバウンドは制御から見た方向で決める

1つの通信でも、送信元側ではアウトバウンド、宛先側ではインバウンドになります。

送信元リソース
      │
      │ アウトバウンド
      ▼
   ネットワーク
      │
      │ インバウンド
      ▼
宛先リソース

アプリケーション全体から見た「外向き / 内向き」ではなく、ルールを配置するリソースやサブネットから見た方向へ変換します。

4. セキュリティグループは送信元 / 宛先リソースへフローを割り当てる

例えばALBからアプリケーションへTCP 8443だけを許可する要件なら、1本のフローを両端へ分解します。

ALB → アプリケーション: TCP 8443

ALB セキュリティグループ
→ アウトバウンド TCP 8443
→ 宛先= アプリケーションSG

アプリケーションセキュリティグループ
→ インバウンド TCP 8443
→ 送信元= ALB SG

送信元セキュリティグループ参照を使えるトポロジーなら、IPアドレスを固定せずリソースグループの関係として表現できます。

5. セキュリティグループの戻りトラフィックを二重に設計しない

セキュリティグループのステートフル性により、許可された接続への応答を新しい逆方向フローとして重複定義する必要はありません。

アプリケーション → DB : TCP 5432

必要な開始方向アプリケーションSG アウトバウンド 5432
DB SG  インバウンド  5432

確立済み接続の戻り通信
→ 逆向きSG ルールを追加する理由にはしない

ただし、DBからアプリへ別接続を新規開始する要件があるなら、それは独立した必要なフローとして評価します。

6. ミドルボックスを経由するとセキュリティグループ参照の成立条件を再確認する

異なるサブネット間を検査アプライアンスなどのミドルボックス経由でルーティングする場合、エンドポイント同士のセキュリティグループ参照だけでは通信を許可できない構成があります。

直接経路インスタンス A ─────────────→ インスタンス B
SG-A                      SG-B

トポロジーが対応
→ SG-B 送信元= SG-A を候補化ミドルボックス経路インスタンス A → ミドルボックス → インスタンス B

エンドポイント間セキュリティグループ参照だけでは不可
→ 相手プライベートIP / サブネットCIDR等を評価

ミドルボックスを通るから送信元IPが必ずミドルボックスへ変わるという意味ではありません。実際のルート経路に対して、セキュリティグループ参照というルール表現が成立するかを確認します。

7. ネットワークACLはサブネット境界を越える箇所へ割り当てる

ネットワークACLはリソースではなくサブネット境界で考えます。異なるサブネット間のリクエストでは、送信元サブネットから出る方向と宛先サブネットへ入る方向を確認します。

サブネットA                         サブネットB

インスタンス A ───────────────────→ インスタンス B
     │                               ▲
     │ NACL-A アウトバウンド               │ NACL-B インバウンド
     └───────────────────────────────┘

まず実際にどのサブネット境界を越えるかを決め、その境界に関連付くNACL ルールへ変換します。

8. 同一サブネット内の通信へNACL インバウンド / アウトバウンドを機械的に当てない

ネットワークACLはトラフィックがサブネットに出入りするときに評価され、同一サブネット内でルーティングされるトラフィックには評価されません。

同一サブネットインスタンス A ─────────→ インスタンス B

サブネット境界を越えない
→ NACL アウトバウンド → NACL インバウンドという変換を行わない

「送信元側アウトバウンド + 宛先側インバウンド」という考え方は、セキュリティグループとネットワークACLで評価単位が異なります。

9. ネットワークACLはリクエストと戻りの両方を境界へ配置する

NACLはステートレスなので、異なるサブネットをまたぐ通信ではリクエストだけでなく戻りトラフィックも明示的に成立させます。

リクエストクライアントサブネットNACL アウトバウンド
        ↓
サーバーサブネットNACL インバウンド : TCP 443

戻りサーバーサブネットNACL アウトバウンド
        ↓
クライアントサブネットNACL インバウンド : クライアントのエフェメラルポート

エフェメラルポートの範囲はクライアント OSや通信方式に合わせて決めます。重要なのは、戻りフローを「セキュリティグループがステートフルだからNACLも不要」と混同しないことです。

10. ルート/ SG / NACLを別々に満たして終わらない

必要フローは、経路と各制御が同時に成立して初めてエンドツーエンドで成立します。

「SGは許可済み」「NACLは許可済み」という個別確認ではなく、同じ実際のルート経路上で整合しているかを確認します。

11. 3層フローを通信単位に分解する

インターネット公開アプリケーションでも、1本の大きなルールでまとめず、層間の必要フローへ分解します。

インターネット
   ↓ HTTPS 443
ALB
   ↓ TCP 8443
アプリケーション
   ↓ TCP 5432
データベース

NACLを厳格化する場合は、各フローが実際に越えるサブネット境界ごとにリクエスト / 戻りを追加で確認します。

12. 外部宛先はSG ルールで表現できるかを先に確認する

承認済み外部サービスだけへアウトバウンドを限定したい場合、要件をそのまま「FQDNをセキュリティグループの宛先へ設定」と変換してはいけません。

承認済み外部サービス
        ↓
SG ルールで宛先を表現可能？
├─ CIDR / プレフィックスリスト / セキュリティグループ等
│   → SGアウトバウンド候補
│
└─ ドメインベースの制御が必要
    → 別の送信制御を評価

セキュリティグループルールは任意のFQDNを直接送信元 / 宛先として指定する制御ではありません。

13. デュアルスタックはIPv4 / IPv6のフローを別々に確認する

同じアプリケーション要件でも、IPv4とIPv6はルートとルールが別に評価されます。

必要なサービスフロー
        ↓
IPv4 経路 / ルール成立？
        +
IPv6 経路 / ルール成立？

IPv4側だけを制限してIPv6側が広く残る、またはIPv6 ルートだけ不足するといった片側だけの設計を避けます。

14. 候補比較は「最も少ないルール」ではなく要件適合で行う

15. エンドツーエンド設計例

要件が「ALBだけがアプリへ8443で接続し、アプリだけがDBへ5432で接続する。アプリから承認済み外部サービスへの通信も必要」である場合、次の順序で判断します。

1. フローを分離
   ALB → アプリケーション : 8443
   アプリケーション → DB  : 5432
   アプリケーション → 外部サービス: 必要ポート

2. 各フローの実際のルート経路を確認

3. リソース側SGへ送信元アウトバウンド + 宛先インバウンド

4. サブネット境界を越えるフローだけ
   NACL リクエスト + 戻りを確認

5. 外部宛先を
   SG ルールで表現できるか確認

6. IPv4 / IPv6を利用するなら双方のルート/ ルールを確認

16. 判断フロー

ネットワーク要件
        ↓
必要なフローを定義送信元 / 宛先/ プロトコル / ポート
        ↓
実際のルート経路を確認
        ↓
ネットワーク境界を特定
        ↓
セキュリティグループリソース基準でアウトバウンド / インバウンドへ変換
        ↓
ミドルボックスを経由する？
└─ はい → セキュリティグループ参照成立条件を再評価
        ↓
ネットワークACLを使う？
└─ はい → 境界ごとにリクエスト / 戻りを確認
        ↓
外部宛先をSGで表現可能？
└─ いいえ → 要件に合う別送信制御を評価
        ↓
IPv4 / IPv6双方を確認
        ↓
エンドツーエンドで必要フローだけ成立

17. 混同ポイント

18. 主要AWS公式資料

• AWS Certified Solutions Architect - Professional 試験ガイド（SAP-C02）
• セキュリティグループのルール
• ネットワークACLによるサブネットトラフィック制御
• VPCのカスタムネットワークACL
• ルーティングオプションの例