FinOps in Azure: Cloud Cost Management

FinOps principles

The FinOps Foundation defines six core principles that distinguish mature cloud financial management from ad-hoc cost-cutting:

1. Teams need to collaborate. Finance, engineering, and product must work together. Finance understands budget cycles; engineering understands what each resource does; product understands the business value delivered. No single team has the full picture.
2. Everyone takes ownership of their cloud usage. Central IT cannot control costs for a hundred engineering teams. Each team must understand and own the cost of the resources it creates.
3. A centralised team drives FinOps. A dedicated FinOps practitioner or team sets standards, builds tooling, educates engineers, and drives the optimisation backlog. Without centralised coordination, FinOps remains a collection of ad-hoc actions.
4. FinOps reports should be accessible and timely. Cost data that arrives three weeks after it is incurred is too late to act on. Real-time or next-day cost data allows teams to catch problems immediately.
5. Decisions are driven by business value. The question is never “is this cheap?” but “does the value this delivers justify what it costs?”
6. Optimise for business goals, not just unit costs. A workload that costs $10,000 per month and drives $500,000 in revenue is not a cost problem. A workload that costs $500 per month and drives no measurable outcome is worth scrutinising.

Phase 1: Inform — building cost visibility

The Inform phase establishes the data infrastructure for FinOps. This means exporting Azure cost data at a granular level and making it accessible to the right people at the right time.

Enable cost export in Azure Cost Management to push daily cost data to Azure Blob Storage in CSV format. From there, ingest it into a reporting tool — Power BI, Azure Data Explorer, or a Synapse Analytics workspace — where teams can build dashboards against their own cost data without needing portal access.

# Create a daily cost export to Blob Storage
az costmanagement export create \
  --name daily-cost-export \
  --scope /subscriptions/SUB_ID \
  --type Usage \
  --dataset-granularity Daily \
  --timeframe MonthToDate \
  --schedule-status Active \
  --schedule-recurrence Daily \
  --schedule-recurrence-period from="2026-03-19T00:00:00Z" to="2027-03-19T00:00:00Z" \
  --storage-account-id /subscriptions/SUB_ID/resourceGroups/myRG/providers/Microsoft.Storage/storageAccounts/costexports \
  --storage-container cost-data \
  --storage-directory exports

Build a cost allocation model that maps spending to business units. The hierarchical model in Azure maps naturally to Management Groups (organisation), Subscriptions (business unit or environment), Resource Groups (team or application), and Tags (feature or cost centre). Design this hierarchy with FinOps in mind: each level should correspond to a team or budget owner who can act on the data.

Showback and chargeback models

Showback is the foundation of cost accountability. Generate a monthly report for each team showing their cloud spend broken down by service and resource, with a comparison to the previous month and to budget. Distribute it automatically from your BI tool or a scheduled Azure Function. The act of making costs visible to teams — without any formal billing or consequences — typically reduces spending by 15–25% as engineers self-correct obvious waste when they can see it.

Chargeback formalises the accountability. The organisation internally bills each team for their Azure spend, typically through finance system journal entries. For this to work, you need highly accurate cost allocation: every resource must be tagged or subscription-scoped to a cost centre. Shared infrastructure (networking hub, monitoring workspace, DNS) must be allocated using an agreed split — typically proportional to each team’s direct resource consumption.

A practical middle ground is budget accountability: each team owns a budget, receives showback reports, and is required to explain variances above a threshold. The budget owner is accountable for keeping their team within budget, even if no money actually changes hands in an internal billing system.

Phase 2: Optimise — systematic efficiency

Optimisation in FinOps is a continuous process, not a one-time project. Structure it as a repeating cycle:

1. Weekly: Review Azure Advisor cost recommendations. Accept or dismiss each recommendation with a recorded reason. Track advisor score over time.
2. Monthly: Review reservation utilisation. Reservations that are underutilised (below 80%) are wasted. Exchange or sell back unused reservations.
3. Monthly: Review orphaned resources — unattached disks, unused public IPs, empty load balancers, stopped VMs. Delete what is not needed.
4. Quarterly: Review VM right-sizing across all production workloads. Use the past three months of utilisation data to make evidence-based resize decisions.
5. Annually: Re-evaluate architectural choices. Are there workloads running on IaaS that would be cheaper on PaaS? Are there services that could be consolidated?

# Review reservation utilisation for the last 30 days
az consumption reservations summaries list \
  --grain daily \
  --reservation-order-id YOUR_RESERVATION_ORDER_ID \
  --query "[].{Date:reservationOrderId, UtilisedHours:usedHours, ReservedHours:reservedHours, UtilisationPct:utilizationPercentage}" \
  --output table

Phase 3: Operate — governance and culture

The Operate phase embeds FinOps into the engineering culture and processes so that cost consideration becomes habitual rather than reactive.

Cost reviews in architecture design. Add cloud cost estimation to the architecture review checklist. Before a new service is deployed to production, engineering teams estimate its steady-state cost using the Azure Pricing Calculator and document the estimate. After 30 days of production, compare actual vs estimate and use the gap to improve future estimates.

Cost gates in CI/CD. Tools like Infracost integrate into Terraform pull requests and post a comment showing the estimated monthly cost change. A configuration that adds $5,000/month triggers a review before it merges. This is far less disruptive than discovering the cost after deployment.

Engineering cost scorecard. Publish a monthly scorecard for each team showing their cost efficiency metrics: cost per unit of business value (cost per transaction, cost per active user), advisor score, DLQ depth, reservation utilisation. Make the data visible and gamify improvement.

Tagging compliance dashboards. Track what percentage of each team’s resources are correctly tagged. Target 100%. Untagged resources cannot be attributed to a cost centre and appear as “unallocated” in cost reports, undermining showback.

Allocating shared infrastructure costs

Not all Azure costs can be directly attributed to a team. Hub networking (ExpressRoute, Azure Firewall, DNS Private Resolver), monitoring workspaces, and shared platform services benefit everyone but are difficult to split. Three common allocation approaches:

• Fixed allocation: Each team pays a fixed monthly share of shared costs, regardless of usage. Simple to administer, but does not create efficiency incentives.
• Proportional allocation: Shared costs are split proportionally to each team’s direct resource spend. A team spending $50,000 in a month where total spend is $500,000 receives 10% of shared costs. This is fair and self-adjusting but requires a calculation step each month.
• Consumption-based allocation: For services that expose usage metrics (network bytes through the firewall, queries to the shared DNS zone), allocate shared cost proportionally to measured consumption. Most accurate but requires instrumenting every shared service.