【実務・中級編】 AWS Gateway Load Balancer (GLB) の基本アーキテクチャとGENEVEカプセル化 – クラウド＆コンテナネットワーク実践ガイド

ネットワークの「透明人間」を使いこなせ：AWS Gateway Load Balancer (GWLB) と GENEVE プロトコルの真実

クラウドネイティブなインフラを構築していると、一度は頭を抱えるのが「サードパーティ製セキュリティアプライアンスの配置」です。ファイアウォールやIPSをインラインで挟みたい。しかし、ネットワーク構成を複雑にせず、かつスケーラブルに保ちたい。そんな現場のジレンマを解消する「切り札」が、AWS Gateway Load Balancer (GWLB) です。

今日は、教科書には載っていない「パケットが裏側でどう蠢いているか」というリアルな話をしましょう。

—

なぜ、今さら GWLB なのか？

かつて、セキュリティアプライアンスをインラインに配置しようとすると、VPC内のルーティングテーブルを書き換え、ターゲットごとにスタティックルートを刻むという「地獄の運用」が待っていました。

GWLB は違います。これは、ネットワークパスの途中に「透過的」に割り込むためのロードバランサーです。クライアントから見たとき、通信相手（ターゲット）は変わらないのに、裏側では GWLB がパケットをキャッチして、仮想アプライアンスの群れに投げ込み、検査が終わったパケットを元のルートに戻す。この「透過的な介入」こそが最大の武器です。

GENEVE プロトコル：パケットを運ぶ「魔法の封筒」

GWLB の核となる技術が GENEVE (Generic Network Virtualization Encapsulation) です。これは UDP ポート 6081 を使用するカプセル化プロトコルで、簡単に言えば「元のパケットを、別のパケットの腹の中に詰め込んで運ぶ」仕組みです。

なぜ VXLAN ではなく GENEVE なのか？それは、GENEVE がヘッダー内に「メタデータ」を付与する余地を広大に残しているからです。GWLB は、このメタデータ領域に「フローの識別情報」を書き込みます。

なぜ重要か: 仮想アプライアンスは、このメタデータを見ることで、パケットの送信元・送信先情報をいちいち解析しなくても、「これはどのフローに属するパケットか」を即座に判断できます。これにより、アプライアンス側の負荷を劇的に下げているのです。

—

通信のシーケンスを解剖する

パケットは以下の経路を駆け巡ります。

1. Ingress: クライアントからのパケットが GWLB に届く。
2. Encapsulation: GWLB がパケットを GENEVE ヘッダーで包む。このとき、宛先はアプライアンスのIPに書き換わる。
3. Inspection: アプライアンスがパケットを開封し、セキュリティ検査を実行。
4. Return: 検査後のパケットを再び GENEVE で包み、GWLB に送り返す。
5. Egress: GWLB が GENEVE ヘッダーを剥がし（Decapsulation）、元のパケットをターゲットへ届ける。

この間、クライアントもターゲットも、間にアプライアンスが存在することに気づきません。まさにネットワーク上の「透明人間」です。

—

実践：GWLB 接続のための設定と確認

現場でトラブルシューティングをする際、まずは 6081 番ポートが疎通しているかを疑うのが鉄則です。

1. 疎通確認のためのヒント（CLI）

アプライアンスの EC2 インスタンス内で、パケットが GENEVE 経由で届いているか確認するには tcpdump を使います。

# アプライアンスのネットワークインターフェースでGENEVEを監視
# 6081ポートのトラフィックが流れていれば、GWLBは正常に動作している
sudo tcpdump -ni eth0 udp port 6081 -vv

2. Python でのダミーヘッダー解析（概念コード）

もしあなたが独自のアプライアンス（カスタムコード）を書く場合、GENEVE ヘッダーをパースする必要があります。

import socket

# GENEVEの標準ポート 6081 をリッスン
UDP_IP = "0.0.0.0"
UDP_PORT = 6081

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind((UDP_IP, UDP_PORT))

while True:
    data, addr = sock.recvfrom(65535)
    # 最初の8バイトはGENEVEの固定ヘッダー
    # ここから先を解析して元のIPパケットを取り出す
    print(f"Received {len(data)} bytes from {addr}")
    # 実際にはここにパケットをデカプセル化するロジックが必要

—

現場のSREが教える「ハマりどころ」Tips

1. MTUの調整を忘れるな: GENEVE カプセル化はヘッダー分（通常 50-100 バイト程度）だけパケットサイズが増えます。アプライアンスとの通信経路で MTU が不足すると、パケットロスが多発します。仮想アプライアンス側のインターフェース MTU を 8500 程度に引き上げるのが定石です。
2. ヘルスチェックの罠: GWLB のヘルスチェックは、アプライアンスが「正常に GENEVE パケットを処理できているか」を監視します。アプリケーション層で 200 OK を返していても、GENEVE のパケットを正しく転送（Hairpinning）できなければ、ロードバランサーからは「異常」と見なされます。
3. 対称性の保持: GWLB はフローベースでアプライアンスにトラフィックを割り振ります。もし往路と復路でアプライアンスのセッション状態が同期されていない場合、ファイアウォールでパケットがドロップされることがあります。アプライアンス側の冗長構成（HA）設計には細心の注意を払ってください。

まとめ：ネットワークの抽象化は「詳細」を知ること

GWLB と GENEVE は、クラウドネットワークの抽象度を一段押し上げました。しかし、抽象度が高いからといって、その中身をブラックボックスにしてはいけません。

パケットがカプセル化され、UDP で運ばれ、メタデータが解析される。この一連の動きをイメージできることが、いざという時のデバッグスピードを分けます。現場で「パケットが消えた」と騒ぐ前に、まずは 6081 ポートの先にあるパケットたちの声に耳を澄ませてみてください。

それでは、良いインフラライフを！