In-Depth

Ignite In Depth: New Azure Virtual Network Manager Public Preview

The point of AVNM is to give you a centralized way to manage connectivity and security policy, scoped to subscriptions or management groups for your entire Azure estate.

• By Paul Schnackenburg
• 11/03/2021

If you manage a large deployment with many vNets in Azure, the freshly released Azure Virtual Network Manager (AVNM) is going to make your life as a cloud network architect so much easier.

Microsoft started this with Azure Virtual WAN (Azure VWAN), a Platform-as-a-Service (PaaS) offering that lets you deploy a hub-and-spoke model, optionally with connectivity back to your on-premises networks (ExpressRoute or S2S VPN), branch office WAN connections, plus Azure Firewall for security. Instead of having to create each individual network component and then configure their connectivity, Azure VWAN lets you define policies and it'll do the configuration behind the scenes.

Up until now though, if you had many vNets, you had to manage them individually, perhaps assisted by Infrastructure as Code and Azure Resource Manager (ARM) templates. You also needed to configure their connectivity to one another and control traffic using Network Security Groups (NSGs), a software-based firewall service. This gets more difficult to manage as the size and complexity of your network grows.

Azure Virtual Network Manager (AVNM) has just been released to public preview at Microsoft's ongoing Ignite conference. In this article I'll cover AVNM, what it can be used for and ponder what improvements we can see as the preview progresses.

Azure Virtual Network Manager
The point of AVNM is to give you a centralized way to manage connectivity and security policy, scoped to subscriptions or management groups for your entire Azure estate. You scope each AVNM to one or more subscriptions or one or more management groups. Then you add vNets to network groups in the AVNM. Each AVNM can have multiple network groups. Adding vNets can be done manually/statically or you can build a set of conditions that'll include any vNet that matches them. Conditions are name, ID, tags, subscription name/ID/tags or Resource Group name/ID/tags with several operators to include exactly the vNets you want to add. If you want to get really fancy you can use the built-in JSON editor to edit the code that your conditions and operators (Contains, Does not contain, In, Not In, Equals, Does not equal, Contains any of, Contains all of, Does not contain any of) results in and click Evaluate to get a list of the vNets that will match. A vNet can be a member of several network groups but only up to five Mesh configurations (see below).

Once you have added the right vNets you can deploy one of two types of configurations: either Connectivity configurations or Security admin configurations. For connectivity you can select Mesh where all vNets will be connected to every other in the group using standard Azure vNet peering, without you having to configure anything apart from this configuration. Alternatively, you can choose Hub and spoke where each vNet will be connected to a central hub. And optionally you can also choose to have each vNet connected to every other vNet using a new connectivity method, Connected Group, which like vNet peering is a direct connection method. If you look at the effective routes for a resource, it lists ConnectedGroup as the next hop for traffic. For Mesh you can optionally expand connectivity across regions for global networking; just be aware of potential egress traffic charges if you have a lot of network traffic. In upgrade scenarios know that you can remove manually configured vNet peerings when you apply connectivity configurations. And AVNM doesn't break normal IP rules -- you still can't have overlapping IP subnets in the vNets you're connecting.

Security admin configuration is about adding rules to the NSGs in scope. A good use case is blocking access from the internet for high-risk protocols (SSH/RDP) with rules that resource owners/administrators can't remove. This will make your security team very happy as for the first time they'll have centralized control over NSGs. Up until now you needed to use Azure Firewall with policies for this type of control (Azure Firewall costs money, sometimes a lot of money, whereas NSGs are free).

Because AVNM is a platform service, it's scalable and highly available. There are only a handful of regions available, but that's likely to expand during the preview. As you roll out security and connectivity configurations, be aware that if you see issues, you can roll back to a previous configuration or undo everything by rolling out a "no configuration." Be careful when deploying configurations because they're not additive, so if you deployed Config1 today and you want to add Config2 tomorrow you'll need to select both, otherwise 2 will replace 1.

Testing
As expected, it's quite straightforward to create a Network Manager, find the resource type and click +Create.

Here I selected two subscriptions, but as you can see in the screenshot, scoping to Management groups is simple. Each AVNM can use Connectivity configurations or Security admin configurations or both. I can see how an architect might split these two functions up across two different departments/teams in a large organization. Once the AVNM is created (takes a minute), it's time to make a group of vNets. Here I added three vNets statically, but in a large environment the ability to set rules that add them dynamically is going to come in very handy. There's also no risk at this point, just because a vNet is a member of one or more network groups. Since there's no configuration deployed yet, nothing will change.

I then created a Connectivity Configuration, selecting Mesh. One way you can use these network groups is controlling what's connected to what. In a hub-and-spoke model you might want your four production vNets connected to the hub and to one another, thus enabling transitivity for that configuration when you apply it to that group. The six development vNets that are connected to the same hub, on the other hand, you add to another group and apply only hub and spoke so they're isolated from each other and only connected to the hub.

The final configuration is Security Admin that you can apply to each of the network groups. It's a collection of rules, with a priority between 0 and 99 where a lower number equals higher priority. Each rule defines the traffic direction, the source destination IPv4 or IPv6 address which can be an individual address, a CIDR range or a list of addresses. You can also define the protocol(s) as TCP, UDP, ICMP, ESP, AH and Any, source/destination port and the type of destination: either IP address or service tag. The action for a rule match can be allow traffic, block/deny traffic or Always Allow even if an NSG or a lower priority security admin rule would have blocked the traffic.

The last step is deploying your configuration, selecting which regions to apply it to. It can take 15-20 minutes to roll it out to all vNets in scope.

Summary
There are some limitations at the time of writing such as lack of CLI/PowerShell support, no cross-tenant support and only 100 Security Admin rules per AVNM, with a max of 1000 IP prefixes in all rules. You can also only have 500 peering connections per vNet and 500 spokes in a hub. Nevertheless, the power of this consolidated way of defining connectivity and security is going to make this the default way to build and maintain large deployments of networks in Azure. The option to "replace" the existing manual vNet peering with the AVNM configuration opens the door to upgrades of existing deployments, but it'll be interesting to see how many IT departments go through the required steps to bring all their vNets into AVNM management. Or maybe they leave them as they are connectivity-wise but use AVNM for centralized NSG rule control. The preview will sort these things out, so stay tuned.