Design scalable Azure network segmentation using landing zones, Azure Firewall, policy enforcement, and governance across subscriptions

Architecture BlueprintNetwork SegmentationVirtual Network ManagerZero Trust

Enterprise Network Segmentation in Azure:
Architecture Patterns That Actually Scale

A network security group per subnet is a genuinely good idea at ten subnets. At three hundred, spread across forty subscriptions and six business units, it's a spreadsheet nobody trusts, a drift problem nobody's tracking, and a single missed NSG away from the one workload that quietly bypasses every rule the security team thought was universal. Segmentation that scales isn't more NSGs — it's a different layer entirely, sitting above them.

Before, not instead of

Security admin rules are evaluated before NSG rules — a central Deny blocks traffic before any NSG is even consulted

Static or Dynamic

Network groups can be populated manually, or automatically via Azure Policy conditions — new VNets inherit governance the moment they're created

No group limit

There's no cap on how many network groups you can create — segmentation granularity scales with your organizational structure, not a platform ceiling

One real gap

Security admin rules currently don't apply to private endpoints under a managed VNet — a specific, documented limitation to design around

Table of Contents

1. 01Why "One NSG Per Subnet" Doesn't Scale
2. 02The Segmentation Toolkit: NSGs, ASGs, Firewall, Private Link
3. 03Security Admin Rules: The Layer That Actually Scales
4. 04Network Groups: Static vs Dynamic Membership
5. 05Admin Rules vs NSG Rules: Who Owns What
6. 06Connectivity Configurations: Mesh, Hub-and-Spoke, and Beyond Peering Limits
7. 07A Layered Reference Architecture
8. 08Step-by-Step: Rolling Out Segmentation at Scale
9. 09Anti-Patterns
10. 10Frequently Asked Questions

Every organization's network segmentation starts the same reasonable way: an NSG on each subnet, rules written by whoever owns that workload, reviewed in whatever code review process that team happens to follow. It works, right up until the organization has enough subnets that "whoever owns that workload" becomes forty different people with forty different levels of security discipline, and the security team's actual visibility into the aggregate posture collapses into hoping everyone did it right. The pattern that scales isn't a better way to write NSGs — NSGs remain exactly as useful as they always were for team-level, workload-specific rules. It's a layer above them: centrally-defined, centrally-enforced rules that apply automatically to every VNet in scope, evaluated before any individual team's NSG gets a chance to accidentally undermine them. Azure Virtual Network Manager's security admin rules are that layer, and understanding how they interact with — not replace — the tools you already know is the actual architecture question this guide answers.

Figure 1 — Traffic evaluation order: security admin rules run first, and can't be bypassed by a missing or misconfigured NSG

A single inbound packet passes through evaluation in a fixed order: security admin rules first, then NSG rules, with Application Security Groups referenced inside NSG rules to group VMs by role rather than static IP. Because admin rules are evaluated before NSGs and a Deny at that layer stops the packet immediately, central governance holds even when a workload team's NSG is missing, misconfigured, or simply never got written.

01Why "One NSG Per Subnet" Doesn't ScaleRoot Cause

NSGs are not the problem — they remain the correct tool for workload-specific, team-owned traffic rules, and nothing in this guide argues for removing them. The problem is treating NSGs as the entire segmentation strategy for an organization with dozens or hundreds of VNets, because that model has a structural weakness that gets worse, not better, as the organization grows.

Failure mode	Why it happens	Why it gets worse at scale
Missing NSGs	A team provisions a subnet, forgets or deprioritizes the NSG	More subnets, more teams, more chances for this specific gap to occur somewhere
Inconsistent rule sets	Each team writes rules independently, with no shared baseline	No two teams' "reasonable defaults" agree, and nobody has visibility into the aggregate posture
Drift over time	Rules added for a one-off troubleshooting session, never removed	Multiplied across every subnet, drift compounds invisibly, and periodic manual audits can't keep pace
No central enforcement of non-negotiables	NSGs are entirely team-owned; nothing stops a team from removing a rule central security depends on	The security team's confidence in "we require X everywhere" is actually just hope

The real failure isn't a bad NSG rule — it's the ONE workload with no NSG at all

In practice, the segmentation incidents that actually matter rarely trace back to a badly-written NSG rule — badly-written rules get caught in review often enough. They trace back to the subnet nobody remembered to put an NSG on at all: a rushed proof-of-concept that became production, a subnet created by an automation script that skipped the NSG step, a team that genuinely didn't know the organizational baseline existed. A purely NSG-based strategy has no mechanism to catch this category of gap — there's nothing to audit against if the missing control was never even a documented requirement in the first place.

02The Segmentation Toolkit: NSGs, ASGs, Firewall, Private LinkFoundation

Before layering on centralized governance, it's worth being precise about what each foundational tool actually does — they're complementary, not competing, and enterprise segmentation uses all of them together.

Tool	What it does	Scope
Network Security Group (NSG)	Allow/deny rules on IP, port, and protocol, attached to a subnet or network interface	Subnet or NIC — team-owned
Application Security Group (ASG)	Groups VMs by application role (e.g. "web-tier," "db-tier") rather than static IP, referenced inside NSG rules	Referenced within NSG rules — makes rules readable and maintainable as membership changes
Azure Firewall	Centralized, stateful L3-L7 filtering, threat intelligence, and egress control — typically in a hub	Hub-level — inspects traffic crossing segment boundaries
Private Link / Private Endpoints	Brings a PaaS service's endpoint inside your VNet's private address space, removing public exposure entirely	Per-service — eliminates an entire class of exposure rather than filtering it

The natural layering: Private Link removes public exposure for PaaS services wherever possible. Azure Firewall inspects and controls traffic crossing major segment boundaries (spoke-to-spoke, spoke-to-internet). NSGs enforce team-specific rules within a subnet. ASGs keep those NSG rules maintainable as the set of VMs playing a given role changes over time. What's been missing from this list — and what the rest of this guide focuses on — is a layer that applies consistent baseline rules across every subnet and every team, without requiring each team to individually implement it correctly.

03Security Admin Rules: The Layer That Actually ScalesCore Mechanism

Security admin rules, part of Azure Virtual Network Manager, are global network security rules that enforce policies defined once, centrally, across every virtual network in a targeted network group — regardless of how many subscriptions or teams those VNets belong to. This is the mechanism that turns "we require X everywhere" from a policy document into an actually-enforced platform property.

Property	Detail
Evaluation order	Before NSG rules — a security admin Deny blocks the packet before any NSG is even evaluated
Rule actions	Allow (NSGs still evaluated after), Always Allow (cannot be overridden by any NSG), Deny
Independence from NSGs	Default security admin rules can be created that don't depend on an NSG existing at all — useful specifically for the "team never created an NSG" failure mode
Scope	Only applies to virtual networks within the scope of your Virtual Network Manager instance — VNets outside AVNM's management scope are unaffected
Rule priority	Each rule in a collection carries a priority value; lower values mean higher priority

A documented, specific limitation: private endpoints under a managed VNet

Worth flagging precisely because it's easy to assume otherwise: security admin rules currently don't apply to private endpoints that fall under the scope of a managed virtual network. If your segmentation strategy depends partly on controlling traffic to specific private endpoints via admin rules, verify this limitation against your specific architecture before assuming coverage — this is exactly the kind of gap that looks covered on a diagram and isn't in practice.

Restrict high-risk management ports via admin rules specifically

Microsoft's own guidance recommends using security admin rules — not just NSGs — to restrict inbound traffic on high-risk ports commonly associated with management protocols and unencrypted data transmission (RDP's 3389 and SSH's 22 are the most universally cited examples). Enforcing this at the admin-rule layer rather than relying on every team's NSG to independently get it right is precisely the pattern this guide is built around: a rule too important to leave to individual team discipline belongs at the layer that can't be bypassed.

04Network Groups: Static vs Dynamic MembershipDeep Dive

A network group is the targeting mechanism for security admin rules and connectivity configurations — the set of VNets a given rule collection actually applies to. How that set is populated is a real architectural decision.

Membership type	How it's populated	Best fit
Static	Manually select specific VNets to include	Small, stable groups; exceptions; VNets that genuinely need individual review before inclusion
Dynamic	Azure Policy-based conditions — VNets matching the condition (tags, naming, subscription, etc.) join automatically	Production/non-production splits, business-unit segmentation, anything where new VNets should inherit governance without manual onboarding

Dynamic membership is what makes this pattern genuinely scale rather than just centralize the same manual effort. A network group defined by a policy condition — for example, "every VNet tagged environment: production" — automatically gains any new VNet matching that condition the moment it's created, with no security admin action required. This directly closes the "team forgot to onboard their new subnet to governance" gap that a purely NSG-based, purely manual approach can't structurally prevent.

No platform limit on group count — segment by whatever axis matches your organization

There's no cap on how many network groups you can create, which means group design should be driven by your organization's actual structure — environment (production/non-production), business unit, region, compliance scope, or some combination — rather than by an artificial platform constraint. A common, practical pattern: two network groups (production, non-production) with distinct security admin rule collections targeted at each, enforcing stricter rules on production while allowing more permissive rules for non-production experimentation.

05Admin Rules vs NSG Rules: Who Owns WhatGovernance Model

The clean way to think about the split — and the framing Microsoft's own documentation uses — is that security admin rules and NSG rules target two different audiences with two different jobs, not two competing implementations of the same job.

Aspect	Security Admin Rules	NSG Rules
Owned by	Central network/security governance team	Individual application or workload teams
Purpose	Organization-wide, non-negotiable guardrails	Workload-specific, fine-grained micro-segmentation
Applied to new resources	Automatically, via dynamic network groups — no team action required	Only if the team remembers to configure it
Can be bypassed by a workload team	No — evaluated before NSGs, independent of NSG existence	Yes, by design — it's the team's own configuration to manage
Relationship to each other	Complementary — admin rules establish the floor; NSGs add flexibility on top, not in competition with it

This model replaces a real, historically painful trade-off

Before this layered model existed, organizations genuinely faced a binary choice with no good middle ground: centralize all NSG management with one governance team (strong enforcement, but every workload team becomes dependent on that team for basic connectivity changes — an operational bottleneck), or fully delegate NSG ownership to workload teams (fast and flexible, but with no reliable central enforcement of anything). Security admin rules specifically exist to eliminate that trade-off — central governance handles the non-negotiables, workload teams keep full autonomy over their own NSG rules within those guardrails, and neither side is waiting on the other for routine work.

Figure 2 — Connectivity configurations: topology as declared intent, not manually-built peerings

Rather than manually creating and maintaining individual VNet peerings, a connectivity configuration declares the intended topology — mesh (every VNet reaches every other), hub-and-spoke (spokes route through shared hub services), or hub-and-spoke with selected direct spoke-to-spoke connectivity for latency-sensitive pairs — and Azure Virtual Network Manager applies and maintains it across the entire target network group automatically.

06Connectivity Configurations: Mesh, Hub-and-Spoke, and Beyond Peering LimitsDeep Dive

Segmentation and connectivity are two sides of the same coin — deciding what's allowed to talk to what is meaningless without also managing how the underlying network topology actually connects things. Virtual Network Manager's connectivity configurations extend the same "declare intent once, apply broadly" model to topology itself.

Topology	Pattern	Best fit
Mesh	Every VNet in the group peers directly with every other	Smaller groups needing full interconnectivity, or specific low-latency, high-throughput peer relationships
Hub-and-Spoke	Spokes route through a central hub for shared services (firewall, gateways)	The standard enterprise default — centralized inspection and shared infrastructure
Hub-and-Spoke with direct connectivity	Standard hub-and-spoke, plus direct peering between specific spokes that need low latency between each other	When most traffic should route through the hub, but a specific pair of workloads needs direct connectivity

The scaling mechanism specifically worth understanding: "connected groups" let Virtual Network Manager manage many VNets as a single logical entity for connectivity purposes, which is what allows topologies to scale beyond the throughput and count limits of standard, individually-managed VNet peering — without incurring a second peering charge on top of the standard one, and while respecting and migrating in any peerings you already had before bringing a VNet into AVNM's scope.

Global mesh has a specific, narrow use case — don't default to it

A full global mesh (every VNet across every region talking directly to every other) is appropriate specifically when every VNet genuinely needs to communicate with every other one, and it's easy to reach for as a "just connect everything" default. In practice, most enterprise segmentation strategies want the opposite — deliberate, limited connectivity paths, not universal reachability — which is why hub-and-spoke (with only specific, justified direct-spoke exceptions) remains the standard recommendation over mesh for most organizations, even though mesh is technically available and easy to declare.

07A Layered Reference ArchitectureSynthesis

Putting every tool from this guide together into one coherent, defensible design — the shape most enterprise Azure segmentation strategies should converge toward.

Layer	Tool	Owner	Enforces
0	Private Link / Private Endpoints	Platform team	PaaS services have no public exposure at all, wherever feasible
1	Security Admin Rules (AVNM)	Central security/network governance	Non-negotiable organization-wide rules — high-risk port blocks, environment isolation
2	Azure Firewall (hub)	Platform/network team	Centralized inspection and egress control for traffic crossing segment boundaries
3	NSG Rules	Workload/application team	Fine-grained, workload-specific rules within a subnet
4	Application Security Groups	Workload/application team	Role-based grouping inside NSG rules, maintainable as membership changes

This is a genuine defense-in-depth model, not redundant duplication — each layer catches a different category of failure. A workload team's forgotten NSG is caught by Layer 1. A misconfigured NSG rule that's technically valid but overly permissive is still bounded by Layer 2's centralized egress inspection. A PaaS service accidentally left with a public endpoint is prevented from ever having one in the first place by Layer 0. No single layer is asked to be the entire security posture on its own.

Map this architecture to Zero Trust principles explicitly

This layered model is a direct expression of Zero Trust network principles applied to Azure specifically: verify explicitly (admin rules and NSGs both require explicit allow, deny by default), use least-privilege access (network groups scope rules to exactly the resources that need them, not broader), and assume breach (defense-in-depth across five independent layers means a single control's failure doesn't equal a full compromise). Framing the architecture this way — rather than as an ad hoc collection of tools — makes it far easier to defend in a security review or audit, because it maps directly onto a security framework auditors already recognize.

08Step-by-Step: Rolling Out Segmentation at ScaleHow-To

1. Inventory current NSG coverage and identify the gaps

   Before adding a new layer, know what the existing one actually looks like — which subnets have NSGs, which don't, and how inconsistent the rule sets already are across teams. This baseline is what proves the value of what comes next, and reveals exactly which non-negotiables belong at the admin-rule layer first.

2. Deploy an Azure Virtual Network Manager instance scoped appropriately

   Decide the AVNM instance's scope — a single management group, a subscription, or broader — matching your organization's actual governance boundaries. Remember: security admin rules only apply to VNets within this instance's scope.

3. Define network groups matching your real segmentation axes

   Start with the split that matters most immediately — commonly production vs non-production — using dynamic, policy-based membership so new VNets inherit the correct group automatically rather than requiring manual onboarding.

4. Create default security admin rules for the non-negotiables first

   Start with rules that don't depend on any NSG existing — high-risk management port restrictions, cross-environment isolation (production VNets can't be reached from non-production) — the specific gaps a purely NSG-based approach structurally can't close.

5. Deploy in Audit-equivalent fashion before hard enforcement

   Use flow logs to observe what the new admin rules would have blocked before they're actively enforced, exactly as you would with any new Azure Policy assignment — validate against real traffic patterns before committing to Deny in production.

6. Layer in connectivity configurations once security rules are validated

   With segmentation rules confirmed correct, declare your connectivity topology (typically hub-and-spoke) via AVNM rather than continuing to hand-manage individual peerings — letting existing peerings migrate in automatically.

7. Document the layer ownership model and communicate it to every workload team

   Make explicit, in writing, which rules live at the admin layer (central, non-negotiable) versus the NSG layer (team-owned, flexible) — this is the governance clarity that prevents both "why did my traffic get blocked and I don't know by what" support tickets and teams assuming central governance covers something it doesn't.

09Anti-PatternsTraps

Anti-pattern	Why it feels right	Why it isn't
Treating security admin rules as a replacement for NSGs	"One centralized layer should be enough"	Admin rules are deliberately not meant to override NSGs — they establish guardrails while NSGs still provide workload-specific flexibility. Removing NSGs loses that flexibility entirely
Populating network groups with static membership only	"We know exactly which VNets need this today"	Every new VNet requires manual onboarding to governance, recreating the exact gap this whole layer was meant to close
Deploying admin rules directly to Deny without validating against real traffic	"We're confident this rule is correct"	An unvalidated Deny at the layer evaluated before every NSG can block legitimate traffic across every VNet in scope simultaneously — the highest-blast-radius place to make this mistake
Defaulting to global mesh connectivity "to keep things simple"	"Fewer connectivity decisions to make"	Universal reachability is usually the opposite of what segmentation is trying to achieve — deliberate, limited connectivity paths matter more than convenience
Assuming security admin rules cover private endpoint traffic	"It's all part of the managed VNet, it must be covered"	This is a documented, current limitation — admin rules don't apply to private endpoints under a managed VNet's scope. Verify explicitly, don't assume
Rolling out enforcement organization-wide in a single change	"Faster to just turn it on everywhere"	A misconfiguration at this scale affects every VNet in the target group at once — phase the rollout by network group, validating each before expanding

Key Takeaways

→NSGs alone don't scale past a certain organizational size. Not because NSGs are flawed, but because a purely team-owned model has no mechanism to catch the "nobody configured it at all" failure mode.

→Security admin rules are evaluated before NSGs. A central Deny blocks traffic before any workload team's NSG is even consulted — this is what makes governance unbypassable rather than merely recommended.

→Dynamic network groups close the "forgot to onboard" gap structurally. Policy-based membership means new VNets inherit governance automatically, not through a manual step someone might skip.

→Admin rules and NSGs are complementary, not competing. Central governance sets the floor; workload teams keep full flexibility above it. Removing either half breaks the model.

→Connectivity configurations replace manual peering with declared topology. Mesh, hub-and-spoke, or hub-and-spoke-with-direct-connectivity, applied to an entire network group at once, scaling beyond standard peering limits.

→Security admin rules don't currently cover private endpoints under a managed VNet. A specific, documented gap — verify it against your architecture rather than assuming coverage.

→Layer everything — no single control should be your entire security posture. Private Link, admin rules, Azure Firewall, NSGs, and ASGs each catch a different category of failure.

Frequently Asked Questions

Do security admin rules replace network security groups?

No, and they're deliberately not designed to. Security admin rules and NSG rules are complementary layers targeting different audiences: security admin rules, managed through Azure Virtual Network Manager, enforce organization-wide, non-negotiable policies defined by a central governance team and applied automatically across every virtual network in scope. NSG rules remain owned by individual workload or application teams for fine-grained, workload-specific micro-segmentation. Security admin rules are evaluated before NSG rules — meaning a security admin Deny blocks traffic before any NSG is even consulted — which is what makes the central layer unbypassable, but the two are meant to work together rather than one replacing the other. Removing NSGs entirely in favor of admin rules alone loses the flexibility workload teams need for their own specific requirements.

What's the difference between static and dynamic network group membership?

Static membership means manually selecting which specific virtual networks belong to a network group — appropriate for small, stable groups or genuine exceptions that need individual review before inclusion. Dynamic membership uses Azure Policy-based conditions to automatically populate the group — for example, every VNet carrying a specific tag, or belonging to a specific subscription, joins the group automatically the moment it's created, with no manual action required from a security administrator. Dynamic membership is what makes centralized segmentation genuinely scale: without it, every new VNet still requires someone to remember to onboard it to governance manually, recreating the exact "forgot to configure it" gap that centralizing the rules was meant to solve in the first place.

Can security admin rules cover traffic to private endpoints?

Not currently, and this is a specific, documented limitation worth designing around explicitly rather than assuming coverage. Security admin rules, as of current Azure Virtual Network Manager documentation, don't apply to private endpoints that fall under the scope of a managed virtual network. If part of your segmentation strategy depends on controlling access to specific private endpoints, that control needs to come from a different mechanism — NSGs, Private Link's own access controls, or another layer in your architecture — rather than assuming the admin-rule layer has it covered. This is exactly the kind of gap that looks closed on an architecture diagram and isn't in practice, so verify it against your specific design rather than taking blanket coverage for granted.

Should I use a mesh or hub-and-spoke connectivity configuration?

Hub-and-spoke is the standard recommendation for most enterprise organizations, and mesh should be reserved for cases where every VNet in a group genuinely needs to communicate directly with every other one. A full mesh topology grants universal reachability across the group, which is usually the opposite of what a deliberate segmentation strategy is trying to achieve — most enterprise designs want limited, justified connectivity paths, not maximum interconnectivity by default. Hub-and-spoke keeps shared services (firewall, gateways, DNS) centralized and lets you inspect traffic crossing segment boundaries at a single chokepoint. If specific spoke pairs genuinely need low-latency direct connectivity, Virtual Network Manager supports hub-and-spoke with selected direct spoke-to-spoke connectivity as a targeted exception, rather than requiring a full mesh to accommodate that one relationship.

Related FAVRITE Articles

• Hub-and-Spoke vs Azure Virtual WAN: Which Network Architecture Wins?
• How to Design Azure Landing Zones: The Enterprise Architecture Blueprint
• RBAC for Azure Files: Least-Privilege Access Patterns
• Microsoft Defender for Cloud: A Practical Guide