Master Azure NSG rules, priorities, and default inbound/outbound traffic controls to secure Azure networks and prevent misconfigurations.

Complete GuideNetwork Security GroupsPriority RulesDefault Rules

Azure Network Security Group Rules Explained:
Inbound, Outbound, Priority, and Default Rules

Every new Azure subnet ships with an NSG posture most engineers get backwards on their first guess: inbound traffic from the internet is blocked, but VNet-internal traffic and outbound internet access are both allowed, out of the box, by design. Getting the default rules wrong in your head is how "secure by default" assumptions turn into actual exposure — the fix is understanding exactly what the three inbound and three outbound default rules do, and why.

65000-65500

Priority range reserved for the six default rules — untouchable, but overridable by any custom rule with a lower number

100-4096

The actual range available for custom rule priorities — you cannot assign a custom rule into the default range

Allowed by default

VNet-internal traffic AND outbound internet access — both permitted out of the box. Only inbound-from-outside is denied

Sept 30, 2027

Full retirement date for NSG flow logs. New ones couldn't be created after mid-2025 — migrate to virtual network flow logs

Table of Contents

1. 01What an NSG Actually Is: Stateful, Layer 4, the 5-Tuple
2. 02Inbound vs Outbound Rules: Two Independent Rule Sets
3. 03Priority: How Azure Decides Which Rule Wins
4. 04The Default Rules — and the Misconception They Create
5. 05Subnet NSGs vs NIC NSGs: Both Must Independently Allow Traffic
6. 06Service Tags and Application Security Groups
7. 07A Complete Worked Example: Tracing One Packet Through the Rules
8. 08NSG Flow Logs Retirement — What to Use Instead
9. 09Step-by-Step: Building a Correct NSG Rule Set
10. 10Anti-Patterns
11. 11Frequently Asked Questions

A Network Security Group looks simple — a list of allow and deny rules — right up until a rule that looks correct doesn't behave the way its priority number, its direction, or its source scope implied it would. The mechanics underneath that simple list are precise and worth knowing exactly, not approximately: every rule is evaluated against a five-part identifier called the 5-tuple, processed in strict priority order with the first match winning and nothing evaluated after it, and layered on top of a default rule set that most engineers describe accurately in conversation and then get subtly wrong the first time they actually reason about a specific packet. This guide works through the mechanics precisely enough that "why did this traffic get through" or "why did this traffic get blocked" stops being a mystery and starts being a five-minute trace through a known, deterministic evaluation order.

Figure 1 — How one packet gets evaluated: the 5-tuple, in strict priority order, first match wins

Every NSG rule is defined by a 5-tuple (source IP, source port, destination IP, destination port, protocol) and a priority number. Azure evaluates custom rules from lowest priority number to highest, stopping at the first rule whose 5-tuple matches the packet — that rule's action (Allow or Deny) is final. Only if no custom rule matches does evaluation fall through to the default rules at priorities 65000, 65001, and 65500.

01What an NSG Actually Is: Stateful, Layer 4, the 5-TupleDefinition

A Network Security Group is a stateful, Layer 4 packet filter — a list of allow/deny rules Azure evaluates against every packet's five-part identity, attachable directly to a subnet or a network interface with no additional infrastructure required.

• The 5-tuple. Every rule and every packet are compared on exactly five properties: source IP, source port, destination IP, destination port, and protocol. A rule matches a packet only when all five criteria align.
• Stateful. If a connection is allowed in one direction, the return traffic is automatically permitted, regardless of what the rules for the opposite direction say. You don't need a matching outbound rule for the response to an allowed inbound request, or vice versa.
• Layer 4, not Layer 7. NSGs filter on IP, port, and protocol — they have no awareness of application-layer content (URLs, HTTP headers, payload inspection). That's Azure Firewall's or a WAF's job, layered on top.
• Does nothing until attached. Creating an NSG has no effect on any traffic until it's associated with a subnet, a network interface, or both.

"Stateful" is what makes NSG rule sets far simpler than they'd otherwise need to be

Because NSGs are stateful, you don't need to write a matching outbound Allow rule just so an inbound-permitted connection's responses can leave the VM — the platform tracks the connection and permits the return traffic automatically. This is a real simplification worth appreciating explicitly: a purely stateless firewall would require symmetric inbound and outbound rules for every legitimate conversation, roughly doubling the rule-writing burden for no security benefit.

02Inbound vs Outbound Rules: Two Independent Rule SetsConcept

Every NSG maintains two entirely separate rule lists — inbound and outbound — each with its own priority ordering and its own default rules. A packet's direction determines which list applies; the two lists never interact directly (aside from the stateful return-traffic behavior covered above).

Direction	Governs	Common use
Inbound	Traffic arriving at the resource — from the internet, from other subnets, from on-premises	Restricting what can initiate a connection TO your VM (RDP, SSH, HTTPS from specific sources)
Outbound	Traffic leaving the resource — to the internet, to other subnets, to on-premises	Restricting where your VM can initiate connections TO (data exfiltration prevention, egress control)

Outbound rules are the ones most commonly forgotten — and that's the actual data exfiltration risk

Teams reliably spend far more attention hardening inbound rules than outbound ones, which is backwards from a risk perspective in one specific way: a compromised VM's ability to exfiltrate data or communicate with a command-and-control server is governed by outbound rules, not inbound ones. The default AllowInternetOutBound rule (Section 4) means, out of the box, any VM can reach any internet destination — a real, permissive default that production environments handling sensitive data should deliberately override, not leave unexamined because "we already locked down inbound."

03Priority: How Azure Decides Which Rule WinsConcept

Priority is a number between 100 and 4096 for any custom rule, and it's the single mechanism that resolves conflicts when multiple rules could apply to the same traffic. Lower numbers mean higher priority — checked first — and the first rule whose 5-tuple matches wins outright, with no further rules evaluated afterward.

Property	Detail
Custom rule range	100 to 4096
Default rule range	65000 to 65500 — reserved, not usable for custom rules
Same priority, same direction	Not allowed — Azure rejects creating two rules with an identical priority and direction
Evaluation order	Lowest number first; first 5-tuple match wins; evaluation stops immediately
No match found	Falls through to the default rules (Section 4)

Leave gaps between priority numbers deliberately — don't pack rules at 100, 101, 102...

A common, low-effort best practice: space custom rule priorities out (100, 200, 300, rather than 100, 101, 102) specifically so a future rule can be inserted between two existing ones without renumbering anything already in place. Renumbering existing rules to make room is a real, avoidable source of accidental precedence changes — a rule that used to be evaluated before another can silently swap positions if priorities have to be shuffled to fit a new one in.

04The Default Rules — and the Misconception They CreateCorrection

Every NSG ships with six default rules — three inbound, three outbound — that cannot be deleted, only overridden by a custom rule at a lower (higher-precedence) priority number. Knowing them precisely matters, because the common mental shortcut ("NSGs deny by default") is only half true.

Rule	Priority	Direction	Effect
AllowVNetInBound	65000	Inbound	Allows ALL traffic originating from within the virtual network (including peered VNets)
AllowAzureLoadBalancerInBound	65001	Inbound	Allows Azure Load Balancer health probe traffic
DenyAllInBound	65500	Inbound	Denies everything else inbound — this is the only genuinely "deny by default" piece
AllowVNetOutBound	65000	Outbound	Allows ALL outbound traffic to the virtual network
AllowInternetOutBound	65001	Outbound	Allows ALL outbound traffic to the internet
DenyAllOutBound	65500	Outbound	Denies everything else outbound

The actual default posture: deny inbound FROM OUTSIDE the VNet, allow almost everything else

Stated precisely: a brand-new NSG with only default rules denies inbound traffic originating from outside the virtual network, but allows all inbound traffic from within the VNet, allows all outbound traffic to the VNet, AND allows all outbound traffic to the internet. Two of those three "allow" defaults surprise people who assumed NSGs behave like a strict, zero-trust-by-default firewall. In particular, AllowInternetOutBound means every VM can reach the internet freely the moment it's created, with no custom rule required — fine for many workloads, a real gap to close deliberately for anything handling sensitive data.

Azure CLI — override the permissive outbound default with an explicit, lower-priority rule# Deny all outbound internet traffic EXCEPT what you explicitly allow. # Priority 4000 fires BEFORE the default AllowInternetOutBound at 65001. az network nsg rule create \ --resource-group myResourceGroup \ --nsg-name myVM-nsg \ --name Deny-Internet-Outbound \ --priority 4000 \ --direction Outbound \ --access Deny \ --protocol '*' \ --source-address-prefixes '*' \ --destination-address-prefixes Internet \ --destination-port-ranges '*' # Then add specific, narrower Allow rules at LOWER priority numbers # (e.g. 100, 200) for exactly the outbound destinations this VM # genuinely needs - Windows Update endpoints, specific SaaS APIs, etc.

A common, ineffective mistake: adding a "Deny All" at a priority number ABOVE the defaults

Adding a custom DenyAllInbound-style rule at priority 65400 (still lower than the default DenyAllInBound's 65500, but higher than AllowVNetInBound's 65000) accomplishes nothing new for VNet-internal traffic — AllowVNetInBound at 65000 already matches and wins first. To actually restrict VNet-internal traffic, the deny rule needs a priority number lower than 65000, in the normal custom range (100-4096), so it's evaluated before the default Allow fires.

05Subnet NSGs vs NIC NSGs: Both Must Independently Allow TrafficDeep Dive

An NSG can be attached to a subnet, a network interface, or both simultaneously. When both are in play, traffic must pass both independently — Microsoft's own current design guidance states this precisely: the most restrictive combination wins.

Traffic direction	Evaluation order
Inbound	Subnet NSG evaluated first, then NIC NSG — both must allow
Outbound	NIC NSG evaluated first, then subnet NSG — both must allow

This is documented as a genuine source of troubleshooting complexity, not just a theoretical edge case

Attaching different NSGs to both a subnet and a NIC creates what's accurately described as a double-filter — technically more granular, but in practice, this layering is a frequent, real source of "why is my correctly-configured rule not working" confusion. If the subnet NSG denies traffic on a given port, it doesn't matter how permissive the NIC NSG is — the subnet layer blocks it first, and vice versa for outbound. Section 7 walks a complete, realistic example of exactly this scenario.

Minimize the number of NSGs you actually maintain — apply at subnet level by default

Current Azure networking best-practice guidance recommends applying NSGs at the subnet level by default, reserving NIC-level NSGs specifically for cases where individual VMs within the same subnet genuinely need different security policies from their neighbors. Defaulting to NIC-level NSGs everywhere multiplies the number of rule sets to keep consistent and dramatically increases the surface area for exactly the kind of dual-NSG confusion this section describes.

06Service Tags and Application Security GroupsDeep Dive

Two features exist specifically to keep NSG rules maintainable as an environment grows, replacing hardcoded IP addresses with names that track Azure's own infrastructure or your application's actual role structure automatically.

Feature	What it replaces	Example
Service tags	Hardcoded IP ranges for Azure services or constructs	VirtualNetwork, AzureLoadBalancer, Internet, Storage, Sql — Microsoft maintains these automatically as underlying IPs change
Application Security Groups (ASGs)	Hardcoded IP addresses for your own VMs, grouped by role	Group web-tier VMs into AsgWeb, reference AsgWeb in a rule instead of each VM's individual IP

Azure CLI — an NSG rule using both a service tag and an ASG# Allow web-tier VMs (AsgWeb) to reach the database tier (AsgDb) # on the SQL port, without hardcoding any IP addresses. az network nsg rule create \ --resource-group myResourceGroup \ --nsg-name nsg-db-tier \ --name Allow-Database-From-WebTier \ --priority 200 \ --direction Inbound \ --access Allow \ --protocol Tcp \ --source-asgs AsgWeb \ --destination-asgs AsgDb \ --destination-port-ranges 1433 # If a new web-tier VM is added later, adding its NIC to AsgWeb # extends this rule automatically - no rule edit required.

ASGs simplify by describing intent, not by adding capability the underlying 5-tuple lacks

An ASG-based rule is functionally identical to writing the same rule against every current member's individual IP address — the difference is entirely about maintainability. As VMs are added to or removed from an ASG, every rule referencing that ASG updates its effective scope automatically, without editing the rule itself. One real constraint worth knowing: every network interface in an ASG must exist in the same virtual network as the first network interface assigned to that ASG — you can't mix VMs from different VNets into a single ASG.

Figure 2 — Worked example: SSH allowed at the NIC layer, still blocked, because the subnet layer denies it first

Adapted from Microsoft's own documented example: web traffic on port 443 passes both the subnet and NIC NSG because neither has a specific deny rule for it. SSH on port 22 from an internet-based management IP is explicitly denied at the subnet layer — even though the NIC-level NSG on the same VM would have allowed it. Because inbound traffic checks the subnet NSG first, the NIC NSG's more permissive rule never even gets evaluated. The fix has to happen at whichever layer is actually doing the blocking, not the layer that looks more specific.

07A Complete Worked Example: Tracing One Packet Through the RulesApplied

Putting the whole model together, precisely: an inbound SSH connection attempt from a specific management IP address, arriving at a VM whose subnet has one NSG and whose NIC has a different NSG.

Step	What Azure checks	Result
1	Direction: inbound. For inbound traffic, the SUBNET NSG is evaluated first.	Proceed to subnet NSG's rule list
2	Subnet NSG custom rules, checked lowest priority first, against the packet's 5-tuple	Rule at priority 300: "Deny TCP port 22 from Internet" — matches (source is outside the VNet)
3	First match found — evaluation stops immediately	Traffic DENIED at the subnet layer. The NIC NSG is never consulted.

Even though the NIC-level NSG on this same VM has a rule explicitly allowing SSH from this exact management IP range, that rule is irrelevant to the outcome — the connection never reaches NIC-level evaluation at all, because inbound traffic checks the subnet layer first and a match there ends the process. The fix has to be applied at the subnet NSG specifically: either add an explicit Allow rule for the management IP range at a lower priority number than the existing Deny, or remove/adjust the subnet-level Deny rule if it's no longer intended to apply this broadly.

The general debugging principle this example teaches: identify WHICH layer is actually blocking before changing anything

A team hitting this exact scenario often reaches first for the NIC NSG, since that's frequently the more actively-managed, per-VM rule set — and changing it accomplishes nothing, because the subnet layer was never reached. Azure's Effective Security Rules view for a NIC, or Network Watcher's IP Flow Verify tool, both surface exactly which specific rule (and by extension, which layer) is responsible for a given Allow or Deny outcome — use one of these to confirm the actual blocking layer before editing any rule, rather than guessing which NSG to change first.

08NSG Flow Logs Retirement — What to Use InsteadCurrent Status

A genuinely current fact worth flagging explicitly for anyone building monitoring or auditing around NSG rule behavior: NSG flow logs are being retired.

Milestone	Effect
After June 30, 2025	New NSG flow logs can no longer be created
September 30, 2027	Full retirement — traffic analytics for NSG flow logs stops working, existing NSG flow log resources are deleted
Recorded log data	Existing flow log records already written to Azure Storage are NOT deleted, and continue to follow their configured retention policy

Microsoft's own guidance recommends migrating to virtual network flow logs, positioned as addressing NSG flow logs' limitations. Any team relying on NSG flow logs for security monitoring, traffic analytics, or compliance auditing should plan this migration deliberately rather than discovering the retirement mid-incident when logs unexpectedly stop.

If you haven't already migrated, this is worth prioritizing now, not near the 2027 deadline

Because new NSG flow logs can no longer be created at all (as of mid-2025), any new NSG deployed today needs virtual network flow logs from the start if flow-level visibility is required — there's no option to defer this decision to closer to the 2027 retirement date for a fresh deployment. For existing NSG flow logs still running, treat the 2027 date as a hard deadline for migration, not a soft target, since traffic analytics support stops working at that point and the flow log resources themselves are deleted.

09Step-by-Step: Building a Correct NSG Rule SetHow-To

1. Decide subnet-level or NIC-level attachment — default to subnet

   Apply the NSG at the subnet level unless a specific VM within that subnet genuinely needs a different policy from its neighbors. This avoids the dual-NSG complexity covered in Section 5 and 7 unless there's a real reason to accept it.

2. Create Application Security Groups for each distinct role in your architecture

   Group VMs by function (web tier, app tier, database tier) before writing any rules, so rules can reference roles rather than individual IPs from the start.

3. Write inbound Allow rules for exactly the traffic each tier needs, using service tags and ASGs

   Scope source and destination as narrowly as the actual requirement allows — a specific ASG or service tag rather than * wherever possible. Space priority numbers out (100, 200, 300) to leave room for future insertions.

4. Explicitly review and override the permissive outbound defaults if the workload requires it

   Decide deliberately whether AllowInternetOutBound's default permissiveness is acceptable for this workload. For anything handling sensitive data, add an explicit Deny-Internet-Outbound rule at a custom priority, then allow only the specific destinations actually required.

5. Verify the final rule set with Effective Security Rules, not just the rules you wrote

   Especially if both subnet and NIC NSGs are in play, check the combined effective rule set for the actual NIC in question — this is the true, enforced outcome, not any single NSG's rule list viewed in isolation.

6. Test with IP Flow Verify from the actual source IPs real traffic will use

   Confirm both the intended Allow and the intended Deny behaviors explicitly, from representative source addresses — don't assume correctness from reading the rule list alone.

7. Configure virtual network flow logs, not NSG flow logs, for ongoing visibility

   Given NSG flow logs can no longer be created, set up virtual network flow logs from the start for any new environment needing traffic-level audit visibility.

10Anti-PatternsTraps

Anti-pattern	Why it feels right	Why it isn't
Assuming NSGs deny everything by default	"Firewalls are deny-by-default"	VNet-internal traffic and outbound internet access are both allowed by default. Only inbound-from-outside-the-VNet is denied out of the box
Adding a "Deny All" rule at a priority number above 65000	"Lower priority number should be more restrictive... wait, higher?"	Any priority at or above 65000 is either invalid or evaluated after the defaults that already allow the traffic — accomplishes nothing for VNet-internal or internet-outbound traffic
Attaching different NSGs to subnet and NIC without a specific reason	"More layers of security"	Creates a documented, common source of troubleshooting confusion — traffic must pass both independently, and the more restrictive one silently wins regardless of the other's intent
Editing the NIC NSG when a subnet-level rule is actually the block	"NIC rules are usually the more specific, actively-managed ones"	If the subnet layer denies the traffic first (for inbound), the NIC layer is never even evaluated — confirm which layer is responsible before editing either
Packing custom rule priorities tightly (100, 101, 102...)	"Simple, sequential numbering"	Leaves no room to insert a new rule between two existing ones without renumbering, risking accidental precedence changes to rules that already work correctly
Continuing to rely on NSG flow logs for new deployments	"They've always worked fine"	New NSG flow logs can no longer be created as of mid-2025, and the feature fully retires September 30, 2027 — migrate to virtual network flow logs now, not near the deadline

Key Takeaways

→NSGs are not deny-by-default in the way most people assume. Only inbound-from-outside-the-VNet is denied by default — VNet-internal traffic and outbound internet access are both permitted, out of the box.

→Custom rule priorities run 100-4096; defaults occupy 65000-65500. These ranges never overlap — a custom rule can't be assigned into the default range.

→First 5-tuple match wins, and evaluation stops immediately. Rule order (priority) matters as much as rule content — two correctly-written rules in the wrong relative order can produce the opposite of intended behavior.

→Subnet and NIC NSGs are evaluated independently, and both must allow the traffic. Inbound checks subnet first; outbound checks NIC first. The more restrictive layer wins regardless of the other's intent.

→Service tags and ASGs describe intent, not new capability. They keep rules maintainable as infrastructure changes, functionally equivalent to hardcoded IPs at any given moment.

→Use Effective Security Rules or IP Flow Verify to confirm the actual enforced outcome. Don't reason from a single NSG's rule list in isolation when both subnet and NIC NSGs are in play.

→NSG flow logs are retiring — migrate to virtual network flow logs now. New NSG flow logs can no longer be created; full retirement is September 30, 2027.

Frequently Asked Questions

Do Azure NSGs block all traffic by default?

No, and this is one of the most commonly misunderstood aspects of how NSGs actually behave. A brand-new NSG's default rule set denies inbound traffic originating from outside the virtual network (via the DenyAllInBound rule at priority 65500), but it explicitly allows all inbound traffic from within the VNet (AllowVNetInBound, priority 65000), all outbound traffic to the VNet (AllowVNetOutBound, priority 65000), and — often the most surprising one — all outbound traffic to the internet (AllowInternetOutBound, priority 65001). So the accurate summary is: inbound access from outside your virtual network is blocked by default, but VNet-internal communication and outbound internet access are both permitted by default, with no custom rule required. Anyone assuming a strict, zero-trust-by-default posture on outbound traffic needs to add explicit rules to achieve that — it isn't the out-of-the-box behavior.

What priority number should I use for a custom NSG rule?

Custom rules must use a priority number between 100 and 4096 — the range from 65000 to 65500 is reserved exclusively for the six default rules and can't be assigned to a custom rule. Within the 100-4096 range, lower numbers are evaluated first and take precedence; the first rule whose 5-tuple matches a given packet wins, with no further rules evaluated afterward. A practical best practice is to space custom rule priorities out — using 100, 200, 300 rather than 100, 101, 102 — specifically so a new rule can be inserted between two existing ones later without needing to renumber anything already in place, which reduces the risk of accidentally changing the relative precedence of rules that already work correctly.

Why does my NSG rule not work even though I configured it correctly?

The most common reason is that a different rule — at a lower priority number in the same NSG, or in a second NSG attached at the other level (subnet vs. NIC) — is matching the traffic first and determining the outcome before your rule is ever evaluated. Because Azure stops evaluating rules the moment it finds a match, a rule you wrote correctly can be entirely irrelevant to the actual outcome if something else catches the traffic earlier in the evaluation order. This is especially common when both a subnet-level and a NIC-level NSG are attached to the same VM — traffic must pass both independently, and inbound traffic checks the subnet NSG first, so a subnet-level deny rule blocks traffic before a more permissive NIC-level rule ever gets consulted. Use Azure's Effective Security Rules view or Network Watcher's IP Flow Verify tool to confirm exactly which rule, in which NSG, is actually responsible for the outcome, rather than assuming based on the rule you intended to be authoritative.

Should I still use NSG flow logs for monitoring traffic?

No — NSG flow logs are being retired and shouldn't be the basis of new monitoring or auditing work. New NSG flow logs can no longer be created as of a policy change effective June 30, 2025, and the feature fully retires on September 30, 2027, at which point traffic analytics support for NSG flow logs stops working and existing NSG flow log resources are deleted (though previously-recorded log data already written to storage is preserved according to its existing retention policy). Microsoft's current recommendation is to migrate to virtual network flow logs, which are positioned as addressing NSG flow logs' limitations. Any environment still relying on NSG flow logs for security monitoring or compliance evidence should plan this migration now rather than waiting until closer to the 2027 deadline, and any new NSG deployed today should use virtual network flow logs from the start if flow-level traffic visibility is required.

Related FAVRITE Articles

• How to Troubleshoot Azure VM RDP Connection Issues: NSG, Firewall, Public IP, and Bastion Fixes
• Enterprise Network Segmentation in Azure: Architecture Patterns That Actually Scale
• Hub-and-Spoke vs Azure Virtual WAN: Which Network Architecture Wins?
• Azure Front Door Wildcard Revalidation Fix