Transit Gatewayに結びついているSite-to-Site VPNのDirect Connect移行作業をやりました
2025.05.16初めに
以前Transit Gateway(TGW) + Site-to-Site VPN(拠点間VPN)を利用している環境においてSite-to-Site VPNを廃止しDirect Connectに切り替えを実施する機会がありました。
Direct Connectに関しては性質上なかなか個人の環境で触れることは難しく検討・検証等する機会が限られている上にやらないうちに忘れそうな気がするので備忘録として記録しておきます。
なお、本記事はAWS側での話がメインで対向側(オンプレミス側)についてはあまり詳しく触れませんのでご注意ください。
また今回のDirect Connectは専用型を利用しています。
変更前後の構成について
今回作業を行った環境の作業前と最終的な対応後の状態は以下の図の通りです。
メインの拠点としては拠点A側を利用しているためこちらのDirect Connectが冗長化されており、通常AWS上のシステムに通信をする際はこちらを利用します。
拠点B側のDirect Connectは拠点AからAWSの接続がダウンした場合、もしくは拠点A自体がダウンした場合の迂回経路となっています(実際には頭蓋のシステムが拠点AしてAWSに通信することが有るため)。
該当環境は開発段階のシステムでありsite-to-site VPN接続(以降VPN接続)は元々Direct Connectが利用できるまでの一時的な接続ため拠点Aのみ接続を行っておりDirect Connect移行後は廃止(削除)となりました。
Direct Connectのサービス自体の障害に備えVPN接続を残しておく選択肢もありましたが、VPN接続を行っていたルータ自体が元々廃止予定であったものであったことやその他状況等を踏まえ今回は見送りとなりました。
移行作業前日の状態
以降前日までの準備段階としてAWS側では以下の作業を実施しています。
- Direct Connectの接続ポートの作成
- 作成後LOA-CFAを発行しプロバイダに連携
- Transit VIFの作成・Direct Connect Gateway(以降DXGW)の作成及び結び付け
VIFやDXGWの各種設定値(AS番号やVLAN番号等)については接続ポート作成時点で確定している必要はありません。
専用線の手配ではプロバイダー様側の作業待ち等が発生する部分もありますので、可能であれば接続ポートの設定値だけ先に確定してLOA-CFAの発行まで済ませ、専用線の手配とVIFやDXGWの設計・設定を並行して進めることも検討してみてください。
この時点の状態のは以下のようになります。
切り替え当日以前にはAWS〜プロバイダ(今回はColt)の接続は完了しており、Direct Connectの接続の状態は「available」となっている状態で(※1)、当日のAWS側の作業としてはTransit Gatewayのアタッチメント・ルートテーブルの作成及び設定のみの状態となっています(※2)。
※1 厳密には１本Downでしたが接続方式によるものとのことでした(あまり詳しくは聞いてないです...)
※2 今回当日作成しましたがアタッチメントの作成自体はこの時点でも可能です(後述)
https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/dedicated_connection.html#create-connection-loa-cfa
請求は、ポートがアクティブになったとき、または LOA が発行されてから 90 日が経過したときのいずれか早い時点で自動的に開始されます。アクティベーションの前、または LOA が発行されてから 90 日以内にポートを削除することで、請求を回避することができます。
なおポート時間の料金は接続ポートがアクティブになった時点から発生します。今回のケースでは料金発生タイミングは実際に当日拠点A/B側の結線が完了したタイミングではなく、Direct Connectの接続の状態が「available」となった時点からとなります。スケジュール的に間が空くや予算等の兼ね合いがある場合は注意しましょう。
接続ポート作成後にサポートケースがオープンされることがある
https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/download-loa-cfa.html
リンクが有効になっていない場合、LOA-CFA がまだダウンロード可能になっていません。追加情報を要求するサポートケースが作成されます。リクエストに応答し、リクエストが処理されると、LOA-CFA をダウンロードできるようになります。それでもダウンロードできない場合は、AWS サポートにお問い合わせください。
条件は公開されていないため不明ですが接続ポート作成時にサポートケースがオープンされることがあります。この場合こちらの対応を行うまで接続ポートの作成が完了せずLOA-CFAの発行ができないため内容を確認し回答しましょう。
今回は「ロケーション名(ex.AT Tokyo Chuo Data Center, Tokyo, JPN)」「プロバイダ名(ex. Colt)」「回線速度(ex. 10GBps)」の回答で問題なく受理されました。当時の話で現在は質問がわかっている可能性もありますので参考程度に実際の文章を読んで回答していただければと思います。
実際の自分の体験ベースですが、サポートケースが開くのは傾向的に開設間もないアカウント(or 利用料金が少ない？)という感じはするので、もしかするとあまり無闇に発行して欲しくないリソースなのかもしれません(質問の回答も作成時に指定した内容なので再確認の意味なのかなと想像)。
当日作業
切り替えの本作業となります。
AWS側ではTransit Gatewayアタッチメントとルートテーブルの作成設定、拠点側でも結線および各種ルータ設定作業を行いました。
作業の流れとしては以下の図の通りです（「’」がついてるのが拠点側作業、無しがAWS側作業です）。
③で拠点側から飛んできたルート情報が各種アタッチメント先に渡されるようになり、⑤のタイミングでTGWからDXGW経由で拠点側にルート情報が飛ぶようになりますのでここは特に操作ミス等ないように注意しましょう。
(決して手を抜いていいわけではありませんが)②、④に関しては接続先用のENI(アタッチメント)や拠点から来た通信の振り分け用のTGWルートテーブルの枠が作成されるのみなので特にTGWの制御には影響はありません。
なので実のところ②、④に関しては事前に作業を行い当日はその作業をスキップする形で進めることは可能でしたが、当日十分時間を取れることもありまとめてこちらで作業しました。
DXGWのアタッチメントの作成には10~15分程度かかりましたので切り替え当日の作業量を最小に抑えるのであれば事前に済ませておきましょう。
(実際に今回当日作業時にかかった時間。AWS側の状態等により左右もされる場合もあるので一例程度に見てください)
Direct Connect接続がうまくいかない場合はVPN接続への戻し作業を行う予定でしたが、この場合はDirect Connect側の接続を拠点で切ってもらいVPN接続を行っていたルータを起動してもらう想定となっておりました(+必要に応じルータの設定調整)。
VPN接続を維持する場合
最初に触れたとおり今回元々VPN接続側は廃止の予定なため当日作業でシャットダウンを行っていますが、仮に障害時用の経路として残しておく場合かつこの手順をスキップし後続の作業を進める形となります。
環境次第ではありますが動的制御かつ伝播しているルート情報が同じかつ場合は別作業は不要です。
- 送信先アドレスの最も具体的なルート。
- 同じ を持つがCIDR、異なるアタッチメントタイプからのルートの場合、ルートの優先度は次のとおりです。
- 静的ルート (Site-to-Site VPN 静的ルートなど）
- プレフィックスリスト参照ルート
- VPC伝播されたルート
- Direct Connect ゲートウェイで伝播されたルート
- Transit Gateway Connect で伝播されたルート
- プライベート Direct Connect で伝播されたルートVPNを介した Site-to-Site
- Site-toVPN-Site で伝播されたルート
- Transit Gateway ピアリング伝達ルート (クラウド WAN）
...
一部のアタッチメントは、BGP 経由でルートアドバタイズをサポートしています。同じ CIDR を持つルートと、同じアタッチメントタイプのルートの場合、ルートの優先度は BGP 属性によって制御されます。
Transit Gatewayルートテーブルでは同じルートが伝播された場合所定の優先度に基づき優先度の高い方を採用します。
そのため今回の作業で仮にVPN接続を削除せずDXGW側との接続のみを行った場合でもTGW側のルーティングはDXGW側を向くようになります。
また仮に障害がありDXGW側のみ接続異常でVPN側は正常な場合は、経路更新のタイミングでTGWのルートテーブルの向き先がVPN接続側に切り替わりそちらで通信を行えます。
なおあくまでTransit Gatewayが受信したルートを書くアタッチメントに伝播する時の優先度ですので、接続元となる拠点側でVPN接続を利用するかDirect Connectを利用するかについては別途Local Pref等のBGP属性を指定し調整してください。
経路切り替えテスト
今回は設定後同日に回線ダウンによる経路変更テストを実施しました。
対応の概要としては以下のとおりです。
- 拠点AのDirect Connectのうち片系統ダウンしても、拠点A内のもう片側のDirect Connectで通信が行われること
- 両系統ダウンパターン実施するので２パターン
- 拠点AのDirect Connectが２本ともダウンした場合に拠点B経由で行われること
- 拠点B経由に切り替わった後、拠点AのDirect Connectが復旧した場合は拠点A経由の通信にフェイルバックすること
切断される箇所としてはDXGW以降の部分となるのでTGW側のルートテーブルは書き換わることはない形となります。
またDWGWでは具体的に伝播された情報を見れるような機能はないのでケースバイケースではありますが多くの場合は拠点側の方で情報を確認し確認する形となります(AWS側ではVIFで接続ができているかBGPによる経路伝播が来てるか確認できる程)。
切断ポイントとしてはAWS側と拠点側の２点ありましたがAWS側はVIFの一時停止のようなことが現時点では実施できず削除再作成が必要となることから今回は「拠点側ルーターのケーブル抜去」となりました(前述の通りVIF作成にある程度時間がかかる、そもそも再作成なのでテストとしてあまりよろしくない)。
どうしてもAWS側の異常テスト行いたい場合は削除・作成の時間を見込み十分な作業時間を確保しておき、また作成時にもマネジメントコンソールではなくCLIでワンライナーで行うなどできる限り作業ミスが少ない再現性の高い方法で作業できるようにしておきましょう。
終わりに
簡単にですがTransit Gateway経由で行っていたVPN接続をDirect Connectに移行した際の作業をまとめてみました。
実のところこの作業自体は１年近く前に行ったのでもう忘れているかなと思っていたのですがやっぱり自分で手を動かしていると頭にしっかり入っているもので思ったよりしっかり書けるものですね(むしろ今の方が頭にしっかり定着してる気がします)。
Direct Connect周辺に関してはなかなか自由に検証できる機会も少なくメインが机上になりがちでそう言った記事をいくつも見てやっていくことになるかと思いますが記事によって視点が違うところもありますのでこの記事もそう言った中での情報収集の一部として役に立てる部分があれば幸いです。
![[Workshop] Dual-stack global networks with AWS Cloud WAN and AWS Direct Connect に参加しました #NET306 #AWSreInvent](https://images.ctfassets.net/ct0aopd36mqt/1dD7b8HkT2sbiJzUIewMTD/e5cdc6f33c4fdd9d798f11a4564612ff/eyecatch_developersio_darktone_1200x630.jpg)
