n many AWS environments built on a landing zone architecture, outbound internet access is often centralized.
Instead of allowing every application VPC to deploy its own NAT gateway, organizations route outbound traffic through a dedicated network account. This design is common in multi-account environments because it simplifies governance, logging, and security controls.
For example, a typical setup may include:
- A network account hosting shared connectivity components
- Application accounts running systems such as API Manager, Campaign Manager, or a Customer Data Platform (CDP)
- Centralized NAT gateways handling internet-bound traffic
From an operational perspective, this architecture is convenient. Security teams can control outbound access in one place, and logging becomes easier to manage.
However, centralizing internet egress also changes how traffic flows through the environment. As multiple systems send outbound requests through shared infrastructure, network paths become longer and data transfer costs can accumulate in unexpected places.
Why Landing Zone Architectures Centralize Internet Egress
Landing zone patterns encourage separation of responsibilities across multiple AWS accounts.
Application workloads typically run in dedicated accounts, while shared infrastructure components are hosted in a network account.
In this model, outbound internet traffic from application VPCs often follows a path like this:
Application VPC → Transit Gateway → Egress VPC → NAT Gateway → Internet
For example, services inside a Campaign Manager platform may need to call external APIs. Similarly, ingestion pipelines in a CDP may pull data from external systems or SaaS platforms.
Rather than deploying NAT gateways inside each application account, organizations route these requests through the centralized egress VPC.
This approach simplifies governance, but it also introduces additional network hops.
Traffic that would normally exit directly from a local NAT gateway must now pass through shared networking infrastructure.
How Centralized Egress Changes Traffic Patterns
When outbound traffic is centralized, the network path becomes longer than in a standalone VPC architecture.
Instead of leaving the VPC immediately through a NAT gateway, packets travel through the Transit Gateway before reaching the egress VPC.
This pattern becomes particularly noticeable in systems where outbound communication is frequent.
For example:
- API Manager services calling partner APIs
- CDP ingestion services retrieving external datasets
- Campaign Manager components interacting with external messaging platforms
In these cases, every outbound request follows the same path through the network hub.
While the architecture remains secure and manageable, the amount of traffic processed by shared infrastructure can grow quickly as multiple platforms scale.
The cost behavior of centralized routing components is discussed in Transit Gateway Costs in Multi-Account AWS Architectures.
NAT Gateway Concentration in Egress VPCs
A common consequence of centralized egress is that NAT gateways become concentrated in a single VPC.
Instead of distributing outbound traffic across multiple application accounts, all internet-bound requests are routed through the NAT gateways in the egress VPC.
In smaller environments this design is rarely noticeable.
However, in larger platforms with multiple systems generating outbound traffic — such as API Manager services communicating with partners or CDP pipelines interacting with external data sources — the NAT gateways in the egress VPC can become extremely busy.
This concentration means that a relatively small number of infrastructure components process the outbound traffic of the entire platform.
The cost implications of NAT gateways in these scenarios are described in NAT Gateway Costs in Multi-Account AWS Data Platforms.
Cross-AZ and Inter-VPC Traffic in Shared Networking
Centralized networking can also introduce additional internal traffic between VPCs.
For example, when application services communicate across accounts through a Transit Gateway, traffic may cross multiple Availability Zones depending on the placement of resources.
Load balancers, application services, and shared networking components may all reside in different zones.
When these elements interact frequently, the resulting cross-AZ traffic can contribute to overall network transfer costs.
This behavior becomes particularly visible in microservice architectures where services interact frequently across multiple layers of infrastructure.
A deeper explanation of cross-zone traffic patterns is covered in Cross-AZ Traffic Costs in AWS.
Observing Traffic Growth as Platforms Scale
In early stages of a platform, centralized egress usually appears inexpensive.
Outbound traffic may be limited to occasional API calls, software updates, or low-volume integrations.
As systems mature, however, outbound communication patterns tend to increase.
For example:
- An API Manager gaining more external consumers
- A CDP ingesting data from additional partner systems
- Campaign systems interacting with multiple external messaging platforms
When these workloads run inside a shared networking architecture, the traffic generated by all systems accumulates in the same egress infrastructure.
Understanding these traffic patterns helps engineering teams anticipate where network costs may appear as the platform grows.
Conclusion
Centralized internet egress is a common design pattern in AWS landing zone environments.
By routing outbound traffic through a shared network account, organizations simplify governance and security management.
At the same time, this design concentrates traffic flows through a smaller set of networking components such as Transit Gateway attachments and NAT gateways.
In platforms that include systems like API Manager, Campaign Manager, and customer data pipelines, the amount of outbound traffic can grow steadily as the platform scales.
Understanding how these traffic patterns interact with shared networking infrastructure helps engineering teams design landing zone architectures that remain both secure and cost-aware.