The Idle Cost of an Azure Landing Zone: Governance First, Connectivity Later
A landing zone that starts with its network hub switched on bills by the hour from the day it is deployed, whether or not any workload is running. Here is which components cost money while idle, which governance controls carry no Azure charge, and how to sequence the two for an early-stage team.
What bills while idle
Microsoft's Cloud Adoption Framework (CAF) landing zone reference implementations include an optional connectivity layer built for enterprise estates. When that layer is enabled at the start, it typically deploys resources that are billed per hour of deployment, not per unit of use:
- Azure Firewall (Standard or Premium). A fixed hourly deployment charge, plus a separate charge per gigabyte processed.
- Azure Bastion. Billed hourly for as long as the host exists, whether or not anyone connects to a VM.
- VPN or ExpressRoute gateways, and DDoS Network Protection. Also billed while deployed, independent of traffic.
- Log Analytics. Billed mainly by data ingested. Low on its own, but diagnostic settings sent from every resource can add up, and commitment tiers carry a daily minimum.
For an enterprise with traffic to inspect and on-premises networks to connect, these costs buy something. For a team with no production workload yet, they pay for capacity that sits unused. Check the Azure pricing calculator for your region and SKUs before you switch the connectivity layer on.
| Approach | Azure billing while idle | What is deployed |
|---|---|---|
| Connectivity-first landing zone | Billed hourly from deployment | Firewall, Bastion and gateways, billed whether or not any traffic flows through them. |
| Governance-first foundation | $0/mo | Control plane only: management groups, subscription vending, group-based RBAC and tagging policy, none of which Microsoft bills for. |
Governance controls that carry no Azure charge
Azure does not charge for the Azure Resource Manager control plane. The following can all be in place before any workload exists:
- A management group hierarchy, for example Root, then Platform, Landing Zones and Sandbox beneath it.
- Subscription vending, with each new subscription inheriting policy from its management group.
- Role assignments to Entra ID security groups instead of standing Owner rights for individuals.
- Azure Policy assignments for Azure resources, Cost Management budgets and required tags.
These carry no Azure runtime charge. Spend starts when you deploy workload compute, container clusters, databases, or the connectivity resources listed above.
Sequencing: governance now, connectivity when traffic needs it
The practical order for an early-stage team is to set up governance first, so developers work in isolated, tagged, budgeted subscriptions, and to add the network hub when there is a concrete reason: central egress inspection, connectivity to on-premises networks, or a compliance requirement that calls for it.
The VitCamp Cloud Governance Foundation follows this order. It includes:
- Policy-governed subscription vending. New subscriptions (Dev, Staging, Sandbox) are created from a pull request with budgets and policy guardrails attached.
- No standing Owners. Role assignments go to groups such as Platform Ops, Network Readers and Workload Developers.
- Documentation in your repository. An Architecture Design Document (ADD), high-level diagrams and Day-2 operational runbooks sit alongside the code.
The Platform Transit Hub (Tier 3) is designed to attach to the same management group hierarchy later, adding the hub network, firewall and connectivity when your workloads need them. Unlike the foundation, the hub carries an Azure idle cost of about $1,400–1,800 per month for the firewall, Bastion and Log Analytics.