Explanation
Workloads in private subnets often access AWS services like S3 or DynamoDB. If this traffic is routed through a NAT Gateway, it incurs both hourly and data processing charges. However, AWS offers VPC Gateway Endpoints (for S3/DynamoDB) and Interface Endpoints (for other services), which provide private access paths that bypass the NAT Gateway entirely. When teams fail to use VPC endpoints - often due to default routing configurations or lack of awareness - they unnecessarily route internal service calls through a costlier, public-facing path. This leads to persistent and avoidable spend.
Relevant Billing Model
NAT Gateways are billed based on a flat hourly fee for provisioning, plus a per-gigabyte charge for data processed. VPC Gateway Endpoints for services like S3 and DynamoDB are free to use. Interface Endpoints for other AWS services do incur hourly and per-gigabyte charges but are typically more cost-effective than routing the same traffic through a NAT Gateway.
Detection
- Check VPC route tables to identify traffic to AWS services routed through NAT Gateway
- Use CloudWatch metrics to analyze NAT Gateway data processing volumes
- Identify subnets that interact with S3, DynamoDB, or other AWS services and lack a configured VPC endpoint
- Correlate high NAT Gateway traffic with internal service calls to confirm inefficiency
Remediation
- Create VPC Gateway Endpoints for services like S3 and DynamoDB in applicable regions
- Use Interface Endpoints for other AWS services frequently accessed by private subnet workloads
- Update route tables to redirect traffic through the appropriate VPC endpoint instead of NAT Gateway
- Educate engineering teams on when and how to use VPC endpoints to minimize network costs