Finding the Right AWS Network Architecture for Your Company
A practical guide to choosing between VPC Peering, Transit Gateway, Cloud WAN, PrivateLink, VPN, and Direct Connect based on your needs.
In the first part , we talked about the questions I ask before designing a network: what already exists, what the company is designing for, how the IP space looks, and what actually needs to communicate.
Now comes the harder part: choosing the architecture.
AWS gives us many ways to connect networks together: VPC Peering, Transit Gateway, Cloud WAN, PrivateLink, VPN, Direct Connect, and others.
The problem is that having more options doesn’t necessarily make the decision easier.
I don’t think there is one AWS networking architecture that is always better than the others. A solution that works perfectly for a company with ten VPCs in one Region might be a bad choice for another company operating hundreds of VPCs across multiple Regions.
So instead of starting with:
Should we use Transit Gateway or Cloud WAN?
I prefer to go back to the requirements we collected in Part 1.
1. Do you actually need a central network?
This is probably the first question I would ask.
If you only have a few VPCs and only some of them need to communicate, you might not need to introduce a central networking service at all.
VPC Peering can still be a perfectly valid option.
It gives you direct connectivity between two VPCs, including VPCs in different accounts and Regions. The important limitation is that VPC Peering is not transitive. If VPC A is connected to B, and B is connected to C, that does not mean A can communicate with C through B.
With three or four VPCs, this might not be a problem.
But imagine having 50 VPCs and trying to manage all the required peering connections, route tables, and dependencies between them.
At some point, the simplicity of VPC Peering starts working against you.
So I usually see VPC Peering as a good option when the connectivity requirement is small and clear, rather than as the backbone of a large network.
2. When does Transit Gateway make sense?
When the number of VPCs starts growing, I usually start thinking about Transit Gateway.
Transit Gateway gives you a hub-and-spoke architecture. Instead of creating connections between every VPC, each VPC connects to a central Transit Gateway, which then handles routing between them.
This immediately makes the network easier to manage.
But connecting everything to one Transit Gateway does not mean everything should communicate.
Transit Gateway route tables allow you to create different routing domains. For example, you can have separate route tables for production, development, shared services, or security environments and control which routes are propagated between them.
For many companies running mainly in one AWS Region, or even a few Regions, Transit Gateway can be enough.
And this is an important point:
Multi-Region does not automatically mean Cloud WAN.
Transit Gateways can also be peered across Regions.
The real question is not only how many Regions you have. It is how much operational complexity you want to manage yourself.
3. When does Cloud WAN start becoming interesting?
Cloud WAN becomes more interesting when the network starts becoming global and managing it as separate Regional networks becomes difficult.
Imagine having multiple Regions, multiple Transit Gateways, many accounts, production and non-production environments, on-premises connectivity, and different routing requirements.
You can build all of that with Transit Gateway.
But now you also have to maintain the routing and segmentation consistently across those Regions.
Cloud WAN approaches this differently.
You define a core network policy that describes things like which Regions should participate in the network, how the network should be segmented, and how attachments should be associated with those segments.
For example, you might define segments such as:
- Production
- Non-production
- Shared services
- Security
- On-premises
For me, this is one of the main differences between Transit Gateway and Cloud WAN.
With Transit Gateway, you are managing the network infrastructure and routing.
With Cloud WAN, you are moving more toward defining the intent of the network through policy.
That can become valuable when the environment is large enough.
But that doesn’t mean Cloud WAN should always be the default.
If your company has 15 VPCs in one Region, introducing Cloud WAN and a global network policy might just add complexity you don’t need.
4. Maybe you don’t need network-to-network connectivity at all
Another question I like to ask is:
Do these two VPCs actually need to be connected, or does one application only need access to one service in the other VPC?
These are very different requirements.
Sometimes people immediately think about VPC Peering or Transit Gateway when an application needs to access another application.
But that gives network-level connectivity.
If all you need is to expose one specific service privately to another VPC or account, AWS PrivateLink might make more sense.
With PrivateLink, consumers can connect privately to a service without requiring general routing between the two VPCs.
This can reduce the amount of network connectivity you need to create in the first place.
And sometimes the easiest network to secure is the connection you never created.
5. Don’t forget the hybrid network
So far, we have mostly talked about VPC-to-VPC connectivity.
But if the company still has data centers, offices, or other on-premises infrastructure, hybrid connectivity becomes another major part of the decision.
For smaller requirements or backup connectivity, Site-to-Site VPN may be enough.
For larger or more predictable connectivity requirements, Direct Connect might be part of the design.
The important part is deciding where that connectivity terminates.
If you already have a Transit Gateway architecture, you can centralize VPN and Direct Connect connectivity through it rather than creating separate connectivity for every VPC.
The same idea applies to Cloud WAN when you are building a broader global network that includes both AWS and on-premises locations.
Again, the service should follow the architecture, not the other way around.
So which one should you use?
I don’t think I would create a rule such as:
- Small company = VPC Peering
- Medium company = Transit Gateway
- Large company = Cloud WAN
The number of VPCs matters, but it is not enough.
I would look at the combination of:
- Number of VPCs
- Number of Regions
- Number of AWS accounts
- How much segmentation is required
- Hybrid connectivity
- How frequently the network changes
- How centralized you want network management to be
- Operational complexity
- Security requirements
- Cost
Two companies with exactly the same number of VPCs might still end up with completely different architectures.
One might have 50 isolated VPCs that barely communicate.
Another might have 50 VPCs spread across five Regions with shared services, centralized inspection, on-premises connectivity, and strict segmentation requirements.
Their networking requirements are completely different.
Final thoughts
One mistake I try to avoid is choosing the AWS networking service first and then designing the network around it.
I prefer doing the opposite.
Understand the requirements first.
Understand what needs to communicate.
Understand the scale.
Understand the security boundaries.
Then choose the service that makes those requirements easier to implement and operate.
Sometimes that will be VPC Peering.
Sometimes Transit Gateway.
Sometimes Cloud WAN.
And sometimes the right answer is a combination of them.
The goal is not to use the most advanced AWS networking service. The goal is to build the simplest network that still meets your requirements today and doesn’t become a problem tomorrow.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article