On-premises cannot reach a NAT Gateway through a virtual private gateway
The same design works with a Transit Gateway and does not work with a VGW. It is one sentence in the documentation, and it decides whether centralised egress for on-premises traffic is possible at all.
· Venerable Networks
Centralised egress for on-premises traffic is a reasonable ask. The data centre already has a VPN or Direct Connect into AWS, there is already a NAT Gateway in the egress VPC, and routing on-premises internet traffic through it means one egress point and one set of source addresses to allow-list.
Whether it works depends entirely on which AWS-side endpoint terminates the connection. From the NAT Gateway documentation:
You can't route traffic to a NAT gateway from Site-to-Site VPN or Direct Connect using a virtual private gateway. You can route traffic to a NAT gateway from Site-to-Site VPN or Direct Connect if you use a transit gateway instead of a virtual private gateway.
Same VPN, same NAT Gateway, same routes. Terminate on a VGW and it does not work. Terminate on a Transit Gateway and it does.
Why this is expensive to discover late
The configuration applies cleanly. You add the route on-premises, you add the route in the NAT subnet's route table pointing back at the VGW, and nothing rejects any of it. The VPN comes up, the tunnels are up, BGP is established, and traffic between on-premises and the VPC works fine.
Only the internet-bound path fails, and it fails silently — the packets are simply not forwarded to the NAT Gateway.
So the failure surfaces during testing of one specific flow, after the VPN is built and in production for everything else. And the fix is not a route change. It is moving the VPN termination from a virtual private gateway to a Transit Gateway, which means a new attachment, new route tables, a cutover window, and re-establishing BGP.
That is a materially different project from the change someone thought they were making.
The pattern this belongs to
This is a specific case of a general rule worth internalising: the AWS-side endpoint you terminate a hybrid connection on decides your ceilings, and it is expensive to revisit.
A virtual private gateway and a Transit Gateway differ on more than this:
Propagated route limits. A VGW propagates into a VPC route table, where the propagated-route limit is 100 and is not adjustable. A Transit Gateway holds its own route table with different limits.
ECMP. Aggregating multiple VPN tunnels for bandwidth requires a Transit Gateway and dynamic routing. It is not available on a VGW, and it is not available with static routing even on a TGW.
Reaching a NAT Gateway. This one.
Number of VPCs. A VGW attaches to one VPC. A Transit Gateway is a hub, so hybrid connectivity reaches every attachment without a VPN per VPC.
None of these are visible when you are choosing, because at the moment of choosing you have one VPC and one VPN and both options work identically. They become visible one at a time, months apart, each as a separate surprise.
The practical guidance: default to terminating on a Transit Gateway unless you are certain the design will stay single-VPC and simple. The attachment costs about $0.05 per hour, which is cheap relative to a termination migration, and it removes this entire class of future constraint.
If you are stuck on a VGW
Options, roughly in order of preference:
Migrate to a Transit Gateway. The real fix, and worth scoping honestly rather than deferring indefinitely.
Keep on-premises egress on-premises. Frequently the right answer. Routing data centre internet traffic through AWS to come back out adds latency, a data processing charge, and a dependency for something the data centre was already doing perfectly well. "Centralised egress" is worth it when it consolidates something genuinely fragmented, not when it relocates a working path.
Use a self-managed NAT instance. An EC2 instance with source_dest_check disabled and IP forwarding on can be routed to from a VGW, because it is just an instance. You take on patching, availability, and throughput management in exchange, and you lose the managed scaling a NAT Gateway gives you. It is a real option and it is rarely the best one.
The adjacent restriction
Also from the same page, and worth knowing at the same time because it is the same shape of constraint:
You can't route traffic to a NAT gateway through a VPC peering connection.
Peering has the same limitation as a VGW here, for the same underlying reason — neither is a transit path to another VPC's edge. There is a longer piece on the peering case, including the direction that does work and a documented Return to Sender behaviour on it that defeats an assumption about return routes.
Between them, the rule reduces to: a NAT Gateway is reachable from within its own VPC, or from a Transit Gateway. Nothing else.
Where to read more
The hybrid connectivity guide works through the VGW versus Transit Gateway decision with all of the ceilings each one sets, which is the decision this restriction is really about. For the routing behaviour of a VGW-terminated VPN, the VPN route propagation lab is a working example of propagation being opt-in on a virtual private gateway and what it looks like when nobody opted in.