Your Azure subscription has existed for a few years. At some point someone created the first subnet, then a VM for a test system was added, then a storage account for backups, then a second subscription because the tax adviser wanted it. Today nobody quite knows what runs where, what it costs, and why the resource “vm-test-final-2” is in production. We build a Landing Zone from this that matches your company in size — not the Microsoft Enterprise maximum that nobody understands anymore.
Do you have this situation?
- You have two or three Azure subscriptions, and nobody can say off the top of their head which is for what. One was created for the ERP test system, another for “cloud stuff”, the third was inherited from a former service provider.
- The resources are called
vm01,storagealt,rg-neu-final,test-bjoern. Which machine belongs to which project only the person knows who created it back then — and they have been working at a different company for a year. - The Azure bill grows by a few hundred euros monthly without anyone being able to explain why. Cost Management was never set up, there are no budgets, no alerts either.
- When management asks “What does Azure cost us per site?”, someone has to dig through the invoice for three hours — and at the end the answer is still a guess.
- There is no guideline on how a new resource is named, in which resource group it lands, or which tags it needs. Each person does it the way they think right at the moment.
Why solve this now instead of postponing
A disorderly Azure environment costs on three levels: it costs hard money through unused resources, wrongly sized VMs and forgotten test environments that have been running for months. It costs time, because every change triggers research work. And it costs security, because without structure nobody notices when a resource emerges outside of policy.
Typical triggers that are now due:
- Microsoft Enterprise Agreement renewal or reseller change — the new contract partner looks at the subscription structure and asks uncomfortable questions.
- A new workload is supposed to go to Azure — a test environment for the ERP, a second SQL database, a web backend. Without a Landing Zone this becomes the next island.
- Cyber insurer or auditor asks about access structure — who has owner rights on which subscription? If the answer is “I don’t know”, that’s a finding.
- Cost shock in the last quarter — the bill is suddenly 40 percent higher, and no one knows where this came from.
How it would look at your company
Step 1 — Assessment and as-is diagram
We start by reading in: which subscriptions exist, which resource groups, which resources, which identities, which rights. Reader rights are enough for this. At the end of step 1 you have a diagram and a table in which every running resource is mapped to a purpose — or marked as “unknown” if nobody knows what it’s there for anymore. This step alone, in a typical mid-market environment, sorts out 10 to 30 percent of costs, because test machines from 2023 are discovered that nobody needs anymore.
Stack hints: Azure Resource Graph for inventory, Cost Management exports, Entra ID role evaluation.
Step 2 — Subscription and management-group structure
We design a structure with you that fits your company. For an 80-employee company a flat setup with management groups for “Production”, “Test/Development” and possibly “Sandbox” — with two to four subscriptions underneath — is sufficient in most cases. That is deliberately less than what the Microsoft CAF documentation envisages for corporations. Whoever doesn’t have four subsidiaries doesn’t need four subscriptions per workload. Delivery: a structure an external person can understand in 15 minutes.
Stack hints: Management Groups, subscription vending, Entra ID PIM for privileged roles.
Step 3 — Naming and tagging convention
We agree with you on a schema you can remember. Typical example: <workload>-<environment>-<type>-<region>-<no>, that is, erp-prod-vm-weu-01. Plus mandatory tags such as costcenter, owner, workload, environment. Important: the convention is only worth something if it’s enforced via Azure Policy — otherwise in three months resources without tags emerge again. Delivery: a naming and tagging standard, documented on one page, plus policy definitions that prevent or flag faulty creations.
Stack hints: Azure Policy (deny/audit), tag inheritance, initiative definitions.
Step 4 — Infrastructure-as-Code basis
Instead of everyone continuing to click in the portal, we define the important resource types once as code. Bicep for Microsoft-native setups, Terraform if you work with other clouds anyway — both work. Delivery: a small repository with modules for the most common needs (VM, storage account, resource group with standard policies, Key Vault), plus a short instruction on how to trigger a deployment. Deliberately no over-engineering: no 14-stage pipeline with approval gates at four levels, but something an IT generalist can learn in two days.
Stack hints: Bicep or Terraform, GitHub Actions or Azure DevOps Pipelines, service principals with restricted rights.
Step 5 — Cost Management and policy baseline
Budgets per subscription, alerts on threshold breach, monthly cost report to management. Plus a policy baseline: no VMs in regions outside the EU, storage accounts without a public endpoint, diagnostic settings as a duty. Delivery: once a month you get an overview of what Azure cost per workload and per cost centre — and the assurance that nobody accidentally creates a VM in another region.
Stack hints: Azure Cost Management Budgets, Action Groups, Azure Policy Initiatives, Microsoft Defender for Cloud Free Tier.
What you should look out for along the way
- Ask about the deletion plan, not just about the build-up plan. A Landing Zone that throws nothing away is not a Landing Zone — it’s a collection. Whoever doesn’t explain how unused resources are identified and removed is just building a prettier garbage dump.
- CAF is a reference, not a mandatory programme. If someone proposes the full Microsoft Cloud Adoption Framework Enterprise-Scale architecture with five management-group levels for your 60-person company, that isn’t wrong — but it’s overkill. Ask for the mid-market variant.
- Define tagging before naming. Tags are changeable, names aren’t. Whoever starts with naming and pulls tags in later has two conventions that never match.
- Clarify in advance who keeps owner rights. If the service provider is the only owner at the end of the project, you have a concentration risk. The owner role belongs with you, the service provider gets Contributor with a clear scope in regular operation.
- IaC needs a code-review path. If anyone can push directly to
mainand the deployment runs automatically, the second pair of eyes is missing. Even a small company can bring two people together for a pull-request review.
What realistically changes afterwards
- Every resource in Azure has a purpose, a cost centre and a responsible person — lookable in 30 seconds.
- The Azure bill can be broken down per workload, per site and per cost centre, without anyone working in Excel for three hours.
- A new workload no longer lands as an island, but in a defined subscription with standard policies and standard tags.
- Unused test machines from last year are gone, and new ones emerge with an expiry date.
- When an auditor asks “Who has owner rights on the production subscription?”, you can answer in a minute.
What you contribute
- Access to the Azure portal with sufficient rights — reader for the assessment, owner for the implementation in a dedicated phase.
- One person at your company who carries the topic and can stand behind decisions on naming and tagging. That isn’t a technical position — management must be able to name cost centres.
- About 4 to 8 hours of stakeholder time spread across several weeks, plus the operational appointments for the implementation steps. More isn’t needed if the assessment is led by us.
Risks and when it doesn’t fit
- If you are currently in the middle of a migration (e.g. ERP move, Office 365 introduction) — then first finish the migration, then the Landing Zone. Two big rebuilds at the same time raise risk without value.
- If your Azure footprint is very small (one VM, one storage account, full stop) — then a small tidy-up action is enough, not a Landing Zone. We tell you that in the initial conversation.
- If the cloud strategy isn’t politically settled and is still being discussed internally whether Azure or AWS — then first clarify the strategy. It makes no sense to build a Landing Zone that will be migrated again in six months.
How the conversation starts
- 30 minutes initial conversation, free of charge, by video or phone.
- What we clarify: current scope of your Azure footprint, existing subscriptions, most urgent pain (costs, structure, security), time window for an assessment.
- Optionally useful in advance: a list of your active subscriptions, a rough idea of the monthly Azure bill, information on whether IaC is already in use.
Frequently asked questions
Do we really need management groups if we only have two subscriptions? No, not necessarily. With two subscriptions a flat structure with policies directly on subscription level is often enough. Management groups are worthwhile from three to four subscriptions onwards or when policies should be inherited. In the initial conversation we clarify what makes sense for your size.
Bicep or Terraform — what do you recommend? Bicep, if you are exclusively in Azure and work with the Microsoft tool stack. Terraform, if you use multiple clouds anyway or already know the tool. Both work. More important than the choice is that it’s used consistently.
What happens to our existing resources — will they be re-deployed? No, usually not. We bring existing resources into the new schema through renaming, tag back-fill and possibly movement between resource groups. New deployment only where it isn’t technically possible otherwise or where the resource is to be renewed anyway.
How long does it typically take? Assessment and structure design about 2 to 3 weeks, implementation of the naming/tagging policy another 2 to 4 weeks, IaC basis and Cost Management another 2 to 3 weeks. In total around 6 to 10 weeks for a mid-market environment. An honest range comes after the assessment.