どーも！shihopowerです！今回はGateway Load Balancer（GWLB）についてお話します。AWS SAPの対策をしていると、このサービスが選択肢に登場してきました。ALBやNLBと違い聞きなじみのないロードバランサーだったので、AWS公式ドキュメントのみを参照してしっかり整理してみました。「GWLBって何？他のロードバランサーと何が違うの？」という方の参考になれば幸いです！
1. はじめに
この記事で分かること
- Gateway Load Balancerの定義と仕組み
- なぜGateway Load Balancerが必要なのか
- フロースティッキネスとタプルの意味
- 具体的なユースケース
- ALB・NLB・CLBとの違い
参照ドキュメント
- What is a Gateway Load Balancer? - Elastic Load Balancing
- Edit target group attributes for your Gateway Load Balancer
- How Elastic Load Balancing works
- Use Elastic Load Balancing to distribute incoming application traffic in your Auto Scaling group
2. Gateway Load Balancerとは（定義）
一言で言うと
Gateway Load Balancer（GWLB）は、仮想セキュリティアプライアンスをAWS上でデプロイ・スケール・管理するためのロードバランサーです。
AWS公式ドキュメントには以下のように記載されています。
Gateway Load Balancers enable you to deploy, scale, and manage virtual appliances, such as firewalls, intrusion detection and prevention systems, and deep packet inspection systems.
つまり、ファイアウォール・侵入検知/防止システム（IDS/IPS）・ディープパケットインスペクション（DPI）システムといった仮想アプライアンスを束ねる「ロードバランサー」です。一般的なWebアプリの負荷分散ではなく、ネットワークセキュリティ用途という点が大きな特徴です。
OSIモデル上の位置づけ（L3動作）
GWLBは**OSIモデルの第3層（ネットワーク層）**で動作します。
| ロードバランサー | OSIレイヤー |
|---|---|
| ALB（Application） | L7（アプリケーション層） |
| NLB（Network） | L4（トランスポート層） |
| GWLB（Gateway） | L3（ネットワーク層） |
| CLB（Classic） | L4 / L7 |
L3で動作するということは、全ポートにわたる全IPパケットを対象にできるということです。HTTP/HTTPSに限定されるALBとは根本的に役割が異なります。
GENEVEプロトコルとは
GWLBはアプライアンスとのトラフィック交換に**GENEVEプロトコル（ポート6081）**を使用します。GENEVEはパケットにメタデータを付与しながらカプセル化できるトンネリングプロトコルで、GWLBがオリジナルのパケット情報を保持しつつアプライアンスに転送するために使われます。
3. なぜGateway Load Balancerが必要なのか
仮想セキュリティアプライアンスのスケール課題
クラウド環境でファイアウォールなどのセキュリティアプライアンスを導入しようとすると、以下のような課題が生じます。
- トラフィックが増えたときにアプライアンスを手動でスケールしなければならない
- アプライアンスが複数台になると、VPCのルーティング設定が複雑になる
- アプライアンスの障害時にトラフィックを別のインスタンスに自動で切り替えられない
GWLBが解決すること
GWLBはこれらの課題を解決します。AWS公式ドキュメントには以下のように記載されています。
It combines a transparent network gateway (that is, a single entry and exit point for all traffic) and distributes traffic while scaling your virtual appliances with the demand.
すなわち、**単一の入口・出口（透過的なネットワークゲートウェイ）**として機能しながら、需要に応じてアプライアンスを自動スケールします。アプリケーション側はGWLBにさえアクセスすれば、背後のアプライアンスが何台に増えても意識する必要がありません。
4. Gateway Load Balancerの仕組み
アーキテクチャ概要
GWLBを使った構成では、主に2つのVPCが登場します。
| VPC | 役割 |
|---|---|
| サービスプロバイダーVPC | GWLBと仮想アプライアンス（FW等）が配置される |
| サービスコンシューマーVPC | 実際のアプリケーションサーバーが配置される |
Gateway Load Balancerエンドポイントとは
2つのVPC間のトラフィックのやり取りには**Gateway Load Balancerエンドポイント（GWLBe）**を使います。AWS公式ドキュメントには以下のように記載されています。
A Gateway Load Balancer endpoint is a VPC endpoint that provides private connectivity between virtual appliances in the service provider VPC and application servers in the service consumer VPC.
GWLBeはAWS PrivateLinkを通じてVPC間をプライベートに接続するエンドポイントです。インターネットを経由せずにトラフィックを安全に受け渡せます。
トラフィックフローの流れ
[インターネット]
↓
[サービスコンシューマーVPC]
アプリケーションサーバー
↓ （ルートテーブルで次ホップをGWLBeに設定）
[GWLBエンドポイント（GWLBe）]
↓
[サービスプロバイダーVPC]
Gateway Load Balancer
↓
仮想アプライアンス（FW / IDS / DPIなど）
↓ （検査後、GWLBに戻す）
Gateway Load Balancer
↓
[GWLBエンドポイント（GWLBe）]
↓
[サービスコンシューマーVPC]
アプリケーションサーバー（トラフィック到達）
トラフィックはルートテーブルによって制御され、アプリケーションサーバーへの到達前に必ずアプライアンスを経由する構成になります。
5. フロースティッキネスとタプルを理解する
フロースティッキネスとは
「フロー（Flow）」は一連の通信セッションを指し、「スティッキネス（Stickiness）」は「粘着性」を意味します。つまりフロースティッキネスとは、同じ通信セッションのパケットを常に同じアプライアンスに送り続ける性質のことです。
GWLBは確立したフローについて、同一フローの全パケットを一貫して同じターゲットアプライアンスにルーティングします（公式ドキュメント：How Elastic Load Balancing works）。
タプルとは
タプル（Tuple）は、パケットを識別するための情報の組み合わせです。GWLBはこのタプルをハッシュキーとして使い、「このパケットはあのアプライアンスへ」という振り分けを行います。
AWS公式ドキュメントでは3種類のタプルが定義されています（Edit target group attributes）。
| タプル | 含まれる要素 | 識別の粒度 |
|---|---|---|
| 5タプル（デフォルト） | ソースIP・ソースポート・宛先IP・宛先ポート・トランスポートプロトコル | 最も細かい |
| 3タプル | ソースIP・宛先IP・トランスポートプロトコル | 中間 |
| 2タプル | ソースIP・宛先IP | 最も粗い |
タプルの要素が多いほど細かく識別できます。5タプルでは、同一クライアントIPであってもポートが変われば別フローとして扱われます。2タプルではIPアドレスのみで識別するため、同一IPからのすべての通信が同じアプライアンスへ向かいます。
なぜセキュリティアプライアンスにスティッキネスが必要か
ファイアウォールやIDSはステートフル（通信の状態を保持する）な機器です。リクエスト（送信）とレスポンス（受信）の両方のパケットを見て初めて正しく検査できます。
もしフロースティッキネスがないと——
リクエスト → アプライアンスA へ
レスポンス → アプライアンスB へ ← アプライアンスBは文脈を知らないので検査できない！
フロースティッキネスがあると——
リクエスト → アプライアンスA へ
レスポンス → アプライアンスA へ ← 同じアプライアンスで一貫した検査が可能！
これがフロースティッキネスが必要な理由です。
タプル選択時の注意事項
AWS公式ドキュメントには以下の注意事項が記載されています。
- フロースティッキネスは接続・フローの偏った分散を引き起こし、ターゲットの可用性に影響する可能性があるため、スティッキネスタイプ変更前に既存フローをすべて終了またはドレインすることが推奨される
- 2タプル・3タプルは、AWS Transit GatewayのアプライアンスモードがONの場合はサポートされない。その場合は5タプルを使用する
6. ユースケース
ファイアウォール／IDS・IPS
最も代表的なユースケースです。インターネットからアプリケーションへのトラフィックをGWLB経由で仮想ファイアウォール／IDS・IPSに通し、不正なパケットを検知・遮断します。アクセスが増えてもGWLBがアプライアンスを自動スケールするため、手動対応は不要です。
ディープパケットインスペクション（DPI）
DPIはパケットの中身（ペイロード）まで検査する技術です。GWLBを使うことで、DPIアプライアンスのフリートにトラフィックを均等に分散しながら、各フローの継続性（スティッキネス）を保ったままコンテンツ検査が行えます。
複数VPCからのトラフィックを一元検査する構成
複数のサービスコンシューマーVPCを持つ組織では、それぞれのVPCにアプライアンスを置くと管理コストが膨大になります。GWLBエンドポイントを活用することで、複数のコンシューマーVPCのトラフィックを1つのサービスプロバイダーVPCに集約し、アプライアンスを共有して一元管理できます。
7. 他のロードバランサーとの比較
比較表
| 項目 | ALB | NLB | GWLB | CLB |
|---|---|---|---|---|
| OSIレイヤー | L7（アプリケーション） | L4（トランスポート） | L3（ネットワーク） | L4 / L7 |
| 対象プロトコル | HTTP / HTTPS | TCP / UDP | 全IPパケット（全ポート） | TCP / SSL / HTTP / HTTPS |
| 通信プロトコル | HTTP/1.1, HTTP/2, gRPC | TCP / UDP | GENEVE（port 6081） | TCP / HTTP |
| 主な用途 | Webアプリ・パスベースルーティング | 高スループット・固定IP | 仮想セキュリティアプライアンス | レガシー用途 |
| MTU | 9001（Jumbo） | 9001（Jumbo） | 8500 | 9001（Jumbo） |
| クロスゾーンLB | デフォルト有効 | デフォルト無効 | デフォルト無効 | 構築方法次第 |
GWLBを選ぶべきシーン
- サードパーティ製仮想ファイアウォール／IDS・IPS／DPIアプライアンスをAWS上でスケールさせたいとき
- VPC境界をまたいでセキュリティ検査を透過的に挿入したいとき
- GENEVEプロトコルをサポートするアプライアンスを利用するとき
逆に、WebアプリのHTTPルーティングにはALB、TCPの高スループットにはNLBを選ぶのが適切です。
8. まとめ
- GWLBはWebアプリの負荷分散ではなく、仮想セキュリティアプライアンスのデプロイ・スケール・管理のためのロードバランサー
- L3（ネットワーク層）で全IPパケットを対象に動作し、GENEVEプロトコルでアプライアンスとやり取りする
- フロースティッキネスにより、同一フローのパケットを常に同じアプライアンスに送り続けることで、ステートフルなセキュリティ検査を実現する
- ALB・NLBがアプリケーションのスケールを担うのに対し、GWLBはそのトラフィックパス上にセキュリティ検査レイヤーを透過的に組み込む役割を担う
最後まで読んでいただきありがとうございました！参考になれば嬉しいです🎉