I simply do not understand Azure landing zones.
A sentence I keep encountering
Azure Landing Zones — explained simply
And frankly, I can see why. Cloud architecture sounds abstract — but what if we thought of it as a classic server room?
What is an Azure Landing Zone?
An Azure Landing Zone is the prepared environment that applications later move into — with networking, access rules, naming conventions and cost allocation in place before the first virtual machine starts. Not the application itself, but the frame in which it can be run securely and traceably.
The term comes from the Microsoft Cloud Adoption Framework. It describes not a single technology but a bundle of decisions you make once and then stop discussing every time.
The four questions a landing zone answers
How is the whole thing structured?
Management groups gather subscriptions, subscriptions bundle resource groups, and inside those sit the actual resources. This hierarchy determines where rules take effect and how costs are attributed.
Who is allowed to do what?
Access rights are granted through roles, not to individual people. Whoever takes on a task gets the role — whoever hands it over loses it automatically.
How does traffic flow?
The network design defines which areas may talk to each other. The common pattern is hub-and-spoke: a central area holding the shared services, with the individual working areas attached to it.
What is permitted?
Azure Policy checks every resource on creation against the defined rules — which regions are allowed, which encryption is mandatory, which tags may be missing and which may not.
Why this should be settled before the first project
A landing zone can be built retrospectively. It just becomes expensive.
Makes decisions under time pressure
Every resource already running has to be moved, renamed or re-permissioned — in live operation, with all the dependencies that have grown in the meantime.
Makes the same decisions once
Structure, roles, rules, and network design are set before the first productive workload. After that, the frame gets used — nothing is renegotiated case by case.
How these four areas feel when you picture them as a building is what the next section shows.
Plan first, then equip
Nobody puts a server rack into a room without thinking it through first. Those same considerations are surprisingly often missing in cloud projects — although they are exactly the same.
Before the first server enters a room, a series of questions gets settled. Where is the room in the first place? Ground floor or basement, flood risk, how far to the nearest power supply. How many racks fit in, and how much space is left to expand? How many servers per rack, and does the cooling still cope in summer?
Then the questions you only think about once something happens: which fire suppression system — water destroys what it is meant to save, so gas. Who gets in during an emergency, and how quickly? What happens during a power cut — does the uninterruptible supply bridge long enough for the generator to start?
None of these questions concerns an individual server. All of them concern the frame in which servers will later stand.
And that is exactly what a landing zone is. Where does the data sit — which region? How many subscriptions do we need, and how do we cut them? What happens when someone accidentally creates a resource in the wrong region — does a rule catch it, or does nobody notice? Who reaches the environment in an emergency, and how is that logged?
The only difference from the server room is that in the cloud you can keep building at any time. That sounds like freedom but is the real danger: in a server room, lack of space forces planning. In the cloud you can grow without order for as long as you like — and only notice when nobody can say any more which resource belongs to whom, or what it costs.
If you want to picture it on a larger scale: Sofian’s City describes the same landscape as an entire city — with an identity town hall, traffic routing and building regulations. The landing zone is the building regulation within it, defining what may be built at all.
Two worlds, one logic
The principles of a well-planned server room transfer almost one to one onto an Azure landing zone. Anyone who knows the one has already made a start on the other.
The same logic · a different medium
Illustration: own graphic, created with AI assistance
Eighteen concepts,
eighteen translations
Every layer of the Azure landing zone has its direct counterpart in the server room. Once you have absorbed these eighteen pairings, the rest of the cloud terminology suddenly becomes intuitive.
The building
The overarching frame in which everything sits. Address, access and responsibility are anchored here.
Subscription
The top-level billing and administration unit. Everything below it belongs organisationally to one subscription.
The server rack
Groups servers that belong together logically — by application, environment or team.
Resource Group
Groups Azure resources that share a life cycle, a location or an owner.
The individual servers
The workhorses: physical machines with CPU, memory, storage and a clearly defined job.
Resources
Virtual machines, storage accounts, app services, SQL databases — everything that provides compute or storage.
The building complex
Several buildings on one campus, managed together — with overarching rules for every site.
Management Group
Bundles several subscriptions and passes policies and access rights down the hierarchy.
The room labelling
Inventory stickers and door signs — at a glance you can see what a room belongs to and who is responsible.
Tags
Metadata such as cost centre, environment or owner attached to resources — important for billing and for order.
The building regulations
Fire safety, escape routes, structural engineering — requirements that must be met automatically during construction, without case-by-case debate.
Azure Policy
Enforces rules automatically — permitted regions or mandatory tags, for example — and prevents deviations at the moment of creation.
The master key
Opens every door. Whoever holds it can get in anywhere — a blessing and a risk at once.
The Owner role
Full control over every resource — including granting permissions. Use sparingly and secure it through PIM.
Access control
Card systems, door codes, video surveillance — governing who may enter which room and when.
Azure RBAC
Role-based access control governs in detail which identity may carry out which action at which scope.
The storage system
SAN and NAS in the server room: the central home for files and databases — with RAID guarding against disk failure.
Storage Account
Central storage for blobs, files, tables and queues — redundancy by configuration instead of a RAID controller.
Monitoring
Alarms, sensors, temperature and power monitoring: problems should surface before anyone has to report them.
Azure Monitor
Metrics, logs and alerts for every resource — the cloud’s sensor network, including notifications before something fails.
The safe
Certificates, keys and valuables don’t sit on a shelf — they live in the safe, with documented access.
Key Vault
Stores secrets, certificates and keys centrally; applications fetch them at runtime instead of carrying them in code.
The emergency key
Sealed in a box for the worst case: when card systems or locks fail, you can still get in.
Break glass account
An emergency access path outside the normal rules — tightly monitored, documented and reserved strictly for emergencies.
The cabling
Network cabling, switches and routers — they determine which areas of the building are allowed to talk to each other.
Virtual Network
VNet, peering, gateways and NSGs — the inner connection fabric that steers traffic between the resources.
The backup tapes
Regular backups on tape, kept in an external vault or at a disaster-recovery site.
Azure Backup
Azure Backup, Site Recovery and geo-redundancy — versioned backups, stored in a geographically separated location.
The secondary site
Multiple buildings in different cities, or campus areas with independent power and network supply.
Regions & Availability Zones
Multi-region deployment and Availability Zones — so an outage in one place doesn’t take everything down.
The blueprint
Blueprint, structural calculations and documented construction procedures — no serious build starts without them.
Infrastructure as Code
Bicep, Terraform, ARM templates and pipelines — the landing zone is described in code, versioned and built repeatably.
The audit report
Regular safety inspections, audit reports and evidence for certifications.
Compliance Manager
Azure Compliance Manager, audit logs and Defender for Cloud — evidence that rules are not just written down but actually followed.
The property boundary
Where the building physically stands — which jurisdiction applies at that location and who may access it from which legal area.
Data Residency
Region binding, EU Data Boundary and Microsoft Cloud for Sovereignty — which jurisdiction the data sits in and who may access it.
Good architecture always begins with structure
Nobody builds a server room by putting servers into an empty space at random. There are plans for cooling, cabling, redundancy and access. Only once that foundation is in place do the servers move in.
Eine Azure landing zone is exactly that foundation, only digital. Before the first production workload it defines how identity, networking, governance, security and compliance fit together. Skip that base and you build technical debt that can only be repaid expensively later.
01 · Identity
Who may do what?
Entra ID, PIM, Conditional Access — the access layer is built cleanly once, not reinvented for each project.
02 · Network
How does the traffic flow?
Hub-and-spoke, private endpoints, firewall policies — the network topology is a load-bearing wall, not a detail.
03 · Governance
What is permitted?
Policies, blueprints, management groups — rules that apply to everyone and are enforced automatically.
Which analogies do you use to make complex cloud concepts tangible?
More from the Klartext series
All issues →RBAC is like a caretaker’s bunch of keys
Why granular roles work the same way in real life as they do in Azure.
◦ In preparationHub-and-spoke is like a company shuttle bus
Understanding network topologies by looking at a works transport system.
◦ In preparationAzure policies are like house rules
Why rules that are enforced automatically make every debate unnecessary.
◦ In preparation