Azure, VNET and Subnet deployment with ARM Templates

In my daily work, I often have to correct network architecture from Azure projects. Sometimes there are not enough free IP, sometimes there are security issues, sometimes bad routing, but it frequently ends with re-architecture and re-host.

Designing a good network architecture for an application or an infrastructure is not easy and designing it in Azure can be more complex and different.

Network in Azure is more about IP routing where traditional datacenter generally uses VLAN or layer 2 switching and less routing.

VNETs are at the heart of network architecture on Azure. A VNET is the address space. It hosts subnet, where you will connect resources. Subnet segment the address space into multiple subnetworks. By default, an IP in a subnet can communicate with any other IP inside the VNET. Azure route traffic between subnets and outside the VNET.

The design of these VNETs for an application, a project, a subscription or for the entire enterprise is important.

One of the first things to do is to choose a network ID, not only for one application or your current project but for the whole enterprise. It needs to cover future projects too.

This network ID should not overlap with networks that may be used in the future and network you may connect to your Azure subscriptions. This includes your on-premises network (for hybridization via VPN or Express Route). It must be large enough to include future project

This network ID is not chosen to be used in a VNET, it's only a reservation of IP address for future demands in Azure.

Let says that you need to design the infrastructure for an application in Azure, there will be some servers, some databases, and a front end. Instead of choosing an address space only for this application you need to choose an address space that can allow extensions of the current project as well as any future projects on Azure.

After all, you do not know at this time if the application will need a firewall, a VPN, a DMZ, … and any other infrastructure needs for the enterprise.

You also know that modifying the network topology is far from easy. Changing a virtual interface can only be done in the same subnet for example.

Let’s start, after some reviews, you decided to use the 10.124.0.0/14 network (on azure you can only use private IP, 10.0.0.0/8, 192.168.0.0/16 or 172.16.0.0/16, if you use other IP it may not work). This ID is not used anywhere on your premises network or any other projects in the Cloud. It gives you 262142 Hosts.

But this ID will not be used like that on any VNET, it's just a reservation or something to says that IP from 10.124.0.0 to 10.127.255.255 are reserved for Azure project.

Networks are somewhat beautiful. A subnet is a division of another subnet you can slice into smaller subnets. It’s called subnetting. But there are some rules on Azure.

in an Azure subnet, the first IP is the network and last is used for the broadcast (it's also the case for all network projects). The 3 firsts IP in the subnet are also used for external routing and name resolution.

If you know that the first project will only use a few machines but can be increased to a few more, it makes sense to use a relatively small subnet for the project. A /25 network for the VNET should be enough, there are 125 available IP and enough space to create few subnets.

We have our first VNET with the address space, we need, now, more divisions for Azure subnet. You need to avoid using only one subnet using the same IP subnet. You need to reserve space for other needs.

Here's come another rule concerning Azure Network, the smallest subnet you can use in Azure is a /29 with 6 IP available but remember, the 3 first IP are reserved for Azure routing and name resolution, so you can use only 3 IP.

Before starting the subnet design, we need to think about your future needs. One needs can be to connect VM to on-premises networks. So, you may need to implement an Azure VPN gateway.

VPN Gateway needs a subnet called gatewaysubnet. You may also need to use a frontend subnet and a database subnet and finally a backend subnet. Because you do not want to put all your machines in the same broadcast domain.

• Gatewaysubnet 10.124.0.0/29
• frontEndSubnet 10.124.0.16/28
• databasesubnet 10.124.0.32/28
• BackendSubnet 10.124.0.48/28

As you can see there is still plenty of space in the original /25. And you may notice that you waste some space (one /29 at least). But this kind of subdivision allows you to better control the flow between VM and give you the ability to extend the project if you need it.

How to deploy that. I prefer to use ARM for deployment because it’s simple and reusable. To deploy a VNET we need:

• The VNET name
• The VNET Location
• Tags
• The VNET network
• The list subnet with their prefix

To be reusable, we need to think like an object. We may have to deploy one or more VNET with one or more subnet.

ARM allows the use of array and object. It will help to model the network architecture to deploy.

    "parameters": {
        "Netconfiguration": {
            "value": [
                {
                    "VnetName": "myapp-vnet",
                    "VnetNetwork": "10.124.0.0/25",
                    "VnetLocation": "westeurope",
                    "tags": {
                        "App": "Myapp",
                        "Environnement": "prod",
                        "Iac": "arm"
                      },
                    "Subnet": [
                        {
                            "SubnetName": "gatewaysubnet",
                            "SubnetPrefix": "10.124.0.0/29"
                        },
                        {
                            "SubnetName": "frontEndSubnet",
                            "SubnetPrefix": "10.124.0.16/28"
                        },
                        {
                            "SubnetName": "databasesubnet",
                            "SubnetPrefix": "10.124.0.32/28"
                        },
                        {
                            "SubnetName": "BackendSubnet",
                            "SubnetPrefix": "10.124.0.48/28"
                        }
                    ]
                }
            ]
        }
    }

The resources section is

"resources": [
        {
            "apiVersion": "2017-05-10",
            "name": "[concat(copyIndex(),'netconfdeploy', uniqueString(resourceGroup().id))]",
            "type": "Microsoft.Resources/deployments",
            "copy": {
                "name": "Vnets",
                "count": "[length(parameters('Netconfiguration'))]"
            },
            "properties": {
                "mode": "Incremental",
                "template": {
                    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
                    "contentVersion": "1.0.0.0",
                    "parameters": {},
                    "variables": {},
                    "resources": [
                        {
                            "apiVersion": "2017-10-01",
                            "type": "Microsoft.Network/virtualNetworks/",
                            "name": "[parameters('Netconfiguration')[copyIndex('Vnets')].VnetName]",
                            "location": "[parameters('Netconfiguration')[copyIndex('Vnets')].VnetLocation]",
                            "tags": "[parameters('Netconfiguration')[copyIndex('Vnets')].tags]",
                            "properties": {
                                "addressSpace": {
                                    "addressPrefixes": [
                                        "[parameters('Netconfiguration')[copyIndex('Vnets')].VnetNetwork]"
                                    ]
                                },
                                "copy": [
                                    {
                                        "name": "subnets",
                                        "count": "[length(parameters('Netconfiguration')[copyIndex('Vnets')].Subnet)]",
                                        "input": {
                                            "name": "[parameters('Netconfiguration')[copyIndex('Vnets')].Subnet[copyIndex('subnets')].SubnetName]",
                                            "properties": {
                                                "addressPrefix": "[parameters('Netconfiguration')[copyIndex('Vnets')].Subnet[copyIndex('subnets')].SubnetPrefix]"
                                            }
                                        }
                                    }
                                ]
                            }
                        }
                    ]
                }
            }
        }
    ]

This is a basic setup, but it helps to understand how to build a network architecture in Azure you can extend and interconnect. Keys, here, are flexibility and anticipation. You also need to care a lot about the network ID you choose, no overlap, good size for the project and compliant with the RFC 1918 for private networks.

More a network topology on Azure (and on-premises too) need to include security from the start. This includes more segmentation and segregation and tools like a firewall. But it's another story.