Amazon Bedrock now has a reference pattern that pulls raw invocation logs from every linked account into a central data lake, exposing the combined data through Athena. Engineers can query per‑invocation prompts, model responses, token counts, and timestamps without manually stitching together siloed S3 buckets or CloudWatch streams.
Why Centralized Visibility Matters
When thousands of model calls run across teams, the default per‑account logging only shows aggregate spend. Without a unified view you cannot trace a spike to a specific prompt, identify wasteful token usage, or separate one team’s consumption from another’s. The data lake fills that gap by delivering a fast, SQL‑compatible surface that includes the exact input and output tokens for each call.
Architecture Overview
The solution relies on three native Bedrock features: model‑invocation logging, delivery to Amazon S3 or CloudWatch, and subscription log filters. Each source account enables logging and forwards the records via a CloudWatch subscription filter to a central account. In the central account a Kinesis Data Firehose delivery stream normalizes the payloads and writes them to a curated S3 bucket. Athena then reads the bucket as a single table, exposing columns for prompt, response, input tokens, output tokens, model identifier, stop reason, account ID, and timestamp.
All components are provisioned with two AWS CloudFormation templates, making the deployment repeatable across any number of accounts. The GitHub repository referenced in the original post contains the templates, Lambda code for any required transformation, and sample Athena queries.
Implementation Steps
- Enable Bedrock invocation logging in every account that runs models, selecting S3 or CloudWatch as the destination.
- Deploy the subscription‑filter stack to each source account; the filter forwards matching log events to the central account’s Firehose.
- In the central account, launch the Firehose and S3 bucket stack. The stack creates the delivery stream, the target bucket, and the Athena database/table definition.
- Run the provided Athena queries to verify that prompts, token counts, and model names appear as expected.
Operational and Security Considerations
Because the lake stores raw prompts and model responses, the data may contain proprietary or sensitive information. Practitioners should enforce strict IAM policies on the central S3 bucket and Athena workgroup, enable server‑side encryption, and consider lifecycle rules to purge data after the required retention period.
Cross‑account log forwarding introduces additional IAM roles: source accounts need permission to publish to the central Firehose, and the central account needs permission to assume roles in the sources for subscription filters. Review these trust relationships to avoid over‑privileged access.
Operationally, monitor Firehose delivery success metrics and Athena query costs, especially if the lake ingests high‑volume logs. Adjust partitioning (e.g., by date and account) to keep query latency low and cost predictable.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
Adopting the Bedrock observability data lake gives you concrete, token‑level insight across the entire organization, turning opaque spend into actionable data. Deploy the CloudFormation stacks, secure the central bucket, and start querying with Athena to debug prompts, allocate costs, and enforce usage policies. The next step is to define retention, partitioning, and access controls that match your compliance and cost‑management goals.
