Network Security: NSGs, ASGs, Azure Virtual Network Manager…

The L3/L4 layer of Azure networking security

Simple explanation

Network Security Groups (NSGs) are Azure’s stateful firewall at the subnet or NIC level — allow/deny rules based on source/destination IP, port, and protocol. They are simple, free, and applied close to the workload. They’re the bread-and-butter L3/L4 control.

Application Security Groups (ASGs) let you reference groups of NICs by name in NSG rules instead of CIDR ranges. “Allow web-tier ASG to talk to db-tier ASG on 3306” is much more maintainable than “allow 10.5.6.0/26 to 10.5.7.0/26 on 3306”.

Azure Virtual Network Manager (AVNM) is the newer centralised network manager — define hub-and-spoke connectivity, mesh connectivity, and security admin rules at scale across many VNets in one place. AVNM security admin rules even take priority over NSG rules — Azure-side enforcement.

Network Security Groups (NSGs)

Scope and rule structure

NSGs apply at subnet (recommended for fleet management) or NIC (fine-grained, used for exceptions). Each NSG has up to 1000 rules across inbound and outbound. Each rule has:

Priority (100–4096, lower wins)
Source — IP/CIDR, service tag, ASG, or *
Destination — same options
Protocol — TCP/UDP/ICMP/ESP/AH/Any
Source port range + Destination port range
Action — Allow or Deny

Default rules (priorities 65000+) sit at the end:

AllowVNetInBound / AllowVNetOutBound — VNet-internal traffic
AllowAzureLoadBalancerInBound — health probes
AllowInternetOutBound — outbound to internet by default
DenyAllInBound / DenyAllOutBound — final catch-all

Service tags — the maintainable way

Service tags represent groups of Microsoft-maintained IP prefixes. Common SC-500-relevant ones:

Internet, VirtualNetwork, AzureLoadBalancer
AzureCloud / AzureCloud.<region> — all Azure datacentre IPs (in region)
Storage / Storage.<region> — Azure Storage public endpoints (in region)
Sql / Sql.<region> — Azure SQL endpoints
AzureKeyVault.<region>
AzureMonitor, AzureActiveDirectory, AzureFrontDoor.Backend

Using service tags means Microsoft maintains the underlying IP ranges; rules stay current automatically.

Application Security Groups (ASGs)

ASGs let NSG rules reference groups of NICs by name. Pattern:

Create ASGs web-tier, app-tier, db-tier.
Attach NICs to the right ASG (a NIC can belong to multiple ASGs).
NSG rule: source = web-tier, destination = app-tier, port = 443, action = Allow.

Two key constraints:

All NICs referenced by an NSG rule via ASG must be in the same VNet as the NSG.
ASGs do NOT span VNets (use AVNM security admin rules or hub-and-spoke + NSGs for cross-VNet rules).

Azure Virtual Network Manager (AVNM)

AVNM scales network governance across many VNets via three configuration types:

AVNM configurations — connectivity, security admin rules, routing
Configuration	What it does
Connectivity	Hub-and-spoke topology (auto-creates hub VNet + spoke peerings) or mesh (any-to-any peering across the scope). Replaces manual peering at scale.
Security admin rules	Priority-enforced NSG-like rules applied to all VNets in scope. Intents: AlwaysAllow / Allow / Deny. AlwaysAllow + Deny intents take priority OVER NSG rules — central enforcement that NSGs cannot override.
Routing (preview/GA depending on region)	Centralised user-defined route management across many VNets.

Security admin rules vs NSGs

This is the most-tested AVNM distinction on SC-500:

NSG rules vs AVNM security admin rules — local vs central
Feature	NSG rule	AVNM Security Admin rule
Scope	Subnet or NIC, within one VNet	Multiple VNets defined by AVNM network groups
Priority over NSG	Lower-priority NSGs in chain compose normally	AlwaysAllow and Deny intents OVERRIDE NSG rules — central enforcement
Created by	Subnet/VNet owner — local control	Tenant network admin — central control
Use case	Local subnet hardening	Tenant-wide invariants ('always deny inbound 22 from Internet', 'always allow Azure Bastion to all RDP/SSH')

The exam pattern: when the scenario describes tenant-wide invariants (block SSH from internet across ALL VNets, regardless of subnet-team-set NSGs), the answer is AVNM security admin rules with Deny intent. When the scenario describes subnet-specific allow lists, the answer is NSGs (optionally with ASGs).

Priority interaction: how AVNM and NSGs compose

When a packet hits a VNet’s subnet:

AVNM Security Admin rules apply first. AlwaysAllow → pass through (no NSG evaluation). Deny → drop (NSG cannot override). Allow → fall through to NSG evaluation.
NSG rules then evaluate normally — subnet NSG first, then NIC NSG.

This is the central-control mechanism: a Deny security admin rule cannot be bypassed by an NSG owner adding a permissive Allow rule. Conversely, an AlwaysAllow ensures a specific path (e.g. Azure Bastion subnets reaching RDP) can never be blocked by an over-zealous NSG configured by a junior admin.

Scenario: Asha builds tenant-wide segmentation at Aurora Health Service

Across 47 subscriptions and ~120 VNets, Asha needs:

AVNM security admin rules at the tenant scope:
- Deny inbound from Internet on TCP/22 and 3389 (SSH/RDP) — enforced across all VNets, no local-team override possible.
- AlwaysAllow inbound from AzureBastion subnets — Bastion is the only sanctioned RDP/SSH path.
- Deny inbound from Internet to AzureKeyVault service tag destinations on VNet peripheries.
Hub-and-spoke connectivity via AVNM connectivity configuration — auto-creates and maintains peerings for new spokes added to the network group.
Per-VNet NSGs with ASGs for application tier segmentation — web-tier → app-tier on 443; app-tier → db-tier on 1433; everything else default-deny.
Service tag-based outbound rules — application subnets allowed outbound only to specific service tags (AzureCloud.AustraliaEast, AzureKeyVault.AustraliaEast, Sql.AustraliaEast, Storage.AustraliaEast) — internet outbound denied by default.

Result: tenant-wide invariants enforced centrally; per-VNet teams retain local control; application traffic flows on labelled paths; outbound restricted to known Microsoft service ranges.