Design Areas

The 8 critical design areas that every Azure Landing Zone must address.

Overview

Microsoft's Cloud Adoption Framework defines 8 design areas for Azure Landing Zones. Each represents a key architectural decision:

1. Azure Billing & Azure AD Tenants

Key Decisions:

• Enterprise Agreement structure
• Subscription organization model
• Cost allocation strategy

Billing Hierarchy

Tenant Considerations

Single Tenant	Multiple Tenants
Simplified management	Isolation between business units
Unified identity	Regulatory requirements
Cross-subscription networking	M&A scenarios
Recommended for most	Rare edge cases

Sample: Cost Allocation Tags

{
  "CostCenter": "CC-12345",
  "Environment": "Production",
  "ApplicationOwner": "app-team@contoso.com",
  "BusinessUnit": "Finance",
  "Project": "SAP-Migration"
}

2. Identity and Access Management

Key Decisions:

• Azure AD configuration
• RBAC model (centralized vs delegated)
• Privileged access management

Identity Architecture

RBAC Strategy

Level	Role	Scope
Platform Admin	Owner	Platform MG
Network Admin	Network Contributor	Connectivity Sub
Security Admin	Security Admin	Root MG
App Team Lead	Contributor	Application Subscription
Developer	Reader	Production, Contributor on Dev

Sample: Custom RBAC Role

{
  "Name": "Landing Zone Owner",
  "Description": "Full control within landing zone, except policy and network",
  "Actions": [
    "*"
  ],
  "NotActions": [
    "Microsoft.Authorization/policyAssignments/*",
    "Microsoft.Network/virtualNetworks/peer/*",
    "Microsoft.Authorization/roleAssignments/write"
  ],
  "AssignableScopes": [
    "/providers/Microsoft.Management/managementGroups/landing-zones"
  ]
}

3. Resource Organization

Key Decisions:

• Management group hierarchy
• Subscription design pattern
• Naming and tagging conventions

Management Group Hierarchy

Tenant Root Group
│
├── Contoso (Intermediate Root)
│   │
│   ├── Platform
│   │   ├── Identity
│   │   ├── Management  
│   │   └── Connectivity
│   │
│   ├── Landing Zones
│   │   ├── Corp
│   │   │   ├── Production
│   │   │   └── Non-Production
│   │   └── Online
│   │       ├── Production
│   │       └── Non-Production
│   │
│   ├── Sandboxes
│   │
│   └── Decommissioned

Naming Convention

{resourceType}-{workload}-{environment}-{region}-{instance}

Examples:
- rg-sap-prod-eastus-001          (Resource Group)
- vnet-hub-prod-eastus-001        (Virtual Network)
- pip-agw-corp-prod-eastus-001    (Public IP)
- st-app1-prod-eastus-001         (Storage Account)
- kv-platform-prod-eastus-001     (Key Vault)

Tagging Strategy

Tag	Purpose	Example
Environment	Lifecycle stage	Production, Development
CostCenter	Billing allocation	CC-12345
Owner	Primary contact	john@contoso.com
Application	Workload name	SAP-Finance
DataClassification	Security level	Confidential
CreatedBy	IaC pipeline or manual	terraform-pipeline

4. Network Topology and Connectivity

Key Decisions:

• Hub-spoke vs Virtual WAN
• IP address planning
• DNS strategy
• Hybrid connectivity

Hub-Spoke Architecture

IP Address Plan

Network	CIDR	Purpose
Hub VNet	10.0.0.0/16	Shared services
GatewaySubnet	10.0.1.0/24	ExpressRoute/VPN
AzureFirewallSubnet	10.0.2.0/24	Azure Firewall
AzureBastionSubnet	10.0.3.0/24	Bastion
Corp Spokes	10.1.0.0/14	Internal workloads
Online Spokes	10.16.0.0/14	Public-facing
Sandbox	10.32.0.0/14	Dev/test

DNS Architecture

5. Security

Key Decisions:

• Security baseline configuration
• Threat detection strategy
• Encryption standards
• Compliance requirements

Security Architecture

Security Baseline Policies

Policy	Effect	Purpose
Require encryption at rest	Deny	Data protection
Require HTTPS	Deny	Transport security
Block public blob access	Deny	Data exposure
Require private endpoints	Audit	Network isolation
Deploy Defender	DeployIfNotExists	Threat detection
Require diagnostic settings	DeployIfNotExists	Logging

Sample: Security Policy Assignment

resource policyAssignment 'Microsoft.Authorization/policyAssignments@2022-06-01' = {
  name: 'security-baseline'
  scope: managementGroup
  properties: {
    policyDefinitionId: '/providers/Microsoft.Authorization/policySetDefinitions/1f3afdf9-d0c9-4c3d-847f-89da613e70a8' // Azure Security Benchmark
    displayName: 'Security Baseline'
    enforcementMode: 'Default'
  }
}

6. Management

Key Decisions:

• Monitoring strategy
• Log retention
• Automation approach
• Update management

Management Architecture

Log Analytics Design

Workspace	Retention	Purpose
Platform	2 years	Security, compliance
Application	90 days	Workload diagnostics
Cost	90 days	Cost analytics

Sample: Diagnostic Setting

resource diagnosticSetting 'Microsoft.Insights/diagnosticSettings@2021-05-01-preview' = {
  name: 'send-to-law'
  scope: storageAccount
  properties: {
    workspaceId: logAnalyticsWorkspace.id
    logs: [
      {
        categoryGroup: 'allLogs'
        enabled: true
      }
    ]
    metrics: [
      {
        category: 'AllMetrics'
        enabled: true
      }
    ]
  }
}

7. Governance

Key Decisions:

• Policy strategy
• Compliance requirements
• Cost management
• Resource lifecycle

Governance Architecture

Policy Assignment Strategy

Scope	Policies	Examples
Root MG	Security baseline	Encryption, HTTPS, diagnostics
Platform MG	Platform-specific	Hub network restrictions
Corp LZ	Internal requirements	Private endpoints required
Online LZ	Public-facing rules	WAF required, DDoS
Sandbox	Relaxed for dev	Audit-only mode

Sample: Cost Management Policy

resource costPolicy 'Microsoft.Authorization/policyDefinitions@2021-06-01' = {
  name: 'deny-expensive-vms'
  properties: {
    displayName: 'Deny Expensive VM SKUs'
    policyType: 'Custom'
    mode: 'All'
    parameters: {}
    policyRule: {
      if: {
        allOf: [
          {
            field: 'type'
            equals: 'Microsoft.Compute/virtualMachines'
          }
          {
            field: 'Microsoft.Compute/virtualMachines/sku.name'
            in: [
              'Standard_M416ms_v2'
              'Standard_M416s_v2'
              'Standard_ND96asr_v4'
            ]
          }
        ]
      }
      then: {
        effect: 'Deny'
      }
    }
  }
}

8. Platform Automation and DevOps

Key Decisions:

• Infrastructure as Code tool
• CI/CD pipeline design
• GitOps strategy
• Subscription vending automation

Platform Automation Architecture

IaC Tool Comparison

Tool	Best For	Learning Curve
Bicep	Azure-native teams	Low
Terraform	Multi-cloud, existing TF teams	Medium
Pulumi	Developer-centric teams	Medium
ARM	Legacy, specific scenarios	High

Sample: GitHub Actions Workflow

name: Deploy Landing Zone

on:
  push:
    branches: [main]
    paths: ['infra/**']

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Azure Login
        uses: azure/login@v1
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
      
      - name: What-If
        uses: azure/arm-deploy@v1
        with:
          scope: managementgroup
          managementGroupId: 'alz'
          region: eastus
          template: ./infra/main.bicep
          additionalArguments: --what-if
      
      - name: Deploy
        uses: azure/arm-deploy@v1
        with:
          scope: managementgroup
          managementGroupId: 'alz'
          region: eastus
          template: ./infra/main.bicep

Design Area Interactions

Key dependencies:

• Identity drives RBAC in Resource Organization
• Network topology affects Security design
• Management requires proper Resource Organization
• Automation implements all other design areas

Quick Reference Card

Design Area	Key Decision	Primary Owner
Billing	Subscription model	Finance + Platform
Identity	RBAC model	Security + Platform
Resource Org	MG hierarchy	Platform
Network	Topology choice	Network + Platform
Security	Baseline policies	Security
Management	Monitoring strategy	Operations
Governance	Policy strategy	Platform + Security
Automation	IaC tooling	Platform

Next Steps

Continue to Management Groups for a deep dive into hierarchical governance.