Azure Virtual Network Manager: Next-Gen vNet Management

Something that Microsoft has always tried to do, and sometimes succeeded spectacularly well in (looking at you – Small Business Server 2011) and sometimes not so much (looking at you – Control Panel / Settings in Windows) is simplifying complex configuration and deployment steps to make it more approachable for a non-expert.

This is particularly evident in Azure networking. The basic building block is a virtual network (vNet) and larger deployments often opt for a hub-and-spoke model where the hub contains shared services, network connectivity to on-premises (Site to Site VPN or ExpressRoute), and firewall services. Add branch offices and their connectivity and you can see how this gets complex very quickly. A few years ago, you had to build such a deployment piece by piece, and then came Azure Virtual WAN (Azure VWAN) which lets you deploy a managed version of the above where Microsoft manages connectivity and security based on your configuration.

If you have a large number of vNets you still have to manage their connectivity and likely filter traffic using Network Security Groups (NSGs) manually, again configuring each piece as you go.

This changes with the recent release of Azure Virtual Network Manager (AVNM) to public preview. In this article, I’ll explain what AVNM is, what you can use it for today, how to configure it, and speculate about what features might be added as it matures during the public preview.

Network Manager UI

Network Manager UI

What is Azure Virtual Network Manager

Azure Virtual Network Manager (AVNM) lets you centrally manage routing, security policy, and connectivity globally across regions and subscriptions. It lets you define a scope for each AVNM which can be based on subscriptions or management groups and then you add vNets to an AVNM, either statically by assigning them or dynamically by defining conditions that will automatically include vNets in a network group. The 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.

It’s also scalable, rather than you having to establish peering between each of the vNets you simply group them together and define the type of connectivity you want (mesh or hub-and-spoke) and AVNM takes care of it behind the scenes. Your network security team will also rejoice, for the first time they can define global security rules that’ll apply to all the resources in the AVNM scope, for instance, a rule to block high-risk protocols ports from the internet which will be added to all the NSGs in scope, and which resource owners can’t remove.

AVNM is a platform service, highly available and scalable with redundancy and replication across the globe. It enables centralized control across an entire enterprise Azure network deployment with monitoring (today you can view your topology end to end, flow logging between any source and destination is coming) and you can roll out changes to the configuration in a staged manner with the ability to “un-deploy” configuration changes if rollback is required.

Setting up Azure Virtual Network Manager

To test this out I searched for Network Managers in the Azure Portal and clicked +Create to make one.

Creating a new Network Manager

I scoped this one to a subscription but picking a management group instead is easy. You also need to choose which features the AVNM is going to support, Connectivity, SecurityAdmin rules, or both. That’s really all there is to creating one, the next step is defining a network group to include the vNets that you want to manage.

vNets

In my testing I included two vNets statically but as mentioned the dynamic membership rules are going to be very useful in large environments. Remember, at this point, the AVNM isn’t doing anything, it’s not until you define configurations and deploy them that anything changes so including/excluding vNets is harmless.

Each AVNM can have multiple groups of vNets and you can have different configurations apply to different groups, furthermore, each vNet can be part of several AVNMs.

Adding vnets to a network group

Next comes creating configurations. Let’s start with a connectivity configuration, here you define the topology: Mesh where every vNet is connected to every other vNet, or Hub and Spoke where each vNet is connected to a central hub. Optionally you can pick for this mesh connectivity to extend across regions but as always be aware of potential egress network charges, depending on the amount of data that flows between resources in your vNets.

In the hub and spoke you can also optionally configure transitivity connectivity so that each vNet is connected to each other as well as the hub. AVNM uses Azure vNet peering for the hub connectivity but connected group connectivity for the vNet-to-vNet connectivity. This is a new connectivity construct which like peering has no extra hops in the traffic, in fact, if you look in the effective routes section, ConnectedGroup is listed as the Next Hop Type.

Note that none of this gets around the basic premise of routing, none of the connected vNets in any connectivity type can have overlapping IP Subnets.

As a practical example, say you’ve got five Production vNets and five Test vNets connected to a hub, you could group the Production vNets together with Hub-And-Spoke and enable transitivity, while the group that contains the five Test vNets (for example dynamically based on a tag so that any new Test networks are automatically included in the group) doesn’t have transitivity enabled.

If you have existing vNets that you’re importing into AVNM and they already have peering configured you can optionally override/delete the existing relationships with AVNM to bring them into centralized management.

Connectivity Configurations

Adding a connectivity configuration

Next, you can create what’s called a security admin configuration, a collection of rules that apply to each of the groups of networks in the AVNM. Each rule has a name, and a priority between 0 and 99, where lower wins over higher numbers. You can also define the direction of the traffic (inbound/outbound), the protocol (TCP, UDP, ICMP, ESP, AH, and Any), source/destination IP v4/v6 address (individual, a list of addresses, CIDR ranges), source/destination port (individual, lists, ranges) and source/destination type (IP address or service tag). The action for each rule can allow traffic, deny (block) traffic, or Always Allow even if a local NSG or a lower priority security admin rule blocks the traffic.

Creating a security admin rule

Once you have configured a connectivity or security admin rule you need to deploy it, picking the type and target region(s).

Deploy a configuration

It can take between 15-20 minutes to roll out a configuration to all the vNets in scope. Note that each deployment is automatic so that if you deployed configuration 1 yesterday and today you want to deploy configuration 2 unless you pick both 1 & 2, you’ll replace configuration 1 with 2. This is also how you un-deploy or roll back a configuration, by selecting None in the configuration to deploy.

What Azure Virtual Network Manager Means for System Admins

AVNM is a crucial (and one might argue, well overdue) addition to Azure. It’s fine to do most things manually in small test deployments and to scale up using ARM templates and automation as the number of networks and resources grow but a centralized view and policy management has been lacking for large infrastructures. There are definitely some limitations in the preview such as the lack of PowerShell / CLI support, cross-tenant support and max number of security admin rules (100 per AVNM), max IP prefixes (1000) in all admin security rules, and 500 peering connections per vNet and 500 spokes for a single hub. I would assume most of these will be addressed during the preview or shortly thereafter. Regardless, I think that AVNM is going to be the best way to build new enterprise Azure deployments going forward. It’ll also be interesting to see how easy it’ll be to “upgrade” existing deployments into AVNM.