Cost Management

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production.

See the section bibliography for the reference material consulted while preparing these pages.

Commands below target Azure CLI 2.90.0 (checked 2026-09-27). The consumption command group (az consumption budget …) ships in CLI core but is still marked preview; the costmanagement and reservations command groups are separate CLI extensions, also preview, that install automatically the first time you run one of their commands. Re-verify flag names with --help before relying on them, since preview command groups change faster than generally available ones.

Every other page in this section describes a service; this one describes what that service costs to run and how to keep it under control once it is running. It covers what actually drives an Azure bill, the tools for estimating cost before you deploy anything, Cost Management’s analysis/budgets/alerts/exports, tags as the mechanism behind chargeback, the three ways to pay less for steady-state compute (reservations, savings plans, spot), dev/test pricing, auto-shutdown and scale-to-zero as architectural cost levers, Advisor’s cost recommendations, and a checklist of the cost-saving levers worth knowing before you design anything. It closes with a qualitative look at where the Bookshelf scenario’s own money goes.

What drives an Azure bill

Every resource on this site’s pages bills along some combination of the same handful of dimensions:

Dimension Where it shows up

Compute time and size

VM/node/replica size multiplied by how long it runs — Choosing a Compute Service, AKS Clusters, Container Apps.

Licensing

Windows/SQL Server guest licensing folded into the meter, unless Azure Hybrid Benefit applies an existing on-premises license instead.

Storage capacity and redundancy

Bytes stored times the chosen redundancy tier (more copies, more cost) — see the redundancy comparison on Storage Accounts.

Storage operations

Per-transaction charges on Blob/Table/Queue/Files that scale with request volume, not just bytes stored.

Database compute/throughput units

vCore/DTU hours (Azure SQL, PostgreSQL and MySQL on Azure) or request units (Cosmos DB and Azure DocumentDB), independent of storage.

Data egress and inter-region traffic

Outbound bytes to the internet, and increasingly, cross-region and cross-availability-zone traffic within Azure itself — see Virtual Networks and Front Door and CDN.

Fixed-cost gateways

Application Gateway, Azure Firewall, VPN Gateway and Bastion bill an hourly base rate whether or not traffic flows through them — Gateways and Load Balancing, VPN Gateway and Hybrid Connectivity.

PaaS consumption units

Container Apps vCPU-seconds/GiB-seconds, Functions executions/GB-seconds, API Management calls — see the pricing sections on each service’s own page.

Support plans and Marketplace items

A subscription-level support plan tier, plus any billed third-party Marketplace offer (Redis and Partner Databases on Azure).

No dimension here has a fixed price on this page — prices change often enough that a hard-coded number would be stale before this page is re-read. Every pricing claim below links to the dated official page instead.

Estimating cost before you deploy

The pricing calculator

Azure’s pricing calculator builds a line-item estimate: add each service you plan to use, its region, tier and expected consumption (VM size and hours, storage GB, RU/s, and so on), and it totals a monthly estimate you can save and share as a link. It has no idea what your actual traffic or data volume will be, so its accuracy is only as good as the assumptions you feed it — treat it as a back-of-envelope figure to sanity-check a design, not a forecast to budget against once something is live.

The Azure Migrate business case

For an existing on-premises (or already-cloud) estate being evaluated for migration, Azure Migrate’s business case feature goes further than the calculator: it starts from Azure Migrate’s own discovery data (actual server inventory and utilization, collected over at least a day so the recommendation reflects real load rather than provisioned size) and produces a multi-year total-cost-of-ownership comparison between the current on-premises cost and the projected Azure cost for a chosen migration strategy. A business case is built against one of three migration preferences — Modernize (PaaS-first, falling back to IaaS where a workload cannot be modernized), Migrate (lift-and-shift to Azure VMs or Azure VMware Solution), or a preference pinned to one target — and one or more savings options (pay-as-you-go, reserved instances, or reserved instances plus a savings plan). The output covers year-over-year cash flow, Azure Hybrid Benefit and Extended Security Update savings where they apply, and a sustainability estimate (projected emissions on-premises versus on Azure), which makes it the tool of choice for justifying a migration to stakeholders who need more than a per-service estimate.

Reference: Microsoft Learn — Build a business case with Azure Migrate

Cost Management: analysis, budgets and alerts

Cost Management + Billing is the free, built-in service every subscription already has; nothing below requires provisioning anything.

Cost analysis

Cost analysis breaks down actual and forecasted spend by subscription, resource group, resource, meter, or tag, over any date range, as a running chart or a table you can export. It is the first place to look when a bill is higher than expected, and its Smart views also surface anomaly insights (see below) without any alert rule having to be configured first.

Budgets

A budget is a scoped spending threshold (subscription, resource group, or a filtered subset of either) that triggers notifications once actual or forecasted cost crosses one or more percentage thresholds of the budgeted amount — it never blocks spend by itself, only notifies.

In the Azure portal

  1. Open Cost Management from Azure Home, select the subscription scope, then Budgets.

  2. Select + Add, choose Cost as the category, a name, an amount, and a time grain (monthly, quarterly or annually), then optionally narrow the scope with a resource group or tag filter.

  3. Add one or more alert thresholds (a percentage of the budgeted amount) and the email recipients or an action group to notify at each one, then select Create.

With the Azure CLI

RG="rg-bookshelf"

az consumption budget create \
  --budget-name "bookshelf-monthly" \
  --category cost \
  --amount 500 \
  --time-grain monthly \
  --start-date "2026-10-01" \
  --end-date "2027-09-30" \
  --resource-group-filter "$RG"

The base az consumption budget create command shown above has no --notifications flag; to attach notification thresholds and recipients from the CLI in one call, use az consumption budget create-with-rg instead, which accepts a --notifications map (up to five per budget) of threshold/operator/contact-email/contact-group entries — the shape mirrors the JSON notifications object in the REST API, so it is often simplest to keep the definition in a file and pass it with --notifications @notifications.json.

Reference: Microsoft Learn — az consumption budget, Create and manage budgets

Anomaly alerts

Separately from budgets, Cost Analysis runs a daily anomaly-detection model per subscription (a univariate time-series forecast trained on the last 60 days of usage, evaluated about 36 hours after each day closes to work from complete data) and flags a day’s total spend as anomalous when it falls outside the forecasted range. An anomaly alert rule, created once per subscription from Cost Management > Cost alerts > Alert rules, emails a one-time summary — the resource groups that changed most and by how much — the first time an anomaly is detected; there is a limit of five anomaly alert rules per subscription. There is no dedicated CLI command for this rule type: automating its creation means calling the Scheduled Actions REST API directly with the scheduled-action kind set to InsightAlert, for example through az rest.

Reference: Microsoft Learn — Identify anomalies and unexpected changes in cost

Exports

An export is a recurring (or one-off) dump of cost/usage data as CSV to a storage account, which is what feeds a FinOps data warehouse, a Power BI report, or any per-team chargeback pipeline that budgets and Cost Analysis alone cannot cover.

In the Azure portal

  1. Open Cost Management, select the scope, then Exports.

  2. Select + Create, name the export, choose the dataset type (cost, usage, or amortized cost — amortized cost spreads a reservation’s up-front cost across the days it covers, so a chargeback pipeline should read from it rather than actual cost if reservations are in use), the recurrence, and the destination storage account and container, then select Create.

With the Azure CLI

STORAGE_ID=$(az storage account show --name "stbookshelf" --resource-group "$RG" --query id -o tsv)

az costmanagement export create \
  --name "bookshelf-monthly-export" \
  --scope "subscriptions/<subscription-id>" \
  --type ActualCost \
  --timeframe MonthToDate \
  --recurrence Monthly \
  --recurrence-period from="2026-10-01T00:00:00Z" to="2027-10-01T00:00:00Z" \
  --schedule-status Active \
  --storage-account-id "$STORAGE_ID" \
  --storage-container "cost-exports" \
  --storage-directory "bookshelf"

Reference: Microsoft Learn — az costmanagement export

Tags for chargeback

Chargeback and showback both start from the same tags described on resource organization’s tags section (not repeated here): without a consistent cost-center/owner/environment tagging scheme applied at creation time — ideally enforced with an Azure Policy that denies untagged resources or inherits tags from the resource group — Cost Analysis and exports can group spend by resource group and meter, but not reliably by team or project. Because tags are not automatically inherited from a resource group by the resources inside it, a chargeback report that groups by tag will silently under-count anything created without the tag actually set on the resource itself.

Reservations, savings plans and spot pricing

Three different mechanisms trade a commitment (of capacity, of spend, or of interruptibility) for a discount off pay-as-you-go pricing, and they are not mutually exclusive — a mature estate typically layers all three.

Reservations

A one- or three-year commitment to a specific SKU/size in a specific region (or region group), paid up front or monthly. It gives the deepest discount of the three for a workload whose shape will not change, because the discount is tied to that exact SKU rather than to spend.

Savings plans

A one- or three-year commitment to a fixed hourly spend rather than a specific SKU. Azure applies the discount automatically to whatever eligible compute usage matches that spend, so a savings plan keeps discounting a workload through a VM-family change, a region move, or a shift between eligible compute services, at a slightly shallower discount than an equivalent-term reservation.

Spot

No commitment at all — a bid for unused Azure capacity at a steep discount, with the trade-off that Azure can evict the instance (or container, or node) with short notice when capacity is needed elsewhere. Spot only suits workloads that tolerate interruption: batch jobs, CI runners, stateless horizontally-scaled tiers, or AKS node pools reserved for such workloads.

flowchart TD Start["Steady-state or bursty workload?"] Interrupt{"Can it tolerate\nsudden eviction?"} ShapeFixed{"Will the exact SKU/region\nstay the same for 1-3 years?"} Start -- "Interruptible, stateless,\nbatch/CI/scale-out tier" --> Interrupt Interrupt -- Yes --> Spot["Spot pricing"] Interrupt -- No --> ShapeFixed ShapeFixed -- "Yes, fixed SKU/region" --> Reservation["Reservation"] ShapeFixed -- "No, spend is\nstable but shape varies" --> SavingsPlan["Savings plan"]

Both reservations and savings plans are still bought mainly through the portal (Cost Management + Billing > Reservations / Savings plans, or Advisor’s own purchase recommendations below) or via Bicep/ARM templates targeting Microsoft.Capacity; the CLI’s reservations extension (preview) covers listing, exchanging and merging existing reservations (az reservations list, az reservations reservation-order calculate) rather than a simple one-line purchase command, so most teams still purchase through the portal even in an otherwise CLI-first workflow.

Reservations and savings plans apply automatically to any eligible usage in their scope (shared across the billing scope by default, or pinned to a single subscription/resource group); nothing in the workload itself has to change to benefit once one is purchased.

Reference: Save costs with Azure reservations, Savings plan for compute, Use Azure Spot Virtual Machines, Microsoft Learn — az reservations

Dev/test pricing

Non-production environments get two separate discount paths, and it is easy to conflate them:

Azure Dev/Test pricing (pay-as-you-go)

A subscription offer (no Enterprise Agreement or Visual Studio subscription required) that removes Microsoft software licensing costs from several services' meters for resources used for development and testing — there is no SLA on a Dev/Test subscription, so it is never a substitute for a staging environment that needs production-grade availability guarantees.

Enterprise Dev/Test

The Enterprise Agreement equivalent: an EA administrator enables it for specific Visual Studio subscribers, who then get Windows/SQL Server guest licensing billed at the Linux-equivalent rate on VMs, plus discounted Cloud Services, App Service, Logic Apps and HDInsight — again, dev/test workloads only, and reservations/savings plans still apply on top for further savings on the compute itself.

Neither offer discounts storage, networking, or most PaaS consumption units — only the licensing component of compute — so pairing a dev/test subscription with auto-shutdown (below) is what actually keeps a non-production environment’s bill low.

Reference: Azure — Enterprise Dev/Test pricing, Azure — Dev/test pricing overview

Auto-shutdown and scale-to-zero

Two different levers for the same goal — not paying for compute that is not doing anything — apply to different kinds of resources.

Auto-shutdown is a VM-level schedule (backed by a Microsoft.DevTestLab/schedules resource, configured from the portal’s Auto-shutdown blade on any VM, DevTest Labs or not) that shuts the guest OS down on a recurring time; Choosing a Compute Service covers the CLI-side caveat that there is no dedicated az vm auto-shutdown command, and that az vm deallocate (which actually releases the compute allocation, unlike an in-guest shutdown) is the CLI-only equivalent for a one-off stop. Auto-shutdown only helps VMs and VM Scale Sets — it has no equivalent for a managed database or a PaaS service, because those bill on their own consumption model.

Scale-to-zero is the PaaS/container-native equivalent: instead of a schedule, the service itself removes the last replica when there is no traffic and adds one back on the next request (accepting a cold-start latency trade-off). This section already covers each instance where it applies — linked here rather than repeated:

Reference: Auto-shutdown a VM

Advisor cost recommendations

Azure Advisor continuously evaluates a subscription’s resources against Microsoft’s own best practices and surfaces recommendations across five categories, one of which is Cost. Typical cost recommendations include underutilized VMs/App Service plans that should be resized or shut down, orphaned resources (unattached managed disks, idle public IPs), and — most valuably for the reservations/savings-plan decision above — a usage-informed "buy a reservation" or "buy a savings plan" recommendation, sized from actual historical consumption rather than a guess.

In the Azure portal

  1. Open Advisor, select the Cost tab, and review each recommendation’s estimated monthly saving.

  2. Select a recommendation to see the affected resource(s) and, for reservation/savings-plan recommendations, a direct link into the purchase flow pre-filled with the recommended term and scope.

With the Azure CLI

az advisor recommendation list --category Cost --output table

Reference: Cost recommendations - Azure Advisor, Microsoft Learn — az advisor recommendation

Cost-saving levers, organized by where they apply

Pulling the mechanisms above together into one checklist, grouped by what part of the estate each lever acts on rather than by tool:

Commitment discounts

Reservations and savings plans for anything running close to 24/7 (see the decision flow above); spot for anything interruptible.

Idle and orphaned resource cleanup

Deallocated-but-not-deleted VMs, unattached managed disks and public IPs, forgotten dev/test resource groups — the everyday target of Advisor’s cost recommendations above.

Elastic and scale-to-zero architecture

Choosing a compute/database tier that scales down to (near) zero between requests instead of one that is always-on, covered per service above.

Non-production schedules

Auto-shutdown outside working hours plus dev/test pricing, applied together rather than either alone.

Storage tiering and lifecycle

Moving cold Blob data to Cool/Archive automatically instead of leaving everything on Hot, per the lifecycle-management policies on Blob Storage.

Right region and redundancy

Choosing the cheapest redundancy tier that still meets the durability requirement (LRS instead of GZRS where cross-region failover genuinely is not needed) and a region close to users to limit egress and latency, per Storage Accounts and Azure Global Infrastructure.

Networking egress awareness

Keeping chatty inter-tier traffic inside a region/availability zone, and serving static content through Front Door/CDN caching instead of re-serving it from origin (Front Door and CDN).

Governance guardrails

Budgets, anomaly alerts, mandatory chargeback tags and an Azure Policy that blocks untagged or oversized resources before they are ever created, closing the loop on all of the above.

Bookshelf: a qualitative cost-driver breakdown

Bookshelf deliberately mixes compute models (Container Apps and AKS), several managed databases, and both an edge and a VPN network path, so its own bill is a reasonable stand-in for what a small multi-service estate actually spends money on. In relative terms, from largest to smallest driver, and without inventing a real dollar figure for any of them:

Always-on compute (aks-bookshelf, cae-bookshelf)

The AKS node pool is provisioned capacity billed whether or not it is busy, so it is typically the single largest line item unless the cluster is sized very small; `cae-bookshelf’s Container Apps are comparatively cheaper at low traffic because Consumption-plan replicas can scale toward zero, but a workload profile-based environment (used for anything needing more headroom) reverts to the same always-on economics as the AKS node pool.

Managed databases (pg-bookshelf, docdb-bookshelf, redis-bookshelf)

Each bills its own provisioned compute/throughput continuously regardless of query volume, making the three together a large and fairly fixed chunk of spend; of the three, redis-bookshelf (an in-memory cache tier) is usually the smallest if sized only for the catalog’s hot-path lookups, while the flexible-server PostgreSQL and DocumentDB instances scale with their compute tier choice more than with data volume at Bookshelf’s size.

Fixed-cost networking (vgw-bookshelf, afd-bookshelf)

The VPN gateway bills an hourly base rate purely for existing, independent of whether the admin path over it (VPN Gateway and Hybrid Connectivity) is ever used that day; Front Door’s base profile cost is smaller, with its variable component driven by request volume and cache miss rate against stbookshelf’s static site and `catalog-api.

API Management (apim-bookshelf)

A meaningful fixed cost at any tier above Consumption, and the tier choice (driven by whether Bookshelf needs the full policy/gateway feature set versus APIM’s scale-to-zero Consumption tier) matters more to this line item than request volume does.

Storage, secrets and configuration (stbookshelf, kv-bookshelf, appcs-bookshelf)

Blob capacity plus transaction volume for `stbookshelf’s static assets and object storage is small relative to the compute and database tiers above, and Key Vault/App Configuration’s operation-based pricing keeps both close to negligible at Bookshelf’s scale; they only become material at a request volume far higher than this scenario’s.

Email (acs-bookshelf)

Priced per email/SMS sent by the notifier job, this is the most directly usage-proportional line item in the whole scenario — it tracks order volume almost exactly, unlike the provisioned-capacity items above it.

The pattern that generalizes beyond Bookshelf: provisioned, always-on compute and database tiers dominate a small estate’s bill far more than per-request PaaS services do, which is exactly why the reservations/savings-plan decision and right-sizing matter more, dollar for dollar, than tuning per-call pricing on the services billed by consumption.

Clean up

This page creates no durable resource of its own beyond the example budget and export shown above, and neither carries an ongoing charge — Cost Management + Billing itself is free. If you created the example budget while following along, remove it the same way any other example resource in this section is removed:

az consumption budget delete --budget-name "bookshelf-monthly"

az costmanagement export delete --name "bookshelf-monthly-export" --scope "subscriptions/<subscription-id>"

References