Fixer

VPC Endpoints Costing You $90/Year Each? Find and Delete Idle Ones

Idle AWS VPC endpoints cost $90/year each. Find and delete unused VPC Interface Endpoints and Gateway Load Balancer Endpoints across all your accounts.

Warp pipes
_– the technical term for the green tubes/tunnels in the Super Mario world.
_

I recently saw the Super Mario Brothers movie with my family. We loved it! It was really fun seeing the iconic characters take on a whole new depth. At the beginning, Mario and Luigi’s adventures start when they’re sucked into a warp pipe. The warp pipe, one of the green teleportation tubes that connect different worlds, separates the intrepid brothers and kicks off their journeys in the Mushroom Kingdom and beyond.

A still image from the mario games, showing the warp pipes. We are using the warp pipes as a metaphor for VPCs which can connect bits of of virtual infrastructure

Welcome to the warp zone

If we think about AWS like the Mario Brothers universe, Virtual Private Clouds (VPCs) would be the warp pipes and their endpoints would be the ends of the pipe, where you pop out or drop in. VPCs and their endpoints are an important part of the behind-the-scenes infrastructure that keeps bits and bytes flowing to the right places. They also, however, come with the potential to overspend. When we don’t keep track of idle endpoints – the ones we no longer use – the costs add up. 

Let’s take a closer look at why we end up with idle VPC endpoints, what it’s costing us, and how to save thousands of dollars every year by getting rid of them.

Table of Contents

  1. The warp pipes of AWS: A quick overview of Amazon Virtual Public Clouds (VPCs)
  2. 3 reasons why idle VPC endpoints pile up
  3. How much are idle VPC endpoints costing you?
  4. How to eliminate idle VPC endpoints
  5. So long, human error: Eliminate idle VPC endpoints automatically with CloudFix

The warp pipes of AWS: A quick overview of Amazon Virtual Public Clouds (VPCs)

Let’s start with the basics. With Amazon VPC, you can define logically isolated virtual networks that contain your AWS infrastructure. Much like configuring routers, VPCs let you build and configure networks to your exact needs. This includes specifying IP address ranges, creating subnets, and configuring routing tables and network gateways. VPCs can span AWS availability zones within a region. With AWS PrivateLink, you can also connect directly to particular AWS services, on-prem networks via a VPN connection, or to other VPCs via a private IP address.

A VPC can contain EC2 instances, RDS instances, Lambda functions, and more. In addition, VPC endpoints allow code running within the VPC to connect to the APIs for particular AWS services without using public IP addresses. There are three types of VPC endpoints:

  1. Gateway endpoints. Gateway endpoints allow the VPC to extend to include S3 and DynamoDB. They allow private traffic between these services and your VPC without any other infrastructure, keeping that traffic off of the public internet. There are no charges associated with gateway endpoints, so we can set them aside for the purposes of this conversation.
  2. Gateway Load Balancer endpoints. Gateway Load Balancers route traffic within the VPC to/from virtual appliances. Gateway Load Balancer endpoints (GWLBEs) connect Gateway Load Balancers to the rest of the VPC. In AWS’s own words, GWLBEs “connect Internet Gateways, VPCs, and other network resources over a private connection. Your traffic flows over the AWS network, and data is never exposed to the internet.” These endpoint types incur an hourly charge regardless of usage, so we will be looking at these carefully. 
  3. Interface endpoints. Interface VPC endpoints connect to services powered by AWS PrivateLink. For example, with Interface endpoints, you can access Amazon S3 directly from a VPC, without your traffic going over the public internet. Other powerful use cases include accessing RDS, Secrets Manager, or Lambda from a VPC. (You can see the full list of services that support Interface endpoints here.) Similar to GWLBEs, Interface endpoints incur an hourly charge, so we have to pay attention to their usage.

While each of these types of VPC endpoints supports a unique type of connection, they have one thing in common: it’s easy to rack up too many of them and spend too much on endpoints that you don’t need.

3 reasons why idle VPC endpoints pile up

There are a few different ways that we end up with idle endpoints:

  1. Incomplete configurations. During the development and testing process, it’s simple to create new resources. In fact, you often see infrastructure labeled test-12-i-hope-this-works, test-13-delete-this, test-14-almost-got-it, etc. Ideally, once the configuration stabilizes, it’s captured in a CloudFormation template or some other IAC solution. IAC creates resources as a logical group, and when the service isn’t needed, it deactivates and deletes all of the associated resources at once. However, during testing, when you are creating resources on an ad-hoc basis, there is no mechanism to remind you to delete the associated resources. As a result, we end up with idle VPC endpoints.
  2. Retired services. Services become deprecated over time. While we’re usually good at remembering to delete the more expensive resources associated with those services, like EC2 instances and RDS databases, we often forget the bits and pieces. (This happens with Elastic Load Balancers and Elastic IP addresses, too.) It’s just like in Mario Brothers. We make sure to get all of the Super Mario mushrooms, but if we’re in a hurry, we skip some of the Super Mario coins. If only Mario had access to an automated tool like CloudFix… we’d be 1up-ing all day long. 
  3. Orphaned resources / scaling down. It’s possible to delete VPCs and security groups without deleting the endpoints. This results in orphaned VPC endpoints that no longer serve a purpose.

It often happens during the scaling down process, when some of the infrastructure such as VPC endpoints remain. We don’t need these endpoints, so there’s no point in maintaining and paying for them.

All of these scenarios are becoming more common. As app deployments grow increasingly complex, the use of VPCs grows too. The result: more endpoints in general, more idle endpoints, and more opportunity to overspend. 

How much are idle VPC endpoints costing you?

Why does it matter if we have idle VPC endpoints floating around? Because we’re paying for something that we don’t need, and that’s never good business.

Let’s look at some numbers. GWLBEs and Interface endpoints are charged at a fixed hourly rate, as well as cost per petabyte. Here’s the current pricing, as of May 2023 in us-east-1:

Category

Element

Cost

Interface Endpoint

Fixed hourly

$0.01/hr

Interface Endpoint

First 1 PB

$0.01/GiB

Interface Endpoint

Next 4 PB

$0.006/GiB

Interface Endpoint

Anything over 5 PB

$0.004/GiB

Gateway Load Balancer Endpoint

Fixed hourly

$0.01/hr

Gateway Load Balancer Endpoint

Data charges

$0.0035/GiB

This doesn’t look like much at first glance, but over time and at scale, it adds up. Your idle VPC endpoints don’t incur the data charges, but you are still paying the hourly charge. That amounts to approximately $90/year, per endpoint. That sounds like crumbs… but enough crumbs can create a serious mess (fellow parents will feel me here deeply.) 

Think about it this way: if you got rid of 30 idle VPC endpoints every year, that’s $2,700 back in your pocket. That’s almost three grand that you could reinvest into something far more valuable than idle endpoints, from additional AWS services to a retro arcade machine for the office (I vote for Teenage Mutant Ninja Turtles.)

How much can your organization save by eliminating idle VPC endpoints? We typically find that between 5-10% of a company’s average AWS spend comes from VPCs. Of that, about 5% (of the 5-10%) can be attributed to idle VPC endpoints. For 1M of annual AWS spend, that’s $5K annually – more than enough for the Ninja Turtles.

How to eliminate idle VPC endpoints

So, it’s clear how we end up with idle VPC endpoints and how much we’re paying for them (too much!) Now let’s see how to get rid of them.

Remember from the pricing table that there is both a fixed hourly charge and a per-GiB data charge. An endpoint that isn’t moving any data still pays the hourly charge, which is exactly why idle endpoints are easy to miss: they cost a little, all the time, and nothing breaks.

Finding them is read-only: CloudFix uses your cost and usage data to find Interface and Gateway Load Balancer endpoints that have gone unused for an extended period, and it skips endpoints that are in the middle of a transition and not safe to change. Each idle endpoint appears in your Recommendations, and nothing happens until you approve it. Once approved, the fix runs as an AWS Systems Manager Automation runbook in your own account and deletes the idle endpoint. Every execution is logged. Congratulations: you’re no longer paying for idle VPC endpoints.

So long, human error: Eliminate idle VPC endpoints automatically with CloudFix

You could hunt these down by hand every month or so, but (a) it’s extraordinarily boring, (b) your engineers have more valuable ways to spend their time, especially given the relatively modest amount of savings, and (c) it’s extremely error prone. Combing through billing data and consoles across every account, copying down endpoint IDs, on and on… there are lots of opportunities to miss something or make a mistake. We are, after all, human.

You could also write your own automation. That too, however, is far from foolproof. Your program would need to understand how to deal with errors at each step. You’d need to retry something if it fails, report it back, surface the findings, and keep track of how often you did it. This is a classic case of what we call “undifferentiated heavy lift.” It’s monotonous work that’s prime to be outsourced.

Enter CloudFix. CloudFix makes it simple to get rid of idle VPC endpoints and reclaim that spend. We thoroughly developed and tested the Cleanup Idle VPC Endpoints finder/fixer to minimize any risk. We prioritize not disrupting services that are in use by only targeting endpoints that have gone unused for an extended period, and we built the automation to account for errors along the way. All you have to do is enable the fixer, evaluate and approve the changes, and start saving.

Take human error – and human effort – out of the equation. With CloudFix, you’ll save just as many gold coins as Mario and Luigi, with a whole lot less effort. We call that a new high score in the game of AWS cost savings.


Ready to start saving on AWS? See how much you could cut from your cloud bill with a free cost optimization assessment, or explore CloudFix automated Finder/Fixers that eliminate waste across 30+ AWS services.

More from the blog

All 81 posts

See which fixers apply to your account.

About 5 minutes to connect with read-only roles. Results typically within 24 hours.