You cannot borrow a peered VPC's NAT Gateway, but the reverse works

Centralised egress is a good instinct. One VPC holds the NAT Gateways, every other VPC routes its internet-bound traffic there, and you pay for NAT once instead of per-VPC.

It works over a Transit Gateway. It does not work over VPC peering, and the reason is a restriction with a name: edge-to-edge routing.

From the AWS troubleshooting guidance for peering:

VPC peering doesn't support edge-to-edge routing through gateways or private connections. Resources in a peered VPC can't use the internet gateway, NAT device, VPN connection, or AWS Direct Connect link of the other VPC to access external networks.

And specifically, from the NAT Gateway documentation:

You can't route traffic to a NAT gateway through a VPC peering connection.

A peering connection carries traffic between two VPCs' address ranges. It is not a transit path to whatever those VPCs are attached to. The same restriction covers the peer's internet gateway, its VPN connections, and its Direct Connect links — peering gives you the VPC, not the VPC's edge.

The direction that does work#

Here is the part that is easy to get backwards, and AWS spells it out with two diagrams' worth of ASCII in the same document:

Not supported:

Client → Peering → NAT → Internet

Supported:

Client → NAT → Peering → Destination

So a workload behind a NAT Gateway can reach a peered VPC through that NAT Gateway. What it cannot do is enter a VPC through a peering and then leave through that VPC's NAT Gateway.

The asymmetry makes sense once you see what each case asks for. The supported case uses the peering as what it is — a path between two VPCs. The unsupported case asks the peering to be a transit hop toward the internet.

Return to Sender#

There is a genuinely surprising behaviour documented on the supported path, and it is worth knowing because it defeats an assumption about return routes:

Traffic from a NAT gateway through VPC peering to destinations in peered VPCs supports "Return to Sender" behavior — return traffic is automatically routed back to the originating NAT gateway even without return routes configured in the destination VPC. This behavior is specific to NAT gateways and does not apply to standard EC2 instances.

Read that carefully. The destination VPC does not need a route back to the NAT Gateway's address range, and traffic returns anyway. That is a deliberate exception to how everything else in a VPC works, and it applies only to NAT Gateways.

The documentation then adds the consequence, which is the reason to care: to prevent this, use NACLs to block the return traffic. In other words, if your security model assumed that omitting a return route was itself a control — a fairly common assumption in one-way integration designs — that assumption does not hold for NAT Gateway traffic. The absence of a route is not the absence of a path.

What to do instead for centralised egress#

Transit Gateway. The documented answer. Traffic from a spoke reaches the egress VPC over the Transit Gateway, then leaves through the NAT Gateway there. This is also the only way to reach a NAT Gateway from a VPN or Direct Connect connection — from the NAT Gateway documentation, that works with a Transit Gateway and does not work with a virtual private gateway.

A NAT Gateway per VPC. Less elegant, and sometimes cheaper than it looks. Centralised egress adds Transit Gateway attachment hours and data processing charges on top of the NAT Gateway charges, so the crossover point is further out than people expect. Work the arithmetic for your traffic volume rather than assuming centralisation saves money.

Neither, for AWS service traffic. A large share of what people route through NAT Gateways is traffic to S3, DynamoDB, and other AWS services. Gateway endpoints for S3 and DynamoDB are free and remove that traffic from the NAT Gateway entirely, which frequently changes the whole calculation.

The check#

If you are auditing for this, look for peering connections as the target of a default route:

aws ec2 describe-route-tables \
  --query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0` && VpcPeeringConnectionId!=null]' \
  --output json

Anything that comes back is an attempt at edge-to-edge routing, and whatever it was meant to reach is not reachable that way.

The wider point is that peering is deliberately minimal. It is not a router and it is not a transit service — it connects two address ranges and nothing else. Most peering surprises come from expecting transitive or edge behaviour from something that was designed to have neither, which is also why peering has no reverse path forwarding and why two VPCs sharing a CIDR behind the same hub is unfixable by routing.

The NAT Gateway guide works through the centralised egress tradeoff with the actual numbers.