---
type: "post"
id: "amazon-bedrock-tokenomics-data-lake-442b50"
slug: "amazon-bedrock-tokenomics-data-lake-442b50"
title: "Amazon Bedrock tokenomics data lake"
description: "AWS describes a deployable data lake that consolidates Amazon Bedrock invocation logs across linked accounts into an Athena-queryable table."
retrieval_nugget: "AWS describes a deployable data lake that consolidates Amazon Bedrock invocation logs across linked accounts into an Athena-queryable table. It gives platform teams visibility into prompts, responses, token counts, model choices and IAM identities, with an optional join to cost data—useful for debugging and attributing usage beyond the aggregate bill."
published_at: "2026-11-10"
updated_at: "2026-11-10"
record_date: "2026-11-10"
date_kind: "published_at"
topics: ["observability","ai-infrastructure"]
entities: ["Amazon Web Services","Amazon Bedrock","Amazon CloudWatch","Amazon Data Firehose","Amazon Athena","Amazon S3","AWS Glue","AWS Cost and Usage Report"]
related_patterns: ["agent-economics-moves-to-completed-work"]
novelty_label: "new_fact"
what_changed: "AWS presents a tutorial for building a data lake to monitor Amazon Bedrock token usage and costs."
prior_refs: ["https://newruntime.com/posts/from-data-to-decisions-conversational-supply-chain-intelligence-b8bdf2/"]
source_url: "https://aws.amazon.com/blogs/machine-learning/amazon-bedrock-tokenomics-data-lake"
source_urls: ["https://aws.amazon.com/blogs/machine-learning/amazon-bedrock-tokenomics-data-lake"]
schema_version: "newruntime-agent-readable-v0.2"
stable_id: "post:amazon-bedrock-tokenomics-data-lake-442b50"
status: "published"
visuals: []
editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]}
routes: {"html":"https://newruntime.com/posts/amazon-bedrock-tokenomics-data-lake-442b50/","markdown":"https://newruntime.com/posts/amazon-bedrock-tokenomics-data-lake-442b50.md","json":"https://newruntime.com/posts/amazon-bedrock-tokenomics-data-lake-442b50.json"}
markdown_url: "https://newruntime.com/posts/amazon-bedrock-tokenomics-data-lake-442b50.md"
---

# Amazon Bedrock tokenomics data lake

## Retrieval answer

AWS describes a deployable data lake that consolidates Amazon Bedrock invocation logs across linked accounts into an Athena-queryable table. It gives platform teams visibility into prompts, responses, token counts, model choices and IAM identities, with an optional join to cost data—useful for debugging and attributing usage beyond the aggregate bill.

## Summary

AWS describes a deployable data lake that consolidates Amazon Bedrock invocation logs across linked accounts into an Athena-queryable table. It gives platform teams visibility into prompts, responses, token counts, model choices and IAM identities, with an optional join to cost data—useful for debugging and attributing usage beyond the aggregate bill.

## What happened

AWS's announcement presents a centralized observability design for organizations running Amazon Bedrock in multiple AWS accounts. Bedrock's native model invocation logging can send full request and response records to S3 or CloudWatch, but AWS says those logs otherwise remain within individual accounts. Its sample solution gathers the logs into a central account and exposes a combined view for cross-organization queries. The CloudFormation templates, Lambda code and SQL queries are published in the AWS Sample Bedrock Invocation Data Lake repository.

The pipeline begins with Bedrock invocation logging enabled in each source account. CloudWatch Logs subscription filters forward new records to a destination in the central account. A Lambda function unwraps batched, compressed events, removes housekeeping messages and flattens a nested caller-identity field. Amazon Data Firehose then converts the records from JSON to Parquet and writes them to S3, organized by date. AWS Glue describes the files to Athena, where SQL queries can run against a raw table or a flattened view.

The processed table can include the prompt, model response, input and output token counts, model, stop reason, account, timestamp and IAM role. AWS says these fields can help teams investigate individual calls, compare token use across models and teams, and find responses cut off by a `max_tokens` stop reason. To estimate spend, the post shows joining the table to AWS Cost and Usage Report 2.0 data using the IAM ARN as the key. The resulting analysis can attribute spend by prompt, team or account and day.

Deployment requires AWS CLI credentials for the accounts, CloudFormation IAM capabilities, at least one Bedrock workload account and one central account (which may be the same), Python 3 with Boto3 for the end-to-end test, and a clone of the repository. AWS says to deploy the central stack first, then a small linked-account stack in each source account, and then enable Bedrock logging separately in each account; deploying the stacks alone does not start logging. After a test invocation, Firehose may take roughly a minute or longer to flush data. AWS also describes an optional Quick Sight dashboard that can be customized with organization metadata.

## What the archive adds

New Runtime's earlier coverage described Amazon Bedrock AgentCore cases where agents extract and verify contract fields, and where governed evidence supports supply-chain questions and human-approved action: [the contract intelligence case](https://newruntime.com/posts/building-an-ai-powered-contract-intelligence-platform-with-7ab3d6/) (2026-09-30) and [the supply-chain intelligence case](https://newruntime.com/posts/from-data-to-decisions-conversational-supply-chain-intelligence-b8bdf2/) (2026-10-22). This is a new operational data-lake design, not a restatement: it focuses on invocation-level observability and cost attribution rather than an application workflow.

## Trend signal

This supports the shift toward workload-level economics rather than treating aggregate model bills or token totals as sufficient. Per-invocation records and a cost join could help teams compare completed work and usage, but AWS's post does not report measured savings or cost per verified task. The connection to [agent economics moves to completed work](https://newruntime.com/patterns/agent-economics-moves-to-completed-work/) is therefore an enabling signal, not proof that the economic unit has shifted.

## Why now

AWS frames the design around organizations running thousands of Bedrock calls a day across multiple accounts, where a bill alone cannot explain what happened inside each call. It also says tokenomics was announced as a formal FinOps domain at the 2026 FinOps Foundation conference. The timing reflects growing demand to observe and allocate model usage, not a newly announced Bedrock logging capability.

## Why it matters

For teams operating Bedrock across departments, the useful change is the ability to ask operational questions at invocation level: which model handled a request, who sent it, how many tokens it consumed, and whether it was cut off. Joined to cost data, those records can make cost allocation and model-selection reviews more specific than looking at a monthly account bill. The sample also exposes a trade-off that should shape deployment: centralizing prompts and completions makes debugging easier but expands the sensitivity and reach of logged data. Teams need to decide which workloads should be logged, who can query records, and how long to retain them before using a shared lake as an organization-wide default.

## Limits and uncertainty

AWS presents an architecture and sample implementation, not measured results from a production deployment. The post gives no observed throughput, operating cost, retention period, or quantified savings from prompt optimization. Invocation logging must be enabled per account, and the described pipeline centers on CloudWatch delivery. The logs contain full prompts and responses, which may include personally identifiable information; AWS recommends restricting S3 and Athena access, but the post does not establish that the design meets any particular organization's compliance requirements. The cost join also depends on the organization's CUR 2.0 data and IAM attribution practices.

## Skill to build now

Pick one Bedrock workload and deploy the sample into a central account plus one linked account. Enable invocation logging explicitly, send a test call, and verify that a Parquet object arrives in S3 and the Athena view returns the expected token counts and IAM identity. Before expanding, review whether prompts can contain personal or confidential data, then scope bucket and query-result access to the smallest set of roles that need it.

## Reader takeaway

A Bedrock bill can tell a team how much it spent; invocation-level logs can show what the calls were, who made them, and which models and prompts drove usage. AWS's sample supplies a path to that visibility, but it does not remove the work of enabling logging, controlling sensitive records or validating whether cost allocation is accurate.

Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- topic hub: [Observability](https://newruntime.com/topics/observability.md): Explore the observability topic hub.
- topic hub: [Ai Infrastructure](https://newruntime.com/topics/ai-infrastructure.md): Explore the ai-infrastructure topic hub.
- collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis.
- collection: [Sources](https://newruntime.com/sources/): See the original sources this archive cites.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)