Azure network security groups: effective rules, ASGs, and traffic control

radio_button_uncheckedshort_text1. Turn the migration requirement into traffic policy

A company with several locations will move critical systems to Azure only if it can tightly control which computers reach its application servers and Azure services. A network security group (NSG) supplies distributed Layer 3 and Layer 4 filtering for resources in a Virtual Network. Its security rules allow or deny inbound and outbound flows.

This chapter develops the complete administrative task: choose where an NSG belongs, design rules from the five-tuple, understand default and effective rules, organize changing workloads with application security groups (ASGs), run the supplied lab, and troubleshoot the result with current Azure tools.

• Determine when to use an NSG and associate it with a subnet or network interface.
• Create, prioritize, implement, and evaluate inbound and outbound security rules.
• Explain augmented rules, service tags, stateful filtering, and effective rules.
• Use ASGs to express application roles without maintaining individual IP addresses.
• Implement the virtual-networking, NSG, ASG, and optional DNS laboratory.

radio_button_uncheckedshort_text2. What an NSG controls—and what it does not

An NSG is a reusable collection of allow and deny rules. It can be associated multiple times, but each subnet and each network interface can have at most one directly associated NSG. A subnet association applies the policy to every supported resource in that subnet; a NIC association adds resource-specific filtering for traffic through that interface.

• NSGs filter traffic; they do not create a route, public endpoint, DNS answer, or outbound translation path.
• Rules operate on IP addresses, protocols, and ports, not URL paths, HTTP headers, user identities, or malware content.
• The virtual-machine overview and the network resource pages show associated subnets, NICs, NSGs, and rules.
• If no NSG is associated at a level, traffic is not filtered by an NSG at that level; other platform, route, firewall, and guest controls can still apply.

radio_button_uncheckedshort_text3. Subnet scope, NIC scope, and a screened subnet

A screened subnet, traditionally called a DMZ, buffers internet-facing resources from trusted internal systems. An NSG can restrict the screened subnet, while an Azure Firewall or another inspection service supplies richer centralized policy when required.

radio_button_uncheckedshort_text4. Every custom rule describes a five-tuple and a decision

Azure evaluates source address, source port, destination address, destination port, and protocol. For inbound traffic, public-to-private address translation occurs before NSG processing; use the destination’s private address when a rule targets a specific Azure resource. Outbound NSG processing happens before private-to-public translation.

radio_button_uncheckedshort_text5. Priority makes the first matching rule decisive

Custom rules are processed from the lowest priority number to the highest. When a packet matches, Azure applies the action and stops evaluating later rules in that NSG. Leave deliberate gaps such as 100, 200, and 300 so an urgent rule can be inserted without renumbering the policy.

• A priority of 100 takes precedence over 110 or 200.
• An Allow at 100 can make a broader Deny at 200 irrelevant for the matching flow.
• A Deny at 100 blocks the flow even if a broader Allow exists at 300.
• Priority values may be reused in the opposite direction; the conflict restriction is the same priority and direction.
• Default rules use 65000, 65001, and 65500, so any valid custom priority is evaluated first.

radio_button_uncheckedshort_text6. Default inbound rules establish a baseline

The result is deny-by-default for unsolicited inbound traffic except traffic represented by the VirtualNetwork and AzureLoadBalancer service tags. The VirtualNetwork tag is broader than a single subnet and can include peered and connected address spaces, so do not assume the default automatically provides workload isolation.

radio_button_uncheckedshort_text7. Default outbound rules permit policy, not connectivity

These rules cannot be deleted, but a higher-priority custom rule can override them. AllowInternetOutBound means the NSG permits a matching flow; it does not supply NAT, a route, or a public address. A private subnet still needs an explicit outbound method such as NAT Gateway, Azure Firewall, or a supported Load Balancer outbound rule.

radio_button_uncheckedshort_text8. NSGs are stateful and rule changes affect new connections

An NSG keeps a flow record. If an outbound TCP connection to port 80 is allowed, the reply traffic does not require a separate inbound rule. Likewise, a response to an allowed inbound connection does not need a matching outbound rule. A rule is required when the connection is initiated in that direction.

Removing or tightening an Allow rule does not interrupt an already established connection. New and updated rules apply to new connections. During validation, close the session or generate a fresh flow before concluding that a rule change failed.

radio_button_uncheckedshort_text9. Effective evaluation across subnet and NIC scopes

For the conceptual inbound path, Azure evaluates the subnet NSG and then the NIC NSG. For outbound traffic, it evaluates the NIC NSG and then the subnet NSG. Each applicable NSG is an independent gate: an Allow at one layer cannot override a Deny or missing Allow at another.

• Inbound flow must be allowed by both the destination subnet NSG and destination NIC NSG when both exist.
• Outbound flow must be allowed by both the source NIC NSG and source subnet NSG when both exist.
• Subnet NSG rules can affect traffic between VMs in the same subnet, including traffic permitted by AllowVNetInBound.
• To isolate same-subnet VMs, add deliberate higher-priority rules and test required exceptions in both directions.
• Prefer one well-designed subnet NSG when per-NIC policy adds no business value.

radio_button_uncheckedshort_text10. Effective security rules reveal the policy that actually applies

Azure Network Watcher’s Effective security rules view aggregates inbound and outbound rules from the NIC NSG, subnet NSG, and Azure Virtual Network Manager security admin rules for a selected network interface. The portal can download the result as CSV and expand the concrete prefixes behind sources and destinations.

• Use Effective security rules to audit the final policy, not to prove packet delivery.
• Use IP flow verify to test a specific direction, protocol, local/remote address, and port against NSG and applicable security admin rules.
• Then inspect effective routes, next hop, DNS, load-balancer health, firewall policy, and the guest operating-system firewall.
• A successful NSG result means “not blocked here,” not “the application is healthy.”

radio_button_uncheckedshort_text11. Security admin rules are evaluated before NSGs

Azure Virtual Network Manager can deploy global security admin rules to VNets in managed network groups. Central governance teams define broad guardrails; application teams retain NSGs for subnet and NIC-level policy. Security admin rules are evaluated before NSGs.

Deployments use eventual consistency, and current exceptions apply to certain services and private endpoints. Effective security rules and IP flow verify help expose the combined policy instead of troubleshooting an NSG in isolation.

radio_button_uncheckedshort_text12. Create a custom rule from the service requirement

In the Azure portal, open the NSG and choose Inbound security rules or Outbound security rules. Add a rule by translating the communication requirement into source, source ports, destination, service or destination ports, protocol, action, priority, and a meaningful name.

1. Use predefined services such as SSH or RDP only when their protocol and port exactly match the requirement.
2. Use Custom for ports such as 8080 or for a controlled list or range.
3. Prefer Any for ephemeral source ports unless the initiating application has a documented fixed source port.
4. Restrict management sources; do not publish SSH or RDP to Any merely to make a test pass.
5. Document the owner, purpose, approval, expected lifetime, and validation evidence for every exception.

radio_button_uncheckedshort_text13. Augmented rules reduce policy sprawl

An augmented rule combines multiple explicit IP addresses, CIDR ranges, ports, or port ranges in one policy. For example, ports 80, 443, 8080, and 8090 can share one rule when the source, destination, protocol, direction, and action are otherwise identical.

Current guidance permits multiple explicit addresses and ports, but only one service tag per rule. ASG limits and valid combinations are subject to current platform limits. A shorter rule set is useful only if each rule still has one understandable purpose; do not combine unrelated flows merely to reduce the count.

radio_button_uncheckedshort_text14. Service tags track Azure service address ranges

Microsoft maintains the prefixes behind a service tag; customers cannot create custom service tags. Use a service tag for an Azure service, an ASG for workload NICs, and an explicit IP/CIDR only when the address itself is the policy identity.

radio_button_uncheckedshort_text15. Application security groups express workload roles

An ASG is a logical collection of network-interface IP configurations. Assign VM NICs to groups such as WebServers or AppServers, then use those groups as the source or destination of an NSG rule. The rule follows group membership when instances scale or addresses change.

• All NICs referenced through ASGs in a rule must satisfy current same-VNet constraints.
• ASGs do not filter traffic by themselves; an NSG rule must reference them.
• A NIC can participate in more than one ASG where supported and useful.
• ASGs can reduce dependence on subnet placement, but subnets remain important routing, delegation, and trust boundaries.
• New members inherit the applicable NSG policy automatically.

radio_button_uncheckedshort_text16. ASG scenario: web tier to application/SQL tier

The supplied online-retailer scenario has WebServers that receive HTTP and HTTPS from the internet and AppServers that handle SQL requests from the web tier. Create one ASG for each tier, join every server NIC to its workload group, then create the NSG and its rules.

Rule 100 keeps the public catalog reachable. Rule 110 permits the required tier-to-tier SQL flow. Rule 120 prevents direct web traffic to the application tier. The later default DenyAllInBound blocks other unsolicited inbound flows. In a production three-tier design, name the SQL destination group DataServers if it represents database servers; policy names should describe the real workload.

radio_button_uncheckedshort_text17. Why ASGs simplify operations—and their limits

• IP maintenance: scaling or replacement changes group membership, not every NSG rule.
• Logical organization: web, application, data, and service roles remain visible even when they share a subnet.
• Simplified rules: one group-based rule can apply to every current and future member.
• Workload readability: policy is easier to review when names express business function.
• Service tags remain distinct: they represent Microsoft-maintained Azure service prefixes, while ASGs represent your workload NICs.

ASGs are not a substitute for all subnet segmentation. Preserve subnet boundaries when routing, service delegation, blast radius, inspection, or lifecycle ownership requires them.

radio_button_uncheckedshort_text18. Laboratory architecture and job skills

The supplied exercise uses resource group az104-rg4 and two VNets. CoreServicesVnet uses 10.20.0.0/16 with SharedServicesSubnet 10.20.10.0/24 and DatabaseSubnet 10.20.20.0/24. ManufacturingVnet uses 10.30.0.0/16 with SensorSubnet1 10.30.20.0/24 and SensorSubnet2 10.30.21.0/24.

• Task 1: create a VNet and subnets through the portal.
• Task 2: create a VNet and subnets from a template.
• Task 3: create an ASG, an NSG, rules, associations, and the required communication.
• Task 4: optionally configure a public Azure DNS zone such as contoso.com and a private zone such as private.contoso.com.
• Allow approximately 50 minutes and use an Azure subscription where these resources are authorized.

radio_button_uncheckedshort_text19. Exercise sequence and validation

1. Create az104-rg4 in the selected region and implement CoreServicesVnet with its two nonoverlapping subnets.
2. Deploy ManufacturingVnet and its two subnets using the supplied or equivalent ARM template; review parameters before deployment.
3. Create the required ASG and assign the intended VM NIC IP configurations to it.
4. Create the NSG, add narrowly scoped inbound and outbound rules, and associate it with the intended subnet or NIC.
5. Test both an allowed flow and a denied flow with fresh connections. Record effective rules and IP flow verify results.
6. Optionally create and validate the public and private Azure DNS zones and the correct VNet link for private resolution.
7. Remove laboratory resources only after confirming the resource group contains no shared or production dependency.

radio_button_uncheckedshort_text20. Assessment answers with reasoning

radio_button_uncheckedshort_text21. Current corrections and AZ-104 traps

• NSGs filter; they do not route, perform NAT, resolve DNS, or inspect application content.
• Lower number means higher priority, and processing stops at the first match within that NSG.
• The same priority can exist once per direction; it is not globally unique across inbound and outbound.
• NSGs are stateful, so reply traffic does not need a mirrored rule and existing flows survive a rule change.
• Default AllowInternetOutBound is permission, not proof of an outbound path from a private subnet.
• Security admin rules from Azure Virtual Network Manager precede NSGs; Always Allow and Deny terminate evaluation.
• ASGs group workload NICs; service tags represent Microsoft-maintained service prefixes.
• New NSG flow logs cannot be created after June 30, 2025 and the feature retires September 30, 2027. Use virtual network flow logs for current designs.
• Effective rules show policy; IP flow verify tests a five-tuple; neither proves application health on its own.

radio_button_uncheckedshort_text22. Compact review, active recall, and resources

Active-recall prompts

• Explain the difference between an NSG and an ASG with one use case for each.
• Trace inbound and outbound evaluation when both subnet and NIC NSGs exist.
• Recreate the six default rules and their priorities from memory.
• Write the three WebServers/AppServers rules without using individual IP addresses.
• Explain why an NSG Allow does not guarantee connectivity.
• Choose between Effective security rules, IP flow verify, effective routes, and flow logs for four troubleshooting questions.

Official documentation

• Azure network security groups overview
• Network security groups and application security groups design guide
• Effective security rules in Azure Network Watcher
• IP flow verify
• Security admin rules in Azure Virtual Network Manager
• Virtual network flow logs
• Manage network security groups