VPC PeeringからAWS Transit Gatewayに移行する際のベストプラクティスと考慮事項

この記事では、既存のVPCで利用されているAmazon Virtual Private Cloud (VPC) PeeringからAWS Transit Gatewayへ移行する際の移行手順やシームレスな移行を実現するために対処すべき考慮事項を紹介します。また、iPerfなどの一般的なネットワークテストおよびベンチマークツールについても解説し、考えられるネットワークへの影響や移行時に監視すべきメトリックスを解説します。

背景

VPC Peeringは2014年に開始され、プライベートIPv4アドレスまたはIPv6アドレスを使用してAWS上の異なるネットワーク間でトラフィックをルーティングし、複数の VPC環境でトラフィックをスケーリングできます。VPC接続は、同じアカウントでも、複数のアカウントでも、異なるAWSリージョン (リージョン間VPC Peering接続とも呼ばれます) でもかまいません。AWSの展開を拡大しVPCを追加していくにつれて、多数のVPC間のポイントツーポイント接続を集中的に管理せずに接続性とルーティングポリシーを管理することは運用上の課題となります。VPCの数が数百に膨れ上がるにつれて、この運用上の課題はより複雑になります。VPCのルーティングが複雑になりすぎると、アクティブなVPC Peering接続がクォータを超えることになります。

お客様がこの課題を克服できるように、2018年にTransit Gatewayを発表しました。Transit Gatewayは単一のゲートウェイを使用して、オンプレミスのネットワークと数千のVPCを接続することできます。このハブ＆スポークモデルにより、管理が大幅に簡素化され、運用の複雑さを軽減させることができます。

アーキテクチャの概要

図１はお客様の現在のAWS環境を表すために、us-west-2とus-east-1の2つのAWSリージョンに3つのVPCワークロードを構築したアーキテクチャの例です。リージョン内のVPC Peeringはus-west-2のVPC-AとVPC-Bを接続しています。VPC-Aは、リージョン間VPC Peeringで設定されているus-east-1のVPC-Cとも通信する必要があります。

長期的な成長に対応するスケーラブルなネットワークアーキテクチャを構築できるように、VPC PeeringからTransit Gatewayに移行する方法の概要を説明します。Transit Gatewayはリージョン単位の構成要素であるため、移行するためには、両方のAWS リージョンに構築します。シンプルにするために、このアーキテクチャのワークロードはEC2インスタンスを使用して表現していますが、実際にはコンテナやその他の AWSサービスで構成することもできます。

図１：マルチVPC AWS環境

図２ではVPC-AとVPC-Bの各インスタンス間のVPC間通信をするために既存のリージョン内VPC Peering接続が示されています。各VPCには、宛先IPアドレスがルートテーブルのプレフィックスと一致した場合に、トラフィックをピアリングしたVPCに転送させるためのルーティングテーブルが作成されています。

図２：VPC Peeringのルーティングテーブル設定

VPC PeeringからTransit Gatewayへのトラフィックの移行を行う場合には、以下の３つの一般的なシナリオが考えられます：

1. 同一リージョンVPC-A Subnet 1からVPC-B Subnet 3へのライブトラフィックをシームレスな移行。
2. 同一リージョンのVPC-A Subnet 2 からVPC-B Subnet 4へのライブトラフィックを移行。これにより、パケットドロップが発生する可能性があり、接続の再確立が必要となります。
3. 異なるリージョン間のVPC-A Subnet 1からVPC-C Subnet 5へのトラフィックの移行。

移行のアプローチ

VPC Peering接続から Transit Gatewayへの移行に必要なプロセスに進む前に、まずEC2インスタンスにiPerf3をインストールして設定します。iPerf3は移行プロセス中のインスタンス間で継続的な接続をシミュレーションします。iPerf3はネットワークのパフォーマンス測定とチューニングを行うオープンソースのツールです。この実験ではシンプルなトラフィックフローのテストにiPerf3を使用していますが、iPerf2を使用しても同じテストを実行することもできます。iPerf2はマルチスレッドをサポートしており、AWS Knowledge Centerの記事で説明されているように、高スループットのパフォーマンステストに適しています。今回のシナリオでは、iPerf3のテストでいくつかのフラグをカスタマイズして使用します。詳細については、iPerfのドキュメントを参照してください。また、行きと戻りのトラフィックがどのパスをたどるかを可視化するために、リージョン内のVPC間トラフィックには VPC Reachability Analyzerを使用して分析し、リージョン間のTransit Gateway間のトラフィックには AWS Network Manager Route Analyzerを利用して設定を検証します。

また、Transit Gatewayへの移行の前に、最大伝送単位(MTU)に関する考慮事項があります。移行のシナリオを進めるにあたり、複数回にわたって取り上げられています。詳細については、Transit Gateway MTUセクションを参照してください。

• VPC PeeringからTransit Gatewayに移行する場合、VPC PeeringとTransit Gatewayで強制されるMTUサイズの違いにより、一部の非対称トラフィックがドロップされる可能性があります。ダウンタイムを回避するために、VPCを更新する前に、両方のVPC内のアプリケーションが8500 byteのMTUより小さいパケットで通信していることを確認してください。
• Transit Gatewayは、ICMPv4パケットの場合はFRAG_NEEDEDを生成せず、ICMPv6 パケットの場合もPacket Too Big (PTB)を生成しません。そのため、Path MTU Discovery (PMTUD)はサポートされていません。
• Transit Gatewayは、すべてのパケットに対して最大セグメントサイズ (MSS)クランプを適用します。詳細については、RFC879を参照してください。

移行シナリオ

シナリオ１：同一リージョンのVPC-A Subnet 1からVPC-B Subnet 3へのライブトラフィックの移行 (us-west-2)

最初のシナリオでは、ルートテーブルを更新してトラフィックをTransit Gatewayに移行する方法について説明します。VPC-A Subnet 1からVPC-B Subnet 3へのトラフィックをTransit Gateway経由にするために、より具体的なプレフィックスを使用します。同時にVPC Peering接続を経由した一部のトラフィックを維持することもできます。こうすることで、残りのトラフィックを移行する前に、一部のVPC間トラフィックで検証するためのサブセットのみをシフトすることができます。

移行ステップ：

1. 初期のアーキテクチャが想定通りに動作することを検証するため、図１に示すようにVPC Peering接続で簡単なテストを実行します。VPC-A Subnet 1 (10.1.11.0/24)のinstance-1を通信時のサーバー（レシーバー）として、VPC-B Subnet 3  (10.2.11.0/24)の instance-3をクライアント（センダー）としてiPerf3テストを開始します。サーバー側（Linux Platform上）では、次のコマンドを実行します。
   >sudo perf3 -s
2. クライアント側で次のコマンドを実行します。
   >sudo iperf3 -c <server ip> -V
3. 赤で囲まれた部分で示されているように、iPerf3はVPC Peering接続が9001 byteのMTUをサポートしていることを検出しています。このシナリオの間、継続的にiPerfトラフィックを実行して、移行中の継続的なライブトラフィックをシミュレートしてください。
   

   図３：VPC Peering接続上のiPerf3テスト

4. 最大セグメントサイズをTransit GatewayがサポートするMTU以下、例えば、8500 byteになるように、-M 8448フラグを使用して設定します。クライアントinstance-3で次のiPerf3コマンドを実行します。
   >sudo iperf3 -c <server ip> -V -M 8448 -t 180
5. ルーティングテーブルにて、より具体的なプレフィックスを指定し、これらのサブネットをTransit Gatewayへ向けることで最初の移行を開始します。ルーティングテーブルの更新を次の図に示します。/24はVPC peering接続の/16のエントリーよりも具体的なプレフィックスであるため、このサブネットのトラフィックはTransit Gatewayを経由するようになります。
   

   図４：サブネット間のトラフィックをTransit Gatewayに移行するルーティングテーブル

6. iPerf3の実行が終了したことを確認し、ルートテーブル更新中にトラフィックが切断されなかったことを確認することができます。
   

   図５：ルーティング変更によって切断されなかったiPerfトラフィック

7. また、VPCのルートテーブル上に設定した特定のルートにより、VPC-A Subnet 1 (10.1.11.0/24)のinstance-1とVPC-B Subnet 3のinstance-3 (10.2.11.0/24)の間のトラフィックはTransit Gateway接続を経由して通信されていることを検証することができます。一方でVPC-A Subnet 2 (10.1.12.0/24)のinstance-2とVPC-B Subnet 4 (10.2.12.0/24)サブネットのinstance-4はVPC peering 接続を経由して通信し続けていることが確認できます。これらは、VPC内の送信元と宛先間の接続テストを実行が可能な設定分析ツールである、Amazon VPC Reachability Analyzerを使用して確認することも可能です。宛先が到達可能な場合、Reachability Analyzerは送信元と宛先間の仮想ネットワークパスの詳細をホップ毎に作成します。宛先に到達できない場合、Reachability Analyzerはブロックしているコンポーネントを特定します。例えば、セキュリティグループ、ネットワークACL、ルートテーブル、またはロードバランサーの設定の問題によって経路がブロックされることがあります。ドキュメントに記載されているように、送信元と宛先間のパス分析を作成することができます。２つのインスタンスペアの解析結果は図６に示されています。
   

   図６：Transit Gateway経路とVPC Peering経路におけるVPC Reachability分析結果

8. このシナリオはVPC-A Subnet 2とVPC-B Subnet 4からのトラフィックが、引き続きVPC Peering接続を経由する形で分割されたネットワークを持った状態で終了します。一方で、VPC-A Subnet 1とVPC-B Subnet 3からのトラフィックはTransit Gatewayに正常に移行されています。
   

   図７：Transit GatewayとVPC peering間で分割された状態のトラフィック

シナリオ2：同一リージョン内のVPC-A Subnet 2からVPC-B Subnet 4へのライブトラフィックの移行における非対称ルーティングの影響

このシナリオではパケットのMTUが9001 byteを使用しているワークロードの移行と、VPC PeeringからTransit Gatewayに移行する際に既存のトラフィックフローにどのような影響を引き起こす可能性があるのかを見ていきます。異常なアプリケーションの動作や潜在的な停止を引き起こす可能性があります。

このシナリオは以下のステップで構成されています：

1. -MフラグをTCP MSS 8949、MTUを9001に固定して、iPerf3テストを開始します。残りのサブネットVPC-A Subnet 2 (10.1.12.0/24)とVPC-B Subnet 4 (10.2.12.0/24)を利用して同じように移行を試します。テストでは、VPC-B Subnet 4のinstance-4がクライアントで、VPC-A Subnet 2のinstance-2がサーバーです。VPC-Bのルートテーブルを更新し、Transit Gatewayを経由して通信されるVPC-A Subnet 2 (10.1.12.0/24)サブネット宛トラフィックのルートエントリを追加します（図 8を参照）。
   

   図８：Transit Gatewayを経由するように、VPC-A Subnet 2のエントリを追加した、更新後のVPC-Bのルートテーブル

2. VPCのルートテーブルはルート評価中にもっとも具体的にプレフィックスが一致しているルートを優先するため、送信トラフィックはTransit Gateway接続を経由してルーティングされます。ただし、両方のルートテーブルが更新されるまで、instance-2からinstance-4への戻りのトラフィックはVPC peering接続を経由するため、非対称ルーティングとなります。送信トラフィックは8949のMSS (MTU 9001)を利用しているため、VPC-Bのルートテーブルの変更が行われると、Transit Gatewayでは図９と図１０で示したように、パケットをドロップします。
   

   図９：Transit Gateway attachmentによりパケットがドロップされiPerf3フローが中断される様子

   

   図１０：Transit Gateway attachmentによりパケットがドロップされiPerf3フローが中断される様子

3. 前ステップ１、２ではクライアントインスタンスのVPCのルートテーブルが更新され、10.1.12.0/24サブネットへルーティング時にTransit Gatewayを優先するようになりました。つまり、ネットワークホップの最初のステップはTransit Gateway attachmentです。次のステップでは逆のシナリオを示しましょう。つまり、クライアントであるinstance-4がサーバとなるinstance-2に対してpeering接続を経由してトラフィックを送信し、instance-2がTransit Gatewayを経由して応答する場合の動作を見てみます。次のステップに進む前に、VPC-Bのルートをもとに戻し、Transit Gatewayに向けられた10.1.12.0/24のエントリを削除してください。
4. 前ステップと同様に-Mフラグを使用してTCP MSSを8949、MTU 9001に固定してiPerf3テストを開始します。Transit Gateway attachmentを経由してトラフィックを送信するために、VPC-A Subnet 2のルートテーブルを次の図に示すような形で、VPC-B Subnet 4 (10.2.12.0/24)宛のトラフィックに対するルートエントリを追加します。
   

   図１１：VPC-A/VPC-Bの更新後のルートテーブル

5. ただし、この場合は、以前と同様なトラフィックの切断は発生しません。これは、クライアントであるinstance-4からサーバとなるinstance-2への転送トラフィックがVPC peering接続を経由しているためです。そのため、Transit Gatewayの制限が適用されません。戻りのトラフィック、instance-2からinstance-4へのトラフィックはTransit Gatewayを経由することになりますが、ドロップはされません。これは、iPerf3がVPC peering接続で9001 byteのMTUパケットを送信し、逆方向にはより小さいサイズのパケット、またはおそらくパケットが送信されていないためです。この動作は図１２と１３で確認ができます。
   

   図１２：VPC Peering接続を経由した切断されない状態のトラフィックフロー

   

   図１３：VPC Peering接続を経由した切断されない状態のトラフィックフロー

6. -Rフラグを利用してiPerf3テストをリバースモード（つまり、サーバが送信し、クライアントが受信する場合）で実行した場合に、Transit GatewayのMTUの適用動作を確認することができます。サーバーであるinstance-2から送信される9001 byteのMTUパケットがVPC-A Subnet 2 (10.1.12.0/24)のTransit Gateway attachmentにヒットし、ドロップされることを確認できます。
   

   図１４：VPC-A Subnet 2のTransit Gateway attachmentによってドロップされた状態のリバースiPerfフロー

このシナリオで確認したように、非対称ルーティングはトラフィックが単方向か双方向かによって奇妙な動作を引き起こすことがあります。この問題を解決するためには、移行を完了するか既存の接続を再確立する前に、アプリケーションでMTUが8500 byte未満のパケットを使用するように更新する必要があります。また、非対称ルーティングを回避するためにルートテーブルも同時に更新する必要があります。両方の変更はサービスに影響を与える可能性があるため、注意深く計画する必要があります。

最後に移行を完了するためにクリーンアップを行います。/16 CIDRをTransit Gateway attachmentをターゲットにするように変更し、/24ルートを削除します。これにより、すべてのトラフィックがTransit Gateway attachmentを経由して通信するようになり、特定のサブネットのルートが必要なくなります。また、EC2インスタンス（instance-2とinstance-4）のペアでVPC Reachability Analyzerを使用してトラフィックパスを最終的に確認することもできます。VPC Peering接続は必要がないため、削除して取り除くことができます。

図１５：Transit Gatewayの/16エントリーを含む更新後のルートテーブル

シナリオ3：異なるリージョンのVPC-A Subnet 1からVPC-C Subnet 5へのトラフィックの移行

このシナリオでは、リージョン間のVPC PeeringからTransit Gatewayピアリング接続へのトラフィック移行をシームレスに行います。このトラフィック移行には、前述と同様のステップがあり、MTUサイズに関する同様な考慮事項もあります。ただし、唯一の違いは、リージョン間VPC Peeringを経由したMTUサイズが1500 byteに制限されていることです。これに対して、リージョン内のVPC Peeringでは9001 byteがサポートされています。したがって、この場合、リージョン間のVPC PeeringからTransit Gateway Peering接続にトラフィックを移行する際に、Transit GatewayでMTUの制限を超えてパケットがドロップを起こすことはほとんどありません。

考慮事項

• この移行の例では、移行中もiPerfの接続は維持されていますが、VPC PeeringとTransit Gateway接続間には共有されたセッションがありません。したがって、データベース接続などの長時間維持される接続は再接続する必要があります。AWSでは、これをサービスに影響を与えるイベントとして計画することを推奨しており、これらの接続を切断して、再接続できるようなメンテナンスウィンドウをスケジュールする必要があります。
• ほとんどの場合で、アプリケーションはホストされているEC2インスタンスのMTU設定を使用し、EC2インスタンス間でネゴシエーションされたMTUがパケットの送信に使用されます。アプリケーションが実行されているインスタンスのMTUを確認および設定するには、EC2 Network MTUドキュメントを参照してください。
• Transit Gatewayのベストプラクティスを考慮する必要があります。Transit Gatewayを介してAWS Hyperplaneネットワークを経由し、リージョン内のトラフィックが通過する場合、VPC Peeringと比較して追加の遅延が発生する可能性があります。ネットワークとアプリケーションのレイテンシー要件を確認し、ネットワークトポロジーを変更する前に十分なテストを行うことを確認してください。
• ネットワークアドレス使用状況 (NAUs) はVPC内のリソースに適用されるメトリックスで、VPCのサイズを計画および監視するために役立ちます。各NAUユニットはVPCを表す合計に寄与します。これらのNAUユニットはVPCがPeeringされているか、同一または別のAWSリージョンにあるか、またはTransit Gatewayを経由して接続されているかに基づいて計算されます。したがって、VPCをスケーリングする際には、VPCのNAUを構成するユニットの総数を把握することが重要です。詳細と例については、NAUドキュメントを、詳細についてはDesigning hyperscale Amazon VPC networksを参照してください。

まとめ

この記事では、VPC PeeringからTransit Gatewayベースのネットワークアーキテクチャに移行するための様々なシナリオを紹介しました。AWS環境とVPCがビジネスの成長に合わせて拡大するにつれて、ネットワークアークテクチャを柔軟性、使いやすさ、スケーラビリティをサポートするように計画する必要があります。これにより、異なるネットワークの接続、ルートテーブルの管理、ネットワークのセキュリティを手動で行う作業量を減らすことができます。VPC PeeringとTransit Gatewayの技術的な違いを注意深く計画して理解することで、Transit Gatewayを利用したスケーラブルなAWSに移行することができます。

(本記事は 2023/04/26に投稿された Best practices and considerations to migrate from VPC Peering to AWS Transit Gatewayを翻訳した記事です。)