- 最新
- 最多得票
- 最多評論
This has been resolved as of May 2026 so it's now possible to add your Transit Gateway to the Regional NAT Gateway's route table.
已回答 4 個月前
Thank you Agent for your reply!
If this is indeed a current limitation of Regional NAT Gateways, I think it would be useful to highlight this constraint within the documentation pages.
已回答 8 個月前
Based on the current capabilities of Regional NAT Gateways, what you're experiencing appears to be a limitation rather than a configuration issue. The Regional NAT Gateway's edge association route table is AWS-managed and contains a default route pointing directly to the VPC's Internet Gateway, along with local routes for the VPC CIDR. This route table cannot be modified to add custom routes for your workload VPC CIDR ranges.
For centralized IPv4 egress using Transit Gateway with multiple spoke VPCs, the traditional approach uses standard (per-AZ) NAT Gateways rather than Regional NAT Gateways. With standard NAT Gateways, you have full control over the subnet route tables where the Transit Gateway elastic network interfaces (ENIs) are located. This allows you to add the necessary routes pointing spoke VPC traffic back to the Transit Gateway as the next hop, which is essential for return traffic flow.
The typical centralized egress architecture works as follows: you add a static route in the Transit Gateway route table pointing all internet traffic to the egress VPC. Once traffic reaches the egress VPC through the Transit Gateway ENIs, it follows routes in the subnet route tables that direct traffic to the NAT gateway. Critically, for return traffic, you must add route table entries in the NAT gateway subnet pointing spoke VPC-bound traffic back to the Transit Gateway.
Since the Regional NAT Gateway's routing table is not customizable and automatically routes traffic directly to the Internet Gateway without the ability to redirect return traffic through the Transit Gateway, it appears that Regional NAT Gateways are not currently designed to support centralized egress architectures with Transit Gateway. For your use case, standard NAT Gateways deployed in the egress VPC would be the appropriate solution, as they provide the routing flexibility needed for this architecture.
Sources
Using the NAT gateway for centralized IPv4 egress - Building a Scalable and Secure Multi-VPC AWS Network Infrastructure
Introducing Amazon VPC Regional NAT Gateway | Networking & Content Delivery
Hello.
The following is a Japanese blog, which explains that if you specify the Transit Gateway ENI in the edge route table, it will be routed to the Transit Gateway.
However, as mentioned in the blog, if you specify the ENI of the Transit Gateway directly, if a failure occurs in the availability zone, routing to the Transit Gateway will not be possible, resulting in a loss of communication.
Therefore, for now, I recommend using a NAT Gateway deployed in an Availability Zone rather than a Regional NAT Gateway to aggregate outbound communications to the Internet.
https://dev.classmethod.jp/articles/regional-nat-gateway-centralized-egress/
