クラウドの「交通整理」を極める：GLBエンドポイントとPrivateLinkで構築する堅牢なネットワークアーキテクチャ
こんにちは。SREとして数多の障害対応を潜り抜けてきた筆者が、今日は少し「玄人好み」のインフラの話をしようと思います。
Web APIの設計やマイクロサービス化が進む現在、ただALBを置いて終わり、という構成はもはや過去の遺物です。特にセキュリティ要件が厳しいエンタープライズ環境では、トラフィックを特定の「検査用VPC」に強制的に流し込み、パケットを精査してからバックエンドへ届ける。そんな「透過的かつセキュアな経路制御」が求められます。
そこで主役となるのが、AWSの Gateway Load Balancer (GLB) と VPCエンドポイント の組み合わせです。今回は、現場で泣きを見ないための実装ノウハウを深掘りします。
—
1. なぜALB/NLBでは不十分なのか？
多くのエンジニアが混乱するのは、ALBやNLBとGLBの「役割の違い」です。
- ALB (Application Load Balancer): HTTP/HTTPSのレイヤー7を解釈し、リクエストを適切なターゲットへ振り分ける「賢い門番」。
- NLB (Network Load Balancer): 超高速なレイヤー4の通信をさばく「スピードスター」。
- GLB (Gateway Load Balancer): これらとは毛色が違います。パケットを「書き換えずに」中継し、ファイアウォールやIDS/IPSといった「仮想アプライアンス」に検査させるための「透明なトンネル」です。
GLBは、パケットにGeneve（Generic Network Virtualization Encapsulation）ヘッダーを付与して運ぶことで、元のIP情報を維持したままアプライアンスへ送り届けます。これが、「透過的（Transparent）」であることの真髄です。
—
2. GLBエンドポイントとVPCエンドポイントの連携フロー
異なるVPC間で通信を行う際、私たちはしばしば「PrivateLink」という魔法を使います。しかし、GLBを利用したインライン構成では、少し構成が変わります。
基本的な通信フロー
1. クライアントVPC: ルートテーブルで宛先へのトラフィックを「VPCエンドポイント（GWLBエンドポイント）」へ向ける。
2. GWLBエンドポイント: パケットを捕まえ、GLB経由で「セキュリティVPC」内のアプライアンスへ転送。
3. セキュリティVPC: アプライアンスがパケットを検査。問題なければパケットを戻す。
4. GWLBエンドポイント: 検査済みパケットを本来の目的地へ配送。
このとき、ルートテーブルの設計こそがすべてを握ります。
—
3. 実践：Terraformでの構成例
現場でインフラコードとして管理する際、最も重要なのは「どこにパケットを流すか」の明示です。以下は、GWLBエンドポイントを定義する際の典型的なスニペットです。
# セキュリティVPC内のアプライアンスへ繋ぐためのGWLBエンドポイント作成
resource "aws_vpc_endpoint" "gwlb_endpoint" {
service_name = aws_lb.my_glB.vpc_endpoint_service_name # GLBが提供するサービス名
subnet_ids = [aws_subnet.private_az1.id] # 通過させるサブネット
vpc_endpoint_type = "GatewayLoadBalancer" # ここがキモ。GatewayLoadBalancerを指定
vpc_id = aws_vpc.client_vpc.id
tags = {
Name = "inspection-endpoint-01"
}
}このエンドポイントを作成すると、AWSは自動的にそのVPC内の特定のネットワークインターフェース（ENI）を介してパケットをルーティングできるようになります。
—
4. デバッグの鉄則：パケットが消えた時の追い方
「構成は正しいはずなのに、なぜかAPIがタイムアウトする」。現場で最も多いトラブルです。そんな時は、以下の手順で切り分けを行ってください。
手順1：ルートテーブルの確認
aws ec2 describe-route-tables を叩き、想定したネクストホップが vpce-xxxxxx になっているか確認してください。「デフォルトルートがインターネットゲートウェイに向いたまま」というミスは、新人からベテランまで一度は経験する道です。
手順2：curlによる疎通確認
接続先に対して、以下のようにHTTPステータスだけでなく接続時間（time_connect）を計測しましょう。
# 接続先までのレイテンシを計測
curl -v -o /dev/null -s -w \
"Connect: %{time_connect}s, TTFB: %{time_starttransfer}s, Total: %{time_total}s\n" \
https://your-api-service.internalもし time_connect が極端に長い場合、アプライアンス側でパケットがドロップされているか、非対称ルーティング（戻りのパケットが違う経路を通っている）が発生している可能性が高いです。
—
5. 最後に：SREとしてのアドバイス
GLBエンドポイントを利用した構成は、柔軟性が高い反面、運用コストも高くなります。特に、セキュリティVPC側のアプライアンスがスケーリングに失敗すると、システム全体がブラックホール化します。
- 監視の徹底:
UnHealthyHostCountやPacketDropCountをCloudWatchで監視し、アラートを設定すること。 - 非対称通信の回避: ルートテーブルは必ず対称的（往復ともに同じGWLBエンドポイントを経由するよう）に構成すること。
「ネットワークは生き物である」ということを常に意識してください。設定ファイル上では正しく見えても、実際のパケットの流れは複雑です。迷ったら VPC Flow Logs を有効にし、どのENIでパケットが止まっているかを可視化しましょう。
インフラエンジニアの仕事は、魔法のような環境を作ることではなく、誰が触っても壊れない「理にかなった道」を敷くことです。今日の知見が、皆さんの現場の安定稼働の一助となれば幸いです。
それでは、また次回の深掘りでお会いしましょう。
コメント