If you’ve ever tried wrangling networking in a landing zone deployment — half a dozen subscriptions, three environments, shared DNS, and a security team breathing down your neck — you already know: the pain’s real.

Enter Azure Virtual Network Manager (AVNM) — your new central control plane for enterprise-grade network governance.

Azure Landing Zones: A Quick Refresher

Azure Landing Zones (ALZ) are the enterprise implementation of Microsoft’s Cloud Adoption Framework (CAF). Think of them as blueprints for scaling cloud platforms in a secure-by-default, governed-by-design way.

Key components often include:

• Hub-and-spoke network topologies
• Central shared services (e.g. DNS, firewalls, logging)
• CI/CD-delivered connectivity and policy
• Split responsibilities between platform and application teams

But here’s the kicker — landing zones scale fast. And with speed comes complexity, especially in your network layer.

That’s where AVNM slips neatly into the picture.

Where AVNM Fits In

AVNM gives platform teams a way to:

• Define topology once and apply it across subscriptions and environments
• Centralise security enforcement without duplicating NSG rules
• Control peering and rule scoping even in a multi-region, multi-team model
• Simplify change audits all AVNM configs are declarative, tracked, and enforceable

Instead of spending hours scripting peerings and distributing “golden” NSGs via ARM or Bicep templates, you define:

• Connectivity configurations for hub-and-spoke or mesh topologies
• Security admin configurations for egress lockdowns, segmentation walls, etc.
• Network groups scoped by tags to dynamically assign VNets to policies

AVNM as a Platform Service (in Your Org Chart)

Landing zones often divide responsibility like this:

AVNM lets you enforce connectivity guardrails and baseline security — without stopping apps from shipping.

By deploying AVNM at the management group level, platform teams can apply topology + protections org-wide without taking away flexibility from application developers.

Network Group Strategy in Landing Zones

Your AVNM Network Groups become the key scoping unit for applying rules and peering policies.

Effective patterns include:

• By environment:
  Use tags like environment=dev, environment=prod
  → Useful for applying per-environment egress rules and segmenting tiers

• By workload or platform zone:
  Tags like app=billing, tier=data, zone=shared
  → Use this to isolate specific data-sensitive workloads

• By function:
  role=core or function=trusted-services
  → For shared DNS zones, Active Directory, or jump boxes

Combine this with Azure Policy and tags and you’ve got scalable, human-readable, code-driven scoping with dynamic membership baked in.

Real Enterprise Use Cases

1. Perimeter Guardrails for Every VNet

Stop egress to the internet across all VNets except what’s explicitly allowed.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

resource DenyOutboundRule 'Microsoft.Network/networkManagers/securityAdminConfigurations/ruleCollections/rules@2024-05-01' = {
  parent: SecurityRuleCollection
  name: 'DenyAllOutbound'
  kind: 'Custom'
  properties: {
    description: 'Deny All outbound traffic'
    protocol: '*'
    direction: 'Outbound'
    sourcePortRanges: ['0-65535']
    destinations: [
      {
        addressPrefixType: 'IPPrefix'
        addressPrefix: '*'
      }
    ]
    destinationPortRanges: ['0-65535']
    access: 'Deny'
    priority: 100
  }
}

This rule lives in a Security Admin Configuration applied to a network group that matches all tagged VNets in dev and test environments. Simple, controlled, repeatable.

2. Hub-and-Spoke Topology as a Service

In your Bicep module:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

@description('Location for all resources')
param location string = resourceGroup().location

@description('Name of the Network Manager')
param networkManagerName string = 'myNetworkManager'

resource avnm 'Microsoft.Network/networkManagers@2024-07-01' = {
  name: networkManagerName
  location: location
  properties: {
    networkManagerScopeAccesses: ['Connectivity']
    networkManagerScopes: {
      managementGroups: ['/providers/Microsoft.Management/managementGroups/mg-platform']
    }
  }
}

AVNM then auto-peers new spokes into the correct topology without scripts, with dynamic entitlement via tag-based Network Groups like zone=shared-hub or zone=app-spoke.

3. Zero Trust Segmentation Between App Tiers

• Create network groups for each trust zone (e.g. tier=frontend, tier=backend)
• Use admin rules to deny cross-tier traffic by default
• Allow application-specific paths via NSGs or dedicated allow rules

This approach matches the CAF Zero Trust strategy and avoids lateral movement with a single policy.

4. Spoke Isolation + Shared Access

• Apply connectivity config that links spokes to hub
• Apply admin rule that denies spoke-to-spoke traffic
• Hub implements central inspection/firewall/logging

This pattern’s critical in regulated industries and helps with:

• Audit compliance
• Network simplicity
• Reduced blast radius

Monitoring and Azure Service Integration

AVNM plays nicely with the rest of the Azure stack:

• NSGs & ASGs: Still valid — now layered beneath AVNM rules
• Defender for Cloud: Reports on AVNM rule misalignments + security insights
• Log Analytics: Use diagnostic settings on AVNM resources for audit trails
• Azure Policy: Enforce tagging and AVNM config presence using policy-as-code

AVNM in ALZ: Topology Snapshot

Best Practices

• Deploy AVNM at the management group level for complete coverage
• Use consistent tagging strategy to simplify group scoping
• Document rule intention in Bicep descriptions or Git repositories
• Delegate access clearly because AVNM config should be owned like a platform product
• Start with ReadOnly mode when previewing admin rules impact

Learn More

• CAF: Azure Landing Zones documentation
• Azure Virtual Network Manager documentation
• Enterprise-scale network segmentation strategies
• Deploying Zero Trust in Azure networks