A VPC endpoint lets resources in a private subnet reach AWS services without sending the traffic through a NAT gateway or the public internet. That matters for cost because a NAT gateway bills both an hourly charge and a per GB data processing charge on all traffic it handles, so a service that pulls heavily from S3 through NAT pays the per GB rate on every byte. Gateway endpoints for S3 and DynamoDB carry no hourly and no data charge and remove that traffic from the NAT path, making them a near automatic win. Interface endpoints, built on AWS PrivateLink, carry their own hourly and per GB charge, so they pay off only where they displace enough NAT or transfer cost to clear that floor.
Here is how the charges work, the two endpoint types, and how to tell which calls are worth moving.
Why does a NAT gateway cost so much?
A NAT gateway exists so private resources can reach out without a public address. It charges in two ways: a flat hourly rate for the gateway itself, and a data processing rate on every GB that flows through it in either direction. The hourly rate is modest, but the data processing rate is where the cost accumulates, because routine internal traffic to S3, DynamoDB, and other AWS services often runs through the same NAT path as genuine internet egress. A data heavy job reading terabytes from S3 across NAT pays the per GB processing charge on all of it, even though the data never leaves the AWS network. That charge is invisible until you read the line item, which is why NAT data processing is one of the quiet budget eaters on AWS.
Gateway or interface endpoint?
| Dimension | Gateway endpoint | Interface endpoint (PrivateLink) |
|---|---|---|
| Services | S3 and DynamoDB only | Most other AWS services and your own services |
| Mechanism | Route table entry | Elastic network interface in each subnet |
| Hourly charge | None | Per endpoint, per availability zone |
| Data charge | None | Per GB processed |
| Cost verdict | Enable by default | Justify with traffic volume |
The asymmetry is the whole point. Gateway endpoints are free to run, so any meaningful S3 or DynamoDB traffic from private subnets should use them rather than NAT. Interface endpoints have a real running cost that multiplies across availability zones, so they earn their place only when the NAT data processing or cross zone transfer they remove exceeds their hourly and per GB charge. Charges are indicative; verify against current AWS pricing for your region.
How do you decide which calls to move?
Treat it as a simple comparison per service. First, enable the gateway endpoints for S3 and DynamoDB everywhere, since there is no running cost to weigh and they immediately pull that traffic off NAT. Then look at the NAT data processing line and identify which services drive it. For each high volume service that supports an interface endpoint, estimate the monthly GB and compare the interface endpoint cost, the hourly rate times the number of availability zones plus the per GB processing, against the NAT data processing the endpoint would remove. Where the endpoint is clearly cheaper, deploy it; where traffic is light, leave it on NAT. The aim is not to put an interface endpoint on everything, which can cost more than it saves, but to move the few high volume services that justify it.
A worked example
A data platform ran analytics jobs in private subnets that pulled large volumes from S3 through a NAT gateway, and the NAT data processing line had become one of the largest items on the networking bill. Enabling a gateway endpoint for S3, which costs nothing to run, removed that traffic from the NAT path and cut the NAT data processing charge sharply within a single billing cycle. The team then added interface endpoints only for two high volume services whose traffic clearly exceeded the endpoint running cost, and left the lighter services on NAT. Total networking spend on the account fell by roughly a third, with the largest single saving coming from the free S3 gateway endpoint. Figures are verified against billing data and anonymised.
Frequently asked questions
Do VPC endpoints save money on AWS?
What is the difference between gateway and interface endpoints?
When is a VPC endpoint not worth it?
Turn the network bill into a lever
We help teams map NAT data processing and transfer charges to the services that drive them, then place endpoints where they actually pay off, as an independent advisory that takes zero provider commissions and answers only to you. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on a Fixed Fee or a no risk Gainshare basis. Download the cloud cost optimization playbook, read the deeper AWS cost optimization guide, and pair this with network architecture choices that cut the bill. For monthly buyer side analysis, subscribe to The Cloud Spend Navigator.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.