待翻译：Part 2: Amazon Bedrock cost attribution with Amazon Athena and CUDOS

AI 服务暂时不可用，以下为来源正文，待恢复后补全翻译。

Part 1 introduced granular cost attribution for Amazon Bedrock. This feature automatically traces every inference request back to the IAM principal that made the call. It showed how the new line_item_iam_principal column can give you per-user and per-application visibility. With optional cost allocation tags, you can also aggregate spend by team, project, or tenant using AWS Cost Explorer. With this approach, you can typically track usage at the granularity you want for any Bedrock-powered service or application, whether third-party tools like Claude Code or Codex or your own custom builds. This post shows how to visualize and analyze cost attribution for Amazon Bedrock through Amazon Athena queries and CUDOS dashboards. First, this post shows you how to set up Cost and Usage Report (CUR) 2.0 through Data Exports instrumented with IAM principal data. Next, this post shows you how to query CUR data with Amazon Athena for analysis. It then introduces the new capabilities of CUDOS dashboards, including granular Bedrock cost and usage data. While Athena provides flexibility for aggregations, integration with different business intelligence (BI) tools, and chargeback processes, CUDOS offers pre-built visuals tailored to your organization’s specific structure. Example query output showing Amazon Bedrock costs by IAM principal and usage type Setting up Cost and Usage Reports (CUR 2.0) Before you can analyze Amazon Bedrock costs, set up a CUR 2.0 data export and connect it to Amazon Athena. Prerequisites You need the following: An AWS account with billing console access. IAM permissions for Cost and Usage Reports, S3, and Athena. An S3 bucket for CUR data storage. Basic familiarity with SQL and the AWS Management Console. (Optional) Claude Code or Kiro-CLI for automated setup. Make sure you have the required IAM permissions. For Amazon Bedrock cost attribution, you need to enable IAM principal data in your CUR 2.0 export so that the line_item_iam_principal column and associated IAM principal tags are populated. Creating a CUR 2.0 data export with IAM principal data Follow the instructions in Creating a standard data export to set up your CUR 2.0 export. When configuring the export, make sure the following options are part of your final configuration: Creating a CUR 2.0 standard data export with caller identity (IAM principal) allocation data enabled In Additional export content, select the following checkboxes: Include caller identity (IAM principal) allocation data — This is the critical setting that populates the line_item_iam_principal column and surfaces IAM principal tags (prefixed with iamPrincipal/) in your cost data. In Data table configurations: Time granularity: Select Hourly for maximum detail. In Data export delivery options: File versioning: Select Overwrite existing report to avoid storing duplicate data. Important: Enabling IAM principal data increases CUR file sizes because usage that was previously a single row is now expanded into multiple rows, one for each IAM principal that contributed to the usage. For high-volume workloads with many distinct principals, plan your Amazon S3 storage accordingly and consider Amazon S3 Lifecycle policies for older CUR files. It may take up to 24 hours for AWS to deliver your first CUR 2.0 report to the S3 bucket. Connecting CUR 2.0 to Amazon Athena With Amazon Athena, you can query your CUR data using standard SQL with no infrastructure to manage. To streamline this setup, an optional agent.md skill repo is available that you can use with AI assistants like Claude Code, Kiro-CLI, or Codex. It automates the end-to-end process of connecting your Athena environment to your CUR data. Clone the repo (git clone https://github.com/aws-samples/sample-cur-iam-principal-bedrock-tracking). Launch Claude Code (claude) or Kiro CLI (kiro) in this directory. Prompt: “Read agent.md and follow its workflow to set up Cost and Usage Report tracking and run the Amazon Bedrock-by-principal query for the current month.” You may also follow the manual setup steps. If you plan to deploy the CUDOS dashboard as well, you can deploy it from AWS CloudFormation. This also deploys the Athena query database as part of the process. Once deployed, here is a sample test query in the Athena Query Editor that you can use: SELECT line_item_iam_principal, line_item_usage_type, line_item_unblended_cost --# Note: replace your_cur_table_name, like cid_data_export.cur2 FROM your_cur_table_name WHERE line_item_product_code in ('AmazonBedrock', 'AmazonBedrockService') AND line_item_iam_principal IS NOT NULL LIMIT 10; If this returns rows with IAM principal ARNs and Bedrock usage types, your setup is complete and ready for deeper analysis. Athena query patterns for Bedrock cost tracking With your CUR 2.0 data available in Athena, you can now answer granular cost attribution questions using SQL. This section provides three progressively sophisticated query patterns that cover the most common analysis scenarios. Note: In the following queries, replace your_cur_table_name with the actual name of your CUR Athena table (for example, cid_data_export.cur2). Query 1: Bedrock costs by IAM principal and usage type This query provides a complete breakdown of Amazon Bedrock spending by caller identity and model usage. It answers the question: “Who is calling which models, and how much are they spending?” SELECT line_item_iam_principal, line_item_usage_type, SUM(line_item_usage_amount) AS total_tokens, SUM(line_item_unblended_cost) AS total_cost FROM your_cur_table_name WHERE line_item_product_code in ('AmazonBedrock', 'AmazonBedrockService') AND billing_period = DATE_FORMAT(CURRENT_DATE, '%Y-%m') AND line_item_iam_principal IS NOT NULL -- AND line_item_usage_type LIKE '%Sonnet%input%' GROUP BY line_item_iam_principal, line_item_usage_type ORDER BY total_cost DESC; Example output: line_item_iam_principal line_item_usage_type total_tokens total_cost arn:aws:sts::123456789012:assumed-role/ChatApp/session-1 USW2-anthropic.claude-opus-4-8-mantle-cache-write-tokens-standard 1629.5 $11.2029 arn:aws:sts::123456789012:assumed-role/DocProcessor/batch-7 USW2-Claude4.6Sonnet-output-tokens 68.579 $1.131 arn:aws:sts::123456789012:assumed-role/ClaudeCode/chat USW2-Claude4.6Sonnet-cache-write-input-token-count 831.74 $3.4309 arn:aws:iam::123456789012:user/alice USW2-Claude4.6Sonnet-input-tokens 17.33 $0.0572 Analysis tips: Use LIKE patterns such as line_item_usage_type LIKE '%Sonnet%output%' or %nova% to filter for specific models. The line_item_iam_principal column contains the full ARN. For assumed roles, the session name after the last / identifies the specific user or session. Query 2: Costs broken down by known IAM principal tags When you’ve tagged your IAM principals with dimensions like team, project, or costcenter (and activated those tags as cost allocation tags), they appear in your CUR 2.0 data as part of the tags columns, with the iamPrincipal/ prefix followed by your tag key. This query groups costs by those tags to answer questions like: “How much did the engineering team spend on Bedrock this month?” or “What’s the total Bedrock cost for the chatbot project?” By project: SELECT tags['iamPrincipal/project'] AS project, line_item_usage_type, SUM(line_item_usage_amount) AS total_tokens, SUM(line_item_unblended_cost) AS total_cost FROM your_cur_table_name WHERE line_item_product_code in ('AmazonBedrock', 'AmazonBedrockService') AND billing_period = DATE_FORMAT(CURRENT_DATE, '%Y-%m') AND line_item_iam_principal IS NOT NULL GROUP BY tags['iamPrincipal/project'], line_item_usage_type ORDER BY total_cost DESC; Example output: project line_item_usage_type total_tokens total_cost data-science USW2-Claude4.5Sonnet-cache-write-input-token-count 433.893 1.789808625 data-science USW2-Claude4.6Sonnet-cache-read-input-token-count 5372.659 1.77297747 engineering USW2-Claude4.5Sonnet-input-tokens 29.481 0.0972873 engineering USW2-Claude4.5Sonnet-output-tokens 31.102 0.513183 Note: This query returns results only if your IAM principals have been tagged with the relevant keys and those tags have been activated as cost allocation tags. Query 3: Dynamic tag discovery using UNNEST for unknown tag schemas In large organizations, you may not know in advance which tags have been applied across all IAM principals. Different teams might use different tag keys, or new tags might be introduced over time. The following example shows how to dynamically explore using Athena’s UNNEST function. This query discovers all IAM principal tags being used across your Bedrock workloads and shows cost allocation for each tag key-value pair: WITH iam_principal_costs AS ( SELECT t.key AS tag_name, t.value AS tag_value, line_item_usage_type, line_item_unblended_cost FROM your_cur_table_name CROSS JOIN UNNEST(tags) AS t(key, value) WHERE line_item_product_code IN ('AmazonBedrock', 'AmazonBedrockService') AND line_item_iam_principal IS NOT NULL AND line_item_iam_principal != '' AND t.key LIKE 'iamPrincipal/%' ) SELECT tag_name || ': ' || tag_value AS tags, line_item_usage_type, SUM(line_item_unblended_cost) AS total_cost FROM iam_principal_costs GROUP BY tag_name, tag_value, line_item_usage_type ORDER BY total_cost DESC; Real-world use case: Multi-service cost comparison Consider a platform team running multiple AI-powered services. For example, the team might run a document summarization pipeline (DocProcessor) and a customer-facing chatbot (ChatApp). The team can assign each service to its own IAM role. With the query patterns from the preceding section, you can isolate how the spend for each service trends with the following query: SELECT line_item_iam_principal, line_item_usage_type, SUM(line_item_usage_amount) AS total_usage, SUM(line_item_unblended_cost) AS total_cost FROM your_cur_table_name WHERE line_item_product_code IN ('AmazonBedrock', 'AmazonBedrockService') AND billing_period = DATE_FORMAT(CURRENT_DATE, '%Y-%m') AND line_item_iam_principal IS NOT NULL AND ( line_item_iam_principal LIKE '%DocProcessor%' OR line_item_iam_principal LIKE '%ChatApp%' ) GROUP BY line_item_iam_principal, line_item_usage_type ORDER BY total_cost DESC; Example output: line_item_iam_principal line_item_usage_type total_usage total_cost arn:aws:sts::123456789012:assumed-role/ChatApp/session-1 USE1-Claude4.6Sonnet-output-tokens 4,800,000 $72.00 arn:aws:sts::123456789012:assumed-role/ChatApp/session-1 USE1-Claude4.6Sonnet-input-tokens 2,900,000 $8.70 arn:aws:sts::123456789012:assumed-role/DocProcessor/batch-7 USE1-NovaLite-output-tokens 6,100,000 $1.46 arn:aws:sts::123456789012:assumed-role/DocProcessor/batch-7 USE1-NovaLite-input-tokens 3,200,000 $0.19 From this output, the platform team can answer questions like: Which application is the top contributor to this month’s Bedrock spend? In this example, ChatApp accounts for over $80 using Claude 4.6 Sonnet, while DocProcessor costs under $5 using Nova Lite. Could we reduce costs by using a different model for each workload? DocProcessor is already on Nova Lite (appropriate for straightforward summarization tasks), but the team might evaluate whether ChatApp could handle some interactions with a lighter model to reduce the $72 output-token cost. Cost of Athena queries You pay only for the queries that you run. You are charged based on the amount of data scanned by each query. The console displays this information after each query, and this information is also available in the Recent Queries tab in the Athena console. Athena queries are billed at $5 per TB scanned (with a 10 MB minimum per query). Because our table automatically uses hive partition projection on billing_period, queries scoped to a single month only scan the parquet files in that month’s folder. Scans are typically well under 10 MB, which costs about $0.00005 per query (the 10 MB minimum). To keep costs low, always inclu [truncated for AI cost control]