AWS Transit Gateway vs Azure Virtual WAN vs Google NCC

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-F

Building 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 D

AWS 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.

Why Cloud Networks Need Transit Architecture

A simple cloud environment might contain one virtual network:

Internet
   |
  VPC
   |
Application

As infrastructure grows, organizations often separate workloads into multiple networks:

Production
Development
Security
Management
Shared Services
Database

This 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 Database

The question becomes:

How should all these networks connect without creating an unmanageable mesh of point-to-point connections?

The Full-Mesh Problem

Imagine four networks.

A direct peering model could become:

        VPC-A
       /     \
    VPC-B---VPC-C
       \     /
        VPC-D

Add 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-D

Each 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 Networks

The implementation is software-defined, but the routing principles remain recognizable.

AWS Transit Gateway Architecture

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 Center

A Transit Gateway can have several attachment types, including:

• VPC attachments
• VPN connections
• Direct Connect gateway connectivity
• Transit Gateway peering
• Connect attachments for SD-WAN or third-party appliances

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.

AWS Transit Gateway Attachments

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 Gateway

The same general idea applies to other supported connectivity types.

The architecture therefore becomes:

VPC
 |
Attachment
 |
TGW
 |
Attachment
 |
VPN / another VPC / other supported connection

This separation is important because Transit Gateway routing decisions are closely tied to attachments and route tables.

AWS Transit Gateway 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 Attachment

AWS 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 Services

while:

Development
     |
Development TGW Route Table
     |
Shared Services

does not necessarily mean:

Development → Production

should also be allowed.

Transit route tables can therefore help create separate routing domains.

AWS Transit Gateway Segmentation Example

Suppose an organization has:

Production VPC
Development VPC
Management VPC
Shared Services VPC

The intended policy is:

Production → Shared Services

Development → Shared Services

Management → Production

Management → Development

but:

Development ✕ Production

A 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.

AWS Transit Gateway and Multiple Regions

Transit Gateway itself is regional.

Large AWS architectures may therefore use:

Region A
   |
Transit Gateway A
   |
Inter-Region Peering
   |
Transit Gateway B
   |
Region B

AWS 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.

Azure Virtual WAN Architecture

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 Center

Microsoft 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.

What Is an Azure Virtual Hub?

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 Center

Microsoft 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.

Azure Virtual WAN Across Regions

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 States

Microsoft 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 Center

This makes Virtual WAN particularly relevant to globally distributed enterprise networks.

Azure Virtual WAN and Hybrid Networking

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 connectivity

The hub becomes the common transit point.

For example:

Branch Office
     |
   VPN
     |
Virtual WAN Hub
   /        \
VNet       ExpressRoute
             |
        Data Center

This is not merely cloud-to-cloud networking.

It is a broader enterprise transit architecture.

Azure Virtual WAN and Centralized Security

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
    |
Destination

Microsoft’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-premises

traffic.

Google Network Connectivity Center Architecture

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 Spoke

NCC 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.

Google NCC VPC Connectivity

One important use case is connecting multiple VPC networks.

Conceptually:

VPC-A
  |
  |
NCC Hub
  |
  |
VPC-B

Google 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          VPC

The hub provides a central connectivity framework instead of requiring every network relationship to be managed independently.

Google NCC and Hybrid Connectivity

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 appliances

A hybrid topology could look like:

Data Center
    |
Cloud Interconnect
    |
Cloud Router
    |
NCC Hub
   /   \
VPC-A  VPC-B

Google 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.

Google NCC for Site-to-Site Connectivity

Another interesting NCC use case is connecting external sites.

Conceptually:

Branch A
   |
Hybrid Connectivity
   |
Google Cloud Network
   |
Hybrid Connectivity
   |
Branch B

Google 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.

AWS Transit Gateway vs Azure Virtual WAN vs Google NCC

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 Biggest Architectural Difference

The names can make the services appear interchangeable:

AWS Transit Gateway
Azure Virtual WAN
Google NCC

but their design emphasis differs.

AWS Transit Gateway

Think primarily:

Regional Layer-3 transit router
       ↓
Attachments
       ↓
Transit route tables

AWS explicitly describes Transit Gateway as a Regional virtual router.

Azure Virtual WAN

Think:

Microsoft-managed global transit architecture
       ↓
Regional virtual hubs
       ↓
VNet + VPN + ExpressRoute + branch connectivity

Microsoft emphasizes managed hub infrastructure and global transit between hubs.

Google NCC

Think:

Global connectivity management hub
       ↓
VPC and hybrid spokes
       ↓
Route exchange / enterprise connectivity

Google 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.

Hub-and-Spoke vs Full Mesh

The central reason these services exist becomes obvious when comparing network topology.

A direct mesh can look like:

A ----- B
|\     /|
| \   / |
|  \ /  |
|  / \  |
| /   \ |
|/     \|
C ----- D

A transit model becomes:

A       B
 \     /
  \   /
   HUB
  /   \
 /     \
C       D

Operationally, the second architecture creates a clear place for:

routing

segmentation

monitoring

hybrid connectivity

security inspection

But centralization also means the hub becomes an important part of capacity, availability, routing, and security planning.

Transit Does Not Automatically Mean Trust

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
Security

The desired connectivity might be:

Management → Production

Management → Development

Security → Production

Security → Development

while:

Development ✕ Production

remains isolated.

Transit architecture should therefore be designed together with:

• routing domains
• firewall policy
• security groups
• network ACLs
• cloud firewalls
• inspection appliances

Connectivity and authorization are separate decisions.

This same principle appears throughout our advanced nftables firewall architecture guide.

Centralized Inspection Architecture

Large environments frequently place security infrastructure near the transit layer.

Consider:

Application VPC
      |
Transit Layer
      |
Security Network
      |
Firewall
      |
Destination

This 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 costs

A 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.

Route Symmetry Matters in Cloud Networks

Suppose traffic follows:

Client VPC
    ↓
Transit Hub
    ↓
Firewall
    ↓
Server VPC

but the response follows:

Server VPC
    ↓
Transit Hub
    ↓
Client VPC

without 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.

Avoid Overlapping CIDR Blocks

Transit architecture becomes substantially harder when connected networks use overlapping IP ranges.

Imagine:

Production VPC
10.10.0.0/16

and:

Acquired Company Network
10.10.0.0/16

A router receiving traffic for:

10.10.20.50

cannot 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 architectures

but all add complexity.

A well-designed cloud environment should therefore begin with an enterprise-wide IP addressing strategy.

Hybrid Cloud Routing and BGP

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 Networks

BGP 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.

Route Propagation vs Static Routes

Cloud transit architectures frequently combine two route sources.

Static routing

An administrator explicitly defines:

Destination → Next Hop

Dynamic route propagation

Routes are learned through connectivity mechanisms or routing protocols.

Conceptually:

On-Premises
advertises
10.50.0.0/16
       ↓
Cloud Transit
       ↓
Cloud networks learn route

Dynamic 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.

Multicloud Transit Architecture

Organizations increasingly operate:

AWS
Azure
Google Cloud
On-Premises
Branch Offices

simultaneously.

A multicloud topology might look like:

                   Enterprise WAN
                  /      |       \
                AWS    Azure     GCP
                 |       |        |
               TGW     vWAN      NCC

Another 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 handling

across independent infrastructures.

For the broader architecture, see Cloud Network Architecture: AWS vs Azure vs Google Cloud.

When AWS Transit Gateway Makes Sense

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 transit

For example:

          Production
              |
Development --TGW-- Shared Services
              |
          Management
              |
              VPN
              |
          Data Center

The main value is creating a central Layer-3 transit architecture instead of managing a large number of individual network relationships.

When Azure Virtual WAN Makes Sense

Virtual WAN becomes particularly relevant when Azure networking includes a combination of:

many VNets

multiple regions

branch offices

remote users

VPN connectivity

ExpressRoute

centralized security

The 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.

When Google Network Connectivity Center Makes Sense

NCC becomes useful when Google Cloud environments need centralized connectivity between:

multiple VPCs

projects

organizations

on-premises networks

branch sites

other cloud networks

Google’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.

Do You Always Need a Transit Hub?

No.

A transit architecture adds another networking layer.

For a small environment containing:

one VPC
one application
one region

introducing 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 WAN

Do not deploy enterprise-scale network infrastructure merely because the provider offers it.

Troubleshooting Cloud Transit Networks

When connectivity fails across a transit architecture, use a layered workflow.

Start with the source.

Confirm its:

IP address
subnet
route table
security policy

Then follow the packet toward the transit layer.

Check:

attachment/spoke state

transit route table

route propagation

destination route

firewall policy

Then inspect the return path.

The workflow becomes:

SOURCE
  ↓
SOURCE ROUTE
  ↓
TRANSIT ATTACHMENT
  ↓
TRANSIT ROUTE
  ↓
SECURITY LAYER
  ↓
DESTINATION NETWORK
  ↓
DESTINATION
  ↓
RETURN ROUTE

Do not stop when you confirm that the forward path exists.

A working connection needs a valid return path too.

Transit Network Design Checklist

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.

Frequently Asked Questions

What is AWS Transit Gateway?

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.

What is Azure Virtual WAN?

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.

What is Google Network Connectivity Center?

Google NCC is a network connectivity orchestration framework built around a global hub and connected spokes, supporting VPC and hybrid connectivity scenarios.

Is Transit Gateway global?

AWS describes a Transit Gateway as a Regional virtual router. Transit Gateways in different regions can be connected through inter-Region peering.

Is Azure Virtual WAN global?

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.

Is Google NCC global?

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.

Does connecting networks to the same transit hub automatically make them trusted?

No. Routing connectivity and security authorization should be treated separately. Use route segmentation and appropriate cloud firewall/security controls according to the architecture.

Conclusion

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 Architecture

The 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.