Network Security Groups and Application Security Groups

A Network Security Group (NSG) acts as a virtual firewall for Azure resources. It contains a list of security rules that allow or deny inbound and outbound network traffic based on source IP, destination IP, port number, and protocol. NSGs can be associated with subnets (affecting all resources in the subnet) or with individual network interfaces (affecting a single VM). When both a subnet NSG and a NIC NSG exist, Azure evaluates both — for inbound traffic, the subnet NSG is applied first; for outbound, the NIC NSG is applied first.

Each NSG rule has the following properties: Priority — a number between 100 and 4096; lower numbers are evaluated first. Source/Destination — an IP address, CIDR range, service tag, or application security group. Source/Destination Port — specific port numbers or ranges (e.g., 80, 443, 3389, or 1024-65535). Protocol — TCP, UDP, ICMP, or Any. Action — Allow or Deny. Rules are evaluated in priority order; the first matching rule wins. If no rule matches, the default rules apply: deny all inbound and allow all outbound traffic.

Every NSG comes with three default inbound rules and three default outbound rules with priorities 65000-65500 that cannot be deleted. Default inbound rules: AllowVnetInBound (allow traffic from VNet), AllowAzureLoadBalancerInBound (allow Azure health probes), DenyAllInBound (deny everything else). Default outbound rules: AllowVnetOutBound, AllowInternetOutBound, DenyAllOutBound. You can override defaults by adding rules with lower priority numbers (100-64999) that take effect before the defaults.

Service tags are predefined groups of IP address ranges for Azure services, allowing you to write concise NSG rules without specifying long lists of IP addresses that change over time. Common service tags include: Internet — all IP addresses outside the VNet. VirtualNetwork — all IPs within the VNet. AzureLoadBalancer — Azure's infrastructure load balancer IP. Storage — Azure Storage service IPs for the chosen region. AzureActiveDirectory — Entra ID endpoints. Microsoft maintains these tags automatically, so your NSG rules stay accurate even as service IPs change.

Associating an NSG with a subnet applies its rules to all resources in that subnet, making it the most efficient way to enforce network policies at scale. For example, associating a 'DenyRDP' NSG with a data-tier subnet prevents any VM in that subnet from being accessed via RDP (port 3389) from outside — regardless of what NIC-level NSGs allow. This subnet-level NSG acts as the first line of defence before traffic even reaches individual VMs, reducing the attack surface at the network boundary.

Application Security Groups (ASGs) allow you to group Azure VM network interfaces by application role rather than by IP address. For example, you create ASGs named webServers, appServers, and dbServers, then assign each VM's NIC to the appropriate ASG. In your NSG rules, you can then write: 'Allow traffic from webServers to appServers on port 8080' — without specifying any IP addresses. When you add or remove VMs, you simply update their ASG membership, and all NSG rules automatically apply correctly without any rule changes.

Once ASGs are defined and VMs are assigned, you write NSG rules that reference ASGs as source or destination. This approach is much more maintainable than IP-based rules because: No IP management — you do not need to know VM IPs; ASG membership handles the mapping. Dynamic scaling — new VMs automatically inherit the correct rules when added to the right ASG. Semantic clarity — rules read naturally ('webServers → appServers on 8080') rather than as opaque IP ranges. ASGs are especially valuable in dynamic environments where VMs are frequently added or replaced.

NSG Flow Logs record information about all IP traffic flowing through an NSG, including source and destination IP, port, protocol, whether the traffic was allowed or denied, and bytes transferred. Flow logs are written to an Azure Storage account in JSON format and can be visualised in Azure Network Watcher's Traffic Analytics tool. Flow logs are invaluable for troubleshooting connectivity problems ('why is this traffic being blocked?'), security investigations, and compliance reporting that requires evidence of traffic patterns.

Three common NSG mistakes that cause connectivity problems: Forgetting the evaluation order — if a Deny rule with priority 100 exists and your Allow rule has priority 200, the traffic is denied because lower priority numbers win. Blocking Azure health probes — Load Balancer health probes come from IP 168.63.129.16; blocking this source causes load balancer backends to appear unhealthy and stop receiving traffic. Overlapping subnet and NIC NSGs — traffic must pass both NSG evaluations; a rule allowing traffic at the subnet NSG will still be blocked if the NIC NSG denies it.

NSGs and Azure Firewall are complementary but different: NSGs — decentralised, attached to subnets and NICs, Layer 3/4 (IP and port) filtering, no traffic logging by default, free with every VNet. Azure Firewall — centralised, managed service in a hub VNet, Layer 3/4 AND Layer 7 (FQDN, URL, IDPS), full logging via Azure Monitor, and cost ~$1,000+/month. Use NSGs for basic perimeter and tier isolation. Use Azure Firewall when you need central, auditable enforcement of outbound internet access with FQDN filtering, threat intelligence, or TLS inspection.

When an NSG is associated with both a subnet and a NIC, you may lose track of which rules are actually applied. Azure provides the Effective Security Rules view in the portal for any VM's NIC, showing the combined result of all NSG rules from both the subnet and NIC level. This is the definitive list of what is actually allowed or denied for that VM. The Azure Network Watcher IP flow verify tool takes this further — you specify a source and destination IP/port and it tells you instantly whether the traffic would be allowed or denied and which specific rule is responsible.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: NSGs contain allow/deny rules evaluated in priority order that filter traffic for subnets or individual network interfaces, service tags simplify rules by representing dynamic groups of Azure service IP ranges, and Application Security Groups allow role-based grouping of VMs for maintenance-free NSG rules that scale with your environment. Next up we explore VNet Peering and Service Endpoints for connecting resources across VNets and to Azure services.