Last week I ran a Kulshan audit against an AWS account I had never seen before. The cost pack flagged a single line item: $1,317 a month in NAT Gateway data processing charges. The customer's CTO read the finding and said, "That can't be right. We don't use NAT Gateway for anything heavy."
It was right. They had three NAT Gateways in three AZs, sitting in a path nobody had mapped. Cross-AZ traffic from a misconfigured EKS workload was hitting the wrong NAT hop, racking up data processing fees plus the inter-AZ egress on top. Annualized: about $40,000.
Here is what is frustrating: NAT Gateway charges sit in EC2-Other in your bill. They do not show up under "VPC" or "Networking" in Cost Explorer's default service grouping. If you are a cost engineer scanning the bill at the service level, NAT Gateway processing is invisible until someone groups by usage type and starts asking what NatGateway-Bytes is.
What I now check first
Three things on any AWS account I touch:
- Cost Explorer grouped by usage type, filtered to
EC2-Other, sorted descending. NAT Gateway always sorts itself if it is the problem. - VPC Flow Logs for one heavy minute, grepped for cross-AZ flows. The shape of the traffic tells you whether the workload thinks it is local.
- NAT Gateway CloudWatch metrics,
BytesOutToDestination, against the workload that thinks it is in the same AZ as its dependencies.
If your bill has a $1,000-a-month-or-more EC2-Other line you cannot explain, the answer is almost always NAT. The fix is usually a Gateway VPC Endpoint for S3 or DynamoDB, or a route table that keeps intra-VPC traffic off NAT entirely. Sometimes both.
I do not write much about NAT Gateway because it is an old story. But I keep finding it. The blind spot is in the bill grouping, not in any individual engineer's work. Until Cost Explorer's default view groups NAT Gateway as its own line, this finding will keep showing up.
Back to all posts