AWS NAT Gateway Not Routing: The Route-Table Checklist

If an AWS VPC NAT gateway is not routing, start with the route table that the failing workload's subnet actually uses. For a traditional zonal public NAT gateway, the private subnet normally needs 0.0.0.0/0 pointing to the NAT gateway, and the NAT gateway's public subnet needs 0.0.0.0/0 pointing to the VPC internet gateway. The counterintuitive part is that seeing the correct NAT route in the console does not prove your packet uses it: the subnet may be attached to another table, or a more-specific route may win before 0.0.0.0/0 is considered. Check the subnet's association first, then the routes, in that order.

A NAT gateway is one stop in a path, not a switch that makes a subnet “have internet.” A packet starts at an EC2 instance, container host, Lambda network interface, or another resource. That resource's subnet chooses a route. The route may send the packet to a NAT gateway. After that, the NAT still needs a valid path toward the destination.

That distinction is why NAT troubleshooting becomes much easier when you stop asking, “Is my NAT gateway configured?” and start asking, “Where does this exact packet go at each hop?”

The NAT gateway route-table checklist

For a traditional zonal public NAT gateway, picture the route as a chain:

private workload → private subnet route table → public NAT gateway → NAT public-subnet route table → internet gateway → internet destination

If one link in that chain is wrong, the timeout at your application can look almost identical. That is why random route editing is inefficient: you can spend an hour fixing the fourth hop when the packet never passed the first one.

Do the checks in that order. If checkpoint 2 is wrong, checkpoint 6 is irrelevant because the packet is already on the wrong road.

1. Start with the source subnet, not the NAT gateway

The fastest NAT diagnosis begins at the machine or network interface that cannot connect.

Write down four things:

• the source private IP address,
• the subnet ID,
• the VPC ID, and
• the destination IP or hostname and port you are trying to reach.

Why the destination matters will become clear later. A NAT route can work for most of the internet while one destination takes a more-specific route toward a transit gateway, VPN, peering connection, network firewall, or another target.

In the VPC console, choose Subnets, open the subnet containing the failing workload, and note its route-table information.

With the CLI:

aws ec2 describe-subnets \
  --subnet-ids subnet-0123456789abcdef0

This gives you the subnet's VPC and Availability Zone. That AZ becomes useful later when you are diagnosing a zonal NAT architecture.

Do not begin by opening the NAT gateways page and choosing the gateway whose Name tag looks familiar. Name tags are for people. Route selection runs on resource IDs and destination prefixes.

Jake learned this the boring way. He had a route table named private-prod, a subnet named private-prod-a, and another subnet that had quietly remained on the VPC's main table. Everything looked coordinated until Ethan asked one unglamorous question: “Which rtb- ID is actually attached?”

That is the question you want to answer first.

2. Find the route table the subnet actually uses

Every subnet is associated with a route table. The association can be explicit, where you deliberately attach a custom table, or implicit, where the subnet uses the VPC's main route table.

That implicit case is a classic NAT failure because nothing looks obviously broken. You edit the private table, see the correct NAT route, save it, test again, and nothing changes. The workload was never using that table.

Console route

1. Open the Amazon VPC console.
2. Choose Subnets.
3. Select the exact source subnet.
4. Open the Route table information.
5. Record the rtb-... ID.
6. Open that route table's Routes tab.

Going through the subnet is safer than starting on the Route tables page because the console is telling you which table controls this subnet rather than asking you to infer it from names.

CLI route

Look for an explicit subnet association:

aws ec2 describe-route-tables \
  --filters "Name=association.subnet-id,Values=subnet-0123456789abcdef0"

If there is no explicit association, inspect route tables for the VPC and identify the one whose association marks it as the main route table:

aws ec2 describe-route-tables \
  --filters "Name=vpc-id,Values=vpc-0123456789abcdef0"

At the end of this step, do not settle for “I think it is the private table.” You want the exact rtb-... ID.

3. Check the private subnet's NAT route

For ordinary IPv4 internet egress through a NAT gateway, the private subnet's table normally includes a default route like this:

Destination       Target
0.0.0.0/0         nat-0123456789abcdef0

The route named local for the VPC CIDR remains. You do not delete the local route to make NAT work. The local route handles matching VPC-local destinations; the default route covers destinations that do not have a more-specific match.

If the NAT route is missing, the console path is:

VPC → Route tables → select the effective private route table → Routes → Edit routes → Add route.

For the destination, enter 0.0.0.0/0. For the target, choose the intended NAT gateway.

CLI:

aws ec2 create-route \
  --route-table-id rtb-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id nat-0123456789abcdef0

If 0.0.0.0/0 already exists but points at the wrong target, replace it:

aws ec2 replace-route \
  --route-table-id rtb-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id nat-0123456789abcdef0

Now inspect the route's state. A route whose target has disappeared can become a blackhole. A blackhole route is not a slower route, a degraded route, or a route that might work later in the request. Its target is not usable for forwarding that traffic.

4. Make sure another route is not winning

A route table can contain a perfectly valid NAT default route and still send a particular destination somewhere else.

VPC routing selects the most specific matching destination. That is why the destination you wrote down at the beginning matters.

Suppose your private table contains:

10.0.0.0/16       local
10.25.0.0/16      tgw-0123456789abcdef0
172.20.8.0/24     pcx-0123456789abcdef0
0.0.0.0/0         nat-0123456789abcdef0

A connection to 10.25.8.9 does not use the NAT default route. The 10.25.0.0/16 transit-gateway route is a more-specific match.

A connection to 172.20.8.50 follows the peering route for the same reason.

A public destination with no more-specific entry can fall through to 0.0.0.0/0 and use NAT.

This gives you a strong diagnostic clue:

If almost everything works but one network, vendor, partner, repository, or service fails, do not immediately blame the NAT gateway. Compare the failing destination IP with every destination prefix in the source subnet's route table.

This also applies to routes that target network interfaces, virtual private gateways, gateway load balancer endpoints, firewall paths, prefix lists, and other routing targets.

A default route is called “default” because it catches what more-specific routes did not match. It is not a command that forces every packet through NAT.

5. Confirm the NAT gateway exists, is Available, and is the right type

Next, take the nat-... ID directly from the selected route and look it up.

In the VPC console, choose NAT gateways, select that exact ID, and check its state. For a gateway that should be carrying traffic, you want Available.

If NAT creation failed, do not keep editing the route table as though the target were healthy. Read the NAT gateway's state message first. A failed gateway is a resource-creation problem before it is a packet-routing problem.

CLI:

aws ec2 describe-nat-gateways \
  --nat-gateway-ids nat-0123456789abcdef0

Now check two separate ideas that are easy to confuse: connectivity type and availability mode.

• A public NAT gateway can provide internet egress when used with the appropriate internet-gateway path.
• A private NAT gateway is for private connectivity patterns. Routing private NAT traffic toward an internet gateway does not turn it into internet NAT.
• A zonal NAT gateway belongs to the traditional per-Availability-Zone model.
• A regional NAT gateway operates at the VPC level and uses a different route-table model.

Those are two axes, not four interchangeable labels. If you diagnose the wrong model, your checklist can look nonsensical.

6. For a zonal public NAT gateway, inspect the NAT subnet's route table

This is the second route table in the traditional public-NAT path, and it is the one people forget.

The source private subnet route sends the packet to the NAT gateway. That does not automatically give the NAT gateway a route to the public internet.

For the zonal public model, the NAT gateway is created in a public subnet. That subnet's route table needs an internet route to the VPC's internet gateway.

The basic pattern looks like this:

That answers a question that often sounds contradictory at first: “How can the VPC route to both a NAT gateway and an internet gateway?”

They are in different route tables for different subnets. Your private workload subnet sends outward traffic to NAT. The NAT's public subnet sends outward internet traffic to the IGW.

CLI for the NAT's subnet route table:

aws ec2 describe-route-tables \
  --filters "Name=association.subnet-id,Values=subnet-0NATPUBLIC123456"

If the default IGW route is missing:

aws ec2 create-route \
  --route-table-id rtb-0PUBLIC123456789 \
  --destination-cidr-block 0.0.0.0/0 \
  --gateway-id igw-0123456789abcdef0

Then confirm the internet gateway belongs to the VPC you are troubleshooting:

aws ec2 describe-internet-gateways \
  --filters "Name=attachment.vpc-id,Values=vpc-0123456789abcdef0"

If the private route is right but this second route is missing, your application sees a timeout that looks like “NAT doesn't work,” even though the packet may have reached the NAT successfully.

7. Regional NAT Gateway changes the route-table checklist

This is one of the most important corrections to older NAT troubleshooting checklists.

If your NAT gateway uses regional availability mode, do not search for “the public subnet containing the NAT gateway.” Regional NAT Gateway is not hosted in a subnet the same way a zonal NAT gateway is.

A regional NAT gateway is associated with the VPC. When it is created, it has its own route table, and that route table comes with an internet-gateway route for internet egress.

Private subnets can route traffic to the same regional NAT gateway ID across Availability Zones. In automatic mode, the NAT gateway can expand into Availability Zones where workload presence requires it.

That gives you a different mental model:

private workload → source subnet route table → regional NAT gateway → regional NAT gateway route table → destination

The CLI creation form is:

aws ec2 create-nat-gateway \
  --vpc-id vpc-0123456789abcdef0 \
  --availability-mode regional

And you can inspect the gateway with:

aws ec2 describe-nat-gateways \
  --nat-gateway-ids nat-0123456789abcdef0

Regional NAT Gateway can take up to 60 minutes to expand to a new Availability Zone after workload presence appears there. Until that expansion completes, traffic can be processed through an existing Availability Zone.

Regional mode is not the answer for every NAT use case. It does not support private NAT. If your requirement is private connectivity to another VPC or an on-premises network using private NAT behavior, the zonal NAT model is still relevant.

Ethan: “The easiest way to waste time in 2026 is to follow a 2024 subnet diagram without first checking whether the gateway is zonal or regional.”

8. A private NAT gateway will not become internet NAT because the routes look right

Public NAT and private NAT solve different problems.

A private NAT gateway uses private addressing for network address translation. You can route it toward supported private connectivity such as a transit gateway or virtual private gateway.

If you attach an internet gateway to the VPC and then route private NAT traffic toward that IGW, the internet gateway drops the traffic. That is not a route-table syntax mistake. It is the wrong NAT connectivity type for public internet access.

Check this before rebuilding subnets. It is entirely possible to produce a route diagram that looks neat while using a NAT resource whose connectivity type cannot perform the job you expect.

9. When the routes are correct, move to security groups and network ACLs

A route answers, “Where should this packet go?” It does not answer, “Is this packet allowed?”

Once you have proved the routing path, inspect the source resource's security group. For an outbound HTTPS test, the security group's outbound rules must allow the required destination and TCP port 443. For an ICMP test, outbound ICMP must be allowed.

The NAT gateway itself is stateful for the traffic it handles. It allows outbound connections and the response traffic associated with those outbound requests. You do not attach a normal EC2 security group to a NAT gateway and solve this by opening an inbound HTTPS rule on the NAT.

Network ACLs are different. A network ACL is stateless, which means you need rules that allow the traffic in both directions.

For a zonal public NAT design, inspect:

• the network ACL associated with the private workload subnet, and
• the network ACL associated with the NAT gateway's public subnet.

A restrictive NACL can allow the outgoing request and then block the returning traffic. To the application, that can look exactly like bad routing: a connection attempt waits and eventually times out.

Use Flow Logs instead of guessing

VPC Flow Logs can help distinguish a routing suspicion from rejected traffic. If you see relevant rejected traffic at a participating network interface, subnet, or VPC flow-log scope, you have useful evidence that the next step belongs in filtering rather than another NAT rebuild.

Conversely, if the expected traffic never appears where you believe it should, go back to route selection and resource identity.

That is a much better use of ten minutes than flipping every NACL rule to “allow all,” testing once, and then trying to remember what you changed.

10. Do not let one bad ping become your NAT diagnosis

A failed ping can mean several things, and “the NAT route is broken” is only one possibility.

First, do not ping the NAT gateway's own Elastic IP address or private IP address and expect it to behave like an EC2 instance. A NAT gateway passes qualifying traffic initiated from resources behind it; it is not a host you diagnose by expecting an ICMP echo reply from the NAT itself.

Second, the remote destination may not answer ICMP.

Third, your security-group or network-ACL rules may permit TCP 443 while blocking ICMP.

If your real requirement is HTTPS, test HTTPS:

curl -I https://example.com

If HTTPS succeeds while ping fails, the NAT route is already moving at least that HTTPS flow. Do not break a working TCP path while trying to make an unrelated ICMP test prettier.

NAT gateways support TCP, UDP, and ICMP. If you are using another IP protocol directly, changing the default route does not add protocol support.

IPsec is a good example of why protocol detail matters. NAT gateways do not directly support IPsec as the native protocol. NAT-Traversal, or NAT-T, encapsulates IPsec in UDP and is the relevant option when your design requires IPsec through NAT.

This is the broader lesson: always test the same protocol, destination, and port your application needs. “Internet works” and “ping works” are not synonyms.

11. The rare case: fragmentation can look like broken NAT routing

Most NAT failures are not fragmentation failures, so do not begin here. But this belongs in a complete checklist because it creates an unusually confusing symptom: small or ordinary traffic works while certain large packets or particular remote systems fail.

Diagnostic tools that send large ICMP packets can report loss through a NAT gateway. A test such as an unusually large ping payload is therefore a poor way to prove that ordinary application traffic cannot route.

There is also a TCP fragmentation edge case. If an endpoint is sending fragmented TCP packets, a NAT gateway can be the wrong component for that traffic pattern, and a NAT instance may be appropriate instead.

This is the kind of failure that should only enter your investigation after simpler evidence has ruled out the common causes:

• the right subnet,
• the right route table,
• the right NAT target,
• the right IGW path for zonal public NAT,
• working filters, and
• a supported protocol.

If a 100-byte request works and a large transfer fails, do not immediately create a second NAT gateway. Compare the behavior by packet size and protocol first.

Jake once wanted to replace an entire route table because a “network test” with a huge ping payload showed loss. Ethan's answer was less dramatic: “Test the thing your booking app actually sends.” That one sentence is useful far beyond Jake's shop.

12. If the connection dies after 350 seconds, the route probably worked

A very specific symptom deserves a very specific diagnosis.

If the connection establishes successfully, carries traffic, becomes idle, and then fails after 350 seconds or more, that is NAT gateway idle-timeout behavior rather than evidence that 0.0.0.0/0 suddenly stopped matching.

When an idle NAT connection times out, the NAT gateway sends an RST when a resource behind it tries to continue using that expired connection.

Possible application-side responses include generating traffic often enough to keep the connection active or configuring TCP keepalive below the NAT gateway idle timeout where that is appropriate for your workload.

The important troubleshooting clue is chronological:

A route-table problem normally prevents the connection from being established in the first place. An idle-timeout problem allows it to work and then removes the inactive connection state later.

If your logs say “every request fails immediately,” look at routing and filtering first.

If they say “the long-lived connection reliably breaks after several quiet minutes,” look at connection behavior.

That distinction stops a surprisingly common cycle where somebody rebuilds a NAT gateway for an application that already proved the NAT path could carry the connection.

13. If existing connections work but new ones fail, check connection capacity

Another symptom that does not fit a simple route-table failure is: some connections already work, but new connections to the same destination stop opening.

A NAT gateway tracks translated connections. For a unique destination — the combination of destination IP address, destination port, and protocol — each IPv4 address on the NAT gateway can support up to 55,000 simultaneous connections.

Adding NAT gateway IP addresses can increase the connection capacity available for that unique destination. A gateway with eight IPv4 addresses can therefore support up to 440,000 concurrent connections to one unique destination.

This is not the first thing a small application should suspect, but high fan-out clients, proxies, batch systems, container fleets, and workloads that create large numbers of short-lived or concurrent connections can reach this type of limit.

Useful NAT gateway CloudWatch metrics include connection-related and idle-timeout indicators. If route-table inspection is clean and the failure begins only under load, metrics belong in your investigation.

Possible responses include:

• reducing unnecessary connection creation,
• closing idle connections so capacity is released,
• adding additional NAT gateway addresses where supported,
• splitting clients across NAT gateways, or
• using a zonal design that distributes clients where appropriate.

Notice how different this symptom is from a missing route. If 0.0.0.0/0 were absent, the first connection and the ten-thousandth connection would not have different opinions about the route table.

14. Cross-AZ NAT can work, but do not confuse “works” with “best design”

With zonal NAT gateways, a private subnet can route to a NAT gateway in another Availability Zone. So the sentence “your workload and NAT are in different AZs” is not enough to prove why a packet does not route.

However, the normal highly available zonal design is to deploy NAT gateways per Availability Zone and route workloads toward the NAT gateway in their own zone. That avoids making one AZ's NAT path the dependency for workloads in another AZ and avoids unnecessary cross-AZ traffic patterns.

Regional NAT Gateway was introduced partly to remove much of that per-AZ operational work. A regional gateway can automatically expand with workload presence and preserve zonal affinity without requiring you to maintain a separate NAT gateway ID and public NAT subnet in each AZ.

So when somebody asks, “Should I create another NAT gateway because my instance is in us-east-1b and NAT is in us-east-1a?” split the question in two:

1. Troubleshooting question: Is the current routing path valid? Different AZs alone do not prove it is broken.
2. Architecture question: Is this the availability and cost pattern you want? That deserves a separate review after connectivity is restored.

Do not redesign the whole VPC in the middle of a five-minute outage diagnosis unless the architecture itself is the confirmed cause.

15. Check whether you are actually debugging IPv6

An IPv4 NAT route does not answer every IPv6 connectivity question.

NAT Gateway supports NAT64, which allows IPv6 workloads to communicate with IPv4 destinations when paired with DNS64 behavior from Route 53 Resolver.

If your workload is IPv6-only and the destination is IPv4-only, the troubleshooting path is not simply “add 0.0.0.0/0.” The subnet's DNS64 setting, synthesized IPv6 destination, and the route toward the NAT64 path become relevant.

If your goal is ordinary outbound-only IPv6 communication to IPv6 destinations, an egress-only internet gateway is another VPC component designed for outbound IPv6 connectivity without unsolicited inbound initiation.

This section matters because dual-stack servers can hide the protocol difference. One hostname can resolve in ways that make two apparently identical curl tests use different address families.

If IPv4 works and IPv6 fails, or IPv6 works while IPv4 fails, separate the two routing questions. Do not assume they share one default route simply because the application uses one hostname.

A useful diagnostic is to record the resolved destination addresses before changing anything. If you are troubleshooting NAT64, prove that you are actually testing the translated IPv6-to-IPv4 path.

16. A broken NAT route can still leave a working bill

The unpleasant part of a NAT outage is that “my application got no useful traffic” does not mean “this resource costs nothing.”

In US East (N. Virginia), a standard NAT gateway example uses a $0.045 per-hour NAT gateway charge and $0.045 per GB of data processed by the gateway. A public IPv4 address is billed separately at $0.005 per IP address per hour. Applicable data-transfer charges can be additional.

Use those figures carefully because architecture can change the effective bill. For example, AWS Network Firewall service-chaining has specific NAT Gateway pricing discounts, and those discount rules were expanded in February 2026 to include NAT gateways service-chained with supported secondary Network Firewall endpoints as well as primary endpoints.

Worked example: one NAT gateway, one public IPv4, 100 GB

Assume a 730-hour month in US East (N. Virginia), one standard NAT gateway, one public IPv4 address, and 100 GB processed through the gateway.

Now imagine Jake created that NAT gateway while rebuilding his shop's booking system. He accidentally left the booking subnet associated with the main route table, so the NAT handled little useful application traffic. The hourly NAT and public-IPv4 resources still exist while he troubleshoots.

That is why deleting and recreating NAT gateways should not be your first diagnostic ritual. Prove the route association first. Recreating the same NAT architecture while leaving the subnet on the wrong table produces a new NAT ID and the same old failure.

There is also a cost-saving routing pattern worth knowing after connectivity works. Supported AWS services can sometimes be reached through VPC endpoints instead of sending that traffic through NAT. For services with gateway endpoints, the route table can contain a service prefix-list route that is more specific than the general NAT default route.

That can reduce unnecessary NAT processing while keeping general internet destinations on NAT.

17. The full CLI checklist, in packet order

If you prefer not to click around the console, run the investigation in this order. Replace the example IDs with your own.

Step 1: describe the source subnet

aws ec2 describe-subnets \
  --subnet-ids subnet-0123456789abcdef0

Record the VPC ID and Availability Zone.

Step 2: find an explicit route-table association

aws ec2 describe-route-tables \
  --filters "Name=association.subnet-id,Values=subnet-0123456789abcdef0"

If there is no explicit subnet association, inspect the VPC tables and identify the main table.

Step 3: read every route in the source table

aws ec2 describe-route-tables \
  --route-table-ids rtb-0123456789abcdef0

Check four things, not one:

• Is there a NAT route for the traffic you expect?
• Is the NAT gateway ID correct?
• Is the route active rather than blackhole?
• Is there a more-specific matching destination route?

Step 4: describe the NAT gateway

aws ec2 describe-nat-gateways \
  --nat-gateway-ids nat-0123456789abcdef0

Look at state, connectivity type, VPC, subnet information for zonal gateways, availability mode, and associated addresses.

Step 5: if zonal public NAT, inspect its hosting subnet

aws ec2 describe-route-tables \
  --filters "Name=association.subnet-id,Values=subnet-0PUBLICNAT12345"

Confirm the internet default route targets the VPC internet gateway.

Step 6: prove the IGW is attached

aws ec2 describe-internet-gateways \
  --filters "Name=attachment.vpc-id,Values=vpc-0123456789abcdef0"

Step 7: describe security groups on the source resource

Use the source resource or ENI to identify its security groups, then inspect outbound rules rather than assuming the default egress rule is still present.

Step 8: inspect network ACLs

Confirm the source subnet's NACL allows both directions of the flow. For zonal public NAT, do the same for the NAT gateway's public subnet.

If all eight checks are clean, the remaining suspects are no longer “some route table somewhere.” You can investigate the destination, protocol, fragmentation, idle timeout, connection volume, DNS behavior, or remote server.

18. Match the symptom to the next check

This table is deliberately symptom-first. If your symptom is already specific, use it. You do not need to restart the investigation from route-table creation every time.

19. When every obvious NAT gateway fix has failed

If the source subnet association is correct, the expected NAT route is active, the correct NAT gateway is Available, the second-hop route is valid, security rules permit the flow, and the protocol is supported, you have reached the point where evidence matters more than configuration screenshots.

Collect a precise failure record.

1. Source private IP.
2. Source subnet ID.
3. Source Availability Zone.
4. Source route-table ID.
5. NAT gateway ID.
6. NAT connectivity type and availability mode.
7. NAT subnet and public-subnet route-table ID if this is zonal public NAT.
8. Internet gateway ID if internet access is expected.
9. Destination IP and hostname.
10. Protocol and destination port.
11. Exact UTC or local time window when the failure occurred.
12. Whether every destination fails or only one.
13. Whether existing connections keep working.
14. Relevant Flow Log entries.
15. Relevant NAT gateway CloudWatch metrics.

That turns “NAT doesn't route” into something supportable:

10.0.12.44 in subnet-abc cannot establish TCP/443 to 203.0.113.20 through nat-xyz between 10:05 and 10:10; other destinations succeed.

That is a dramatically better troubleshooting statement because it immediately raises different questions: a destination-specific route, destination-side filtering, a connection-capacity pattern, or a remote service issue.

Also check whether the remote system has unusual TCP behavior. One rare compatibility problem involves remote hosts using TCP timestamp/recycle behavior that can interfere with connections coming through NAT. If a problem occurs only with one remote server while ordinary internet destinations work, do not keep changing the VPC default route without investigating the remote endpoint.

Support cannot make an unavailable third-party destination answer you, and it cannot make an unsupported protocol become supported by changing a route-table entry. The more precisely you define the failed flow, the faster you separate AWS routing from the other side of the connection.

AWS NAT gateway route-table FAQ

Why is my AWS NAT gateway not routing internet traffic?

Start with the subnet containing the failing resource. Find the route table that subnet actually uses, confirm the destination selects a route to the intended NAT gateway, and confirm the NAT gateway is Available. For a zonal public NAT gateway, also confirm the NAT's public subnet routes internet traffic to an internet gateway attached to the same VPC.

What route should a private subnet use for an AWS NAT gateway?

For ordinary IPv4 internet egress, the private subnet normally uses 0.0.0.0/0 with the NAT gateway as the target. A more-specific route can still override that default for matching destinations.

Why does 0.0.0.0/0 point to NAT but my EC2 instance still has no internet?

The subnet may use another route table, the NAT gateway may be unavailable or the wrong connectivity type, a more-specific route may win, the zonal public NAT subnet may lack its IGW route, or security-group and network-ACL rules may block the flow.

How do I know which route table my private subnet actually uses?

Open the subnet in the VPC console and inspect its route-table information. With the CLI, search route-table associations for the subnet ID. If there is no explicit association, the subnet uses the VPC's main route table.

Why does my NAT gateway route say blackhole?

A blackhole route means its target is not usable. This commonly appears after the target resource has been deleted. Replace the route with the intended active target or remove the stale route if it is no longer required.

Does a public NAT gateway need an internet gateway?

For zonal public NAT internet access, the NAT gateway's public subnet routes internet traffic to an internet gateway attached to the VPC. Regional NAT Gateway uses its own route-table model and automatically starts with an internet-gateway route for internet egress.

Can a more-specific AWS VPC route bypass my NAT gateway?

Yes. VPC route selection uses the most specific matching destination. A route for a narrower CIDR or matching prefix list can be selected instead of the general 0.0.0.0/0 NAT route.

Can I ping an AWS NAT gateway to check whether it works?

Do not use the NAT gateway's own Elastic IP or private IP as a ping target and expect an ICMP reply. Test a permitted destination through the NAT path from a resource behind the gateway, preferably using the same protocol your application requires.

Why does ping fail through NAT while HTTPS still works?

The remote system may not answer ICMP, or your security rules may treat ICMP differently from TCP 443. If HTTPS succeeds through the expected path, a failed ping alone does not prove the NAT route is broken.

Can a private NAT gateway access the public internet through an IGW?

No. Private NAT is designed for private connectivity. Routing traffic from a private NAT gateway toward an internet gateway does not convert it into public internet NAT; the internet gateway drops that traffic.

Does Regional NAT Gateway need a public subnet?

No. Regional NAT Gateway operates at the VPC level instead of being hosted in a public subnet. It has its own route table and can expand across Availability Zones based on workload presence.

Why does my NAT gateway connection drop after 350 seconds?

A NAT gateway times out an idle connection after 350 seconds. If the connection originally worked and only fails after remaining idle, investigate keepalive and application connection behavior instead of rebuilding the route table.

Why do existing NAT connections work but new connections fail?

Under heavy connection volume, you may be approaching NAT connection capacity for a unique destination. Check CloudWatch metrics, idle connections, client connection behavior, and whether adding NAT gateway IP addresses or distributing clients is appropriate.

Does an AWS NAT gateway support IPsec?

NAT gateways do not directly support native IPsec traffic. NAT-Traversal, or NAT-T, encapsulates IPsec in UDP and is the relevant approach when your design needs IPsec to traverse NAT.

Why does one private subnet use NAT successfully while another subnet fails?

Compare their effective route tables, default routes, more-specific routes, and network ACLs. One subnet may be explicitly associated with the NAT route table while the failing subnet is still using the VPC's main table.

What should I collect before opening AWS Support for a NAT routing issue?

Collect the source IP, subnet ID, route-table ID, VPC ID, NAT gateway ID, NAT type and availability mode, destination IP, protocol, port, failure time, relevant IGW and NAT-subnet details, VPC Flow Log records, CloudWatch NAT metrics, and whether the failure affects all destinations or only one.

The five-minute NAT route check I would use first

If I had only five minutes before somebody asked for an update, I would not recreate the NAT gateway.

I would take the private IP of the failing workload, identify its subnet, and open that subnet's actual route table. I would compare the destination IP against every route, not just stare at 0.0.0.0/0. I would follow the chosen route to the exact NAT gateway ID and check that it is Available and that its connectivity type and availability mode match the design.

For a zonal public NAT gateway, I would then open the NAT gateway's public subnet and prove that subnet has its own default route to an internet gateway attached to the same VPC.

If that packet path is intact, I would stop modifying routes and move to security-group egress, network ACLs, Flow Logs, protocol behavior, and destination-specific evidence.

If the connection already works but later dies, I would check the 350-second idle-timeout pattern. If existing connections survive while new ones fail during load, I would check connection capacity. If only odd large packets fail, I would investigate fragmentation. If the gateway is private, I would stop expecting an internet gateway to turn it into public NAT. If it is regional, I would stop searching for a NAT hosting subnet that the regional model does not use.

That order matters because each successful checkpoint eliminates an entire family of guesses.

If your setup has a failure that falls outside this decision path, save the exact source IP, destination IP, subnet ID, route-table ID, NAT gateway ID, protocol, port, and failure time before changing anything else. Those details make the next investigation far more useful than another screenshot saying “NAT gateway: Available.” I hope the next time this happens, the problem turns out to be the boring one: one subnet attached to the wrong route table and five minutes to fix it.

Revision note. Written October 3, 2026, with the Regional NAT Gateway included. When the NAT page says Available and nothing gets out, the answer is nearly always one route table away; start with the subnet's real association.