In many AWS architectures, workloads run in private subnets and still need to communicate with services outside their VPC.
The default solution is usually a NAT gateway. It works well for simple environments, but in larger platforms the amount of traffic passing through NAT can become surprisingly large.
This pattern appears frequently in systems such as a Customer Data Platform (CDP) ingesting external events, an API Manager exposing services to partners, or internal applications like Campaign Manager calling external APIs.
When these systems run inside a multi-account landing zone architecture, outbound traffic from multiple VPCs often concentrates around a small number of NAT gateways.
At that point, engineers usually start evaluating alternatives such as PrivateLink or interface endpoints.
NAT Gateway as the Default Outbound Path
In many landing zone setups, application workloads are deployed in private subnets for security reasons.
For example:
• CDP ingestion workers processing external events
• API Manager backend services calling partner APIs
• Campaign Manager services sending notifications or analytics data
All of these systems need outbound connectivity.
The simplest design is routing outbound traffic through NAT gateways located in the application VPC or in a centralized egress VPC.
This design keeps services private while still allowing them to reach external endpoints.
However, NAT gateways introduce two cost components:
- Hourly gateway cost
- Data processing charges for every GB of traffic
In architectures where multiple systems generate outbound traffic simultaneously, NAT usage can scale quickly.
This behavior is discussed in more detail in NAT Gateway Costs in Multi-Account AWS Data Platforms.
When PrivateLink Changes the Traffic Pattern
PrivateLink allows services to expose endpoints privately inside the AWS network.
Instead of sending traffic to public endpoints through NAT gateways, workloads can connect directly to interface endpoints inside their VPC.
In multi-account environments this is particularly useful when one platform exposes internal services to other accounts.
Examples include:
- An API Manager exposing internal APIs to application accounts
- A shared CDP ingestion service used by multiple systems
- Platform services running in a central account within a landing zone
Using PrivateLink removes the need for internet routing and NAT traversal for these interactions.
However, PrivateLink introduces its own cost model based on endpoint usage and data processing.
This makes the decision less obvious than it initially appears.
A related comparison between endpoint connectivity models is explained in VPC Endpoints vs NAT Gateway: When It Works, When It Doesn’t.
Cross-Account Communication in Landing Zones
n landing zone architectures, different systems often run in separate AWS accounts.
For example:
- API Manager in a shared services account
- CDP platform in a data account
- Campaign Manager in an application account
Traffic between these systems may flow through centralized networking components such as Transit Gateway.
When service-to-service communication becomes frequent, routing everything through NAT or internet endpoints can introduce unnecessary network hops.
In these cases, exposing internal services through PrivateLink can simplify traffic flow while keeping connectivity private.
The networking model behind these architectures is described in Transit Gateway Costs in Multi-Account AWS Architectures.
When NAT Gateway Still Makes More Sense
Despite the advantages of PrivateLink, NAT gateways remain the simplest solution for many workloads.
For example:
- Services downloading container images
- Applications calling third-party SaaS APIs
- Workloads accessing public cloud services
In these scenarios PrivateLink may not be available or may add unnecessary complexity.
Most real systems therefore end up using a combination of both approaches.
Understanding where traffic flows between services is the key to deciding when NAT gateways are acceptable and when PrivateLink is worth introducing.
The broader context of how these traffic patterns contribute to network charges is explained in AWS Data Transfer Costs in Multi-Account Architectures.
Conclusion
The choice between NAT gateways and PrivateLink is rarely about replacing one component with another.
It is about understanding how services communicate inside the platform.
In systems such as CDP pipelines, API platforms, and campaign systems running inside multi-account landing zones, different traffic patterns emerge naturally as the architecture grows.
NAT gateways provide a simple outbound path, while PrivateLink enables controlled private connectivity between services.
Engineering teams that understand these patterns can make more informed decisions about both architecture and network cost.