- Newest
- Most votes
- Most comments
You’re already on the right track with CloudWatch metrics and VPC Flow Logs — that’s usually where I start as well. But in practice, I’ve found it’s better to combine a few checks instead of relying on just one.
One thing that helped me was checking CloudTrail. If an endpoint isn’t showing up with a vpcEndpointId in events over a longer period, it’s usually a sign nothing is really using it.
I also look at the ENIs created by the endpoint (in EC2 → Network Interfaces). If the traffic there is flat — no bytes or packets for weeks — that’s another strong indicator.
Cost Explorer is useful too. Sometimes you’ll see endpoints that are charging hourly but have almost no data processed. Those are often just sitting idle.
Another simple check is tags/ownership. In a lot of cases, endpoints are left behind by old projects, and there’s no clear owner anymore.
And finally, a quick sanity check against the architecture helps — like if there’s an endpoint for SSM or ECR but nothing in that VPC is actually using those services anymore.
Before deleting anything, I usually tag them (something like candidate-for-deletion=true) and leave them for a few days just to be safe.
Based on the available information, to clean up unused VPC Endpoints and reduce costs, you can delete them through either the AWS Console or command line tools.
To delete VPC Endpoints using the Console:
- Open the Amazon VPC console at https://console.aws.amazon.com/vpc/
- In the navigation pane, choose "Endpoints"
- Select the interface endpoint you want to delete
- Choose "Actions", then "Delete VPC endpoints"
- When prompted for confirmation, enter "delete"
- Choose "Delete"
When you delete an interface endpoint, its associated endpoint network interfaces are also deleted.
To delete VPC Endpoints using the Command Line: You can use the AWS CLI with the delete-vpc-endpoints command or Windows PowerShell with the Remove-EC2VpcEndpoint command. With the CLI, you can delete multiple endpoints at once by specifying their IDs.
Regarding identification of unused endpoints: The approaches you've mentioned—checking CloudWatch metrics (BytesProcessed) for Interface Endpoints and reviewing VPC flow logs—are the standard methods for identifying traffic patterns. Unfortunately, the available documentation doesn't provide additional specific methods beyond these for identifying unused VPC endpoints. Your current approach of monitoring traffic over a 30-60 day period using CloudWatch metrics and VPC flow logs is the recommended way to determine which endpoints have negligible usage before proceeding with deletion.
Once you've identified the unused endpoints through your traffic analysis, you can proceed with the deletion process outlined above to reduce costs.
Sources
Use DeleteVpcEndpoints with an AWS SDK or CLI - AWS SDK Code Examples
Delete an interface endpoint - Amazon Virtual Private Cloud
Manage resource endpoints - Amazon Virtual Private Cloud
I’ve been dealing with VPC endpoint 'cost creep' as well. To avoid just guessing based on CloudWatch, I ran your specific requirements through a grounded engine I'm building called Nexus.
It’s designed to pull directly from the AWS Well-Architected and Networking documentation to avoid the usual AI hallucinations. Here is the raw technical output it provided for your scenario:
"Based on your cost optimization goals, here are additional approaches to identify unused VPC Endpoints:
****## 1. VPC Flow Logs Analysis (Enhanced)
- Filter logs by destination port and VPC Endpoint ENI
- Look for rejected connections or connection timeouts
- Parse logs for source IPs to identify which applications are connecting
2. AWS CloudTrail
- Monitor API calls to VPC Endpoints
- Check for service-specific API activity (e.g., S3, Secrets Manager calls through endpoints)
- Review "DescribeVpcEndpoints" and related operations
3. Service-Specific Metrics
- Check the underlying service's metrics (not just the endpoint):
- S3: S3 bucket request metrics
- Secrets Manager: API calls to retrieve secrets
- SNS/SQS: Message counts
- DynamoDB: Request counts
4. VPC Endpoint Service Metrics
- Review "ActiveConnections" CloudWatch metric on the endpoint itself
- Monitor connection state changes
5. Network Analysis Tools
- Use Amazon Detective or VPC Flow Logs Insights for deeper packet analysis
- Query for any traffic associated with endpoint IPs over your time period
6. Manual Audit
- Document which applications/teams own each endpoint
- Contact application owners to confirm current usage"****
The part about checking the underlying service metrics (S3 request metrics, etc.) rather than just the endpoint BytesProcessed is usually the safest 'Double Check' before you hit delete.
I’m using Nexus to verify these kinds of infrastructure spend questions against the actual AWS frameworks—if you have a more specific set of services (like PrivateLink for 3rd party apps), I'm happy to run the specific docs through the engine for you.
Thanks for all the advice. We’ve just noticed ourselves that our costs have skyrocketed because we’re suddenly being charged for VPC endpoints that have existed for several years but were never billed before. According to the analytics, data is flowing through them—that’s undeniable—but apparently AWS has changed its billing policy, and now these VPC endpoints are being charged as well.
Do you know what would happen if we disabled some of the endpoints, since we believe there isn’t enough data traffic and the VPC endpoint is more expensive? I can’t find any direct information on what happens when an endpoint is removed. This applies, for example, to Monitoring, ECS, and ECR. We don’t want a situation where, after disabling the endpoint, no service can pull its image anymore.
Relevant content
- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated 4 years ago
Thanks Pothuraju Jayakrishna Yadav.