When you decide to adopt Azure or any other cloud technologies for your company’s infrastructure, the first and the most important factor that you need to consider is a good flexible architecture that is going to host your Infrastructure. Infrastructure design depends on many factors like your company’s strategy, roadmap, budget, security, governance, locations, devops practice, applications (going to be hosted on IaaS/PaaS/SaaS), network, storage, backup, monitor, disaster recovery, sla etc. etc. 

Some examples for the above listed factors: 

1. Strategical decisions: Whether to have all the servers, applications, storage on the cloud or some will be in on premises and some on cloud with a hybrid connectivity? Whether you will be modernizing your legacy applications?  

2. Roadmap decisions: Support? Flexibility? Availability? Scalability? 

3. Budget decisions: Whether to reduce the OPEX and CAPEX? Licensing benefits?  

4. Security decisions: How do you like to have your identity managed? Whether to use RBAC? How do you like to encrypt data during transit or at rest? 

5. Network decisions: Whether to utilize a physical NVA appliance (NGFW) or Azure Firewall for firewall? Azure WAF or Azure Front door or Application Gateway for web firewall which comes as a service? Which all ports you like to expose to internet? 

6. Governance decisions: How to organize resources? Do you need Management groups? Whether the data should be replicated to other regions in case of a disaster recovery? Do you want to follow any naming convention for the resources? 

7. Applications: Whether to lift and shift legacy applications to IaaS or Modernize those applications using PaaS or migrate to SaaS? 

8. Disaster recovery (DR): Whether you need a flexible DR requirement? In another location? 

9. Monitor decisions: Would you like to monitor all the workloads? Do you want to get alerts? To take corrective actions. 

Azure Network Topologies 

In Azure we can have different kinds of network topologies. 

1. Flat topology where all the resources are deployed in a single virtual network. This type of topology is relatively easy to design however the more resources are added to the network, chances of performance problems are likely to happen.  

2. Mesh topology where the resources are deployed in multiple virtual networks and network peering is established between these virtual networks directly to each other. Since all the nodes in the network are interconnected, network traffic is fast and can be easily redirected as needed. Disadvantage of a mesh topology includes that it requires many connections, making it costlier to operate and manage than other network topologies. 

3. Hub and spoke topology (also known as Star topology) where one or more spoke networks connect to a hub virtual network using network peering. Hub often contains shared resources (Firewall, Monitoring, DNS, AD DS, NTP, File Server, KMS, Jump Boxes etc.) which will be utilized by the resources (Web server, Database server, App services etc.) in the spokes and the traffic between the spokes are often controlled through the hub. In this model, we can easily add and remove spokes without any impacts on the rest of the network, thus giving us greater flexibility. 

Larger companies which cannot afford incase if the central hub fails need to plan for multiple hubs, preferably based on locations or based on the type of workloads (Production and Non-Production). Ideally for hub-to-hub connectivity, VNet peering is used if the hubs are in the same region and if they are in multiple regions, Global VNet peering need to be established. 

In this article we’re going to create a single hub and multi spoke reference architecture using three different Azure Subscriptions. 

The main components that are in this architecture: 

1. Management groups 

2. Resource groups  

3. Virtual networks and Subnets 

4. Virtual network peering 

5. Custom routing rules 

6. Virtual machine workloads 

7. Network security groups (NSG) 

8. Application security groups (ASG) 

Management groups 

If we have got multiple Azure subscriptions and want to manage all those subscriptions in a consistent way and apply policies and role-based access controls, then the best approach is to keep these subscriptions in a management group. 

We will be creating three management groups for the reference architecture, one for the hub, another one for the production spoke and a third one for the development and staging spokes. 

Azure Subscriptions  

A subscription in Azure is an agreement with Microsoft which is required to provision resources (Virtual machines (VMs), Virtual network, Storage etc.) in Microsoft Azure. A subscription be considered as a billing unit. The consumption of the resources provisioned in a Azure subscription will reflect in the subscription bill. 

We will be using three subscriptions for the reference architecture, one for the hub subscription, another one for the production spoke subscription and a third one for the development and staging (non-production) spoke subscriptions. 

Resource groups 

A Resource group (RG) is a container that holds resources in Azure. Usually, RG can hold the resources together that are created as a result of a deployment like a virtual machine, app service, storage account etc. or we can decide how we want to group the related resources in a resource group that makes the most sense for our organization. 

We will be creating three resource groups for the reference architecture, one for the hub resources another one for the production spoke resources and a third one for the development and staging spoke resources. 

Virtual networks & Subnets 

The Virtual Network service enables us to connect resources in Azure to each other with virtual networks (VNets). It is kind of a LAN and can be seen as a logical isolation representation within a subscription. 

We will be creating 4 Virtual networks for the reference architecture, one for the hub Virtual network another one for the production spoke Virtual network and one Virtual network each for the development and staging spokes. 

In the Hub virtual network, we will have subnets for VPN gateway, Firewall, Application gateway and Bastion. 

In the Production spoke virtual network, we will have 2 subnets. Each subnet is designed to host production web servers (frontend facing internet) and production application and database servers (the backends which are not exposed to internet). 

We will be also creating two subnets each for the spoke (Staging and Development virtual networks) virtual networks. One subnet for the web tier and a second one for the backend tier which consists of Application and Database servers. 

Virtual network peering  

Network peering in Azure uses the Microsoft backbone infrastructure to establish a connection between two virtual networks, and traffic is routed through private IP addresses only.  

The hub subscription will have virtual network peering with the production virtual network spoke as well as with staging and development virtual network spokes. There is no direct virtual network peering between the spokes, as we want the spoke-to-spoke traffic to go via the hub network. This way the spokes can utilize the services of the shared resources in the hub. 

Peering Name	Description
LinkHubToProduction	Peer Hub to Production Spoke
LinkProductionToHub	Peer Production Spoke to Hub
LinkHubToStaging	Peer Hub to Staging Spoke
LinkStagingToHub	Peer Staging Spoke to Hub
LinkHubToDevelopment	Peer Hub to Development Spoke
LinkDevelopmentToHub	Peer Development Spoke to Hub

Points to be noted while performing the VNet peering.  

• To allow forwarded traffic while making peering connections. 
• To allow gateway transit while peering connection in the hub. 

• To use remote gateways while peering connection in each spoke. 

Network Security Group  

A Network Security Group (NSG) is an OSI layer 3 & 4 basic network filter/firewall that allows us to restrict access to resources within a virtual network, usually associated with Subnets or NIC’s. 

NSG has Inbound Security Rules as well as Outbound Security Rules. Using these rules, we can specify inbound traffic and outbound traffic rules with source, destination, port and action to allow or deny. 

Application Security Group 

Application Security Group (ASG) helps us to manage more specific security of Virtual Machines by grouping them according to the applications that run on them. We can see ASGs as an application centric use of NSGs. 

Combining NSG and ASG 

In some cases, the subnet design is very complex which makes it difficult to document and troubleshoot NSG rules. In such scenarios, using ASGs will reduce the number of subnets and make it easier to troubleshoot in case of any issues. 

For example, take the example of a three-tier application consisting of a web server, application server and database server. Here web server can be isolated in its own subnet because it is directly connected to the Internet. An NSG can be configured in this subnet to allow web traffic into the web server.  

For the application server and database server, we can define an NSG in the subnet along with two ASGs, one that allows the application traffic into the Application server from the web server subnet and another ASG that allows the application traffic into the Database server from the Application server. 

Bastion 

Bastion is a service that provides secure RDP/SSH connectivity to the VMs from the Azure portal over SSL. By using Bastion, VMs don’t need to have public IP for managing them remotely over the internet.  

Azure Bastion is deployed inside a virtual network with a dedicated subnet and supports virtual network peering.  

There are many advantages of using Bastion over a Jump box server, however there are cases where you need to have jump box server when you need to work on specific tools installed on the jump box server. 

Here will create an Azure Bastion host on the Hub subscription.  

Private endpoint  

Private Endpoint allows us to use a private IP address from the virtual network to privately access Azure PaaS services such as Storage account, Cosmos DB, Key vault etc. which are normally accessible via public IP address. 

This way the traffic stays within the Azure backbone instead of the internet. 

VPN Gateway  

Normally VPN Gateway is used when we have a requirement to connect the Azure virtual networks to the on-premises network. VPN gateway supports both Policy based and Route based connection. Route based support multiple sites connection to single Azure VPN Gateway while policy-based supports one connection per VPN Gateway. VPN gateway also supports Site to Site (S2S), Multi-Site, Point to Site (P2S), Virtual Network to Virtual Network and Express Route connections. 

We will be creating a VPN gateway with a dedicated gateway subnet 

Application gateway 

Application gateway is a Web load balancer which can also act as a Layer 7 Web Application Firewall to secure inbound web traffic. OWASP standards are supported in Azure WAF. 

Azure Firewall 

Azure Firewall is a fully managed, stateful firewall solution filters both inbound and outbound traffic between virtual networks and internet. 

In our reference architecture, there is no direct communication between the spokes and spoke to spoke communication should happen through Azure Firewall with the help of User Defined Routes (UDR). 

User Defined Routes 

User Defined Routes (UDR) are required to manually direct traffic to Azure Firewall to allow/route/deny/block traffic between Hub to Spokes, Spokes to Hub and Spoke to Spoke connectivity. 

UDRs are also required as VNets are non-transitive, as one spoke cannot carry traffic to another spoke through an intermediate spoke via the Hub natively. Azure Firewall is needed to facilitate this functionality and this approach is only required if you have a requirement for every packet to be inspected. 

We could avoid UDRs and rely on the built in System Route Tables if all the Spoke VNets are peered and all the subnets are allowed to talk to each other. However, this approach is not ideally recommended. 

Table Name: Production Spoke Table 

Route Name	Address Space	Next Hop Type	Next Hop Address	Description
ProductionToAzFwUdr	10.10.0.0/19	VirtualAppliance	10.10.10.4	All the Outbound flow from Production Spoke should go to Firewall

Table Name: Hub Table 

Route Name	Address Space	Next Hop Type	10.10.10.4	Description
AzFwUdrToProduction	10.20.0.0/19	VirtualAppliance	10.10.10.4	Outbound flow from Firewall should go to Production
AzFwUdrToStaging	10.30.0.0/19	VirtualAppliance	10.10.10.4	Outbound flow from Firewall should go to Staging
AzFwUdrToDevelopment	10.40.0.0/19	VirtualAppliance	10.10.10.4	Outbound flow from Firewall should go to Development
AzFwUdrToInternet	0.0.0.0/0	Internet		If spokes need to access internet

Table Name: Staging Spoke Table 

Route Name	Address Space	Next Hop Type	Next Hop Address	Description
StagingToAzFwUdr	10.10.0.0/19	VirtualAppliance	10.10.10.4	All the Outbound flow from Staging Spoke should go to Firewall

Table Name: Development Spoke Table 

Route Name	Address Space	Next Hop Type	Next Hop Address	Description
DevelopmentToAzFwUdr	10.10.0.0/19	VirtualAppliance	10.10.10.4	All the Outbound flow from Development Spoke should go to Firewall

Address Space 

One important factor we need to consider while designing the architecture is the number of hosts required in each network. This involves the selection of classful network, subnetting, subnet masks, IP range etc.  

Network Name	IPv4 address space	Subnet name	Subnet address range
Hub-VNet	10.10.0.0/19	GatewaySubnet	10.10.4.0/24
Hub- VNet	10.10.0.0/19	ManagementSubnet	10.10.1.0/24
Hub- VNet	10.10.0.0/19	AzureFirewallSubnet	10.10.10.0/26
Hub- VNet	10.10.0.0/19	AzureBastionSubnet	10.10.20.0/27
Production- VNet	10.20.0.0/19	WorkloadSubnet	10.20.1.0/24
Staging- VNet	10.30.0.0/19	WorkloadSubnet	10.30.1.0/24
Development- VNet	10.40.0.0/19	WorkloadSubnet	10.40.1.0/24