Azure Network Topology and Architecture

When implementing cloud technology, it’s essential to pay close attention to the design of the networking topology. In this blog post, we will delve into the Azure networking topology and architecture, specifically examining two crucial methods. We will go over the design recommendations and limitations of Azure Hub and Spoke, and Azure Virtual WAN.

Azure Hub and Spoke Architecture:

In the Azure cloud, Hub is a virtual network (VNet) that is a central connectivity point to the other networks, including other VNets and on-premise. The spokes are VNets that connect with the Hub and can be utilized to separate workloads. The Hub/Spoke design consists of a hub located on the top, with all other VNets peered with the Hub VNet, regardless of whether they are in the same or different subscriptions. The firewalls placed in the Hub are responsible for safeguarding the traffic of the virtual networks. Regarding architectural patterns, there’s no difference in using ExpressRoute in a hub-spoke topology. This technology provides connectivity between the Hub and the on-premises network and works more efficiently when there’s a high amount of data ingress and egress.

Within the Hub VNet, we can centralize all necessary shared services (Identity, DNS, Endpoint protection, and other tools). With Spoke traffic routing now being directed through the Hub firewall via UDRs, all traffic entering and exiting the spokes must pass through the firewall for inspection before continuing. To enhance security within the destination subnet, NIC-based NSGs or application security groups can be utilized to safeguard individual servers from East-West attacks.

To ensure proper network traffic flow, each spoke VNet must have a route table with a single route directing traffic to the Firewall in the Hub. It’s essential to turn off gateway propagation in this route table.

When to use Hub and Spoke Architecture:

• While using a single Azure region, then it’s recommended to implement a hub and spoke architecture is recommended.
• It is recommended when there is no requirement for transitive connectivity between virtual networks for landing zones across areas with the Azure network architecture covering multiple regions.
• Recommend using Azure Route Server for network transitivity between ExpressRoute and VPN gateways while aligning with a single region and without vWAN.
• It is recommended for a smaller number of VPN connections.

Limitations:

• The maximum number of virtual network peering connections allowed for each virtual network?
• ExpressRoute, with private peering, can advertise a maximum number of prefixes from Azure to on-premises.
• As of this writing, according to Azure Networking Limits, there is a limit of 400 routes for route tables. Azure Networking limitations.

Azure Virtual WAN Architecture:

The Azure Virtual WAN service combines various networking, security, and routing features into a single interface. The architecture follows a hub and spoke model that can easily handle branches, users, ExpressRoute circuits, and virtual networks. The ‘hub’ can connect endpoints in different ‘spokes’ across the cloud by establishing a global transit network. The spokes are VNets, On-premise, a remote site with VPN.

The vWAN hub, managed by Microsoft, is a cloud-hosted network with various service endpoints for seamless connectivity. On-premises networks (VPN sites) can effortlessly connect to a VPN gateway within the virtual Hub, while ExpressRoute circuits can be linked to the Hub for enhanced connectivity. Additionally, mobile users can connect to a point-to-site gateway within the Hub.

If a global enterprise customer has multiple hubs for accessing the cloud, they can connect to the hub closest to their physical location and users. When multiple hubs are enabled in a single virtual WAN, they are automatically interconnected via hub-to-hub links. This enables global connectivity between branches and Vnets that are distributed across multiple regions. Furthermore, hubs that are all part of the same virtual WAN can have different regional access and security policies associated with them.

To ensure efficient functioning, it is recommended to set up essential shared services such as DNS, Domain controller servers in a separate virtual network. Deploying customer resources within the Virtual WAN hub is not possible due to its unique network topology. To secure the vWAN hub, you can either use an Azure firewall or a third-party NG Firewall appliance.

When to use Hub and Spoke Architecture:

• This is recommended for facilitating a vast number of VPN connections with Azure.
• This is recommended for achieving transitive connectivity across multiple virtual networks.
• This solution is recommended for connecting multiple on-premises and Azure, allowing for an “any-to-any” connection.
• For more excellent combined data transfer capabilities when connecting with Azure, it is recommended to use this option.
• The Virtual WAN’s user VPN gateways (point-to-site) have the ability to scale up to 20 Gbps of aggregate throughput and can accommodate up to 100,000 client connections per virtual hub.
• The Virtual WAN’s site-to-site VPN gateways can handle an aggregate throughput of up to 20 Gbps.

Limitations:

• Azure Virtual WAN is bound by Azure subscription limits for Virtual WAN.
• A single Azure Virtual WAN hub supports a specific maximum number of VM workloads across all directly attached VNets. 
• It is not possible to establish over 500 virtual network connections for a single Virtual WAN virtual hub.

I suggest looking into vWAN for your network setup, as it can greatly simplify the Hub and spoke configuration. This is particularly advantageous as your network expands, with increased communication between regions and on-premises. Using vWAN can reduce your workload in terms of management and maintenance.

If you want to set up an extensive or global network in Azure, Microsoft suggests using Virtual WAN. This will provide global transit connectivity across Azure regions and on-premises locations without requiring you to set up transitive routing for Azure networking manually.