導入
マルチアカウントやマルチリージョンでの接続はVPC peeringかTransit Gatewayが必要ですが、
アカウント数やリージョン数が多い場合や外部接続との通信を集約したい場合はTransit Gatewayが適切となります。
今回はマルチアカウントかつマルチリージョンでの接続を実際に検証して見ました。
構成
以下のような構成の場合、中央アカウントにTransit Gatewayを置きそこをハブとして各アカウントが通信を行うイメージです。
そこで今回は以下構成図の東京リージョンのEC2から大阪リージョンのEC2にpingを飛ばして見たいと思います。
同じアカウントの別リージョンに通信する時も中央アカウントを通って通信します。
作業の流れ
1.中央アカウントでの作業(TGW作成、RAMで共有)
1-1.TGW(Transit Gateway)を作成
1-2.RAMでTGWを共有
2.リソースアカウントでの作業(TGA(VPC)とEC2の作成)
2-1.TGWの共有を承諾
2-2.VPCとサブネットを作成
2-3.サブネットにTransit Gateway Attachment(TGA(VPC))を作成
2-4.EC2の設置とセキュリティグループの設定
3.中央アカウントでの作業(TGA(VPC)の承諾、TGA(Peering Connection)の作成)
3-1.リソースアカウントのTGAを承諾
3-2.TGA(Peering Connection)作成
3-3.TGWルートテーブルにTGA(Peering Connection)の静的ルート登録を行う
3-4.Transit Gatewayルートテーブル確認
4.リソースアカウントでの作業（サブネットのルートテーブルにルート登録）
4-1. EC2が所属するサブネットに関連付いたルートテーブルにルート登録
4-2.Pingテスト
1.中央アカウントでの作業(TGW作成、RAMで共有)
1-1.TGW(Transit Gateway)を作成
東京リージョン、大阪リージョンそれぞれで作成します。
Amazon 側の自律システム番号 (ASN)
ASNは接続する他のTGWと重複しないように設定します。
TGWはVGWやDXGW(Direct Connect Gateway)経由でオンプレミス環境とも接続することできます。
その場合、DXGWのASN、DXGWと接続するオンプレミス環境のルーターのASNとも被らないように注意しましょう。
https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/direct-connect-transit-gateways.html
今回、その他のパラメーターはデフォルト値で作成しますが、私なりの気づきを記載します。
デフォルトルートテーブルの関連付け
TGW配下同士のVPCを全て通信許可とする場合は有効で問題ありません。
単一VPC同士のみの通信を許可する要件がある場合はデフォルトルートテーブルとは別のルートテーブルを作成し手動で関連付けします。
この項目を有効としていても関連付けは後から別のルートテーブルに付け替えることができます。
デフォルトルートテーブルの伝播
有効にすると作成したアタッチメントのVPCのCIDRがデフォルトルートテーブルに自動で伝播されます。
関連付けと同様、TGW配下同士のVPCを全て通信許可とする場合は有効で問題ありません。
共有アタッチメントを自動承諾
今回は無効とします。
有効とすると中央アカウント管理者の承諾なしにアタッチが承諾されるためリソースアカウント管理者が勝手に作成したTGW アタッチメントが自動でavailableになります。
無効にするデメリットとしては
中央アカウント側で承諾の作業が必要になるためCloudFormationでリソースアカウントのTGW アタッチメントを作成できなくなることです。
Transit Gateway CIDR ブロック
今回は入力しません。Transit Gateway Connectを使用する際に使うことがあるようですが、Transit Gateway Connectは東京リージョンでは使用できないため今回説明は省略します。
1-2.RAMでTGWを共有
東京リージョン、大阪リージョンそれぞれで作成します。
RAM(Resource Access Manager)でTGWをリソースアカウントに共有します。
Organizations内のアカウント間で共有する場合は、「自分の組織内でのみ共有を許可」を選択できます。
その場合、Organizationsの統合されたサービスでRAMを有効化する必要があります。
2.リソースアカウントでの作業(TGA(VPC)とEC2の作成)
2-1.TGWの共有を承諾
東京リージョン、大阪リージョンそれぞれで承諾します。
2-2.VPCとサブネットを作成
東京リージョン、大阪リージョンそれぞれで作成します。
TGW配下のVPCはCIDRが重複しないように作成します。
TGA用のサブネットを作成することをAWSは推奨していますので作成しましょう。
基本的にTGA専用なので最小の/28で問題ありません。
https://docs.aws.amazon.com/vpc/latest/tgw/tgw-best-design-practices.html
マルチAZ構成にする場合はAZごとにサブネットを作成しましょう。
ちなみにTGWの固定費はアタッチメントごとに発生しますが、VPC単位での課金なのでアタッチメントをマルチAZ構成にしても料金が2倍,3倍になるわけではありません。
2-3.サブネットにTransit Gateway Attachment(TGA(VPC))を作成
東京リージョン、大阪リージョンそれぞれで作成します。
AZ間で冗長する場合は各AZのサブネットを選択します。
2-4.EC2の設置とセキュリティグループの設定
東京リージョン、大阪リージョンそれぞれで作成します。
EC2の作成方法は今回省略します。
2-2で作成したサブネット(private-1a-sn)にEC2を所属させます。
EC2のセキュリティグループでpingが通るよう設定変更します。
東京リージョンの場合、以下で設定します。
プロトコル：ICMP
ソース：大阪リージョンのEC2のIP(今回は所属するVPCのCIDR 10.1.0.0/16で登録)
3.中央アカウントでの作業(TGA(VPC)の承諾、TGA(Peering Connection)の作成)
3-1.リソースアカウントのTGAを承諾
東京リージョン、大阪リージョンそれぞれで承諾します。
2-3で作成したTGAを承諾します。
3-2.TGA(Peering Connection)作成
東京リージョンのみで作成します。
大阪リージョン側でTGA(Peering Connection)を承諾
3-3.TGWルートテーブルにTGA(Peering Connection)静的ルート登録を行う
東京リージョン、大阪リージョンそれぞれで登録します。
東京リージョンの場合はTGWルートテーブルに以下を登録します。
CIDR：リソースアカウント大阪リージョンのEC2が所属するVPCのCIDR(10.1.0.0/16)
アタッチメント：東京リージョンのTGA(Peering Connection)
TGA(Peering Connection)は静的にルートを登録する必要があります。
3-4.Transit Gatewayルートテーブル確認
東京リージョン、大阪リージョンそれぞれで確認します。
TGWデフォルトルートテーブルを確認します。
関連付けにTGA(VPC)とTGA(Peering Connection)があり、
伝播にTGA(VPC)があり、
ルートにTGA(Peering)が静的登録されてあればOKです。
TGW作成時にデフォルトルートテーブルの関連付け/伝播を無効にした場合は手動で関連付け、伝播をする必要があります。
また別のTGWルートテーブルに関連付けさせたい場合は、デフォルトルートテーブルから対象のアタッチメントの関連付けを解除する必要があります。
(TGWアタッチメントは一つのTGWルートテーブルにしか関連付けできないため)
TGW配下のVPCと接続したくないサブネットやサーバがある場合はTGWルートテーブルでブラックホールとして登録します。
4.リソースアカウントでの作業（サブネットのルートテーブルにルート登録）
4-1. EC2が所属するサブネットに関連付いたルートテーブルにルート登録
東京リージョン、大阪リージョンそれぞれで登録します。
各ルートテーブルに以下を登録します。
東京リージョンの場合
宛先：大阪リージョンのEC2のIP(今回はVPCのCIDR 10.1.0.0/16を登録)
ターゲット：東京リージョンのTGW
4-2.Pingテスト
SSHかSession Managerで東京リージョンのEC2に接続し(手順説明は省略)、大阪リージョンのEC2にPingを飛ばします。
注意点(アタッチメントの費用について)
単価
https://aws.amazon.com/jp/transit-gateway/pricing/
Transit Gateway Attachmentごとに0.07USD/時間発生します。(東京/大阪リージョンの場合) ※2023年10月時点
今回だと1日置くと、0.07 x 24h x 4つ =6.72USD/日かかります。
検証が終わったらすぐアタッチメントを削除しましょう。
課金対象
TGA(VPC)はVPC単位で課金されます。今回であれば2つです。アタッチメントをAZ間で冗長構成としても料金は変わりません。
TGA(Peering Connection)は各リージョンのアタッチメントごとに課金されます。今回であれば2つです。
今回の検証では計4つのアタッチメントが課金されます。
請求先のアカウント
請求先のアカウントはTGAがあるアカウントです。今回であれば
TGA(VPC)はリソースアカウントに課金、
TGA(Peering Connection)は中央アカウントに課金されます。
以上
