マルチアカウント環境でのTransit Gatewayを試してみる-ピピローグ

仕事でAWS Transit Gatewayを触った。理解したつもり！ｗ

改めて自分の中できちんと理解したいので、

個人のAWSアカウントでTransit Gatewayを試してみました。

単一アカウントだとしょーもないので、マルチアカウント環境で！

構成図としては以下のような感じにしてみた。

それぞれTGW1,TGW2というアカウントにそれぞれVPCがあって、

それらをInfraアカウントのTransit Gatewayに繋ぐ、といった感じ。

まさにTransit Gatewayとはリージョン内のVPC間を繋ぐ架け橋みたいなもの。

1:1ならVPC Peeringで良いだろって言う話なんだけど、

VPCの数が増えてきたりするとPeeringの数もバカみたいに増えてくるので、

構成がややこしくなる。

Transit Gatewayがあるとシンプルな構成になるし、管理が非常に楽。

というわけでやってみた。

どのアカウントで実施すべきかはきちんと書くけど、ややこしいので注意。

Transit Gateway作成

まずはInfrastructureアカウントで基となるTransit Gatewayを作成する。

ここの部分ね。

VPCのTransit Gatewayから「Transit Gatewayを作成」をクリックする。

名前を入力する。

ASN番号はデフォルト（64512）がダメなら別のものを指定。

Transit Gatewayに繋ぐNW機器でASN番号が重複しないものを決める必要がある。

他はそのままで「Transit Gatewayを作成」をクリックする。

作成されました。

Resource Access ManagerでのOrganizations共有の有効化

AWSアカウントがOrganizationsに属していて、

同じ組織内のアカウントに対してはわざわざ承認する必要もなくなるので、その設定を行う。

Organizationsの管理アカウントにて「Resource Access Manager」から「設定」を開き、

「共有を有効にする」にチェックを入れる。

共有が有効になったことを確認する。

Transit Gatewayを別アカウントに共有

作成したTransit Gatewayを別アカウントから接続できるように共有の設定を行う。

この部分。

Infrastructureアカウントに戻り、AWS Resource Access Managerを開く。

「リソースの共有の作成」をクリックする。

共有の名前を入力し、リソースはトランジットゲートウェイを選択し、対象のTGWにチェックを入れる。

「Next」をクリックする。

そのまま「Next」をクリックする。

共有先のアカウントを設定。

通常はすべてのユーザーでいいと思うけど、組織内にのみ共有したいのであれば

「自分の組織内でのみ共有を許可」を選択する。

プリンシパルは組織IDを入力する。もちろんアカウントIDでもいける。

全て入力できれば、「Next」をクリックする。

確認画面が表示されるので、「リソース共有を作成」をクリックする。

共有が正常に作成された。

それぞれのアカウント（TGW1、TGW2）でTransit Gatewayが表示されていることを確認する。

共有先アカウントではTransit Gatewayの名前は引き継がれないので、

任意で名前を使えるなりなんなりご自由に。

Transit Gatewayアタッチメント作成（TGW1）

共有されたTransit GatewayにVPCを繋ぐためのアタッチメントを作成する。

この部分。

TGW1のアカウントに移り、Transit Gatewayアタッチメントの作成を行う。

名前を入力し、Transit Gateway IDは先ほど共有されたTGWを指定、

アタッチメントタイプはVPCを選択する。

VPC IDは接続するVPCを指定。

サブネットIDは各AZのサブネット（※）を指定する。

今回は面倒だったので単一AZにしたけど、普通は全てのAZを指定するよねｗ

※AWSのベストプラクティスによるとVPCアタッチメント専用のセグメント（/28）を作ってそれを指定するのがいい模様。

アタッチメントが正常に作成されました。

作成したアタッチメントを今度は共有元で承諾する必要がある。

今度はInfrastructureアカウントのTransit Gatewayを確認すると、さっき作成したアタッチメントが表示されているので、詳細を表示する。

アクションから「Transit Gatewayアタッチメントを承諾」をクリックする。

確認画面が表示されるので、「承諾」をクリックする。

TGW1アカウントに戻ると、Transit Gatewayアタッチメントが「Pending」状態になっているのが・・・・

「Avaliable」に変わる。

Transit Gatewayアタッチメント作成（TGW2）

上記と同じことをTGW2アカウントでも実施する。

以上で、それぞれのTransit Gatewayアタッチメントが作成された。

Transit Gatewayルートテーブル（設定は任意）

Transit GatewayもL3機能を持っているので、当然ルーティングも意識しておく必要がある。

デフォルト状態でTransit Gatewayを作成すると、デフォルトルートテーブルの関連付けや伝播が有効になるので、特に意識しなくてもルートテーブルは勝手に更新されるんだけど、

オンプレミスやAWS外への通信を意識すると、Transit Gatewayルートテーブルも検討する必要がある。

イメージだと以下の部分。

ちなみに作成したTransit Gatewayアタッチメントごとにルートテーブルを割り当てることができる。

今回はシンプルな構成なので、ルートテーブルは一つだけ。

オンプレミスとか別環境へのルートが必要な場合は「静的ルート作成」から設定する必要がある。

当然ながら、共有しているTransit Gatewayでは、Transit Gatewayを作成したアカウントでルートテーブルを全て管理する必要がある。

各VPCでの設定変更

ここでやることは大きく二つ。

ルートテーブルの更新とセキュリティグループの追加。

イメージだとこの部分。

ルートテーブルの更新は各サブネットごとに割り当てられたテーブルに対して、

対向となるセグメントへの通信をTGWへ向けるだけ。

あとはセキュリティグループも明示的に対向のセグメントの通信許可を入れたほうがいい。

全てのトラフィックを許可したグループID指定があるので、

それを使ったらいいやーって思ってたら、通信ができなくてドツボにハマったｗｗｗｗｗ

解説等はこちら参照。

EC2で疎通確認

以上で設定は終わり！

それぞれのVPCにEC2を立てて、Pingで疎通確認を行う。

test-sv01(172.20.22.172)からtest-sv02(172.20.38.31)へpingコマンド実行。

プライベートサブネットにしていて、ssh接続が面倒だったので、

SSMからAWSコンソール経由でアクセスした。

SSMの使用方法はまた今度書く。

やったぜ(･∀･)

ネットワークの知識があればTransit Gatewayは簡単

DirectConnect Gatewayの部分もやってみたかったけど、流石にそれを個人で試すのは無理なのでお試しはここまで。

初めはすごくとっつきにくかったTransit Gatewayだけど、一度設定してみたら仕組みは非常にシンプルなものだと理解。

ネットワークの知識を理解してたらTransit Gatewayもすぐ理解できるんじゃない？

Oracle Cloudで言うところの動的ルーティングゲートウェイ（DRG）だね。

DRGについては過去に↓のような記事を書いた。

当然ながらTransit Gatewayも料金は発生する。

詳細は公式サイトを参照。

具体的にはTransit Gatewayアタッチメント接続した時間と

Transit Gatewayを経由したデータ量に対して料金がかかる。

なので、作成したTransit Gatewayアタッチメントは使い終わったら削除しておくことが無難。

アタッチメント1つにつき1ヶ月常時接続で大体$50くらいかかる。

普通は2つ以上アタッチメントは接続するから、最低$100くらいだね。

Transit GatewayはVPCの数がものすごく増えてきて、

Peering接続構成がメッシュみたいになってきた時に真価を発揮する。

複雑な構成になってきたらTransit Gatewayを導入すべき。