Suboptimal Routing Through NAT Gateway Instead of VPC Endpoint

Jason Eckle

Service Category

Networking

Cloud Provider

AWS

Service Name

AWS NAT Gateway

Inefficiency Type

Inefficient Configuration

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

Relevant Documentation