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

記事タイトルとURLをコピーする

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

はじめに

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

GWLBとは

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

従来のアプライアンス構成

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

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

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

  • 従来のアプライアンス構成①

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

  • 従来のアプライアンス構成②

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

GWLBの概要

概要図

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

コンポーネント

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

  • GWLBe(GWLBエンドポイント)
  • エンドポイントサービス
  • GWLB

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

概要

  • GWLBはターゲットとの通信にGENEVE(UDP: 6081)というトンネリングプロトコルを使います。
  • GWLBは5 タプルハッシュ(送信元IPおよびポート,宛先IPおよびポート,プロトコル)に基づき、ターゲット(アプライアンス)に負荷を分散します。
  • GWLBにはリスナーポートが存在せず、通信を受け取ったらGENEVEにカプセル化し、ターゲット(アプライアンス)に負荷を分散します。
  • GENEVEのヘッダー内には、GWLBeのIDやソースVPCのIDが含まれます。

GENEVEのメリット

  • 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

構成例

ここからGWLBの構成例を記載いたします。 大きくTGWを利用するか、しないかの構成になるかと思います。

TGWなし

①VPCからInternetへのトラフィック監査

TGWあり

②VPCからInternetへのトラフィック監査

③VPC間のトラフィック監査

④オンプレからInternetへのトラフィック監査

⑤オンプレからVPCへのトラフィック調査

参考資料

www.youtube.com

福島 和弥 (記事一覧)

2019/10 入社

AWS CLIが好きです。