Networking is the fundamental building block of pretty much all IT solutions, but is often hard to appreciate due its transparent nature. If done right, networks offer easy integration and seamless flow of data, but it typically requires a lot of thought and design work up front.
In traditional physical networks, it also requires the purchasing, installation and configuration of networking equipment such as switches, routers and firewalls.
It also requires a lot of knowledge such as subnetting and routing protocols such as OSPF or BGP.
All of this can be quite daunting, especially for smaller organisations, where these skills and assets have to be brought in with the burden of on-going service management and maintenance.
On top of this, there is the also the cost of ownership of these assets, where you must consider things such as hardware refresh cycles and selecting vendors for your switching / routing / firewalls etc. This continual investment in assets which need to be ‘sweated’, can be an awkward conversation for non-IT folks who may adopt a more ‘purchase-and-forget’ type attitude.
Now, the cloud doesn’t quite get rid of this complexity entirely, but it does drastically reduce the friction in getting your solutions deployed. You can get up and running very quickly, and this section will describe how.
The Basics
Virtual networks, or VNets, are the main networking component in Azure.
They performs 3 major functions:
- Isolation of networks – this is the default behaviour, but VNets can be peered to allow inter-VNet traffic
- Access for resources, internal to Azure – for example, attaching an Azure VM to a network
- Network integration, for resources, services or networks outside of Azure – for example, enabling access from on-premises infrastructure to Azure networks
When you first create a VNet, it provides an isolated area for private connectivity.
At the point of creation, you must specify an address space for the VNet. This is the total range of addresses that the VNet will support.
Planning for network ranges is extremely important, when you consider things like VPNs or peered networks, which prohibit overlapping address ranges. You can re-address VNet address spaces, but bear in mind this could impact your services.
Within this address space, you can create subnets to which you can then assign your resources. Subnets are smaller allocations (or blocks) of IP addresses that can be consumed within the address space.
By default, communication between subnets on the same VNet is automatically allowed.
An analogy here is that an address space can be compared to post codes, whilst subnets are like streets and IP addresses are like individual houses within the street.
Once a street is fully populated with houses, any new houses must be built on a different street, within that post code, until all streets are full and a new post code is required. Now, this analogy might be a little weak given that you don’t need to fully populate a subnet (or a street) for it to work, you could have one IP address allocated in each subnet (and that might make for a very awkward series of streets), but I think you get you idea…
The first usable address on a subnet is X.X.X.4, the first 3 IP addresses are reserved by Azure for services. Standard networking practices prevent the use of .0 and .255, as these are used for the network and broadcast addresses respectively.
The largest subnet you can use is a /8 – which provides 16,777,214 usable host addresses. The smallest usable subnet is /29 which leaves 3 usable host addresses after the Azure reservations.
👍 Use a subnet calculator tool such as https://www.calculator.net/ip-subnet-calculator.html to understand IP address ranges, subnets and reserved addresses (such as network and broadcast addresses).
Private IP addresses are automatically allocated using Azure’s built-in DHCP service, you cannot use a custom DHCP service as this is not supported and is a guaranteed way to brick any VMs you may have running in Azure. You can also create public IP addresses for services that need to be accessible over the Internet (more on this in upcoming sections).
DNS (Domain Name System) is a critical part of networking. Computers are very good at understanding numbers, so if you told it to find 192.168.0.1, it would do it with ease.
Humans are not so good at remembering numbers – to illustrate this point – ask anyone what their three closest friends/family members mobile phone numbers are from memory. Not so great, right? To help with this, DNS does the lookup between IP addresses and human-friendly (or rather, easily recallable) domain names such as (www.google.com). When you type this into your browser, behind the scenes the DNS server will lookup www.google.com to see what the underlying IP address is and route the request accordingly. A good primer on DNS can be found here: https://www.cloudflare.com/en-gb/learning/dns/what-is-dns/
There are two options for using DNS at the VNet level. You can use the default Azure DNS servers for name resolution, or you can specify your own DNS servers. For general use, the Azure DNS servers might be sufficient, but for fine-grained control you will want to point to your own DNS servers so that you can create and manage the different DNS records to point to your custom services.
⚠️ Remember, egress traffic is billable, so if your DNS server is publicly accessible but sits outside of Azure, you will be billed for each request!