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.
Does this sound familiar?
- You have two or three Azure subscriptions, and nobody can say off the top of their head which one 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. The only person who knows which machine belongs to which project is whoever created it back then — and they left for another company a year ago. - The Azure bill grows by a few hundred euros every month, and nobody can 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 the answer is still a guess.
- There is no rule for how a new resource is named, which resource group it lands in, or which tags it needs. Everyone does it however seems right at the time.
Why now — and not later
An unmanaged Azure environment costs you on three levels. It costs hard cash through unused resources, oversized VMs and forgotten test environments that have been running for months. It costs time, because every change starts with detective work. And it costs security, because without structure nobody notices when a resource is created outside policy.
Typical triggers that put this on the agenda:
- Microsoft Enterprise Agreement renewal or reseller change — the new contract partner looks at the subscription structure and asks uncomfortable questions.
- A new workload is headed for Azure — a test environment for the ERP, a second SQL database, a web backend. Without a Landing Zone it becomes the next island.
- A cyber insurer or auditor asks about your 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 nobody can say where it came from.
What this would look like at your company
Step 1 — Assessment and as-is diagram
We start by building a complete picture: which subscriptions exist, which resource groups, which resources, which identities, which permissions. Reader access is all we need for that. 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 remembers what it’s there for. This step alone often uncovers noticeable savings potential — test machines from 2023 that nobody needs anymore, for example.
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 enough in most cases. That is deliberately less than what the Microsoft CAF documentation envisages for large corporations. If you don’t have four subsidiaries, you don’t need four subscriptions per workload. Deliverable: a structure an outsider 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 people can actually remember. Typical example: <workload>-<environment>-<type>-<region>-<no>, i.e. 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 untagged resources will be back within three months. Deliverable: a naming and tagging standard documented on a single page, plus policy definitions that block or flag non-compliant resources at creation.
Stack hints: Azure Policy (deny/audit), tag inheritance, initiative definitions.
Step 4 — Infrastructure-as-Code foundation
Instead of everyone continuing to click around the portal, we define the important resource types as code, once. Bicep for Microsoft-native setups, Terraform if you work with other clouds anyway — both work. Deliverable: a small repository with modules for the most common needs (VM, storage account, resource group with standard policies, Key Vault), plus a short guide on how to trigger a deployment. Deliberately no over-engineering: no 14-stage pipeline with approval gates on 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 when thresholds are breached, a monthly cost report to management. Plus a policy baseline: no VMs in regions outside the EU, no storage accounts with a public endpoint, mandatory diagnostic settings. Deliverable: 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 the wrong region.
Stack hints: Azure Cost Management Budgets, Action Groups, Azure Policy Initiatives, Microsoft Defender for Cloud Free Tier.
What to watch out for
- Ask about the deletion plan, not just the build plan. A Landing Zone that never throws anything away is not a Landing Zone — it’s a collection. Anyone who can’t explain how unused resources get 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 can be changed, names can’t. Start with naming and pull tags in later, and you end up with two conventions that never line up.
- Clarify up front 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; in regular operation the service provider gets Contributor with a clear scope.
- IaC needs a code-review path. If anyone can push straight to
mainand the deployment runs automatically, there is no second pair of eyes. 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 — and you can look it up in 30 seconds.
- The Azure bill can be broken down per workload, per site and per cost centre, without anyone spending three hours in Excel.
- 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 are created with an expiry date.
- When an auditor asks “Who has owner rights on the production subscription?”, you can answer within 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 owns the topic internally and can back the decisions on naming and tagging. That isn’t a technical role — but management must be able to name cost centres.
- About 4 to 8 hours of stakeholder time spread across several weeks, plus the working sessions for the implementation steps. That’s all it takes if we lead the assessment.
Risks and when it doesn’t fit
- If you are currently in the middle of a migration (an ERP move, an Office 365 rollout) — finish the migration first, then build the Landing Zone. Two big rebuilds at the same time raise the risk without adding value.
- If your Azure footprint is very small (one VM, one storage account, and that’s it) — then a small clean-up is enough, not a Landing Zone. We’ll tell you that in the initial conversation.
- If the cloud strategy hasn’t been settled yet and the Azure-versus-AWS question is still being debated internally — clarify the strategy first. It makes no sense to build a Landing Zone that gets migrated again in six months.
How the conversation starts
- A free 30-minute initial conversation, by video or phone.
- What we clarify: the current scope of your Azure footprint, existing subscriptions, your most urgent pain point (costs, structure, security), and a time window for an assessment.
- Optionally useful in advance: a list of your active subscriptions, a rough idea of the monthly Azure bill, and 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 applied directly at subscription level is often enough. Management groups start paying off from three to four subscriptions, or when policies should be inherited. In the initial conversation we clarify what makes sense at your size.
Bicep or Terraform — what do you recommend? Bicep if you work exclusively in Azure and 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 using it consistently.
What happens to our existing resources — will they be re-deployed? No, usually not. We bring existing resources into the new schema by back-filling tags and, where needed, moving them between resource groups. Since most Azure resources can’t be renamed, the naming convention applies to newly created resources — the existing estate is mapped via tags. Re-deployment only where there is no technical alternative, or where the resource is due for renewal anyway.
How long does it typically take? Assessment and structure design take about 2 to 3 weeks, implementing the naming/tagging policy another 2 to 4 weeks, the IaC foundation and Cost Management another 2 to 3 weeks. In total, around 6 to 10 weeks for a mid-market environment. We’ll give you an honest range after the assessment.