This chapter covers Azure Network Security Groups (NSGs) and Application Security Groups (ASGs), two fundamental building blocks for network security in Azure. For the SC-900 exam, understanding how NSGs filter traffic at the subnet and NIC level, and how ASGs simplify rule management by grouping VMs logically, is essential. Expect 2–3 questions on this topic area (approximately 5–8% of the exam), often testing default rules, rule processing order, and the difference between NSG and ASG use cases.
Jump to a section
Imagine a large office building with multiple floors and departments. The building has a single main entrance guarded by a security desk. This desk is like a Network Security Group (NSG) — it controls all traffic entering and leaving the building based on rules (e.g., "only employees with badges can enter, and only during business hours"). Each floor has multiple rooms belonging to different teams: Sales, Engineering, HR. Each team's room is an Application Security Group (ASG) — a logical grouping of VMs that share the same security requirements. Instead of writing NSG rules for each individual room (which would be tedious and error-prone), you write rules that reference the team names. For example, a rule says "Allow traffic from Engineering to Database servers only on TCP port 1433." When a new employee joins Engineering, they get a badge that automatically places them in the Engineering ASG. The security desk (NSG) enforces the rule without needing to know the employee's name or room number. If an employee moves from Sales to Engineering, their badge is updated, and the security rules automatically apply to them. This is the core benefit of ASGs: decoupling security rules from individual IP addresses or VM names, reducing administrative overhead and preventing misconfigurations when VMs are added, removed, or resized. The analogy breaks down in that ASGs do not enforce time-based rules natively, but the concept of grouping and rule inheritance is identical.
What Are Azure Network Security Groups (NSGs)?
An Azure Network Security Group (NSG) is a stateful, distributed firewall that filters network traffic to and from Azure resources in a virtual network (VNet). It contains a set of security rules that allow or deny inbound and outbound traffic. NSGs can be associated with a subnet, a network interface (NIC), or both. When associated with a subnet, the rules apply to all VMs in that subnet. When associated with a NIC, the rules apply only to that specific VM.
How NSGs Work Internally
NSGs are implemented as a software-defined networking layer within the Azure fabric. Each rule has the following components:
Name: A unique name within the NSG.
Priority: An integer between 100 and 4096. Lower numbers have higher priority. Rules are evaluated in priority order.
Source and Destination: Can be IP addresses, CIDR blocks, service tags (e.g., Internet, VirtualNetwork), application security groups, or * (any).
Protocol: TCP, UDP, ICMP, or * (any).
Direction: Inbound or Outbound.
Action: Allow or Deny.
Port: Source and destination port ranges.
When a packet arrives at a VM, the Azure host processes it through the NSG associated with the VM's NIC (if any) and then the subnet NSG (if any). The order of evaluation depends on the direction:
Inbound traffic: First, the subnet NSG is evaluated (if associated), then the NIC NSG. If the subnet NSG denies the traffic, it is dropped before reaching the NIC NSG.
Outbound traffic: First, the NIC NSG is evaluated (if associated), then the subnet NSG.
This is different from traditional firewalls where you might expect a different order. Azure processes inbound traffic from the subnet inward to the NIC, and outbound traffic from the NIC outward to the subnet.
Default Rules
Every NSG comes with a set of default rules that cannot be deleted but can be overridden by custom rules with lower priority numbers. The default inbound rules are:
AllowVNetInBound: Priority 65000, allows all traffic from the virtual network (source VirtualNetwork) to any destination.
AllowAzureLoadBalancerInBound: Priority 65001, allows traffic from Azure Load Balancer (source AzureLoadBalancer).
DenyAllInbound: Priority 65500, denies all inbound traffic not explicitly allowed.
Default outbound rules:
AllowVnetOutBound: Priority 65000, allows all outbound traffic to the virtual network.
AllowInternetOutBound: Priority 65001, allows all outbound traffic to the internet.
DenyAllOutBound: Priority 65500, denies all outbound traffic not explicitly allowed.
Note: The default outbound rule AllowInternetOutBound is why VMs can access the internet by default. To restrict outbound access, you must add a custom rule with a higher priority (lower number) that denies internet traffic.
Rule Processing and Evaluation
Azure processes rules in priority order until a matching rule is found. If no rule matches, the traffic is denied by the default deny rule. This is a key point: NSGs are *allow by default* only for traffic that matches an allow rule; otherwise, they are *deny by default* due to the default deny rules.
Service Tags
Service tags are predefined identifiers for Azure services. They simplify rule creation by abstracting IP ranges. Common service tags include:
VirtualNetwork: Represents the entire VNet address space, connected VNets, and on-premises networks via VPN/ExpressRoute.
AzureLoadBalancer: The Azure infrastructure load balancer.
Internet: Traffic originating from outside the VNet.
Sql: Azure SQL Database and Azure Synapse Analytics.
Storage: Azure Storage.
AzureActiveDirectory: Azure AD.
Service tags cannot be used as custom tags; they are provided by Microsoft and updated automatically as IP ranges change.
Application Security Groups (ASGs)
An Application Security Group (ASG) is a logical grouping of VMs that share common security requirements. Instead of writing NSG rules with individual IP addresses, you can reference an ASG as the source or destination. This decouples security rules from the underlying infrastructure.
ASGs are defined at the NIC level. A VM's NIC can be assigned to up to 20 ASGs. ASGs exist within a resource group and can include VMs from different availability zones or even different VNets (as long as they are in the same region and subscription).
How ASGs Work with NSGs
When you create an NSG rule, you can specify an ASG as the source or destination. For example:
Allow | TCP | 443 | ASG: WebServers | ASG: AppServersThis rule allows HTTPS traffic from any VM in the WebServers ASG to any VM in the AppServers ASG. When a VM is added to the WebServers ASG, the rule automatically applies to it without modifying the NSG.
Combining NSGs and ASGs
You can associate an NSG with a subnet or NIC, and within that NSG, use ASGs in rules. The ASG itself does not filter traffic; it is merely a grouping mechanism. The filtering happens in the NSG rules that reference the ASG.
Limitations and Constraints
Number of rules: Up to 1000 rules per NSG (both inbound and outbound combined).
Number of ASGs per subscription: 3000.
Number of ASGs per NIC: 20.
Number of IPs per ASG: 4000.
Priority range: 100 to 4096.
NSGs are stateful: If you allow inbound traffic on port 80, the outbound return traffic is automatically allowed regardless of outbound rules. Similarly, if you allow outbound traffic, the inbound response is allowed.
Interaction with Other Azure Services
Azure Firewall: A managed, cloud-native firewall with advanced features like application filtering and threat intelligence. NSGs are often used in conjunction with Azure Firewall for defense in depth.
Azure DDoS Protection: Provides protection against DDoS attacks. NSGs can be used to mitigate some attacks, but DDoS Protection is separate.
VNet Peering: NSGs can control traffic between peered VNets.
Azure Bastion: NSGs must allow traffic from Azure Bastion's service tag.
Verification Commands
You can view NSG rules using Azure CLI:
az network nsg show --name MyNSG --resource-group MyRG --query "securityRules"To list effective security rules for a NIC:
az network nic show-effective-nsg --name MyNIC --resource-group MyRGThis shows the combined rules from subnet and NIC NSGs.
Important Exam Facts
NSGs filter traffic at the network layer (Layer 3/4). They do not inspect application payloads.
NSGs are stateful. This means that if you allow inbound traffic, the outbound response is automatically allowed, even if outbound rules would deny it. This is a common exam point.
You can associate an NSG to a subnet, a NIC, or both. When both are associated, the subnet NSG is evaluated first for inbound traffic, then the NIC NSG.
Default rules have priorities 65000, 65001, and 65500. Custom rules must have priorities between 100 and 4096.
ASGs are not separate firewall rules; they are referenced in NSG rules.
Service tags simplify rules but are not customizable.
NSGs are not a replacement for Azure Firewall. Azure Firewall is a managed firewall service with application-level filtering, while NSGs are basic network ACLs.
Plan IP Addressing and Subnet Layout
Before creating NSGs, design your VNet and subnets. Determine which subnets will host which tiers (web, app, database). Each subnet can have one NSG associated. Plan IP ranges to avoid overlap. For example, use 10.0.0.0/16 for the VNet, with subnets 10.0.1.0/24 for web, 10.0.2.0/24 for app, and 10.0.3.0/24 for database. This step is critical because NSG rules will reference these subnets. A common mistake is to use overly broad ranges that allow unintended traffic.
Create Network Security Group
In the Azure portal, navigate to Network Security Groups and click Create. Provide a name (e.g., WebSubnet-NSG), subscription, resource group, and region. The region must match the VNet's region. After creation, the NSG has no custom rules—only the default rules. You can also create NSGs via CLI: `az network nsg create --name WebSubnet-NSG --resource-group MyRG --location eastus`.
Define Inbound Security Rules
Add inbound rules to allow necessary traffic. For a web subnet, you might allow HTTP (TCP 80) and HTTPS (TCP 443) from the Internet. Use service tag `Internet` as source. Set priority to 100 for HTTP and 110 for HTTPS. Deny all other inbound traffic by default. Remember: lower priority numbers are evaluated first. If you have a deny rule at priority 200 and an allow rule at priority 300, the deny rule will be processed first if it matches.
Define Outbound Security Rules
By default, outbound internet traffic is allowed. To restrict outbound traffic, add a custom deny rule with higher priority (lower number) than the default allow rule (65001). For example, to block outbound internet except to specific IPs, add a rule: Deny | Any | Any | Internet | * at priority 100, then add allow rules for required destinations at lower priorities (e.g., 110).
Associate NSG with Subnet or NIC
Associate the NSG with the target subnet or NIC. For subnet association: go to the subnet in the VNet, select the NSG. For NIC association: go to the VM's networking blade, select the NIC, and associate the NSG. You can associate one NSG per subnet and up to two NSGs per NIC (one subnet NSG and one NIC NSG). If both are associated, the subnet NSG is evaluated first for inbound traffic.
Create Application Security Groups
Create ASGs for logical groupings. For example, create ASGs named WebServers, AppServers, and DatabaseServers. Assign NICs of VMs to these ASGs. In the portal, go to Application Security Groups, click Create, provide name and resource group. Then edit each VM's NIC to add the ASG. CLI: `az network asg create --name WebServers --resource-group MyRG` and `az network nic update --name WebVM-NIC --resource-group MyRG --asg WebServers`.
Update NSG Rules to Use ASGs
Modify NSG rules to reference ASGs instead of IP addresses. For example, change a rule source from a specific IP to `WebServers` ASG. This simplifies rule management. When new VMs are added to the ASG, the rules automatically apply. Ensure that the ASG exists in the same region as the NSG. You can combine ASGs with service tags and IP ranges in the same rule.
Verify Effective Rules
After configuring, verify the effective rules using the Azure portal (VM -> Networking -> Effective security rules) or CLI: `az network nic show-effective-nsg --name MyNIC --resource-group MyRG`. This shows the combined rules from all associated NSGs. Check that expected rules are present and that no unintended rules are blocking traffic. Common issues: rules with overlapping ranges causing unexpected denials.
Enterprise Scenario 1: Multi-Tier Web Application
A company deploys a three-tier web application: web servers, application servers, and database servers. They use NSGs to isolate each tier. The web subnet NSG allows inbound HTTP/HTTPS from the Internet (service tag Internet) and denies all other inbound. The app subnet NSG allows inbound traffic only from the web subnet (source IP range 10.0.1.0/24) on port 8080. The database subnet NSG allows inbound traffic only from the app subnet on port 1433 (SQL). Outbound rules are configured to allow only necessary traffic (e.g., web servers can access the internet for updates, but app and database servers cannot). This setup ensures that even if a web server is compromised, the attacker cannot directly access the database. Performance is high because NSGs are distributed and do not introduce latency. Common misconfiguration: forgetting to allow outbound responses, but NSGs are stateful, so return traffic is automatically allowed. However, if traffic originates from a different IP (e.g., a load balancer), statefulness may not cover it, requiring explicit rules.
Enterprise Scenario 2: Microservices with ASGs
A company runs a microservices architecture with hundreds of small services, each deployed in multiple VMs. Managing IP-based NSG rules is impractical because IPs change frequently due to scaling. Instead, they create ASGs for each microservice (e.g., AuthService, PaymentService, InventoryService). NSG rules reference these ASGs: for example, allow traffic from AuthService to PaymentService on port 5000. When a new instance of PaymentService is created, it is added to the PaymentService ASG, and the rules automatically apply. This reduces administrative overhead and prevents misconfigurations. The company also uses Azure Policy to enforce that all VMs must belong to at least one ASG. A pitfall: if an ASG is accidentally deleted, all VMs in it lose their security rules, potentially exposing them. Regular audits and backups of ASG assignments are recommended.
Enterprise Scenario 3: Hybrid Network with On-Premises
A company uses ExpressRoute to connect on-premises to Azure. They need to allow specific on-premises IP ranges to access Azure VMs. They create an NSG on the gateway subnet to filter traffic from on-premises. They use service tag VirtualNetwork to allow traffic from on-premises (since ExpressRoute extends the VNet). However, they must be careful: the default AllowVNetInBound rule allows all traffic from on-premises. To restrict, they add a custom rule with higher priority to deny specific IPs. They also use ASGs to group VMs that need on-premises access. A common issue: forgetting that VirtualNetwork includes on-premises addresses, which may unintentionally allow access. They mitigate by using explicit IP ranges in rules.
What SC-900 Tests on NSGs and ASGs
The SC-900 exam (objective 3.4) focuses on the fundamental concepts: what NSGs and ASGs are, their purpose, and how they differ from Azure Firewall. You will not be asked to write CLI commands, but you must understand rule components, default rules, and the stateful nature of NSGs. Key topics:
Statefulness: This is the most tested concept. Many candidates think NSGs are stateless like traditional ACLs. Remember: if you allow inbound traffic, outbound response is automatically allowed, and vice versa. This is a frequent trick question.
Default rules: Know the three default inbound and three default outbound rules, their priorities (65000, 65001, 65500), and that they cannot be deleted but can be overridden.
Association: Understand that NSGs can be associated to subnets or NICs. For inbound traffic, subnet NSG is evaluated first, then NIC NSG. For outbound, the reverse.
ASG purpose: ASGs are for grouping VMs logically to simplify rule management. They are not separate firewalls. Common wrong answer: "ASGs filter traffic independently."
Service tags: Know that service tags like Internet, VirtualNetwork, AzureLoadBalancer are predefined and cannot be customized.
Common Wrong Answers
"NSGs are stateless." This is false. NSGs are stateful. Candidates confuse them with traditional network ACLs.
"You can override default rules by deleting them." Default rules cannot be deleted; you must create custom rules with lower priority numbers to override them.
"ASGs can be used without NSGs." ASGs have no effect unless referenced in an NSG rule. They are just labels.
"NSGs can filter at the application layer (Layer 7)." NSGs operate at Layer 3/4 only. For Layer 7 filtering, use Azure Firewall or WAF.
"The default outbound rule allows all outbound traffic." The default rule AllowInternetOutBound allows outbound to the internet, but there is also a default deny rule that applies if no other rule matches.
Numbers and Values on the Exam
Priority range: 100–4096 (custom rules).
Default rule priorities: 65000, 65001, 65500.
Maximum rules per NSG: 1000.
Maximum ASGs per NIC: 20.
Maximum ASGs per subscription: 3000.
Maximum IPs per ASG: 4000.
Edge Cases
Multiple NSGs: If a NIC has an NSG and the subnet has a different NSG, both are evaluated. For inbound, subnet NSG first, then NIC NSG. For outbound, NIC NSG first, then subnet NSG.
Deny overrides allow: Because rules are processed in priority order, if a deny rule matches before an allow rule, the traffic is denied. This can be used to block specific traffic while allowing general traffic.
Service tag changes: Service tags are updated by Azure automatically. You don't need to manage IP ranges.
How to Eliminate Wrong Answers
If a question mentions "application-layer inspection" or "deep packet inspection," eliminate NSG as the answer; that's Azure Firewall.
If a question asks about "logical grouping of VMs for security rules," the answer is ASG.
If a question asks about "stateful filtering at subnet or NIC level," the answer is NSG.
If a question mentions "customizable IP ranges" for Azure services, that's not NSG service tags (they are fixed).
NSGs are stateful firewalls that filter traffic at Layer 3/4.
Default inbound rules allow VNet and Azure Load Balancer traffic; default outbound allows VNet and internet traffic.
Custom rules have priorities 100–4096; lower number = higher priority.
ASGs are logical groups of VMs used in NSG rules to simplify management.
NSGs can be associated to subnets and NICs; both can be applied simultaneously.
Inbound traffic: subnet NSG evaluated first, then NIC NSG.
Outbound traffic: NIC NSG evaluated first, then subnet NSG.
Service tags are predefined and cannot be customized.
Maximum 1000 rules per NSG, 3000 ASGs per subscription.
ASGs do not filter traffic; they are only referenced in NSG rules.
These come up on the exam all the time. Here's how to tell them apart.
Network Security Group (NSG)
Filters traffic at subnet or NIC level.
Contains allow/deny rules with priority, source, destination, port, protocol.
Stateful firewall.
Can use service tags and IP ranges.
Up to 1000 rules per NSG.
Application Security Group (ASG)
Logical grouping of VMs (NICs).
No filtering capability on its own.
Must be referenced in NSG rules to apply.
Simplifies rule management by decoupling from IPs.
Up to 20 ASGs per NIC, 3000 per subscription.
Mistake
NSGs are stateful only for TCP traffic.
Correct
NSGs are stateful for TCP, UDP, and ICMP. For example, if you allow inbound UDP on port 53 (DNS query), the outbound response is automatically allowed regardless of outbound rules.
Mistake
You can associate an NSG to a VM directly without a NIC.
Correct
NSGs are associated to subnets or NICs, not directly to VMs. When you see "associate to VM" in the portal, it is actually associating to the VM's primary NIC.
Mistake
Application Security Groups can be used to filter traffic without an NSG.
Correct
ASGs are just labels. They have no filtering capability on their own. They must be referenced in NSG rules to affect traffic.
Mistake
Default rules cannot be overridden.
Correct
Default rules can be overridden by adding custom rules with lower priority numbers (higher priority). For example, to deny all inbound traffic, add a rule with priority 100 that denies all inbound.
Mistake
NSGs can filter traffic based on domain names or URLs.
Correct
NSGs operate at Layer 3/4 (IP, port, protocol). They cannot inspect application layer data like URLs. For that, use Azure Firewall or Application Gateway WAF.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An NSG (Network Security Group) is a stateful firewall that filters network traffic based on rules. An ASG (Application Security Group) is a logical grouping of VMs that simplifies NSG rule creation by allowing you to reference the group name instead of individual IP addresses. ASGs do not filter traffic themselves; they are used within NSG rules.
No. NSGs are associated to subnets or network interfaces (NICs). When you associate an NSG to a VM in the portal, it actually associates to the VM's primary NIC. You can also associate an NSG to a subnet, which applies to all VMs in that subnet.
NSGs are stateful. This means that if you allow inbound traffic, the outbound response is automatically allowed, and vice versa. For example, if you allow inbound TCP on port 80, the outbound TCP responses on ephemeral ports are automatically permitted without an explicit outbound rule.
Default inbound rules: AllowVNetInBound (priority 65000), AllowAzureLoadBalancerInBound (65001), DenyAllInbound (65500). Default outbound rules: AllowVnetOutBound (65000), AllowInternetOutBound (65001), DenyAllOutBound (65500). These rules cannot be deleted but can be overridden with custom rules of higher priority (lower number).
Add a custom outbound rule with priority lower than 65001 (e.g., 100) that denies all outbound traffic to the Internet (source `Any`, destination `Internet`, action `Deny`). Because this rule has higher priority than the default allow rule (65001), it will be evaluated first and block the traffic.
No. ASGs are regional resources. They can only contain VMs from the same region. However, they can span multiple VNets within that region and across availability zones.
A service tag is a predefined identifier for an Azure service, such as `Internet`, `VirtualNetwork`, `AzureLoadBalancer`, `Sql`, or `Storage`. Using service tags in NSG rules simplifies rule creation because you don't need to know the specific IP ranges, which Microsoft updates automatically.
You've just covered Azure NSG and Application Security Groups — now see how well it sticks with free SC-900 practice questions. Full explanations included, no account needed.
Done with this chapter?