【Transit Gateway】アウトバウンド通信を集約する環境を構築してみる(クロスアカウント編)

2022/04/06更新: 2022年版のブログ書いてます。ルート設計周りの情報はこちらを御覧ください。

• 【AWS Transit Gateway】複数VPCのアウトバウンド通信を集約する環境を作る | DevelopersIO

ーーーーーーーーーーー

前回のブログでインターネットへのアウトバウント通信を 1VPCの NATゲートウェイへ集約する環境を構築しました。

• 【Transit Gateway】アウトバウンド通信を集約する環境を構築してみる | Developers.IO

今回は クロスアカウント環境 でアウトバウント通信を集約する環境を作ってみます。

ルート設計の考え方は前回(1アカウント編) と同じですが、 Transit Gateway のリソースを他の複数アカウントと共有するために AWS Resource Access Manager(RAM) を使用します。

RAM周りの設定など、クロスアカウント環境ならではの設定に注目して構築していきます。

目次

1. 構築内容・ルート設計
   1. Outbound-VPC、APP1-VPC の作成
   2. TGWの作成、TGWアタッチメント(親アカウント)
   3. TGWを共有
   4. TGWアタッチメント(子アカウント)
   5. TGWルートテーブルの作成、関連付け
   6. ルート設計
2. 構築してみた
   1. 作成したプロジェクト説明
   2. アウトバウンド接続確認
3. 拡張する場合
   1. 新規アカウントの APP-VPCを追加する場合
4. おわりに

構築内容・ルート設計

今回の構築で作成したリソースを順番に説明していきます。

※以降 TGWリソース/アウトバウンド用VPCを所有しているアカウントを 親アカウント 、 TGWを共有される側のアカウントを 子アカウント と呼びます。

※説明するサブネットは全て 1AZ(ap-northeast-1a) です。

Outbound-VPC、APP1-VPC の作成

土台を作ります。

• 親アカウント: Outbound-VPC 、NATゲートウェイを作成
• 子アカウント: APP1-VPC、アウトバウンド通信テスト用のインスタンスを作成

TGWの作成、TGWアタッチメント(親アカウント)

TGWを作成します。

TGWルートテーブを自分で編集する必要があるので、以下オプションで作成します。

• Default route table association: 無効
• Default route table propagation: 無効

また、クロスアカウントのアタッチメントを自動で承認させたいので、 Auto accept shared attachments: 有効 とします。

• Auto accept shared attachments: 有効

TGW作成後、TGW用サブネットへのアタッチメントを作成します。

※まだこの時点では TGW共有はされていないため、 子アカウント へ TGWアタッチメントは作成できません。

TGWを共有

AWS Resource Access Manager(RAM) はAWSリソースを他のアカウントでも利用できるようにするサービスです。

RAMを使って TGWリソースを子アカウントへ共有 します。

RAMで共有リソースを作成する際には以下 2点を指定します。

• リソース: 共有するリソース。 今回は 作成したTGWリソース。
• プリンシパル: 共有先のAWSアカウント、組織ユニット(OU)、または組織。 (今回の検証環境は AWSアカウントを指定)

リソース共有の作成後、 子アカウントのマネコンから 「リソースの共有を承認」します。

承認後、子アカウントで このTGWリソースを扱えるようになります。

※ 子アカウントが AWS Organizations の組織内の場合 、 親アカウントの RAM > Settings > Enable sharing within your AWS Organizations を有効にすることで、この承認プロセスを省けます。

TGWアタッチメント(子アカウント)

この操作は子アカウントで行います

TGWへのアタッチメントを子アカウント上で行います。

TGWルートテーブルの作成、関連付け

この操作は親アカウントで行います

先程作成した子アカウントのアタッチメントは、親アカウントのマネコンからも見ることが出来ます。

新規TGWルートテーブルを作成して、 2つのアタッチメントに 関連付け(Association) させます

ルート設計

VPCルートテーブル、TGWルートテーブルを設定します。 ルートテーブルの内容の解説は 前回のブログ > ルート設計 を参照ください。

クロスアカウントの場合、 各ルートテーブルを設定するアカウント を意識する必要があります。

• 親アカウント: 自身のVPCルートテーブルと TGWルートテーブル
• 子アカウント: 自身のVPCルートテーブルのみ

構築してみた

上で示した環境を実際に構築してみました。

今回は AWS Cloud Development Kit (CDK) を使って構築しています(言語: Python)。

• CDK: 1.30.0
• Python: 3.7.3

作成したプロジェクト説明

作成したプロジェクト・スタックは以下のとおりです。

• 親アカウント CDKプロジェクト | github
  • 1. OutNwStack: Outbound-VPC/サブネット作成用
  • 2. TgwStack: TGW, TGWアタッチメント作成用
  • 3. VpcRouteStack: VPCルート設定用
  • 4. TgwRouteStack: TGWルート設定用
• 子アカウント CDKプロジェクト | github
  • 1. AppNwStack: APP-VPC/サブネット作成用
  • 2. AppInstanceStack: テスト通信用EC2インスタンス作成用
  • 3. TgwAttachmentStack: TGWアタッチメント作成用
  • 4. VpcRouteStack: VPCルート設定用

以下の順番でデプロイします(RAMの共有/承認プロセスはマネコン上で実施)。

このようなデプロイフローになるのは、以下依存関係があるためです。

• 子アカウントの TGW関連の設定: リソースが共有されてから 実施しないといけない
• 親アカウントの TGWルートの設定: 子アカウントで TGWアタッチメントを作成してから 実施しないといけない

アウトバウンド接続確認

デプロイして作成された 子アカウントの EC2インスタンスへ SystemsManagerの Session Manager で入ってみます。

curl -I https://dev.classmethod.jp/ を実行してインターネットへのアウトバウンド通信ができるかどうか確かめてみます。 デプロイして作成された EC2インスタンスへ SystemsManagerの Session Manager で入ってみます。

ちゃんと情報取得できていますね。親アカウントのNATゲートウェイ経由のアウトバウンド通信ができていることが分かりました。

拡張する場合

新規アカウントの APP-VPCを追加する場合

手順は以下のとおりです。

1. (子アカウント#2) VPC、サブネット作成
2. ※ (親アカウント/子アカウント#2) RAMでTGWを共有/共有を承認
3. (子アカウント#2) TGWアタッチメントの作成、VPCルートテーブルの作成
4. (親アカウント) VPCルートテーブル、TGWルートテーブルの更新

※子アカウント#1/#2 が同じ組織ユニット(OU) かつ OUでTGWを共有している場合、 手順2は不要です

おわりに

以前の 1アカウント内のアウトバウンド通信 集約環境とルート設計は同じですが、 RAMを利用するため少し複雑です。

• TGWルートテーブルは親アカウントで設定
• TGWアタッチメントは各アカウントで設定
• VPCルートテーブルは各アカウントで設定

上記を意識すると良いと思います。

この記事が少しでもどなたかのお役に立てば幸いです。