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.

Configuring Azure Monitor Private Link Scope (AMPLS) for Secure Log Ingestion

In regulated industries and enterprise environments, network security requirements often mandate that monitoring data must not traverse the public internet. Azure Monitor Private Link Scope (AMPLS) addresses this by enabling Log Analytics workspaces and Application Insights resources to receive data exclusively over a private network connection.

This post covers the AMPLS architecture and provides a step-by-step configuration guide.

1. What Is AMPLS and Why Use It

Without AMPLS, Azure Monitor agents on virtual machines send telemetry to Azure Monitor's public endpoints over the internet, even if the VMs themselves are on a private network. AMPLS routes this traffic through a Private Endpoint within the virtual network, ensuring that log ingestion never leaves the private network boundary.

Key scenarios where AMPLS is required:

• Compliance requirements that prohibit data traversal over public networks (e.g., Australian ISM, PCI-DSS)
• Environments where outbound internet access from VMs is blocked by policy
• Hub-and-spoke network architectures where monitoring traffic must flow through a centralised network hub

AMPLS uses two access mode settings that control its behaviour:

• Private Only: the workspace accepts data only from private endpoint connections
• Open: the workspace accepts data from both private endpoints and public endpoints

Start with Open mode during migration to avoid disrupting existing monitoring while private connectivity is being established

2. Creating the Private Link Scope

1. Navigate to Azure Monitor > Private Link Scopes
2. Select + Create
3. Provide a Name and select the Resource group and Region
4. Under Azure Monitor Private Link Scope settings, set Data Ingestion access mode to Open for initial configuration
5. Select Review + create

Once created, the Private Link Scope is an empty container. Resources must be connected to it before it provides any routing.

3. Connecting Log Analytics Workspaces

1. Open the newly created AMPLS resource
2. Navigate to Azure Monitor Resources > + Add
3. Select the Log Analytics workspace to connect
4. Select Apply

Repeat this process for any Application Insights resources that should also route through the private endpoint. A single AMPLS instance can connect up to 50 Log Analytics workspaces and 50 Application Insights resources.

Following is a summary of what AMPLS covers once resources are connected:

Traffic Type	Routed via AMPLS
Log Analytics agent (AMA/MMA) data ingestion	Yes
Application Insights SDK telemetry	Yes
Log Analytics query API	Yes
Azure Diagnostics (VM diagnostic extension)	No (separate configuration required)

4. Creating the Private Endpoint

The Private Endpoint is the network interface within the virtual network that routes traffic to AMPLS.

1. From the AMPLS resource, navigate to Private endpoint connections > + Private endpoint
2. Provide a name and select the Subscription, Resource group, and Region
3. Under Resource, confirm the target is the AMPLS resource with sub-resource azuremonitor
4. Under Virtual Network, select the VNet and subnet where the private endpoint should be placed
5. Under DNS, select Yes for private DNS zone integration. This is required for name resolution to work correctly

Azure automatically creates the required private DNS zones (privatelink.monitor.azure.com, privatelink.ods.opinsights.azure.com, and others) when DNS integration is selected.

5. Validating Connectivity

After the private endpoint is provisioned, validate that an Azure Monitor Agent on a VM in the connected VNet can reach the workspace through the private endpoint:

Heartbeat
| where TimeGenerated > ago(1h)
| summarize count() by Computer, SourceSystem

Agents routing through AMPLS report SourceSystem = "OpsManager". Confirm that expected VMs are appearing and that heartbeats are consistent.

Summary

AMPLS provides a clear network path for Azure Monitor telemetry in environments where public endpoint access is not acceptable. The configuration is straightforward: create the scope, connect workspaces, deploy a private endpoint with DNS integration, and validate with a heartbeat query. Starting in Open access mode allows existing agents to continue working while private connectivity is established and tested.