As AWS environments grow beyond a single account, networking architecture becomes one of the most important structural decisions in the platform.
In many organizations adopting an AWS landing zone model, workloads are deliberately separated across accounts. API services, internal applications, and data platforms often operate in different VPCs to isolate responsibilities and reduce operational risk.
A typical architecture might include an API Manager VPC handling partner integrations, a CDP platform VPC processing customer data pipelines, and a Campaign Manager VPC running application services.
Although these systems are isolated at the account level, they still need to communicate internally. APIs retrieve customer attributes, data pipelines publish results to application services, and batch workloads move datasets across environments.
At this point, engineering teams must decide how VPCs should connect to each other. Two of the most common approaches are VPC Peering and AWS Transit Gateway.
Both provide private connectivity inside AWS, but they behave very differently as architectures scale.
Why VPC Connectivity Becomes Necessary in Multi-Account Platforms
Before comparing the two approaches, it is useful to understand why VPC connectivity becomes unavoidable in modern AWS platforms.
In smaller deployments, most services run inside a single VPC. Internal communication happens through private subnets, and networking complexity remains limited.
Multi-account environments change this model significantly.
For example, a typical data platform architecture might separate systems as follows:
- API Manager account exposing APIs to external consumers
- Data platform account hosting CDP ingestion pipelines and analytics jobs
- Application account running campaign services or internal tools
Even though these workloads are separated across accounts, they still exchange data.
API services may call internal data APIs. Campaign systems may query segmentation results from analytics pipelines. Batch processes may publish datasets from ingestion environments into application layers.
Without private networking between VPCs, these interactions would require public endpoints or additional proxy layers. For security and latency reasons, most organizations prefer private connectivity.
This is where the decision between VPC Peering and Transit Gateway typically appears.
VPC Peering: Simple, Direct Network Connectivity
To understand how these architectures differ, it is helpful to start with the simpler model.
VPC Peering creates a direct private connection between two VPCs. Once the connection is established, resources inside both networks can communicate using internal IP addresses.
Traffic remains within the AWS backbone and never traverses the public internet.
In small environments, this model works extremely well.
For example, an API service inside an API Manager VPC might call an internal customer profile service hosted inside the CDP platform VPC. A single peering connection allows that communication to happen with minimal configuration.
Because traffic flows directly between the two VPCs, the network path is short and predictable.
However, this model begins to break down as the number of VPCs grows.
The Peering Mesh Problem
As additional VPCs are introduced, the number of required peering connections increases rapidly.
This happens because VPC Peering is non-transitive. If VPC A is connected to VPC B, and VPC B is connected to VPC C, VPC A cannot automatically communicate with VPC C.
Each connection must be created explicitly.
In a platform with three VPCs, the connections might look like this:
- API Manager VPC ↔ CDP Platform VPC
- API Manager VPC ↔ Campaign Manager VPC
- CDP Platform VPC ↔ Campaign Manager VPC
As the environment expands, this relationship grows quickly.
With five VPCs, the number of required connections becomes ten.
With ten VPCs, the number increases to forty-five.
This network topology eventually becomes a peering mesh, where each VPC maintains connectivity relationships with multiple peers.
Operational complexity grows in several ways:
- Route tables must be maintained across multiple VPCs
- CIDR management becomes more difficult
- Network policy changes must be propagated across connections
At a certain scale, the effort required to maintain the network becomes a platform engineering challenge in itself.
Transit Gateway and the Hub-and-Spoke Model
When VPC connectivity grows beyond a few direct connections, many organizations adopt a different architecture.
AWS Transit Gateway introduces a centralized routing hub that connects multiple VPCs through a hub-and-spoke topology.
Instead of connecting every VPC directly to each other, each VPC attaches to the Transit Gateway.
Traffic between networks flows through this hub.
In landing zone architectures, the Transit Gateway typically resides in a network account, while workload VPCs exist in separate application accounts.
For example:
• API Manager VPC attaches to the Transit Gateway
• CDP platform VPC attaches to the Transit Gateway
• Campaign Manager VPC attaches to the Transit Gateway
Each VPC requires only a single attachment.
This dramatically simplifies connectivity because the Transit Gateway becomes the central routing point for the entire platform.
The cost characteristics of this model are explored in Transit Gateway Costs in Multi-Account AWS Architectures.
Cost Model Differences
Although Transit Gateway simplifies topology, it introduces a different cost structure.
With VPC Peering, traffic flows directly between VPCs. The primary cost consideration is data transfer between Availability Zones or regions.
Transit Gateway introduces additional components:
- Attachment costs per VPC
- Per-GB data processing charges
Every packet exchanged between VPCs must pass through the Transit Gateway.
In platforms where services exchange large volumes of data, these processing costs can accumulate over time.
Understanding how these traffic flows contribute to overall network spend is discussed further in AWS Data Transfer Costs in Multi-Account Architectures.
Traffic Patterns in Data Platforms and API Systems
In many modern platforms, internal traffic grows as systems become more interconnected.
For example:
- API Manager services retrieving customer attributes from CDP APIs
- Campaign systems requesting segmentation results from analytics pipelines
- Ingestion pipelines publishing datasets between processing environments
These interactions generate east-west traffic inside the platform.
As services scale and workloads increase, the number of internal requests grows as well.
When these systems run across multiple VPCs and accounts, network architecture plays a direct role in both operational complexity and cost behavior.
Designing connectivity with these traffic patterns in mind is often more important than simply comparing service pricing.
Conclusion
VPC Peering and AWS Transit Gateway both provide secure private connectivity between VPCs, but they address different architectural needs.
Peering offers a simple and efficient solution when the number of networks is small and connectivity requirements remain limited.
Transit Gateway introduces a centralized routing hub that simplifies connectivity in larger multi-account environments.
For engineering teams operating API platforms, customer data systems, and multi-account infrastructures, the decision should be based on expected platform growth and traffic patterns rather than pricing alone.
Network architectures that appear simple today must remain manageable as the platform evolves.