初学者でもわかる！！Transit Gatewayでアカウント間のVPC接続を行う方法

# 超詳細Transit Gatewayのアカウント間VPC接続手順 
<br>
クラウドベンダーに入社してから約半年、何度も何度もTransit Gateway という言葉が出てきて、すでに3回ほど触る機会がありました。こんなに短いスパンで関わっているということは、重要でよく使うものなのだろう！でも手順やコミュニケーションが多くてよくわかりにくい！！ということで、初学の私でもわかりやすいTransit Gateway接続手順を作らせていただきました。
こちらの記事は作成の手順をメインに進めていきます！



## Transit Gatewayとは


Amazon VPC Transit Gateway は、仮想プライベートクラウド (VPC) とオンプレミスネットワークを相互接続するために使用されるネットワークの中継ハブです。Site to Site VPNやDirect Connectも各ネットワークリソースも柔軟に接続することができます。Site to Site VPNやDirect Connect等を通してオンプレミスと接続します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3941184/bdcc0a11-1379-36b8-b70a-7e5469295741.png)


## なぜTransit Gatewayなのか？
Direct ConnectやSite to Site VPNが存在する中、Transit Gatewayを選ぶべきはいつなのか。

先に回答です！
**①20個以上のVPCを接続したい場合**
**②VPC同士を接続したい場合**
の2パターンです。

逆にいうと①②はDirect Gatewayでは不可能です。VPCピアリングでVPC同士を接続する方法もありますが、VPCが多い場合はそれぞれにVPCピアリングを設定する必要があるため作業量が多くなります。
しかし、TGWは単一リージョン内での通信を対象とするなどデメリットもあるので構築環境をもとにベストプラクティスを考えてください。

ではここから、実際の接続手順に入ります！
## 全体図


今回作成するTransit Gatewayの構成図です！

![スクリーンショット 2024-12-05 1.03.04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3941184/b1c1fe34-2542-d5c4-1ac4-084ed2768e50.png)

|| アカウント1|アカウント2| 
|:------|-----|------------:|
| Transit Gateway| test-tgw1     | ー       | 
| アタッチメント| tgw-at1   | tgw-at2       | 
| VPC| test-vpc1 （172.31.0.0/16）   | test-vpc2 （10.0.0.0/24）   | 

2つのアカウントのVPC接続を行うためにアカウントごとのアクションが必要になります。今回は以下の手順でTransit Gatewayを作成しました！
|| アカウント1|アカウント2| 
|:------|-----|------------:|
|1| Transit Gatewayの作成      | ー       | 
|2 |アタッチメント作成     |  ー    | 
|3 |RAMでTransit Gatewayを共有     |  ー    | 
|4| ー      | Transit Gateway共有の承認       | 
|5| ー      | アタッチメントの作成         | 
|6| アタッチメントの承認      | ー       | 
|7|Transit Gatewayルートテーブルの設定   | ー     | 
|8| VPCルートテーブルの設定   | VPCルートテーブルの設定     | 

## 1, Transit Gatewayの作成（アカウント1）
まずは先ほど説明したTransit Gatewayを作成していきます。

VPC
↓
Transit Gateway
↓
Transit Gateway作成

![スクリーンショット 2024-12-02 18.38.55.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3941184/e9db77fc-e290-0d3d-a572-6955d781534b.png)

**・ASN番号**ーAWSのTransit Gatewayが外部のネットワークとやり取りするために必要な「ネットワークの住所」のようなものです。

GWを使用するときに他のDirect Connectなどを使用している際は番号が重複しないように気をつけてください。何も設定しないとAWSが自動的にASNを割り当てます (デフォルト: 64512)。


**・DNSサポート**ーTGWで接続されたVPC内のパブリック IPv4 DNS ホスト名をプライベートIPアドレスに名前解決をできるようにするための機能です。

**・セキュリティグループの参照**ーセキュリティグループを使った通信制御を可能にします。

通常、セキュリティグループはVPC内の通信を制御します。しかし、Transit Gatewayを経由してネットワーク間をつなぐと、セキュリティグループの設定が適用されない場合があります。この機能を有効にすると、Transit Gatewayで接続されたVPC間でもVPC内で行う制御と同様にセキュリティグループを使った通信制御が可能になります。この機能により、VPC同士の通信やVPN、Direct Connect経由の通信をより柔軟かつ安全に管理できます。

**・VPN ECMP サポート**ー同じ帯域のVPNを束ねて高帯域化させることが可能な機能です。1つのVPN接続では、最大で1.25Gbpsまでの帯域を利用可能ですが、それを超えるスループットが必要な場合にはECMPを有効にします。


**・デフォルトルートテーブルの関連付け**ーTransit Gateway アタッチメントがこの Transit Gateway のデフォルトのルートテーブルに自動的に関連付けられます。

**・デフォルトルートテーブル伝播**ールートテーブルアタッチメントがこの Transit Gateway のデフォルトのルートテーブルに自動的に伝播されます。

Transit Gateway作成時にデフォルトルートテーブルの関連付けと、デフォルトルートテーブル伝搬を有効化すると共有元と共有先のVPC CIDRが登録されています。Transit Gatewayに接続されている全てのVPCで通信が可能となります。
**関連付け、伝播に関しては後で詳しく説明します！**

**・マルチキャストサポート**ーマルチキャストは、1つの送信者が複数の受信者に同じデータを同時に送信する通信プロトコルです。


**・クロスアカウント共有オプションの設定**ー手動の操作を行わずに共有アタッチメントをに承諾します。(今回は手動で行います。こちらを有効化する際は手順6をスキップしてください)

**・CIDR ブロック**ーCIDRで指定されるIPアドレスの集まりです。

Connect (GRE) アタッチメントまたは PrivateIP VPN を設定する場合に使用されます。他のアタッチメントと被らない任意のCIDRを入力してください。
IPv4 にはサイズ /24 CIDR ブロック以上 (例: /23 または /22) 、IPv6 にはサイズ /64 CIDR ブロック以上 (例: /63 または /62) を指定できます。



## 2, アタッチメント作成（アカウント1）
Transit Gateway アタッチメントはVPCとTransitGatewayを接続するエンドポイントに近いもので、AWS Transit Gatewayと別のネットワークとの接続点になります。

![スクリーンショット 2024-12-05 0.20.40.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3941184/ddbd56e7-2bd1-0c43-12ad-0a65474e0740.png)



VPC
↓
Transit Gatewayアタッチメント



![スクリーンショット 2024-12-03 23.38.12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3941184/2558b00e-34ce-020d-cab7-daf79c46b9fc.png)



**・セキュリティグループ参照サポート**ーセキュリティグループを参照する場合はここの設定でも有効にする必要があります。

**・アプライアンスモードサポート**ー通信先が異なるAZであっても、戻りの通信は行きの通信と同じ経路を辿るようになります。

VPC アタッチメントが複数のアベイラビリティーゾーンにまたがっており、ステートフルな検査のために送信元ホストと送信先ホスト間のトラフィックを同じアプライアンスを介してルーティングする必要がある場合に有効とします。

**・VPC ID**ーアタッチメントを作成するVPCを選択します。


**・サブネットID**ーVPCアタッチメントを作成するサブネットを選択します。1つのAZに1つのENIのみ可能です。

TGWアタッチメント専用サブネットを作成するのがベストプラクティスとされており、その際は小さな CIDR (/28 など)を設定することが推奨されています。

↓
Transit Gatewayアタッチメントを作成。





## 3, RAMでTransit Gatewayを共有（アカウント1）
AWS Resource Access Manager(RAM)は異なるアカウントで様々なリソースの共有を行うことができる機能です。今回はTransitgatewayを共有していきます。

Resource Access Manager
↓
自分が共有/リソース共有
↓
リソース共有の作成


![スクリーンショット 2024-12-02 18.40.35.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3941184/8424cfba-fc62-3cd4-f9be-6674929115f8.png)


**・リソース**ー共有するリソースを選択します。今回は先ほど作成したトランジットゲートウェイを選んでください。


↓
次の画面へ。
<br>
![スクリーンショット 2024-12-02 18.40.59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3941184/98a98af3-2109-7686-f15a-9a6e9611cbd0.png)

**・マネージド型アクセス許可を関連付ける**ーデフォルトの設定では「サービスネットワークへのサービスの関連付け」と「サービスネットワークへのVPCの関連付け」を行うことが可能になります。それに加えて共有リソースでプリンシパルが実行できるアクションを指定するには許可の選択が必要です。
↓
次の画面へ。
<br>




![スクリーンショット 2024-12-02 18.41.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3941184/d52ae03a-1436-8340-b9dc-3a34fd76b36e.png)


**・プリンシパル**ー今回は他のAWSアカウントとリソースを共有するため「全てのユーザーとの共有を許可」を選択します。

Transit Gateway を Organization 内でのみ共有する場合は、自分の組織内でのみ共有を許可を選択します。

**・プリンシパルのタイプ**ー共有先を選択します。今回は「AWSアカウント」を選択し、RAMの共有先である**アカウント2**のアカウントIDを追加します。
↓
次の画面へ。
↓
内容を確認してリソース共有を作成。


## 4, TGWの共有を承諾（アカウント2）

RAM
↓
リソースの共有
↓
先ほど共有された共有リソースを選択（名前をチェック）
↓
リソースの共有を承認

![スクリーンショット 2024-12-02 23.33.46.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3941184/d9be5510-1807-040b-e61c-1d2610bacb71.png)


ステータスがアクティブになっていることを確認します。
これでTransit Gatewayの共有が完了！！！



## 5, アタッチメント作成（アカウント2）
手順3と同様にアタッチメントを作成


## 6, アタッチメントの承認（アカウント1）
VPC
↓
Transit Gatewayアタッチメント



![スクリーンショット 2024-12-05 8.45.27.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3941184/4489409a-1089-d872-ab0e-aad60365bbe7.png)





アカウント2で作成したアタッチメントの承認を行います。
共有先側（アカウント1）は共有元（アカウント2）のアタッチメントの承認が必要です。



## 7, Transit Gatewayルートテーブルの設定（アカウント1）
### ルートテーブルの作成
Transit Gateway アタッチメントのルーティングを設定します。
ここからが私的いちばんの難関でした！ルートテーブルの作成は簡単なのですが、ルーティングが、、
ここからややこしくなっていくので実際のリソースネームを使用していきます。

今回VPC同士の相互接続を設定するためルートテーブルを2つ、**tgw-rt1**と**tgw-rt2**を作成します。


VPC
↓
Transit Gatewayルートテーブル
↓
Transit Gatewayルートテーブルを作成

![スクリーンショット 2024-12-02 23.57.11.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3941184/705ff8be-e4ed-024b-06d2-73e7224d4b1d.png)


名前:**tgw-rt1**
Transit Gateway ID:**test-tgw1のID**
↓
Transit Gatewayルートテーブルの作成

以上！！！！！同様に**tgw-rt2**も作成します。

でも、今はこの状態↓
![スクリーンショット 2024-12-05 0.42.58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3941184/42a8804b-1f1d-9165-86ea-574342a2f84a.png)

ルートテーブルを作っただけでは接続ができないのでルーティングをします。

ルーティングは関連付け、伝播の2種類があります。
これがまたややこしい、、、、



### Transit Gatewayの関連付けと伝播

![スクリーンショット 2024-12-03 22.49.59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3941184/59720189-13ad-79b3-8df5-6327b777f3e9.png)



**・関連付け**ー固定されたルートを設定し、管理者がルートテーブルに手動でエントリを追加・変更します。1つのアタッチメント（1つのVPC）が、1つのルートテーブルにしか関連付けできないのでVPCごとに異なるルーティングが必要な、変更が少ない場合に適しています。

![スクリーンショット 2024-12-05 0.47.40.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3941184/5306fb0e-8ca7-ee8f-bf41-6d7d6b14c5b2.png)







（例）開発VPCの 10.1.0.0/16 から本番VPCの 10.2.1.0/24 への通信だけを許可する


デメリットとして、ネットワーク構成が変更されるたびに手動で更新が必要でありスケーラビリティに限界があります。

<br>
<br>

**・伝播**ーVPCにセカンダリCIDRが追加されたときなどに自動的にルートテーブルに反映されるようになります。これにより、手動でルートを設定する手間が省け、通信がスムーズになります。また、ネットワーク管理が簡単になることで全体の運用効率が向上します。Transit Gateway peeringは、伝播ができないので注意が必要です。


![スクリーンショット 2024-12-05 0.47.40.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3941184/8901de17-4d0e-c980-f07f-75ae0430d56f.png)

（例）オンプレミスに新しいサブネット 172.16.2.0/24 を追加した際、BGP経由で自動的にルートを学習

デメリットとして、意図しないルートが伝播される可能性があるためセキュリティ要件によっては不適切な場合があります。

### Transit Gatewayルーティング設定

tgw-rt1をアカウント1へのルーティングに設定します。

**・関連付け**
VPC
↓
Transit Gateway ルートテーブル
↓
**tgw-rt1**を選択
↓
関連付け
↓
関連付けを作成

![スクリーンショット 2024-12-05 8.48.29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3941184/312faed7-3fef-7a23-c802-178f52ea1679.png)
伝播するアタッチメント： **tgw-at2**





<br>
<br>

**・伝播**
Transit Gateway ルートテーブル
↓
**tgw-rt1**を選択
↓
伝播
↓
伝播を作成

![Transit Gateway ID.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3941184/04dfa0e6-950b-efff-748e-4a65a0777dfd.png)


伝播するアタッチメント： **tgw-at1**


<br>

![スクリーンショット 2024-12-05 19.04.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3941184/ca07f498-d7df-1b0a-931c-6bd0fc1a9021.png)


↑ルートを確認するとアカウント1へのルーティングされていることが確認できます。

tgw-rt2にも同様アカウント2へのルーティングを進めてください。




## 8, VPCルートテーブルの設定（アカウント1＆アカウント2）
最後の手順です！VPC側ではTransit Gatewayからは経路を受け取りません。 VPC側ルートテーブルには静的にTransit Gatewayへのルートを追加する必要があります。両方のアカウントで、VPCのルートテーブルを設定を行い、他のアカウント向けの経路をTGWに向けます。

VPC
↓
ルートテーブル
↓
ルートテーブルを選択
↓
ルート
↓
ルートを編集

![スクリーンショット 2024-12-05 8.55.13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3941184/df64e13b-80b1-dc0b-d35b-6a7a6d3d7961.png)


![スクリーンショット 2024-12-05 8.55.23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3941184/9191a857-8632-f890-2119-01569d6ec8f4.png)



アカウント1のVPC
送信先：172.31.0.0/16(アカウント2のVPC)
ターゲット：test-tgw1


アカウント2のVPCにも以下のルートを追加！！!
送信先：10.1.0.0/24(アカウント1のVPC)
ターゲット：test-tgw1

**これにてTGWによるアカウント間VPC接続完了！！**

## まとめ
今回初めてブログを書いてみました！
私自身理解がとっても遅く、たくさんの記事を読み漁るのでこの記事1つでみなさんがTransit Gatewayでのアカウント間のVPC接続に苦手意識がなくなったら嬉しいです。
お疲れ様です！！

## 参考文献
https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/what-is-transit-gateway.html

https://www.ashisuto.co.jp/db_blog/article/aws-transitgateway.html#aws-tgw-1

https://zenn.dev/fdnsy/articles/5a4e7f816f3d13

https://zenn.dev/fdnsy/articles/5a4e7f816f3d13

https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/tgw-vpc-attachments.html#vpc-attachment-security

https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/create-tgw.html

https://qiita.com/t_tsuchida/items/f4467e0e1a4fbe64447c

https://repost.aws/ja/knowledge-center/transit-gateway-sharing

https://qiita.com/If_it_bleeds-we_can_kill_it/items/c3f3d7cfbda5c019989a

https://dev.classmethod.jp/articles/enable-appliance-mode-when-using-transit-gatewayto-aggregate-communication-to-vpc-for-inspection/

https://blog.serverworks.co.jp/aws-transit-gateway-appliance-mode

https://dev.classmethod.jp/articles/transit-gateway-supports-multicast/