Chargeback and Showback in Azure: Building a Cost Allocation Model

As organisations mature their FinOps practice on Azure, cost visibility alone is no longer sufficient. Finance teams need to allocate cloud costs to the correct business units, and engineering teams need to understand the financial impact of their architectural decisions. This is where chargeback and showback models become essential.

This post covers the difference between the two models and provides a practical approach to implementing cost allocation in Azure.

1. Showback vs Chargeback

Both models serve the same purpose of attributing cloud costs to the teams or business units that generate them, but they differ in consequence:

• Showback: teams are shown their costs for awareness and accountability, but the costs are not transferred to their budget. This is the appropriate starting point for most organisations.
• Chargeback: costs are formally allocated and transferred to the consuming team's budget. This requires financial systems integration and strong tagging discipline before it is viable.

I recommend starting with showback for at least one full quarter before introducing chargeback. Showback surfaces tagging gaps and data quality issues that would cause chargeback disputes if unaddressed.

2. Prerequisites: Tagging Strategy

A cost allocation model is only as accurate as the tagging on the resources being measured. Before building any reports, confirm the following tag coverage:

Navigate to Azure Policy > Compliance and filter for any tag-related policy assignments. Look for non-compliant resources and remediate them before proceeding.

The minimum required tags for a cost allocation model are:

Tag	Purpose
cost-center	Finance reference code for the owning business unit
team	Engineering team responsible for the resource
environment	Separates operational (prod) from non-operational (staging, dev) costs
workload	The product or service the resource supports

3. Using Azure Cost Allocation Rules

Azure Cost Management supports Cost Allocation Rules, which allow shared costs (such as a shared networking subscription, a centralised Log Analytics workspace, or a shared API Management instance) to be split and attributed to consuming subscriptions or resource groups.

1. Navigate to Cost Management + Billing > Cost Management > Cost allocation (preview)
2. Select + Add
3. Under Source, select the subscription or resource group containing the shared cost
4. Under Targets, define the allocation split, either by fixed percentage or proportional to each target's existing spend
5. Select Save

Following is an example allocation scenario:

Shared Resource	Total Monthly Cost	Allocated To	Split
Hub VNet + Firewall	$1,200	Production (70%), Non-Prod (30%)	Fixed
Centralised Log Analytics	$800	By each team's ingestion volume	Proportional

4. Exporting Chargeback Data for Finance Systems

Once allocation rules are configured, the resulting cost data can be exported for integration with finance systems.

Navigate to Cost Management > Exports with the subscription or management group as scope. Create a monthly scheduled export that includes the allocated cost data. The exported CSV includes the allocation split fields, enabling downstream processing to attribute costs to the correct cost centre.

For organisations using Power BI, the Azure Cost Management connector in Power BI Desktop connects directly to the Cost Management API and reflects cost allocation rules in real time.

5. Communicating Results to Stakeholders

The final step is delivering the showback or chargeback report to the relevant teams. Following is a practical distribution approach:

• Engineering teams: monthly cost summary by resource group, shared via a Power BI report or a Teams message generated by a Logic App triggered on export delivery
• Finance: monthly CSV export delivered to a shared storage account, consumed by the existing financial reporting process
• Leadership: a quarterly Workbook summary at management group scope showing total cloud spend by business unit and trend over time

Summary

A robust cost allocation model on Azure requires clean tagging, cost allocation rules for shared resources, and a consistent export and distribution process. Starting with showback builds the data quality and organisational habits needed to make chargeback viable, ensuring there are no disputes when costs are formally transferred to business unit budgets.

Using Azure Monitor Container Insights to Control AKS Costs

Azure Kubernetes Service workloads are frequently overprovisioned. Resource requests and limits set conservatively during initial deployment often remain unchanged as workloads stabilise, resulting in nodes running at a fraction of their available capacity while incurring full compute costs.

Azure Monitor Container Insights provides the visibility needed to identify overprovisioned workloads and make data-driven right-sizing decisions. This post covers enabling Container Insights and using its reports to reduce AKS cost.

1. Enabling Container Insights

Container Insights is not enabled by default on AKS clusters. To enable it:

1. Navigate to your AKS cluster > Monitoring > Insights
2. If not yet enabled, select Configure monitoring
3. Select the target Log Analytics workspace. Use an existing workspace to centralise container logs with other workload logs
4. Select Configure

Enabling Container Insights installs the Azure Monitor Agent on the cluster's node pools and begins collecting CPU, memory, and network metrics at the container, pod, node, and cluster level.

Note that Container Insights ingestion adds to Log Analytics workspace costs. For large clusters, review the expected ingestion volume before enabling. The Cost optimisation settings option (available during configuration) allows ingestion to be limited to essential metrics only.

2. Analysing Node Utilisation

The most immediate cost signal in Container Insights is node CPU and memory utilisation. Nodes consistently running below 30% utilisation are candidates for consolidation.

Navigate to AKS cluster > Monitoring > Insights > Nodes. The Nodes view shows:

• CPU usage % per node over the selected time range
• Memory working set % per node
• A summary of the node pool VM size and count

Set the time range to Last 30 days to get a representative view of utilisation patterns rather than a point-in-time snapshot. Nodes showing average CPU utilisation below 20% across a 30-day window warrant investigation.

3. Identifying Overprovisioned Workloads at the Container Level

Navigate to AKS cluster > Monitoring > Insights > Containers. This view shows per-container CPU and memory usage relative to the configured resource requests and limits.

Containers where:

• CPU usage is consistently below 20% of the request — the request should be reduced
• Memory usage never approaches the limit — the limit can be reduced without risk

Following is a KQL query that surfaces containers with low CPU utilisation relative to their requests:

KubePodInventory
| where TimeGenerated > ago(7d)
| join kind=leftouter (
    Perf
    | where ObjectName == "K8SContainer"
    | where CounterName == "cpuUsageNanoCores"
    | summarize AvgCPU = avg(CounterValue) by InstanceName
) on InstanceName
| project ContainerName, Namespace, AvgCPU
| order by AvgCPU asc

Run this query in Log Analytics workspace > Logs to get a ranked list of containers by CPU consumption.

4. Right-Sizing Node Pools

Once individual container overprovisioning is addressed, review whether the node pool VM size remains appropriate for the adjusted workload profile.

Navigate to AKS cluster > Node pools, select a node pool, and review the VM size. Azure Advisor may also surface AKS right-sizing recommendations if the cluster has been running with consistent utilisation data for 30+ days.

For development and staging clusters, consider:

• Switching to spot node pools for non-production workloads; spot pricing on AKS node pools can reduce VM costs by 60–80%
• Enabling cluster autoscaler with a min count of 1 during off-hours to avoid paying for idle nodes overnight

Summary

Container Insights provides the data needed to move AKS cost conversations from estimates to evidence. Combining node-level utilisation analysis with per-container resource request reviews typically surfaces meaningful right-sizing opportunities in any cluster that has been running for more than 60 days without a deliberate review.

Planning Your Azure Budget for the Year Ahead: A Practical Framework

The end of the calendar year is the right time to review actual Azure spend, assess what changed during the year, and set a realistic budget for the year ahead. A well-structured budget is not just a financial control; it is a governance tool that keeps engineering and finance aligned throughout the year.

This post outlines a practical framework for reviewing the current year's spend and setting up Azure budgets for the next 12 months.

1. Reviewing the Current Year's Spend

Before setting next year's budget, it is important to understand this year's patterns, particularly which resource groups grew significantly, which were decommissioned, and whether any anomalies inflated the total.

1. Navigate to Cost Management + Billing > Cost Analysis
2. Set the Time range to This year (or the last 12 months if the current year started recently)
3. Set Granularity to Monthly and Group by to Resource group

This view shows the month-by-month cost trend per resource group. Look for:

• Resource groups with consistent growth: these need a higher budget allocation next year
• Months with spikes: investigate whether these were one-time events (migrations, incidents) or recurring patterns
• Resource groups with zero activity in recent months: candidates for decommission

2. Estimating Next Year's Budget

A practical estimation approach is to take the last three months of spend (Q4 of the current year), calculate the average monthly cost, and apply a growth factor based on planned workload changes.

Following is a simple framework:

Input	Example
Average monthly spend (last 3 months)	$4,200
Planned new workloads	+15%
Expected optimisation savings	-10%
Estimated monthly budget	$4,410
Annual budget	$52,920

Add a buffer of 5–10% to the annual budget to account for unplanned usage. Setting the budget too tightly leads to constant alert noise; setting it too loosely removes the governance benefit.

3. Creating Annual and Monthly Budgets

Azure Cost Management supports budgets at multiple time grains. For annual planning, I recommend creating both an annual budget at subscription or management group scope and monthly budgets at individual resource group scope.

To create a budget:

1. Navigate to Cost Management + Billing > Cost Management > Budgets > + Add
2. Set the Reset period. Select Annually for the top-level budget and Monthly for resource group budgets
3. Set the Budget amount based on the estimate from Step 2
4. Configure alert thresholds at 50%, 80%, and 100%
5. Add email recipients for each threshold. Include both the engineering lead and a finance contact

4. Using the Forecast to Validate the Budget

Azure Cost Management includes a spend forecast based on historical usage patterns. This is a useful sanity check before finalising budget amounts.

Navigate to Cost Management > Cost Analysis and set the view to Accumulated costs. The forecast line (shown in a lighter colour beyond the current date) projects spending to end of period based on current trajectory.

If the forecast significantly exceeds the proposed budget, either adjust the budget upward or identify specific optimisation actions that will reduce spend before the new year begins.

5. Scheduling a Quarterly Budget Review

A budget set in January rarely reflects reality by June. Build in a quarterly review. At each review, compare actual spend against budget, assess whether planned workloads have materialised as expected, and adjust budgets or resource allocations accordingly.

Summary

Effective Azure budget planning starts with an honest review of the current year's data, followed by a realistic estimate that accounts for planned growth and known optimisations. Configuring budgets with graduated alert thresholds (not just a single 100% alert) ensures that teams have time to respond before limits are reached, avoiding surprises at year-end billing reconciliation.