As cloud environments grow, networking becomes less about connecting a single subnet to the internet and more about connecting dozens of virtual networks, multiple regions, branch offices, data centers, VPNs, and sometimes multiple cloud providers.
At small scale, direct connections between networks may be manageable. At enterprise scale, they quickly become difficult to operate.
Consider an environment containing six isolated networks:
VPC-A
VPC-B
VPC-C
VPC-D
VPC-E
VPC-FBuilding individual connections between every network creates an increasingly complex mesh.
Cloud providers therefore offer centralized connectivity architectures built around a common idea:
Network A
|
Network B ----- Transit Hub ----- Network C
|
Network DAWS provides Transit Gateway, Microsoft Azure provides Virtual WAN, and Google Cloud provides Network Connectivity Center (NCC).
They address overlapping networking problems, but they are not identical products.
This guide compares their architectures, routing models, hybrid connectivity options, segmentation capabilities, and practical use cases.
If you need the broader foundation first, read our Cloud Network Architecture: AWS vs Azure vs Google Cloud, which explains VPCs, VNets, provider backbone networks, hybrid connectivity, and multicloud networking.
A simple cloud environment might contain one virtual network:
Internet
|
VPC
|
ApplicationAs infrastructure grows, organizations often separate workloads into multiple networks:
Production
Development
Security
Management
Shared Services
DatabaseThis isolation has major security and operational benefits, but those networks still need controlled communication.
For example:
Production → Shared DNS
Development → Shared Services
Management → Production
Branch Office → Applications
Data Center → Cloud DatabaseThe question becomes:
How should all these networks connect without creating an unmanageable mesh of point-to-point connections?
Imagine four networks.
A direct peering model could become:
VPC-A
/ \
VPC-B---VPC-C
\ /
VPC-DAdd more networks and the number of relationships grows rapidly.
With ten or fifty networks, operating individual peerings, routes, VPNs, and security policies becomes much more difficult.
A centralized transit architecture changes the model:
VPC-A
|
VPC-B --- TRANSIT --- VPC-C
|
VPC-DEach network connects primarily to the transit layer.
That layer then determines how traffic moves between networks.
This is the cloud version of a familiar networking concept:
Access Networks
↓
Routing Core
↓
Other NetworksThe implementation is software-defined, but the routing principles remain recognizable.
AWS Transit Gateway is designed as a network transit hub connecting Amazon VPCs and external networks.
AWS describes a Transit Gateway as a Regional virtual router operating at Layer 3. Packets are forwarded toward attachments based on destination IP addresses.
A simplified architecture looks like:
Production VPC
|
|
Development VPC --+-- AWS Transit Gateway
|
|
Management VPC
|
|
Site-to-Site VPN
|
Data CenterA Transit Gateway can have several attachment types, including:
This means Transit Gateway can become the routing center of a relatively large AWS network.
The authoritative implementation details are maintained in the AWS Transit Gateway documentation. AWS documents Transit Gateway as a hub for interconnecting VPCs and on-premises networks.
The concept of an attachment is fundamental.
A VPC does not simply become part of the Transit Gateway automatically.
It is attached.
Conceptually:
VPC-A
|
Attachment
|
Transit GatewayThe same general idea applies to other supported connectivity types.
The architecture therefore becomes:
VPC
|
Attachment
|
TGW
|
Attachment
|
VPN / another VPC / other supported connectionThis separation is important because Transit Gateway routing decisions are closely tied to attachments and route tables.
Transit Gateway has its own routing layer.
This should not be confused with the route table inside an individual VPC.
Conceptually:
EC2 Instance
↓
VPC Route Table
↓
Transit Gateway
↓
TGW Route Table
↓
Destination AttachmentAWS documents that each VPC or VPN attachment is associated with a Transit Gateway route table.
This creates powerful segmentation possibilities.
For example:
Production
|
Production TGW Route Table
|
Shared Serviceswhile:
Development
|
Development TGW Route Table
|
Shared Servicesdoes not necessarily mean:
Development → Productionshould also be allowed.
Transit route tables can therefore help create separate routing domains.
Suppose an organization has:
Production VPC
Development VPC
Management VPC
Shared Services VPCThe intended policy is:
Production → Shared Services
Development → Shared Services
Management → Production
Management → Developmentbut:
Development ✕ ProductionA carefully designed Transit Gateway routing architecture can support that separation.
The key lesson is:
Connectivity to the same transit hub does not have to mean unrestricted connectivity between every attached network.
This is similar to traditional routing and firewall segmentation.
Our nftables Inter-VLAN Firewall guide demonstrates the same principle at the Linux network layer: routing capability and authorization policy are separate concerns.
Transit Gateway itself is regional.
Large AWS architectures may therefore use:
Region A
|
Transit Gateway A
|
Inter-Region Peering
|
Transit Gateway B
|
Region BAWS states that inter-Region peering can connect Transit Gateways using AWS global infrastructure.
This allows organizations to create regional transit architectures and then connect them.
That differs from assuming there is one unlimited global Transit Gateway containing every AWS region.
Microsoft approaches large-scale cloud transit through Azure Virtual WAN.
Virtual WAN brings together routing, connectivity, and security functions through Microsoft-managed virtual hubs.
A simplified architecture looks like:
Azure VNet
|
Azure VNet ---- Virtual WAN Hub ---- Branch
|
|
ExpressRoute
|
Data CenterMicrosoft describes Virtual WAN as a networking service combining multiple networking, security, and routing capabilities behind a common operational interface. Supported connectivity includes site-to-site VPN, point-to-site VPN, ExpressRoute, virtual networks, and other scenarios.
The hub is central to Virtual WAN.
A Virtual WAN hub is a Microsoft-managed virtual network.
Instead of building and operating every routing component manually, the customer connects networks and connectivity services to this managed hub.
Conceptually:
Branch
|
|
VNet A -------- Virtual Hub -------- VNet B
|
|
ExpressRoute
|
Data CenterMicrosoft handles much of the underlying hub infrastructure and routing.
This is one of the key differences between Virtual WAN and manually building your own hub VNet using network virtual appliances.
Virtual WAN becomes especially interesting in multi-region environments.
You can deploy hubs in multiple Azure regions:
Europe
|
Virtual Hub
|
Microsoft Backbone
|
Virtual Hub
|
United StatesMicrosoft documents that Standard Virtual WAN hubs can be interconnected in a full-mesh model, allowing traffic to use the Microsoft backbone for inter-hub connectivity.
The architecture can therefore expand into:
Europe Hub
/ \
VNets Branches
\
Microsoft
Backbone
|
US Hub
/ \
VNets Data CenterThis makes Virtual WAN particularly relevant to globally distributed enterprise networks.
Enterprise cloud networks often still depend heavily on physical data centers and branch offices.
Virtual WAN can aggregate connectivity from:
Azure VNets
Site-to-Site VPN
Point-to-Site VPN
ExpressRoute
SD-WAN / branch connectivityThe hub becomes the common transit point.
For example:
Branch Office
|
VPN
|
Virtual WAN Hub
/ \
VNet ExpressRoute
|
Data CenterThis is not merely cloud-to-cloud networking.
It is a broader enterprise transit architecture.
Transit and security are closely related.
Instead of allowing every spoke to independently reach every destination, traffic can be directed through centralized inspection infrastructure.
A common design is:
Spoke VNet
|
Virtual WAN Hub
|
Azure Firewall
|
DestinationMicrosoft’s documented hub-and-spoke Virtual WAN architecture supports secured hubs and centralized policy using Azure Firewall.
This is useful when organizations want consistent inspection across:
spoke-to-spoke
spoke-to-internet
branch-to-cloud
cloud-to-on-premisestraffic.
Google Cloud’s Network Connectivity Center takes another approach to centralized network connectivity.
Google describes NCC as an orchestration framework built around a central management resource called a hub with connected spokes.
The high-level architecture is:
VPC A
|
|
On-Prem ------ NCC Hub ------ VPC B
|
|
Hybrid SpokeNCC supports several spoke types, including VPC and hybrid connectivity scenarios.
The official Google Network Connectivity Center documentation describes the current hub-and-spoke model and supported resources.
One important use case is connecting multiple VPC networks.
Conceptually:
VPC-A
|
|
NCC Hub
|
|
VPC-BGoogle documents that VPC spokes can exchange subnet routes through an NCC hub.
This is useful when organizations deliberately separate workloads into multiple VPC networks but still require controlled connectivity between them.
For example:
Production VPC
|
|
NCC Hub
/ \
Security Shared Services
VPC VPCThe hub provides a central connectivity framework instead of requiring every network relationship to be managed independently.
NCC is not limited to VPC-to-VPC networking.
Hybrid spokes can participate in architectures connecting Google Cloud to external networks.
This may involve technologies such as:
Cloud VPN
Cloud Interconnect
Router appliancesA hybrid topology could look like:
Data Center
|
Cloud Interconnect
|
Cloud Router
|
NCC Hub
/ \
VPC-A VPC-BGoogle documents NCC scenarios for connecting VPC networks with on-premises networks and other cloud environments.
This makes NCC relevant not only to cloud networking but also to enterprise WAN design.
Another interesting NCC use case is connecting external sites.
Conceptually:
Branch A
|
Hybrid Connectivity
|
Google Cloud Network
|
Hybrid Connectivity
|
Branch BGoogle documents site-to-site data transfer scenarios in which its cloud networking infrastructure participates in connectivity between external sites.
This expands the role of the cloud provider from hosting applications to participating in the enterprise WAN architecture.
At a high level, the three technologies address similar architectural pressures.
| Capability | AWS Transit Gateway | Azure Virtual WAN | Google NCC |
|---|---|---|---|
| Central hub architecture | Yes | Yes | Yes |
| Connect cloud virtual networks | VPC attachments | VNet connections | VPC spokes |
| Hybrid networking | Yes | Yes | Yes |
| VPN integration | Yes | Yes | Yes |
| Dedicated connectivity integration | Direct Connect-related architecture | ExpressRoute | Cloud Interconnect |
| Multi-region design | TGW peering | Multiple connected virtual hubs | Global NCC hub with regional resources |
| Routing segmentation | TGW route tables | Virtual hub routing/route tables | Route exchange and topology controls |
| Branch connectivity | VPN / Connect | Strong Virtual WAN focus | Hybrid spokes |
| Centralized security integration | Security VPC / appliance patterns | Azure Firewall / NVAs | Security and appliance patterns |
This table should be treated as an architectural summary rather than a feature-by-feature purchasing comparison because individual capabilities, quotas, routing behavior, and pricing can change.
Always verify implementation details in the provider’s current documentation.
The names can make the services appear interchangeable:
AWS Transit Gateway
Azure Virtual WAN
Google NCCbut their design emphasis differs.
Think primarily:
Regional Layer-3 transit router
↓
Attachments
↓
Transit route tablesAWS explicitly describes Transit Gateway as a Regional virtual router.
Think:
Microsoft-managed global transit architecture
↓
Regional virtual hubs
↓
VNet + VPN + ExpressRoute + branch connectivityMicrosoft emphasizes managed hub infrastructure and global transit between hubs.
Think:
Global connectivity management hub
↓
VPC and hybrid spokes
↓
Route exchange / enterprise connectivityGoogle describes the NCC hub itself as a global resource that can contain spokes from multiple regions.
Understanding these architectural differences is more useful than treating all three services as identical products with different names.
The central reason these services exist becomes obvious when comparing network topology.
A direct mesh can look like:
A ----- B
|\ /|
| \ / |
| \ / |
| / \ |
| / \ |
|/ \|
C ----- DA transit model becomes:
A B
\ /
\ /
HUB
/ \
/ \
C DOperationally, the second architecture creates a clear place for:
routing
segmentation
monitoring
hybrid connectivity
security inspectionBut centralization also means the hub becomes an important part of capacity, availability, routing, and security planning.
A common architecture mistake is assuming:
If two networks connect to the same transit hub, they should communicate freely.
That defeats much of the reason for separating networks.
Imagine:
Production
Development
Management
SecurityThe desired connectivity might be:
Management → Production
Management → Development
Security → Production
Security → Developmentwhile:
Development ✕ Productionremains isolated.
Transit architecture should therefore be designed together with:
Connectivity and authorization are separate decisions.
This same principle appears throughout our advanced nftables firewall architecture guide.
Large environments frequently place security infrastructure near the transit layer.
Consider:
Application VPC
|
Transit Layer
|
Security Network
|
Firewall
|
DestinationThis can provide centralized inspection for traffic between environments.
However, the design must account for:
route symmetry
firewall state
throughput
failure domains
availability zones
cross-region traffic
network costsA stateful firewall usually expects to see both directions of a connection.
If traffic reaches the firewall on one path but returns through another, stateful inspection can fail.
The underlying principle is similar to the Linux networking behavior explained in Linux rp_filter and Asymmetric Routing.
Suppose traffic follows:
Client VPC
↓
Transit Hub
↓
Firewall
↓
Server VPCbut the response follows:
Server VPC
↓
Transit Hub
↓
Client VPCwithout returning through the same stateful inspection path.
Depending on the architecture and firewall implementation, this can break the connection or bypass intended inspection.
Before troubleshooting the application, verify the actual route in both directions.
Traditional routing knowledge therefore remains highly relevant in cloud environments.
Our Linux Policy Routing with ip rule and Multiple Routing Tables guide provides a useful foundation for understanding why routing decisions can differ based on policy rather than only destination.
Transit architecture becomes substantially harder when connected networks use overlapping IP ranges.
Imagine:
Production VPC
10.10.0.0/16and:
Acquired Company Network
10.10.0.0/16A router receiving traffic for:
10.10.20.50cannot determine the intended destination simply from the address if both networks advertise overlapping space into the same routing context.
Solutions may involve:
renumbering
NAT
isolated routing domains
specialized network appliances
proxy architecturesbut all add complexity.
A well-designed cloud environment should therefore begin with an enterprise-wide IP addressing strategy.
Connecting physical infrastructure to cloud transit often introduces Border Gateway Protocol (BGP).
The architecture can become:
On-Prem Router
|
BGP
|
Dedicated / VPN Connectivity
|
Cloud Transit
|
Cloud NetworksBGP allows routes to be exchanged dynamically rather than configuring every destination manually.
For example, AWS documents BGP route propagation for VPN and Direct Connect-related Transit Gateway connectivity.
Azure ExpressRoute and Google Cloud Router-based hybrid architectures similarly rely heavily on dynamic routing concepts.
This is why BGP remains one of the most valuable networking skills for cloud engineers.
Cloud transit architectures frequently combine two route sources.
An administrator explicitly defines:
Destination → Next HopRoutes are learned through connectivity mechanisms or routing protocols.
Conceptually:
On-Premises
advertises
10.50.0.0/16
↓
Cloud Transit
↓
Cloud networks learn routeDynamic routing reduces manual configuration, but it also means engineers must understand where a route originated and where it propagates.
When troubleshooting, ask:
Where was this prefix learned?
Which route table contains it?
Which networks receive it?
Which route wins?
What is the return path?These questions are often more useful than immediately changing firewall rules.
Organizations increasingly operate:
AWS
Azure
Google Cloud
On-Premises
Branch Officessimultaneously.
A multicloud topology might look like:
Enterprise WAN
/ | \
AWS Azure GCP
| | |
TGW vWAN NCCAnother design may use dedicated cloud-to-cloud connectivity or a third-party networking platform.
The technical challenge is not simply connecting everything.
It is creating predictable:
routing
segmentation
DNS
security
observability
failure handlingacross independent infrastructures.
For the broader architecture, see Cloud Network Architecture: AWS vs Azure vs Google Cloud.
Transit Gateway becomes particularly useful when an AWS environment grows beyond a few independently connected VPCs.
Typical scenarios include:
many VPCs
multiple AWS accounts
shared services
centralized security
hybrid connectivity
regional transitFor example:
Production
|
Development --TGW-- Shared Services
|
Management
|
VPN
|
Data CenterThe main value is creating a central Layer-3 transit architecture instead of managing a large number of individual network relationships.
Virtual WAN becomes particularly relevant when Azure networking includes a combination of:
many VNets
multiple regions
branch offices
remote users
VPN connectivity
ExpressRoute
centralized securityThe architecture is especially compelling when an organization wants Microsoft-managed hubs rather than operating its own transit VNets and routing appliances.
Microsoft’s current documentation describes Virtual WAN as combining networking, routing, and security capabilities in a managed architecture.
NCC becomes useful when Google Cloud environments need centralized connectivity between:
multiple VPCs
projects
organizations
on-premises networks
branch sites
other cloud networksGoogle’s documentation specifically describes VPC-to-VPC, site-to-cloud, and site-to-site connectivity scenarios through NCC.
For organizations already using Google Cloud’s global networking model, NCC provides a central framework for organizing these relationships.
No.
A transit architecture adds another networking layer.
For a small environment containing:
one VPC
one application
one regionintroducing a sophisticated transit architecture may add unnecessary complexity and cost.
Architecture should grow with requirements.
A useful progression is:
Single Network
↓
Few Networks
↓
Direct Connectivity
↓
Growing Environment
↓
Central Transit
↓
Multi-Region Transit
↓
Hybrid / Multicloud WANDo not deploy enterprise-scale network infrastructure merely because the provider offers it.
When connectivity fails across a transit architecture, use a layered workflow.
Start with the source.
Confirm its:
IP address
subnet
route table
security policyThen follow the packet toward the transit layer.
Check:
attachment/spoke state
transit route table
route propagation
destination route
firewall policyThen inspect the return path.
The workflow becomes:
SOURCE
↓
SOURCE ROUTE
↓
TRANSIT ATTACHMENT
↓
TRANSIT ROUTE
↓
SECURITY LAYER
↓
DESTINATION NETWORK
↓
DESTINATION
↓
RETURN ROUTEDo not stop when you confirm that the forward path exists.
A working connection needs a valid return path too.
Before deploying a large cloud transit architecture, verify:
□ IP ranges do not overlap unnecessarily.
□ Production and development routing domains are intentional.
□ Shared services have clearly defined access policies.
□ Management networks are isolated.
□ Hybrid routes are documented.
□ Route propagation is understood.
□ Static routes have clear ownership.
□ BGP advertisements are controlled.
□ Return paths are predictable.
□ Stateful firewalls receive symmetric traffic.
□ Multi-region failure behavior is understood.
□ DNS architecture matches network segmentation.
□ Transit throughput requirements are known.
□ Logging and flow visibility are enabled.
□ IPv6 requirements have been considered.
□ Disaster recovery routing has been tested.The transit hub should simplify the network—not become an undocumented black box in the middle of it.
AWS Transit Gateway is a Regional Layer-3 transit service used to connect VPCs and on-premises networks through attachments and Transit Gateway route tables.
Azure Virtual WAN is a Microsoft-managed networking service that combines connectivity, routing, and security capabilities using regional virtual hubs and can provide global transit between those hubs.
Google NCC is a network connectivity orchestration framework built around a global hub and connected spokes, supporting VPC and hybrid connectivity scenarios.
AWS describes a Transit Gateway as a Regional virtual router. Transit Gateways in different regions can be connected through inter-Region peering.
A Virtual WAN can contain virtual hubs in multiple regions. In Standard Virtual WAN, Microsoft provides inter-hub connectivity over its backbone for global transit scenarios.
Google documents an NCC hub as a global resource, although the resources associated with its spokes can have their own regional or service-specific characteristics.
No. Routing connectivity and security authorization should be treated separately. Use route segmentation and appropriate cloud firewall/security controls according to the architecture.
AWS Transit Gateway, Azure Virtual WAN, and Google Network Connectivity Center solve a problem that appears as cloud infrastructure grows:
How do you connect many networks without turning the environment into an unmanageable mesh?
AWS approaches the problem with a Regional Layer-3 Transit Gateway, attachments, and transit route tables.
Azure Virtual WAN uses Microsoft-managed regional hubs that combine cloud, branch, VPN, ExpressRoute, routing, and global transit capabilities.
Google Network Connectivity Center uses a global hub-and-spoke connectivity framework for connecting VPC and hybrid network resources.
The common architectural evolution is:
Independent Networks
↓
Point-to-Point Connections
↓
Growing Complexity
↓
Central Transit
↓
Routing Segmentation
↓
Hybrid Connectivity
↓
Multi-Region Networking
↓
Global / Multicloud ArchitectureThe most important design principle is not which product name appears in the diagram.
It is whether the architecture provides predictable routing, controlled segmentation, symmetric traffic paths, centralized visibility, and clear failure behavior.
For the broader provider networking architecture behind these services, read Cloud Network Architecture: AWS vs Azure vs Google Cloud.
For routing fundamentals, continue with Linux Policy Routing with ip rule and Multiple Routing Tables and Linux Traffic Uses the Wrong Interface.
For asymmetric stateful paths, use Linux rp_filter and Asymmetric Routing.
And for the security architecture behind segmented routed networks, see Advanced nftables Firewall Architecture.
Together, these articles create a bridge between traditional Linux networking and modern enterprise cloud networking—exactly where cloud network engineering becomes most valuable.
AI Agents as Code: Managing AI Agent Configurations, Prompts and Tools with Git AI agents…
Data Center Power Distribution Architecture: UPS, PDU, Redundancy and Rack Power Explained Data center power…
DNSSEC Troubleshooting: Fix SERVFAIL & DNSKEY Errors DNSSEC Troubleshooting: How to Fix SERVFAIL, DS, DNSKEY…
Terraform State Management Explained: Remote State, Locking, Backends and Best Practices Terraform makes infrastructure reproducible…
RTO vs RPO Explained: Disaster Recovery Objectives, Examples and Planning A disaster recovery plan is…
Network Intrusion Detection Explained: NIDS, Sensors, Signatures and Traffic Analysis A firewall can decide whether…