Many AWS organizations adopt a landing zone architecture to standardize account structure, security controls, and network connectivity across their cloud environments.
In these setups, workloads are distributed across multiple AWS accounts. Application platforms, data pipelines, and shared infrastructure often run in separate VPCs connected through centralized networking components such as Transit Gateway or shared networking accounts.
While this architecture improves governance and scalability, it also introduces new network cost behaviors that are not always obvious during system design.
In many cases, unexpected AWS network costs do not originate from a single service. Instead, they emerge from architectural patterns that gradually accumulate data transfer charges across multiple layers of the platform.
Understanding these architectural anti-patterns helps engineering teams identify where network costs originate and how they evolve as the platform grows.
Before examining specific examples, it is important to understand how landing zone architectures influence network traffic patterns.
How Landing Zone Architectures Change Network Traffic
Landing zone environments typically separate workloads across several accounts to enforce isolation and ownership.
For example, an organization may operate:
- A network account managing shared connectivity
- An API platform account exposing APIs to partners
- A data platform account running CDP pipelines
- An application account hosting campaign services
Although each account operates independently, the services running inside them frequently interact.
API services may request customer data from the CDP platform. Campaign systems may retrieve segmentation results from analytics pipelines. Data pipelines may publish processed datasets to downstream applications.
These interactions create cross-VPC and cross-account traffic patterns that are routed through centralized networking infrastructure.
Without careful design, these traffic patterns can unintentionally amplify AWS network costs.
Before addressing solutions, it helps to examine some of the most common architectural patterns that generate unnecessary network spend.
Anti-Pattern 1: Centralizing All Traffic Through NAT Gateways
One of the most common cost issues in landing zone environments is routing all outbound traffic through centralized NAT Gateways.
In many architectures, private subnets rely on NAT Gateways to access external services or AWS public endpoints.
However, when workloads frequently access AWS services such as S3 or DynamoDB through NAT Gateways, unnecessary data processing costs are introduced.
For example:
Private subnet → NAT Gateway → S3
Although this pattern works functionally, it forces internal AWS service traffic through an internet gateway path that incurs NAT processing charges.
In data-heavy systems such as CDP platforms, ingestion pipelines often read or write large datasets to S3. If these transfers pass through NAT Gateways, costs can grow quickly.
A more efficient approach is using VPC Gateway Endpoints, which allow services such as S3 to be accessed directly within the AWS network without NAT traversal.
This architectural trade-off is examined in VPC Endpoints vs NAT Gateway: When It Works, When It Doesn’t.
Another architectural pattern that frequently introduces unexpected cost growth is excessive cross-Availability Zone traffic.
Anti-Pattern 2: Uncontrolled Cross-AZ Service Communication
High availability often leads engineers to deploy services across multiple Availability Zones.
Load balancers distribute requests across instances in different zones, and container orchestration systems dynamically place workloads across nodes.
While this improves resilience, it can unintentionally create cross-AZ service communication.
For example:
Service in AZ-A → Load Balancer → Service in AZ-B
Every request crossing AZ boundaries incurs a data transfer charge.
In high-throughput platforms such as API systems or analytics pipelines, these charges accumulate gradually but persistently.
This behavior is often difficult to detect because the architecture appears correct from a reliability perspective.
A deeper explanation of these patterns can be found in Cross-AZ Traffic Costs in AWS.
As organizations scale their landing zone environments, connectivity between accounts often introduces another hidden cost pattern.
Anti-Pattern 3: Excessive Transit Gateway Data Processing
Transit Gateway is frequently used as the central connectivity layer in landing zone architectures.
All application VPCs attach to the Transit Gateway, and traffic between accounts flows through this central hub.
While this design simplifies routing and governance, it also introduces per-GB data processing charges.
For example:
API Manager VPC → Transit Gateway → CDP platform VPC
Each request between services must pass through the Transit Gateway.
In platforms where microservices exchange data frequently across accounts, these processing costs can scale with application traffic.
Although Transit Gateway provides strong operational benefits, engineers should evaluate which traffic flows truly require centralized routing.
The pricing behavior of this architecture is discussed in Transit Gateway Costs in Multi-Account AWS Architectures.
Another frequently overlooked source of network cost comes from internal service communication patterns.
Anti-Pattern 4: Excessive Service-to-Service Communication
Microservice architectures encourage decomposing systems into smaller services.
However, as services multiply, the number of internal API calls increases dramatically.
A single user request may trigger multiple internal service interactions:
Client → API layer → authentication service → customer service → analytics service
Each internal call generates network traffic.
When these services operate across multiple VPCs or AZs, the cumulative cost impact becomes noticeable.
Platforms that rely heavily on internal APIs should monitor east-west traffic carefully to ensure that service boundaries do not unintentionally amplify network cost.
This behavior is explored further in Hidden Inter-Service Traffic Costs in AWS Microservice Architectures.
Conclusion
Landing zone architectures provide strong governance and scalability for large AWS environments, but they also introduce new networking behaviors that can influence cost.
Unexpected network spend often originates not from individual services but from architectural patterns that accumulate traffic across multiple layers of the platform.
Centralized NAT usage, uncontrolled cross-AZ traffic, excessive Transit Gateway routing, and dense service-to-service communication are among the most common cost drivers.
By understanding these patterns early, engineering teams can design network architectures that balance scalability, resilience, and cost efficiency as the platform grows.