This article is part of the AWS Cost Optimization series, specifically the section on Network & Data Transfer Costs. In multi-account AWS platforms with centralized networking, NAT Gateways are often introduced early as the default egress solution. As systems scale-especially with data-heavy workloads—NAT Gateway costs frequently become a major and unexpected expense.
After identifying NAT Gateway costs and Cross-AZ traffic as key drivers, many teams ask the same question: can NAT Gateways be replaced with VPC Endpoints to reduce costs?
Architecture Context
This article assumes the following enterprise AWS architecture, which matches many large-scale platforms and data systems:
- An AWS Organization with multiple accounts
- Network Account
- Shared Services Account
- Multiple Workload Accounts
- A centralized Transit Gateway in the Network Account
- NAT Gateways deployed per Availability Zone in the Network Account
- Workload VPCs attached to the Transit Gateway
- Backend services implemented in Spring Boot (ECS, EKS, or EC2)
- Backend workloads running in private subnets with no Internet Gateway
- Data-heavy components accessing S3, DynamoDB, and other AWS-managed services
In this architecture, outbound traffic from workload accounts is routed through the Network Account, where NAT Gateways act as the primary egress.
Why NAT Gateways Become Expensive in This Architecture
In a centralized network design, NAT Gateways aggregate outbound traffic from multiple workload VPCs.
As the platform grows:
- All outbound traffic is funneled through a small number of NAT Gateways
- NAT data processing costs scale linearly with traffic volume
- Batch jobs and analytics pipelines generate large outbound transfers
- Traffic may cross Availability Zones before reaching the NAT Gateway
These costs are not configuration mistakes. They are a structural result of centralized networking combined with data-heavy workloads.
What VPC Endpoints Change (and What They Don’t)
VPC Endpoints allow private connectivity between a VPC and supported AWS services without traversing the public internet or a NAT Gateway.
They change the path that AWS-native service traffic takes, but they do not eliminate the need for outbound internet access.
Traffic destined for external APIs, public SaaS services, or unsupported endpoints still requires NAT Gateways.
Gateway Endpoints (S3 and DynamoDB)
Gateway Endpoints are especially effective in data platforms.
In architectures where large volumes of traffic are directed to S3 or DynamoDB—such as ingestion pipelines, CDP storage layers, or analytics
jobs—routing traffic through NAT Gateways is unnecessary.
Replacing NAT-routed S3 and DynamoDB traffic with Gateway Endpoints removes NAT data processing costs entirely while preserving private
networking.
Interface Endpoints (PrivateLink)
Interface Endpoints support a wider range of AWS services and private integrations.
They reduce reliance on NAT Gateways but introduce their own costs, including hourly charges and per-AZ pricing.
In multi-account, multi-AZ environments, uncontrolled Interface Endpoint creation can lead to endpoint sprawl and new cost management challenges.
When Replacing NAT Gateways Works Well
Replacing NAT Gateways with VPC Endpoints works best when traffic patterns are predictable and AWS-native.
Common examples in this architecture include:
- Spring Boot services reading and writing objects to S3
- Batch processing and ETL jobs interacting with DynamoDB
- Analytics workloads accessing AWS-managed services at scale
In these scenarios, VPC Endpoints provide immediate and measurable cost reductions without changing the security model.
When NAT Gateways Are Still Required
NAT Gateways remain necessary for:
- Access to public APIs and third-party SaaS platforms
- Mixed traffic patterns that include both AWS services and internet destinations
- Transitional architectures during refactoring or migration
In centralized, multi-account designs, eliminating NAT Gateways entirely is rarely realistic. The goal is controlled usage, not removal.
NAT Gateway and Cross-AZ Traffic as a Cost Multiplier
NAT Gateway costs increase significantly when traffic crosses Availability Zones before reaching the gateway.
This pattern is common in Transit Gateway-based architectures, where workloads and shared network components span multiple AZs.
This interaction is explained in detail in Cross-AZ Traffic Costs in AWS.
By routing AWS service traffic through VPC Endpoints instead of NAT Gateways, platforms often reduce both NAT data processing fees and
Cross-AZ transfer charges.
A Practical Egress Design Pattern for This Architecture
In mature multi-account environments, NAT Gateways and VPC Endpoints coexist.
A common and effective pattern is:
- Use VPC Endpoints for high-volume AWS-native service traffic
- Reserve NAT Gateways for unavoidable internet access
- Review traffic flows regularly as workloads evolve
This approach aligns cost optimization with architectural intent rather than reactive cost cutting.
Conclusion
In centralized, multi-account AWS architectures, NAT Gateways are not a design mistake—but they are rarely the optimal solution for all outbound traffic.
Replacing NAT Gateways with VPC Endpoints can significantly reduce network costs when applied intentionally and selectively.
The objective is not elimination, but deliberate and well-governed use.
Part of the AWS Cost Optimization series
Back to AWS Cost Optimization pillar
Related:
NAT Gateway Costs in Multi-Account AWS Data Platforms
Cross-AZ Traffic Costs in AWS
Next:
Transit Gateway Costs in Multi-Account AWS Architectures