What a NAT Gateway really costs — and how to schedule it

The NAT Gateway is the most expensive thing in most non-production VPCs that nobody looks at. It has no stop button, its charge is decoupled from traffic, and high-availability guidance quietly multiplies it per Availability Zone. Here is the arithmetic and the only mechanism that actually reduces it.

The two charges

A NAT Gateway bills on two axes in us-east-1:

• Hourly charge: $0.045 per gateway-hour, billed 24/7 the moment the gateway exists — independent of whether a single byte flows through it.
• Data processing: $0.045 per GB of data processed through the gateway.

Traffic that crosses an Availability Zone boundary also incurs standard inter-AZ data transfer (on the order of $0.01/GB per direction — TODO(verify)), but for a dormant environment the number that matters is the first one: the hourly charge you pay for nothing.

What a dormant multi-AZ setup burns

AWS's own high-availability guidance is one NAT Gateway per Availability Zone, so that a zone failure does not take out egress for the others. That is sound architecture — and it means the fixed hourly charge is paid per zone. For an environment that is only genuinely used ~45 hours of the 168-hour week, here is the hourly-charge cost of leaving the gateways up 24/7 versus scheduling them down outside working hours (us-east-1, hourly charge only):

The math is $0.045 × 720 hours for always-on, and $0.045 × ~193 hours (45 hours/week over a 30-day month) for the scheduled case, per gateway. Data processing is on top and is genuinely usage-based, so it largely disappears on its own when the environment is idle — the hourly charge is the part scheduling recovers.

Why you can't just stop it

Unlike EC2 and RDS, a NAT Gateway exposes no stop/start. The API surface is create-nat-gateway and delete-nat-gateway and nothing in between. To stop paying for an idle gateway you must delete it, and to bring the environment back you must create a new one — a new gateway with a new ID — then repair the route tables that pointed at the old one.

One detail makes this tractable: the Elastic IP. A NAT Gateway's public address is an EIP you allocate. If you keep the EIP allocation when you delete the gateway, you can re-associate the same address on the replacement, so anything downstream that allowlists your egress IP keeps working across the cycle.

Scheduling a NAT Gateway: the delete/recreate cycle

The off-window action deletes the gateway; the on-window action recreates it and re-points the route. The shape of it, in the AWS CLI:

# --- OFF window: tear down, keep the EIP allocation ---
aws ec2 delete-nat-gateway --nat-gateway-id nat-0abc123
aws ec2 wait nat-gateway-deleted --nat-gateway-id nat-0abc123
# the route to 0.0.0.0/0 via nat-0abc123 is now blackholed; leave or remove it

# --- ON window: recreate in the same subnet, reuse the same EIP ---
NAT_ID=$(aws ec2 create-nat-gateway \
  --subnet-id subnet-0public456 \
  --allocation-id eipalloc-0kept789 \
  --query 'NatGateway.NatGatewayId' --output text)
aws ec2 wait nat-gateway-available --nat-gateway-id "$NAT_ID"

# repoint the private route table at the new gateway id
aws ec2 replace-route \
  --route-table-id rtb-0private012 \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id "$NAT_ID"

That is the happy path for one gateway. A safe implementation has to handle the parts that bite:

• Provisioning latency. create-nat-gateway takes on the order of a couple of minutes to reach available. Your on-window has to fire early enough that egress is ready before the environment is in use.
• Route table discovery. Every private route table that used the old gateway needs its 0.0.0.0/0 route repointed. Enumerate them rather than hardcoding one.
• Dropped connections. Deleting a gateway drops in-flight connections. This is fine for idle non-production; do not do it to anything with active long-lived flows.
• EIP accounting. Track the allocation ID you are preserving so recreation is deterministic and you are not leaking addresses.

This orchestration — waiters, per-route-table repointing, EIP reuse, and doing it on a timezone-aware schedule — is exactly what Uptime Scheduler runs for NAT Gateways tagged for scheduling, inside your own account.

FAQ