Case Study: The $198K/Year AWS Bill Hiding Inside "EC2-Other"

A client running a large multi-region AWS estate asked a familiar question: why does "EC2-Other" keep going up? It was now one of the largest items on the bill and climbing month over month. But "EC2-Other" tells you almost nothing. It is a catch-all bucket where AWS groups NAT Gateways, EBS volumes, data transfer, and a dozen other charges that have nothing to do with the instances themselves.

This is the most common blind spot we see in cost reviews. Teams scrutinize their EC2 instance fleet, negotiate Savings Plans, right-size diligently, and then accept "EC2-Other" as unavoidable overhead because nobody can see inside it. In this case, the unexplained portion had quietly grown into six figures a year.

The first move is always the same: break the category down by usage type. Within minutes, one component dominated: NAT Gateway data processing, running at roughly $15,700 per month across two regions, and rising.

A NAT Gateway charges two ways: an hourly fee, and a per-gigabyte fee for every byte it processes. The hourly fees were trivial. The data processing charge was the entire problem, which meant something was pushing enormous volumes of traffic through it. The question was what, and to where.

We turned on VPC Flow Logs for the egress VPCs and analyzed the destinations. The result was unambiguous: 93% of NAT traffic in one region and 99% in the other was going to S3, in the same region. The application VPCs had no S3 Gateway endpoint, so every byte destined for S3 was routed out through the transit network and the NAT Gateway, paying the per-gigabyte toll to reach a service sitting next door.

Cross-referencing traffic patterns against the destination buckets identified the source: the database cluster's daily backups. Each night, the cluster uploaded a full backup of a multi-terabyte database, around 6 TB every single day, and every gigabyte took the most expensive route available. That single backup job was generating roughly $300 a day in NAT processing charges. The billing data reconciled against the flow logs almost to the dollar.

The remedy is almost anticlimactic. Adding an S3 Gateway endpoint to each application VPC inserts a route table entry that sends S3-bound traffic directly to S3, bypassing the NAT Gateway entirely. No application changes, no DNS changes, no downtime. Traffic shifts to the new route as soon as the endpoint is in place.

The only diligence required is a pre-flight check of bucket policies: any policy that restricts access by source IP needs reviewing, because traffic arriving via a gateway endpoint presents a private IP rather than the NAT's public one. We audited those policies before rollout so the cutover carried no surprises.

That one change eliminated roughly $14,800 per month in NAT data processing charges, about $178,000 a year, for the cost of a route table entry.

While verifying the backup buckets, something else looked wrong. The buckets held over 90 TB each across two regions, and the team's understanding was that backups "moved to cheaper storage and then aged out." The lifecycle configuration told a different story.

The policy transitioned objects to S3 Intelligent-Tiering on day zero and deleted them on day 30. On paper, that sounds like cost-optimized hygiene. In practice, it is a null operation, because Intelligent-Tiering keeps every object in its frequent-access tier, billed at rates equivalent to S3 Standard, for the first 30 days before it will consider moving anything to a cheaper tier.

Tier down on day 30. Delete on day 30. Nothing ever tiered. Ninety-plus terabytes of backups, restored on only the rarest occasions, sat at premium storage rates for their entire lifetime, in both regions, for as long as the policy had existed. The "savings" configuration everyone believed in had never saved a cent.

The fix had one trap worth knowing: archive tiers carry minimum storage durations (Glacier classes bill a 90-day minimum), so pointing a 30-day-retention policy at Glacier saves nothing over keeping the data in a cold instant-access class. Alternatively, the retention window can be extended to match the minimum, tripling the safety margin at the same cost. We modeled both and let the client choose. Either path recovers roughly $2,500 per month.

Total recovered: approximately $16,500 per month, or about $198,000 a year, from two configuration changes. No instances resized, no services migrated, no code shipped, no downtime taken. The diagnosis took a single afternoon with Cost Explorer, VPC Flow Logs, and a willingness to keep asking "why" until the bytes had an explanation.

There is a further lever still on the table: switching the database from daily full backups to incrementals would cut the backup volume by 80–90%, worth roughly another $3,000 a month. That requires coordination with the data team, so it was logged as a follow-up rather than bundled into the quick wins. The pattern matters: capture the zero-risk savings immediately, queue the deeper changes properly.

Nothing here was exotic. Both issues are textbook AWS behavior, fully documented, and invisible in exactly the way that matters: each looked correct from the inside. The backups ran flawlessly every night, and the monitoring was green. The lifecycle policy existed and looked responsible, and the console showed it active. Every individual component was "working." Only the bill knew the truth, and the bill filed it under a category designed to be ignored.

This is the recurring lesson from cost work: the most expensive problems are rarely failures. They are systems doing precisely what they were configured to do, where the configuration quietly disagrees with what everyone believes it does. Finding them takes no special tooling. Cost Explorer and Flow Logs are available in every account. It takes someone whose job is to be suspicious of the bill.

If your "EC2-Other" line keeps growing and nobody can say why, the answer is sitting in your usage-type breakdown right now. Upload your most recent AWS bill and we will trace it: where the money is actually going, which charges are routing mistakes, and what your equivalent of the free route table entry is worth.