If you’re in charge of creating or maintaining the infrastructure or security of a large and complex Azure network environment, comprised of many virtual networks (VNets), Network Security Groups (NSGs), and virtual machines (VMs) spread across several Azure regions and subscriptions, some of these questions could sound familiar to you:
These questions are common to larger enterprises and reflect common use cases we see from customers.
Well, have no fear! There’s a new kid in town, designed to solve all these use cases (and more) — Azure Virtual Network Manager (AVNM).
In this article, we will introduce Azure Virtual Network Manager at a high level, giving you an overview of its capabilities and show you where to go for more information.
Azure Virtual Network Manager is a highly scalable and highly available network management solution that lets you manage virtual network connectivity and network security rules. Currently, AVNM supports connectivity and security admin configuration features. AVNM allows you to group, configure, deploy, and manage virtual networks at scale across your subscriptions and Azure regions. Network managers can be scoped at any level (or multiple! See below.) of your management group or subscription hierarchy as long as you have the network contributor role, and all child virtual networks “downstream” can be managed from a single pane of glass.
Below, if you select the scope for your AVNM to be only management group A, then the VNets under subscriptions D, E, and F (which are ultimately encapsulated within management group A) are all visible to that network manager.
Additionally, you can create multiple AVNMs – as long as two AVNMs do not have the exact same scope and feature combination, they can coexist and the configurations of these AVNMs will be overlayed. The reason why AVNM has this design is because this ensures that VNets would know which AVNM’s configuration would prevail when there is a conflict.
For example, referencing the diagram above, you can have one AVNM scoped to management group A for corporate-wide enforcement; and another AVNM scoped to management group C for business- or environment-specific security or connectivity purposes. These two AVNMs can be used by two different teams. When there is a conflict between the security admin configurations from different AVNMs, the configuration from the AVNM with a higher-level scope will prevail. We’ll cover more details on configurations later.
The logic illustrated in the three scenarios below is that these AVNMs cannot have the exact the same combination of the scope and feature.
The operative concept here is where the AVNM is “scoped”, the management group(s) and/or subscription(s) visible to AVNM control. In Example 4 below, a parent management group also has both a connection and security configuration applied. Since AVNM #1 and AVNM #2 do not have the exact the same combination of the scope and feature, you can create these two AVNMs. When there are conflicting security admin rules from AVNM #1 and AVNM #2, the security admin rules from AVNM #1 prevail over the conflicting rules of AVNM #2 because the scope of AVNM #1 is at a higher hierarchy level.
The Azure Virtual Network Managers are managed in their own section of the Azure Portal and are known as “Network Managers”:
As a new Azure product, AVNM has the standard bevy of features you’d expect, such as:
We’ll go through the bits in some detail, further on, but here’s the network manager creation GUI through the Azure Portal:
At a high level, AVNM can create connectivity configurations and/or security admin configurations to control either network connectivity and/or network security.
Let’s take a closer look at how AVNM works. There are four main pieces of AVNM:
These components added together make the magic happen.
Let’s look at the last three of these in more detail.
While the network manager itself can be scoped at management groups and subscriptions, there needs to be an explicit definition of which of the VNets in that scope will be impacted. Like, are we talking all of your VNets? Only those for your test environment? Only those for a line of business? Those hosting servers with sensitive information? The ability to define multiple, very specific network groups allows for configurations to be applied very high up in the governance infrastructure yet be very granular on which VNets it impacts.
Network groups define which VNets in the network manager scope are going to be governed. This is a logical grouping, so you have complete control of network group membership by:
For example, a network group with dynamic membership can include all VNets starting with the word “Prod” in their name, or any VNet belonging to a particular line of business’ resource group. Multiple criteria can be added together to get very fine control of which VNets are included in the network group. You can also create your dynamic membership definition using JSON syntax. See here for details.
After you deploy the configurations applied to a network group, any new VNets that match the defined dynamic criteria get added to that network group and those VNets that change and no longer match the dynamic membership criteria get removed from the network group. However, for static membership, you need to make any changes to the membership manually and deploy the configurations applied to that network group again. In summary, when your definition of the network group changes, you need to deploy the configurations applied to it again to take effect. In the case of dynamic membership, if the definition of the membership doesn’t change (i.e. you don’t change the conditional statements), you don’t need to re-deploy the configuration, and AVNM will automatically take care of the membership changes.
As mentioned earlier, a network manager can be scoped to management groups subscriptions. When an AVNM is scoped to a management group, it means all child management groups and child subscriptions are in that AVNM’s scope. Once the scope is defined, Azure’s governance mechanism will apply it “downstream” to include any VNet in that scope. Defining a network group inside of a network manager defines “which” VNets to include (whether statically or dynamically, or both). Since multiple configurations from different AVNMs can be applied simultaneously, if there are conflicts, the configurations from the AVNMs with the higher-scoped level (from the Azure governance perspective) take precedence. So, the higher up in the management group/subscription hierarchy the network manager is scoped, the more priority it has.
In the graphic below, we see a simple management group structure, with two child management groups, and three subscriptions distributed under those, containing a combined total of five VNets.
Let’s look at some of the interactions you can perform:
Enterprise-wide deployment: a network manager can be created and scoped to the top management group level and it will apply to all VNets that match the definition for the network group. It’s worth emphasizing that a network manager can be scoped to management groups and subscriptions, but only the VNets matched to the network group(s) definitions will be governed. The scoping basically bubbles up the potential VNets that could be managed under the network manager through configurations, assuming they are in a network group.
For example, an AVNM created and scoped at the highest management group will have all VNets in the entire enterprise as potential candidates. However, in this example, since a network group in the AVNM has a dynamic membership definition that limits the VNets to those with “Test” in the name, only those across the enterprise that match are actually subject to the AVNM configurations.
To take things a step further, as mentioned above, multiple AVNMs could be created by two teams, with one created for the enterprise-wide scope, and another scoped for a specific line of business or other purpose. As a simple example, you could create two network managers: one with the scope of the top-level management group to be used by the central governance team and would have the ability to apply configurations enterprise-wide (AVNM1 in the image below). Another one could be scoped to a subordinate management group or subscription, and would be used by a product team wishing to apply product-specific security admin rules en masse (AVNM2 in the image below).
The result is a robust mechanism that lets you make complex security scenarios that have the minimum controls deployed enterprise-wide by a central team and allow subordinate lines of business, projects, or other entities able to add their own configurations via separate network managers.
AVNM can manage the connectivity and security of VNets. It does this by means of configurations. A configuration can be of either connectivity or security admin type, and an AVNM can contain both types of configurations. When you first create your network manager, you can select what types of configurations that you want the network manager to be capable of in the “Features” selection. Note that you cannot modify the features of that network manager once you’ve created it.
A connectivity configuration is a simple construct that defines the type of network topology to be configured on your VNets, and the network groups on which to apply it.
Let’s look in more detail at the two variants:
Note that the direct connectivity created between spoke VNets would be displayed as “ConnectedGroup” in your effective routes. The connections between the hub and the spokes would be peerings. See here for more details.
Using these settings together, you can create a hub and spoke topology where some VNets can have direct connectivity within the network group, like “Prod” below, and some, like “Test”, only have connectivity to the hub from each spoke VNet. The colored area below shows the VNets that are part of a ConnectedGroup, which in this case are the Prod VNets, since direct connectivity was enabled for the Prod network group. All the Prod and Test VNets are connected to the hub VNet through peering.
Prior to the connectivity configuration of AVNM, your main option for connectivity between VNets was to manually peer them together. This involves setting the network peering relationship up on each side of the pair, and it quickly becomes an administrative burden as the number of VNets increased (for example, in the case of the mesh topology, 10 VNets would require 10*9/2=45 peerings; 500 VNets=124,750 peerings). It can be programmatically controlled, true, but as the number of VNets scales into the tens and hundreds, it can quickly become unmanageable, let alone if you need to alter the topology.
Using a connectivity configuration with dynamic network group membership can greatly reduce this burden and make it a simple matter to connect a multitude of VNets together.
Now let’s have a look at what AVNM does to control security. This is done using security admin configurations, which include network traffic rules grouped into rule collections that are then applied to one or more network groups.
These security admin rules get evaluated before NSGs get processed, so they have a higher priority than NSG rules. This allows an AVNM configuration to be defined at a corporate or business unit level to restrict or allow traffic, while still allowing subordinate teams to manage their own traffic through traditional NSGs, a separate AVNM scoped lower in the governance structure, or with lower priority rules. Note, security admin rules do not change NSGs. Instead, they are defined independently, and security admin rule won’t change NSGs.
These security admin rules are exactly what you’d expect from something like NSGs or a firewall—you select a priority, direction, action, source, and destination network parameters. However, in addition to Allow or Deny, there’s a third option to Always Allow. The traffic that meets the Always Allow rule would be allowed without getting evaluated by NSG rules or lower priority security admin rules. You can use Always Allow to force of the traffic to be allowed.
As a network administrator, you can use security admin rules to create high-priority rules that should be enforced across your organization and still allow individual product teams to control their own NSGs for flexibility. Without AVNM's security admin rule, it was not easy to enforce your organization's security rules while preserving product teams' agility in meeting their security needs. Often, you needed to allow all the NSGs to be managed by either the network administrator or the individual teams. The former case incurs significant operational overhead to the network administrator, and the latter lacks security enforcement. Using security admin rules, you can solve this issue.
Security admin configurations also allow you to protect your network environment at scale. Security admin configuration can be defined and applied to all in-scope VNets. It doesn’t matter if there is one, ten, a hundred, or a thousand or more NSGs – any new Azure resources created and connected to a VNet in a network group with a security admin configuration applied will be protected from day one.
Here are several AVNM use cases for security rules:
Along with the introduction of the Azure Virtual Network Manager product itself, other areas of Azure have been enhanced to give you full visibility of the impact your network managers are having.
Integration with Network Watcher
Effective security rules
For starters, the Network Watcher blade has been enhanced. In addition to network security rules placed via NSGs, Network Watcher’s Effective security rules blade clearly shows the security admin rules associated with a network manager.
IP flow verify
The IP flow modelling available through Network Watcher’s IP flow verify blade has also been enhanced to factor in AVNM’s security admin rules. The name of the AVNM security admin rule is displayed in the results, like “Port80” in this example.
Integration with Network Interfaces and Virtual Machines
When looking at a Network Interface attached to a VNet with an applied AVNM security admin configuration, the AVNM security admin rules are located just below those of the NSG’s.
By extension, the Virtual Machine blade’s Networking section will also bubble up this information, allowing you to clearly differentiate NSG vs. AVNM security admin rules.
So up to this point, we’ve covered the building blocks of AVNM that control what is to be configured by connectivity/security admin configurations and network groups. The final piece is deployment.
Here’s a high-level flowchart of creating an AVNM and putting it into place:
We’ve covered the first three up to this point. Now, let’s drill down a bit into step 4. A deployment rolls out configuration(s) (connectivity or security admin) to one or more Azure regions.
For the final step of implementing AVNM, we will:
AVNM deployments use the goal state model, which means you define the final state you wish to have. You just tell AVNM all the configurations you wish to have as the end result, and AVNM will figure out how to make it happen and make the necessary changes for you! For example, you originally had configurations 1 and 2 in regions X and Y, and now you want to have configurations 2 and 3 in regions Y and Z. AVNM will identify the necessary changes and deliver the end result for you without the need for you to think how to achieve it. As such, to remove all the configurations, you apply a “None” configuration to your regions to tell AVNM that you do not want to have any configurations. See here for more information.
Remember, as mentioned above, unless your definition of the network group is changed, you don’t need to re-deploy to reflect the changes in the VNet membership. If the network group being deployed is defined only by dynamic membership, a configuration will automatically apply to any new VNets that match the definition from deployment time on. Same with those that fall out of dynamic membership conditions. This is because your definition of dynamic membership didn’t change.
On the other hand, if you change any definitions of network groups (whether that’s a manual change of VNet membership for a static membership or the conditional statements governing dynamic membership) or the configurations after a deployment is using them, then it is necessary to re-deploy the configuration(s) affected.
So now we’ve looked at the building blocks of the new Azure Virtual Network Manager and how they fit together to control a potentially large and far-ranging set of Azure VNets. We’ve seen that AVNM is a very powerful central management tool for VNets. It can control connectivity and security across a customizable scope of VNets automatically and reduce the administrative burden for managing large (or even medium or modestly small) Azure VNet infrastructures. Overlapping network managers scoped to specific targets can provide laser-focused fine-grained impact. Different organizational resources can be given scoped-down network managers that they have control over.
This new solution can reduce the management burden of Azure VNet management significantly and offer a way to enforce enterprise standards from the highest governance level to as low and granular as desired.
AVNM is currently in Public Preview. Here are a few resources to get you started:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.