Azure Landing Zones Part 5 - Deploying a New Landing Zone

Introduction

Welcome to the fifth post in our Azure Landing Zones series! We’ve covered the Connectivity and Management Subscriptions, governance with Azure Policies, and how to monitor and optimize your environment. Now it’s time to put all the pieces together and deploy a new Azure Landing Zone.

An Azure Landing Zone is more than just a subscription—it’s a fully configured environment designed to host your workloads securely, efficiently, and at scale. In this post, we’ll:

1. Walk through the key components of a new Landing Zone.

2. Use Infrastructure-as-Code (Bicep) to automate the deployment.

3. Ensure integration with the existing hub-and-spoke architecture.

By the end of this post, you’ll have a ready-to-use Landing Zone that adheres to best practices for scalability, security, and governance.

---

What’s in a Landing Zone?

A new Landing Zone includes all the resources and configurations needed to support your workloads. Here’s what we’ll deploy:

1. Resource Group Structure: Organized by workload or environment.

2. Virtual Network (VNet): Integrated with the hub-and-spoke architecture.

3. Role-Based Access Control (RBAC): To manage permissions securely.

4. Diagnostic Settings: To enable monitoring and logging.

5. Azure Policy Assignments: To enforce governance.

6. Integration with Management and Connectivity Subscriptions: For centralized logging, monitoring, and networking.

---

Step 1: Plan Your Landing Zone

Before deployment, define the following:

1. Workload Type: Is this Landing Zone for production, development, or testing?

2. Resource Naming Conventions: Follow standardized naming patterns.

3. VNet Design: Allocate an address space and subnet ranges.

4. Tagging Standards: Ensure resources are tagged for cost management and ownership.

5. Policies: Identify which Azure Policies to apply (e.g., region restrictions, tagging requirements).

---

Step 2: Infrastructure-as-Code with Bicep

Here’s a Bicep template to deploy a new Landing Zone with the key components.

targetScope = 'subscription'

  

param location string = 'East US'

param workloadVNetName string = 'WorkloadVNet'

param workloadVNetAddressSpace string = '10.2.0.0/16'

param workloadSubnets array = [

  {

    name: 'AppSubnet'

    addressPrefix: '10.2.1.0/24'

  }

  {

    name: 'DbSubnet'

    addressPrefix: '10.2.2.0/24'

  }

]

param workloadResourceGroupName string = 'WorkloadRG'

param logAnalyticsWorkspaceId string

param hubVNetId string

  

// Create Resource Group

resource workloadRG 'Microsoft.Resources/resourceGroups@2021-04-01' = {

  name: workloadResourceGroupName

  location: location

}

  

// Create Workload VNet

resource workloadVNet 'Microsoft.Network/virtualNetworks@2023-02-01' = {

  name: workloadVNetName

  location: location

  properties: {

    addressSpace: {

      addressPrefixes: [workloadVNetAddressSpace]

    }

    subnets: workloadSubnets

  }

  dependsOn: [workloadRG]

}

  

// Peer Workload VNet to Hub VNet

resource hubToWorkloadPeering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2023-02-01' = {

  name: 'HubToWorkload'

  parent: resourceId('Microsoft.Network/virtualNetworks', hubVNetId)

  properties: {

    remoteVirtualNetwork: {

      id: workloadVNet.id

    }

    allowVirtualNetworkAccess: true

    allowForwardedTraffic: true

  }

}

  

resource workloadToHubPeering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2023-02-01' = {

  name: 'WorkloadToHub'

  parent: workloadVNet

  properties: {

    remoteVirtualNetwork: {

      id: hubVNetId

    }

    allowVirtualNetworkAccess: true

    allowForwardedTraffic: true

    useRemoteGateways: true

  }

}

  

// Diagnostic Settings for Workload VNet

resource diagnosticSettings 'Microsoft.Insights/diagnosticSettings@2021-05-01-preview' = {

  name: 'VNetDiagnostics'

  properties: {

    logs: [

      {

        category: 'Administrative'

        enabled: true

      }

      {

        category: 'Security'

        enabled: true

      }

      {

        category: 'ResourceHealth'

        enabled: true

      }

    ]

    workspaceId: logAnalyticsWorkspaceId

  }

}

---

Step 3: Deploy the Template

1. Prepare Parameters:

   - Replace placeholders like location, workloadVNetName, workloadSubnets, and hubVNetId with your specific values.

2. Run the Deployment:

   ```bash

   az deployment sub create      --template-file ./landing-zone.bicep      --parameters location="East US"      workloadVNetName="ProdVNet"      workloadResourceGroupName="ProdWorkloadRG"      workloadVNetAddressSpace="10.2.0.0/16"      logAnalyticsWorkspaceId="/subscriptions/<sub_id>/resourceGroups/ManagementRG/providers/Microsoft.OperationalInsights/workspaces/ManagementLogs"      hubVNetId="/subscriptions/<sub_id>/resourceGroups/ConnectivityRG/providers/Microsoft.Network/virtualNetworks/HubVNet"

   ```

---

Step 4: Validate the Deployment

After deployment:

1. Check the Resource Group: Verify that the WorkloadRG contains the VNet and diagnostic settings.

2. Test Network Connectivity: Ensure the peering between the hub and workload VNets is operational.

3. Validate Logging: Check the Log Analytics Workspace for diagnostic logs from the workload VNet.

---

Step 5: Integrate Governance

Assign Azure Policies to enforce governance in the new Landing Zone:

1. Tagging Requirements: Ensure resources in the workload are tagged for cost management.

2. Region Restrictions: Restrict resources to approved regions.

3. Security Policies: Enforce encryption and deny public IPs.

---

Best Practices for Landing Zone Deployment

1. Standardize Naming and Tags: Use consistent conventions to improve manageability.

2. Automate Deployment: Use Bicep or Terraform to ensure repeatability.

3. Enable Monitoring: Integrate diagnostics with centralized Log Analytics for visibility.

4. Test Before Production: Always validate network connectivity and security configurations.