Direct Connect GatewayとTransit Gatewayの併用構成への移行手順をまとめてみた

Direct Connect GatewayとVPCの直結構成から、Direct Connect GatewayとTransit Gatewayの併用構成への移行手順をまとめてみました。オンプレミス環境側のルーターの設定変更ができない環境でも、AWSからオンプレミス環境にアドバタイズするCIDRを工夫することで、できるだけダウンタイムを短くすることができます。
2021.09.08

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に接続しています。

Transit VIF切替前の構成図

これを最終的に以下のように、Direct Connect GatewayとTransit Gatewayの併用構成に切り替えます。

Transit VIF切替後の構成図

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

具体的な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とエラーが表示されます。

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の作成

Direct Connect Gatewayの作成が完了すると、以下のように表示されます。

Direct Connect Gatewayの作成後

3. 新規に作成したDirect Connect GatewayとTransit VIFの関連付け

新規に作成したDirect Connect GatewayとTransit VIFを関連付けます。

関連付けたいTransit VIFを選択して、承諾するをクリックします。

承諾前Transit_VIF

次に、Transit VIFと関連付けたいDirect Connect Gatewayを選択して、仮想インターフェイスを承諾するをクリックします。

Transit VIFの承諾

しばらくすると、Transit VIFの状態がpendingdownと変化し、最終的にavailableとなります。併せてBGPのステータスもavailableとなっていることを確認します。また、Amazon側のASNは10124からDirect Connect Gatewayで設定したASNである64513に変化しています。

承諾後Transit VIF

作業後の構成図を図示すると、以下のようになります。

Transit VIF承諾後の構成図

4. Transit Gatewayの作成

Transit Gatewayを作成します。

ASNは既存のDirect Connect Gatewayや、新規に作成したDirect Connect Gatewayと重複しないように64531を選択しました。また、Transit Gaetway Attachment毎に任意のTransit Gateway Route Tableを関連付けたいので、Default association route tableDefault propagation route tabledisableにしました。

Transit Gatewayの作成

作成後しばらくすると、Transit GatewayのStateがavailableとなります。

Transit Gateway available

5. 新規に作成したDirect Connect GatewayとTransit Gatewayの関連付け

新規に作成したDirect Connect GatewayとTransit Gatewayを関連付けます。

作成したDirect Connect Gatewayを選択して、ゲートウェイの関連付けタブのゲートウェイを関連付けるをクリックします。

Direct Connect GatewayとTransit 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なのか判断できません。

Private_VIFとTransit_VIFからアドバタイズされるCIDRが同じ場合

ここで、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となります。

Private_VIFとTransit_VIFからアドバタイズされるCIDRが異なる場合

Direct Connect GatewayとTransit Gatewayの関連付けをして、しばらく待つと、状態がassociatedになります。

Direct Connect GatewayとTransit Gatewayの関連付け後

また、VPCのコンソールより、Transit Gateway Attachmentを確認すると、Resource typeがDirect Connect GatewayのTransit Gateway Attachmentが作成されていることが確認できます。

Direct Connect Gateway用のTransit Gateway Attachmentの確認

作業後の構成図を図示すると、以下のようになります。

Direct Connect GatewayとTransit Gateway関連付け後の構成図

6. Transit Gaetway 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 Gaetway Attachment用のサブネットとして、10.1.0.64/27のサブネットを作成をしました。

作業後の構成図を図示すると、以下のようになります。

Transit Gateway Attachment用のサブネット追加後の構成図

7. VPC用のTransit Gateway Attachmentの作成

VPC用のTransit Gateway Attachmentを作成します。

特別な設定はなく、作成したTransit Gateway Attachment用のサブネットを指定して作成します。

Transit Gateway Attachmentの作成

Create attachmentクリック後にTransit Gateway Attachmentの一覧を確認すると、Resource typeがVPCのTransit Gateway Attachmentが作成されていることが確認できます。

VPCのTransit Gateway Attachmentの確認

作業後の構成図を図示すると、以下のようになります。

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の作成

VPC用のTransit Gateway Route Tableの作成が完了したことを確認します。

VPC用のTransit Gateway Route Tableの確認

次にルーティングの設定を行います。

RoutesタブのCreate static routeをクリックします。

VPC用Transit Gateway Route Tableのルート設定前

ここで、10.0.0.0/16宛の通信はDirec Connect Gatewayのアタッチメントを通るように設定し、Create static routeをクリックします。

Direc Connect Gatewayのアタッチメント宛のルートの作成

ルート一覧で、対象のルートが追加されたことを確認します。

Direc Connect Gatewayのアタッチメント宛のルートの作成確認

同様に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の作成

Direct Connect Gateway用のTransit Gateway Route Tableの作成が確認できた後、ルーティングの設定を行います。

10.1.0.0/16宛の通信はVPCのアタッチメントを通るように設定し、Create static routeをクリックします。

VPCのアタッチメント宛のルートの作成

ルート一覧で、対象のルートが追加されたことを確認します。

VPCのアタッチメント宛のルートの作成確認

作業後の構成図を図示すると、以下のようになります。

Transit Gateway Route Table設定後の構成図

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をクリックします。

VPC用のTransit Gateway Route TableとTransit Gateway Attachmentとを関連付け

Choose attachment to associateで、VPC用のTransit Gateway Attachmentを選択し、Create associationをクリックします。

VPC用のTransit Gateway Route TableとTransit Gateway Attachmentとを関連付け設定

しばらくすると、対象の関連付けのStateがassociatedになります。

VPC用のTransit Gateway Route TableとTransit Gateway Attachmentとを関連付け確認

続いて、Direct Connect Gateway用のTransit Gateway Route TableとTransit Gateway Attachmentとを関連付けます。

Direct Connect Gateway用のTransit Gateway Route TableのAssociationsタブからCreate associationをクリックします。

Direct Connect Gateway用のTransit Gateway Route TableとTransit Gateway Attachmentとを関連付け

Choose attachment to associateで、Direct Connect Gateway用のTransit Gateway Attachmentを選択し、Create associationをクリックします。

Direct Connect Gateway用のTransit Gateway Route TableとTransit Gateway Attachmentとを関連付け設定

しばらくすると、対象の関連付けのStateがassociatedになります。

Direct Connect Gateway用のTransit Gateway Route TableとTransit Gateway Attachmentとを関連付け確認

作業後の構成図を図示すると、以下のようになります。

Transit Gateway Route TableとTransit Gateway Attachmentの関連付け後の構成図

10. オンプレミス環境への通信がTransit Gatewayを向くようにVPCのルートテーブルを変更

オンプレミス環境への通信がTransit Gatewayを向くようにVPCのルートテーブルを変更します。

現在のVPCのルートテーブルは以下のようになっています。Transit Gatewayを経由して通信をするために、VGW宛のルートをTransit Gateway宛に変更します。

VPCのルートテーブル設定変更前の構成図

Transit Gatewayに向くようにルートテーブルを変更することで非対称ルーティングが発生します。非対称ルーティングが発生による注意点及び、発生するタイミングについて補足します。

まず、現在の通信経路は以下の様になっています。(オレンジの矢印が通信経路)

VPCのルートテーブル設定変更前の通信経路

続いて、以下がVPCのルートテーブルを変更して、オンプレミス環境への通信がTransit Gatewayに向くように変更した場合の通信経路です。

VPCのルートテーブル設定変更後の通信経路

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に変更されている事を確認します。

オンプレミス環境宛のターゲットが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を選択し、関連付けを解除するをクリックします。

既存Direct Connect GatewayとVirtual Private Gatewayの関連付けの解除

確認画面が出るので、関連付けを解除するをクリックします。

既存Direct Connect GatewayとVirtual Private Gatewayの関連付けの解除確認

関連付けの解除が完了すると、ゲートウェイの関連付けが正常に解除されました。と表示されます。

関連付けの解除が完了確認

このタイミングでダウンタイムが発生します。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のデタッチ

確認画面が表示されるので、デタッチするをクリックします。

VGWのデタッチ確認

デタッチが完了すると、VGWの状態がdetachedになります。

VGWのデタッチ後状態確認

続いて、VGWを削除します。

VGWを選択し、アクション - 仮想プライベートゲートウェイの削除をクリックします。

VGWの削除

確認画面が表示されるので、はい、削除しますをクリックします。

VGWの削除確認

削除が完了すると、VGWの状態がdeletedになります。

VGWの削除後状態確認

作業後の構成図を図示すると、以下のようになります。

VGW削除後の構成図

13. 既存のDirect Connect Gatewayの削除

既存のDirect Connect Gatewayと接続しているVPCが無くなったことを確認した後、Direct Connect Gatewayを削除します。

既存のDirect Connect Gatewayに関連付けられたゲートウェイがないことを確認して、削除するをクリックします。

既存Direct Connect Gatewayの削除

確認画面が表示されるので、削除するをクリックします。

既存Direct Connect Gatewayの削除

以上で、Direct Connect GatewayとVPCの直結構成から、Direct Connect GatewayとTransit Gatewayの併用構成への移行作業は完了です。

最終的な構成図を図示すると、以下のようになります。

Direct Connect Gateway削除後の構成図

Transit Gatewayを使いこなして自由にルーティングさせよう

Direct Connect GatewayとVPCの直結構成から、Direct Connect GatewayとTransit Gatewayの併用構成への移行手順をまとめてみました。

Transit VIFを取り扱っているネットワーク回線事業者も徐々に増えており、Direct Connect GatewayとTransit Gatewayの併用構成へ移行する案件に遭遇する方も多くなると思います。

このブログが誰かの助けになれば幸いです。

以上、東京オフィスの のんピ(@non____97)でした!