How Azure Billing Works: Costs, Budgets, and Cost Management

The billing hierarchy

Azure billing is organized in a hierarchy that maps to how most organizations structure their finances:

• Billing account — the top-level entity associated with your contract with Microsoft (PAYG credit card, MCA, or EA enrollment). All charges ultimately roll up here.
• Billing profile — a subset of a billing account (used in MCA). Has its own invoice and payment method. Useful for separate departments or cost centers.
• Invoice section — a further subdivision within a billing profile. Used to separate costs for different teams or projects on the same invoice.
• Subscription — the resource container you’re already familiar with. Charges for Azure resources in a subscription roll up to the invoice section or billing profile above it.

For Pay-As-You-Go customers, the structure is simpler: one billing account → one or more subscriptions → one monthly invoice per subscription.

Understanding which subscription costs go to which invoice section matters most for large organizations doing internal chargebacks. For individuals and small teams, the subscription is the practical unit of billing.

How Azure services are priced

Different Azure services use different billing models. Knowing the model for each service you use helps you predict costs and avoid surprises.

The pricing table above is for rough orientation — actual prices vary by region, tier, commitment, and promotions. Always use the Azure Pricing Calculator (calculator.azure.com) for real estimates before committing to an architecture.

The egress trap

Data coming into Azure (ingress) is free. Data leaving Azure (egress) to the internet is charged. This catches beginners who design architectures that move large amounts of data out of Azure regularly — for example, serving large files directly from Blob Storage to users rather than through a CDN. Cross-region data transfer within Azure also incurs fees, though at a lower rate than egress to the internet.

Pay-as-you-go vs reserved instances vs Savings Plans

Azure gives you three ways to pay for compute resources, with different trade-offs between flexibility and cost.

Pay-As-You-Go (PAYG)

Full price, no commitment, maximum flexibility. The right choice for variable or unpredictable workloads, development environments, and workloads you’re not sure you’ll keep. A VM that runs 24/7 at PAYG pricing will cost significantly more annually than the same VM on a reservation.

Reserved Instances

You commit to a specific VM size and region for 1 or 3 years, paid upfront or monthly, in exchange for up to 72% discount. Reserved Instances apply as a billing benefit — you keep running PAYG VMs, and Azure automatically applies the reservation discount to matching usage. You don’t have to change anything about how VMs are deployed.

Reserved Instances make sense for VMs that run continuously (production database servers, always-on application servers). They don’t help for dev environments that run 8 hours a day.

Azure Savings Plans

Savings Plans are more flexible than Reserved Instances. Instead of committing to a specific VM size, you commit to an hourly spend amount (e.g. $10/hour of compute) across any eligible service and region. You get a discount (up to 65%) on compute usage up to your committed amount. Usage above the commitment falls back to PAYG pricing.

Savings Plans work well when you know your compute spend will be stable but want flexibility to change VM sizes, regions, or services without losing the discount.

Azure Cost Management

Azure Cost Management is the tool for analyzing and controlling your Azure spend. You access it from the Azure portal by searching for “Cost Management” or by navigating through your subscription’s menu.

Cost analysis

Cost analysis shows your historical spend broken down by service, resource group, location, tag, or any combination. You can switch between daily, monthly, and custom date ranges, and export the data to CSV for reporting.

Budgets

A budget is a spending threshold you set on a subscription, resource group, or management group. When your spend reaches a percentage of the budget, Azure sends an alert to specified email addresses or triggers an action group.

# Create a monthly budget of $500 on a subscription with alerts at 80% and 100%
az consumption budget create \
  --budget-name "monthly-subscription-budget" \
  --amount 500 \
  --time-grain Monthly \
  --start-date "2026-04-01" \
  --end-date "2027-03-31" \
  --resource-group "" \
  --notifications '[
    {
      "enabled": true,
      "operator": "GreaterThan",
      "threshold": 80,
      "contactEmails": ["ops-team@acme.com"],
      "contactRoles": ["Owner", "Contributor"]
    },
    {
      "enabled": true,
      "operator": "GreaterThan",
      "threshold": 100,
      "contactEmails": ["ops-team@acme.com", "manager@acme.com"],
      "contactRoles": ["Owner"]
    }
  ]'

Cost recommendations

The “Advisor Recommendations” section of Cost Management suggests ways to reduce spend — for example, identifying underutilized VMs that could be downsized, or unused resources that are still incurring charges (a stopped-but-not-deallocated VM still charges for storage; a public IP address without an attached resource still charges a small fee).

Checking your spend with the Azure CLI

# Show cost summary for the current subscription in the current billing period
az consumption usage list \
  --billing-period-name "202603" \
  --output table

# Show costs by resource group for the last 30 days
az costmanagement query \
  --type Usage \
  --timeframe MonthToDate \
  --scope "/subscriptions/{sub-id}" \
  --dataset-aggregation '{"totalCost": {"name": "PreTaxCost", "function": "Sum"}}' \
  --dataset-grouping '[{"type": "Dimension", "name": "ResourceGroupName"}]'

# List all resource groups and their approximate cost for the current month
az consumption usage list \
  --query "[].{ResourceGroup:instanceName,Cost:pretaxCost,Currency:currency}" \
  --output table

The Azure CLI’s cost commands give you a quick snapshot without opening the portal. This is useful for automated cost reporting scripts or pre-deploy sanity checks in CI/CD pipelines.

Common sources of unexpected charges

These are the scenarios that generate surprise charges for beginners most often:

Stopped VMs that are still allocated

In Azure, “stopping” a VM from inside the OS (the equivalent of pressing the power button) does NOT stop charges. The VM is still allocated — Azure is still holding the hardware for it. You must deallocate the VM through the portal or CLI to stop compute charges. Deallocated VMs still incur small storage charges for their OS disk, but no compute charge.

# Deallocate a VM (stops compute charges)
az vm deallocate --resource-group rg-dev --name dev-vm-01

# Start it again later
az vm start --resource-group rg-dev --name dev-vm-01

Orphaned resources

When you delete a VM in the portal, the VM itself is deleted, but associated resources — managed disk, network interface, public IP address — may not be. Each of those orphaned resources has its own ongoing cost. Always check for orphaned resources after deleting VMs.

Dev/test environments left running overnight

A Standard_D8s_v5 VM running 24/7 costs roughly $280/month. Running it during business hours only (8 hours × 22 days) costs about $80/month. Automation to shut down dev environments at night pays for itself quickly. Azure VM Auto-Shutdown is a free feature available on any VM — configure it in the portal.

Data transfer between regions

If your application architecture has components in different Azure regions calling each other (e.g., a web server in East US calling a database in West Europe), each call incurs cross-region bandwidth charges. Design for resource colocation within a region when possible.