AWS Gateway Load Balancer デプロイのベストプラクティス

本稿は、2021年7月8日に Networking & Content Deliveryで公開された “Best practices for deploying Gateway Load Balancer”を翻訳したものです。

はじめに
re:Invent 2020 では、サードパーティの仮想アプライアンスのデプロイ、スケーリング、可用性の管理を簡単かつ費用対効果の高い方法で行うことができるサービスである　Gateway Load Balancer（GWLB）の一般提供を開始しました。これらのアプライアンスには、クラウド内のファイアウォール（FW）、侵入検知および防止システム（IDS / IPS）、ディープパケットインスペクションシステムが含まれます。発売以来、多くのお客様が　AWSパートナーのファイアウォールを備えた GWLB を実稼働環境に導入してきました。このブログ記事では、GWLB を導入する際に考慮すべきベストプラクティスとして、最も一般的に使用される設計パターンと最適な構成設定に焦点を当てます。

長期間持続する TCP フローをサポートするために、TCP キープアライブまたはタイムアウト値を調整する
内部 VPC でのトラフィック検査のフロー対称性を維持するために、AWS Transit Gateway で Appliance Mode を有効にする
Cross-Zone Load Balancing（クロスゾーン負荷分散）を使用するタイミングを理解する
アプライアンスと AZ の障害シナリオを理解する
アウトバウンドトラフィック検査で、ワンアーム（*1）またはツーアーム（*2）のファイアウォールデプロイモードを選択する
SSL/TLS トラフィック検査で、ワンアームまたはツーアームのファイアウォールデプロイモードを選択する

*1 ワンアーム（One-Arm）は、アプライアンスを通信を仲介する機器に対して横付けに配置する構成を指します。
*2 ツーアーム（Two-Arm）は、アプライアンスを通信経路中に配置する構成を指します。

1. 長期間持続する TCP フローをサポートするために、TCP キープアライブまたはタイムアウト値を調整する

一部のアプリケーションや API リクエスト(データベースへの同期 API コールなど)には、長い非アクティブ期間があります。GWLB は TCP フローに対して350秒、非TCPフローに対して 120 秒の固定アイドルタイムアウトを設定しています。アイドルタイムアウトに達するか、フローの TCP 接続が閉じられると、そのフローは GWLB の接続状態テーブルから削除されます。これにより、クライアント側でフローがタイムアウトする可能性があります。既に終了したフローに対する後続の UDP パケットは、別の健全なファイアウォールインスタンスに送信される場合があります。削除されたフローに対する後続の非 SYNTCP パケットは、GWLB によりドロップされる可能性があります。以前と同じ5つのタプル(送信元/宛先IP、送信元/宛先ポート、プロトコル)を使用した新しい TCP 接続リクエストでも、以前とは異なるターゲットにルーティングされる可能性があります。一部のファイアウォールのデフォルトタイムアウトは 3600 秒(1 時間)です。この場合、GWLB のアイドルタイムアウトはファイアウォールのタイムアウト値よりも低くなり、ファイアウォールやクライアントに気づかれずに GWLB がフローを削除してしまいます。

これを防ぐには、下の図 1 に示すように、クライアント/サーバーのアプリケーション/オペレーティングシステム (OS) のいずれかで TCP キープアライブ設定を 350 秒未満に設定するか、ファイアウォールのタイムアウト設定を TCP フローでは 350 秒未満、非 TCP フローでは 120 秒未満に設定することをお勧めします。これにより、何も操作が行われなかったり、ファイアウォールが GWLB の前にセッションを削除したりしても、クライアント/サーバーはフローを維持できます。

図 1: クライアント/サーバー (アプリケーションまたは OS レベル) またはファイアウォールでキープアライブ値とタイムアウト値をそれぞれ設定する

例えば、Linux ディストリビューションでは、TCP キープアライブ設定の主要なパラメーターは tcp_keepalive_time です。これはクライアントまたはサーバーの OS レベルで変更できます。これは TCP キープアライブが送信されるまでの TCP 接続のアイドル時間を表します。tcp_keepalive_time 間隔を次のように短縮する必要があります。

net.ipv4.tcp_keepalive_time = 60 #(or a value less than 350 seconds)

また、UDP などの非 TCP フローの場合、接続状態に関連するタイマーは通常アプリケーションレベルで実装されます。これは、オペレーティングシステムには通常、UDP プロトコル用の特定のタイマー設定がないためです。

2. 内部VPCでのトラフィック検査のフロー対称性を維持するために、AWS Transit Gateway で Appliance Mode を有効にする

このベストプラクティスは、AWS Transit Gateway の GWLB のデプロイに適用されます。ディープパケットインスペクション用のステートフルファイアウォールを備えたアプライアンス VPC（インスペクション VPC、セキュリティ VPC、またはShared Services VPC とも呼ばれる）を介した VPC 間通信を有効にするには、お客様は Transit Gateway で Appliance Mode 機能を有効にする必要があります。

その理由は次のとおりです。下の図 2a に示すように、2 つの EC2 インスタンスが 2 つの異なる AZ の 2 つの異なる VPC にデプロイされているとします。インスタンスが AWS Transit Gateway を介して同じ AZ にない VPC アタッチメントを使用して相互に通信しようとすると、パケットのルーティングが非対称になります。同じ 2 つの通信ノードからのフォワードフローとリバースフローが 2 つの異なる AZ にある 2 つの異なるファイアウォールインスタンスに送信され、トラフィックが中断されます。これは、デフォルトでは、トラフィックが VPC アタッチメント間でルーティングされる場合、AWS Transit Gateway はトラフィックが宛先に到達するまで送信元と同じ AZ にトラフィックを保持するためです。

図 2a: アプライアンス VPC アタッチメントで Transit Gateway Appliance Modeが無効になっている場合の非対称トラフィックフロー (デフォルト動作)

この問題を解決するために、AWS Transit Gateway に「Appliance Mode」機能が追加されました。下の図 2b に示すように、この機能により VPC アタッチメント間の対称的な双方向トラフィック転送が保証されます。つまり、フォワードフローとリバースフローは、そのフローの持続期間中、同じ AZ の同じファイアウォールインスタンスに送信されます。これにより、ファイアウォールは特定のフローの双方向を認識できるため、Appliance VPC 内のステートフルトラフィック検査機能が維持されます。

Appliance Mode の詳細については、ドキュメントまたはこのブログ投稿をご覧ください。フローの安定性を確保するには、アプライアンス VPC に AWS Transit Gateway を 1 つだけ接続する必要があることに注意してください。AWS Transit Gateway はフロー状態情報を互いに共有しないため、複数の AWS Transit Gateway を 1 つのアプライアンス VPC に接続しても、フローの安定性は保証されません。

図 2b: アプライアンス VPC アタッチメントで Transit Gateway Appliance Mode が有効になっている場合の対称トラフィックフロー

特定のユースケース、たとえば下の図 2c に示すように、専用の集中型 Internet Egress Appliance VPC を使用したデプロイでは、VPC アタッチメント間の双方向のトラフィック転送は行われないため、Appliance Mode の有効化は任意です。ただし、Spoke VPC からの特定の AZ のワークロードが他のワークロードよりも多くの下りトラフィックを生成している場合は、それぞれの AZ のファイアウォールが飽和状態になっている可能性があります。トラフィックを両方の AZ のファイアウォールに均等に分散するには、アプライアンス VPC に接続された VPC アタッチメントで Appliance Mode を有効にします。

図 2c: 専用のInternet Egress アプライアンス VPC で Appliance Mode が無効 (デフォルト動作)

要約すると、Appliance Mode は AWS Transit Gateway の VPC アタッチメントではデフォルトで無効になっています。アプライアンス VPC 経由の VPC-to-VPC トラフィック検査では、アプライアンス VPC に接続された VPC アタッチメントで Appliance Mode を有効にする必要があります。ただし、専用の Egress VPC 経由でインターネット宛ての Spoke VPC から発信されるトラフィックを検査する場合、Appliance Mode の有効化は任意です。いずれの場合も、Appliance Mode を有効にすると、AWS Transit Gateway は AZ アフィニティ(*3)を維持しなくなり、トラフィックが AZ を通過できるようになります。AWS データ転送料金の引き下げに関する 2022 年 4 月の発表により、このシナリオでは AZ 間のデータ転送料金は発生しません。

*3: AWSリソースが特定のアベイラビリティーゾーン(AZ)に固定されること

3. Cross-Zone Load Balancing（クロスゾーン負荷分散）を使用するタイミングを理解する

デフォルトでは、ロードバランサーは同じ AZ 内の登録済みアプライアンスにトラフィックを均等に分散します。この構成では、お客様は通常、ファイアウォールサービスの可用性とトラフィックの分散のために、GWLB の背後にある 1 つの AZ 内に複数のターゲットを登録します。1 台のターゲットアプライアンスがヘルスチェックに失敗した場合、GWLB は同じ AZ 内の他の正常なインスタンスにトラフィックをルーティングします。これにより、トラフィックが AZ 境界を越えないため、費用対効果の高いソリューションとなります。このセットアップは費用対効果が高くなりますが、特定の AZ 内のすべてのターゲットに障害が発生した場合、顧客は高可用性とトラフィック分散の両方の側面を失います。

高可用性とバランスのとれたトラフィック分散を実現するために、「クロスゾーン負荷分散」と呼ばれる機能を有効にする別のアプローチを選択するお客様もいます（下の図3 を参照）。この機能により、複数の AZ にまたがるアプリケーションのデプロイと管理が容易になります。クロスゾーン負荷分散を有効にすると、GWLB は、ターゲットがどの AZ にあるかに関係なく、登録されている正常なターゲットすべてにトラフィックを分散します。クロスゾーン負荷分散を有効にすると、トラフィックが AZ を通過するときに標準の AZ 間料金が発生します。

図 3: クロスゾーン負荷分散が有効 (デフォルトでは無効) の場合にフローがどのように分散されるかを示す、GWLB を使用したファイアウォールの典型的なデプロイ構成

4. アプライアンスと AZ の障害シナリオを理解する

ファイアウォールサービスの可用性は、ファイアウォール障害と AZ 障害の 2 つのイベントによって影響を受ける可能性があります。他の AWS ロードバランサー (Classic Load Balancer(CLB)、Application Load balancer(ALB)、Network Load Balancer(NLB)) と同様に、GWLB は VPC で実行されるリージョンサービスであり、AZ 障害に対して回復力があります。ただし、GWLB エンドポイントは AZ リソースであるため、お客様は複数の AZ に GWLBエンドポイントを作成する必要があります (GWLBE として示されている上記の図 3 を参照)。また、他のロードバランサーとは異なり、このような障害イベントが発生した場合、GWLB はフロー管理の点で異なる動作をします（概要については以下の表1を参照してください）。

既存のフロー
ターゲットに障害が発生すると、ALB や NLB などのロードバランサーは既存のフロー/セッションを終了し、リセットシグナルを送信します。ただし、GWLB は透過的なサービスであるため、フェイルオープンモード(*4)で動作します。つまり、本質的にステートフルな既存のフローは、タイムアウトするかクライアントによってリセットされるまで、障害が発生したターゲットに関連付けられ続けるということです。詳細は、既存フローの AWS Gateway ロードバランサーのターゲットフェイルオーバー機能の最近の機能強化を参照してみてください。

*4: ネットワークデバイスが故障した場合に、トラフィックをブロックせずに通過させる動作モードを指します。

新しいフロー
ヘルスチェックの設定（間隔としきい値）に基づいて、ターゲットに異常のフラグが立てられると、GWLB は新しいフローを正常なターゲットに再ルーティングするまでに最大 50〜60 秒の遅延を追加します。新しいフローの再ルーティングを開始する最小時間は最大70秒です。これは、ヘルスチェックの 20 秒(最小間隔: 10 秒、最小しきい値: 2)と GWLB バックエンドが検出して再ルーティングするための 50 秒の合計です。

障害シナリオ	クロスゾーン負荷分散	既存のフロー	新しいフロー
AZ で 1 つの FW に障害が発生	無効	タイムアウトまたはクライアントからのリセットが必要	同じ AZ 内の正常なターゲットに送信
AZ で 1 つの FW に障害が発生	有効	タイムアウトまたはクライアントからのリセットが必要	同じ AZ または複数の AZ 内の正常なターゲットに送信
AZ ですべての FW に障害が発生	無効	少なくとも 1 つのターゲットが復元されるまでタイムアウトまたはドロップ	少なくとも 1 つのターゲットが復元されるまでタイムアウトまたはドロップ
AZ ですべての FW に障害が発生	有効	タイムアウトまたはクライアントからのリセットが必要	AZ 全体の正常なターゲットに送信
AWS リージョンで 1 つの AZ に障害が発生	無効 / 有効	他の AZ を通過するフローは影響を受けません	他の AZ を通過するフローは影響を受けません

表 1: 上の表は、GWLB の既存のフローと新しいフローに関するさまざまな障害シナリオをまとめたものです

既存のフローまたは新しいフローに対する障害イベントの全体的な影響は、それらのフローを処理するファイアウォールインスタンスの数によって異なります。たとえば、10 のファイアウォールが稼働していて、1 つのファイアウォールがダウンすると、最大 70 秒以内にフローの 10 % に影響が及びます。

5. アウトバウンドトラフィック検査で、ワンアームまたはツーアームのファイアウォールデプロイモードを選択する

GWLB は、ファイアウォール導入の 2 つの異なるモデルをサポートしています（下の図 5a と 5b を参照）。ワンアームとツーアーム（ファイアウォールがNATも実行可能）です。

ワンアームモード:下の図 5a に示すように、ファイアウォールはトラフィック検査のためだけにワンアームモードで展開され、NAT ゲートウェイは変換を行います。これは最も一般的な導入方法であり、NAT 機能をサポートするファイアウォールへの依存を排除します。また、NAT を NAT Gateway にオフロードすることで、ファイアウォールのパフォーマンスを向上させます。

図 5a: ワンアームファイアウォールの導入 — NAT Gateway が変換を実行している間、ファイアウォールはトラフィック検査専用です。

ツーアームモード:下の図 5b に示すように、ファイアウォールはツーアームモードで導入され、検査と NAT の両方を実行します。一部の AWS パートナーは、ファイアウォールに NAT 機能を提供しています。GWLB はこのような導入モードでシームレスに統合されます。GWLB で追加の構成変更を行う必要はありません。ただし、ファイアウォールネットワークは異なります。一方のネットワークインターフェースはプライベートサブネット上にあり、もう一方はパブリックサブネット上にあります。このモードには、ファイアウォールパートナーからのソフトウェアサポートが必要です。一部の GWLB パートナー（Palo Alto Networks、Valtix）はこの機能をサポートしていますが、このモードを使用する前に、選択した
AWS パートナーに相談してください。

図　5b: 2アームの FW 展開 — ファイアウォール (ツーアームモード) は検査と変換の両方を実行します。

6.SSL/TLS トラフィック検査で、ワンアームまたはツーアームのファイアウォールデプロイモードを選択する

GWLB は、トラフィックが暗号化されているかどうかに関係なく、透過的なサービスとして機能します。GWLB は TLS フローを終了したり、SSL オフロードを実行したりしません。代わりに、ファイアウォールで復号化とディープパケットインスペクションを実行する必要があります。このユースケースでも、GWLB は 2 つの異なるファイアウォール導入モードをサポートしています（下の図 6a と 6b を参照）。

ワンアームモード:下の図 6a に示すように、ファイアウォールはワンアームモードで展開され、GWLB は暗号化されたトラフィックを通過します。パケットインスペクションプロセス中、ファイアウォールは元の 5 タプル（送信元/宛先 IP、送信元/宛先ポート、プロトコル）を変更せずに復号化して再暗号化します。

図 6a: ファイアウォールは、ワンアームモードで、トラフィックをインターネットに送信する前に復号化して再暗号化します。その逆も同様です。

ツーアームモード:下の図 6b に示すように、ファイアウォールはツーアームモードで展開されます。トラフィックは暗号化されたファイアウォールに入り、インターネットに送信される前に復号化および検査されます。その逆も同様です。このモードでは、ファイアウォールの 2 つのアームにある 2 つのフローのうちの 5 タプルが一致する必要はありません。この機能をサポートする GWLB パートナーには、Check Point、Palo Alto Networks、Trend Micro などがあります。ただし、このモードを使用する前に、選択した AWS パートナーに相談してください。

図 6b: 2 アームモードのファイアウォールは、トラフィックをインターネットに送信する前に復号化および暗号化を行います。その逆も同様です。

まとめ

この投稿では、サードパーティの仮想アプライアンスをより堅牢で、回復力があり、スケーラブルな方法でネットワークアーキテクチャに設計およびデプロイするのに役立つ、Gateway Load Balancer のベストプラクティスについて説明しました。Gateway Load Balancer を今すぐ開始するには、このページにアクセスしてください。 Gateway Load Balancer の詳細については、以下のブログを参照してください。

この投稿に関するフィードバックや質問がある場合は、Amazon Elastic Compute Cloud(EC2) フォーラムで新しいスレッドを開始するか、AWS サポートにお問い合わせください。

この記事の翻訳はソリューションアーキテクトの長屋が担当しました。原文はこちらです。

Amazon Web Services ブログ