はじめに
前回までの記事では、以下の内容を整理してきました。
-
VPC 間接続のキホン
https://qiita.com/pommny_dev/items/58f3fdd7cb8b97af6a61 -
リージョン間の Transit Gateway 接続
https://qiita.com/pommny_dev/items/973311d7817a90abff7f -
Transit Gateway 接続の可視化
https://qiita.com/pommny_dev/items/792c69faaf33e10009e8
今回はその続編として、クロスアカウントでの VPC 接続 を整理していきます。
基本的な作業や考え方はこれまでと変わりませんが、ポイントは「どのアカウントで作業を行うのか」です。
クロスアカウント環境ではリソースのオーナーシップが分かれるため、操作手順がやや複雑になりがちです。
今回の構成
別アカウント（アカウント B）で VPC（10.20.10.0/26）を 1 つ作成し、これまでに構築してきた Transit Gateway と接続します。
ルートは本番環境VPC①－Shared環境VPC間のみ疎通することとします。
クロスアカウントでのリソース作成の考え方
VPCをクロスアカウントにてTransit Gatewayで接続する場合、基本的な設計は変わらないが、作業するアカウントが分かれる点に注意が必要。
- アカウントA：Transit Gatewayを作成したアカウント
- アカウントB：VPCを接続したい環境のアカウント
手順の流れは以下の通り。
-
Transit Gatewayを共有
- アカウントAから、アカウントBに対してTGWをリソース共有する。
-
アカウントBでアタッチメントを作成
- 共有されたTGWを選択してVPCアタッチメントを作成する。
- 作成後にアカウントA側でアタッチメントを承認する。
-
アカウントAでルートテーブルを作成・関連付け
- ルートテーブルはTGWを作成したアカウント（＝アカウントA）で管理する必要がある。
- 必要なルート設定を行い、アタッチメントと関連付ける。
👉 特に「Transit Gatewayのルートテーブルは、TGWを作成したアカウントでしか作成・管理できない」点を押さえておくことが重要。
構築のステップ（概観）
-
事前準備（VPC・サブネット・ルートテーブル作成）
接続先となる VPC と必要なサブネット／ルートテーブルを作成する。 -
Transit Gateway のリソース共有
TGW をオーナーアカウントから共有し、別アカウントでも利用できるようにする。 -
VPC アタッチメント作成
共有された TGW に対して、接続先アカウントから VPC をアタッチする。 -
ルートテーブル作成・関連付け
TGW 側と VPC 側のルートテーブルに、相互通信のためのルートを設定する。 -
疎通確認
実際にインスタンス間で通信を行い、接続が正しくできているか確認する。
ステップ①：VPC・サブネット・ルートテーブルの準備
アカウントBにて、以下を実施する。
-
VPC：CIDRは
10.20.10.0/26 - サブネット：App層用とTGW層用の2つを作成
- ルートテーブル：それぞれのサブネットに紐付け
- 疎通確認用のサーバをApp層に構築。（10.20.10. 39）
ステップ②：Transit Gateway のリソース共有
クロスアカウントで利用するために、Transit Gateway をアカウントBに共有する。
ここでは AWS Resource Access Manager (RAM) を利用してリソース共有を行う。
1. Resource Access Manager で共有設定を開始
- サービス一覧から Resource Access Manager を開く
- 「リソースを共有」から新しい共有を作成する
2. 共有するリソースを指定
- リソースタイプに Transit Gateway を選択
- 対象となる TGW を選択し追加
3. アクセス許可を関連付ける
- 共有先のアカウントにて、Transit Gateway関連で行える操作を定義する。
- 今回はデフォルト設定で問題無い。
4. 共有先を指定
- プリンシパル（共有先）として 共有先のアカウントのAWSアカウントID を入力
- 必要に応じて組織単位での共有も可能
5. 確認して共有を作成
-
入力内容を確認し「共有を作成」
-
ステータスが「アクティブ」になれば、アカウントBにTGWが共有される
-
アカウントB側のResource Access ManagerでもアカウントAのTransit Gatewayが確認可能
これでTransit GatewayがアカウントBに共有できたため、アカウントA側でTransit Gatewayアタッチメントを作成可能。
ステップ③：Transit Gateway アタッチメントを作成
アカウントB側で、共有された Transit Gateway に対して VPC アタッチメントを作成する。
1. アタッチメントの作成
- アカウントBにてVPCコンソールから Transit Gateway アタッチメントを作成 を選択
- Transit Gateway ID に共有済みのTGWを指定（アカウントAのTGWが選択可能になっているはず）
- 接続するVPCとサブネットを指定して作成
2. 承認フロー
-
アタッチメント作成後、アカウントA・B共に作成したアタッチメントが表示されるが、初期状態では 「Pending Acceptance」 になる
-
アカウントA（TGW所有アカウント）のコンソールから、対象のアタッチメントを確認し 承認 する
-
承認後、アカウントA・B側共にアタッチメントのステータスが「Available」となる
👉 ポイント
- アタッチメントの「作成」はアカウントBで行い、
- 「承認」はTGWを所有するアカウントAで実施する。
この二段階がクロスアカウント接続における重要な流れ。
これでアタッチメントが作成出来たため、Transit GatewayとクロスアカウントでVPCの紐付けが出来たことになる。
（ルーティング設定をしていないため疎通は不可）
ステップ④：Transit Gateway ルートテーブルの作成・関連付け
1. Transit Gateway ルートテーブルの作成（アカウントA）
- ルートテーブルはTGWを所有するアカウントAで作成・管理する必要がある
- 作成したルートテーブルに、アカウントBで作成したアタッチメントを関連付ける
2. 関連付けの確認（アカウントB側）
- アカウントBでルートテーブル作成・関連付け後、アカウントBのコンソールからも、共有されたTGWに紐づくルートテーブルの関連付け状況を確認できる
- これにより、クロスアカウント接続が有効になっていることを確認可能
■ルート設計
-
ルーティングの設計の考え方はこれまでと変わらない。
-
今回は本番環境VPC①とShared環境VPCを接続するため、それぞれのVPCに紐づけられているアタッチメントにお互いのアタッチメント・CIDRへのルートを追加する。
-
Transit Gateway ルートテーブル
- CIDR：接続先VPC CIDRを追加
- ターゲット：接続先VPCアタッチメント
-
VPC ルートテーブル（アカウントB側）
- 宛先：接続先VPCのCIDR
- 次ホップ：Transit Gateway Attachment
👉 ポイント
- TGWルートテーブルは必ずTGWを所有するアカウントで作成・管理する。
- VPCルートテーブル側では、接続先のCIDRをTGWに向ける設定を行う。
- この両方の設定が揃ってはじめて、VPC間通信が成立する。
これで各VPCのルーティングまで完了しました。
ステップ⑤：疎通確認
最後に、接続先VPCのEC2インスタンスに対して疎通確認を実施する。
例として、test-netconnection で本番環境VPC①（10.10.10.0/26）からShared環境VPC（10.20.10.0/26）への接続を確認。
疎通出来ました
おわりに
今回はクロスアカウントでの構築ステップを整理しました。
ここまでの記事を通じて、Transit Gateway の基本的な構成 ―
- 単一リージョンでのVPC接続
- リージョン間接続
- クロスアカウント接続
に加え、Network Manager を使った接続の可視化 までカバーできました。
これで一通り、Transit Gateway の“キホン”はマスターできたのではないかと思います。
次章（ラスト）では、Transit Gatewayのコストについてと、VPC Peering など他の接続方式と比較したときのTransit Gateway の優位性 を考察したいと思います。