AWS Transit Gateway
https://d1.awsstatic.com/webinars/jp/pdf/services/20191113_AWS-BlackBelt_Transit_Gateway.pdf
## Transit Gateway とは
Transit Gateway をハブとしてVPC,VPN、Direct Connectを繋ぐ
各VPCの各AZごとに1つのENIが作成され、それをアタッチする。
VPC間の通信を行う場合には同一のAZのENIを経由して通信が行われる。
送信先に同一AZが存在しない場合には、存在するAZのENIのいづれかに出力され通信できる。戻りのENIも必要になる。ない場合は戻りの通信ができないため、不通になる。
## ユースケース
- 自由に通信できるRoute Domain
- これがデフォルト動作
- すべてのVPC間で通信が可能
- CIDR とvlcid などのid を結びつけ
- VPCを追加するとRoute Table に自動で追加
- ルーティングテーブルを扱わず、プラグアンドプレイで相互接続可能
- 制限したい場合はNACLやSecurity Group で制限する
- VPC間の通信を制限するRoute Domain
- ルーティングテーブルを複数用意し、共通でアクセスできるVPCと制限するVPCでルートテーブルを分ける
- マルチアカウントでVPC内制御できない場合にTransit Gateway で通信を制御できる
- 中央集権でネットワークを管理したい場合に最適
- インターネットに自由に通信できるOutbound Route Domain
- インターネットVPC向けの経路。戻りも書く必要がある。
- VPC間のトラフィックをインライン監査するRoute Domains
- VPC間の通信を行う際には一旦ミドルボックスでトラフィックを監査後に対象のVPCに抜けるようにするといったことができる。
- 監査を行うインスタンスを冗長化して監視すると行ったことが必要。また、ルーティングテーブルを操作するLambdaなどを作成して監視すると行ったことが必要
- Transit Gateway + Direct Connect/VPN
- 他拠点を収容するVPN Hub
## 構成
On-premise DC —Direct Connect—Direct Connect Gateway - Transit Gateway - VPCs
Direct Connect を二本引いて冗長化することも可能。
片方をVPCにするといったことも可能
## Tips
- TGWのアタッチメントENIに専用サブネットを作成するのが良い。他のインスタンスと同郷するとTGWからの経路の影響を受ける
- クロスアカウントやVPN接続の場合 Route 53 Resolver Endpoint が必要になってくる
## Transit Gateway を利用しなくてもいいケース
- TGWで通信制限するRoute Domain
- VPC Peering/DXGWで共通VPC以外は通信制限するRoute Domain(VPC Peering と DXGWで通信制限は可能。コストも削減できる）
## 雑感
コストベースで考えるとアタッチに対して料金がかかってくるのと通信自体にコストがかかってくるので割高な印象。しかし、VPCの数が数千になってくるとVPC Peering で手で設定するより、Direct Connect を利用してマネージドにしてもらった方がルートテーブルの管理だったり、インスタンスの管理などが楽になると思う。この辺りはビジネス的な判断になるのかなと思った。
その他ミドルボックスでのトラフィックの管理などもできるのでそれを入れたい場合や、各VPCを自由にアタッチしたりして大規模に構成する場合には検討の遡上に上がるのかなと思った。
HA構成を取りたいときにも比較的簡単に複数AZを複数のDirect Connect を経てTGWにアタッチさせることができるので比較的楽に構成ができるとメリットがあると言えそう。
