この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
Direct Connect GatewayとVPCの直結構成から、Direct Connect GatewayとTransit Gatewayの併用構成にダウンタイムを少なく移行したい
こんにちは、のんピ(@non____97)です。
皆さんはTransit Gatewayは好きですか? 私は大好きです。自称Transit Gatewayおじさんです。
Transit Gatewayを使うことによって、オンプレミス環境と多数のVPCを接続したい場合や、複数のVPCを互いに接続したい場合にネットワークアーキテクチャを簡素化することができます。
しかし、最初からTransit Gatwayを使用されている方はそこまで多くないのではないのでしょうか。
恐らく、多くの方が以下のようにPrivate VIFを用意して、Direct Connect Gatewayを使ってオンプレミス環境とVPCを接続しているのではないでしょうか。
そこで、今回は「Direct Connect GatewayとTransit Gatewayの併用構成になるべくダウンタイム少なく移行したいなぁ」という方向けに、Direct Connect GatewayとVPCの直結構成から、Direct Connect GatewayとTransit Gatewayの併用構成への移行手順をまとめます。
いきなりまとめ
- Direct Connect GatewayとTransit Gatewayの併用構成にするためには、Transit VIFが必須
- Transit VIFを取り扱っているかをネットワーク回線事業者に確認する
- 新規にDirect Connect Gatewayを用意する
- Virtual Private Gatewayと関連付いているDirect Connect Gatewayに、追加でTransit Gatewayを関連付けることはできない
- Direct Connect Gatewayの「許可されたプレフィックス」を活用して、通信経路を制御する
- Transit Gateway AttachmentをVPCに追加しても、VPCのルートテーブルを変更するまで通信経路は変わらない
- 非対称ルーティングが発生しても正常に通信ができるかをネットワーク回線事業者に確認する
- Virtual Private Gatewayと既存Direct Connect Gatewayの関連付けを解除をするタイミングでダウンタイムが発生する
- 移行作業完了後、不要なリソースを削除する
検証の環境
検証の環境は以下の通りです。
ネットワーク回線事業者のWANのサービスから、Private VIFの延ばして、Direct Connect Gateway経由でVPCに接続しています。
これを最終的に以下のように、Direct Connect GatewayとTransit Gatewayの併用構成に切り替えます。
Direct Connectを使用する際は、多くの方がAWS Direct Connect デリバリーパートナーが提供している接続サービスを使用して、オンプレミス環境とVPCを接続していると思われます。
今回の検証でも、そのような接続サービスを利用しており、利用者側でルーター(上述の図の「NWパートナー機器」や「WAN内機器」)の設定変更はできないという仮定で作業をします。
また、AWSに割り当てるためのネットワークとして10.1.0.0/16を予約しているものとします。
それでは、次の章からDirect Connect GatewayとVPCの直結構成から、Direct Connect GatewayとTransit Gatewayの併用構成への具体的な移行手順を紹介します。
1. Transit VIFを用意する
まず、Transit VIFを用意します。
Transit VIFはDirect Connect GatewayとTransit Gatewayの併用構成を採用するために必須となります。Private VIFではDirect Connect GatewayとTransit Gatewayの併用構成をすることはできません。
Transit VIFはAWS Direct Connect デリバリーパートナーが提供しているサービスを利用して、用意します。
AWS Direct Connect デリバリーパートナーがTransit VIFを用意できるかは、AWS Direct Connect デリバリーパートナーが提供しているサービス仕様を確認して判断します。
例えば、NTT CommunicationsさんのFIC-Connection AWSというサービス仕様を確認すると、Transit VIFを扱っていることが分かります。
Transit VIFがAWS Direct Connect デリバリーパートナーによって作成されると、マネージメントコンソールより仮想インターフェースのタイプがtransitのVIFを確認することができます。
具体的なTransit VIFの払い出しの手順や手続きは、お付き合いのあるAWS Direct Connect デリバリーパートナーへお問い合わせください。
作業後の構成図を図示すると、以下のようになります。
2. Direct Connect Gatewayの作成
次にDirect Connect Gatewayを作成します。
「既に存在しているDirect Connect Gatewayを使えば良いのでは?」と思われるかもしれませんが、Virtual Private Gateway(以降VGW)と関連付いているDirect Connect Gatewayに追加でTransit Gatewayを関連付けようとすると、Cannot associate Transit Gateway to a Direct Connect Gateway that has Virtual Gateways associatedとエラーが表示されます。
そのため、新規でDirect Connect Gatewayを作成する必要があります。
Direct Connect Gatewayの名前とASNを指定して、Direct Connect ゲートウェイを作成するをクリックして、作成します。ASNは既存のDirect Connect Gatewayと被らないように64513を指定しました。
Direct Connect Gatewayの作成が完了すると、以下のように表示されます。
3. 新規に作成したDirect Connect GatewayとTransit VIFの関連付け
新規に作成したDirect Connect GatewayとTransit VIFを関連付けます。
関連付けたいTransit VIFを選択して、承諾するをクリックします。
次に、Transit VIFと関連付けたいDirect Connect Gatewayを選択して、仮想インターフェイスを承諾するをクリックします。
しばらくすると、Transit VIFの状態がpending→downと変化し、最終的にavailableとなります。併せてBGPのステータスもavailableとなっていることを確認します。また、Amazon側のASNは10124からDirect Connect Gatewayで設定したASNである64513に変化しています。
作業後の構成図を図示すると、以下のようになります。
4. Transit Gatewayの作成
Transit Gatewayを作成します。
ASNは既存のDirect Connect Gatewayや、新規に作成したDirect Connect Gatewayと重複しないように64531を選択しました。また、Transit Gateway Attachment毎に任意のTransit Gateway Route Tableを関連付けたいので、Default association route tableとDefault propagation route tableはdisableにしました。
作成後しばらくすると、Transit GatewayのStateがavailableとなります。
5. 新規に作成したDirect Connect GatewayとTransit Gatewayの関連付け
新規に作成したDirect Connect GatewayとTransit Gatewayを関連付けます。
作成したDirect Connect Gatewayを選択して、ゲートウェイの関連付けタブのゲートウェイを関連付けるをクリックします。
関連付けるTransit Gatewayを選択して、許可されたプレフィックスを入力して、ゲートウェイを関連付けるをクリックします。
ここで、許可されたプレフィックスについて補足します。
Transit Gatewayに接続したVPCのCIDRはそのままオンプレミス環境にアドバタイズされず、Direct Connect Gatewayの「許可されたプレフィックス」で指定した任意のCIDRがアドバタイズされます。
ここで、許可されたプレフィックスをVPCのCIDRと同じ10.1.0.0/24とすると、Private VIFと接続しているWAN内機器 BとTransit VIFと接続しているWAN内機器 CからアドバタイズされるCIDRがどちらも10.1.0.0/24となります。そのため、WAN内機器 Aのルーティングテーブルを見ただけでは、10.1.0.0/24へのネクストホップがWAN内機器 BなのかWAN機器 Cなのか判断できません。
ここで、WAN内機器 Aを確認及び、操作ができるのであれば、Local Preferenceで優先パスを指定することができますが、今回の縛りではそれができません。今回はその解決策として、Transit VIFと接続しているWAN内機器 CからアドバタイズするCIDRをわざと大きくします。
具体的には、許可されたプレフィックスで、AWSに割り当てるためのネットワークとして予約している10.1.0.0/16を指定します。
こうすることで、Private VIFと接続しているWAN内機器 Bからは10.1.0.0/24、Transit VIFと接続しているWAN内機器 CからアドバタイズされるCIDRは10.1.0.0/16となります。ルーティングはロンゲストマッチ(最も具体的なネットワーク)の経路を優先します。そのため、10.1.0.0/24のVPC上のEC2インスタンスにアクセスする際、WAN内機器 AのネクストホップはWAN内機器 Bとなります。
Direct Connect GatewayとTransit Gatewayの関連付けをして、しばらく待つと、状態がassociatedになります。
また、VPCのコンソールより、Transit Gateway Attachmentを確認すると、Resource typeがDirect Connect GatewayのTransit Gateway Attachmentが作成されていることが確認できます。
作業後の構成図を図示すると、以下のようになります。
なお、仮にTransit Gatewayとの接続に対する許可されたプレフィックスをVPCのCIDRにしてしまった場合でも、継続してPrivate VIF側にルーティングされるケースもあります。例えばCiscoルーターやJuniperルーターではeBGPから学習したルートの最も古いルートが優先されます。
Ciscoルーターの場合
両方のパスが外部のときは、先に受信したパス（最も古いパス）が優先されます。
この手順によってルートフラップが最小限に抑えられます。これは、たとえ次の決定条件（手順 11、12、および 13）に基づいて新しい方のパスが優先ルートになった場合でも、新しい方のパスによって古い方のパスが置き換えられないためです。
Juniperルーターの場合
両方のパスが外部にある場合、最も古いパス、つまり、最初に学習されたパスを優先します。これは、ルートフラッピングを最小限に抑えるために行われます。このルールは、以下の条件のいずれかに該当する場合には使用されません。
- -path-selection external-router-id が設定されています。
- 両方のピアが同じルーター ID を持っています。
- どちらのピアもコンフェデレーションピアです。
- どちらのパスも現在アクティブなパスではありません。
6. Transit Gateway Attachment用のサブネットの作成
Transit Gateway Attachment用のサブネットの作成します。
Transit Gateway Attachmentは他のAWSリソースと同居させず、独立したTransit Gateway Attachment用のサブネットを作成することが推奨されています。
同居させた場合、同一のルートテーブルを参照することになるため、その影響を回避することが目的です。影響が発生するケースとしては、通信を監査用インスタンスにインターセプトさせたいなど、特殊なルーティングをしたい場合になります。
Q. VPC をアタッチするときに指定するサブネットをアタッチ専用のサブネットとする必要性について、もう少し具体例を挙げて説明していただきたいです。そのサブネットの内部のEC2 インスタンスのルーティングに影響あるとのことでしたが、どのような影響があるのか？などを教えていただきたいです。
A. Transit Gateway (TGW) のアタッチメントがついているサブネットと同一のサブネットに EC2 インスタンスが存在する場合に、その EC2 インスタンスはTGWと同じルーティングテーブルを参照します。 例えば インライン監査用の VPC の TGW の ENI がある Subnet 上に EC2 インスタンスを設置してしまうと、その EC2 インスタンスは必ずインライン監査のミドルボックス ENI に吸い込まれてしまい、EC2 インスタンスの意図するルーティングテーブルを作れなくなってしまいます。こういったことを防ぐために、TGW 専用のサブネットを作ることをお薦めしています。 こちらおよびこちらの資料を併せてご参照ください。
[AWS Black Belt Online Seminar] AWS Transit Gateway 資料及び QA 公開
今回はTransit Gateway Attachment用のサブネットとして、10.1.0.64/27のサブネットを作成をしました。
作業後の構成図を図示すると、以下のようになります。
7. VPC用のTransit Gateway Attachmentの作成
VPC用のTransit Gateway Attachmentを作成します。
特別な設定はなく、作成したTransit Gateway Attachment用のサブネットを指定して作成します。
Create attachmentクリック後にTransit Gateway Attachmentの一覧を確認すると、Resource typeがVPCのTransit Gateway Attachmentが作成されていることが確認できます。
作業後の構成図を図示すると、以下のようになります。
8. Transit Gateway Route Tableの設定
VPC及び、Direct Connect Gateway用のTransit Gateway Attachmentと関連付けるTransit Gateway Route Tableを作成します。
まず、VPC用のTransit Gateway Route Tableです。
Transit Gateway Route TableのNameタグの入力と、Transit Gatewayを選択して、Create Transit Gateway Route Tableをクリックします。
VPC用のTransit Gateway Route Tableの作成が完了したことを確認します。
次にルーティングの設定を行います。
RoutesタブのCreate static routeをクリックします。
ここで、10.0.0.0/16宛の通信はDirec Connect Gatewayのアタッチメントを通るように設定し、Create static routeをクリックします。
ルート一覧で、対象のルートが追加されたことを確認します。
同様にDirect Connect Gateway用のTransit Gateway Route Tableも作成します。
VPCの時と同様に、Transit Gateway Route TableのNameタグの入力と、Transit Gatewayを選択して、Create Transit Gateway Route Tableをクリックします。
Direct Connect Gateway用のTransit Gateway Route Tableの作成が確認できた後、ルーティングの設定を行います。
10.1.0.0/16宛の通信はVPCのアタッチメントを通るように設定し、Create static routeをクリックします。
ルート一覧で、対象のルートが追加されたことを確認します。
作業後の構成図を図示すると、以下のようになります。
9. Transit Gateway Route TableとTransit Gateway Attachmentの関連付け
作成したTransit Gateway Route TableとTransit Gateway Attachmentとを関連付けます。
まずは、VPC用のTransit Gateway Route TableとTransit Gateway Attachmentとを関連付けます。
VPC用のTransit Gateway Route TableのAssociationsタブからCreate associationをクリックします。
Choose attachment to associateで、VPC用のTransit Gateway Attachmentを選択し、Create associationをクリックします。
しばらくすると、対象の関連付けのStateがassociatedになります。
続いて、Direct Connect Gateway用のTransit Gateway Route TableとTransit Gateway Attachmentとを関連付けます。
Direct Connect Gateway用のTransit Gateway Route TableのAssociationsタブからCreate associationをクリックします。
Choose attachment to associateで、Direct Connect Gateway用のTransit Gateway Attachmentを選択し、Create associationをクリックします。
しばらくすると、対象の関連付けのStateがassociatedになります。
作業後の構成図を図示すると、以下のようになります。
10. オンプレミス環境への通信がTransit Gatewayを向くようにVPCのルートテーブルを変更
オンプレミス環境への通信がTransit Gatewayを向くようにVPCのルートテーブルを変更します。
現在のVPCのルートテーブルは以下のようになっています。Transit Gatewayを経由して通信をするために、VGW宛のルートをTransit Gateway宛に変更します。
Transit Gatewayに向くようにルートテーブルを変更することで非対称ルーティングが発生します。非対称ルーティングが発生による注意点及び、発生するタイミングについて補足します。
まず、現在の通信経路は以下の様になっています。(オレンジの矢印が通信経路)
続いて、以下がVPCのルートテーブルを変更して、オンプレミス環境への通信がTransit Gatewayに向くように変更した場合の通信経路です。
Transit Gatewayを経由して通信をさせるために、Private Subnetのルートテーブルにて、10.0.0.0/16へのターゲットをVGWからTransit Gatewayに変更します。
このようにすることで、行きと戻りの通信経路が異なる「非対象ルーティング」の状態になります。
非対象ルーティングが発生することによって、WAN内機器 Aからすると、意図しないVLANからパケットが戻ってくることになります。仮に、WAN機器 Aにてステートを管理する機能を有している場合に、戻りのパケットが異常なパケットと判断され、パケットをドロップしてしまう可能性があります。
このような非対称ルーティングが発生しても、パケットのドロップが発生しないかは、事前にネットワーク回線事業者にお問い合わせください。
仮にドロップしてしまう場合は、ダウンタイムを最小限にするため、VPCのルートテーブルの変更作業と後述する11. 既存Direct Connect GatewayとVirtual Private Gatewayの関連付け解除の作業を同期的に実施する必要があります。
一方でドロップしない場合は、VPCのルートテーブル変更後の都合の良いタイミングで11. 既存Direct Connect GatewayとVirtual Private Gatewayの関連付け解除の作業を実施することが可能です。
それでは、オンプレミス環境への通信がTransit Gatewayに向くように、VPCのルートテーブルの変更作業に移ります。
まず、実際にルートテーブルを変更する前に、tracertで現在のオンプレミス環境への通信経路を確認します。
EC2インスタンスからオンプレミス環境上のリソース(10.0.0.10)に対してtracertを実行すると、以下のようにPrivate VIFを通っていることが確認できました。
> tracert -d 10.0.0.10
10.0.0.10 へのルートをトレースしています
経由するホップ数は最大 30 です:
1 1 ms <1 ms <1 ms 169.254.252.1
2 2 ms 2 ms 2 ms 10.0.1.205 # <- Private VIFのAmazon ルーターのピア IP
3 5 ms 4 ms 4 ms 10.0.1.206 # <- Private VIFのルーターのピア IP
4 * 6 ms 5 ms 10.0.1.2
5 8 ms 8 ms 8 ms 10.0.1.1
6 8 ms 8 ms 8 ms 10.0.1.250
7 8 ms 8 ms 8 ms 10.0.0.10
トレースを完了しました。また、非対称ルーティングが発生したことで通信ができなくなることを素早く察知するために、以下コマンドで定期的にpingを打ち続けます。
> ping -t 10.0.0.10| ?{$_ -ne ""} | %{(Get-Date).ToString() + " $_"}
2021/09/08 14:32:27 10.0.0.10 からの応答: バイト数 =32 時間 =7ms TTL=59
2021/09/08 14:32:28 10.0.0.10 からの応答: バイト数 =32 時間 =7ms TTL=59
2021/09/08 14:32:29 10.0.0.10 からの応答: バイト数 =32 時間 =7ms TTL=59
2021/09/08 14:32:30 10.0.0.10 からの応答: バイト数 =32 時間 =7ms TTL=59
2021/09/08 14:32:31 10.0.0.10 からの応答: バイト数 =32 時間 =7ms TTL=59
2021/09/08 14:32:32 10.0.0.10 からの応答: バイト数 =32 時間 =7ms TTL=59
(以下略)以上で準備が完了したので、実際にオンプレミス環境への通信がTransit Gatewayを向くようにVPCのルートテーブルを変更します。
VGWがルートに含まれるルートテーブルを選択して、ルートタブのルートを編集をクリックします。
送信先が10.0.0.0/16のターゲットがVGWとなっていたため、ターゲットをTransit Gatewayに変更します。変更後、変更を保存をクリックします。
送信先が10.0.0.0/16のターゲットがVGWからTransit Gatewayに変更されている事を確認します。
ルートテーブルの変更作業後、pingの実行状態を確認して、連続して要求がタイムアウトしました。と表示されていないことを確認します。継続してpingが正常に実行できている場合は、問題ありません。
最後に、本当にTransit Gatewayを経由して通信を行なっているのかを確認します。
作業前と同様に、EC2インスタンスからオンプレミス環境上のリソース(10.0.0.10)に対してtracertを実行すると、意図した通りにTransit VIFを通っていることが確認できました。
> tracert -d 10.0.0.10
10.0.0.10 へのルートをトレースしています
経由するホップ数は最大 30 です:
1 * * * 要求がタイムアウトしました。
2 <1 ms <1 ms <1 ms 169.254.252.5
3 3 ms 3 ms 3 ms 10.10.255.50 # <- Transit VIFのAmazon ルーターのピア IP
4 4 ms 4 ms 4 ms 10.10.255.49 # <- Transit VIFのルーターのピア IP
5 4 ms 4 ms 4 ms 10.10.255.35
6 * * * 要求がタイムアウトしました。
7 6 ms 6 ms 6 ms 10.0.1.1
8 7 ms 7 ms 6 ms 10.0.1.250
9 7 ms 7 ms 7 ms 10.0.0.10
トレースを完了しました。なお、今回はVGWがルートに含まれるルートテーブルは1つでしたが、ルートテーブルが複数存在している場合は、このタイミングでターゲットがVGWとなっているルートを全てTransit Gatewayに変更します。
11. 既存Direct Connect GatewayとVirtual Private Gatewayの関連付け解除
既存Direct Connect GatewayとVGWの関連付けを解除します。
この作業を実施することで、既存Direct Connect Gateway及び、Private VIFを介してVPCと通信ができなくなります。また、VPCから既存Direct Connect Gateway及び、Private VIFに繋がっている機器へ経路情報がアドバタイズされなくなります。
結果として、VPC上のEC2インスタンスにアクセスする際は、行きと戻りの通信どちらもTransit VIFを通るようになります。
それでは、既存Direct Connect GatewayとVGWの関連付け解除作業に移ります。
既存Direct Connect Gatewayのゲートウェイの関連付けタブからVGWを選択し、関連付けを解除するをクリックします。
確認画面が出るので、関連付けを解除するをクリックします。
関連付けの解除が完了すると、ゲートウェイの関連付けが正常に解除されました。と表示されます。
このタイミングでダウンタイムが発生します。Pingの実行結果から判断すると、今回は5分程度のダウンタイムでした。
2021/09/08 14:40:37 10.0.0.10 からの応答: バイト数 =32 時間 =7ms TTL=59
2021/09/08 14:40:38 10.0.0.10 からの応答: バイト数 =32 時間 =7ms TTL=59
2021/09/08 14:40:39 10.0.0.10 からの応答: バイト数 =32 時間 =7ms TTL=59
2021/09/08 14:40:40 10.0.0.10 からの応答: バイト数 =32 時間 =7ms TTL=59
2021/09/08 14:40:41 10.0.0.10 からの応答: バイト数 =32 時間 =7ms TTL=59
2021/09/08 14:40:42 10.0.0.10 からの応答: バイト数 =32 時間 =7ms TTL=59
2021/09/08 14:40:43 10.0.0.10 からの応答: バイト数 =32 時間 =6ms TTL=59
2021/09/08 14:40:44 10.0.0.10 からの応答: バイト数 =32 時間 =7ms TTL=59
2021/09/08 14:40:45 10.0.0.10 からの応答: バイト数 =32 時間 =6ms TTL=59
2021/09/08 14:40:50 要求がタイムアウトしました。
2021/09/08 14:40:55 要求がタイムアウトしました。
2021/09/08 14:41:00 要求がタイムアウトしました。
2021/09/08 14:41:05 要求がタイムアウトしました。
2021/09/08 14:41:10 要求がタイムアウトしました。
2021/09/08 14:41:15 要求がタイムアウトしました。
2021/09/08 14:41:20 要求がタイムアウトしました。
2021/09/08 14:41:25 要求がタイムアウトしました。
2021/09/08 14:41:30 要求がタイムアウトしました。
2021/09/08 14:41:35 要求がタイムアウトしました。
2021/09/08 14:41:40 要求がタイムアウトしました。
2021/09/08 14:41:45 要求がタイムアウトしました。
2021/09/08 14:41:50 要求がタイムアウトしました。
2021/09/08 14:41:55 要求がタイムアウトしました。
2021/09/08 14:42:00 要求がタイムアウトしました。
2021/09/08 14:42:05 要求がタイムアウトしました。
2021/09/08 14:42:10 要求がタイムアウトしました。
2021/09/08 14:42:15 要求がタイムアウトしました。
2021/09/08 14:42:20 要求がタイムアウトしました。
2021/09/08 14:42:25 要求がタイムアウトしました。
2021/09/08 14:42:30 要求がタイムアウトしました。
2021/09/08 14:42:35 要求がタイムアウトしました。
2021/09/08 14:42:40 要求がタイムアウトしました。
2021/09/08 14:42:45 要求がタイムアウトしました。
2021/09/08 14:42:50 要求がタイムアウトしました。
2021/09/08 14:42:55 要求がタイムアウトしました。
2021/09/08 14:43:00 要求がタイムアウトしました。
2021/09/08 14:43:05 要求がタイムアウトしました。
2021/09/08 14:43:10 要求がタイムアウトしました。
2021/09/08 14:43:15 要求がタイムアウトしました。
2021/09/08 14:43:20 要求がタイムアウトしました。
2021/09/08 14:43:25 要求がタイムアウトしました。
2021/09/08 14:43:30 要求がタイムアウトしました。
2021/09/08 14:43:35 要求がタイムアウトしました。
2021/09/08 14:43:40 要求がタイムアウトしました。
2021/09/08 14:43:45 要求がタイムアウトしました。
2021/09/08 14:43:50 要求がタイムアウトしました。
2021/09/08 14:43:55 要求がタイムアウトしました。
2021/09/08 14:44:00 要求がタイムアウトしました。
2021/09/08 14:44:05 要求がタイムアウトしました。
2021/09/08 14:44:10 要求がタイムアウトしました。
2021/09/08 14:44:15 要求がタイムアウトしました。
2021/09/08 14:44:20 要求がタイムアウトしました。
2021/09/08 14:44:25 要求がタイムアウトしました。
2021/09/08 14:44:30 要求がタイムアウトしました。
2021/09/08 14:44:35 要求がタイムアウトしました。
2021/09/08 14:44:40 要求がタイムアウトしました。
2021/09/08 14:44:45 要求がタイムアウトしました。
2021/09/08 14:44:50 要求がタイムアウトしました。
2021/09/08 14:44:55 要求がタイムアウトしました。
2021/09/08 14:45:00 要求がタイムアウトしました。
2021/09/08 14:45:05 要求がタイムアウトしました。
2021/09/08 14:45:10 要求がタイムアウトしました。
2021/09/08 14:45:15 要求がタイムアウトしました。
2021/09/08 14:45:16 10.0.0.10 からの応答: バイト数 =32 時間 =6ms TTL=57
2021/09/08 14:45:17 10.0.0.10 からの応答: バイト数 =32 時間 =6ms TTL=57
2021/09/08 14:45:18 10.0.0.10 からの応答: バイト数 =32 時間 =6ms TTL=57
2021/09/08 14:45:19 10.0.0.10 からの応答: バイト数 =32 時間 =7ms TTL=57
2021/09/08 14:45:20 10.0.0.10 からの応答: バイト数 =32 時間 =6ms TTL=57
2021/09/08 14:45:21 10.0.0.10 からの応答: バイト数 =32 時間 =6ms TTL=57
2021/09/08 14:45:22 10.0.0.10 からの応答: バイト数 =32 時間 =6ms TTL=57仮に、長時間接続できない場合は、既存Direct Connect GatewayとVGWを関連付けて、リカバリーします。
12. Virtual Private Gatewayの削除
既存Direct Connect GatewayとVGWの関連付けを解除した状態でも通信ができる事を確認したため、VGWを削除します。
まず、VPCからVGWをデタッチします。
VGWを選択し、アクション - VPCからデタッチをクリックします。
確認画面が表示されるので、デタッチするをクリックします。
デタッチが完了すると、VGWの状態がdetachedになります。
続いて、VGWを削除します。
VGWを選択し、アクション - 仮想プライベートゲートウェイの削除をクリックします。
確認画面が表示されるので、はい、削除しますをクリックします。
削除が完了すると、VGWの状態がdeletedになります。
作業後の構成図を図示すると、以下のようになります。
13. 既存のDirect Connect Gatewayの削除
既存のDirect Connect Gatewayと接続しているVPCが無くなったことを確認した後、Direct Connect Gatewayを削除します。
既存のDirect Connect Gatewayに関連付けられたゲートウェイがないことを確認して、削除するをクリックします。
確認画面が表示されるので、削除するをクリックします。
以上で、Direct Connect GatewayとVPCの直結構成から、Direct Connect GatewayとTransit Gatewayの併用構成への移行作業は完了です。
最終的な構成図を図示すると、以下のようになります。
Transit Gatewayを使いこなして自由にルーティングさせよう
Direct Connect GatewayとVPCの直結構成から、Direct Connect GatewayとTransit Gatewayの併用構成への移行手順をまとめてみました。
Transit VIFを取り扱っているネットワーク回線事業者も徐々に増えており、Direct Connect GatewayとTransit Gatewayの併用構成へ移行する案件に遭遇する方も多くなると思います。
2024/2/16追記 : 公開されているDirect Connectのハンズオン資料にもTransit Gatewayへの切り替え手順が記載されていたので紹介します。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
0
