Direct Connect と VPN をフェイルオーバーのために併用する場合の Transit Gateway ルート設定

記事タイトルとURLをコピーする

営業部 佐竹です。
本日は、Direct Connect (DX) と Site-to-Site VPN (VPN) を併用する構成での AWS Transit Gateway (TGW) のルートテーブル設計と実際の設定をご紹介しつつ、実環境でフェイルオーバーテストを行った結果をご紹介します。

はじめに

Direct Connect と Site-to-Site VPN を Transit Gateway に紐づけて利用を行う場合、以下の通りの構成図になります。

f:id:swx-satake:20211004141444p:plain

ネットワーク設計

設計を以下の通りとします。

  • Direct Connect 障害発生時には、Site-to-Site VPN へ自動的に切り替えが行われること
  • Direct Connect 障害復旧時には、Site-to-Site VPN から Direct Connect へと自動的に切り戻しが行われること
  • Direct Connect は Transit Gateway と接続するにあたり、Direct Connect Gateway の導入が必須となるため、これを利用すること
  • VPC は Transit Gateway と関連付けし、Transit Gateway を経由して VPC 間通信を実現すること
  • Transit Gateway の Attachment に関連付けられる Transit Gateway ルートテーブルによって経路制御されること
  • Transit Gateway ルートテーブルでは不用な通信が行われないよう、必要に応じて Static ルートを活用すること

このような設計での構成において、どのように Transit Gateway のルートテーブルを記載することになるでしょうか?

本ブログでは、上図のような構成において Transit Gateway のルートテーブルにおける具体的な設計をご紹介します。

TGW ルート設計

f:id:swx-satake:20211004153834p:plain

設計の全体像を、上の通り構成図にて示します。

DXGW 及び VPN のルート設計

f:id:swx-satake:20211004154018p:plain

Direct Connect Gateway 及び Site-to-Site VPN に関連付ける Transit Gateway ルートテーブルは同じ設定となるため、ルートテーブルを1つとしてそれぞれに関連付けを行います。

また、具体的なルート設定としては、目的とする VPC に対する経路を Static で記載しています。Propagations の設定は記載していません。

VPC01 のルート設計

f:id:swx-satake:20211004154030p:plain

VPC01 に関連付ける Transit Gateway ルートテーブルは Propagations の設定を用いて、Direct Connect Gateway と Site-to-Site VPN それぞれに対して「伝播」を許可します。

Direct Connect と Site-to-Site VPN は、同時に設定がされる場合は、常に Direct Connect 側が優先されるためこのような設計となります。

Q.AWS Direct Connect と VPN 接続を同時に同じ VPC で使用することはできますか?

はい、しかしフェイルオーバーの場合のみです。Direct Connect パスが確立されると、AS パスに前置される情報に関係なく、常に Direct Connect パスが優先されます。ご使用の VPN 接続が、Direct Connect からのフェイルオーバートラフィックを処理できるようにしてください。

https://aws.amazon.com/jp/directconnect/faqs/

VPC01 から VPC02 へは Static でのルートを記載して対応します。

VPC02 のルート設計

f:id:swx-satake:20211004154042p:plain

VPC02 に関連付ける Transit Gateway ルートテーブルは VPC01 と同様に Propagations の設定を用いて、Direct Connect Gateway と Site-to-Site VPN それぞれに対して「伝播」を許可します。

VPC02 から VPC01 へも同様に Static でのルートを記載して対応します。

Propagations によるルートへの自動追記

設計段階では、VPC01 及び VPC02 のアタッチメントに関連付けられた Transit Gateway ルートテーブルのルートには、Direct Connect Gateway と Site-to-Site VPN どちらの経路も存在しません。

これは Propagations にて設定を行っているためで、Direct Connect が Up したタイミング(もしくは Site-to-Site VPN が Up したタイミング)で伝播によりそれらへのルートへと自動的に追加されます。

f:id:swx-satake:20211004154200p:plain

上図は、Direct Connect が Up したタイミングでの構成です。

f:id:swx-satake:20211004131432p:plain

実際に Attachment におけるルートテーブルを確認すると、「Propagated」として Direct Connect Gateway へのルートが追加されることがわかります。

Direct Connect と Site-to-Site VPN が同時に Up している状態でも、この通りのルートとなります。これは先に記載した「常に Direct Connect パスが優先される」という仕様によるものです。

f:id:swx-satake:20211004154228p:plain

これにより、VPC からオンプレミス環境への通信は、VPN を併用する場合においても常に Direct Connect を経由します。

VPN へのフェイルオーバーを試す

Direct Connect が接続されているルータの電源を落とすか、Direct Connect のフェイルオーバーテストの実行を行うことで Direct Connect を意図的にダウンさせ、VPN へと経路が自動的に切り替わるのか検証を行います。

f:id:swx-satake:20211004154242p:plain

この場合、フェイルオーバー後に上図の通りとなります。

VPC01 及び VPC02 のアタッチメントに関連付けられた Transit Gateway ルートテーブルのルートには、Direct Connect Gateway へのルートが削除され、自動的に Site-to-Site VPN (表記は VPN となる)への経路が追加されることになります。

f:id:swx-satake:20211004131314p:plain

実際に Attachment におけるルートテーブルを確認すると、「Propagated」として Site-to-Site VPN へのルートが追加されることがわかります。

これにより、フェイルオーバー後の VPC からオンプレミス環境への通信は VPN を経由することとなります。

また、Direct Connect が復旧しフェイルバックされた後は、本ルートは Direct Connect Gateway 優先に自動的に切り替わります。

まとめ

今回のブログでは、Direct Connect と Site-to-Site VPN を併用する構成での AWS Transit Gateway のルートテーブル設計と実際の設定をご紹介しつつ、実環境でフェイルオーバーテストを行った結果を紹介させて頂きました。

ご紹介した通り、Transit Gateway のルートには「Propagations」を活用することで、簡単に Direct Connect と Site-to-Site VPN のフェイルオーバーの設定が記載可能です。

なお、ブログでご紹介しました通り、Direct Connect から Site-to-Site VPN へのフェイルオーバーが正しく動作するかどうかは、実環境で十分に動作検証を行って頂くようお願い致します。

本ブログの内容に関連した AWS 公式のナレッジセンターを共有してこの記事を終わりにしたいと思います。

aws.amazon.com

では、またお会いしましょう。

2021年10月5日追記

blog.serverworks.co.jp

本ブログの続きとも言える内容を記載しましたので、合わせてご覧くださいますと幸いです。

佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ

営業部カスタマーサクセス課所属。AWS資格12冠。2010年1月からAWSを利用してきました。2021 Japan APN Ambassador /2020-2021 APN ALL AWS Certifications Engineer。AWSのコスト削減、最適化を得意としています。