こんにちは！サーバーワークスの松井です。
Transit GateWayについてハブみたいにVPCを行き来できるサービスだというざっくりとした認識で止まっている方は多いのではないでしょうか。
今回は一歩進んでTGWを複雑なネットワーク要件でどのように導入していけばよいのかをシュミレーションしながら紹介したいと思います。
よく見る構成
このような構成をよく見かけると思います。 では、実際にはどのように通信が可能なのでしょうか。
今回やりたいこと
・東京リージョンのVPCとシンガポールリージョンのVPCをつなぐ
・アカウントAとアカウントB内のVPCをつなぐ
・東京リージョンの本番環境と開発環境は通信できないようにする
・東京リージョンとシンガポールリージョンは、DX経由で社内ネットワークに通信可能(オンプレからの通信はリージョン毎に分ける)
・社内ネットワークとAWS環境のCIDR範囲は重複しているケースを想定
用語について
DirectConnect・・・DX
DirectConnectGateway・・・DXGW
TransitGateway・・・TGW
構成図
最終的な構成とルートの記載の仕方は以下を参考
事前準備
・本番,開発,DR用のVPCをそれぞれのリージョンに作成
・各VPCに行きたい経路へのCIDR範囲を記載
・アカウントAでTGW,DXGWを作成
・Direct Connect接続を承諾(DXGWの広報範囲がTGWのルートテーブルに伝搬されることを確認)
※ネットワーク制御する際には、自動ですべてTGWのルートテーブルに関連付けられないようTGW作成の際に以下は無効に設定する
Default route table association
Default route table propagation
Auto accept shared attachments
東京リージョンとシンガポールリージョンは、DX経由で社内ネットワークに通信可能(オンプレからの通信はリージョン毎に分ける)
２つのDX用にTransit VIFを作成し、DXGWに関連づけます。
DXGWと2つのTGWを関連付ける際には、許可されたIPプレフィックスに以下の内容で設定
・東京リージョンのTGW->東京リージョンのVPCのCIDR範囲
・シンガポールリージョンのTGW->シンガポールリージョンのVPCのCIDR範囲
Private VIFと違い各VPC毎にVIFを作成する必要がないので、Transit VIFさえ作ってしまえば、あとはAWS内をTGWで行き来する経路とすることができます。
東京リージョンのVPCとシンガポールリージョンのVPCをつなぐ
２つのTGWをpeering接続し、送信先のVPCのCIDR範囲を静的に記載します。
基本的にはリージョン内通信はリージョン内のTGWで通信しますが、リージョン間の通信は、TGW経由で行います。
アカウントAとアカウントB内のVPCをつなぐ
AWS Resource Access Manager(RAM)を使ってアカウントAで作成したTGWのリソース共有を作成し、アカウントBで共有を承諾した後、アカウントBでTGW attachment,TGW Association,TGW Propagationを追加していきます。
※TGW Association,TGW Propagationを設定すると自動的にTGWのルートテーブルにVPCのCIDRは追加されます。
東京リージョンの本番環境と開発環境は通信できないようにする
社内ネットワークのCIDR範囲とVPCのCIDR範囲が重複している場合は、ブラックホールを作って制御する
ブラックホールに指定したCIDR範囲には通信ません
今回は本番・開発双方でENIを作成し、通信させたくないCIDR範囲をVPCのルートテーブルに記載
ENIはルートテーブルに登録後削除します->ルートテーブルを見るとブラックホールと表記される
※社内ネットワークのCIDR範囲が一致していない場合、VPCのルートテーブルに記載のないVPCのCIDR範囲には通信しない
まとめ
アカウント・リージョンが異なる場合のTGW利用方法を紹介してきました。
TGWはVPC毎にPeering接続、VIFの接続をしなくてよいので便利ですが、VPCを拡張し続ける場合にはTGWのルートテーブルを運用していく必要はあります。
今回の構成を参考にTGWの導入の実現性を是非ご検討してみてください。
