Azure landing zones and the STACKIT target architecture

Management groups become folders

A demo landing zone written for this page and assessed by StackToIT on 4 November 2026: two management groups, a policy assignment, a hub and a spoke network with peering, a firewall, a route table, a Log Analytics workspace and a role assignment. Left: the input. Right: the resource blocks of the STACKIT Terraform the engine wrote; the review comments above each block are left out here.

resource "azurerm_management_group" "platform" {
  display_name = "Platform"
  name         = "mg-platform"
}

resource "azurerm_management_group" "landing_zones" {
  display_name               = "Landing Zones"
  name                       = "mg-landing-zones"
  parent_management_group_id = azurerm_management_group.platform.id
}

resource "stackit_resourcemanager_folder" "platform" {
  name                = "Platform"
  parent_container_id = var.folder_parent_container_id
  owner_email         = var.folder_owner_email
}

resource "stackit_resourcemanager_folder" "landing_zones" {
  name                = "landing-zones"
  parent_container_id = stackit_resourcemanager_folder.platform.container_id
  owner_email         = var.folder_owner_email
}

• The hierarchy survives

  The child management group becomes a child folder, through the reference to the parent folder. Check that against the STACKIT Resource Manager documentation, which states (as of November 2026) that STACKIT currently supports a single level of folder hierarchy: a folder inside a folder may not apply as drafted, so flatten the tree or place the second folder under the organization. The run notes that role assignments on a STACKIT folder apply to its projects; the STACKIT access-control page opened for this guide does not describe that inheritance, so test it before you rely on it.

• The identifier does not

  The management group ID is not carried, because STACKIT assigns the folder ID itself. The display name is made a valid STACKIT name, so Landing Zones becomes landing-zones.

• Values you supply

  The parent container and an owner e-mail address have no default: the folders go under the organization or an existing folder you name.

Peering becomes a Network Area

From the same run. Two VNets and their peerings are replaced by one Network Area for the organization. Networks of projects inside the area route to each other privately.

resource "azurerm_virtual_network_peering" "hub_to_spoke" {
  name                      = "hub-to-spoke-orders"
  resource_group_name       = azurerm_resource_group.hub.name
  virtual_network_name      = azurerm_virtual_network.hub.name
  remote_virtual_network_id = azurerm_virtual_network.spoke.id
}

resource "azurerm_virtual_network_peering" "spoke_to_hub" {
  name                      = "spoke-orders-to-hub"
  resource_group_name       = azurerm_resource_group.spoke.name
  virtual_network_name      = azurerm_virtual_network.spoke.name
  remote_virtual_network_id = azurerm_virtual_network.hub.id
}

resource "stackit_network_area" "migrated" {
  organization_id = var.organization_id
  name            = "migrated-network-area"
}

resource "stackit_network_area_region" "migrated" {
  organization_id = var.organization_id
  network_area_id = stackit_network_area.migrated.network_area_id
  ipv4 = {
    network_ranges   = [for p in var.network_area_ranges : { prefix = p }]
    transfer_network = var.network_area_transfer_network
  }
}

• Per-peering settings are gone

  The area has no per-peering settings, so the names, gateway transit, forwarded traffic and subnet selection of the peerings are not generated. The run asks you to check the routing of the area.

• Projects join at creation

  The comment in the file states that the projects of the migrated networks must be created in the area with a networkArea label, and that this cannot be changed after the project exists. Decide the area before you create projects.

• Ranges and transfer network

  The area takes the address spaces of the VNets as its ranges by default. The transfer network, a CIDR the networks do not use, has no default.

What the engine hands to an architect

The firewall, the route table and the policy assignment do not become resource blocks. Left: the three input blocks. Right: waves 1 and 3 of the run's sequencing file, migration/technical-sequencing.md, with the class and confidence of every unit; wave 2 is left out here. The input blocks are not adjacent in main.tf, so each has its own pane, verbatim.

resource "azurerm_subscription_policy_assignment" "allowed_locations" {
  name                 = "allowed-locations"
  subscription_id      = "/subscriptions/00000000-0000-0000-0000-000000000000"
  policy_definition_id = "/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c"

  parameters = jsonencode({
    listOfAllowedLocations = { value = ["germanywestcentral", "northeurope"] }
  })
}

resource "azurerm_firewall" "hub" {
  name                = "fw-hub"
  location            = azurerm_resource_group.hub.location
  resource_group_name = azurerm_resource_group.hub.name
  sku_name            = "AZFW_VNet"
  sku_tier            = "Standard"

  ip_configuration {
    name                 = "primary"
    subnet_id            = azurerm_subnet.firewall.id
    public_ip_address_id = azurerm_public_ip.firewall.id
  }
}

resource "azurerm_route_table" "spoke" {
  name                = "rt-spoke-orders"
  location            = azurerm_resource_group.spoke.location
  resource_group_name = azurerm_resource_group.spoke.name

  route {
    name                   = "default-via-firewall"
    address_prefix         = "0.0.0.0/0"
    next_hop_type          = "VirtualAppliance"
    next_hop_in_ip_address = "10.0.0.4"
  }
}

## Wave 1 — 7 unit(s)

| Unit | Class | Target |
|---|---|---|
| `azurerm_log_analytics_workspace.platform` | RECONFIGURE / MEDIUM | STACKIT Logs / Observability |
| `azurerm_management_group.platform` | RECONFIGURE / MEDIUM | STACKIT folder |
| `azurerm_public_ip.firewall` | RECONFIGURE / MEDIUM | implicit (belongs to the gateway, firewall or load balancer) |
| `azurerm_route_table.spoke` | MANUAL_REVIEW / LOW | — |
| `azurerm_subscription_policy_assignment.allowed_locations` | REDESIGN / MEDIUM | none managed — policy as code in the delivery pipeline (e.g. OPA/Conftest, Checkov) |
| `azurerm_virtual_network.hub` | RECONFIGURE / MEDIUM | STACKIT project networking / Network Area (SNA) |
| `azurerm_virtual_network.spoke` | RECONFIGURE / MEDIUM | STACKIT project networking / Network Area (SNA) |

## Wave 3 — 1 unit(s)

| Unit | Class | Target |
|---|---|---|
| `azurerm_firewall.hub` | MANUAL_REVIEW / LOW | — |

• Azure Firewall: MANUAL_REVIEW

  The run says Azure Firewall has no general-availability STACKIT equivalent. STACKIT Unified Firewall is an opt-in feature that may still change and is not yet in the Terraform provider, so the design chooses between it, security groups or a firewall appliance on STACKIT servers.

• Route table: MANUAL_REVIEW

  The routes the scan lists are a lower bound, because BGP route propagation is on by default and may add routes the configuration does not write. A table drafted from the listed routes would be narrower than the source, so none is drafted and the Network Architect decides.

• Policy assignment: REDESIGN

  STACKIT has no policy engine equivalent. The guardrails move into the pipeline that applies the Terraform (policy as code, for example OPA or Checkov) and into the role design of the organization.

How the landing zone maps

Classes as the run decided them: 10 RECONFIGURE, 2 MANUAL_REVIEW and 1 REDESIGN across 13 units. 6 of them were drafted, 4 need no resource and 3 are held for a person.

Three ways to build the target

The run proposes one target per unit, not an organization. These are the layouts architects usually weigh, and what each means for the units above. The layouts are practice; the assessment of each unit is from the run.

Decide in this order

1. 01

   1. Organization and folders

   The network area and routing tables are organization resources, and the folders sit under the container you name. Fix this first; the other steps need its IDs.

2. 02

   2. The network area and its ranges

   Choose the ranges and the transfer network, then create the projects inside the area. Do not create them first.

3. 03

   3. Projects and roles

   The resource group scope of each resource is an open setting. STACKIT has no resource groups, so you map the boundaries of the old groups to projects and to roles on folders and projects.

4. 04

   4. Routes and egress

   Take the routing decision the run raised, and decide how outbound traffic leaves the networks. The run could not prove how the workload subnet reached the internet in Azure.

5. 05

   5. Logging

   The draft creates a Logs instance with 90 days of retention. Before a source writes to it, create a write access token and set the access list; the draft does neither.

6. 06

   6. Guardrails as code

   Port the policy assignment into the pipeline that applies the Terraform before the first workload is applied.

What the Azure landing zone has that STACKIT does not

• Subscriptions as a vending unit

  The run treats each subscription and resource group as a layout question. STACKIT projects play the role, and creating them is a process you design.

• Central policy

  No managed engine evaluates resources against rules. Your delivery pipeline does.

• Managed central firewall

  Not available as a drafted resource; the design decides.

• Workspace-based monitoring

  KQL queries, workbooks and alerts are rewritten for the tools of the STACKIT Logs and Observability services.

Questions platform teams ask

Sources

• Microsoft Learn: what is an Azure landing zone
• STACKIT Network Area: concepts
• STACKIT security groups: concepts
• STACKIT Resource Manager
• STACKIT docs: Resource Manager organizations and folders
• STACKIT docs: Resource Manager access control