GPU and Model Cost Allocation: What AWS, Azure and Google Bills Can Attribute

GPU cost allocation on the three big clouds is no longer a blank. Since April 2026, Amazon Bedrock can attribute model spend to the IAM role that made the call, but only per usage type per day. Google lets you put labels on every Vertex AI request, but caps each label key at 1,000 unique values for the life of the billing account. Azure splits Foundry spend by model deployment. We read the vendor documentation for 7 common allocation tasks across all three clouds. Native billing fully handles 7 of the 21 cells.

Who this is for: the head of a platform or FinOps team who runs AI workloads on more than one cloud and has to produce a single chargeback report.

The short answer: AWS, Azure and Google can all split managed model spend by application, and AWS can also split it by IAM caller. None of them can price a single request in the bill. GPU-hours by Kubernetes namespace are available on EKS and GKE with caveats, and least documented for GPUs on AKS.

This post sits next to our earlier reading of what the State of FinOps 2026 says about AI spend tooling. This one stays inside the three native billing products.

AWS Bedrock cost tracking: profiles, Projects and IAM principals

AWS now offers three separate ways to attribute Bedrock spend, and which one works depends on the endpoint your code calls.

Application inference profiles and Projects split spend by workload

An application inference profile is a resource you create per application or team, tag, and then pass as the model ID. The Bedrock user guide says you can "attach tags to an application inference profile to track costs when you submit on-demand model invocation requests". You pass the profile ARN in InvokeModel, Converse and their streaming variants.

The catch is the endpoint. Bedrock now runs two inference endpoints, bedrock-runtime and the newer bedrock-mantle. AWS's IAM principal cost tracking page carries a comparison table showing that application inference profiles work only on bedrock-runtime. Projects, the construct AWS marks as recommended, work only on bedrock-mantle with the Responses and Chat Completions APIs. If half your services call one endpoint and half the other, you need both constructs.

A team that standardises on inference profiles and then moves a service to bedrock-mantle loses its application attribution silently. Nothing errors.

IAM principal attribution reaches the caller, at daily grain

On 9 April 2026 AWS announced cost allocation by IAM principal for Bedrock, in CUR 2.0 and Cost Explorer. On 11 August 2026 it extended the feature to bedrock-mantle. The AWS Billing guide says AWS records the caller identity for each Bedrock call in a line_item_iam_principal column, and tags on that principal appear with an iamPrincipal/ prefix.

Three limits matter in practice. The finest grain is per usage type per day, with no per-request cost. Tags are not retroactive, so only spend after activation is attributed. And tags are activated from the payer account, not a member account.

The same page recommends Projects for application-level attribution and IAM principals for user-level attribution in the same account. It also notes that session tags suit "LLM gateways that proxy requests on behalf of multiple users or tenants". We think that is the strongest design on any of the three clouds: a gateway that assumes a role with session tags per tenant gets tenant-level cost into the bill. Enabling it multiplies CUR rows by the number of calling identities per model.

Per-request token counts live elsewhere. Bedrock model invocation logging records input and output token counts and the caller's ARN for every request. It is disabled by default and captures only bedrock-runtime calls. So the newer endpoint, the one Projects need, is currently invisible to the only per-request record AWS offers.

Azure OpenAI cost management: deployments, project tags and the gateway

Azure's model is the most resource-shaped of the three. Cost attaches to the Foundry resource and its model deployments, and finer attribution comes from Azure API Management rather than from Cost Management.

Deployment and project splits in Cost Analysis

Microsoft's Foundry cost management page, updated in October 2026, says you can add "deployment tags, user-defined tags" as filters to segment costs by model deployment. It also describes a preview feature: for supported models, project usage is automatically tagged with a project tag. That covers models sold by Azure, including Azure OpenAI, and not models served through Azure Marketplace.

Azure OpenAI appears under the Cognitive Services service name, so the right filter is the Azure OpenAI service tier rather than a service filter. Partner and community model meters land under the resource group rather than the Foundry resource, so a cost view scoped to the resource undercounts.

If your teams share a deployment, you get nothing finer from the bill.

Per-caller token counts come from API Management, not the bill

For per-caller attribution Microsoft points to Azure API Management. Its llm-emit-token-metric policy, formerly named azure-openai-emit-token-metric, sends total, prompt and completion token counts to Application Insights. Default dimensions include API ID, Product ID, User ID and Subscription ID, and you can add up to five custom dimensions. It now covers OpenAI Chat Completions and Responses, Anthropic Messages and Google Vertex AI.

The limits are tight. API Management limits each dimension to 100 unique values and each metric namespace to 1,000 active time series, and data beyond that is silently discarded. A dimension keyed on end-user ID breaks in any product with more than 100 users.

Provisioned deployments add another wrinkle. Microsoft's provisioned throughput page says they are billed hourly per PTU "regardless of the number of tokens consumed", and that reservation discounts apply to the PTU meter rather than to individual deployments. If two teams share a provisioned deployment, the bill cannot split it at all.

Google Cloud Billing and Vertex AI: labels on every request

Google takes the most granular approach of the three. You attach labels to the inference request itself, and those labels flow into Cloud Billing reports and the BigQuery billing export.

Request labels and the 1,000-value ceiling

Google's custom metadata labels page says Gemini calls take labels in the request body on generateContent and streamGenerateContent. Partner models such as Anthropic Claude and Mistral take them in an X-Vertex-AI-Labels header. A call can carry up to 64 labels for Google models and 32 for partner models. Costs typically appear within a day, sometimes later.

The limit that shapes your design is cardinality. Each label key can hold up to 1,000 unique values over the life of the billing account, and the key "might be dropped without notice" beyond that. Google itself warns against timestamps and per-call IDs. So request labels suit team, feature and environment keys, not customers or requests.

Header labels with the x-goog-agent-platform-observability-label prefix reach request metadata logs only, and Google's page states that they "never reach Cloud Billing". Use both on purpose: body labels for low-cardinality billing keys, header labels for run and request IDs that belong in logs.

Provisioned Throughput silently drops your labels

The same page says requests using the Provisioned Throughput consumption option "silently ignore labels sent in the request". Provisioned Throughput is Google's fixed-price, fixed-term capacity product. Header labels are still recorded in logs, but the billing attribution disappears. A team that moves a busy workload from pay-as-you-go to a 1-year commitment to save money also loses its per-feature cost view on that day.

The pattern holds across all three clouds: the cheaper the capacity, the coarser the attribution.

GPU cost allocation by team on EKS, AKS and GKE

Self-hosted models and fine-tuning jobs run on GPU nodes, usually in Kubernetes.

On AWS, split cost allocation data for EKS has covered NVIDIA and AMD GPUs, Trainium and Inferentia since 2 September 2025. It adds three usage records per pod per hour for accelerated instances in the CUR. AWS's September 2025 blog explains that pods are charged the greater of reservation and usage, and unused instance cost is "proportionally distributed to each pod". A separate splitLineItem/UnusedCost column exists, so idle cost can be queried, but it is folded into team totals by default.

On Google, GKE cost allocation writes namespace, workload and pod labels into the detailed BigQuery export, and GPU SKUs are covered. Unrequested capacity lands in a kube:unallocated bucket rather than inside team totals, which is the cleaner choice for finding waste. Two caveats stand out. Google says the feature does not work with A4 or A4X instances or their GPUs, which are its newest Blackwell-generation machine types. And a pod with more than 50 Kubernetes labels loses all of them in billing.

On Azure, the AKS cost analysis add-on, built on OpenCost, breaks cost down by cluster and namespace and reports idle, system and unallocated charges separately. Microsoft's page does not mention GPUs or GPU node pools. It also requires the Standard or Premium cluster tier and an Enterprise Agreement or Microsoft Customer Agreement.

Requests, not utilisation, on every cloud

All three Kubernetes tools allocate on reservations or requests. Google says so directly: allocation data "is based on resource requests, not resources consumed". AWS uses the greater of the two. None of them tells you how busy the accelerator was. A team that requests a full GPU and runs it at 15% utilisation is billed for the full GPU in every one of these reports. Utilisation has to come from monitoring telemetry joined on node and pod. The money at stake is laid out in our GPU break-even utilisation model.

The cloud cost management AI matrix, with a document behind every cell

Each cell links to the vendor page that supports the verdict. "Native" means the cloud's own billing data answers the question. "Partial" means it answers with a documented condition or only through logs or metrics. "Gap" means the documentation we read describes no native answer.

Source: vendor documentation linked in each cell, retrieved 6 and 7 November 2026. Verdicts are Zan Digital's reading of the documentation, not product tests.

Counting the cells gives the original figure in this post. Of 21 cells, 7 are native, 11 partial and 3 gaps. AWS scores 3 native cells, Azure and Google 2 each. The differences are in which questions each cloud answers, not in how many.

A sample tagging scheme that survives all three clouds

The design rule: put low-cardinality ownership keys in billing, and put high-cardinality identifiers in logs. Google's limits are the strictest, so design to them and the scheme works everywhere: lowercase keys, digits, underscores and dashes only, at most 63 characters, and no key that will ever exceed 1,000 values.

Billing keys versus log keys

The first five keys are ownership keys: they change rarely and belong in the bill. The last two are identity keys: they grow without limit and belong in logs or traces, joined back to billing on day, model and team.

Two rules make this scheme hold. First, issue a separate inference profile, Project, deployment or label value per team before anyone ships. Every cloud in the matrix refuses to rewrite history once tags arrive. Second, route all model traffic through one gateway that stamps the keys. Hand-applied tags decay the day an engineer copies a code sample without them. Our comparison of AI gateway fees and failover covers what that layer costs.

For per-run cost, the run_id has to travel with every model call into your tracing tool. The tracing products in our LangSmith, Braintrust and Arize review record tokens per span. Multiply by your rate card and you have an estimated cost per run that you reconcile against the daily bill by team.

Where native tools stop and finops AI spend tools start

The matrix shows four gaps that push teams to third-party cloud cost management tools.

The first is cross-cloud normalisation. AWS calls the owner an IAM principal tag, Azure a deployment tag, Google a request label. A team on two clouds has to map three schemas into one report.

The second is direct provider spend. Calls to OpenAI or Anthropic outside a cloud never touch these bills. Those invoices arrive by API key and day, as our State of FinOps reading documents.

The third is shared committed capacity. When two teams share a Provisioned Throughput or PTU block, someone must split the hourly charge by each team's share of tokens. A tool can, if it ingests your gateway metrics alongside the bill.

The fourth is cost per task. No native bill carries a run ID, so any tool claiming cost per agent run is joining billing data to your traces. Ask the vendor to show the join, not the dashboard. Variance at this level is large, as our measurement of agent token cost variance shows.

Our position: buy a third-party tool for normalisation and shared-capacity splitting if you run on two or more clouds. Do not buy one to get per-task cost.

Where this comparison is weakest

Three objections deserve a direct answer, and the first partly wins.

First, this is a documentation reading, not a product test. Azure's AKS add-on may well allocate GPU node cost correctly. We marked it partial because the page does not say so. The same applies to AWS Provisioned Throughput, where the API reference documents resource tags but we found no page describing how they flow into cost reports.

Second, the verdict scale is ours. "Native" versus "partial" is a judgement, and a reader could defensibly move two or three cells. Bedrock's daily-grain IAM attribution could be called partial. Google's request labels could be called native for callers in a small B2B product. The count of 7 native cells is a summary of our reading and should not be quoted as a measured market fact.

Third, the documentation is moving fast. Bedrock's IAM attribution is seven months old and its bedrock-mantle extension under three. Azure's project tag is in preview. Google's pages are mid-rebrand to new product names and paths. Any cell here could change within a quarter.

What survives all three objections: none of the clouds documents per-request cost in the bill, and all three degrade attribution on committed capacity. Those are design facts, and your tagging scheme should assume them.

Frequently asked questions

Where to start this week

Find out which Bedrock endpoint each of your services calls, which Azure deployments are shared between teams, and which Vertex AI workloads run on Provisioned Throughput. Those three lists mark exactly where your current tags are silently failing.

Then pick the five billing keys above and have one gateway owner stamp them on every model call. History will not backfill, so every week of delay is spend you can never allocate. When the data starts flowing, feed it into your AI spend forecasting process so the forecast is built on attributed spend rather than a single line.

Related reading