VPC interface endpoints bill an hourly availability charge per Availability Zone where they are deployed, even when traffic is near zero. This finding is distinct from NAT Gateway overuse: NAT findings flag high data-processing charges on a shared egress path, while idle endpoint findings flag private connectivity you are paying for but not using.
Before you delete an endpoint
- Confirm no applications, Lambda functions, or batch jobs still route traffic through this endpoint (check security groups, route tables, and DNS resolution in the VPC).
- Verify the same AWS service is not reachable through a different endpoint, a gateway endpoint, or public internet paths your workloads still depend on.
- Review cross-AZ endpoint deployments — deleting one AZ's endpoint may be enough if traffic is concentrated elsewhere.
- Coordinate with teams that onboarded the endpoint for compliance or private-link requirements; some endpoints exist for audit reasons despite low traffic.
Paid plans include remediation scripts to delete the endpoint. Review the generated commands against your network diagram before running them in production.
What triggers this finding
A VPC interface endpoint with near-zero traffic over the lookback window, still incurring hourly availability charges.
Typical fix
Delete the endpoint if workloads no longer need private connectivity to the service. Update route tables and security groups first.
Example savings
About $7–$15/month per interface endpoint in most regions, plus data processing charges.
See also: Severity and savings estimates for how Parsivex calculates figures on your report.
Per-ENI billing, and why the estimate is a floor
An interface endpoint is not an abstract routing rule — it is a set of elastic network interfaces, one in each subnet you place it in, and AWS bills the hourly availability charge per interface. At the us-east-1 reference rate of $0.01 per hour, that is $7.30 a month for a single interface, plus a per-GB data-processing charge on whatever passes through.
Parsivex prices this finding at the single-interface figure: $7.30 a month, reported as the full saving. For a production endpoint deployed across three Availability Zones — the normal configuration, since a single-AZ endpoint is a single point of failure — the real charge is three times that, and deleting it saves three times what the finding says. The estimate is a deliberate floor, and the number of subnets is the multiplier the finding does not apply.
The excluded data-processing charge works the same way, though for an endpoint by definition moving under a megabyte a month it rounds to nothing. Where the estimate genuinely understates is subnet count, not traffic.
Gateway endpoints never appear here. S3 and DynamoDB gateway endpoints are free, carry no ENIs, and the detector skips anything whose endpointType is not Interface.
Confirming the traffic, and the subnet count
The finding fires when BytesProcessed over 30 days totals under 1 MB, the endpoint is at least 30 days old, and CloudWatch returned metrics at all — an endpoint whose metrics could not be read is skipped rather than assumed idle.
aws cloudwatch get-metric-statistics --namespace AWS/PrivateLinkEndpoints \
--metric-name BytesProcessed \
--dimensions Name=VpcEndpointId,Value=vpce-0123456789abcdef0 \
--start-time 2026-07-13T00:00:00Z --end-time 2026-08-12T00:00:00Z \
--period 86400 --statistics Sum
A megabyte across a month is a genuinely tiny number — a handful of API calls would clear it — so a total under the threshold means the endpoint is carrying essentially nothing. Then check what you are actually paying for:
aws ec2 describe-vpc-endpoints --vpc-endpoint-ids vpce-0123456789abcdef0 \
--query 'VpcEndpoints[].[ServiceName,VpcId,SubnetIds,PrivateDnsEnabled]'
The length of SubnetIds is the multiplier on the $7.30. PrivateDnsEnabled is the field that determines what happens when the endpoint is removed, and it matters more than the traffic figure.
Endpoints that carry almost nothing on purpose
Low byte counts are the expected steady state for a whole class of legitimate endpoints, because the value is in availability rather than volume.
- Break-glass access paths. An SSM endpoint exists so that Session Manager still works when the bastion is gone and the NAT Gateway is misconfigured. It processes a few kilobytes a year and is the only way into a private subnet on the worst day.
- Credential and key operations. KMS and STS endpoints handle small, infrequent, and completely load-bearing calls.
- Compliance mandates. Endpoints built to satisfy a requirement that named AWS traffic never traverses the public internet. The requirement is unaffected by how much traffic there is.
- Cost avoidance for the wrong service. An endpoint added to keep traffic off a NAT Gateway, where the traffic subsequently moved elsewhere.
- Disaster-recovery VPCs. Endpoints in a standby environment that is quiet by design.
The last of these has a trap attached, and it points back at an adjacent finding.
Deleting is quiet, not loud
The instinct is that removing an unused endpoint either saves money or breaks something obviously. On an endpoint with private DNS enabled, neither happens — the failure is silent.
While the endpoint exists, private DNS makes the service's standard hostname resolve to the endpoint's private addresses inside the VPC. Delete the endpoint and that hostname resolves to the public service address again. Traffic does not fail; it reroutes, out through the NAT Gateway or internet gateway, where it now attracts NAT data-processing charges and, for an environment with a compliance requirement about public-internet traversal, quietly violates it. An endpoint costing $7.30 a month can be the thing preventing a much larger NAT Gateway charge, which is why the traffic figure alone is not sufficient grounds to remove it.
The reversibility is genuinely good, with one caveat. Recreating an interface endpoint takes a couple of minutes and costs nothing extra, so an over-eager deletion is cheap to undo. But the replacement gets a new endpoint ID, and anything that references the old one by value breaks permanently — most often IAM and bucket policies with an aws:SourceVpce condition, which will keep denying requests until every policy is updated. Search for the endpoint ID across your policies before deleting, not after.
Where an endpoint is deployed across more subnets than it needs, removing individual subnet associations is the partial fix worth considering: each one removed drops another $7.30 from the monthly charge while the endpoint, its ID, and its DNS behaviour all stay intact.