What is a landing zone

A landing zone is a blueprint applied to an empty Azure subscription — a standardized foundation that every cloud application must follow. It defines how costs are controlled, what security and operational baselines are enforced, and it provides a ready-to-use deployment pipeline so application teams never have to start from scratch.

The landing zone is built for team autonomy, minimized dependencies on centrally managed components, and promotes a self-service model to create or update landing zones to match an application’s path from development to production.

What You Get

  • Self-service — create, update, and remove landing zones via GitHub Issues and Pull Requests.
  • You Build It, You Run It — design, implement, and operate the application from start to sunset.
  • Autonomy — foundational Azure configuration baked directly into the landing zone, without any shared services.
  • Hello-World — a getting-started deployment pipeline aligned with platform management principles.

Platform Rules

  • Cost — tracked at the application level — every landing zone maps directly to the app’s invoice section.
  • Isolated Landing Zones — one application — one environment — one landing zone: a isolated subscription for each application/environment.
  • Policy-driven governance — Azure Policies enforce allowed configurations and deny anything outside the security baseline.
  • Single Region Deployments: deployment flow is streamlined to a single Azure region.

Step 1: Register the Application

Before creating the first landing zone, the application must be registered. This step establishes the application’s financial boundary by creating a dedicated Azure invoice section and defines metadata—such as owner, engineering contacts, and criticality—that is automatically applied to every landing zone.

The registration workflow also provisions an Entra ID reader group with read-only visibility into all future subscriptions, and sets up a GitHub repository containing getting-started deployment pipelines and Bicep modules. Application-specific values are stored as GitHub environment variables, enabling automation to create and manage landing zones as a self-service experience.

Step 2: Request Landing Zone

Users create a new landing zone by providing environment-specific details in the New Landing Zone Request GitHub Issue template. The automated workflow generates the landing zone parameter file and a dedicated GitHub Actions workflow, then opens a Pull Request.

Once the Pull Request is merged into the main branch, the platform provisions and configures the Azure landing zone. The landing zone is considered ready when the user receives an Azure Monitor email indicating that a new Action Group has been created — an indirect confirmation that budgets, policies, and guardrails have been applied and the environment is ready to use.

Landing Zone parameters 

using '../bicep/main.bicep'

param appName = 'HeyAzure'
param environment = 'test'
param budget = 100
param engineerEmail = 'mantas@outlook.dk'
param addressPrefix = '24'
param subscriptionId = ''

param exemptions = [
  {
    clarifications: 'pam param pam pam - urgen!'
    policyToExclude: policyReference.allowedLocations.assignmentId
    referenceId: [
      policyReference.allowedLocations.referenceIds['allowed-locations']
    ]
  }
  {
    clarifications: 'another policy exemption'
    policyToExclude: policyReference.denyCrossTenantReplicati.assignmentId
    referenceId: [
      policyReference.denyCrossTenantReplicati.referenceIds['storageAccount-crossTenantReplication']
    ]
  }
]

// values are fetched from GitHub Variables
param applicationReaderEntraGroupId = readEnvironmentVariable('ENTRAID_READER_GROUP_ID', '')
param diagnosticSettingsPolicyResourceId = readEnvironmentVariable('POLICY_CONFIG_DIAGNOSTICSETTINGS_RESOURCE_ID', '')

var policyReference = loadJsonContent('policy-assignment-reference.json')

  • Landing zone name — Automatically generated by concatenating: management-group-name - application-name - environment.

  • Budget — Alerts are triggered when 80% of the configured amount is reached.
    A notification email is sent to the engineer’s email address.

  • Engineer email — Used for sending budget alerts and Azure Health notifications.

  • addressPrefix — Defines the virtual network address space for the landing zone. The default is /24, which provides 255 IP addresses. Once configured, it cannot be changed later.

  • subscriptionId — Used when Bring-Your-Own-Subscription is required so the landing zone can be built on top of an existing Azure subscription. In all other cases, this value should be left empty so automation can provision a new subscription.

  • exemptions — Azure Policy exemptions applied to the landing zone. The policyReferences variable provides up-to-date Azure Policy assignment and reference IDs, removing the need for landing zone users to handle cumbersome resource IDs.

  • applicationReaderEntraGroupId — The Entra ID group that provides read-only access at the landing zone level. This group is created automatically during the application registration process.

  • diagnosticSettingsPolicyResourceId — The resource ID used to reference centrally managed Azure Policy definitions. It allows the landing zone to automatically apply the organisation-wide diagnostic settings policy. This value is generated by the Azure-Policy workflow.

GitHub - Management Plane