Design considerations for Azure Virtual Network Manager (AVNM)

In my previous article about Azure Virtual Network Manager (AVNM), I introduced some details about this service’s features. Still, AVNM is in preview, but it has quite strong merits. In collected a few design considerations for Azure Virtual Network Manager, in case you want to adopt it into your architecture. You can treat this as a set of guidelines for shaping your cloud design using AVNM.

I divided these directions into the following categories:

• General
• Network
• Security
• Regions
• Costs

General considerations for Azure Virtual Network Manager (AVNM)

There are a few general aspects to take a look at during the design phase, from a more governance perspective.

1. In Preview – At the time, I am writing this article, the AVNM service is still in preview mode. Therefore, some things may be changed, and as in most such cases in Azure, there is no SLA assigned while the service is in preview.
2. Easy testing – It simplifies the deployment. Any changes applied to the infrastructure seem like an additional layer on the environment, which can be revoked at any time with no harm done.
3. Subscriptions count – A subscription is a cost base for AVNM. It charges per subscription base, not virtual network (VNet) count.
4. Scope – at which level of hierarchy do you want to assign the network? This is bound to VNets, that you can manage.
5. Instances – Do you want to have one instance of AVNM, or divide it between one overarching and add a second layer for additional features? While deciding how many instances you may need, always take into consideration that there may be conflicts in security admin rules, as when using always allow, the highest scope AVNM rule takes precedence.

Network considerations for Azure Virtual Network Manager (AVNM)

1. Multiple connectivity configurations – A VNet can be a part of multiple connectivity configurations and can be a part of multiple connectedGroups. However, it can only be a member of two simultaneously. You can be a part of Hub and Spoke with a direct connectivity set and a part of Mesh, or part of two Meshes, or two Hub and Spokes (both with direct connectivity on).
2. VNet limit – There is, as of today, a limit of 250 VNets in a connected group. Bear in mind, that this may change.
3. The boundary within the communication – When you turn on the direct connectivity in Hub and Spoke model, firstly it’s only going to set connectivity between spokes in the same connectivity group (for regions – new topic) or network groups (as set in the AVNM panel either dynamic or static). Therefore, you have two boundaries. The first is a region, which divides the VNets into groups. Second, your manual or automatic setting of assigning VNets to groups. Even though your VNets may be in the same network groups, they are still going to be separated by regions into different connectivity groups. You can learn more about these details in the video introduced by John Savill. With direct connectivity, the spokes can talk directly within the network group and region.

Whether to use Hub and Spoke or Mesh

With Mesh, the AVNM behaves differently than with Hub and Spoke. With Hub and Spoke, if you have different network groups, as part of the topology, and you turn on the direct connectivity, the different networks (assigned to different network groups) are separated. Then, the communication between spokes from different network groups is not established. However, the Mesh model (in AVNM) is turning any-to-any communication relation. It does not abide association of VNet within various network groups. For example, all VNets (which are part of Mesh) can reside in separate network groups, and they still can communicate with each other without peering. Also bear in mind, that depending on the deployment option, it can be bound to the region or not (in the deployment, you have the option to ‘enable mesh connectivity across the regions’).

If you want to establish communication between all spokes, no matter the region, after turning on the direct connectivity, you can enable global mesh, which creates one big connectivity group allowing all spokes to talk to each other.

Network Groups

1. Network Groups memberships – There is a static, which allows selectively adding VNets to your network groups. You can do it either manually or by scripts, but selectively. Another option is a dynamic membership assignment. This mechanism adds VNets, that match the criteria you specify, to the defined group.
2. Network Group precedence and number of network groups – Let’s assume you have Hub and Spoke, and spokes defined in two separate network groups. You also enable direct connectivity. Even though the VNets are in the same region, the precedence in establishing the communication is taken by the network group. So the network group is a boundary when it comes to the scope of the effectiveness of direct connectivity within the Hub and Spoke model. There is a great reason, why you may want to have multiple network groups in AVNM. It may be to limit the direct communication between the VNets within the same network group. You may want to have different admin rules, and control different aspects of connectivity within your environment. This adds a layer of consideration to your network planning.

Security considerations for Azure Virtual Network Manager

1. Security admin rules precedence – Security admin rules are high-priority rules. They take precedence over any Network Security Groups (NSG) rules. They can be used to enforce policies across your network groups within AVNM.
2. Security admin rule works similar to NSG regarding destination, source, IP, ports, protocols, etc. However, its association is at a different level. NSG is associated with Subnet or NIC, and the security admin rule is appended to VNet.

Which security admin rules’ actions to choose?

With the security admin rule, you have a certain path to consider. First, there is the precedent rule (at the highest level of your hierarchy). Then, this rule may be going through the lower level security admin rules, before reaching the network security groups. These NSGs are assigned at the subnet or NIC level, outside the rules of AVNM. With just ‘allow’ action, the security admin rule allows you to differentiate the rules within your environment.

1. E.g. overall you have ‘allow’, but for some VNets (under control of another AVNM), subnets, or NICs (under control of NSGs) you may have ‘deny’. Then with just allow, the top-level security admin rule will not override the lower rules.
2. One possible solution is to block the traffic at the top level. Then, certain traffic will not even reach the lower level. However, it will not be allowed everywhere for the whole scope of the environment under the AVNM.
3. Another option is to choose ‘always allow’ action, then no matter what other rules are set in the lower hierarchy, this one will always have precedence. This will not go through any lower security rules. Therefore, it is so important to incorporate it into your planning, to ensure that the rules that must apply to the whole environment, will always be effective.
   Of course, if at the end of the route we have any NVA or Firewall, and there is a different rule, it can stop the traffic there.

Regions

You can choose which regions to target while deploying your configuration. Why is this an option? Looking at what AVNM is capable of, this is the option to limit the scope of your impact. First test the rules, in a somewhat isolated environment, to assess how it is performing, before going all-in.

Costs in AVNM

You pay per subscription managed within the scope of Azure Virtual Network Manager per hour. If a subscription is managed by a few AVMNs, then you pay for this subscription, as many times as the subscription exists in AVNMs. Please note, that for Hub and Spoke setup, besides costs for AVNM, you also pay additionally for peering traffic, that is created by AVNM.