AWS Cloud WANとAWS Transit Gatewayを関連付けてTransit Gatewayと接続しているVPCやSite-to-Site VPNの経路情報をCloud WANに登録してみた
Transit Gatewayを介してCloud WANとVPCやSite-to-Site VPNを接続したい
こんにちは、のんピ(@non____97)です。
皆さんはTransit Gatewayを介してCloud WANとVPCやSite-to-Site VPNを接続したいなと思ったことはありますか? 私はあります。
今すぐにCloud WANを全面採用することは考えないが、既存のTransit Gatewayを活かしながらCloud WANの恩恵を受けたい時があります。
Transit GatewayからCloud WANへの移行されたい場合は以下AWS Blogsの記事やre:Postをご覧ください。
Transit Gatewayを介してCloud WANとVPCやSite-to-Site VPNを接続する方法を示した情報がインターネット上に少なかったので実際に試してみます。
検証環境
検証環境は以下のとおりです。

Transit Gatewayを介してVPCやSite-to-Site VPNを接続するパターンおよび、Transit Gatewayを介さずに直接Cloud WANと接続するパターンの2パターンを用意しています。
AWS CDKのコード
リソースは全てAWS CDKでデプロイしました。
使用したコードは以下GitHubリポジトリに保存しています。
AWS CDKのコードの構成は以下のようになっています。
.
├── bin
│ └── aws-cdk-cloud-wan-tgw-s2s-vpn.ts # CDK アプリケーションのエントリポイント。ap-northeast-1 に AwsCdkCloudWanTgwS2SVpnStack を 1 つ定義
├── lib
│ ├── aws-cdk-cloud-wan-tgw-s2s-vpn-stack.ts # メイン Stack。Cloud WAN / TGW×2 / VPC×6 / VPN×3 / Cloud WAN-TGW peering 一式を組み立て
│ ├── constructs
│ │ ├── core-network.ts # Cloud WAN の GlobalNetwork / CoreNetwork / prod セグメント / attachment-policies を定義する Construct
│ │ ├── index.ts # Construct のバレルファイル
│ │ ├── private-vpc.ts # ワークロード用 VPC の Construct。discriminated union で Cloud WAN attach と TGW attach を切替 (TGW 時は RT association/propagation も自動生成)
│ │ ├── transit-gateway.ts # TGW + 明示 Route Table を作成。Cloud WAN peering 用 Policy Table を AwsCustomResource (createTransitGatewayPolicyTable) で作成
│ │ └── vpn-vpc.ts # オンプレ接続用 VPC の Construct。VPN Router EC2 / EIP / CGW / Site-to-Site VPN を含む。Cloud WAN/TGW attach を props で切替、TGW 時はDescribeTransitGatewayAttachments で attachment ID を取得し RT association/propagation を実行
│ └── network-config.ts # CIDR / ASN / セグメント名 / VPN tunnel inside CIDR / PSK など全設定を集中管理
├── src
│ └── ec2
│ └── vpn-router-userdata.sh # VPN Router EC2 の UserData。Libreswan (IPsec) + FRR (BGP) + ネットワーク namespace (vrf1) を自動セットアップ。CGW_ASN / AWS_ASN を Fn::Sub で受け取り
Cloud WAN / TGW 双方で再利用可能
├── test
│ ├── aws-cdk-cloud-wan-tgw-s2s-vpn.test.ts # Stack 全体のユニットテスト。リソース数 (TGW×2 / VPC×6 / VPN×3 / EIC×5 など) と prod segment tag を検証
│ └── constructs
│ ├── core-network.test.ts # CoreNetwork の policy document (prod segment / attachment-policies) を検証
│ ├── private-vpc.test.ts # Cloud WAN attach / TGW attach の両ケースで attachment 種別とルート先を検証
│ ├── transit-gateway.test.ts # TGW が default RT 無効 + 明示 RT を作成し、ASN が prop で渡せることを検証
│ └── vpn-vpc.test.ts # Cloud WAN attach / TGW attach / createEicEndpoint=false の各パターンで VPN リソース構成を検証
├── cdk.context.json
├── cdk.json
├── jest.config.js
├── package.json
├── pnpm-lock.yaml
├── README.md
├── .gitignore
├── .npmignore
└── tsconfig.json
Cloud WANとTransit Gatewayを関連付けるステップは以下のとおりです。
- Transit Gateway policy tableの作成
- Cloud WANのGlobal NetworkにTransit Gatewayを登録
- Cloud WANのGlobal NetworkにてTransit Gatewayとのピアリングを作成
- (1)で作成したTransit Gateway policy tableを指定
- Cloud WANのCore NetworkにてアタッチメントタイプをTransit Gateway route tableとしてアタッチメントを作成
- 以下を指定
- (3)で作成したTransit Gatewayピアリング
- Transit Gateway
- アタッチメントポリシーに一致するようなタグ
- 以下を指定
Core network Policy自体は以下のとおりです。
{
"core-network-configuration": {
"vpn-ecmp-support": true,
"asn-ranges": [
"64512-64555"
],
"edge-locations": [
{
"location": "ap-northeast-1",
"asn": 64512
}
],
"inside-cidr-blocks": [
"192.168.0.0/16"
]
},
"version": "2021.12",
"attachment-policies": [
{
"rule-number": 100,
"condition-logic": "or",
"description": "attachment segment prod",
"action": {
"association-method": "constant",
"segment": "prod"
},
"conditions": [
{
"type": "tag-value",
"value": "prod",
"operator": "equals",
"key": "cloudwan-seg"
}
]
}
],
"segments": [
{
"name": "prod",
"require-attachment-acceptance": false,
"edge-locations": [
"ap-northeast-1"
]
}
]
}
環境の確認
Core Network
作成した環境の確認をします。
まずはCore Networkです。
アタッチメントは以下のように4つ存在しています。

ピアリングはTransit Gateway分の2つが存在しています。

トポロジグラフは以下のとおりです。Transit Gatewayを介して接続しているVPCやSite-to-Site VPNはここからでは確認できないですね。

トポロジツリーも然りです。

論理ビューでもTransit Gatewayと接続しているVPCとSite-to-Site VPNは確認できません。

ただし、ルートを確認すると確かにTransit Gatewayと接続しているVPCとSite-to-Site VPNのCIDRが登録されていました。

BGPに関する細かい情報はルーティング情報ベースから確認できます。

Transit Gatewayと接続しているSite-to-Site VPNは以下のように2つのASNがAS Pathとして登録されていることが分かります。

Transit Gatewayネットワーク
続いて、Transit Gatewayネットワークです。
概要ではTransit Gatewayと接続しているVPNやピアのステータス、イベントが確認できます。

地域ではTransit Gatewayと接続しているリソースの配置を確認することが可能です。

トポロジグラフを確認すると、Transit Gatewayと接続しているVPCやSite-to-Site VPNも表示されました。

イベントではGlobal Networkに関するイベントを確認できました。

モニタリングでも然りです。

ルートアナライザーではTransit Gateway間の通信パスを論理的に評価することが可能です。しかし、Cloud WANとTransit Gatewayと接続している場合、Transit GatewayピアリングはTransit Gateway route tableと直接関連付けられているのではなく、Transit Gateway policy tableを介して関連付けられているため、評価をすることはできません。注意しましょう。あくまでTransit Gateway同士で直接ピアリングされている場合など、Cloud WANと関連付けられていない場合に使用する機能です。

Transit Gateway route table
Transit Gateway route tableも確認します。
関連付けを確認してもCloud WANとのピアリングはないことが分かります。

無理にピアリングのTransit Gateway attachmentを関連付けようとしても、Cannot have both PolicyTableAssociation and RouteTableAssociation on the same TransitGateway Attachment: tgw-attach-05461cd995a942214とTransit Gateway policy tableと関連付け済みであるがためにエラーになります。

伝播はTransit Gatewayに接続している全てのアタッチメントが設定されています。

ちなみにそれぞれの伝播を削除すると、このTransit Gateway route tableから伝播されたルートが削除されるのはもちろん、Cloud WANへのルートの伝播もされなくなります。これはこのTransit Gateway route tableをCloud WANと関連付けているためです。
ルートは以下のようにCloud WANに接続しているもの含めて全てのネットワークアドレスが登録されています。

疎通確認
疎通確認です。
VPN VPC 2のEC2インスタンスからVPN VPC 3のEC2インスタンスへpingを打ちます。
$ hostname -i
10.11.1.138
$ ping -c 4 10.21.1.206
PING 10.21.1.206 (10.21.1.206) 56(84) bytes of data.
64 bytes from 10.21.1.206: icmp_seq=1 ttl=121 time=10.4 ms
64 bytes from 10.21.1.206: icmp_seq=2 ttl=121 time=6.33 ms
64 bytes from 10.21.1.206: icmp_seq=3 ttl=121 time=6.14 ms
64 bytes from 10.21.1.206: icmp_seq=4 ttl=121 time=6.21 ms
--- 10.21.1.206 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 6.142/7.262/10.370/1.795 ms
はい、問題なく通信できました。
図示すると以下のとおりです。

Transit GatewayとCloud WANを連携させてルーティングできる
AWS Cloud WANとAWS Transit Gatewayを関連付けてTransit Gatewayと接続しているVPCやSite-to-Site VPNの経路情報をCloud WANに登録してみました。
Transit GatewayとCloud WANを連携させてルーティングできることが分かりました。Transit Gatewayとのピアリング間で明示的にルートを追加する必要がないのは楽ですね。買収などで組織が拡大していく中で複数のTransit Gatewayがある場合、Cloud WANを使って通信をコントロールするというシナリオもあるでしょう。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!








