Amazon Bedrock tokenomics data lake

If you need an observability data lake for your Amazon Bedrock workloads, you’re not alone. When you’re running thousands of model invocations a day across multiple accounts, after a request is sent you might be wondering, what happened? You can see the aggregate bill, but you can’t see what happened inside each call. You might start to ask questions: what prompt was sent, what the model returned, how many tokens it used, which model handled it, and whether the response was any good! If you’re a platform or machine learning (ML) engineer looking after a fleet of Amazon Bedrock workloads across teams, that’s a real problem. You can’t debug a spike, you can’t spot wasteful prompts, and you can’t tell one team’s usage from another’s. We built something to help: a centralized observability data lake for your Amazon Bedrock invocations. In this post, I cover what native data you have and how we designed the lake. I also show how to use it to see your prompts and derive the per-invocation cost. The AWS CloudFormation templates, AWS Lambda code, and SQL queries are all in the AWS Sample Bedrock Invocation Data Lake GitHub repository. This post walks through the architecture and deployment steps. The repo has everything you need to deploy it. What Amazon Bedrock visibility do you have today? Amazon Bedrock offers model invocation logging, and it’s genuinely powerful. You turn on invocation logs in the settings in each AWS account you are using Bedrock. It delivers a full record of requests and responses to Amazon Simple Storage Service (Amazon S3) or Amazon CloudWatch. The data exists, but it’s locked inside individual accounts. What you really want is a single, fast, queryable view of every invocation across your whole organization. That’s what the data lake gives you. What is the Amazon Bedrock observability data lake? A centralized Amazon Bedrock invocation log data lake pulls raw model invocation logs from your linked accounts into Amazon CloudWatch. Subscription log filters then forward those records to your central account. The central account processes the data through Amazon Data Firehose, and exposes them through Amazon Athena as one clean table you can query across your organization. Figure 1: Amazon Bedrock invocation observability data lake architecture across a central account and linked accounts Everything is deployed as Infrastructure as Code using two AWS CloudFormation templates, so you can roll it out repeatably across every account in your organization. This can be found in the AWS Sample Bedrock Invocation Data Lake GitHub repository. What does each Amazon Bedrock invocation log capture? After we run this solution, you will have a combined set of data across the linked account you deploy to so you can query with Athena. What you get per invocation after the logs are flattened into the processed table: The prompt the user or application sent. The model response that came back. Input and output token counts, so you can measure the true weight of each call. The model used, so you can understand utilization of models across teams. The stop reason (for example, max_tokens), which tells you when a response was cut off. The account and timestamp, so you can attribute and time-slice everything. The AWS Identity and Access Management (IAM) role, so you can see who sent the prompt. After every invocation is captured like this, you go from “We used X tokens on Amazon Bedrock” to “Here is exactly what each model calls contained, and how efficient it was.” That’s the visibility platform and ML teams have been missing. How is the Amazon Bedrock data lake designed? The data lake moves each invocation through five stages, from the moment Amazon Bedrock writes a log to the point you can query it in Athena. 1. Amazon Bedrock writes an invocation log Every time an application calls an Amazon Bedrock model, Amazon Bedrock can record what happened: which model, which account, which IAM identity made the call, how many input and output tokens were used, and the prompt and response text. You turn this on once per account with a single API call, pointing Amazon Bedrock at a CloudWatch log group and giving it a role that can write there. 2. CloudWatch forwards the logs to a central account Each source account gets a subscription filter on its Amazon Bedrock log group. Think of it as a permanent forwarding rule that says “send every new event to this address.” The address is an Amazon CloudWatch Logs destination living in your central account. Source accounts don’t get permissions on the central pipeline. They hand events to the destination, and the central account’s own role takes it from there. 3. A small Lambda tidies each record CloudWatch doesn’t hand over clean JSON. It bundles events into batches and wraps them compressed and encoded, so what arrives looks like gibberish until you unwrap it. A small Lambda function does three jobs: Unwraps the batch back into individual log records. Throws out the noise. CloudWatch sends occasional housekeeping messages and plain-English notices like “Permissions are correctly set for Amazon Bedrock logs.” These aren’t invocation data, and letting them through breaks the next stage. Flattens one awkward field. The caller’s identity arrives nested one level down. The Lambda lifts it to the top so it’s straightforward to query later. 4. Amazon Data Firehose converts to Parquet and writes to S3 Amazon Data Firehose buffers the records and writes them to an Amazon S3 bucket, converting from JSON to Parquet on the way through. Firehose also files each object under a date path (year=2026/month=08/day=27/). 5. Use Athena to query the data and connect it to cost data An AWS Glue table tells Athena how to read those files, so you can query the lake with ordinary SQL. You can see which users are using the most tokens, which models are commonly selected, and what people are prompting. If you want, you can also connect this to the AWS Cost and Usage Report (CUR) to get the spend of user prompts by day. What do you need before you start? A few things need to be in place before you deploy: AWS Command Line Interface (AWS CLI) configured with credentials for each account. CloudFormation CAPABILITY_IAM and CAPABILITY_NAMED_IAM permissions. At least one linked account (the account running your Amazon Bedrock workloads) and one central account to receive the replicated logs (these can be the same account). Python 3 with Boto3 (pip install boto3), for the end-to-end test script. Cloned repo with all the resources in it. How do you deploy it? The order matters here. The central account stack has to exist before the linked account stacks can reference it. Stage 1: Deploy the central data lake stack Deploy the central CloudFormation stack first, into the account that will own the pipeline. Note two values from the stack outputs before moving on: the CloudWatch Logs destination ARN (which every source account needs) and the AWS Quick Sight role ARN (needed later if you deploy the dashboard). Stage 2: Deploy the logging stack in each source account Deploy the linked account CloudFormation. Repeat this for every account running Amazon Bedrock workloads. The source stack is small and takes a single input: the destination ARN from Stage 1. Stage 3: Turn on Amazon Bedrock model invocation logging Deploying the stack doesn’t start the logging. Amazon Bedrock logging is an account-level setting, not a CloudFormation resource. Activate it once per source account, pointing Amazon Bedrock at the log group and the logging role from Stage 2. Turn on CloudWatch delivery only. Stage 4: Verify data is arriving Run a test invocation in a source account, wait for Amazon Data Firehose to flush its buffer (roughly a minute, sometimes longer), then confirm Parquet objects have appeared under the data lake’s data/ prefix. Finally, check your S3 bucket to see data. Stage 5: Create the Athena view and query the data The central stack saves the view definition as a named Athena query but doesn’t run it. Execute that saved query once to create the flattened view. Run queries in the dedicated Athena workgroup, against either the raw table or the flattened view. The view is straightforward: token counts, cache tokens, stop reason, and prompt/response previews are already flat columns. How can you see costs of your Amazon Bedrock tokens? When you want a dollar figure against all of this, join the processed table to your CUR 2.0 data. The join key is the IAM ARN. You can use the following example queries in the Bedrock Data Lake SQL file. That one join turns the observability lake into cost attribution too: which prompts cost the most, cost per team or account by day, and what your least efficient invocations are actually costing you. It’s a great addition, but the data lake earns its keep well before you get there. What is tokenomics and why does this data lake matter for it? Tokenomics, the practice of managing the economics of artificial intelligence (AI) token consumption, was announced as a formal FinOps domain at the 2026 FinOps Foundation conference. It’s built on the same See, Save, Run, and Plan pillars as Cloud Financial Management, but applied to tokens instead of infrastructure. The challenge is that you can’t optimize what you can’t measure. Most organizations today lack the granular data needed to answer basic tokenomics questions: which teams are consuming the most tokens, and which prompts are wasteful. With per-invocation token and cost visibility, teams can match each workload to the model that fits it. That’s exactly what this data lake gives you. With per-invocation visibility into prompts, responses, token counts, models, and IAM identities, you have the foundation to start running a tokenomics practice rather than only tracking an Amazon Bedrock bill. Create an Amazon Bedrock invocation log dashboard If you want to visualize your token consumption, we have an AWS Quick Sight dashboard. This shows you the data from the table over time so you can share it with stakeholders in your organization. Using AWS Quick Sight, you can customize the dashboard and add organization metadata such as team information to make it your own. To deploy this, use the cid-cmd deploy CLI command. Full step-by-step deployment instructions are in the repository README, including AWS Quick Sight role configuration and datasource setup. Figure 2: AWS Quick Sight Amazon Bedrock dashboard What can you now do with Amazon Bedrock invocation logs? With every invocation in one fast, queryable table, you can finally answer questions that used to be a pain: Debug and audit invocations – Pull the exact prompt and response for specific calls, in an account, without digging through raw log files. Measure token efficiency – Compare input_tokens against output_tokens and model choice across teams to find where you’re burning tokens for no reason. Spot prompt engineering opportunities – Find requests where the response was cut off (stop_reason = max_tokens), which is a good sign the prompt or config needs work. Review model families – The data shows which model serves each pattern so teams can confirm each model matches its workload. Govern usage across teams – Each invocation is tied to an account so you know who’s running what. Data governance Because this solution centralizes full prompts and completions from every team into a single Amazon S3 bucket, security and governance are built into the architecture from the start. The bucket is protected by server-side encryption with AWS Key Management Service (AWS KMS), so data is encrypted at rest by default. Access to the bucket and to Amazon Athena query results is controlled through AWS Identity and Access Management (IAM) policies. You can scope permissions to the teams and roles that need them. Prompts might contain personally identifiable information (PII), depending on how your users interact with Amazon Bedrock. We recommend reviewing your IAM policies and Amazon S3 bucket policies to confirm that only authorized principals can reach the data. Clean up If you wish to delete the resources made, empty the buckets of objects then delete the CloudFormation templates. Be mindful to empty the S3 buckets before deleting and delete the Athena Workgroup by hand. You now have a way to turn the raw invocation logs from Amazon Bedrock into a single, fast, org-wide observability layer. Instead of a closed system, you get a clear view of every prompt, response, token count, and model choice across your accounts. When you want it, you also get a direct line to the cost of each one. As with any system project, don’t try to boil the ocean. Start with one or two linked accounts, get comfortable querying the invocations table, then expand across the org. Your Amazon Bedrock usage is only going to grow, so the sooner you build this visibility, the more straightforward every future debugging, efficiency, and cost conversation gets. If you have any questions, or want to share how you’re building observability into your own workloads, visit the AWS Sample Bedrock Invocation Data Lake GitHub repository. About the authors