How to find unused NAT gateways in AWS

Unused or misrouted NAT gateways are expensive because they keep charging even when they should have been retired. This guide helps you check whether a gateway is still needed, whether traffic should move to an endpoint, and whether retirement is actually safe.

When this guide is worth doing

NAT gateway cost shows up in Cost Explorer or VPC billing
private-subnet traffic changed and the original network path may be stale
you suspect S3 or DynamoDB traffic is still going through NAT instead of cheaper private endpoints

Step 1: Inventory NAT gateways by region

Start with the console or CLI, and do not assume waste lives only in your primary region.

for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  echo "=== $region ==="
  aws ec2 describe-nat-gateways \
    --region "$region" \
    --query 'NatGateways[].{NatGatewayId:NatGatewayId,State:State,SubnetId:SubnetId,VpcId:VpcId,Tags:Tags}' \
    --output table
done

Capture each gateway ID, VPC, subnet, environment tag, and whether it is clearly tied to production or looks like leftover infrastructure.

Step 2: Check whether the gateway is seeing meaningful traffic

Open CloudWatch metrics for the NAT gateway and review a 14-30 day window. These metrics are your best signal:

BytesInFromDestination
BytesOutToDestination
BytesInFromSource
BytesOutToSource
Error and drop metrics (if your environment emits them)

Low or intermittent traffic usually means retire-first discussion territory. High traffic does not automatically mean “keep it”; it usually means the usage pattern might be expected and worth confirming before action.

Step 3: Review route tables and endpoint coverage

In the VPC console:

Identify route tables used by private subnets that point at the NAT gateway.
Check whether S3 or DynamoDB endpoints already exist in that VPC.
Confirm those route tables are actually associated with the endpoints you expect.

Risk reminder: route edits are real production changes. Savings matter, but change safety matters more.

Step 4: Estimate the likely savings

Use a practical estimate before building full forecasts:

For unused-looking gateways, savings are roughly the hourly charge plus any remaining data processing.
If traffic is mostly S3/DynamoDB-related, estimate how much data would move off NAT once endpoint coverage is validated.

For startup teams, directional estimates are usually enough to justify a review. You can tighten precision once ownership and routing context are established.

Step 5: Decide the safest action

Common outcomes:

Retire the NAT gateway if the subnet path is no longer used.
Keep the NAT gateway and add an endpoint when traffic is real but currently routed expensively.
Hold for now when dependency context is incomplete and break risk remains unclear.

Before any routing change, document the owner, rollback plan, and expected savings.

Quick ROI example

A low-volume environment with one NAT gateway and stale data processing can still produce a meaningful annual waste line item. That is often enough to justify a focused review before any broad migration decision.

Where OpsCurb helps

OpsCurb focuses on detection and prioritization. It surfaces NAT opportunities, estimates likely savings, and flags cases where deeper validation is needed before making route changes.

Next steps:

Compare this to NAT gateway to S3 endpoint savings
Preview the Sample First-Scan Report
See Pricing if you want recurring visibility instead of one-off checks

How to Find Unused NAT Gateways in AWS