AWS Transit Gateway と Regional NAT Gateway を使ってアウトバウンドを集約するうえで、できることできないことをまとめる

はじめに

こんにちは、そしてこんばんは！
サービスプラットフォーム事業部の大嵩です。

今回は、Regional NAT Gateway と AWS Transit Gateway を組み合わせて複数 VPC のインターネット出口を 1 つにまとめる構成で、何ができて何ができないのかを検証します！

複数の VPC を運用していると、VPC ごと・AZ ごとに NAT Gateway を並べることになり、費用も運用（AZ ごとのルートテーブル管理）もじわじわきますよね。
Regional NAT Gateway が出てからは1 つ作れば AZ をまたいで面倒を見れると思っていたのですが、Transit Gateway（以下 TGW）で集約する構成にそのまま載せられるのかがずっと気になっていました。
GA 直後は「TGW 集約には使えない」という話もあったので、今どうなっているのかを手を動かして確かめてみます！

Regional NAT Gateway とは

まずは公式ドキュメントの説明から。

Use regional NAT gateways when you want to simplify your network architecture, improve your security posture, and configure high availability by default. A regional NAT gateway automatically expands across Availability Zones based on your workload presence. Unlike standard NAT gateways (referred to as zonal NAT gateways), which operate in a single Availability Zone, regional NAT gateways follow your workloads to provide automatic high availability.

とのことですが、要するに「1 つの NAT Gateway ID で全 AZ をカバーし、ワークロードのある AZ に自動で広がってくれる NAT Gateway」ですね！
従来の NAT Gateway は「Zonal NAT Gateway」と呼び分けられるようになりました。

違いをまとめるとこんな感じです。

パブリックサブネットが不要。VPC を指定するだけで作れる
ルートテーブルには AZ を問わず同じ NAT Gateway ID を書けばよい
VPC 内の ENI（ネットワークインターフェース）を検知して、その AZ に自動で展開・縮退する
AZ あたり最大 32 IP（ゾーナルは 8 IP）
作成時に 専用のルートテーブル が自動で作られ、0.0.0.0/0 → インターネットゲートウェイ が最初から入っている

この「専用のルートテーブル」が今回の主役です。
Zonal NAT Gateway ではパブリックサブネットのルートテーブルに戻りルートを書いていましたが、Regional NAT Gateway ではこの専用ルートテーブルに書くことになります。

注意！

接続タイプは Public のみ です。Private NAT（重複 CIDR を吸収する用途）はZonal NAT Gateway を使う必要があります
料金は 稼働している AZ の数だけ時間料金がかかります。「1 つにまとめた」からといって時間料金が 1 個分になるわけではありません
新しい AZ への展開には最大 60 分かかるとドキュメントに書かれています。展開が終わるまでは既存の AZ でクロス AZ 処理されます

Regional NAT gateways for automatic multi-AZ expansion - Amazon Virtual Private Cloud

Use regional NAT gateways when you want to simplify your network architecture, improve security posture, and configure high availability by default. A regional NAT gateway automatically expands across Availability Zones based on your workload presence.

docs.aws.amazon.com

これまで TGW と組み合わせられなかった話

Regional NAT Gateway は 2025 年 11 月に GA しました。

https://aws.amazon.com/about-aws/whats-new/2025/11/aws-nat-gateway-regional-availability

aws.amazon.com

ところが GA 直後の専用ルートテーブルは、ルートのターゲットに インターネットゲートウェイ / ENI / Gateway Load Balancer エンドポイント しか選べませんでした。
TGW 集約構成では「NAT Gateway から Spoke VPC への戻りトラフィックを TGW に向ける」ルートが必須なので、これができないと成立しません。
TGW アタッチメントの ENI を直接ターゲットにする回避策はあったものの、特定 AZ の ENI に固定されるので SPOF になってしまい、「現状オススメしない」と声が出ていました。。。

その後、2026 年 5 月ごろのアップデートで専用ルートテーブルに TGW をターゲット指定できるようになりました！
公式ドキュメントにもこう書かれています。

Regional NAT gateways support AWS Transit Gateway as a valid route in the regional NAT gateway route table. Regional NAT gateways do not support private NAT. If you need private NAT, use zonal NAT gateways instead.

とのことで、TGW 集約の道が開けたわけですね！

じゃあ、実際どこまで使えるのか？
私は 自動モード で「TGW アタッチメントの ENI だけを置いた Egress VPC で本当に AZ 展開するのか」「何分かかるのか」と、ドキュメントに書いてある「できないこと」が本当にできないのかを、まとめて確かめてみます！

本記事のゴール

Regional NAT Gateway を Egress VPC に 1 つだけ置き、TGW 経由で複数の Spoke VPC からインターネットに出る構成を実際に組んで、次のことを確かめます！

専用ルートテーブルに TGW を指定するだけで、本当に集約構成が成立するのか
Egress VPC に EC2 を 1 台も置かず、TGW アタッチメントの ENI だけで自動モードの AZ 展開が起きるのか。起きるなら何分かかるのか
展開が終わる前と後で、通信はどの AZ から出ていくのか
Egress VPC に無い AZ に Spoke がいたらどうなるのか
blackhole で Spoke 間を遮断したまま、インターネットへの通信だけ通せるのか
ドキュメントに「できない」と書いてあること（Private NAT、専用ルートテーブルの関連付けやターゲットの制約）は、実際に API を叩くとどう弾かれるのか

結論から言うと、集約構成はちゃんと成立しました！
ただ、途中で「blackhole を消しても Spoke 間が通らない」「Private 指定がエラーにならず Public になる」といった、ドキュメントを読んだだけでは気づけない挙動にいくつか当たったので、そのあたりも含めて紹介します。

今回の構成

Egress VPC（10.0.0.0/16）: TGW アタッチメント用サブネットを 1a / 1c に置き、あとから 1d を追加します。インターネットゲートウェイと Regional NAT Gateway（自動モード）だけで、パブリックサブネットも EC2 も置きません
Spoke A（10.1.0.0/16）: 1a / 1c のプライベートサブネットに EC2 を 1 台ずつ。AZ アフィニティの確認用です
Spoke B（10.2.0.0/16）: 1d のプライベートサブネットに EC2 を 1 台。Egress VPC に「無い」AZ からの通信を見るためです
TGW: デフォルトルートテーブルの自動関連付け・伝播は切り、App と Egress の 2 枚を明示的に使います

ルートの流れは次のとおりです。

Spoke のプライベートサブネット: 0.0.0.0/0 → TGW
TGW App ルートテーブル（Spoke を関連付け）: 0.0.0.0/0 → Egress アタッチメント、10.0.0.0/8 → blackhole
TGW Egress ルートテーブル（Egress を関連付け）: Spoke の CIDR を伝播
Egress VPC の TGW サブネット: 0.0.0.0/0 → Regional NAT Gateway
Regional NAT Gateway の専用ルートテーブル: 0.0.0.0/0 → IGW（自動）に加えて 10.1.0.0/16 → TGW、10.2.0.0/16 → TGW を追加

検証用の割り切りとして、Spoke には Session Manager 用の Interface VPC エンドポイントを置いています。
NAT 経由のインターネットが通らない状態でも EC2 に入れるようにするためです。
本番の集約構成であれば、エンドポイントも集約 VPC 側に寄せて Route 53 Private Hosted Zone を共有する設計になるかと思います。
また TGW アタッチメントは EC2 と同じサブネットに置いていますが、本番では TGW 専用の小さなサブネットを分けるのがベストプラクティスです。

環境準備（Terraform）

一式 Terraform で組みました。ポイントだけ抜き出します。

Regional NAT Gateway を作る

サブネットも EIP も指定しません。availability_mode = "regional" と VPC だけです。

resource "aws_nat_gateway" "regional" {
  vpc_id            = aws_vpc.egress.id
  availability_mode = "regional"
  connectivity_type = "public"

  tags = {
    Name = "${var.prefix}-egress-rnat"
  }

  depends_on = [aws_internet_gateway.egress]
}

専用ルートテーブルに TGW への戻りルートを足す

自動作成される専用ルートテーブルは Terraform 管理外ですが、aws_nat_gateway の route_table_id 属性で ID が取れるので、aws_route でルートだけを足せます。
ここが 2026 年 5 月のアップデートで可能になった箇所です！

resource "aws_route" "edge_to_spokes" {
  for_each = { for k, s in local.spokes : k => s.vpc_cidr }

  route_table_id         = aws_nat_gateway.regional.route_table_id
  destination_cidr_block = each.value
  transit_gateway_id     = aws_ec2_transit_gateway.this[0].id

  depends_on = [aws_ec2_transit_gateway_vpc_attachment.egress]
}

Egress VPC の TGW サブネットから NAT Gateway へ

AZ が違っても同じ NAT Gateway ID を書けるので、ルートテーブルは 1 枚で済みます。

resource "aws_route" "egress_tgw_default" {
  route_table_id         = aws_route_table.egress_tgw.id
  destination_cidr_block = "0.0.0.0/0"
  nat_gateway_id         = aws_nat_gateway.regional.id
}

TGW の App ルートテーブル

resource "aws_ec2_transit_gateway_route" "app_default" {
  destination_cidr_block         = "0.0.0.0/0"
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.egress[0].id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.app[0].id
}

resource "aws_ec2_transit_gateway_route" "app_blackhole" {
  destination_cidr_block         = "10.0.0.0/8"
  blackhole                      = true
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.app[0].id
}

AZ 展開の時間を測りたかったので、apply は 3 段階に分けました。

Egress VPC + IGW + Regional NAT Gateway だけ
TGW + Spoke + EC2 + 全ルート
Egress VPC に 1d の TGW サブネットを追加

hashicorp/aws プロバイダは 6.66.0 を使っています。全部で 58 リソースでした。

できること検証

まずは Regional NAT Gateway だけ作ってみる

ENI が 1 つも無い VPC に Regional NAT Gateway を作ると、どうなるんでしょうか？

作成直後の状態がこちらです。

❯ aws ec2 describe-nat-gateways --nat-gateway-ids nat-18209da7df598eb5d \
    --query 'NatGateways[0].NatGatewayAddresses[].[AvailabilityZone,PublicIp,Status]' --output text
ap-northeast-1c 57.180.107.76   succeeded

ワークロードがゼロでも、1 AZ 分（1c）の EIP は最初から確保される んですね！
ただし、この時点で Egress VPC の ENI 一覧を見ても NAT Gateway の ENI は出てきません。

専用ルートテーブルはこうなっていました。関連付けの欄に nat-xxxx が入っていて、ルートは local と 0.0.0.0/0 → IGW の 2 本です。

ちなみに、専用ルートテーブルには Name タグが付かないので、ルートテーブル一覧から探すときは次のフィルタが便利でした。

aws ec2 describe-route-tables --filters Name=association.gateway-id,Values=nat-18209da7df598eb5d \
  --query 'RouteTables[].RouteTableId' --output text

専用ルートテーブルに TGW をターゲット指定できる！

TGW と Spoke を含む 2 段階目を apply したところ、10.1.0.0/16 → tgw-xxxx、10.2.0.0/16 → tgw-xxxx のルートが無事に入りました！

コンソールで「ルートを編集」を開くと、ターゲットの候補に Transit Gateway が並んでいます。GA 当初はここに無かったわけですね。

TGW アタッチメントの ENI だけで AZ 展開するのか？

2 段階目の apply で Egress VPC に生えた ENI は、TGW アタッチメントの 2 つ（1a / 1c）だけです。
EC2 は 1 台もありません。これを Regional NAT Gateway は「ワークロード」と見てくれるのでしょうか・・・？

1 分間隔で describe-nat-gateways を回して記録した結果がこちらです。

apply 完了              2026-09-24 16:52:54
2026-09-24 17:01:00  ap-northeast-1a    None           associating
2026-09-24 17:07:05  ap-northeast-1a    13.114.0.103   succeeded

apply 完了から 8 分で associating、14 分で succeeded になりました！
TGW アタッチメントの ENI も、ちゃんとワークロードとして検知してくれるようです。
ドキュメントの「最大 60 分」よりはかなり早く、AWS ブログにある「平均 15〜20 分」に近い値でした。

展開が終わる前はどこから出ていくのか？

展開を待っている間（16:56）に、3 台の EC2 から checkip.amazonaws.com を 10 回ずつ叩いてみました。

== otake-test-rnat-tgw-spoke-a-1a (ap-northeast-1a)
  10 x 57.180.107.76 -> ap-northeast-1c
== otake-test-rnat-tgw-spoke-a-1c (ap-northeast-1c)
  10 x 57.180.107.76 -> ap-northeast-1c
== otake-test-rnat-tgw-spoke-b-1d (ap-northeast-1d)
  10 x 57.180.107.76 -> ap-northeast-1c

3 台とも 1c の EIP で出ています。1a の EC2 も 1c 経由、つまりクロス AZ で処理されていました。
通信自体は問題なく通るので「展開前は疎通しない」わけではないのですが、この間はクロス AZ のデータ転送料金がかかる点には注意が必要です！

展開後は AZ アフィニティが維持される！

展開が終わった直後（17:08）に同じことをやると、結果が変わりました。

== otake-test-rnat-tgw-spoke-a-1a (ap-northeast-1a)
  10 x 13.114.0.103 -> ap-northeast-1a
== otake-test-rnat-tgw-spoke-a-1c (ap-northeast-1c)
  10 x 57.180.107.76 -> ap-northeast-1c
== otake-test-rnat-tgw-spoke-b-1d (ap-northeast-1d)
   4 x 13.114.0.103 -> ap-northeast-1a
   6 x 57.180.107.76 -> ap-northeast-1c

1a の EC2 は 1a の EIP、1c の EC2 は 1c の EIP で出るようになりました！
Spoke から TGW に入ったトラフィックが同じ AZ の Egress アタッチメント ENI に出て、そこから同じ AZ の NAT Gateway で処理されている、というきれいな流れです。

Egress VPC に無い AZ の Spoke はどうなる？

上の結果で面白いのが Spoke B（1d）です。Egress VPC には 1d の TGW サブネットが無いので、TGW は 1a と 1c の ENI にフローを 4:6 で分散 させました。
「無い AZ からでも通信はできるが、AZ アフィニティは効かない」というわけですね。

あとから AZ を足すとどうなる？

3 段階目として Egress VPC に 1d の TGW サブネットを追加し、アタッチメントに含めました。

apply 完了              2026-09-24 17:58:34
2026-09-24 17:59:14  ap-northeast-1d    None           associating
2026-09-24 18:05:22  ap-northeast-1d    54.150.119.82  succeeded

こちらは apply 完了から 40 秒で associating、6 分 48 秒で succeeded でした！
最初の展開（8 分 / 14 分）より明らかに早いです。すでに動いている NAT Gateway に AZ を足すのと、ゼロから最初の AZ を立てるのとで所要時間が違うようです。

展開後にもう一度 checkip を叩くと、Spoke B は 10 回すべて 1d の EIP になりました。

== otake-test-rnat-tgw-spoke-b-1d (ap-northeast-1d)
  10 x 54.150.119.82 -> ap-northeast-1d

「Spoke 側に新しい AZ が増えたら、Egress VPC 側にもその AZ の TGW サブネットを足す」だけで、NAT Gateway 側は何もしなくてよいというのは運用がかなり楽ですね！

blackhole で Spoke 間を遮断しつつ egress だけ通す

TGW の App ルートテーブルに 10.0.0.0/8 → blackhole を入れているので、Spoke A から Spoke B へは通らないはずです。
Spoke A（1a）の EC2 から Spoke B の EC2 に ping と HTTP を打ちつつ、同時に checkip も叩いてみました。

--- ping 10.2.0.75
3 packets transmitted, 0 received, 100% packet loss, time 2047ms
--- http://10.2.0.75/
http failed exit=28
--- checkip
13.114.0.103

Spoke 間は落ちて、インターネットには出られています。狙いどおりですね！

blackhole を消しても Spoke 間は通らない・・・？

「じゃあ blackhole を消せば Spoke 間も通るよね」と思いきや、消しても通りませんでした。。。
理由は App ルートテーブルの中身です。Spoke の CIDR は Egress ルートテーブルにしか伝播していないので、blackhole を消すと Spoke A → Spoke B のパケットは 0.0.0.0/0 にマッチして Egress VPC に運ばれ、そのまま Regional NAT Gateway に吸い込まれます。

Regional NAT Gateway のフローログにその痕跡がばっちり残っていました。

nat-18209da7df598eb5d apne1-az4 10.1.0.58 10.2.0.75 10.1.0.58 10.2.0.75 40990 80 6 ACCEPT ingress
nat-18209da7df598eb5d apne1-az4 13.114.0.103 10.2.0.75 13.114.0.103 10.2.0.75 46534 80 6 ACCEPT egress

1 行目が Spoke A（10.1.0.58）から入ってきたパケット、2 行目が 1a の EIP に SNAT されて Spoke B へ送り出されたパケットです。Spoke B から見ると送信元がパブリック IP になっているので返せず、戻りのレコードは 0 行でした。
しかも、落ちるトラフィックに NAT Gateway のデータ処理料金がかかります。

Spoke 間を通したい場合は、Spoke のアタッチメントを App ルートテーブルにも伝播させます。
伝播された /16 は blackhole の /8 より具体的なので、blackhole は残したままでも通ります。

--- ping 10.2.0.75
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
--- http://10.2.0.75/
hello from ip-10-2-0-75.ap-northeast-1.compute.internal in otake-test-rnat-tgw-spoke-b
--- checkip
13.114.0.103

blackhole は「TGW で明示的に落として、NAT Gateway に無駄なトラフィックを流さない」ための保険と考えるのが正しそうです。

フローログとメトリクス

フローログは --resource-type RegionalNatGateway で NAT Gateway そのものを対象にできます。
Terraform でも aws_flow_log の regional_nat_gateway_id で指定できました。

resource "aws_flow_log" "rnat" {
  regional_nat_gateway_id  = aws_nat_gateway.regional.id
  traffic_type             = "ALL"
  log_destination_type     = "cloud-watch-logs"
  log_destination          = aws_cloudwatch_log_group.flowlog.arn
  iam_role_arn             = aws_iam_role.flowlog.arn
  max_aggregation_interval = 60
  log_format               = "$${resource-id} $${az-id} $${srcaddr} $${dstaddr} $${pkt-srcaddr} $${pkt-dstaddr} $${srcport} $${dstport} $${protocol} $${action} $${flow-direction} $${start}"
}

resource-id に NAT Gateway ID、az-id にどの AZ で処理されたかが入るので、AZ アフィニティの裏取りにも使えます。
instance-id や interface-id は Regional NAT Gateway では - になるので、ログ形式から外しています。

できないこと検証

ここからは「ドキュメントにできないと書いてあること」を、実際に API を叩いて確かめます。

ハマりポイント：`--dry-run` ではパラメータ検証されない

最初は --dry-run で安全に試そうとしたのですが、全部 DryRunOperation（実行していれば成功していた）が返ってきました。。。
EC2 API の dry-run は 権限チェックだけ で、パラメータの妥当性は見てくれません。
なので、できないことの検証は本当に実行して失敗させる必要がありました。成功してしまったときはその場で削除・復元するスクリプトを組んで臨みました。

Private 接続タイプの Regional NAT Gateway は作れないはず。。が、エラーにならない件について

ドキュメントには「Regional NAT gateways do not support private NAT」とあります。
では --connectivity-type private を付けて作ると、どうなるでしょうか？

❯ aws ec2 create-nat-gateway --vpc-id vpc-xxxx --availability-mode regional --connectivity-type private
{
    "NatGateway": {
        "NatGatewayId": "nat-1a8b915b346dfba16",
        "State": "pending",
        "ConnectivityType": "public",
        "AvailabilityMode": "regional",
        "AutoScalingIps": "enabled",
        "AutoProvisionZones": "enabled"
    }
}

エラーにならずに作成され、しかも ConnectivityType が public に置き換わっています！
Private 指定が黙って無視されて、Public な Regional NAT Gateway ができました。
これは当然の動きだとも思いますが、エラーが出ないとなると意図せず作成され、EIPの課金も始まってしまうと思うと少し怖いかもしれません。。。
なお、Terraform の hashicorp/aws プロバイダは connectivity_type を regional モードでは public に限定してバリデーションしてくれるので、Terraform 経由なら plan の段階で弾かれます。

Regional モードで `--subnet-id` は指定できない

An error occurred (MissingParameter) when calling the CreateNatGateway operation: SubnetId is not supported for a NAT gateway with availability mode regional.

こちらはきちんとエラーになりました。エラーコードが MissingParameter なのはちょっと不思議ですが、メッセージは明快です。

専用ルートテーブルは動かせない

専用ルートテーブルを Egress VPC のサブネットに関連付けようとすると、

An error occurred (OperationNotPermitted) when calling the AssociateRouteTable operation: Operation not permitted because this RouteTable is associated to a NAT Gateway.

逆に、自分で作ったルートテーブルを NAT Gateway に関連付けようとすると、

An error occurred (InvalidParameterValue) when calling the AssociateRouteTable operation: invalid value for parameter gateway-id: nat-18209da7df598eb5d

gateway-id はインターネットゲートウェイと仮想プライベートゲートウェイ用のパラメータなので、NAT Gateway ID は受け付けてもらえません。
専用ルートテーブルはNAT Gateway 専属で、差し替えも共有もできないと覚えておけばよさそうです。

専用ルートテーブルに置けるもの・置けないもの

ルートの宛先とターゲットをいろいろ試しました。

試したこと	結果
Egress VPC の CIDR 内のより具体的な宛先（10.0.1.0/24）→ TGW	できない
プレフィックスリスト宛先 → TGW	できる
TGW アタッチメントの ENI をターゲット	できる

VPC CIDR 内の宛先はこんなエラーでした。

An error occurred (InvalidParameterValue) when calling the CreateRoute operation: The destination CIDR block 10.0.1.0/24 is equal to or more specific than one of this VPC's CIDR blocks. This route can target only an interface or an instance.

これは通常のルートテーブルと同じ制約ですね。
一方、インターネットゲートウェイに関連付ける「ゲートウェイルートテーブルにあるプレフィックスリストを宛先にできない」という制約は、専用ルートテーブルには ありませんでした。 Spoke の CIDR が増えていく環境では、戻りルートをプレフィックスリストでまとめられるのはうれしいポイントです！
GA 当初の回避策だった TGW アタッチメント ENI のターゲット指定も、今でも通ります。

Appliance mode を有効にしても AZ アフィニティは保たれた

Appliance mode というと「フローハッシュで ENI を選ぶ」印象が強かったので、有効にすると AZ アフィニティが崩れるのでは？と思って試してみました。
結果は 3 台とも 20 回すべて自分の AZ の EIP で、変化なしでした。
ドキュメントを確認すると、今の Appliance mode は送信元と宛先の AZ を見て経路を決める仕様になっています。インターネット向けのように宛先に AZ の情報がない通信は、送信元と同じ AZ の ENI に送られると明記されていて、今回の結果もそのとおりでした。
ただし、この動きには前提があり、Appliance mode のアタッチメントに関連付けた TGW ルートテーブルでルートの伝播が有効になっている必要があります。伝播がないとフローハッシュでの振り分けに戻ります。今回は Egress 用のルートテーブルに Spoke の CIDR を伝播させていたので、条件を満たしていました。
なお、送信元 AZ に Egress 側の ENI が無い場合は、ドキュメント上はフローハッシュで AZ が選ばれます。このケースは今回は試していません。

Amazon VPC attachments in AWS Transit Gateway - Amazon VPC

Learn about how VPC attachments work in AWS Transit Gateway.

docs.aws.amazon.com

ハマりポイント

--dry-run はパラメータ検証をしない。できないことの確認は本実行が必要
Private 指定はエラーにならず Public になる。API 直叩きの IaC では特に注意
Regional NAT Gateway の ENI は VPC の ENI 一覧に出てこない。describe-nat-gateways の NetworkInterfaceId も None のまま。「ENI があるか」で状態確認する運用はできない
専用ルートテーブルに Name タグが付かない。association.gateway-id フィルタで探す
blackhole を消しただけでは Spoke 間は通らず、NAT Gateway に吸い込まれる。App ルートテーブルへの伝播が必要
専用ルートテーブルは NAT Gateway を削除すると一緒に消えるが、サービスリンクロール AWSServiceRoleForNATGateway は残る

利用料に注意！

Regional NAT Gateway は 稼働している AZ の数だけ時間料金がかかります。3 AZ に展開していれば 3 NAT Gateway-hours です。
「1 個にまとめた」のは管理単位の話で、時間料金がゾーナル 3 台分から 1 台分に減るわけではありません。
一方で、TGW 集約にすると Spoke の数が増えても NAT Gateway の時間料金は増えず、代わりに TGW のアタッチメント料金とデータ処理料金が乗ります。

AWS Transit Gateway の料金

Amazon Web Services, Inc.

Amazon VPC の料金