「空港のセキュリティゲート」で考えてみましょう。乗客（パケット）は必ずセキュリティチェック（検査アプライアンス）を通ってから搭乗口（アプリ）へ向かいます。
サードパーティのネットワーク仮想アプライアンスのデプロイと管理を簡素化するAWSのサービスです。
GWLBアーキテクチャは「GWLB本体」「GWLBエンドポイント」「検査アプライアンス」の3要素で成り立ちます。
セキュリティVPCに配置。複数のアプライアンスへトラフィックを均等分散しながら、元のパケット情報をそのまま保持（GENEVEカプセル化）して透過検査を実現する。
アプリケーションVPCに配置するインターフェース。ルートテーブルの向き先をGWLBEに設定するだけで、アプリ側の設定を変えずにトラフィックを検査経路へリダイレクト。
Palo Alto、Fortinet、Check Point などのファイアウォール・IDS。パケット内容（レイヤー7）を解析し、許可・ブロック・ログを判定。GWLBがスケールを自動管理する。
インターネットからアプリまでの経路にGWLBエンドポイントを挿入し、すべてのトラフィックをセキュリティVPCへ「迂回」させます。
パケットが「受信」から「アプリ到達」または「ブロック」に至るまでの流れを追います。
GWLBがどのように「透過的」かつ「スケーラブル」に動くかを詳しく見ます。
パケットをGENEVEプロトコルでラップし、元のIPヘッダー・ポート情報を保持したまま転送。アプライアンスはオリジナルのパケット内容を完全に見ることができ、送受信元の変更なし。
同一TCPセッションの往路・復路のパケットは必ず同じアプライアンスインスタンスに送られる（5-tuple ハッシュ）。ステートフルなセッション管理が正しく維持される。
GWLBはアプライアンスの死活監視を常時実行。障害インスタンスを自動的に除外し、正常なインスタンスだけにトラフィックを向ける。検査の空白時間を最小化。
アプライアンスをAuto Scalingグループで管理することでトラフィック増大に自動対応。GWLBが新しいアプライアンスを即座に検出し、負荷分散に加える。管理者の手作業不要。
GWLBエンドポイント（GWLBE）の置き場所は「インバウンド検査」と「アウトバウンド検査」で異なります。
検査されたトラフィックのすべてのアクションが、一箇所に集まりクロスVPC分析が可能になります。
| フィールド | 内容 | 活用シーン |
|---|---|---|
| src-ip / dst-ip | 送受信元IPアドレス | 攻撃元IPの特定・ブロックリスト作成 |
| action | ALLOW / DENY / ALERT | ポリシー効果の検証・コンプライアンス証跡 |
| threat-name | 検知した脅威の種類 | インシデント対応・SIEM相関分析 |
| bytes / packets | フロー量データ | データ漏洩の異常検知・容量計画 |
| session-id | セッション識別子 | 往路・復路の紐付けとフォレンジック |
| サービス | 検査レイヤー | アプライアンス統合 | 主な用途 | GWLBとの関係 |
|---|---|---|---|---|
| Gateway Load Balancer | L3〜L7（DPI） | ✅ サードパーティ統合 | 透過的全トラフィック検査 | — |
| AWS WAF | L7（HTTP/S） | ❌ AWSマネージドのみ | Webアプリ攻撃防御 | GWLBと併用可。WAFはCloudFront/ALBに付加 |
| Security Group / NACL | L3〜L4のみ | ❌ | IPポートベースのフィルタ | GWLBの前後に組み合わせる基本防御層 |
| AWS Network Firewall | L3〜L7 | ❌ AWSマネージドのみ | AWSネイティブのステートフルFW | サードパーティ不要な場合のGWLB代替 |
| Amazon GuardDuty | ログ分析 | ❌ | 脅威インテリジェンス・異常検知 | GWLBログの分析先として補完 |
Created by SSuzuki1063
AWS SAP Learning Resources