Microsoft Azure — Azure Cost Management

Azure is Microsoft's cloud computing platform offering over 200 services. This article covers azure cost management with production-ready configurations, best practices, and hands-on examples.

Why Azure Cost Management Fails Without Governance

Most Azure cost blowouts aren't accidents — they're the result of absent governance. Without policies, teams spin up oversized VMs, leave orphaned disks, and forget to shut down dev environments. Azure Cost Management (ACM) is the tool, but governance is the practice. Start by defining budgets, enforcing tags, and setting RBAC boundaries. A common failure mode: giving 'Contributor' access to junior devs who unknowingly deploy Premium SSD v3 disks on B-series VMs. The result? A $10k surprise at month-end. Governance means tagging every resource with 'Environment', 'Owner', and 'CostCenter' — and making those tags mandatory via Azure Policy. Without this, ACM dashboards are just pretty graphs of your burning money.

#!/bin/bash
# Enforce required tags on resource groups
az policy assignment create \
  --name 'require-tags' \
  --policy '2a0e14a6-b0a6-4fab-991a-187a4f81c8ae' \
  --params '{"tagName":{"value":"Environment"}}' \
  --display-name 'Require Environment tag'

# Assign deny effect for missing tags
az policy assignment create \
  --name 'deny-missing-tags' \
  --policy '7c4b3898-1234-4b7a-b3c1-d11111111111' \
  --params '{"tagName":{"value":"CostCenter"}}' \
  --display-name 'Deny missing CostCenter tag'

Setting Budgets and Alerts That Actually Work

Budgets in ACM are your early warning system. But most teams set a single monthly budget and ignore it. The real trick: tiered budgets with action groups. Set a budget at 80% of forecasted spend, then 100%, then 110%. Each threshold triggers an action group that sends email, posts to Slack, and optionally runs an automation runbook to shut down non-critical resources. Use the Consumption Budget API to create budgets programmatically. A common mistake: setting budgets on the subscription level only. Instead, set budgets per resource group or tag dimension (e.g., 'Environment:dev'). This way, a dev team blowing their budget doesn't trigger a false alarm for production. Also, enable anomaly alerts — they detect unusual spending patterns like a compromised VM mining crypto.

#!/bin/bash
# Create a budget for the 'dev' tag with action groups
az consumption budget create \
  --budget-name 'dev-budget' \
  --amount 5000 \
  --time-grain 'Monthly' \
  --time-period '{"startDate":"2026-01-01","endDate":"2026-12-31"}' \
  --category 'cost' \
  --scope '/subscriptions/...' \
  --notifications '{
    "firstThreshold": {
      "enabled": true,
      "operator": "GreaterThan",
      "threshold": 80,
      "contactEmails": ["finops@example.com"],
      "contactRoles": ["Owner"],
      "contactGroups": []
    },
    "secondThreshold": {
      "enabled": true,
      "operator": "GreaterThan",
      "threshold": 100,
      "contactEmails": ["finops@example.com"],
      "contactRoles": ["Owner"],
      "contactGroups": []
    }
  }'

Cost Allocation with Tags and Resource Groups

Raw cost data is useless without allocation. Tags are the primary mechanism, but they fail when teams don't apply them consistently. Use Azure Policy to enforce tag inheritance from resource groups. For shared resources (like a load balancer used by multiple apps), allocate costs proportionally using Azure Cost Allocation rules. These rules split costs based on tags, formulas, or percentages. For example, split a shared AKS cluster cost 70/30 between two teams. Without allocation, shared costs become an orphan line item that nobody owns. Pro tip: use the 'cm-resource-parent' tag to track hierarchical relationships. This enables chargeback reports that show each team their true cost, including shared infrastructure.

#!/bin/bash
# Create a cost allocation rule splitting shared AKS costs 70/30
az billing cost-allocation-rule create \
  --billing-account-name '...' \
  --rule-name 'aks-split' \
  --display-name 'AKS Cluster Split' \
  --details '{
    "sources": [
      {
        "sourceType": "Resources",
        "sourceResources": [
          {
            "resourceId": "/subscriptions/.../resourceGroups/shared/providers/Microsoft.ContainerService/managedClusters/aks-cluster",
            "resourceType": "Microsoft.ContainerService/managedClusters"
          }
        ]
      }
    ],
    "targets": [
      {
        "targetType": "CostAllocationProportional",
        "policy": {
          "tag": "CostCenter",
          "values": {
            "team-a": 70,
            "team-b": 30
          }
        }
      }
    ]
  }'

Rightsizing Recommendations: Trust but Verify

ACM's rightsizing recommendations are a good starting point, but they're not gospel. They often suggest downsizing based on average utilization, ignoring peak loads. For example, a VM running at 40% CPU average might need that headroom for batch jobs. Always validate with Azure Monitor metrics over a 30-day window. Use the Azure Resource Graph to query underutilized resources and cross-reference with your own monitoring. A common pattern: identify VMs with CPU < 5% and network < 1 MB for 7 days, then schedule a shutdown during off-hours. But beware — rightsizing a database server without understanding query patterns can cause performance degradation. Production insight: we once downsized a VM based on ACM recommendation, only to find the app crashed during month-end processing because the new SKU had less memory bandwidth.

// Kusto Query to find VMs with low CPU and network
let threshold_cpu = 5.0;
let threshold_network = 1.0; // MB
let lookback = 7d;
resources
| where type == 'microsoft.compute/virtualmachines'
| extend vmId = id
| join kind=inner (
    metric
    | where TimeGenerated > ago(lookback)
    | where MetricName == 'Percentage CPU'
    | summarize avg_cpu = avg(Average) by _ResourceId
) on $left.vmId == $right._ResourceId
| where avg_cpu < threshold_cpu
| join kind=inner (
    metric
    | where TimeGenerated > ago(lookback)
    | where MetricName == 'Network In Total'
    | summarize avg_network = avg(Average) by _ResourceId
) on $left.vmId == $right._ResourceId
| where avg_network < threshold_network * 1024 * 1024 // convert MB to bytes
| project vmId, avg_cpu, avg_network

Reserved Instances and Savings Plans: When to Commit

Reserved Instances (RIs) and Savings Plans (SPs) offer significant discounts (up to 72%) for committing to 1 or 3 years. But they're not always the right move. The key is to analyze your baseline spend — the resources that run 24/7. Use ACM's 'Advisor recommendations' for RI/SP purchases, but again, verify. A common mistake: buying RIs for burstable workloads. If your VM runs only 8 hours a day, a Savings Plan (which covers all compute) is better than a VM-specific RI. Also, consider Azure Hybrid Benefit for Windows Server and SQL Server licenses. Production insight: we saw a team buy 3-year RIs for a project that got cancelled after 6 months. They were stuck paying for unused capacity. Always start with 1-year commitments and only go 3-year for truly stable workloads. Use the 'Exchange' and 'Refund' policies as a safety net, but don't rely on them.

#!/bin/bash
# Get RI purchase recommendations from ACM
az consumption reservation recommendation list \
  --subscription-id '...' \
  --look-back-period 'Last30Days' \
  --product 'Standard_D2s_v3' \
  --scope 'Single' \
  --term 'P1Y' \
  --query '[].{sku:sku, normalizedSize:normalizedSize, recommendedQuantity:recommendedQuantity, expectedSavings:expectedSavings}' \
  --output json

Automating Cost Optimization with Azure Policy and Runbooks

Manual cost optimization doesn't scale. Automate using Azure Policy for governance and Azure Automation runbooks for remediation. For example, create a policy that denies creation of VMs above a certain size (e.g., no Standard_E64s_v3 in dev). For existing resources, schedule a runbook to shut down VMs during off-hours. Use the 'Start/Stop VMs during off-hours' solution from Azure Automation, but customize it to your needs. Another pattern: automatically delete orphaned disks older than 30 days. Use Azure Resource Graph to find disks not attached to any VM, then run a cleanup script. Production insight: we automated shutdown of non-production VMs from 7 PM to 7 AM, saving 40% on compute costs. But we learned to exclude VMs with 'DoNotShutdown' tag to avoid breaking critical batch jobs.

# PowerShell runbook to stop VMs based on tag
param(
    [Parameter(Mandatory=$true)]
    [string]$ResourceGroupName
)

$connection = Get-AutomationConnection -Name AzureRunAsConnection
Connect-AzAccount -ServicePrincipal -Tenant $connection.TenantID -ApplicationId $connection.ApplicationID -CertificateThumbprint $connection.CertificateThumbprint

$vms = Get-AzVM -ResourceGroupName $ResourceGroupName | Where-Object {$_.Tags['DoNotShutdown'] -ne 'true'}
foreach ($vm in $vms) {
    if ($vm.PowerState -eq 'VM running') {
        Stop-AzVM -ResourceGroupName $ResourceGroupName -Name $vm.Name -Force
        Write-Output "Stopped VM: $($vm.Name)"
    }
}

Monitoring and Reporting with Power BI and ACM APIs

ACM's built-in dashboards are limited. For real visibility, export cost data to Azure Storage and build custom reports in Power BI. Use the Consumption API to pull detailed cost data daily. Set up a data export to a storage account, then use Power BI's Azure Cost Management connector. Build reports that show cost by tag, resource type, and region. Include trends and forecasts. A common mistake: only looking at monthly totals. Instead, track daily spend to catch anomalies early. Also, create a 'cost per unit' metric — e.g., cost per transaction or per user. This ties cloud spend to business value. Production insight: we built a Power BI report that showed cost per environment per team. One team's dev environment was costing more than production because they left GPU instances running. The report made it obvious, and they fixed it within a week.

#!/bin/bash
# Create a daily cost export to storage
az costmanagement export create \
  --scope '/subscriptions/...' \
  --export-name 'daily-cost-export' \
  --schedule '{"recurrence":"Daily","recurrencePeriod":{"from":"2026-01-01T00:00:00Z","to":"2026-12-31T00:00:00Z"}}' \
  --delivery-info '{"destination":{"resourceId":"/subscriptions/.../resourceGroups/rg-cost/providers/Microsoft.Storage/storageAccounts/costexports","container":"costdata","rootFolderPath":"/daily"}}' \
  --definition '{"type":"ActualCost","timeframe":"MonthToDate","dataSet":{"granularity":"Daily","grouping":[{"type":"Tag","name":"Environment"},{"type":"Tag","name":"CostCenter"}]}}'

Handling Multi-Account and Enterprise Agreement Scenarios

At scale, you'll have multiple subscriptions, maybe multiple Azure AD tenants, and an Enterprise Agreement (EA) or Microsoft Customer Agreement (MCA). ACM can aggregate costs across subscriptions, but you need proper hierarchy. Use management groups to organize subscriptions by department or environment. For EA, enable the 'Azure Cost Management' role for finance teams. A common pain point: cross-tenant cost visibility. You can't see costs across tenants in a single ACM view. Instead, export cost data from each tenant to a central storage account and aggregate in Power BI. Also, understand the difference between EA billing scopes (enrollment, department, account) and MCA billing profiles. Production insight: a client with 50 subscriptions across 3 tenants had no unified view. We built a central Power BI report that ingested exports from each tenant, giving the CFO a single pane of glass.

#!/bin/bash
# Export cost from each tenant to central storage
# Run this in each tenant with appropriate credentials
TENANT_ID='tenant-a-id'
SUBSCRIPTION_ID='sub-a-id'
CENTRAL_STORAGE='costexportscentral'

az costmanagement export create \
  --scope "/subscriptions/$SUBSCRIPTION_ID" \
  --export-name "cross-tenant-export" \
  --schedule '{"recurrence":"Daily","recurrencePeriod":{"from":"2026-01-01T00:00:00Z","to":"2026-12-31T00:00:00Z"}}' \
  --delivery-info "{\"destination\":{\"resourceId\":\"/subscriptions/central-sub/resourceGroups/rg-cost/providers/Microsoft.Storage/storageAccounts/$CENTRAL_STORAGE\",\"container\":\"costdata\",\"rootFolderPath\":\"/$TENANT_ID\"}}" \
  --definition '{"type":"ActualCost","timeframe":"MonthToDate","dataSet":{"granularity":"Daily"}}'

Cost Optimization for Containers and AKS

AKS cost management is tricky because you pay for the underlying VMs, not the pods. Use the AKS Cost Analysis add-on (preview) to see cost per namespace, deployment, or label. Enable the 'Cost analysis' feature in the AKS cluster and install the 'cost-analyzer' Helm chart. This breaks down cluster costs by workload. A common mistake: over-provisioning node pools. Use cluster autoscaler and node pool scaling to match demand. Also, consider using Spot VMs for batch workloads — they can save up to 90%. But beware of eviction. Production insight: we saw a team running 10 nodes for a dev cluster that had 3 pods. After enabling cost analysis, they downsized to 3 nodes and saved $4k/month. Another tip: use Azure Policy for AKS to enforce resource limits on namespaces, preventing noisy neighbors from consuming all cluster resources.

# Install AKS cost analysis add-on
apiVersion: helm.azure.com/v1
kind: HelmRelease
metadata:
  name: cost-analyzer
  namespace: cost-analysis
spec:
  chart:
    repository: https://kubecost.github.io/cost-analyzer
    name: cost-analyzer
    version: 1.100.0
  values:
    global:
      azure:
        subscriptionId: "..."
        resourceGroupName: "rg-aks"
        clusterName: "aks-cluster"
      prometheus:
        enabled: true
    kubecostProductConfigs:
      clusterName: "aks-cluster"
    networkCosts:
      enabled: true

Azure Cost Management is a tool, but the real win is culture. You need buy-in from developers, architects, and finance. Start small: enforce tagging, set budgets, and share cost reports weekly. Celebrate wins — when a team reduces spend, highlight it. Use gamification: give a 'Cost Champion' award each quarter. But also have teeth: if a team exceeds budget without justification, escalate. Production insight: we implemented a 'cost review' as part of every sprint retrospective. Within 3 months, teams were proactively optimizing. The key is to make cost visibility a habit, not a monthly panic. Remember: the goal is not to minimize spend, but to maximize value per dollar. Don't optimize so hard that you hurt innovation. Balance cost with performance and reliability.