On this page9 sections
Short answer
Should you use Azure hub-and-spoke or Virtual WAN, and how do you connect either to AWS?
Choose hub-and-spoke with your own hub virtual network when you want full control of routing and firewall appliances and have few branches. Choose Virtual WAN when many branches or regions need Microsoft-managed hubs. To reach an AWS transit gateway from either, plan an IPsec VPN with BGP, and settle the autonomous system numbers (ASNs) before you build.
Who this is for: architects who run, or are about to run, workloads in both AWS and Azure. It is based on Microsoft Learn and AWS documentation, with page dates in the sources.
How do the AWS and Azure building blocks line up?
Microsoft’s comparison of AWS and Azure networking maps the services below. Two differences matter for design. An AWS subnet sits in one Availability Zone, while an Azure subnet is regional and spans the zones. And neither platform allows transitive peering, so transitive routing needs a hub or a transit service.
| Function | AWS | Azure |
|---|---|---|
| Private network | VPC | Virtual network (VNet) |
| Central transit | Transit Gateway | Virtual WAN |
| Managed firewall | AWS Network Firewall | Azure Firewall |
| Dedicated connection | Direct Connect | ExpressRoute |
| IPsec VPN | Site-to-Site VPN | VPN Gateway |
| Route tables | Route tables | User-defined routes (UDRs) |
Microsoft’s mapping lists only Virtual WAN against Transit Gateway, and its design guide calls Virtual WAN Azure’s equivalent of AWS Transit Gateway. The other Azure option is a hub VNet you build and peer to, with gateways or network virtual appliances (NVAs) in the hub providing transit. Microsoft’s Cloud Adoption Framework covers landing zones built on either topology.
What is the difference between the two Azure topologies?
In hub-and-spoke, you build and run a hub VNet that holds shared services: a VPN or ExpressRoute gateway, Azure Firewall or another NVA, and DNS. Spoke VNets peer to the hub. Peering is nontransitive, so spoke-to-spoke traffic needs a route through a firewall or NVA in the hub, or a direct peering. For spokes to use the hub’s gateway, the hub peering allows gateway transit, each spoke peering uses the remote gateway, and all peerings allow forwarded traffic. A hub is regional, so each region gets its own.
In Virtual WAN, Microsoft manages the hub. Spokes attach through VNet connections, and the hub router handles routing. A hub can hold VPN and ExpressRoute gateways, and in a Standard Virtual WAN all hubs connect in a full mesh over the Microsoft backbone. A VNet connects to only one hub and cannot keep its own virtual network gateway. Microsoft calls Virtual WAN a scale alternative to hub-and-spoke, not a replacement.
The hub-and-spoke vs Virtual WAN decision table
The branch counts below are Microsoft’s rules of thumb; the connection and throughput figures are documented limits on the pages read.
| Factor | Hub-and-spoke (customer-managed hub) | Virtual WAN |
|---|---|---|
| Who runs the hub | You | Microsoft |
| Fit by scale | Up to about 30 VPN branch connections | 30 or more VPN branches, or many Azure regions |
| Routing | You configure UDRs for spoke-to-spoke traffic | Hub router propagates routes; custom route tables for isolation |
| Multiple regions | One hub per region; you build inter-region routing | Hubs interconnect automatically (Standard tier) |
| NVA control | Full: number of NICs, instances, and size | Supported NVA partners; check their features against your security requirements |
| Inspection | Azure Firewall or an NVA in your hub, steered with UDRs | Secured virtual hub with routing intent (Standard tier only) |
| SD-WAN | Manual NVA deployment | Native SD-WAN partner integration |
| Documented limits | Peerings per VNet are limited; see Azure networking limits | 1,000 site-to-site connections or 2,000 IPsec tunnels per hub; with routing intent, 600 address spaces across the VNets connected to one hub; 50 Gbps hub router at 50 routing infrastructure units |
| Costs to plan | Hub components billed separately (firewall, gateways) | Hub, routing infrastructure units, gateway scale units, data processing, and secured-hub firewall charges |
| Changing later | Move to Virtual WAN with a parallel run | Basic can be upgraded to Standard, not downgraded |
Microsoft’s design guide lists reasons to stay with hub-and-spoke: you need granular control of the hub VNet, you operate in a single region with fewer than 10 branches, or compliance requires customer-managed routing. It also says multiregion alone is not enough reason for Virtual WAN, since a dual hub-and-spoke often covers two regions.
Two cautions from the same guide. Virtual WAN does not import existing UDR configurations, so routing is redesigned, not copied. And removing routing intent does not restore the previous default route table, so save a copy of the configuration first. To migrate, Microsoft recommends running a Virtual WAN hub next to the old hub and moving spoke connections incrementally, validating routing after each one.
How do you connect either one to AWS Transit Gateway?
Both Azure topologies reach AWS the same way: a Site-to-Site VPN on the AWS side, attached to the transit gateway, and BGP over IPsec to Azure’s VPN gateway, in the hub for Virtual WAN or in the hub VNet for hub-and-spoke. Dedicated circuits (Direct Connect with ExpressRoute) are the alternative when bandwidth, latency, or compliance rules out the internet; this article covers the VPN.
Facts that shape the design:
- Four tunnels, not two. Each AWS Site-to-Site VPN connection has two tunnels with unique public IP addresses, and AWS says to configure both. Azure’s gateway is active-active, so Microsoft’s AWS walkthrough creates one AWS connection per Azure instance: four tunnels in total. That walkthrough uses Azure VPN Gateway; Microsoft publishes no Virtual WAN-to-AWS walkthrough, so validate the Virtual WAN mapping of sites, links, and tunnels in a lab.
- ASNs. The Amazon-side ASN is private: 64512 to 65534 for 16-bit ASNs, with 64512 as the default. Virtual WAN uses 65515 and does not support ASN changes for hubs or gateways. Azure reserves 65515 and 65517 to 65520, among others, and Microsoft lists the usable private ranges as 64512 to 65514 and 65521 to 65534. The two sides must use different ASNs.
- BGP addresses. Each AWS tunnel takes a /30 inside CIDR from 169.254.0.0/16, minus the blocks AWS reserves. Azure accepts custom APIPA BGP addresses in 169.254.21.* and 169.254.22.*, so place the /30s there. The BGP peer address cannot be the device’s public IP.
- Bandwidth. A standard AWS tunnel carries up to 1.25 Gbps; Large Bandwidth Tunnels carry up to 5 Gbps and are available only on connections attached to a transit gateway or Cloud WAN. On the Azure side, one Virtual WAN VPN scale unit is 500 Mbps per instance, and Microsoft lists a per-tunnel maximum of 2.3 Gbps, so plan equal-cost multipath (ECMP) across tunnels rather than one large tunnel.
- MTU. AWS Site-to-Site VPN supports an MTU of 1446 bytes and an MSS of 1406, lower with some algorithms, with no jumbo frames and no Path MTU Discovery. Microsoft recommends clamping TCP MSS to 1,350 bytes and a tunnel MTU of 1,400 on the Azure side.
- Overlap. The hub address range cannot overlap the VNets you connect or the on-premises ranges.
The AWS-to-Azure connectivity checklist
- Choose the transport: internet VPN, or Direct Connect with ExpressRoute. Write down why.
- Plan address space so that VPC, VNet, hub, and on-premises ranges do not overlap.
- Plan ASNs before creating either side: a 16-bit private Amazon-side ASN outside Azure’s reserved list, such as the default 64512, and Azure’s ASN (65515 in Virtual WAN) entered as the AWS customer gateway’s BGP ASN.
- Create the AWS side: customer gateways and VPN attachments on the transit gateway with dynamic routing. Keep VPN ECMP support enabled; for ECMP, the advertised ASN and BGP attributes such as the AS path must match.
- Set the AWS tunnel startup action. The default leaves initiation to the customer gateway; Microsoft’s walkthrough sets the AWS side to start the tunnel.
- Create the Azure side: for Virtual WAN, VPN sites and links for the AWS tunnels connected to the hub; for hub-and-spoke, a local network gateway and connection per AWS tunnel. Use the APIPA ranges above.
- Bring all four tunnels up, and confirm that BGP sessions are established on each.
- Check route propagation: transit gateway route table association and propagation, routes from VPC subnets to the transit gateway, and on Azure the hub routes or UDRs. In Virtual WAN, spoke subnets with a UDR table need gateway route propagation enabled.
- Check route quotas: AWS accepts up to 1,000 dynamic routes per VPN connection on a transit gateway and advertises up to 5,000; check the current Azure gateway limits for your design.
- Decide where inspection happens, so each flow is inspected once, by design.
- Test failure: take one tunnel down, then one gateway instance, and watch routes and sessions converge.
What this article has not tested
- Nothing here was built for this article. Statements are as documented by Microsoft and AWS on October 4, 2026, and figures change.
- Direct Connect with ExpressRoute designs, multi-region meshes across clouds, Virtual WAN with NVA partners, and Azure Virtual Network Manager are not covered.
FAQ
Is Azure Virtual WAN the same as AWS Transit Gateway?
Microsoft maps Virtual WAN to Transit Gateway as the managed central transit service, and its design guide calls Virtual WAN Azure’s equivalent. They are not identical: Virtual WAN adds Microsoft-managed hubs, native SD-WAN partner integration, and routing intent. A hub VNet that you build and peer to is the other Azure way to provide transit.
When is hub-and-spoke enough on Azure?
Microsoft’s guide suggests traditional hub-and-spoke for organizations with fewer than 30 branches, a single region, and a need for full control over hub resources. It also lists custom NVAs in the hub and compliance rules that require customer-managed routing as reasons to stay. A dual hub-and-spoke often covers two regions.
Can I change the Virtual WAN hub ASN?
No. Microsoft’s FAQ says Virtual WAN does not support ASN changes for virtual hubs or any gateways, and Microsoft’s site-to-site tutorial shows the AS number field as not editable. Virtual WAN uses 65515, so choose the AWS and on-premises ASNs around it and avoid every ASN that Azure reserves.
Which ASN should I use on the transit gateway when connecting to Azure?
A 16-bit private ASN that differs from Azure’s and is not on Azure’s reserved list. AWS’s default, 64512, qualifies, and Microsoft’s AWS walkthrough uses it. Avoid 65515 to 65520: they fall inside AWS’s 16-bit private range but outside the private ranges Microsoft lists as usable for remote BGP peers.
Should I use VPN or Direct Connect with ExpressRoute between AWS and Azure?
Start from bandwidth, latency, and compliance. An AWS blog post describes three patterns: Site-to-Site VPN over the internet, Direct Connect and ExpressRoute in infrastructure you manage, or both through a multicloud connectivity provider. The VPN is encrypted but crosses the public internet, with the per-tunnel limits above; the dedicated patterns do not use the internet path.
Sources
Checked against vendor documentation on How the articles are checked
- Azure Virtual WAN network topology (design guide, dated 2026-06-17)
- Hub-spoke network topology in Azure (Architecture Center, dated 2026-04-10)
- What is Azure Virtual WAN?
- Azure Virtual WAN FAQ (dated 2026-05-27)
- Tutorial: create a site-to-site connection using Azure Virtual WAN
- Connect a virtual network gateway to Virtual WAN (ASN 65515)
- How to connect AWS and Azure using a BGP-enabled VPN gateway (dated 2026-02-18)
- VPN Gateway FAQ, BGP and routing (reserved and usable ASNs)
- Compare AWS and Azure networking options
- Define an Azure network topology (Cloud Adoption Framework)
- TCP/IP performance tuning for Azure VMs (MSS and MTU)
- Create a transit gateway (Amazon-side ASN, VPN ECMP)
- How AWS Transit Gateway works (routing, ECMP)
- Site-to-Site VPN tunnels and Large Bandwidth Tunnels
- Tunnel options (inside CIDR, startup action)
- Site-to-Site VPN quotas (routes, bandwidth, MTU)
- Designing private network connectivity between AWS and Microsoft Azure (AWS blog, 2024-01-11)