AWS Transit Gatewayでアウトバウンドサブネットを集約する!

AWS Transit Gateway雑感

VPCをGWに直接収容できる
サブネット単位で細かくルートを制御できる
料金

VPCをGWに直接収容できる

AWS Transit GatewayではVPCアタッチメントが用意されており、VPCを直接収容できる。

似たようなコンセプトのGCP Network Connectivity Centerには直接VPCを収容することができず、VPCとの間でVPN接続を構成しVPCを収容することになる。このため多くのVPCを相互接続する場合、AWS Transit GWのほうがシンプルな構成で実現できると言える。ちなみに、AzureにもVirtual WANという同様のサービスがあり、こちらはvNetを仮想ハブへダイレクトに収容できる。

サブネット単位で細かくルートを制御できる

AWSと異なりGCPのルーティングテーブルはVPC単位で管理される。このためオンプレミスの感覚でサブネット単位でルートを制御しきるのが難しい側面がある。ネットワークタグによりルートの適用範囲を制限することはできるが、共有環境ではNWタグを勝手に使われないような対策を考える必要がある。

料金

Transit Gateway自体は無料、VPCと接続するための
Transit Gatewayアタッチメントは1つ36.5USD/月必要だが、マルチAZ構成をとっている場合はVPCあたり2アタッチメントが必要だ。これとは別にデータ転送料として1GBあたり0.02USDとなっている。

今回の構成

Transit Gatewayサブネットは配置しないものとする。

想定する結果

VPC1-VPC2のVM間でPINGできる
VPC1,VPC2からVPC3を経由しインターネットにアクセスできる

Transit Gateway

resource "aws_ec2_transit_gateway" "tgw" {
  description = "tgw"
  default_route_table_association="disable"
  default_route_table_propagation="disable"
}

オプション:

default_route_table_association - Transit GWアタッチメントにデフォルトで紐づくルートテーブル
別途定義したルートテーブルを紐づけるので無効化
default_route_table_propagation - Transit GWのデフォルトルートテーブルにTransit Gateway アタッチメントを伝達するかどうか
デフォルトルートテーブルは使わないので無効化

Transit Gatewayのルートテーブル

Transit Gatewayに紐づくアタッチメントに紐づく

Staticルート

0.0.0.0/0からVPC3アタッチメントへのルート

VPC1,VPC2からTransit GWに送られてきたインターネット宛のパケットをVPC3のPrivateサブネットに送るために必要となるデフォルトルート。

resource "aws_ec2_transit_gateway_route" "tgw_default_route" {
  destination_cidr_block         = "0.0.0.0/0"
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.vpc3_attachment.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.tgw_rtbl.id
}

Dynamicルート

Transit GWルートテーブルに挿入される各VPCアタッチメントの接続されたサブネットの属するVPC CIDRを含むルート。Transit GWにきたパケットを適切なTransit GWアタッチメントに転送するために必要となる。

resource "aws_ec2_transit_gateway_route_table_propagation" "tgw_default_propagation1" {
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.vpc1_attachment.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.tgw_rtbl.id
}

resource "aws_ec2_transit_gateway_route_table_propagation" "tgw_default_propagation2" {
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.vpc2_attachment.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.tgw_rtbl.id
}

resource "aws_ec2_transit_gateway_route_table_propagation" "tgw_default_propagation3" {
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.vpc3_attachment.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.tgw_rtbl.id
}

動作確認

インターネット宛の通信

  [ec2-user@ip-172-24-1-42 ~]$ curl google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>

VPC1,VPC2からVPC3経由のインターネットあて通信を実現するには、VPC3のIGWから出ててPubサブネットに帰ってきたパケットがTransit GWまで戻れるよう、PubサブネットにVPC1,VPC2に対するルートを定義する必要がある。

resource "aws_route" "vpc3_public_to_onprem" {
  destination_cidr_block = "172.16.0.0/12"
  route_table_id         = aws_route_table.vpc3_public_rtbl.id
  transit_gateway_id     = aws_ec2_transit_gateway.tgw.id
}

Transit Gatewayを経由したVPC1,VPC2(VM間)の相互接続

# ssh -i key ec2-user@172.24.1.42

       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

...
[ec2-user@ip-172-24-1-42 ~]$

DefaultのSecurity Groupは異なるSGに属するVMからのアクセスをブロックするようになっている。このため、VPC1-VPC2間通信許可のためのインバウンドSGルールを別途追加しておく必要がある。

VPC Reachability Analyzerによるトラブルシューティング

通信のFrom/Toを指定し、その間で通信を阻害する要素の存在をチェックしてくれる。

実行結果に表示される日本語のメッセージからは原因を把握しづらいものの、ここで示されているSecurity Groupのインバウンドルールが対向サブネットをブロックしているという原因を的確に指摘してくれていた。

目次