APIM Costing/Showback Method (Using Azure Monitor & App Insights)

[ncheruvu-MSFT]

Workflow:

flowchart LR

    subgraph APIM
        G[API Gateway] -->|Logs: subscriptionId, apiName, latency| L
    end

    subgraph Observability
        L[Log Analytics Workspace]
        M[Azure Monitor Metrics]
        L --> K[Kusto Aggregations]
        M --> K
    end

    subgraph CostData
        C[Azure Cost Mgmt Export]
        C --> K
    end

    K --> P[Azure Monitor Dashboard]

    subgraph Governance
        T["Azure Tags (BU, Product, App)"]
        S[Subscriptions per BU]
    end

    T -.-> G
    S -.-> G

Loading

1. APIM Layer

Subscription key uniquely identifies the BU
APIM diagnostic logs capture:

subscriptionId
apiName
operationName
backendUrl
callerIp
duration, backendDuration
status codes

2. Observability Layer

Application Insights receives APIM diagnostics (via Diagnostic Settings)
Log Analytics Workspace stores:

ApiManagementGatewayLogs
AppTraces, AppRequests, AppDependencies

Kusto aggregates BU metrics

3. Cost Layer

Azure Cost Management Exports

Export to Storage Account daily
Contains cost grouped by subscription, resource group, tags

Kusto reads exported cost CSV → aggregates per BU

4. Dashboard Layer

Azure Monitor Workbooks

Real-time API usage
Latency (avg, p95, p99)
Backend response patterns
Error rates (4XX, 5XX)
Cost allocated per BU

Optional: App Insights Workbook Templates

5. Governance Layer

Consistent:

BU tags
APIM product names
Subscription naming
Backend tagging

[simonkurtz-MSFT]

Products are associated with APIs, not with consumers, so pairing an APIM subscription key with a product to distinguish customers would be inappropriate. Every caller - apps, business units, customers, etc. would have their own subscriptions (and, thus, keys) but not their own products.

Do we care about duration & backend duration? We should ensure we don't log data for data's sake when it comes to billing. We don't bill by minutes, we do it by requests (or, in the context of AI, with tokens).

I would speed up the export. Smaller deltas exported more often. Daily is an eternity nowadays. Better to make it a bit more frequent and allow for adjustments. I'd do it in minutes (start with every 10).

[ncheruvu-MSFT]

Products are associated with APIs, not with consumers, so pairing an APIM subscription key with a product to distinguish customers would be inappropriate. Every caller - apps, business units, customers, etc. would have their own subscriptions (and, thus, keys) but not their own products.

Do we care about duration & backend duration? We should ensure we don't log data for data's sake when it comes to billing. We don't bill by minutes, we do it by requests (or, in the context of AI, with tokens). once should be good.

I would speed up the export. Smaller deltas exported more often. Daily is an eternity nowadays. Better to make it a bit more frequent and allow for adjustments. I'd do it in minutes (start with every 10).

updated description and added workflow.

[simonkurtz-MSFT]

Let's start by calling this Costing rather than Chargeback as the former is a determination of what it may ultimately cost to call APIs whereas the latter is a consequence of that. Put differently, you may want to determine the cost, but you may not take it to a point where you charge business units for it. We are simply producing the data, not the process of the chargeback.

In the diagram, let's make these changes, please:

• The API Gateway would be part of APIM, not Clients.
• Similarly, pull out Backends from APIM

This is a bit of a hybrid here between an infrastructure and a sample as it layers on considerably. Let's see if you can package it into a costing sample first, even with the additional provisioning of resources and then reevaluate. I want to be very protective with how the infrastructures are set up in order to not add too many components beyond the intent of the infrastructure. Otherwise, we will be closing in on the landing zones approach, which this project aims to avoid ("too much").

[ncheruvu-MSFT]

Let's start by calling this Costing rather than Chargeback as the former is a determination of what it may ultimately cost to call APIs whereas the latter is a consequence of that. Put differently, you may want to determine the cost, but you may not take it to a point where you charge business units for it. We are simply producing the data, not the process of the chargeback.

In the diagram, let's make these changes, please:

• The API Gateway would be part of APIM, not Clients.
• Similarly, pull out Backends from APIM

This is a bit of a hybrid here between an infrastructure and a sample as it layers on considerably. Let's see if you can package it into a costing sample first, even with the additional provisioning of resources and then reevaluate. I want to be very protective with how the infrastructures are set up in order to not add too many components beyond the intent of the infrastructure. Otherwise, we will be closing in on the landing zones approach, which this project aims to avoid ("too much").

updated as per recommendations. we can also build alternative options like static webapp to show data.

[simonkurtz-MSFT]

Keep the implementation simple, please. The less moving parts, the better, I suspect.
Could you please update the diagram, too?

[simonkurtz-MSFT]

Apologies for not having this closed yet. Yesterday's PR should have been associated with it (and I didn't verify). Closing as complete now.