I simply do not understand Azure landing zones.
A sentence I hear often in client conversations
And frankly, I can see why. Cloud architecture sounds abstract — but what if we thought of it as a classic server room?
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
Eight concepts,
eight translations
Every layer of the Azure landing zone has its direct counterpart in the server room. Once you have absorbed these eight 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.
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 preparation Issue #03Hub-and-spoke is like a company shuttle bus
Understanding network topologies by looking at a works transport system.
◦ In preparation Issue #04Azure policies are like house rules
Why rules that are enforced automatically make every debate unnecessary.
◦ In preparation