Gateway Load Balancer(GWLB)を一言でいうと?
GWLBとは? ── 全体像
🏢 「空港のセキュリティゲート」に例えると…
空港に入るすべての旅客は、必ずセキュリティゲートを通過します。ゲートでは荷物の X線検査やボディチェックを受けますが、旅客のパスポート情報(送信元IP)は変わりません。検査が終われば、旅客はそのまま搭乗ゲートへ向かいます。この「全員が必ず通る、でも元の情報はそのまま」という仕組みが、GWLBの「透過的検査」そのものです。
さらに、空港には複数のセキュリティレーンがあり、混雑したらレーンを増やし(スケーリング)、1つのレーンが故障しても他のレーンでカバーします(高可用性)。GWLBも同様に、検査装置(アプライアンス)を複数配置して負荷を分散します。
GWLBの4大特徴
① 透過的な検査
アプリケーション側は検査の存在を意識しません。ルートテーブルの設定だけでトラフィックを検査経路に誘導でき、元のIP情報(送信元・宛先)はそのまま保持されます。
② Geneveプロトコル
レイヤー3で動作し、元のパケットを丸ごとGeneve形式でカプセル化してアプライアンスに転送します。UDPポート6081を使用し、フロー情報(5タプル/3タプル/2タプル)で分散可能です。
③ 高可用性
複数のAZにまたがってアプライアンスを配置し、ヘルスチェックで障害を検知すると自動フェイルオーバー。クロスゾーン負荷分散にも対応しています。
④ GWLBエンドポイント
VPCエンドポイント技術(PrivateLink)をベースに、VPC間のトラフィック入口・出口として機能します。ルートテーブルでGWLBeを指定して経路を制御します。
Geneveプロトコル ── パケットの「封筒詰め」
✉️ 「封筒の中に封筒」を入れる仕組み
あなたが友人に手紙を送るとします。普通はそのまま封筒に入れて郵便局に出しますよね。ところが、セキュリティ会社が中身を検査する必要がある場合、元の封筒ごと大きな封筒に入れてセキュリティ会社に送ります。セキュリティ会社は大きな封筒を開け、中の元の封筒を検査し、問題なければ元の封筒をそのまま宛先に転送します。これがGeneveカプセル化の考え方です。
(大きな封筒)
GWLB ↔ アプライアンス
ポート 6081
ヘッダー
仮想ネットワーク識別子
フロー追跡用
拡張メタデータ
(中の封筒)
送信元・宛先 IP
ポート情報
実際のデータ
💡 なぜGeneveが重要?
VXLANやNVGREなどの類似プロトコルと異なり、GeneveはTLVオプションで任意のメタデータを柔軟に追加できます。AWSはこれを活用してフローCookieやAZ情報をアプライアンスに伝達し、ステートフルな検査を実現しています。また、元のパケットを完全に保持するため、アプライアンスは送信元IPを正確に識別でき、セキュリティ分析の精度が向上します。
トラフィックフロー ── データの旅路
🚗 「高速道路の料金所検査」で考える
高速道路の入口から入った車(パケット)が目的地に行く途中、必ず料金所兼検問所(GWLBe → GWLB → アプライアンス)を通過します。検問所では車のナンバープレート(送信元IP)を記録し、荷物(パケット内容)を検査します。問題なければそのまま通過させ、車は目的地へ向かいます。帰りも同じ検問所を通ります。
🌐 インターネットからトラフィック到着
外部ユーザーがWebアプリにアクセス。トラフィックがInternet Gatewayを経由してVPCに入る。
🔗 IGWルートテーブルがGWLBeへ転送
Internet Gatewayのルートテーブルにて、アプリサブネット宛のトラフィックをGWLBエンドポイントに向ける。
📤 GWLBeがセキュリティVPCへ転送
GWLBエンドポイントがPrivateLinkを通じて、セキュリティVPC内のGWLBにトラフィックを送る。
📦 GWLBがGeneveでカプセル化・分散
GWLBが元のパケットをGeneveプロトコルでカプセル化し、ターゲットグループ内のアプライアンスに負荷分散。
🔍 アプライアンスが検査
ファイアウォール/IDS/IPSが元のパケットを検査。問題なければGWLBに返送、問題ありなら遮断。
📥 GWLBがGWLBeに返送
検査済みパケットをデカプセル化し、GWLBエンドポイント経由でコンシューマーVPCに戻す。
🖥️ アプリケーションに到着
検査済みの安全なトラフィックがアプリケーション(EC2やALB)に到達。元のIPアドレス情報はそのまま。
VPCアーキテクチャ ── 2つのVPCの関係
🏗️ なぜVPCを分けるのか?
セキュリティアプライアンスを専用VPCに集約することで、複数のアプリケーションVPCのトラフィックを一元的に検査できます。これは「マンションの全室を1つの警備室で監視する」のと同じ考え方で、セキュリティポリシーの統一管理、アプライアンスの共有によるコスト削減、アプリケーションチームとセキュリティチームの責任分離を実現します。
GWLBあり vs なし ── 何が変わる?
❌ GWLBなしの場合
- ⚠️ 各VPCにアプライアンスを個別配置 → コスト増
- ⚠️ NATやプロキシで中継 → 元のIPアドレスが失われる
- ⚠️ アプライアンス障害時の切替が手動 → ダウンタイム
- ⚠️ トラフィック増加時の手動スケーリング
- ⚠️ ルーティングが複雑になり管理負荷が増大
✅ GWLBありの場合
- ✨ アプライアンスを集約VPCで共有 → コスト最適化
- ✨ Geneveカプセル化で元のIP情報を完全保持
- ✨ ヘルスチェック+自動フェイルオーバー → 高可用性
- ✨ ターゲットグループで自動スケーリング
- ✨ ルートテーブル+GWLBeのシンプルな経路制御
3種類のロードバランサー比較
🏨 「ホテルのスタッフ」に例えると…
ALBは「コンシェルジュ」── お客の要望(URLパス、ホスト名)に応じて最適な部門に案内します。NLBは「玄関の回転ドア」── 誰でも超高速で通しますが、中身は見ません。GWLBは「セキュリティスタッフ」── 全員の荷物を検査しますが、お客の身元(IP)は変えません。
| 項目 | ALB | NLB | GWLB |
|---|---|---|---|
| 動作レイヤー | L7(HTTP/HTTPS) | L4(TCP/UDP/TLS) | L3(IP)+ Geneve |
| 主な用途 | Webアプリの振り分け | 高速TCP/UDP転送 | セキュリティアプライアンス検査 |
| ターゲット | EC2, Lambda, IP | EC2, IP, ALB | EC2, IP(アプライアンス) |
| 送信元IP保持 | X-Forwarded-For | 保持 or Proxy Protocol | Geneveで完全保持 ✅ |
| VPC間連携 | なし | PrivateLink可 | GWLBeで専用設計 ✅ |
| ポート | 80, 443 など | 任意のTCP/UDPポート | UDP 6081(Geneve) |
| ホテルの例え | 🧑💼 コンシェルジュ | 🚪 回転ドア | 🛡️ セキュリティスタッフ |
ユースケース ── どんな時に使う?
次世代ファイアウォール
Palo Alto、Fortinet、Check Pointなどのサードパーティ製ファイアウォールで、すべての通信をインライン検査
IDS/IPS(侵入検知/防御)
不正なアクセスパターンをリアルタイム検知し、攻撃トラフィックを自動ブロック
ディープパケットインスペクション
パケットの中身を詳細に分析し、マルウェアやデータ漏洩を検出
コンプライアンス監査
規制要件に基づくすべてのトラフィックの記録・検査を一元的に実施
マルチVPCセキュリティ
Transit Gatewayと組み合わせ、数十〜数百のVPCのトラフィックを集約検査
ゼロトラストネットワーク
East-West(VPC内)トラフィックも含め、すべての通信を「信頼しない」前提で検査
ルートテーブル設定 ── 経路制御の鍵
🗺️ 「道路標識」で例えると…
ルートテーブルは「道路標識」です。「○○方面はこちら」と書いてあるように、トラフィックの行き先を指示します。GWLBの場合、IGWのルートテーブルに「アプリサブネット行きはGWLBeを経由せよ」と記載することで、すべてのトラフィックをセキュリティ検査に誘導します。
| ルートテーブル | 宛先(Destination) | ターゲット(Target) | 説明 |
|---|---|---|---|
| IGWルートテーブル | 10.0.1.0/24(アプリサブネット) | GWLBe | インバウンドをGWLBeに誘導 |
| GWLBeサブネットRT | 0.0.0.0/0 | IGW | 検査済みを外部へ返送 |
| アプリサブネットRT | 0.0.0.0/0 | GWLBe | アウトバウンドもGWLBeに誘導 |
⚠️ 設定の注意点
GWLBeはアプリケーションサブネットとは別のサブネットに配置する必要があります。同じサブネットに置くとルーティングループが発生します。また、IGWの「Edge Association」ルートテーブルを使って、インバウンドトラフィックをGWLBeに向けることが重要です。
高可用性とスケーリング
ヘルスチェック
TCP/HTTP/HTTPSでアプライアンスの状態を定期的に確認。異常検知時は自動的にトラフィックを正常なアプライアンスに切替えます。
クロスゾーン負荷分散
複数AZのアプライアンスに均等にトラフィックを分散。片方のAZに障害があっても、もう片方で処理を継続できます。
ターゲットグループ
Auto Scalingグループと連携し、トラフィック増加時にアプライアンスインスタンスを自動追加。縮小も自動です。
フロースティッキネス
5タプル/3タプルハッシュにより、同じフローのパケットを同じアプライアンスに送り続け、ステートフル検査を維持します。