An Azure landing zone is the configured environment — subscriptions, management groups, networking, identity, and governance policies — into which workloads are deployed. It is the foundation layer of your Azure estate, and the decisions made when designing it have consequences that persist for years.
From a FinOps perspective, the landing zone is the most important design decision you will make. Everything that comes after — how easily you can attribute costs to teams, whether tagging is consistent, how efficiently commitment discounts are applied, how shared platform costs are handled — is shaped by how the landing zone is structured. Get it right and FinOps has a solid foundation. Get it wrong and the FinOps team spends years working around structural limitations rather than optimising costs.
The key difference from other FinOps decisions: Most FinOps decisions are reversible. You can change a tag, adjust a budget, buy a different reservation. Landing zone structural decisions — subscription design, management group hierarchy, billing account structure — are very difficult and disruptive to change once workloads are running. They deserve proportionately more attention upfront.
What a Landing Zone Contains
Microsoft's Azure Landing Zone (ALZ) reference architecture provides a well-tested pattern. Understanding its components helps clarify which decisions matter most for FinOps:
Component | What it is | FinOps relevance |
|---|---|---|
Management group hierarchy | The organisational structure above subscriptions — Root, Platform, Landing Zones, Sandbox tiers | High — determines policy inheritance, commitment discount scope options, and where governance policies are applied |
Platform subscriptions | Dedicated subscriptions for shared services: Connectivity (hub networking), Management (monitoring, logging), Identity (domain controllers) | High — these are shared costs that all workloads depend on but no single workload owns. Cost allocation strategy needed. |
Workload subscriptions | The subscriptions where application workloads are deployed — Corp (connected to hub) and Online (internet-facing) | High — subscription design is the primary unit of cost attribution and determines how naturally costs map to teams and products |
Sandbox subscriptions | Isolated subscriptions for experimentation, with restricted policy and optional spending limits | Medium — needs spending limits to prevent runaway costs; should be isolated from production cost reporting |
Azure Policy | Governance rules applied across the hierarchy — tag enforcement, allowed SKUs, allowed regions, security baselines | High — the mechanism for enforcing tagging, restricting expensive resource types, and preventing cost surprises at source |
Networking topology | Hub-spoke VNet architecture, ExpressRoute or VPN connections, Azure Firewall, DNS | Medium — hub networking is a significant shared cost (Azure Firewall alone can be £1,000+/month) that needs to be accounted for in cost allocation |
Subscription Design — The Most Important FinOps Decision
Subscriptions are the fundamental billing unit in Azure. Every Azure resource belongs to one subscription, and cost is reported and managed at the subscription level by default. How workloads are distributed across subscriptions directly determines how naturally costs can be attributed to the teams and products responsible for them.
There is no single right answer to subscription design — it depends on your organisation's size, structure, and how you want to attribute cost. But the trade-offs are clear:
Subscription pattern | Description | FinOps implications |
|---|---|---|
One subscription per team or product | Each team or product owns its own subscription(s) | Cleanest cost attribution — costs are naturally segmented by owner. Commitment discount scope needs careful management across many subscriptions. Good for chargeback. |
One subscription per environment | Separate subscriptions for Production, Non-Production, Dev — shared across teams | Easy to isolate production vs non-production costs. Harder to attribute within each environment to specific teams without tagging. Good for budget management by environment. |
One subscription per team per environment | Each team has separate Production and Non-Production subscriptions | Best of both — clean attribution by team and by environment. Can result in many subscriptions to manage. Most mature pattern for organisations doing chargeback. |
Shared subscription (minimal separation) | Most or all workloads in a small number of shared subscriptions | Lowest administrative overhead but hardest FinOps. Cost attribution relies entirely on tagging, which is fragile. Makes commitment discount management and chargeback significantly more complex. |
The tagging burden inversely tracks subscription granularity. The fewer subscriptions you use, the more you rely on tagging to attribute costs — and the harder FinOps becomes when tagging is incomplete. More granular subscription design reduces the tagging burden and makes cost attribution more reliable, at the cost of more subscriptions to manage.
Non-production subscriptions and Dev/Test pricing
Landing zones should designate specific subscriptions for non-production workloads. This matters for FinOps for two reasons. First, it makes it straightforward to separate production spend (what the business depends on) from development spend (what teams are experimenting with) in your cost reporting. Second, subscriptions configured as Dev/Test subscriptions in Azure are eligible for significantly reduced pricing on many services — Windows VMs, SQL Database, and other services covered by the Dev/Test offer. Non-production workloads running in production subscriptions pay full price unnecessarily.
Sandbox subscriptions and spending limits
The ALZ pattern includes sandbox subscriptions for unconstrained experimentation. From a FinOps perspective, sandboxes should always have a spending limit configured so that experimental work cannot generate an unexpectedly large bill. Sandbox spend should be tracked separately from workload spend — it represents investment in learning and exploration rather than operational cost, and it should be reported and budgeted differently.
Management Group Hierarchy and Policy Inheritance
The management group hierarchy sits above subscriptions and is where governance policies are applied at scale. Azure Policy assigned to a management group is automatically inherited by all child management groups and subscriptions within it. This inheritance is the mechanism that makes landing zone governance efficient — you define a policy once at the right level and it applies everywhere below it.
For FinOps, the key policies to apply at management group level are:
Policy type | Purpose | FinOps benefit |
|---|---|---|
Require tag on resources | Deny or audit resource creation if required tags are absent | Ensures cost attribution data exists on every resource from creation — no retroactive tagging effort needed |
Inherit tag from resource group | Automatically apply resource group tags to child resources | Reduces tagging burden on individual resources — tag the resource group, resources inherit it |
Allowed locations | Restrict resource deployment to approved regions | Prevents resources being accidentally deployed in expensive regions or regions outside your commitment discount scope |
Allowed VM SKUs | Restrict which VM sizes can be deployed | Prevents developers spinning up expensive VM families they don't need — a common source of cost surprises in development environments |
Require approved resource types | Limit which Azure services can be deployed | Prevents sprawl into services outside your cost management visibility and commitment discount coverage |
Policy mode matters — Audit vs Deny. A tag policy set to Audit mode will flag non-compliant resources but still allow them to be created. A Deny policy blocks creation entirely. For tagging, Audit mode is common during initial rollout (to avoid blocking teams while compliance is being established), but Deny mode is the right end state. Running permanently in Audit mode means non-compliant resources accumulate and the policy becomes meaningless in practice.
Commitment discount scope and management groups
Azure Savings Plans can be scoped to a management group — the discount applies to all eligible usage across subscriptions within that management group and its children. This is an important capability for organisations that want to pool commitment discounts across a defined set of subscriptions without sharing them across the entire billing account. Your management group design should be considered alongside your commitment discount strategy: a management group boundary that makes organisational sense may also make sense as the boundary for a shared Savings Plan.
Tagging from Day One — The Landing Zone Advantage
The single biggest FinOps advantage of a well-designed landing zone is the ability to enforce tagging from the moment the first resource is deployed. Tagging is the foundation of cost attribution — without it, you cannot reliably allocate costs to teams, products, or cost centres. But tagging is also the most commonly neglected FinOps practice, because it requires consistent discipline across every team deploying every resource.
Azure Policy enforced at management group level removes the dependency on individual discipline. If a resource cannot be created without the required tags, you don't need to rely on teams remembering. The policy does the enforcement.
The minimum viable tag set at landing zone level
Landing zone tag policy should enforce the tags that are essential for cost attribution — the ones without which you cannot answer basic cost management questions. Typically:
Environment — Production, Non-Production, Development, Sandbox. Essential for separating operational from development cost.
Owner — The team or individual accountable for the resource. Essential for cost conversations and anomaly response.
CostCentre — The business unit or cost centre to which the cost is charged. Essential for chargeback.
Application or WorkloadName — The product or service the resource belongs to. Essential for workload-level cost visibility.
Additional tags can be layered on by teams for their own purposes, but these four should be enforced by policy. Any resource without them should either be blocked from creation or flagged immediately for remediation.
The problem with retroactive tagging
Organisations that didn't enforce tagging from the start consistently find themselves in the same position: hundreds or thousands of resources with no or inconsistent tags, teams that have developed deployment habits that don't include tagging, and a FinOps function that cannot attribute a significant proportion of spend. Retroactive tagging at scale is time-consuming, disruptive, and never fully complete — there are always resources that get missed, and the cost history before the tagging effort is permanently unattributable. This is the most compelling argument for getting landing zone tag policy right before the first workload is deployed.
Platform Subscription Costs — The Shared Cost Problem
The ALZ pattern separates shared infrastructure into dedicated platform subscriptions. The Connectivity subscription runs the hub network — Azure Firewall, VPN or ExpressRoute gateways, Azure Bastion, DNS resolvers. The Management subscription runs the monitoring and operations platform — Log Analytics workspaces, Azure Monitor, Azure Automation, Defender for Cloud. The Identity subscription runs domain controllers or other identity infrastructure.
These platform costs are substantial and shared — every connected workload subscription benefits from them, but no single workload owns them. This creates a cost allocation challenge that the landing zone design needs to address explicitly.
Common approaches to platform cost allocation
Approach | Description | Trade-offs |
|---|---|---|
Central overhead | Platform costs are absorbed centrally and not charged to workload teams | Simple. Removes friction with teams. Risk: teams have no visibility into the cost of the shared services they consume, so they don't consider it in their design decisions. |
Equal split | Platform costs divided equally across connected subscriptions | Simple to calculate. Unfair if workloads vary significantly in size — a small workload pays the same as a large one. |
Proportional allocation | Platform costs allocated proportionally to each workload's share of total spend | More equitable. Requires tracking total spend by workload. A larger workload that generates more traffic through the firewall pays more. |
Usage-based | Allocate based on measurable consumption — firewall data processed, Log Analytics ingestion by workspace | Most accurate. Requires instrumentation and tracking of per-workload consumption metrics. Not always feasible for every platform component. |
Decide your approach before the landing zone is live. The methodology doesn't need to be perfect, but it needs to be agreed and documented — teams need to know in advance how platform costs will affect their cost centre allocation.
Azure Firewall — the most commonly underestimated platform cost
Azure Firewall has a fixed deployment cost (charged per hour regardless of traffic) plus a data processing charge for every gigabyte that passes through it. On a busy enterprise network, data processing charges can exceed the base deployment cost significantly. Teams building workloads connected to the hub network often don't realise they're contributing to firewall data processing costs, because those costs appear in the Connectivity subscription rather than their own. Making this visible — either through allocation or through transparency — changes how teams think about their traffic patterns.
Subscription Vending and FinOps Metadata
Mature landing zone implementations use subscription vending — an automated process for provisioning new subscriptions on demand. When a team needs a new subscription, they submit a request through a pipeline or portal, the vending process creates the subscription, places it in the correct management group, applies baseline policies, and hands it over ready to use.
Subscription vending is a significant FinOps opportunity. The request process can capture exactly the metadata you need for cost attribution: cost centre, workload name, owning team, environment type, business unit. This metadata becomes the foundation for cost allocation and is collected at the moment when it's easiest to gather — before any resources exist — rather than retroactively.
If your subscription vending process doesn't collect FinOps metadata, you're missing the most reliable point in the lifecycle to capture it. Once a subscription exists and teams are deploying into it, the window for clean data collection has passed.
Architect's Perspective
Involve FinOps in landing zone design — not just the review
The most common pattern is for a cloud platform or architecture team to design the landing zone and then bring FinOps practitioners in to review it before launch. By the time review happens, the major structural decisions have already been made and changing them is expensive. FinOps requirements — specifically, how costs will be attributed, what the chargeback model is, how shared costs will be split — should be inputs to the subscription design and policy decisions, not a review after the fact.
Design the landing zone for your future state, not your current size
Organisations often design landing zones that are appropriate for their current team structure and workload count but don't scale as the estate grows. A design that works for five teams and twenty subscriptions may create significant pain at fifty teams and two hundred subscriptions. Consider how the subscription hierarchy, naming conventions, and policy structure will work when the estate is three to five times larger, and build for that rather than for today.
Don't treat the ALZ reference architecture as mandatory
Microsoft's Azure Landing Zone reference architecture is a well-tested, opinionated starting point — but it is a starting point. The full ALZ implementation is significant in scope and complexity, and not every organisation needs all of it. A smaller organisation might implement a simplified landing zone with fewer subscriptions and less automation and get 80% of the FinOps benefit at 20% of the complexity. Understand what the ALZ reference solves, take what's relevant to your context, and document your deviations clearly.
Landing zone debt accumulates like technical debt
Organisations that defer landing zone improvements — leaving tagging unenforced, running subscriptions in suboptimal configurations, avoiding the work of splitting a shared subscription — accumulate cost management debt. Each month that passes without good tagging is another month of cost history that cannot be retrospectively attributed. Each month of shared subscriptions is another month of allocation complexity. Unlike technical debt, landing zone debt is often invisible until a FinOps initiative surfaces how much attribution is missing. By then, the remediation cost is high.
How Can Turbo360 Cost Analyzer Help?
Turbo360 Cost Analyzer works with your landing zone structure — whatever state it's currently in — to give you cost visibility and to identify where landing zone improvements would have the highest FinOps impact.
Unified view across all subscriptions
Landing zones span many subscriptions, and cost management tools that operate at a single subscription level give you a fragmented view. Cost Analyzer provides a unified cost view across all your landing zone subscriptions — workload subscriptions, platform subscriptions, sandbox subscriptions — so you can see the full picture of your Azure spend in one place, with the ability to drill into any subscription, resource group, or resource.
Tag coverage analysis
Cost Analyzer shows you the proportion of your total spend that is covered by your cost attribution tags — and more importantly, which subscriptions, resource groups, or resource types have the worst tag coverage. This makes it straightforward to prioritise remediation: fix the highest-spend, lowest-compliance areas first and track coverage improvement over time. If you're implementing or improving landing zone tag policy, Cost Analyzer gives you the before-and-after data to demonstrate the impact.
Platform subscription cost visibility
The shared costs in your platform subscriptions (Connectivity, Management, Identity) are often poorly understood by workload teams. Cost Analyzer can break down platform subscription spend by service and meter — so you can see exactly what Azure Firewall is costing, what the Log Analytics workspace is ingesting from each connected subscription, and which platform components are the largest shared cost items. This data is essential for designing and communicating a fair platform cost allocation methodology.
Multi-tenant and MSP environments
For organisations managing multiple customer landing zones — managed service providers, system integrators, or enterprises with distinct business unit estates — Cost Analyzer's multi-tenant capability provides cost visibility across all of them without requiring consolidation of billing accounts. Each landing zone can be monitored and reported on independently while also being aggregated for portfolio-level reporting.
FAQ
Do we need to implement the full Azure Landing Zone reference architecture to get FinOps benefits?
No. The key FinOps benefits from landing zone thinking come from a small number of structural decisions: getting subscription design right so costs map to ownership naturally, enforcing tagging via Azure Policy, and having a clear approach to shared platform costs. These can be implemented without adopting the full ALZ reference architecture. If you're a smaller organisation or earlier in your cloud journey, a simplified landing zone that gets these three things right will deliver most of the FinOps value at a fraction of the complexity of a full ALZ implementation.
We already have workloads deployed without a landing zone. How do we improve our position?
Start with the highest-impact, lowest-disruption improvements. Enforcing tagging via Azure Policy on existing subscriptions is usually the first step — enable Audit mode to understand the scale of the compliance gap, then progressively move to Deny mode for new resources while remediating existing ones. Subscription restructuring (splitting shared subscriptions, moving to per-team or per-product subscriptions) is higher impact but also more disruptive and should be planned carefully. Use cost data to prioritise: identify which subscriptions and resource groups have the worst attribution clarity and tackle those first.
How should we handle the cost of the platform subscriptions (Connectivity, Management, Identity)?
Decide your approach before workloads start deploying into the landing zone — teams need to know in advance whether platform costs will be charged back to them and on what basis. The most pragmatic starting point for most organisations is proportional allocation: allocate platform costs to workload subscriptions in proportion to their share of total workload spend. This is more equitable than an equal split and simpler than usage-based allocation. Document the methodology, communicate it to workload owners, and review it annually as the estate grows.
What's the right number of subscriptions for our landing zone?
There is no right number — it depends on how many teams you have, how you want to attribute cost, and whether you're doing showback or full chargeback. The useful principle is: subscriptions are cheaper than the cost management complexity they prevent. Azure's subscription limits are high enough that most organisations will never hit them through deliberate workload separation. If you're debating whether a workload deserves its own subscription, the FinOps answer is almost always yes — the cost attribution clarity is worth the management overhead.
Can we change our subscription design after workloads are running?
Some changes are possible but most are disruptive. Moving a resource group between subscriptions requires recreating the resources in the new subscription — it is not a live migration for most resource types. Reorganising management group membership is easier as it doesn't affect resources directly, but it changes the policies that apply to those subscriptions and needs careful validation. Changing billing account structure is the most disruptive and requires working with Microsoft directly. The best time to get subscription design right is before workloads are deployed; the second-best time is as soon as you recognise the current design is causing problems, before the estate grows further.
Useful Resources
Related playbook pages
Microsoft resources