Associating Azure Network Security Groups

In this post, I will explain how the two options for associating a network security group (NSG) work, virtual machine NIC or subnet, and I’ll recommend a method to use.
 

 

Associate with a NIC

The first way to associate an NSG is to associate with a NIC; this is the method used when you next-next-next your way through creating a virtual machine in the Azure Portal. My choice of words might hint at my attitude to that but more on this later.
When you associate an NSG with a virtual machine’s NIC, the inbound and outbound rules allow or deny packets as the hit the NIC.

 
Any inbound rule is applied after traffic leaves the subnet and attempts entry to the virtual machine via the NIC. A deny rule will drop the packet at this point and an allow rule will allow the packet in to be further inspected by any firewall in the guest OS, such as the Windows Firewall.
Associating an NSG with a NIC is very powerful and granular but in no time at all, this approach will become a nightmare to manage. One could have one NSG for lots of virtual machines but that will quickly become unworkable as rules become specialized and difficult to troubleshoot. In reality, this approach is OK for very small deployments that will remain very small, for example, a single virtual machine.

Associate with a Subnet

The second way to deploy an NSG in Azure is to associate it with a subnet of a virtual network. This is a deployment that you must do yourself and not featured in any default next-next-next process.
When you associate an NSG with a subnet, the inbound and outbound rules are applied to allow or deny packets when they enter the subnet. Inbound rules filter traffic as they enter the subnet. Outbound rules are applied the same way.

 
Once you have more than a few or even just one virtual machine, this is the preferred way to secure a virtual network at Layer-4 (TCP or UDP). If you apply good virtual network design practices, treating each subnet as a security boundary and placing similar machines in the same subnet, then this approach scales out. If you have a more complex subnet, such as those you might lift-and-shift migrate from on-premises, then you can use application security groups to identify roles within a subnet and apply rules to those roles.