Enterprise Azure Landing Zone Step-by-Step Configuration and Implementation Document

If you’re interested in learning how to build a complete enterprise Azure Landing Zone Framework, this is covered in detail here: Mastering Azure Landing Zone Framework Enterprise Architecture

1. Purpose

This document provides a practical step-by-step implementation guide for the Azure Landing Zone architecture shown in the diagram. The design follows Microsoft’s Azure Landing Zone model, which is based on eight major design areas: billing and tenant setup, identity, management groups, networking, security, management, governance, and automation.

2. Target Architecture

The landing zone will include:

• Microsoft Entra ID Identity Foundation
• Management Group Hierarchy
• Platform Subscriptions
• Workload Subscriptions
• Hub-And-Spoke Network Topology
• Centralized Security
• Centralized Monitoring
• Governance Through Azure Policy
• Automation Using Bicep, Terraform, Azure Devops, or Github Actions

Microsoft supports Azure Landing Zone deployment through the Azure portal, Bicep, and Terraform, with the IaC Accelerator providing Bicep or Terraform-based deployment using Azure Verified Modules.

3. Assumed Enterprise Environment

Assume the company has:

• 5,000 to 15,000 users
• Hybrid identity with on-premises Active Directory
• Multiple business units
• Production and non-production workloads
• Regulatory requirements
• Need for centralized security, monitoring, and governance
• Hybrid connectivity using VPN or ExpressRoute

4. Phase 1 – Prepare the Azure Tenant

Step 1. Validate Microsoft Entra ID Tenant

Confirm that the organization has a dedicated Microsoft Entra ID tenant.

Validate:

• Tenant name
• Verified domain names
• Global Administrator accounts
• Break-glass accounts
• MFA configuration
• Conditional Access readiness
• Azure subscription ownership

Recommended baseline:

• At least two emergency access accounts
• MFA enforced for privileged users
• No daily administration using Global Administrator
• Privileged Identity Management enabled

Step 2. Configure Emergency Access Accounts

Create two cloud-only emergency accounts.

Example:

• breakglass01@company.com
• breakglass02@company.com

Configuration:

• Exclude from Conditional Access
• Assign Global Administrator
• Use long, complex passwords
• Store credentials securely
• Monitor all sign-ins
• Do not use for daily operations

Step 3. Enable Microsoft Entra ID Security Features

Enable:

• Microsoft Entra ID P1 or P2
• Conditional Access
• Privileged Identity Management
• Identity Protection
• Access Reviews

The identity and access design area for Azure Landing Zones focuses on securing the Azure control plane and enabling workload teams to operate inside platform-defined guardrails.

5. Phase 2 – Create Management Group Hierarchy

Step 4. Create the Root Management Group Structure

Create the following hierarchy:

Tenant Root Group
│
├── Platform
│   ├── Identity
│   ├── Management
│   └── Connectivity
│
├── Landing Zones
│   ├── Corp
│   └── Online
│
├── Sandbox
│
└── Decommissioned

Purpose:

• Platform contains shared enterprise services
• Landing Zones contains application workloads
• Sandbox is for controlled experimentation
• Decommissioned holds retired subscriptions

Microsoft’s Azure Landing Zone guidance uses management groups as a core resource organization structure for applying governance and policy inheritance at scale.

Step 5. Create Management Groups Using PowerShell

Connect-AzAccount

New-AzManagementGroup -GroupName "mg-platform" -DisplayName "Platform"
New-AzManagementGroup -GroupName "mg-identity" -DisplayName "Identity" -ParentId "mg-platform"
New-AzManagementGroup -GroupName "mg-management" -DisplayName "Management" -ParentId "mg-platform"
New-AzManagementGroup -GroupName "mg-connectivity" -DisplayName "Connectivity" -ParentId "mg-platform"

New-AzManagementGroup -GroupName "mg-landingzones" -DisplayName "Landing Zones"
New-AzManagementGroup -GroupName "mg-corp" -DisplayName "Corp" -ParentId "mg-landingzones"
New-AzManagementGroup -GroupName "mg-online" -DisplayName "Online" -ParentId "mg-landingzones"

New-AzManagementGroup -GroupName "mg-sandbox" -DisplayName "Sandbox"
New-AzManagementGroup -GroupName "mg-decommissioned" -DisplayName "Decommissioned"

6. Phase 3 – Create Subscription Architecture

Step 6. Create Platform Subscriptions

Create these subscriptions:

sub-platform-identity-prod
sub-platform-management-prod
sub-platform-connectivity-prod
sub-platform-security-prod

Purpose:

• Identity subscription hosts identity-related services if required
• Management subscription hosts monitoring and automation
• Connectivity subscription hosts hub network services
• Security subscription hosts Sentinel, Defender integrations, and security tooling

Step 7. Create Workload Subscriptions

Create these subscriptions:

sub-prod-corp-001
sub-nonprod-corp-001
sub-prod-online-001
sub-nonprod-online-001
sub-data-prod-001
sub-data-nonprod-001

Recommended naming standard:

sub-[environment]-[businessunit]-[number]

Example:

sub-prod-finance-001
sub-dev-hr-001
sub-prod-data-001

Step 8. Move Subscriptions into Management Groups

New-AzManagementGroupSubscription `
  -GroupName "mg-connectivity" `
  -SubscriptionId "<connectivity-subscription-id>"

New-AzManagementGroupSubscription `
  -GroupName "mg-management" `
  -SubscriptionId "<management-subscription-id>"

New-AzManagementGroupSubscription `
  -GroupName "mg-corp" `
  -SubscriptionId "<production-subscription-id>"

New-AzManagementGroupSubscription `
  -GroupName "mg-sandbox" `
  -SubscriptionId "<sandbox-subscription-id>"

7. Phase 4 – Configure RBAC Model

Step 9. Define Enterprise Role Groups

Create Microsoft Entra ID groups:

grp-azure-platform-owners
grp-azure-network-admins
grp-azure-security-admins
grp-azure-monitoring-admins
grp-azure-workload-owners
grp-azure-workload-contributors
grp-azure-readers
grp-azure-cost-management

Step 10. Assign RBAC by Scope

Recommended RBAC model:

Tenant Root Group
- Minimal assignments only

Platform Management Group
- Platform Owners

Connectivity Management Group
- Network Admins
- Platform Owners

Management Management Group
- Monitoring Admins
- Security Admins

Landing Zones Management Group
- Workload Owners
- Security Readers

Production Subscriptions
- Workload Contributors
- Security Readers

Sandbox
- Limited Contributor access

Principle:

• Assign permissions at management group level only when required
• Use Privileged Identity Management for privileged roles
• Avoid direct user assignments
• Use groups only

8. Phase 5 – Configure Governance and Azure Policy

Step 11. Define Required Tags

Standard enterprise tags:

Environment
Owner
CostCenter
ApplicationName
BusinessUnit
DataClassification
Criticality
ManagedBy

Step 12. Assign Tagging Policies

Apply at Landing Zones management group:

• Require Environment tag
• Require Owner tag
• Require CostCenter tag
• Inherit tags from resource group
• Append missing tags where appropriate

Step 13. Configure Location Restrictions

Apply at Platform and Landing Zones management groups.

Example allowed regions:

East US
East US 2
West US 2
Central US
North Europe
West Europe

Purpose:

• Prevent resource sprawl
• Enforce data residency
• Improve compliance control

Step 14. Configure Deny Policies

Apply policies to deny:

• Public IP creation in production
• Storage accounts with public network access
• Key Vault public access
• Unapproved VM SKUs
• Resources without required tags
• Deployment to unapproved regions
• Network interfaces with public IP addresses

Azure Policy includes built-in definitions and initiatives for many of these controls, including public network access auditing and Private Link evaluation.

Step 15. Configure Private Endpoint Governance

For production workloads:

• Require private endpoints for PaaS services
• Disable public network access
• Integrate private endpoints with Private DNS Zones
• Use policy to deploy DNS records automatically where possible

Microsoft recommends Private Link and DNS integration at scale for enforcing private connectivity to PaaS services and reducing public endpoint exposure.

9. Phase 6 – Build Hub Network in Connectivity Subscription

Step 16. Create Hub Resource Group

Set-AzContext -Subscription "<connectivity-subscription-id>"

New-AzResourceGroup `
  -Name "rg-connectivity-hub-prod-eastus" `
  -Location "EastUS"

Step 17. Create Hub Virtual Network

Recommended address space:

Hub VNet: 10.0.0.0/16
Azure Firewall Subnet: 10.0.0.0/26
Gateway Subnet: 10.0.1.0/27
Bastion Subnet: 10.0.2.0/26
Shared Services Subnet: 10.0.10.0/24
Private Endpoint Subnet: 10.0.20.0/24

PowerShell example:

$location = "EastUS"
$rg = "rg-connectivity-hub-prod-eastus"

$fwSubnet = New-AzVirtualNetworkSubnetConfig `
  -Name "AzureFirewallSubnet" `
  -AddressPrefix "10.0.0.0/26"

$gwSubnet = New-AzVirtualNetworkSubnetConfig `
  -Name "GatewaySubnet" `
  -AddressPrefix "10.0.1.0/27"

$bastionSubnet = New-AzVirtualNetworkSubnetConfig `
  -Name "AzureBastionSubnet" `
  -AddressPrefix "10.0.2.0/26"

$sharedSubnet = New-AzVirtualNetworkSubnetConfig `
  -Name "snet-sharedservices" `
  -AddressPrefix "10.0.10.0/24"

New-AzVirtualNetwork `
  -Name "vnet-hub-prod-eastus" `
  -ResourceGroupName $rg `
  -Location $location `
  -AddressPrefix "10.0.0.0/16" `
  -Subnet $fwSubnet,$gwSubnet,$bastionSubnet,$sharedSubnet

Step 18. Deploy Azure Firewall

Deploy:

• Azure Firewall Premium
• Firewall Policy
• Threat Intelligence mode
• DNS proxy enabled
• Application rules
• Network rules
• DNAT rules only if required

Recommended rules:

Allow internal Azure platform traffic
Allow required Microsoft update endpoints
Allow workload-to-approved-PaaS endpoints
Deny all internet traffic by default
Log all denied traffic

Step 19. Deploy VPN Gateway or ExpressRoute Gateway

Use VPN Gateway when:

• Smaller branch connectivity
• Lower cost required
• Backup connectivity needed

Use ExpressRoute when:

• Enterprise-grade private connectivity is required
• Predictable latency is needed
• Large data transfer is expected

Step 20. Deploy Azure Bastion

Deploy Azure Bastion in the hub.

Rules:

• No public IPs on virtual machines
• Admin access only through Bastion
• Use PIM for administrator access
• Use Just-In-Time access where possible

10. Phase 7 – Configure Private DNS

Step 21. Create Private DNS Zones

Create common zones:

privatelink.blob.core.windows.net
privatelink.file.core.windows.net
privatelink.queue.core.windows.net
privatelink.table.core.windows.net
privatelink.vaultcore.azure.net
privatelink.database.windows.net
privatelink.azurewebsites.net
privatelink.servicebus.windows.net
privatelink.azurecr.io

Step 22. Link Private DNS Zones to Hub and Spokes

Link zones to:

• Hub VNet
• Production spoke VNets
• Non-production spoke VNets
• Data spoke VNets

Example:

New-AzPrivateDnsVirtualNetworkLink `
  -ResourceGroupName "rg-dns-prod-eastus" `
  -ZoneName "privatelink.blob.core.windows.net" `
  -Name "link-vnet-hub-prod-eastus" `
  -VirtualNetworkId "<vnet-resource-id>" `
  -EnableRegistration:$false

11. Phase 8 – Build Spoke Networks

Step 23. Create Production Spoke VNet

Recommended address space:

Production Spoke: 10.10.0.0/16
App Subnet: 10.10.1.0/24
Data Subnet: 10.10.2.0/24
Private Endpoint Subnet: 10.10.10.0/24
Management Subnet: 10.10.20.0/24

Step 24. Create Non-Production Spoke VNet

Non-Production Spoke: 10.20.0.0/16
App Subnet: 10.20.1.0/24
Data Subnet: 10.20.2.0/24
Private Endpoint Subnet: 10.20.10.0/24

Step 25. Create Data Spoke VNet

Data Spoke: 10.30.0.0/16
Data Lake Subnet: 10.30.1.0/24
Synapse Subnet: 10.30.2.0/24
Databricks Subnet: 10.30.3.0/24
Private Endpoint Subnet: 10.30.10.0/24

12. Phase 9 – Configure VNet Peering

Step 26. Peer Hub to Spokes

Configure:

• Hub to production spoke
• Production spoke to hub
• Hub to non-production spoke
• Non-production spoke to hub
• Hub to data spoke
• Data spoke to hub

Peering rules:

• Allow forwarded traffic
• Allow gateway transit from hub
• Use remote gateway from spoke
• Do not allow direct spoke-to-spoke unless explicitly required

Step 27. Configure User Defined Routes

Create route table for each spoke subnet.

Default route:

Address Prefix: 0.0.0.0/0
Next Hop Type: Virtual Appliance
Next Hop IP: Azure Firewall private IP

Apply route table to:

• App subnet
• Data subnet
• Management subnet

Do not apply forced tunneling blindly to private endpoint subnets unless the routing design has been tested.

13. Phase 10 – Configure Network Security Groups

Step 28. Create NSGs for Each Subnet Type

Recommended NSGs:

nsg-prod-app
nsg-prod-data
nsg-prod-management
nsg-prod-privateendpoint
nsg-nonprod-app
nsg-data-analytics

Step 29. Apply Baseline NSG Rules

Recommended inbound model:

Deny all inbound from internet
Allow required internal subnet traffic
Allow Azure Bastion to management ports
Allow application gateway or load balancer traffic only where required
Deny direct RDP and SSH from internet

Recommended outbound model:

Allow required Azure platform services
Allow private endpoint traffic
Force internet-bound traffic to Azure Firewall
Deny unnecessary outbound internet access

14. Phase 11 – Deploy Centralized Monitoring

Step 30. Create Log Analytics Workspace

Deploy in Management subscription:

rg-management-monitoring-prod-eastus
law-enterprise-prod-eastus

Step 31. Configure Diagnostic Settings

Send logs from all critical resources to Log Analytics:

• Activity Logs
• Azure Firewall logs
• Key Vault logs
• Storage logs
• NSG flow logs
• VPN Gateway logs
• ExpressRoute logs
• App Service logs
• AKS logs
• SQL logs

Step 32. Configure Azure Monitor Alerts

Create alerts for:

• Failed privileged sign-ins
• Policy non-compliance
• Firewall deny spikes
• VPN tunnel down
• ExpressRoute circuit down
• VM CPU/memory/disk thresholds
• Key Vault access failures
• Public IP creation attempts

Microsoft’s Azure readiness guidance describes platform landing zone components as including governance, shared services, connectivity, security, and monitoring.

15. Phase 12 – Deploy Microsoft Sentinel

Step 33. Enable Microsoft Sentinel

Enable Sentinel on the centralized Log Analytics Workspace.

Configure connectors:

• Microsoft Entra ID
• Microsoft Defender for Cloud
• Microsoft Defender XDR
• Azure Activity
• Azure Firewall
• Key Vault
• Office 365
• Windows Security Events
• DNS logs

Step 34. Configure Analytics Rules

Create Sentinel analytics for:

• Impossible travel
• Privileged role assignment
• Multiple failed sign-ins
• Suspicious firewall traffic
• Public IP deployment
• Key Vault secret access anomaly
• Malware detection
• Suspicious PowerShell execution

Step 35. Configure Sentinel Playbooks

Use Logic Apps for:

• Notify Security Operations
• Create incident ticket
• Disable compromised account
• Block source IP
• Trigger investigation workflow

16. Phase 13 – Configure Microsoft Defender for Cloud

Step 36. Enable Defender Plans

Enable Defender for:

• Servers
• Storage
• SQL
• Containers
• Key Vault
• App Service
• Resource Manager
• DNS where required

Step 37. Configure Security Posture Management

Enable:

• Secure Score tracking
• Regulatory compliance dashboard
• Workload protections
• Vulnerability assessment
• JIT VM access
• Adaptive application controls where appropriate

17. Phase 14 – Configure Key Vault and Secrets Management

Step 38. Deploy Central Key Vaults

Recommended model:

kv-platform-prod-eastus
kv-app-prod-eastus
kv-data-prod-eastus

Configuration:

• RBAC authorization enabled
• Soft delete enabled
• Purge protection enabled
• Public network access disabled
• Private endpoint enabled
• Diagnostic logs enabled

Step 39. Store Secrets and Certificates

Store:

• Application secrets
• API keys
• Certificates
• Encryption keys
• Automation credentials

Do not store secrets in:

• Scripts
• Pipelines
• ARM templates
• Bicep files
• Terraform variable files
• Git repositories

18. Phase 15 – Configure Workload Landing Zones

Step 40. Create Resource Group Standards

Recommended naming:

rg-[appname]-[environment]-[region]-[number]

Examples:

rg-payroll-prod-eastus-001
rg-payroll-dev-eastus-001
rg-data-prod-eastus-001

Step 41. Deploy Application Workloads

Production workload pattern:

Application Gateway or Front Door
App Service / AKS / VM Scale Set
Private Endpoint
Azure SQL / Storage / Key Vault
Log Analytics integration
Defender enabled
Backup enabled

Step 42. Deploy Data Workloads

Data workload pattern:

Azure Data Lake Storage
Azure Data Factory
Azure Synapse Analytics
Azure Databricks
Private Endpoints
Managed Identities
RBAC and ACLs
Centralized logging

19. Phase 16 – Configure DevOps and Automation

Step 43. Create Repository Structure

Recommended structure:

azure-landing-zone/
│
├── platform/
│   ├── management-groups/
│   ├── policy/
│   ├── rbac/
│   ├── connectivity/
│   ├── monitoring/
│   └── security/
│
├── landing-zones/
│   ├── corp/
│   ├── online/
│   └── data/
│
├── modules/
│   ├── network/
│   ├── keyvault/
│   ├── storage/
│   ├── monitor/
│   └── policy/
│
└── pipelines/

Step 44. Configure CI/CD Pipeline

Pipeline stages:

Validate
Security Scan
Plan
Approve
Deploy
Post-Deployment Validation

Use:

• Bicep or Terraform
• Azure DevOps or GitHub Actions
• Pull request approval
• Branch protection
• Secrets from Key Vault
• Separate pipelines for platform and workloads

20. Phase 17 – Configure Cost Management

Step 45. Configure Budgets

Create budgets per:

• Subscription
• Business unit
• Environment
• Application

Example budgets:

Production Corp: $50,000/month
Non-Production Corp: $15,000/month
Data Platform: $40,000/month
Sandbox: $5,000/month

Step 46. Configure Cost Alerts

Alert thresholds:

50 percent
75 percent
90 percent
100 percent
110 percent

Step 47. Configure Cost Optimization Controls

Apply:

• Reserved Instances
• Savings Plans
• Auto-shutdown for Dev/Test VMs
• SKU restrictions
• Storage lifecycle policies
• Unattached disk cleanup
• Idle public IP cleanup

21. Phase 18 – Configure Backup and Disaster Recovery

Step 48. Deploy Recovery Services Vaults

Recommended vaults:

rsv-prod-eastus
rsv-nonprod-eastus
rsv-data-eastus

Configuration:

• Soft delete enabled
• Immutability enabled where required
• Cross-region restore where required
• Private endpoint where supported
• Diagnostic logs enabled

Step 49. Configure Backup Policies

Recommended backup tiers:

Tier 1: Daily backup, long-term retention, cross-region restore
Tier 2: Daily backup, medium retention
Tier 3: Weekly backup, short retention

Step 50. Configure Azure Site Recovery

Use ASR for:

• Critical VMs
• Legacy applications
• Applications requiring regional failover

Document:

• RTO
• RPO
• Recovery region
• Failover order
• Test failover schedule
• Runbooks

22. Phase 19 – Configure Security Baselines

Step 51. Apply Production Security Baseline

Production must enforce:

• No public IPs unless approved
• No unrestricted inbound traffic
• Private endpoints for PaaS
• Key Vault soft delete and purge protection
• Defender for Cloud enabled
• Diagnostic logs enabled
• Encryption enabled
• MFA and Conditional Access enforced
• PIM for privileged roles

Step 52. Apply Non-Production Security Baseline

Non-production must enforce:

• Required tags
• Region restrictions
• Diagnostic logs
• Defender where required
• No uncontrolled public exposure
• Budget limits
• Auto-shutdown policies

Step 53. Apply Sandbox Security Baseline

Sandbox must enforce:

• Strong budget limits
• Expiration tags
• Restricted SKUs
• Restricted regions
• No production connectivity
• No sensitive data
• Automatic cleanup policy

23. Phase 20 – Validation Checklist

Step 54. Validate Identity

Confirm:

• Break-glass accounts exist
• MFA is enabled
• PIM is configured
• Conditional Access policies are active
• Admin roles are assigned to groups
• No unnecessary Global Administrators exist

Step 55. Validate Governance

Confirm:

• Management groups exist
• Subscriptions are placed correctly
• Azure Policy assignments are active
• Required tags are enforced
• Deny policies are working
• Compliance dashboard is visible

Step 56. Validate Network

Confirm:

• Hub VNet exists
• Spoke VNets exist
• VNet peerings are active
• Firewall routes are applied
• VPN or ExpressRoute is connected
• Private DNS resolution works
• Private endpoints resolve correctly

Step 57. Validate Security

Confirm:

• Defender for Cloud is enabled
• Sentinel is enabled
• Key Vault private endpoints work
• Firewall logging is enabled
• NSGs are applied
• No unauthorized public IPs exist

Step 58. Validate Monitoring

Confirm:

• Log Analytics receives logs
• Diagnostic settings are enabled
• Alerts are firing correctly
• Dashboards are available
• Activity logs are collected centrally

Step 59. Validate Backup and DR

Confirm:

• Recovery Services Vaults exist
• Backup policies are assigned
• Test restore completed
• ASR replication is healthy
• DR runbooks are documented

24. Final Implementation Order

Use this order in real enterprise deployment:

1. Prepare tenant and identity
2. Create management groups
3. Create platform subscriptions
4. Create workload subscriptions
5. Assign RBAC
6. Apply baseline policies
7. Build hub network
8. Configure firewall, VPN, ExpressRoute, and Bastion
9. Create Private DNS zones
10. Build spoke networks
11. Configure VNet peering
12. Configure route tables and NSGs
13. Deploy monitoring workspace
14. Enable Defender for Cloud
15. Enable Microsoft Sentinel
16. Deploy Key Vaults
17. Onboard workloads
18. Configure backup and disaster recovery
19. Configure DevOps pipelines
20. Validate compliance and operations

25. Final Architecture Outcome

After implementation, the enterprise has:

• Centralized identity
• Centralized governance
• Centralized networking
• Centralized monitoring
• Centralized security
• Isolated workload subscriptions
• Controlled production and non-production environments
• Private PaaS access
• Policy-driven compliance
• Automated deployment model
• Enterprise-ready Azure foundation