Transit Gatewayのルーティングを考えてみる

こんにちは、SCSK横山です。

前回のブログにて「Transit Gatewayの構築は簡単だった」と書きましたが、ルーティング部分はTransit Gatewayならではの考慮点があったので、今回はそちらに触れてみたいと思います。

はじめに

前回のブログは以下ブログとなります。

Transit Gateway構築後、テストセグメントを構築したのち、インスタンスを構築し、DC Bへの通信テストを行うこととしました。

案2

 

Transit Gatewayのルーティング

Transit Gateway導入後、ルーティングの考慮として2つがあげられました。

  1. Transit Gateway ルートテーブル
  2. Transit Gateway へのルート伝播

先に記載したように、今回の環境は1VPCであることから、当初はルート伝播を考えておりました。

しかしながら、既存環境への影響を考慮した際、テストセグメントのみTransit Gatewayを見せたいことから、ルート伝播は利用せず、Transit Gatewayのルートテーブルのみを利用して構築することとしました。

 

行ったこと

現在利用しているセグメントとは別のテストセグメントを構築後、以下の順序でルーティングを確立していきました。

  1. テストセグメントおよびTransit Gateway作成時に構築する3セグメント用のルーティングテーブルを作成する。
  2. 作成したルーティングテーブルのデフォルトゲートウェイにTransit Gatewayを指定する。その他社内セグメント用のルーティングテーブルも適宜作成する。
  3. Transit Gatewayルートテーブルを新規作成後、VPC、Site-to-Site VPNを関連付けを行う。
  4. ルートタブを選択し、デフォルトゲートウェイに、DC Bと接続したSite-to-Site VPNを指定する。また、VPC CIDRをVPC向けのルートとして追加する。

これら作業を実施し、正常に通信が確立できることを確認してから、現在の本番セグメントのルーティングを今回新たに作成したルートテーブルに付け替えし、作業を完了させました。

 

おわりに

Transit Gatewayは複数VPC間の通信を確立する非常にパワフルなサービスで、今回のように1VPC用で使うケースはあまりないかと思います。また複数のVPCが存在する場合、ルーティングの考慮ももう少し複雑になるかもしれません。

しかしながら、1VPCでも便利に活用できるケースもあったため、今回補足記事を書いてみました。皆様の参考になれば幸いです。

タイトルとURLをコピーしました