Transit Gateway on 図解わかりやすいAWS

マルチリージョン接続 — DX-GWの限界とTransit Gatewayピアリング

Sat, 26 Nov 2022 00:00:00 +0000

連載: VyOSで作るAWSハイブリッド接続（全4回）

単一Site-to-Site VPN — VyOS×AWSの基礎

トンネル冗長化とBGP経路制御

Transit Gatewayへの置き換えとECMP

マルチリージョン接続 — DX-GWの限界とTGWピアリング（この記事）

0. この回のテーマ

第3回で、VPNの終端をリージョンのハブ＝Transit Gatewayにしました。ハブができたので、次の自然な欲求は 「別のリージョンともつなぎたい」 です。

東京（ap-northeast-1）のVPCと、バージニア（us-east-1）のVPCを相互接続し、さらにオンプレ（VyOS）から両リージョンに届く状態をゴールにします。

ここで多くの人が最初に考えるのが Direct Connect Gateway（DX-GW） です。「DX回線を複数リージョンで共用できる」と聞くと、リージョン間もつながりそうに見える。ところが、ここに落とし穴があります。この回は「DX-GWでは越えられない壁」を確認してから、正しい道具＝TGWピアリングで超えます。

1. なぜDX-GWではリージョン間がつながらないのか

DX-GWは、1本のDirect Connect回線を、複数リージョン・複数アカウントのVPC/TGWから共用するための仕組みです。「オンプレ↔各リージョン」の通信を提供します。

ですが、DX-GWはリージョン間（TGW↔TGW）のルートを交換しません。各リージョンのTGWルートテーブルは、DX-GW経由で別リージョンの経路を学習しないからです。

図の × がそれです。オンプレからは各リージョンに届くのに、東京VPC ↔ バージニアVPC が直接つながらない。DX-GWはあくまで「オンプレとAWSをつなぐDX回線の共用ポイント」であって、「リージョン間ルータ」ではないからです。

補足: 今回DXは用意できないので、DX-GWは「あるものと想定」して実際には構築していません。Terraform定義だけ置いておきます。要点は 「DX-GWの守備範囲はオンプレ↔AWSであって、リージョン間ではない」 という役割の理解です。

DX-GWのTerraform（参考・未構築）

resource "aws_dx_gateway" "test" {
 name = "satoshi-dxgw"
 amazon_side_asn = "64600"
}

// 東京TGWをDX-GWに関連付け
resource "aws_dx_gateway_association" "jp_tgw" {
 dx_gateway_id = aws_dx_gateway.test.id
 associated_gateway_id = aws_ec2_transit_gateway.tgw.id
 allowed_prefixes = [
 "10.99.0.0/16", # 東京VPC
 "10.0.2.0/24", # オンプレ(VPN経由)
 ]
}

// バージニアTGWをDX-GWに関連付け
resource "aws_dx_gateway_association" "us_tgw" {
 provider = aws.us
 dx_gateway_id = aws_dx_gateway.test.id
 associated_gateway_id = aws_ec2_transit_gateway.tgw_us.id
 allowed_prefixes = ["10.201.0.0/16"] # バージニアVPC
}

allowed_prefixes で各リージョンの経路を許可しても、それは「オンプレ↔そのリージョン」の話。リージョン同士の経路はここには現れません。

2. リージョン間をつなぐ正解 — Transit Gatewayピアリング

リージョン間を直接つなぐ道具が TGWピアリングです。東京TGWとバージニアTGWを1対1でピアリングし、AWSのバックボーン上でリージョン間トラフィックを運びます。

構成のポイントは2つあります。

① TGWのASNをリージョンごとに分ける

ピアリングする2つのTGWは、別々のASNを持たせます（今回は東京 65100 / バージニア 65200）。

// 東京TGW
resource "aws_ec2_transit_gateway" "tgw" {
 amazon_side_asn = 65100
 auto_accept_shared_attachments = "enable"
 tags = { Name = "satoshi-tgw-jp" }
}

// バージニアTGW
resource "aws_ec2_transit_gateway" "tgw_us" {
 provider = aws.us
 amazon_side_asn = 65200
 auto_accept_shared_attachments = "enable"
 tags = { Name = "satoshi-tgw-us" }
}

② ピアリングは「張る」と「ルートを書く」が別作業

ここが一番の落とし穴です。TGWピアリングはBGPでルートを自動伝播しません。ピアリング接続を張っただけでは1パケットも流れない。各TGWのルートテーブルに、相手リージョンのCIDR宛のルートを手で登録して初めて通ります。

VPNやVPC内のダイナミックなルート学習に慣れていると、ここで確実にハマります。ピアリングは「線をつなぐ」だけ、「どの宛先をその線に流すか」は別途スタティックに教える、と覚えてください。

// ピアリング接続を張る（東京→バージニア）
resource "aws_ec2_transit_gateway_peering_attachment" "jp_us" {
 peer_region = "us-east-1"
 peer_transit_gateway_id = aws_ec2_transit_gateway.tgw_us.id
 transit_gateway_id = aws_ec2_transit_gateway.tgw.id
}

// バージニア側で受諾
resource "aws_ec2_transit_gateway_peering_attachment_accepter" "tgw_us" {
 provider = aws.us
 transit_gateway_attachment_id = aws_ec2_transit_gateway_peering_attachment.jp_us.id
}

// 東京TGWルートテーブル: バージニアVPC宛 → ピアリングへ
resource "aws_ec2_transit_gateway_route" "jp_to_us" {
 destination_cidr_block = "10.201.0.0/16" // バージニアVPC
 transit_gateway_attachment_id = aws_ec2_transit_gateway_peering_attachment.jp_us.id
 transit_gateway_route_table_id = aws_ec2_transit_gateway.tgw.association_default_route_table_id
}

// バージニアTGWルートテーブル: 東京VPC宛・オンプレ宛 → ピアリングへ
resource "aws_ec2_transit_gateway_route" "us_to_jp" {
 provider = aws.us
 destination_cidr_block = "10.99.0.0/16" // 東京VPC
 transit_gateway_attachment_id = aws_ec2_transit_gateway_peering_attachment.jp_us.id
 transit_gateway_route_table_id = aws_ec2_transit_gateway.tgw_us.association_default_route_table_id
}

resource "aws_ec2_transit_gateway_route" "us_to_onprem" {
 provider = aws.us
 destination_cidr_block = "10.0.2.0/24" // オンプレ(VyOS)
 transit_gateway_attachment_id = aws_ec2_transit_gateway_peering_attachment.jp_us.id
 transit_gateway_route_table_id = aws_ec2_transit_gateway.tgw_us.association_default_route_table_id
}

バージニア側からオンプレ（10.0.2.0/24）に戻すルートも忘れずに。東京TGWを経由してVPNに落ちるので、10.0.2.0/24宛もピアリングアタッチメントに向けます。

3. オンプレ（VyOS）から見えるもの

面白いのは、VyOSは何も追加設定していないのに、バージニアVPC（10.201.0.0/16）への経路を学習している点です。東京AWSが、VPN越しに「US向けはこっち」とBGPで広告してくれるからです。しかも第3回のECMPが効いていて、2本のトンネル両方から等コストで届いています。

vyos@vyos:~$ show ip route
B>* 10.99.0.0/16 [20/100] via 169.254.61.113, vti1, weight 1 ## 東京VPC
 * via 169.254.234.49, vti0, weight 1
B>* 10.201.0.0/16 [20/100] via 169.254.61.113, vti1, weight 1 ## バージニアVPC(新規)
 * via 169.254.234.49, vti0, weight 1

BGPテーブルでも、東京・バージニア両方のVPCが、AS-PATH 65100（東京TGWのASN）越しに2本で見えています。

vyos@vyos:~$ show ip bgp
 Network Next Hop Metric LocPrf Weight Path
*> 10.0.2.0/24 0.0.0.0 0 32768 i
*= 10.99.0.0/16 169.254.61.113 100 0 65100 i
*> 169.254.234.49 100 0 65100 i
*= 10.201.0.0/16 169.254.61.113 100 0 65100 i
*> 169.254.234.49 100 0 65100 i

4. エンドツーエンドの疎通確認

3つの経路をすべて確認します。

東京VPC → バージニアVPC（リージョン間。これがDX-GWでは通らなかった経路）:

$ ping 10.201.33.240
64 bytes from 10.201.33.240: icmp_seq=1 ttl=252 time=147 ms
64 bytes from 10.201.33.240: icmp_seq=2 ttl=252 time=145 ms

オンプレVyOS → バージニアVPC（VPN→東京TGW→ピアリング→バージニア、と3ホップ跨ぐ）:

vyos@vyos:~$ ping 10.201.33.240 source-address 10.0.2.15
64 bytes from 10.201.33.240: icmp_seq=1 ttl=251 time=169 ms
64 bytes from 10.201.33.240: icmp_seq=2 ttl=251 time=170 ms

バージニアVPC → オンプレVyOS（戻り。バージニアTGWの10.0.2.0/24ルートが効いている証明）:

$ ping 10.0.2.15
64 bytes from 10.0.2.15: icmp_seq=1 ttl=61 time=166 ms
64 bytes from 10.0.2.15: icmp_seq=2 ttl=61 time=176 ms

東京経由（約25ms）に対し、バージニアは約145〜170ms。太平洋を渡る分のレイテンシがそのまま乗っていて、AWSバックボーン経由でリージョン間を通っていることが数字でも分かります。

5. 連載のまとめと、ここから先

4回かけて、VyOSを偽オンプレCGWに見立てたまま、AWSハイブリッド接続の能力を1段ずつ積み上げました。

回	到達点	核心
1	単一VPN	IPsec+BGPの基礎と「謎の値の出どころ」
2	冗長化	BGP経路制御は方向で道具が変わる（Weight / AS-Path Prepend）
3	TGW + ECMP	終端をハブルータTGWに。MED 100/100で両系アクティブ、非対称ルーティングの副作用
4	マルチリージョン	DX-GWはリージョン間を繋がない。TGWピアリングは「張る」と「ルートを書く」が別作業

道具の守備範囲を取り違えない、というのが通底するテーマでした。VGWとTGW、DX-GWとTGWピアリング——名前が似ていても役割の格が違います。

今後の拡張（未検証・構想）

この検証環境はさらに伸ばせます。以下は今後の課題として:

AWS Network Firewall: SG/ACLでは難しい、ステートフル＋ブラックリスト＋ドメインベースのフィルタを中央集約。TGWの経路上に挟む構成
Accelerated Site-to-Site VPN: AWS Global Accelerator経由でVPNを高速化（TGW終端が必須、VGW不可）
PrivateLink / Route 53 Resolver: サービス公開・DNSのハイブリッド解決

ベースができていれば、これらは「経路の途中に何を挟むか」の話に落ちます。土台としてのVyOS×TGW構成は、そのまま実験台に使えます。

VGWからTransit Gatewayへ — VPNのECMP冗長化

Thu, 24 Nov 2022 00:00:00 +0000

連載: VyOSで作るAWSハイブリッド接続（全4回）

単一Site-to-Site VPN — VyOS×AWSの基礎

トンネル冗長化とBGP経路制御

Transit Gatewayへの置き換えとECMP（この記事）

マルチリージョン接続 — DX-GWの限界とTGWピアリング

0. この回のテーマ

第2回では、VPNの終端に VGW（仮想プライベートゲートウェイ） を使い、2本のトンネルをBGPでアクティブ/スタンバイに制御しました。

今回はこの終端を Transit Gateway（TGW） に置き換えます。狙いは2つです。

2本のトンネルを同時に使う（ECMP / ロードバランス） 構成にする
将来の拡張（複数VPC・マルチリージョン）の土台を作る

VGWとTGWは役割の格が違う

ネットワーク機器の感覚で対比すると分かりやすいです。

	VGW	Transit Gateway
立ち位置	1つのVPC専用のVPN終端装置	リージョン規模のハブルータ
束ねられるもの	そのVPCとのVPN/DXだけ	複数VPC・複数VPN・DX・別リージョンのTGWまで
例えるなら	拠点ルータのVPNモジュール	データセンターのコアスイッチ／ルータ

VGWが「VPCに後付けするVPN口」なら、TGWは「VPCもVPNもDXも全部ぶら下げる中央ルータ」です。今はVPN1本をつなぐだけですが、第4回でこのハブ性がマルチリージョン接続の鍵になります。

そしてもう一つ、TGWはECMP（Equal-Cost Multi-Path）に対応しています。これが今回の挙動差の本体です。

1. VyOS側: 経路制御を「外す」

第2回では、2本を意図的に偏らせるためにWeightとAS-Path Prependを入れました。ECMPは両トンネルを等コストにして同時利用するのが目的なので、この偏りを削除します。

// VyOS → AWS の偏り（Weight）を削除
delete protocols bgp neighbor 169.254.234.49 address-family ipv4-unicast weight '300'

// AWS → VyOS の偏り（AS-Path Prepend）を削除
delete protocols bgp neighbor 169.254.61.113 address-family ipv4-unicast route-map export 'VPC-Tunnel-2-OUT'

削除後のBGPテーブルを見ると、2本が等コストになり、*=（multipath = ECMP対象）のマークが付きます。

vyos@vyos:~$ show ip bgp
 Network Next Hop Metric LocPrf Weight Path
*> 10.0.2.0/24 0.0.0.0 0 32768 i
*> 10.99.0.0/16 169.254.234.49 100 0 64512 i
*= 169.254.61.113 100 0 64512 i ## = はmultipath

*> と *= の両方が有効経路として使われる状態、これがECMPです。

2. AWS側: VGWを外しTGWを作る（Terraform）

ここから初めてTerraformで組みます。やることは「TGWを作る」「ネットワーク用サブネットにアタッチする」「VPN接続をTGWに紐づける」の3点です。

// Transit Gateway本体
resource "aws_ec2_transit_gateway" "tgw" {
 auto_accept_shared_attachments = "enable"
 tags = { Name = "satoshi-tgw" }
}

// TGWをネットワーク用サブネットにアタッチ
resource "aws_ec2_transit_gateway_vpc_attachment" "tgw" {
 subnet_ids = [aws_subnet.network.id]
 transit_gateway_id = aws_ec2_transit_gateway.tgw.id
 vpc_id = var.vpc.id
 tags = { Name = "tgw-attach-shared-vpc" }
}

// Publicサブネットから、オンプレ(10.0.2.0/24)宛をTGWへ向けるルート
resource "aws_route" "public_tgw" {
 route_table_id = aws_route_table.pub.id
 destination_cidr_block = "10.0.2.0/24"
 transit_gateway_id = aws_ec2_transit_gateway.tgw.id
}

// Site-to-Site VPNの接続先を VGW ではなく TGW にする
resource "aws_vpn_connection" "vpn" {
 transit_gateway_id = aws_ec2_transit_gateway.tgw.id // ← ここがVGWからの変更点
 customer_gateway_id = aws_customer_gateway.cgw.id
 type = "ipsec.1"
 static_routes_only = false // 動的(BGP)

 tunnel1_log_options {
 cloudwatch_log_options {
 log_enabled = true
 log_group_arn = aws_cloudwatch_log_group.vpn.arn
 log_output_format = "json"
 }
 }
 tags = { Name = "${var.name}-vpn-01" }
}

TGWアタッチで踏みやすい3つの注意点

AZの一致: あるサブネットからTGW経由で通信したいなら、そのサブネットと同じAZにTGWのアタッチメント（ENI）が存在している必要があります。AZをまたぐと無言で届きません。
専用サブネット推奨: TGWアタッチ用に小さな専用サブネットを切るのがベストプラクティス。EC2を置くサブネットと混ぜない。
ルートテーブルへの明示: VPCのルートテーブルに、オンプレ宛（10.0.2.0/24）をTGW向きで登録する必要があります。VGWの「ルート伝搬」のようには自動で入りません。

3. 検証: VGWとの挙動差（MEDとECMP）

ここが第2回との一番面白い対比です。VPNテーブルを見ると、両トンネルともMEDが100で通知されています。

vyos@vyos:~$ show ip bgp
 Network Next Hop Metric LocPrf Weight Path
*> 10.0.2.0/24 0.0.0.0 0 32768 i
*> 10.99.0.0/16 169.254.234.49 100 0 64512 i
* 169.254.61.113 100 0 64512 i

第2回のVGWは 100 / 200 を付けてアクティブ/スタンバイに誘導してきました。TGWは 100 / 100 の等コスト。これがTGWのデフォルトが**ECMP（両系アクティブ）**である証拠です。終端を替えただけで、AWS側のBGP広告の性格が変わる、というのは押さえどころです。

	VGW（第2回）	TGW（今回）
AWSが付けるMED	100 / 200	100 / 100
デフォルト挙動	アクティブ/スタンバイ	ECMP（両系同時利用）

非対称ルーティングに注意

ECMPの実機検証で、実際にこういう現象が出ます。AWS側からpingを打つと、行きと戻りで別々のトンネルを通ることがあります。

VyOS側から打つと、両方向とも同じ経路（.6系）に乗りました。

これがECMPの本質的な副作用、非対称ルーティングです。経路が等コストで複数あると、ハッシュ次第で行きと戻りが別トンネルになる。

ICMPなら問題なく返りますが、経路上にステートフルな機器（FW・NAT・IDS等）があると致命的になり得ます。行きのパケットしか見ていない機器が戻りを不正と判断して落とすからです。実運用でECMPを使うなら、経路上のステートフル機器の有無を必ず確認してください。スループットを稼ぎたいだけなら第2回のアクティブ/スタンバイの方が安全、という判断もあります。

4. 完成形

VPNの終端がVGWからTransit Gatewayに替わり、2本のトンネルがECMPで同時に使われる構成です。

まとめ

VGWは1VPC専用のVPN口、TGWはリージョンのハブルータ。格が違う
終端をTGWにすると、AWSのMEDが 100/100の等コストになり、デフォルトで**ECMP（両系アクティブ）**になる（VGWは100/200のアクティブ/スタンバイ）
ECMPには非対称ルーティングの副作用がある。経路上にステートフル機器があると危険
TGWアタッチは AZ一致・専用サブネット・ルートの明示登録 が踏みどころ
TGWというハブを手に入れたことで、次回は別リージョンとの接続に進めます。ここで「DX-GWではリージョン間がつながらない」という壁にぶつかり、TGWピアリングで超えます。

Transit Gateway on 図解 わかりやすいAWS

マルチリージョン接続 — DX-GWの限界とTransit Gatewayピアリング

0. この回のテーマ

1. なぜDX-GWではリージョン間がつながらないのか

2. リージョン間をつなぐ正解 — Transit Gatewayピアリング

① TGWのASNをリージョンごとに分ける

② ピアリングは「張る」と「ルートを書く」が別作業

3. オンプレ（VyOS）から見えるもの

4. エンドツーエンドの疎通確認

5. 連載のまとめと、ここから先

今後の拡張（未検証・構想）

VGWからTransit Gatewayへ — VPNのECMP冗長化

0. この回のテーマ

VGWとTGWは役割の格が違う

1. VyOS側: 経路制御を「外す」

2. AWS側: VGWを外しTGWを作る（Terraform）

TGWアタッチで踏みやすい3つの注意点

3. 検証: VGWとの挙動差（MEDとECMP）

非対称ルーティングに注意

4. 完成形

まとめ

Transit Gateway on 図解わかりやすいAWS