Today, Vantage is launching Token Allocation Support for AWS Bedrock Model Invocation Logs, attributing costs to per-invocation metadata in order to allocate billed Bedrock costs by team, application, customer, feature, environment, experiment, or other business dimensions.

Today, customers utilizing the Legacy Cost and Usage Report are able to attribute AWS Bedrock spend by account, model, and region. CUR 2.0 adds the IAM Principal and Session that drove costs, plus any cost-allocation tags applied to that principal. In many applications, multiple end-users, customers, or features share a single IAM principal, making principal tags a constant across that principal’s requests. This limits CUR-based attribution to the IAM principal rather than the per-invocation business context that generated the spend. The per-invocation context needed for allocation below the principal level—such as customer, feature, environment, experiment, or other application metadata—is available in Bedrock Model Invocation Logs as raw JSON, including optional requestMetadata provided at request time. However, this information exists only in logs and is not natively joined to cost data in AWS.

Now, with the launch of LLM Token Allocation for Bedrock, customers can use Model Invocation Logs to gain request-level attribution of Bedrock costs, allowing them to perform precise cost allocations of their LLM usage. Customers can navigate to the LLM Enrichment section of the Integrations page and select AWS Bedrock, then provide read-only access to their Model Invocation Log bucket via CLI, Terraform, or the AWS Console, and Vantage will automatically begin ingesting all log data. Vantage then joins each Bedrock cost row to the matching invocation log entries during ingestion, splitting a single cost row into multiple enriched rows—proportionally allocated by token share, with requestMetadata tags propagated onto every resulting row. Customers can then roll those tags into the dimensions that matter for their business using Virtual Tags—teams, applications, environments, cost centers, product lines, or anything else composable from the tags their applications are already emitting at invocation time.

Token Allocation Support for AWS Bedrock Model Invocation Logs is available at no additional Vantage charge for eligible customers with an AWS billing integration. To get started, go to the LLM Enrichment section of the Integrations page and select AWS Bedrock. For more information, see our AWS Bedrock LLM Enrichment documentation.

Frequently Asked Questions

1. What is Vantage launching?

Vantage is launching Token Allocation Support for Bedrock Model Invocation Logs. Vantage reads Bedrock Model Invocation Logs from S3, uses their LLM usage and metadata to allocate matching Bedrock CUR costs, and surfaces the resulting dimensions as tags in Cost Reports, Virtual Tags, Budgets, and more.

2. Who is this for?

This is for engineering managers and AI platform leaders who need to isolate which teams, applications, workflows, models, or product features are driving Bedrock token consumption, and for Finance and FinOps teams that need to translate that usage into precise product, feature, customer, or cost-center allocations for COGS, margin analysis, chargeback, budgeting, and forecasting. It is especially valuable when multiple workloads share an AWS account or IAM principal and the CUR does not contain the business context needed for bottom-line attribution.

3. How much does it cost?

There is no additional charge for Bedrock Token Allocation. It is included for customers with an AWS integration, and allocated costs do not count against a separate meter.

4. How does the feature work?

Amazon Bedrock Model Invocation Logging writes gzipped JSON records to an S3 bucket owned by the customer, including its account, Region, timestamp, request ID, operation, model, calling identity, token counts, and any requestMetadata supplied by the application. In Vantage, the customer connects each bucket where logs are stored as an AWS Bedrock enrichment source. Vantage adds read-only access to the existing AWS cross-account role; it does not create a new role or require long-lived credentials.

With each AWS cost import, Vantage:

• Reads Model Invocation Log objects for the relevant dates.
• Normalizes supported records by AWS account, model, Region, operation, inference scope, service tier, token type, and metadata.
• Deduplicates repeated records using their request identifiers and groups token usage by metadata combination.
• Matches those token groups to eligible Bedrock cost rows and splits each row in proportion to token share.
• Adds the corresponding requestMetadata and Vantage-managed vntg:ai:* tags to the enriched rows.

Only records with a model and positive supported token usage enter the allocation index. Records that cannot be matched are withheld rather than attributed to the wrong cost.

Neither Legacy CUR nor CUR 2.0 contains a Bedrock request ID, so this is not a one-to-one request-to-invoice join. Vantage reconciles logged usage to aggregated CUR rows using the billing day, model, token type, AWS account, and applicable pricing qualifiers. The AWS bill remains the source of truth: enrichment changes attribution, not total cost.

5. How do I configure this in AWS?

In order to configure Bedrock Invocation logs in AWS, you will need:

• Bedrock Model Invocation Logging enabled in every AWS Account and Region where your applications make supported runtime calls, with Amazon S3 configured as a destination. Logging is disabled by default and each destination bucket must be in the same AWS account and Region as its logging configuration.
• Custom requestMetadata for the dimensions you want to allocate, such as team, application, customer, feature, or environment. Converse and ConverseStream accept the metadata in the request body; InvokeModel and InvokeModelWithResponseStream use the signed X-Amzn-Bedrock-Request-Metadata header. Bedrock supports up to 16 string key/value pairs per request.
• An existing Vantage AWS billing integration for the account, plus read access from its cross-account role to the Model Invocation Log bucket. If the bucket uses SSE-KMS, grant kms:Decrypt separately.

Vantage does not enable Model Invocation Logging or create and manage its destination buckets. Customers retain ownership of the buckets, logging configuration, metadata, and retention policy. For a multi-account rollout, use Vantage's reference Bedrock Token Allocation solution in the FinOps as Code repository.

6. Why use Model Invocation Logs if CUR 2.0 already supports IAM principal attribution?

IAM principal attribution may be enough when your AWS identities already match how you want to allocate costs. CUR 2.0 identifies the calling user, role, or assumed-role session, and activated role or session tags can associate that usage with a team or cost center. But when one application session serves several customers or features, those tags do not distinguish the individual requests within that session.

Session tags can vary between sessions, but using them for customer or feature allocation requires managing sessions around those dimensions. With requestMetadata, the same session can send one Bedrock call tagged customer=acme, feature=search and the next tagged customer=globex, feature=summarization. The allocation context changes with each call without changing how the application authenticates.

Model Invocation Logs capture that metadata alongside token usage and caller identity. Vantage uses those token counts to allocate matching CUR costs by customer, feature, or other request-level dimensions while preserving the billed total. The logs also provide request details for investigation, and Vantage Import History shows how much logged usage matched the bill and helps diagnose allocation gaps. Existing IAM and supported application inference profile tags remain useful alongside this finer-grained context.

7. What AWS permissions does Vantage receive?

Vantage extends the existing AWS cross-account role; it does not create a second Vantage role or require long-lived credentials. It uses read-only permissions scoped to the configured sources:

• s3:GetObject and generated-policy s3:GetObjectAcl for log objects
• s3:ListBucket and s3:GetBucketLocation to locate objects and determine the bucket Region
• bedrock:GetModelInvocationLoggingConfiguration to discover the configured destination, prefix, and Region
• kms:Decrypt when objects use SSE-KMS

KMS access must be granted separately from the generated S3 and Bedrock policy. Vantage does not write to the bucket or change Bedrock logging configuration.

8. Does Vantage collect prompts or completions?

No. Bedrock Model Invocation Logs can contain request and response content in the customer's AWS account, but Vantage extracts only the fields needed for enrichment, such as model, Region, operation, token counts, caller identity, and requestMetadata. Vantage does not collect or store prompt or completion text, and does not write that content to Vantage-owned enrichment artifacts. Customers should still protect and retain their source logs according to their own security and privacy requirements.

9. Is enrichment data used to train models?

No. Vantage does not use this enrichment data to train models.

10. How fresh are allocated costs?

Enrichment runs as part of the existing AWS cost-ingestion process and follows the AWS refresh cadence. Vantage reprocesses a rolling three-day window so late-arriving log objects can be picked up automatically.

11. How far back will Vantage enrich Bedrock spend?

There is no separate Vantage-imposed log-history limit. A billing period can be enriched when it is processed while an active source exists and matching logs remain in the bucket. Connecting a source does not automatically reprocess every completed historical month. Older periods are enriched when those billing periods are reprocessed, such as through an AWS restatement or CUR backfill.

12. What happens when logged usage and billed usage do not match?

The same reconciliation rules used by Custom LLM Enrichment apply:

• If matching logs contain fewer tokens than the bill, Vantage allocates the covered share and preserves the remainder on a leftover row.
• If matching logs contain more tokens than the bill, Vantage scales the logged groups down proportionally to the billed amount.
• If a cost row has no matching telemetry, it passes through unsplit.

In every case, the provider bill remains authoritative and total Bedrock cost is unchanged.

13. What permissions are required in Vantage?

An Organization Owner or Integration Owner can connect an AWS Bedrock enrichment source. Viewing enriched costs does not require a special role; the resulting tags follow the same access rules as other cost data.

14. How do I know enrichment is working?

For a connected AWS Bedrock source you can view its import history in the console, including:

• Log Lines Kept: the share of records Vantage successfully read and indexed.
• Tokens Kept: the share of indexed token usage attached to a cost row.
• Bill Match: the share of eligible provider cost rows that received logged usage; it is not the percentage of spend allocated.

Select Tokens Kept to open Token Metrics, which separates Log Scan from Join dispositions and provides sample records for many exclusion reasons. For current-month percentages, Vantage excludes the latest two days while AWS billing catches up, preventing fresh logs from making match rates appear artificially low. For detailed instructions on how to view import history and column descriptions, see the documentation.

15. What happens when I stop or resume a source?

Stopping pauses future enrichment for that bucket without rolling back or deleting already-enriched history. The paused source remains visible. Resuming restarts going-forward enrichment on the next AWS refresh.

16. What if I use Bedrock in multiple accounts or Regions?

Model Invocation Logging is configured per account and Region. Connect the bucket for each account and Region whose usage should be enriched. Vantage supports multiple regional buckets for one AWS account and multiple accounts; each bucket becomes an enrichment source scanned for its configured Region.

17. How can I roll this out across an AWS Organization?

Vantage publishes a reference Bedrock Token Allocation solution in the FinOps as Code repository for multi-account environments. The toolkit uses CloudFormation StackSets to:

• Identify the accounts and Regions where Bedrock has generated spend.
• Create or adopt a regional S3 log bucket.
• Enable Bedrock Model Invocation Logging.
• Add read access to the existing Vantage cross-account role.
• Verify that logs are arriving with the fields Vantage needs.

The solution centralizes deployment rather than log storage: Model Invocation Logging remains configured per account and Region, and each resulting bucket is connected to Vantage as an enrichment source. It refuses to overwrite an existing logging configuration that points to another bucket or CloudWatch destination. Test the template in one account first, then use the included preflight.py and verify.py tools to plan and validate the organization-wide rollout.

18. Do I need to change my application?

Not to continue invoking Bedrock, and not to receive dimensions AWS records automatically. To allocate by custom dimensions such as customer, feature, purpose, or prompt version, the application or a shared client/gateway must attach those values as requestMetadata. Requests that omit metadata still succeed, so teams seeking consistent coverage should add it in a shared invocation layer. Avoid putting credentials, secrets, or unnecessary personal data in metadata.

19. Can I configure this through the Vantage API or Terraform?

The Vantage enrichment source is configured in the Vantage console. AWS-side permissions can be deployed through AWS Console/CloudFormation, the AWS CLI, or Terraform.