Introduction

Moving to the cloud isn’t just about deploying virtual machines and services—it’s about creating a repeatable, secure, and governed foundation that scales as your organization grows. Microsoft’s Azure Landing Zone Accelerator provides a structured way to establish this foundation, and Azure Verified Modules (AVMs) are the building blocks that make it reliable.

In this article, we’ll explore what the Landing Zone Accelerator is, how AVMs work, and why they’re a game changer for enterprises adopting Azure.

---

The Challenge of Cloud Foundations

Enterprises often face a common set of challenges when deploying workloads in Azure:

• Inconsistent configurations across environments

• Security and compliance gaps due to misapplied policies

• Lack of repeatability when scaling workloads

• Manual effort to reapply governance and monitoring settings

Without a baseline, cloud sprawl can lead to uncontrolled costs, security risks, and operational headaches. That’s where the Landing Zone Accelerator and Verified Modules come in.

---

What is the Azure Landing Zone Accelerator?

The Azure Landing Zone Accelerator is Microsoft’s implementation of Cloud Adoption Framework (CAF) landing zones. It provides:

• Architecture guidance: how to design identity, networking, security, and monitoring foundations

• Pre-built modules: reusable templates for deploying best-practice Azure resources

• Governance and compliance: policy-driven controls to enforce security standards

• Flexibility: deploy piecemeal (per module) or as a full baseline

Think of it as a starter kit for enterprise-scale Azure environments—pre-configured, opinionated, and ready to extend.

---

Introducing Azure Verified Modules (AVMs)

So what makes a module “verified”?

An Azure Verified Module is a reusable infrastructure-as-code module that has been:

• Reviewed by Microsoft engineers

• Aligned with Azure best practices

• Validated with testing for functionality and security

• Versioned and maintained for lifecycle management

Unlike custom or community modules, AVMs give you confidence—you’re using a module that’s been vetted to meet enterprise and security standards.

Examples of AVMs include:

• Identity & Role assignments

• Virtual networks and subnets

• Monitoring and diagnostic settings

• Security policies (e.g., Defender for Cloud)

---

How AVMs Fit Into the Landing Zone Accelerator

The Landing Zone Accelerator is essentially a composition of AVMs. For example:

1. Identity & Access

   • Azure AD integration

   • Role-based access control (RBAC)

2. Networking

   • Virtual networks, subnets, private DNS, and firewalls

3. Management & Monitoring

   • Azure Monitor setup

   • Log Analytics workspaces

   • Policy assignments

4. Security & Compliance

   • Microsoft Defender for Cloud policies

   • Blueprints for regulatory compliance

Each of these pieces can be deployed via a verified module, ensuring consistent quality and security.

The Landing Zone Accelerator is essentially a composition of AVMs. Each AVM handles a specific domain (identity, networking, monitoring, security), and together they provide a full enterprise-ready foundation.

One of the most important first steps is subscription vending.

Example: Subscription Vending with AVMs

Subscription vending is the process of creating and configuring new Azure subscriptions in a standardized, governed way. Instead of manually creating subscriptions and applying inconsistent configurations, you can use AVMs to automate and enforce standards.

A subscription vending AVM might include:

• Creation of the subscription

• Assignment of management groups

• Application of Azure Policy for compliance

• Enabling monitoring and diagnostic settings

• Setting up baseline RBAC roles

This ensures every subscription is born secure, compliant, and consistent—a key requirement for large organizations managing hundreds of workloads.

Bootstrapping Your Landing Zone

Once subscriptions are managed, the next step is bootstrapping. This is about preparing your environment so that other teams can deploy confidently.

Bootstrapping often includes:

• Assigning core management groups and policies

• Deploying identity AVMs (like role assignments, UAMI/SMI configurations)

• Setting up automation hooks (CI/CD pipelines for IaC deployments)

• Ensuring billing and tagging standards are enforced

Bootstrapping is like laying the concrete foundation of a house—you don’t see it once it’s built, but everything depends on it.

Platform Landing Zone

The platform landing zone is where your enterprise shared services live. It’s built using AVMs to establish services that all applications and business units will consume, such as:

• Networking AVMs: Hub-and-spoke VNet, private DNS, firewalls, ExpressRoute/Virtual WAN

• Security AVMs: Microsoft Defender for Cloud, Sentinel integrations, Key Vault

• Management AVMs: Log Analytics, Azure Monitor, policy baselines, update management

The platform landing zone provides the secure, monitored backbone of your cloud estate. Without it, application teams would have to reinvent networking, monitoring, and security every time.

Application Landing Zone

Finally, we reach the application landing zone—where business workloads actually run.

AVMs in this layer handle:

• App-specific networking (VNets/subnets inside the spoke)

• Identity (role assignments, managed identities)

• Observability (diagnostic settings tied to central monitoring)

• Security policies tailored to workloads (e.g., PCI-DSS apps, healthcare apps)

Because of the baseline AVMs applied during subscription vending and the shared platform landing zone, the application landing zone can focus purely on the workload without worrying about governance gaps.

Policy Context & Policy Versioning

When using Azure Landing Zones and Azure Verified Modules (AVMs), policies are central to ensuring consistent, secure, and compliant infrastructure. They act as guardrails—restricting what can be deployed, enforcing settings, and ensuring resources meet standards automatically. The Landing Zone Accelerator has a formal approach for policies, especially around policy versioning, which helps maintain stability and flexibility over time.

What is Policy Context

• A policy in Azure is a definition that enforces rules over resources—e.g., allowed VM sizes, permitted locations, enabling diagnostic logs, enforcing tag usage.

• In Landing Zones, policies are typically applied via initiative definitions (policy sets) that bundle multiple individual policies together. These ensure a baseline of compliance across identity, security, networking, and monitoring.

• The AVMs and the Landing Zone Accelerator include many of these policy initiatives out of the box, so when you deploy modules, relevant policies are “baked in.”

Why Policy Versioning Matters

Policy versioning in the Azure Landing Zones Accelerator guides how policies evolve while keeping backward compatibility and avoiding breaking changes. Key points:

• Immutable releases: Once a policy (or initiative) version is released and consumed, that version should not change in a breaking way. If new policy requirements or enhancements are needed, a new version is published.

• Semver or version numbering: Policies and initiatives are versioned explicitly. This means you (or your deployment pipelines) can pin to policy version 1.0.0, 1.1.0, etc., ensuring that when Azure or Microsoft releases updates for policy sets, your environment doesn’t change unexpectedly.

• Upgrade paths: When newer policy versions are released, you can plan in advance—to test them in non-production, to review impact, and to gradually promote to production.

How Policy Versioning Works in the Accelerator

• The Landing Zone Accelerator stores policy definitions and initiatives in its GitHub repository. Each policy package or module has a version number. When you reference a policy module in your Bicep or AVM template, you specify the version you want.

• Example snippet (in Bicep / AVM context):

    module baselinePolicy 'br/public:avm/policy/initiative/baseline:1.2.0' = {
      name: 'baseline-policy'
      params: {
        allowedLocations: [ 'eastus', 'australiaeast' ]
        tagDefaults: { environment: 'prod' }
      }
    }
  

  In this example, baseline:1.2.0 pins the policy initiative to version 1.2.0 so updates later to version 1.3.0 or 2.0.0 are opt-in rather than automatic.

Best Practices: Using Policy Versioning in Your Adoption

• Pin your policy versions in your IaC templates so you know exactly what controls are being applied.

• Monitor new releases of policy versions from the Accelerator repo. Review change logs.

• Test policy changes in dev/test subscriptions before rolling them out.

• Coordinate with your governance team—policy changes can impact deployments, cost, and compliance audits.

Why This Matters

This layered approach—subscription vending → bootstrapping → platform landing zone → application landing zone—is what makes the Landing Zone Accelerator with AVMs so powerful.

Each step builds on the previous one:

1. Subscriptions are created consistently.

2. Bootstrapping enforces governance.

3. Platform services are shared and secure.

4. Applications deploy quickly and safely.

This ensures your Azure environment is scalable, secure, and operationally efficient from day one.

References

• Azure Landing Zones – https://azure.github.io/Azure-Landing-Zones/

• Landing Zone Accelerator (User Guide) – https://azure.github.io/Azure-Landing-Zones/accelerator/