Understanding Azure Virtual Networks

Way back when virtualization was a new thing, virtual networks were simple connections that linked virtual servers and the occasional networking appliance. Now, however, things are different. Building and managing a virtual network is part and parcel of running a virtual infrastructure and is akin to managing a physical network.

That’s even more the case when you’re building a hybrid environment that stretches between on-premises systems and cloud infrastructure. Suddenly you’re having to manage a network that mixes your own physical and virtual systems with those at your cloud provider, while adding in the complexity of either a VPN or a Multiprotocol Label Switching (MPLS) direct connection to link your site to the cloud. It’s not easy, but the big clouds like Azure provide tools to help you.

Introducing Azure Virtual Networks

At the heart of both Azure’s infrastructure- and platform-as-a-service model is the Azure Virtual Network (VNet), a managed VLAN that connects your resources to Azure’s and provides a secure partition that keeps your network traffic in your tenant without leaking it to other users who may be using the same physical servers. Azure Virtual Networks don’t need to be connected to on-premises networking; you can use VLANs to build and manage cloud-native infrastructures and resources. They can then link between different Azure regions, using Azure’s private networking to manage transits without using the public internet.

As part of Azure Virtual Networks, you can deploy virtual appliance implementations of most common network hardware, treating your VLAN as a software-defined network that builds on top of Azure’s own routing and switching services. At the same time, it’s a gateway to the tools built into Azure Application Gateway and Azure Bastion, linking application networks to the public internet, either for direct access or through network tools like web application firewalls and managed load balancers, with geographic routing to deliver traffic to the nearest instance of your application, as well as back into your own network, ensuring protected access for approved users.

Each Azure VNet has outbound access to the internet, much like working with any firewalling router. Your resources initially have private addresses, with external IP addresses managed via a load balancer. Internally your VNet can host virtual machines as well as specific Azure resources like Azure Kubernetes Service. Other resources are accessed via service endpoints that link your resources to your network and prevent other users from accessing them, locking access down to your VNet. If you have more than one VNet hosting infrastructure or resources that you want to share, you can set up VNet peering to allow cross-network operations (and cross-region operations where VNets are in different Azure regions).

Building and deploying your first VNet

How do you go about building and managing a network in Azure? VNets are created as Azure resources and managed as part of a resource group. You can use any Azure management tool to create and deploy a network, using familiar tools and concepts.

At its most basic, building an Azure Virtual Network is very like working with a standard private network using RFC 1918 addresses. You can choose your own subnets as necessary, using them to segment your address space and manage individual VLANs and security groups within your VNet. If you’re using an Azure VNet as an extension of your own on-premises network, you need to make sure that there’s no overlap between address ranges. It’s probably a good idea to start from that assumption. Even if you don’t initially plan to build a hybrid cloud instance, correcting your IP addresses when you finally do can be a complex process.

Once you’ve set up the basic network, you can add virtual machines and other resources. It’s important to understand that this is a software-defined virtual network; there is no relationship between where VMs are instantiated in a network and how your network operates. As far as you’re concerned, the two machines are on the same network. Azure’s underlying networking fabric handles the actual networking.

Adding virtual devices and services to a VNet

All you need to do when creating a resource is select the VNet and the subnet you wish to use, and Azure will configure and manage the connection for you. If you’re using virtual machines, it’s simple to test that your network is in place. For Windows you can log on with PowerShell and ping another host on your VNet. The same for Linux, using bash.

Although it’s easy to build your first network from the Azure Portal, if you’re working at scale and using software-defined infrastructure for your applications, you’ll want to use Azure Resource Manager templates to configure and deploy a network. ARM has the tools necessary to define network names, address spaces, subnets, and more. Templates can be stored in an application repository and deployed through a continuous integration/continuous delivery (CI/CD) platform.

You can now use Microsoft’s new Bicep infrastructure definition language to create your ARM templates. Other tools such as Terraform or Pulumi also have options for building and managing Azure networks, working directly with its APIs. You can choose what works best for you and your development team.

Software-defined networking tools in Azure

Once a network is in place, you can take advantage of Azure’s software-defined networking capabilities, adding filters to use Azure network security groups to lock down access to specific servers. For example, you can have rules that ensure only SSL traffic goes to an application web server. Similarly, you can create custom routing that overrides Azure’s default routing, deploying a virtual machine as a network appliance to manage your own routing tables for your application. You’ll need to create an Azure route that connects subnet traffic to your virtual appliance, at which point its own routing takes over.

Hybrid operations require remote connections. Here you can control access by limiting VPN access to specific internal computers, using a point-to-point VPN. This approach can manage access to an operating cloud-native application, giving engineers and support staff access. Similarly, site-to-site VPNs open up a VNet to all your internal resources, extending your data center into Azure and vice versa. Physical connections via ExpressRoute work much the same as a site-to-site VPN, bridging your local and cloud resources.

Azure’s Virtual Network is free for internal traffic, though adding some services to your network will add resource- and usage-based pricing. Start by choosing an IPv4 RFC 1918 address space and netmask for all your networks. You’ll then use a higher netmask to create your first subnet, using a service like Azure Bastion to manage access to servers, and Azure Front Door to provide a secured set of external IP addresses, load balancer, and firewall.

This is a foundational Azure service, essential to build, deploy, and manage cloud-native applications. Your Azure Virtual Network is how you link your services and Azure’s together, providing a link back to on-premises and out to the wider internet, as well. It can even serve as an introduction to software-defined networking and to concepts that will be essential if you’re using Azure Stack HCI or Azure Arc to build private and hybrid clouds.