概要
仕事でTransit GatewayをPoC環境で構築する機会があって思ったより、やることがあったので記事にしてみました。また、構築して通信を分析できるサービスも教わったので使って、経路も確認しました。
Transit Gatewayとは
- VPC間の接続をまとめることができるサービス
- VPC間のハブの役割になるイメージ
- 異なるリージョン間での通信はTransit Gatewayが２つ必要
- 異なるアカウントでリージョンが同じならTransit Gatewayを共有が必要
Amazon VPC Transit Gateway とは
メリット
- 複数のVPCを1つのTransit Gatewayに接続して、ハブ＆スポーク型のネットワークを簡単に構築可能
- Transit Gatewayルートテーブルを使うので、ルート情報を一元管理できる
Reachability Analyzerとは
- VPC内の通信を分析できるサービス
- どこで、通信が遮られているかがわかる
- 1回分析あたり、0.10$
Reachability Analyzer
実演
実際に、アカウントAにTransit Gateway本体を作成して、それをアカウントBと共有して、同一リージョンで通信ができるかを確認する。
以下が構成図です。
※Transit Gatewayの共有は省きます。
実際の流れ
- アカウントA、BでVPCの作成
- アカウントAでTransit Gatewayの作成
- アカウントBにTransit Gateway共有（RAMの共有は一部省きます）
- アカウントA、Bでアタッチメントの作成し、アカウントAで承諾
- アカウントAでTransit Gatewayルートテーブルを作成（Transit Gateway本体はアカウントAにある）
- アカウントA、BでVPCのパブリックサブネットのルートテーブル編集
- アカウントA、BでEC2インスタンスを作成
- Reachability Analyzerで疎通確認
やってみた
アカウントA、BでVPCの作成
アカウントA、BそれぞれにVPCを作成していきます。その際にVPCのCIDRブロックが被ってしまうと通信が混乱するためCIDRブロックを被らせないようにしましょう。
-
アカウントAのVPC(CIDRを10.0.0.0/16に設定)
AZに関しては検証用なのでシングルにする(アカウントBも同様)。
-
アカウントBのVPC(CIDRを172.0.0.0/16に設定)
アカウントAでTransit Gatewayの作成
Transit Gateway本体を作成していきます。のちにアカウントBと共有します。
- アカウントAでTransit Gatewayを作成する。
名前を「AccountA-tgw」にして作成をする。デフォルトルートテーブルに関しては別途作成していきたいので、チェックを外しました。
作成してしばらくすると状態が「Available」になります。これで、Transit Gateway本体の完成です。
アカウントBにTransit Gateway共有（RAMの共有は一部省きます）
- 作成したTransit GatewayをアカウントBに共有するためアカウントAでResource Access Managerのコンソール画面へ移動し、「自分が共有」のリソースの共有でリソースの共有の作成をする
- 共有するリソースタイプと共有するリソースを選択します
- アクセス許可の画面に移りますので、次に進みます
- プリンシパルオプションの画面に移ります。今回は組織内のアカウントに許可するので、「自分の組織内のみを許可」を選択します。プリンシパルタイプでは今回は一つのアカウントのみですので、「AWSアカウント」を選択して共有先のAWSアカウントIDを入力します
- 確認画面へ移るので、確認して「リソース共有を作成」をクリックします
アカウントA、Bでアタッチメントの作成し、アカウントAで承諾
-
アカウントAでTransit Gatewayアタッチメントを作成します。VPCやサブネットを選択する場面がありますが、最初に作成したVPCを、サブネットはプライベートサブネットを選択してください
-
アカウントBでアカウントAのTransit Gatewayが共有されているかを確認する
-
アカウントAのTransit Gatewayが共有されていることを確認出来たら、アカウントAと同様にTransit Gatewayアタッチメントを作成します
-
アカウントAのTransit Gatewayアタッチメント画面でアカウントBで作成されたアタッチメントが表示されるのため、承諾する
※このアタッチメントのNameタグが空白なので、記入したほうがわかりやすい -
アカウントBで状態が「Available」になっているのを確認する
アカウントAでTransit Gatewayルートテーブルを作成、ルートテーブルの編集
Transit Gatewayとアタッチメントを介してVPC間が通信できるようにルートテーブルを作成する。作成後に関連付けやルートの設定を行う。
- ルートテーブルの作成をする際に今回の作業で作成したTransit GatewayIDを選択する
- 作成したルートテーブルを選択して「関連付け」で今回作成した、２つのアタッチメントを関連付ける（同時に２つのアタッチメントを関連付けることはできません。）
- 伝番を作成します。そうすることで、自動的にルートに通信の方向がアタッチメントに行くように登録されます（2と同様、同時に作成はできない）
- 伝番の作成で各アタッチメントを登録したのち「ルート」に経路が登録されていることを確認
上の画像を見る限り、登録されていますね！
アカウントA、BでVPCのパブリックサブネットのルートテーブル編集
VPCを作成した際に一緒に作成された、パブリックサブネットのルートテーブルを編集して通信がTransit Gatewayに向くようにします。
以下のように各アカウントにルート情報を追加します。
- アカウントＡ
| 送信先 | ターゲット |
|---|---|
| 172.0.0.0/16 | Transit GatewayID |
- アカウントB
| 送信先 | ターゲット |
|---|---|
| 172.0.0.0/16 | Transit GatewayID |
アカウントA、BでEC2インスタンスを作成
疎通確認の対象として、各アカウントにEC2インスタンスを立てます。インスタンスの作成の手順は省きますが、セキュリティーグループのインバウンドルールを以下のように設定してください。
- アカウントＡ
| タイプ | ソース |
|---|---|
| すべてのTCP | 172.0.0.0/16 |
- アカウントB
| 送信先 | ターゲット |
|---|---|
| すべてのTCP | 10.0.0.0/16 |
Reachability Analyzerで疎通確認
疎通確認を行います。SSMのSessionManagerを使ってPingを使って疎通確認はできますが、Reachability Analyzerを使うことで通らなかった際に、どこで通信が遮られているかがわかるのでそちらを使っていきます。
- VPCのコンソール画面から「Network Manager」に移ります。
VPCのコンソール画面を下にスクロールすると見えてきます。迷いますね... - Reachability Analyzerを使う前に「設定」で「信頼されたアクセス」を有効にしていない場合、有効にしてください
※既に有効の場合は飛ばします。
有効の確認
- Reachability Analyzerを選択して「パスの作成と分析」をしていきます。まずはアカウントBからアカウントAに通信ができるかを確認します
- 分析結果の確認をしていきます
到達できませんでしたね…
しかし、原因を教えてくれます！
セキュリティーグループに原因があるみたいですので、見てみます。
インバウンドルールのソースが「10.0.0.0/16」になっていますね。「172.0.0.0/16」に直して再度分析します。 - 再分析をする
無事にできていますね。
経路も見てみましょう！
Transit Gatewayを通って通信がされていることが確認できました！
アカウントAからアカウントBに対しても確認してみてください（ここでは割愛します。）
感じたこと
- Transit Gatewayは資格試験でよく見かけたことがあるが、こうして実際に構築すると各コンポーネントの理解が足りないと感じた
- Reachability Analyzerは一方通この通信のみの分析なので往復分として2回やる必要がありそう
参考文献
以下を参考にして学習しました。
ありがとうございます。
AWS Resource Access Managerを使用して、複数アカウントでAWS Transit Gatewayを共有して通信する方法
AWS Transit Gatewayを使用してEC2同士のクロスアカウント通信を行う
Transit Gatewayを設定して、同一リージョン内の複数VPC間でEC2インスタンス同士の通信を行ってみた
VPC Reachability Analyzerを使ってみてわかった便利さと意外なハマりどころ