How do you segment an Azure network with NSGs?

Segment an Azure network by placing tiers in separate subnets and attaching network security groups (NSGs) that allow only the flows each tier needs. The key surprise is that Azure's default rules allow all traffic inside the virtual network, so you must add your own deny rules to get real separation.

What does an NSG actually do?

Microsoft describes an NSG as a set of security rules that allow or deny inbound traffic to, or outbound traffic from, several types of Azure resources. Each rule has a name, priority, source, destination, protocol, direction, port range and action.

Priority is a number from 100 to 4096. Lower numbers are processed first, and once traffic matches a rule, processing stops. You cannot create two rules with the same priority and direction. Rules are evaluated on the five tuple of source, source port, destination, destination port and protocol.

NSGs are stateful. If you allow an outbound request, the reply is allowed back without an inbound rule. Rule changes apply only to new connections. Microsoft's own example: if you remove the rule that allowed an SSH session, the open session keeps working, and only new attempts are blocked. After tightening a rule, expect old sessions to linger.

Which default rules surprise people?

Azure adds default rules to every NSG, at priorities 65000 and above so yours always run first. The important ones:

• AllowVNetInBound and AllowVnetOutBound at 65000: all traffic between addresses in the virtual network is allowed.
• AllowInternetOutBound at 65001: outbound to the internet is allowed.
• DenyAllInbound and DenyAllOutBound at 65500: everything else is denied.

You cannot delete these, but you can override them with rules of a lower number. The first one is why a bare NSG does not segment anything. A compromised web server and a database server in the same virtual network can reach each other until you add a deny.

How do you build segments that hold?

Think in tiers. A constructed example: a shop has a web tier, an application tier and a database tier, each in its own subnet.

1. On the database subnet's NSG, add an allow rule at priority 100 from the application tier's address range or application security group on the database port only.
2. Add a deny rule at priority 200 from the VirtualNetwork service tag to any destination port. This overrides the default allow for lateral traffic.
3. On the application tier, allow inbound only from the web tier on the app port, and deny the rest of the virtual network the same way.
4. Restrict outbound too. Replace the default internet allow with specific destinations, using service tags where possible.

Two features keep this maintainable. A service tag stands for the IP prefixes of an Azure service, so you do not chase address changes. Application security groups let you group virtual machines by role and write rules against the group rather than IP addresses. Microsoft notes you can reuse the policy at scale without maintaining explicit addresses.

For organization wide baselines, Azure Virtual Network Manager can push security admin rules. These always have higher priority than NSG rules. A Deny admin rule blocks traffic before any NSG sees it, and an Always allow rule bypasses NSGs entirely, so use them with care.

What else should you know?

• NSG flow logs retire on September 30, 2027, according to the Microsoft page, and new flow logs can no longer be created. Plan on virtual network flow logs for visibility.
• Some services deployed into subnets, such as HDInsight and scale sets, have port requirements. If you deny a port they need, they stop working, so read the requirements before applying an NSG to the subnet.
• Basic host services (DHCP, DNS, instance metadata, health monitoring) use virtual IPs that NSGs do not filter by default.

What to do

1. Draw the tiers and the allowed flows on one page before you write a rule.
2. Put each tier in its own subnet and attach an NSG to each.
3. Write explicit allows with low priority numbers, then a deny for the rest of VirtualNetwork.
4. Use application security groups and service tags instead of raw IPs.
5. Tighten outbound traffic, not just inbound.
6. Roll out in audit mode first: log, review the flows, then enforce, and remember existing sessions persist.
7. Move flow logging to virtual network flow logs before the retirement date.

Safeguard's asset discovery can help you list the workloads you need to place into tiers. See the dependency inventory demo for the software side of that inventory.

Quick check

Sources

• Network security groups overview, Microsoft Learn

Last reviewed: 18 October 2026.