Delete idle VPC endpoints

A VPC endpoint is a piece of networking plumbing that lets cloud resources talk to AWS services privately. The kind this finding is about — interface endpoints — carry a small fixed charge of roughly $0.01 per hour for each Availability Zone they're set up in, plus a per-gigabyte charge for any traffic. The fixed part bills every hour regardless of whether any traffic flows. An endpoint set up across three zones is about $22 a month before a single byte moves through it.

This finding flags interface endpoints that are sitting idle — almost no traffic over the last month — but still drawing that fixed monthly charge. In practice these are leftovers from a project or proof-of-concept that never went live, copies created automatically in every account by a shared template, or endpoints set up in more zones than the workload ever needed. Each one is a small recurring charge on no business activity. Across a large estate with a landing-zone template that provisions a dozen of them per account, the number lands in the low thousands a month with nothing to show for it.

One important nuance for finance: there is a closely related, very common piece of advice that says to create VPC endpoints to cut NAT Gateway data-processing cost. That advice is sound when the endpoint carries real traffic. This finding is the opposite case — endpoints that carry no traffic and therefore only cost money. The right framing is that an idle interface endpoint is a governance and ownership signal: it means networking was provisioned and then forgotten, and the longer it sits, the harder it is to attribute or charge back to a business unit.

Sam is the finance partner embedded with the platform team at a fintech. At the monthly cost review, the networking line has crept up again and Sam asks one question that's now standard on the agenda: "How many interface VPC endpoints are idle — drawing the per-zone charge with no traffic — and what's that costing us a month?" The dashboard says ~$2,400 across the sandbox and shared-service accounts. Small in absolute terms, but it's been roughly that every month for half a year, so the cumulative is well into five figures.

The conversation isn't technical. Sam doesn't ask about AZs or DNS or PrivateLink. She asks three things: where did these come from, who owns them, and is anything actually using them. The platform lead is candid — they nearly all came from the standard account template, which provisions a fixed set of endpoints into every account whether the workloads land there or not. That single answer reframes the whole category: this isn't a cleanup problem, it's a default-template problem. Engineering commits to two things — a one-off cleanup of the idle endpoints, and a change to the template so sandbox accounts don't get the full set by default.

Sam also flags the trap she's learned to watch for: there's standing advice to add endpoints to cut NAT Gateway cost, so she's careful not to ask anyone to "delete all the endpoints." The target is specifically the interface endpoints with no traffic. Two months later the line is down to a residual few hundred dollars of endpoints that genuinely carry traffic, and the template fix means it stays there. The dollar figure was a leading indicator of a defaults problem; the cleanup itself was almost incidental.

The per-resource impact is small and the aggregate is material. A typical estate carries somewhere from a few hundred to a few thousand dollars a month in idle interface endpoints — usually well under 1% of total cloud spend. Not enough to move a quarterly number on its own, but enough that it lands in "unexplained networking variance" every month, and finance ends up chasing it across teams instead of focusing on the bigger commitments.

The more important point is the cause. Unlike most waste, which comes from individual engineers, this category is usually manufactured by a single shared template that provisions the same endpoints into every account by default. That makes it both easy to fix at the root and easy to let grow unnoticed — every new account adds to the line automatically. On the monthly report, watch the count of idle endpoints alongside the dollar amount; if the count grows in lockstep with new account creation, the template is the lever, not the teams.

There's a nuance finance specifically needs to hold. Interface endpoints are also a legitimate cost-saving tool — adding one can cut NAT Gateway data-processing charges substantially when real traffic flows. So this is not a "fewer endpoints is always better" story. The defensible question at the review is narrow: "which interface endpoints have no traffic over 30 days?" — never "why do we have endpoints at all?" Conflating the two undoes a real optimisation while chasing a small one.

Finally, it's a chargeback and leading-indicator signal. Template-provisioned endpoints with no owner are dollars that can't cleanly attribute to a business unit, which weakens the chargeback model. And sustained growth in the idle count usually means account vending is outrunning template hygiene — the same drift that predicts other default-driven waste (oversized baseline infrastructure, unused log groups) trending up six months later. Watch it as a signal, not a target.

Some pieces of cloud networking bill a small fixed fee per hour just for existing, whether or not anything uses them. Interface VPC endpoints are one of those — and they multiply quietly when a standard template copies them into every account. At scale, the result is a recurring drag on the cloud bill from connectivity the business provisioned and then forgot.

This is a hygiene and accountability issue rather than a big-ticket cost. Each flagged endpoint is money spent on something with no clear owner and no active value. Cleaning them up is low-risk, but the more valuable outcome is the discipline it establishes: networking that is created by a template still needs an owner, a purpose, and a review date — not just a default.

At one company, the quarterly cloud review used to carry a slide line that read "$2,400/month of idle VPC endpoints." Small number, but it sat there every quarter, never shrinking, occasionally growing as the account count grew. The exec sponsor stopped asking about the dollars and started asking about the shape: "Why do brand-new sandbox accounts come pre-loaded with networking nobody asked for? Who owns the template that does that?"

Within two quarters the slide changed. The headline was no longer the dollar figure; it was "account templates now provision connectivity on demand, not by default, and every endpoint has a named owner." The idle spend dropped to a residual of endpoints that genuinely carry traffic, and the line stopped appearing as an action item. The exec hadn't asked engineering to chase a few thousand dollars — she'd asked them to fix the default that the dollars were exposing.

That's the right outcome state. "Zero endpoints" is the wrong goal — endpoints that carry traffic earn their keep and often save money. "No idle endpoints, and templates that don't create them by default" is the right one. The cost line becomes a confidence signal instead of a recurring chore.

The dollar amount here is usually small. It's tracked because of what its size and trend say about the discipline underneath — specifically about defaults. A small, flat number means account templates are provisioning connectivity sensibly and someone owns the result. A growing number, climbing with every new account, means the inverse: a default is creating cost automatically and no one is closing the loop. That same pattern almost certainly applies to other things the template provisions by default.

There's a second-order point worth holding. The right fix is not "have fewer endpoints" — endpoints that carry traffic save money and improve security. The fix is removing the idle ones and changing the default that creates them. So this category sits at the intersection of cost discipline and platform-defaults governance. The leadership question is about the template, not the dollars.