【AWS Gateway Load Balancer(GWLB)】概要と設計ポイントと構成例について

こんにちは。AWS CLIが好きな福島です。

はじめに

今回は、GWLBを触る機会があり、Black Beltの動画を視聴したため、その内容をブログに記載いたします。

GWLBとは、ELBの1種でネットワークアプライアンス(以降、アプライアンス)の可用性を向上させることができるロードバランサーになります。

GWLBが登場する前からAWS上でトラフィックの監査を行うためにアプライアンスを導入しているケースがあり、その際の構成は以下の通りでしたが、課題がありました。

まず、アプライアンスを導入する場合、トラフィックを監査したいリソースが存在するサブネットのデフォルトルートをアプライアンスにする必要があります。

もちろん、ルートには複数のアプライアンスを指定することができないため、冗長性構成を組むためには、アプライアンスを監視し異常を検知した場合にルートテーブルを更新するLambdaなどを作りこむ必要がありました。

また、以下のようにVPNを使った構成もあり、この場合はBGPにより障害時の切替時間は短縮できますが、ネットワーク構成の複雑化やVPN使用による帯域の制限やアプライアンスへの負荷影響といった懸念がありました。

つまり、GWLB登場前はアプライアンスの冗長化が大変だったため、それを簡素化してくれるサービスがGWLBとなります。

GWLBの概要図は以下の通りです。

GWLBを構築する上で必要なリソースは以下の通りです。

※ 概要図では、エンドポイントサービスが省略されていますが、GWLBe ⇒ エンドポイントサービス ⇒ GWLB というイメージです。

VPCは、VPC内のIPからしか通信を受け取りませんが、GENEVEを使いカプセル化することで送信元と送信先をVPC内のIPにすることが可能です。 (GWLBと異なるVPCからの通信を処理できます。)
オリジナルのパケットをNatなどで書き換えることなく通信を透過的にアプライアンスに流すことができます。

GWLBeはAZごとに作成する必要があります。
ターゲットとなるアプライアンスはGENEVEプロトコルをサポートしている必要があります。
ターゲットグループを作成する際は、プロトコルをGENEVEにしなければ、GWLBのターゲットに関連付けできません。
クロスゾーン負荷分散はデフォルトオフのため、必要に応じて有効化する必要があります。(基本有効にしておくべきかなと思います。)
TGWを使わない構成かつVPCとインターネット間の通信にGWLBを挟む場合、VPC Ingress Routingを使う必要があります。
TGWを使った構成の場合、GWLBが存在するVPC用TGWアタッチメントのアプライアンスモードを有効化しなければ、以下の図(※1)のように非対称ルーティングになります。詳細は、https://blog.serverworks.co.jp/aws-transit-gateway-appliance-mode を参照ください。

※1