A landing zone for mid-sized companies, in Terraform or Bicep: the parts that matter

A landing zone is the prepared ground your cloud workloads land on: the account and subscription structure, guard rails, identity, network, logging and cost control, all set up before the first application arrives. Enterprise reference architectures can look like they need a platform team of twenty. A mid-sized company needs the same ideas in a smaller size, written as code, so a team of two can run it. Here is the version I build.

Dominik Heinrich

November 8, 202611 min read

1. What a landing zone covers

Microsoft's Cloud Adoption Framework splits the Azure landing zone into eight design areas: billing and the Entra tenant, identity and access, resource organisation, network topology and connectivity, security, management, governance, and platform automation with DevOps. That list is a good checklist even if you build something much smaller than the reference architecture.

The point of all of it is simple: teams should be able to create a new subscription for an application and have security, network, logging and cost control already in place, instead of every team inventing its own. For a mid-sized company that means a handful of management groups and policies, one hub network, central logs and budgets, all applied by a pipeline.

2. Management groups by purpose, not by department

Management groups let you apply policies and access to many subscriptions at once. A tree can be up to six levels deep, not counting the root and the subscriptions, but a mid-sized company rarely needs more than two or three. I use: one company group at the top, under it Platform (identity, management, connectivity), Landing zones (split into internal and internet-facing if their rules differ), Sandbox for experiments with a budget cap, and Decommissioned for subscriptions on their way out.

Avoid mirroring the org chart. Departments get reorganised; the difference between an internal app and an internet-facing one does not. Purpose-based groups keep policies stable when the company changes.

Tip from practice

One subscription per application and environment is a good default: it is the cleanest boundary for access, network and cost, and it makes the bill readable without any tagging magic.

3. Guard rails as policy, at the top

Azure Policy is where a landing zone earns its keep. Assign the rules on the company management group so they apply to everything below: allowed regions, required tags, no public IP addresses where they aren't needed, diagnostic settings sent to the central workspace, encryption and TLS minimums. Start new rules in audit mode, fix what they find, then switch them to deny.

In an automotive project, Azure Policies and Blueprints enforced security baselines and network rules across every team, and a regulated application moved to Azure Kubernetes Service without loosening a single control. The teams didn't need to remember the rules; the platform refused anything that broke them.

hcl

# Allowed regions for everything under the company management group
resource "azurerm_management_group_policy_assignment" "allowed_locations" {
  name                 = "allowed-locations"
  management_group_id  = azurerm_management_group.company.id
  policy_definition_id = "/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c" # built-in: Allowed locations

  parameters = jsonencode({
    listOfAllowedLocations = { value = ["switzerlandnorth", "westeurope"] }
  })
}

Landing zone for a mid-sized company on Azure: Terraform or Bicep in Git applied by a pipeline; under the Entra ID tenant root a company management group with policies for regions, tags and no public IPs; a Platform group with identity (groups, PIM), management (logs, Defender), connectivity (hub network, firewall), budgets with alerts per subscription and tags for owner, cost centre and environment; a Landing zones group with Corp and Online subscriptions and spoke networks peered to the hub; plus Sandbox and Decommissioned groups. — The landing zone structure I use for mid-sized companies: platform, landing zones, sandbox and decommissioned, all applied as code. Click to open full size.

4. One identity, no standing admin rights

Everything signs in through Entra ID. Give rights to groups, never to individual people, so joiners and leavers are handled in one place. Owner and other high roles are not assigned permanently: with Privileged Identity Management, people request them for a few hours, with a reason, and it is logged.

Applications use managed identities instead of stored secrets wherever the service supports it, and the rest of the secrets live in Key Vault with access by identity. Keep two emergency accounts outside the normal flow, with strong protection and alerts on every sign-in, so a broken identity setup can't lock you out of your own cloud.

5. Network: one hub, a spoke per workload

Hub-and-spoke is the right default for most mid-sized companies. The hub holds the shared pieces: the firewall, the connection to the office or data centre (VPN or ExpressRoute), DNS. Every workload gets its own spoke network, peered to the hub, with traffic between spokes and to the internet going through the firewall where you can see and control it.

Plan address ranges once, for years, and write them down; overlapping ranges are one of the most expensive mistakes to fix later. Use private endpoints for databases and storage so they are not reachable from the internet at all, and let policy deny public endpoints where they aren't intended.

6. Logs, security and a budget on every subscription

The management subscription holds the central Log Analytics workspace, Defender for Cloud and the alerting. Policy makes sure every new resource sends its diagnostics there, so nobody has to remember. Alerts go to people who can act, not to a shared mailbox nobody reads.

Cost control is part of the landing zone, not an afterthought. Every subscription gets a budget with alerts on the forecast, and every resource gets the tags owner, cost centre and environment, enforced by policy. In the automotive project, cost controls and a tagging strategy meant every euro had an owner; that is what turns a cloud bill from a surprise into a conversation.

7. Everything as code, applied by a pipeline

A landing zone built by clicking in the portal drifts within weeks. Write it as code in Git and let a pipeline apply it, with a plan that someone reviews before every change. You don't need to start from nothing: Microsoft maintains ready-made Azure landing zone code for Terraform and for Bicep (the Terraform module is part of Azure Verified Modules), which implements the reference structure and lets you switch parts on and off.

For a mid-sized company I usually take those modules, cut them down to what is needed now, and keep the configuration in one small repository: management groups, policy assignments, the hub network, budgets and role assignments. New application teams then get a subscription through a pull request, with everything above already in place.

8. The same structure on AWS and Google Cloud

On AWS the building blocks have different names but the same jobs. Accounts play the role of subscriptions, organisational units the role of management groups, and service control policies set guard rails across them. Note how SCPs work: they never grant permissions, they define the maximum that roles in those accounts can have. AWS Control Tower sets up a landing zone with these pieces, applies controls (also called guardrails) and creates new accounts from templates through Account Factory.

Google Cloud publishes its own landing zone design guide with folders, folder-level policies and Shared VPC networks per environment. Whichever cloud you are on, the five decisions stay the same: structure by purpose, guard rails at the top, one identity without standing admin rights, a central network and central logs, and everything as code.

Takeaway
A good landing zone is small, boring and written as code: purpose-based structure, guard rails as policy at the top, one identity, one hub network, central logs and a budget on every subscription.

Real projects behind this

A regulated workload moves to Azure, fully in Terraform

Try it yourself

Cloud bill estimate

Want this in your company? Let's talk mail@dominikheinrich.ch

Sources and official guides