A municipal shared-services VPC accumulated many interface VPC endpoints for rarely used AWS APIs, and hourly endpoint ENI charges are noticeable. What should the architect do?
Select an answer to reveal the explanation.
Short Explanation
Every fancy private doorway has a monthly rent. Keep the interface endpoints you use; return the keys on the ones gathering dust.
Full Explanation
Interface VPC endpoints create Elastic Network Interfaces in selected subnets/AZs and incur hourly charges plus data processing. A municipal shared-services VPC that accumulated many endpoints for rarely used AWS APIs pays rent on unused private doorways. The architect should consolidate and remove unnecessary interface endpoints, retaining only those whose private-access, compliance, or NAT-avoidance value exceeds ENI hourly cost. Shared endpoints for commonly used APIs (for example, frequently called regional services) stay; dusty one-off endpoints go.
Creating an interface endpoint for every AWS service in every AZ immediately maximizes spend predictability in the wrong direction—predictably high. Assuming interface endpoints have no hourly cost so sprawl does not matter is factually wrong. Replacing all interface endpoints with public 0.0.0.0/0 security group rules on databases is a security failure, not a FinOps strategy.
Exam caveat: Gateway endpoints for S3/DynamoDB have a different pricing model (no hourly gateway charge) and should not be confused with interface endpoint ENI hours. Prefer gateway endpoints where applicable before proliferating interface endpoints.
Operational check: inventory interface endpoints and last-used CloudWatch metrics or flow logs, meet with app owners on required private AWS APIs, delete unused endpoints in a change window, prefer gateway endpoints for S3 backup paths, and confirm VPC endpoint hourly charges drop in Cost Explorer.