マルチリージョン接続 — 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構成は、そのまま実験台に使えます。

Direct Connect on 図解 わかりやすいAWS