Azure Network Virtual Manager (AVNM) is the service that allows you to manage your network setup, connectivity configuration, and security rules for your cloud environment. You can set the scope to which the defined rules are applied. You can have any instances targeting the same scope, but then you pay more, as this is per subscription per instance of AVNM payment. Additionally, even though the VNETs do not span cross-region, with AVNM you can set the connectivity rules, which establish the peerings between your VNETs. Also, you do not need, for Hub and Spoke model to deploy a transit gateway to achieve transitiveness. The Azure Virtual Network Manager (AVNM) allows you to create an overarching instance to manage and control your whole networking layer in Azure. Please note that this service is still in the preview.
What can Azure Virtual Network Manager (AVNM) do?
Azure Virtual Network Manager (AVNM) can define connectivity, and security admin rules, this is powerful. As this may have a huge impact on your environment, when you do it wrong e.g. block the traffic for the whole environment, overwriting any other set rules.
AVMN while deploying the configuration, allows being granular with rules that are being set, also you can limit the target region (more on choosing the region you can read in following post) , to proceed with testing them, before going on a full scale.
How does direct connectivity in AVNM Hub and Spoke model work?
The Azure Virtual Network Manager’s (AVNM) direct connectivity setting for Hub and Spoke, does not require any peerings to establish spoke-to-spoke communication. So when you enable the direct communication, it deploys only the peering between the Hub and Spoke (for communication). Between the spokes, the communication is resolved without the need for any peering. So this is not adding a bunch of peerings between the spokes, it uses this new concept of connectivity group that is a part of the software-defined networking of Azure. You just enable the direct connectivity between the spokes, but this communication is not hopping through a hub. It’s not using some hidden NVA somewhere (not adding hops, not adding latency).
By default, the region is still the boundary of communication between VNETs, but you can overwrite this with the rule that allows everything to talk with everything, even across the regions.
What do you need to know about configurations in Azure Virtual Network Manager (AVNM)?
For effectively applying modifications to the existing configuration (new features, network security admin rules, direct connectivity, etc.), it requires you to deploy it. You do not need to redeploy, when new network groups are created, they will be detected and applied automatically.
All these rules and configurations regarding within Azure Virtual Network Manager (AVNM) are additive. This gives you lots of flexibility. You can add manual peers if you want to. Then, they will work together with the rules of Azure Virtual Network Manager (AVNM). It is also brownfield environment friendly. If you have existing things, it will leave your settings untouched or it gives you the choice to delete them. However, remember that in some cases, the rules like disabling certain ports, protocols, etc. are overwriting the local Network Security Group (NSG) rules.
Hub and Spoke model in Azure Virtual Network Manager (AVNM)
How then Spokes are going to talk to each other? After enabling the direct connectivity, within the Spoke effective routes, you may notice the route named ConnectedGroup. This is what allows the communication between Spokes within the region (for direct connectivity).
The other thing, that happens after deploying the direct connectivity, is within the realm of Azure Policy. The rule of Azure Virtual Network Manager (AVNM) adds an additional policy assignment called AVMN Group Policy. This policy is how Azure Virtual Network Manager (AVNM) tracks the membership. This is how it gets notified when a new network comes into the group. It is leveraging Azure Policy behind the scenes, to help manage and control what happens under the hood.
Only Hub and Spoke model requires peering to allow communication between spokes and hub.
Connected Group in Azure Virtual Network Manager (AVNM)
Allowing communication between the Spokes, without the need of setting the peerings, as well as tracking what is happening with Azure Policy. This is a key point of Azure Virtual Network Manager (AVNM). The concept of ‘connectedGroup’ is resolved by the software-defined networking of Azure. It allows communication between the Spokes within the region for network groups, and with mesh across the regions, is only available through the features of AVNM. In any other case, achieving the same goal requires adding a bunch of peerings between VNETs.
A VNET can be a part of multiple connectivity configurations and can be a part of multiple ‘connectedGroups’, but it can only be a member of two. E.g. the one VNET can be a part of Hub and Spoke with direct connectivity set and a part of the mesh, or part of two meshes, or two Hub and Spokes (both with direct connectivity on).
Mesh Model
The Mesh model consists of a bunch of VNETs that can talk to each other. In Mesh Model the communication between all networks is bound by region. Azure Virtual Network Manager’s (AVNM) Mesh model establishes the communication between VNETs without the need of peering. For Mesh, the connected group is created between all the VNETs within the groups, that you add during the configuration. No matter, if the VNETs are assigned to different network groups. Optionally, you can turn on the global mesh to allow communication between VNETs located in the different regions.
Similarities between Network Security Groups (NSGs) and AVNM’s security admin configuration
Security admin configuration looks familiar to Network Security Groups (NSG), both require the following input:
- Setting the priority of the rule you set (even though the priority’s range differs).
- Choosing the action you want to enforce, whether it is allowed or denied. There is one additional action in the security admin configuration, required to override the other rules.
- Setting the protocols that are allowed, note that the security admin configuration has two protocols more.
- Information about a source like a type, IP address, and port.
Differences between Network Security Groups (NSGs) and AVNM security admin configuration
Security admin configuration and difference in comparison with NSG:
- The priority in security admin configuration range from 0 to 99. The lower the number, the higher priority. With this range, the security admin configuration can achieve precedence over NSG, as NSG’s priority starts from 100.
- In security admin configuration, like in NSG, you can pick the protocols, but there are two additional ESP and AH.
- There is also the difference in actions (in comparison to NSG). You have the options to allow and deny. Additionally, you get ‘always allow’. This means that any traffic matching these rules will be allowed. It is regardless of other rules with the lower priority or user-defined NSGs.
- The different user interface, which is not crucial, however, worth mentioning.
- The configuration of Azure Virtual Network Manager (AVNM) can overwrite NSGs. E.g. if you need certain traffic to be passed through, even though NSG tries to block it.
A few other points you should know
- Every change of configuration within the network group requires separate deployment.
- To check if you deleted the Azure Virtual Network Manager (AVNM) correctly from the environment, you can verify if you still see the VNET peering in effective routes. When the direct connection was set, also ‘ConnectedGroup’ from the effective routes section should be removed.
- If you have a well-planned environment structure, then when adding a new VNET, you can rely on your dynamic rules to automatically add it to the correct network group. All the configuration and rule sets within the environment will be automatically applied to it. Therefore, it is crucial that the planning will consist of all the factors to ensure the feasibility of this solution. Then it allows you to simplify and centralize the new network components onboarding process.
- When removing an existing configuration, you are redirected to deploy a configuration, when you have an option to choose a goal state of your configuration, where you can choose the option “none – remove existing connectivity configuration’. You can withdraw configuration with region granularity, so you do not have to withdraw it from the whole environment, just the parts that you want.
- The security admin rules of Azure Virtual Network Manager (AVNM) are checked before NSGs.
- More information on AVMN is available on Microsoft website.
