The AWS Bill Nobody Talks About
When engineers and finance teams sit down to review cloud costs, the usual suspects tend to dominate the conversation: EC2 instances that are too large, RDS databases running around the clock, or S3 storage that accumulated over years without a lifecycle policy in place. NAT Gateways rarely make it onto that list — and that silence is costing organisations a significant amount of money every month.
A NAT Gateway, or Network Address Translation Gateway, is the AWS-managed component that allows resources inside a private subnet — EC2 instances, containers, Lambda functions — to reach the public internet without being directly exposed to inbound traffic. It is an essential piece of infrastructure in almost every production AWS environment, which is precisely why its costs are so easy to overlook. It feels like a utility, something that simply has to be there, and utilities tend not to get scrutinised the same way discretionary spending does.
The problem is that NAT Gateways are not priced like a utility. AWS charges for them in two distinct ways: a flat hourly rate for each gateway that exists, and a per-gigabyte data processing fee for every byte that passes through it. That second charge is where organisations tend to haemorrhage money without realising it.
How the Data Processing Fee Becomes a Trap
Consider what happens in a typical AWS environment. An application running on EC2 or in a container regularly reads from or writes to an S3 bucket. Perhaps it is pulling model artefacts, reading configuration files, writing logs, or processing data as part of a pipeline. From a developer's perspective, this is unremarkable — S3 is cheap, the application is already in AWS, and everything is "in the cloud." The assumption, not unreasonably, is that data moving between two AWS services inside the same account must be inexpensive, if not free.
The reality is that if those resources are in a private subnet, traffic destined for S3 travels out through the NAT Gateway before reaching Amazon's S3 endpoints. That traffic is metered. Every gigabyte processed through the NAT Gateway incurs the per-GB charge, regardless of the fact that the data never left Amazon's network infrastructure. At any meaningful scale — data pipelines, machine learning workloads, media processing, analytics jobs — those gigabytes accumulate rapidly and the costs follow.
This is not a niche edge case. S3 is one of the most widely used AWS services, and the pattern of private-subnet compute talking to S3 is practically universal. It means that for a large proportion of AWS customers, NAT Gateway data processing fees on S3-bound traffic represent one of the largest preventable cost items on their entire bill.
The Fix Is Free and Takes Ten Minutes
What makes this situation particularly striking is how straightforward the solution is. AWS offers a feature called a VPC Endpoint — specifically, a Gateway Endpoint for S3 — that routes traffic between resources in a VPC and S3 directly through Amazon's internal network, completely bypassing the NAT Gateway. There is no additional charge for using an S3 VPC Gateway Endpoint. AWS does not charge for the endpoint itself, and traffic that flows through it does not incur the NAT Gateway data processing fee.
Enabling the endpoint involves navigating to the VPC section of the AWS console, creating a new endpoint, selecting the S3 service, and associating it with the relevant route tables. The process requires no application code changes. No restarts, no redeployments, no configuration updates to anything running in the environment. Once the endpoint and its route table entries are in place, traffic from eligible subnets automatically begins using the private path to S3.
The entire operation can genuinely be completed in under ten minutes by anyone with the appropriate IAM permissions. For organisations running significant S3 workloads, the cost reduction on the following month's bill can be immediate and substantial.
Why This Cost Goes Unnoticed for So Long
Part of the reason NAT Gateway fees persist unexamined is structural. Cloud billing dashboards are designed to surface total service costs, and NAT Gateway as a line item is easy to interpret as simply "the cost of having private subnets," which feels non-negotiable. The distinction between the fixed hourly charge and the variable data processing component is not immediately obvious in a high-level cost view.
Additionally, engineers who build the original infrastructure often do so with security and availability as the primary concerns. Private subnets, NAT Gateways — these are the textbook recommendations for production workloads, and rightly so. Cost optimisation at the routing level is rarely part of the initial design conversation. By the time the architecture is in production and the team is focused on features, the billing pattern is already established and invisible in the background noise of a growing cloud bill.
There is also an organisational element. In many companies, the engineers who understand the network architecture are not the same people reviewing the monthly bill, and the finance or DevOps teams reviewing costs may not have the context to identify which line items are avoidable versus structural. NAT Gateways sit in a blind spot between these two groups.
S3 Is the Starting Point, Not the Entire Story
The S3 VPC Gateway Endpoint is the most impactful first step, but it is worth understanding that it is one part of a broader set of optimisations available within AWS VPC networking. DynamoDB also supports a Gateway Endpoint with the same zero-cost, no-traffic-charge model, and for applications that use DynamoDB heavily from private subnets, enabling that endpoint follows the same logic.
Beyond Gateway Endpoints, AWS also offers Interface Endpoints — previously known as PrivateLink — for a wider range of services including SQS, SNS, Secrets Manager, and others. Interface Endpoints do carry an hourly charge, so the economics require evaluation based on actual traffic volumes, but for high-throughput workloads the math can still favour the endpoint over NAT Gateway data processing fees.
The broader principle is that NAT Gateways should be treated as the path of last resort for outbound traffic from private subnets, used only when no purpose-built private routing option exists — not as the default path for all inter-service communication. Auditing existing environments against that principle tends to reveal multiple opportunities for meaningful cost reduction.
A Practical Starting Point for Any Team
For any team looking to address this, the recommended starting point is straightforward. Pull the NAT Gateway costs from AWS Cost Explorer, broken down by data processing versus hourly charges. If data processing fees are significant — and in most non-trivial environments, they will be — investigate which services are generating the bulk of that traffic. In the majority of cases, S3 will be at or near the top of that list.
Enabling the S3 VPC Gateway Endpoint costs nothing, carries no risk to running workloads, and requires no coordination with application teams. It is one of the few cloud cost optimisations that is simultaneously free, low-effort, low-risk, and high-impact. The fact that it remains so underutilised is a testament to how effectively routine infrastructure costs can hide in plain sight on a cloud bill.