Part 4: VNET, Subnet and Peerings

Scenario: Building a demo or proof of concept to understand the technology, azure resources and configuration settings that involve Azure Virtual Networks, VNet Peerings, Virtual Network Gateway, and Site to Site VPN Connections. The architecture is to emulate a hybrid cloud topology with on-premises network emulated with an Azure VNETs in a hub and spoke network topology.

My Azure CLI script to build most of this network architecture can be found at https://github.com/RoyKimYYZ/azurehubandspokenetworkpoc/blob/main/create-hubandspokenetwork.azcli

VNET, Subnet and Network Peerings Design

This design composes of 3 VNets. The hub VNet serves as the centralized communication point to host shared services and support inbound and outbound traffic to the virtual network. The hub VNet in my design would be treated as a production environment. Having another hub VNet for in a devtest environment would be difficult to manage and expensive. The uses cases in a hub VNet are hard to emulate completely in a devtest environment. You can have a devtest but the use cases are limited and can still help experimenting. In my design, have the following subnets

• Gateway subnet – this is to serve the virtual network gateway for hybrid cloud use cases. This can be used for your on-premises network and other cloud such as AWS or GCP. In my script and architecture, I have an Azure virtual network that emulates the on-premises network and there is a site to site VPN connection by using the virtual network gateway.
• Management subnet – this is to server any jump box servers for administration purposes. A jump box server can be used to remote connect into the network and from within this server, connect and do administration to other servers in the network.
• Firewall subnet – this is to serve the option of having Azure Firewall service. This is a managed Azure service that supports network security for inbound and outbound traffic.
• WAF subnet – this is to serve the option of having an Azure application gateway with the web application firewall for layer 7 traffic filtering and monitoring.
• Workload subnet – this is to serve any general workloads as a shared service to other services. This can be a domain controller, DNS server, mail server, print server or any other type of proxy server. One can add more subnets and name them appropriately for the type of servers it will serve.
  

The spoke VNets in my design are Prod and DevTest Vnets. Spoke VNets are to connect to the Hub Vnet only. There shouldn’t be another layer of Vnets connecting to each spoke VNet forming a multi-layer tree pattern. Spoke VNets have the design goals of providing network isolation and management.

Prod VNet – This is to serve production workloads. You can have subnets named by a type of workloads or specific to an application. You can further isolate traffic between subnets with network security groups to allow and deny traffic based on source and target address spaces.

DevTest VNet – This is to serve non production workloads for development and testing. By default the spoke VNets do not have any network traffic communication with each other. So it is appropriate that the DevTest and Prod VNet do not have any connectivity with each other for security reasons. You can create various subnets to organize resources and define security boundaries.

The Hub and Spoke topology is extendable by adding more VNets to the Hub Vnet has needed.

Network Peerings provide connectivity between VNets in either one direction or two directions. In my design, I have two peerings between the Hub VNet and the 2 Spoke VNets. The peerings are bi-directional so that there is traffic going both ways. The peerings also support the use of the Virtual network gateway in the Hub VNet so that the Spoke VNet can connect to resources and servers in the on-premises network and vice versa.

You can read Microsoft documentation Hub-spoke network topology in Azure for further understanding of concepts.

Read further for the Network Security Best Practices in part 5.