Microsoft Azure provides different services to monitor and control network. Application Security Group (ASG) and Network security group (NSG) are two of those services. Though designed to serve entirely different purpose, the similarity in the name is often the point of confusion.

In this article I briefly talk about NSG and ASG along with key differences between them.

Table of contents:

Network Security Group

Azure network security group (NSG) is used to filter network traffic between Azure resources in an Azure virtual network. We can create security rules to allow or deny inbound network traffic to, or outbound network traffic from, several types of Azure resources. For each rule, you can specify source and destination, port, and protocol.

Security rules are evaluated and applied based on the five-tuple (source, source port, destination, destination port, and protocol) information. You can’t create two security rules with the same priority and direction. A flow record is created for existing connections. Communication is allowed or denied based on the connection state of the flow record. The flow record allows a network security group to be stateful.

Reference the above picture, along with the following text, to understand how Azure processes inbound and outbound rules for network security groups:

Inbound traffic

For inbound traffic, Azure processes the rules in a network security group associated to a subnet first, if there’s one, and then the rules in a network security group associated to the network interface, if there’s one. This includes intra-subnet traffic as well.

  • VM1: The security rules in NSG1 are processed, since it’s associated to Subnet1 and VM1 is in Subnet1. Unless you’ve created a rule that allows port 80 inbound, the traffic is denied by the DenyAllInbound default security rule, and never evaluated by NSG2, since NSG2 is associated to the network interface. If NSG1 has a security rule that allows port 80, the traffic is then processed by NSG2. To allow port 80 to the virtual machine, both NSG1 and NSG2 must have a rule that allows port 80 from the internet.
  • VM2: The rules in NSG1 are processed because VM2 is also in Subnet1. Since VM2 doesn’t have a network security group associated to its network interface, it receives all traffic allowed through NSG1 or is denied all traffic denied by NSG1. Traffic is either allowed or denied to all resources in the same subnet when a network security group is associated to a subnet.
  • VM3: Since there’s no network security group associated to Subnet2, traffic is allowed into the subnet and processed by NSG2, because NSG2 is associated to the network interface attached to VM3.
  • VM4: Traffic is allowed to VM4, because a network security group isn’t associated to Subnet3, or the network interface in the virtual machine. All network traffic is allowed through a subnet and network interface if they don’t have a network security group associated to them.

Outbound traffic

For outbound traffic, Azure processes the rules in a network security group associated to a network interface first, if there’s one, and then the rules in a network security group associated to the subnet, if there’s one. This includes intra-subnet traffic as well.

  • VM1: The security rules in NSG2 are processed. Unless you create a security rule that denies port 80 outbound to the internet, the traffic is allowed by the AllowInternetOutbound default security rule in both NSG1 and NSG2. If NSG2 has a security rule that denies port 80, the traffic is denied, and never evaluated by NSG1. To deny port 80 from the virtual machine, either, or both of the network security groups must have a rule that denies port 80 to the internet.
  • VM2: All traffic is sent through the network interface to the subnet, since the network interface attached to VM2 doesn’t have a network security group associated to it. The rules in NSG1 are processed.
  • VM3: If NSG2 has a security rule that denies port 80, the traffic is denied. If NSG2 has a security rule that allows port 80, then port 80 is allowed outbound to the internet, since a network security group isn’t associated to Subnet2.
  • VM4: All network traffic is allowed from VM4, because a network security group isn’t associated to the network interface attached to the virtual machine, or to Subnet3.

Application Security Group

Application security groups enable you to configure network security as a natural extension of an application’s structure, allowing you to group virtual machines and define network security policies based on those groups. You can reuse your security policy at scale without manual maintenance of explicit IP addresses. The platform handles the complexity of explicit IP addresses and multiple rule sets, allowing you to focus on your business logic. To better understand application security groups, consider the following example:

Application security groups

In the above picture, NIC1 and NIC2 are members of the AsgWeb application security group. NIC3 is a member of the AsgLogic application security group. NIC4 is a member of the AsgDb application security group. Though each network interface in this example is a member of only one network security group, a network interface can be a member of multiple application security groups, up to the Azure limits.

ASGs introduce the ability to deploy multiple applications within the same subnet, and isolate traffic based on ASGs. With ASGs you can reduce the number of NSGs in your subscription. In some cases, you can use a single NSG for multiple subnets of your virtual network. ASGs enable you to centralize your configuration, providing the following benefits in dynamic environments

Conclusion

ASGs introduce the ability to deploy multiple applications within the same subnet, and isolate traffic based on ASGs whereas NSGs can be used to filter network traffic to different Azure resources. Application Security Groups along with the latest improvements in NSGs, have brought multiple benefits on the network security area, such as a single management experience, increased limits on multiple dimensions, a great level of simplification, and a natural integration with your architecture, begin today and experience these capabilities on your virtual networks.