利用Athena和CUDOS实现Amazon Bedrock成本归属可视化

第 1 部分介绍了 Amazon Bedrock 的细粒度成本归属功能。该功能会自动将每个推理请求追溯到发起该调用的 IAM 主体（IAM principal），展示了新的 line_item_iam_principal 列如何为您提供每位用户和每个应用程序的可见性。结合可选的成本分配标签，您还可以使用 AWS Cost Explorer 按团队、项目或租户聚合支出。通过这种方法，无论第三方工具（如 Claude Code 或 Codex）还是您自己的自定义构建，都可以按照所需的粒度跟踪任何 Bedrock 驱动服务或应用程序的使用情况。本文展示如何通过 Amazon Athena 查询和 CUDOS 仪表板可视化和分析 Amazon Bedrock 的成本归属。

首先，本文将向您展示如何通过包含 IAM 主体数据的 Data Exports 设置 Cost and Usage Report（CUR）2.0。接下来，展示如何用 Amazon Athena 查询 CUR 数据进行分析。然后介绍 CUDOS 仪表板的新功能，包括细粒度的 Bedrock 成本和使用数据。Athena 提供了聚合灵活性以及与不同商业智能（BI）工具和计费流程的集成，而 CUDOS 则提供针对您组织特定结构量身定制的预建可视化。

展示按 IAM 主体和使用类型划分的 Amazon Bedrock 成本的示例查询输出

设置 Cost and Usage Reports（CUR 2.0）

在分析 Amazon Bedrock 成本之前，需要设置 CUR 2.0 数据导出并将其连接到 Amazon Athena。

您需要满足以下条件：

拥有计费控制台访问权限的 AWS 账户。

Cost and Usage Reports、S3 和 Athena 的 IAM 权限。

用于 CUR 数据存储的 S3 存储桶。

基本熟悉 SQL 和 AWS 管理控制台。

（可选）Claude Code 或 Kiro-CLI 用于自动化设置。

确保您拥有所需的 IAM 权限。

对于 Amazon Bedrock 成本归属，您需要在 CUR 2.0 导出中启用 IAM 主体数据，以便填充 line_item_iam_principal 列和关联的 IAM 主体标签。

创建包含 IAM 主体数据的 CUR 2.0 数据导出

按照创建标准数据导出中的说明设置您的 CUR 2.0 导出。配置导出时，确保以下选项属于您的最终配置：

创建启用了调用方身份（IAM 主体）分配数据的 CUR 2.0 标准数据导出

在 Additional export content（其他导出内容）中，选中以下复选框：Include caller identity (IAM principal) allocation data（包含调用方身份（IAM 主体）分配数据）—— 这是关键设置，用于填充 line_item_iam_principal 列，并在成本数据中显示带有 iamPrincipal/ 前缀的 IAM 主体标签。

Include caller identity (IAM principal) allocation data（包含调用方身份（IAM 主体）分配数据）—— 这是关键设置，用于填充 line_item_iam_principal 列，并在成本数据中显示带有 iamPrincipal/ 前缀的 IAM 主体标签。

在 Data table configurations（数据表配置）中：Time granularity（时间粒度）：选择 Hourly 以获得最大详情。

Time granularity（时间粒度）：选择 Hourly 以获得最大详情。

在 Data export delivery options（数据导出交付选项）中：File versioning（文件版本控制）：选择 Overwrite existing report 以避免存储重复数据。

File versioning（文件版本控制）：选择 Overwrite existing report 以避免存储重复数据。

重要提示：启用 IAM 主体数据会增加 CUR 文件大小，因为以前作为单行的使用量现在会展开为多行，每个贡献使用量的 IAM 主体对应一行。对于具有许多不同主体的高吞吐量工作负载，请相应规划您的 Amazon S3 存储，并考虑对较旧的 CUR 文件使用 Amazon S3 Lifecycle 策略。

AWS 可能需要长达 24 小时才能将您的第一份 CUR 2.0 报告交付到 S3 存储桶。

将 CUR 2.0 连接到 Amazon Athena

借助 Amazon Athena，您可以使用标准 SQL 查询 CUR 数据，无需管理任何基础设施。为了简化此设置，有一个可选的 agent.md skill repo 可与 Claude Code、Kiro-CLI 或 Codex 等 AI 助手配合使用。它可以自动化将 Athena 环境连接到 CUR 数据的端到端流程。

克隆仓库（git clone https://github.com/aws-samples/sample-cur-iam-principal-bedrock-tracking）。

在此目录中启动 Claude Code（claude）或 Kiro CLI（kiro）。

提示："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."

您也可以按照手动设置步骤操作。

如果您计划同时部署 CUDOS 仪表板，可以从 AWS CloudFormation 进行部署。这也会在此过程中部署 Athena 查询数据库。

部署完成后，以下是 Athena 查询编辑器中的示例测试查询，您可以使用的：

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;

如果此查询返回带有 IAM 主体 ARN 和 Bedrock 使用类型的行，说明您的设置已完成，可以进行更深入的分析。

用于 Bedrock 成本跟踪的 Athena 查询模式

随着 CUR 2.0 数据在 Athena 中可用，您现在可以使用 SQL 回答细粒度的成本归属问题。本节提供三种渐进复杂的查询模式，涵盖最常见的分析场景。

注意：在以下查询中，将 your_cur_table_name 替换为您的 CUR Athena 表的实际名称（例如 cid_data_export.cur2）。

查询 1：按 IAM 主体和使用类型划分的 Bedrock 成本

此查询按调用方身份和模型使用情况提供 Amazon Bedrock 支出的完整明细。它回答的问题是："谁在调用哪些模型，他们花费了多少？"

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;

使用 LIKE 模式（如 line_item_usage_type LIKE '%Sonnet%output%' 或 %nova%）可以按特定模型进行筛选。

line_item_iam_principal 列包含完整的 ARN。对于代入角色，最后一个 / 之后的会话名称标识特定用户或会话。

查询 2：按已知 IAM 主体标签细分的成本

当您已经使用团队、项目或成本中心等维度标记了 IAM 主体（并将这些标签激活为成本分配标签）后，它们会作为标签列的一部分出现在您的 CUR 2.0 数据中，前缀为 iamPrincipal/，后跟您的标签键。此查询按这些标签对成本进行分组，以回答类似这样的问题："工程团队本月在 Bedrock 上花费了多少？"或者"chatbot 项目的 Bedrock 总成本是多少？"

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;

注意：此查询仅在您的 IAM 主体已使用相关键进行标记且这些标签已被激活为成本分配标签时才会返回结果。

查询 3：使用 UNNEST 进行动态标签发现以应对未知标签架构

在大型组织中，您可能无法提前知道已应用到所有 IAM 主体的标签。不同的团队可能使用不同的标签键，或者随时可能引入新标签。以下示例展示如何动态探索 Athena 的 UNNEST 函数。

此查询发现跨 Bedrock 工作负载使用的所有 IAM 主体标签，并显示每个标签键值对的成本分配：

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;

真实用例：多服务成本比较

考虑一个运行多个 AI 驱动服务的平台团队。例如，团队可能运行一个文档摘要流水线（DocProcessor）和一个面向客户的聊天机器人（ChatApp）。团队可以为每个服务分配各自的 IAM 角色。利用前一部分的查询模式，你可以隔离每个服务的支出趋势，查询如下：

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;

通过此输出，平台团队可以回答以下问题：

哪个应用是本月 Bedrock 支出最大的贡献者？在这个例子中，ChatApp 使用 Claude 4.6 Sonnet 花费超过 80 美元，而 DocProcessor 使用 Nova Lite 的成本不到 5 美元。

我们能否通过为每个工作负载使用不同的模型来降低成本？DocProcessor 已经使用 Nova Lite（适用于简单的摘要任务），但团队可以评估 ChatApp 是否可以使用更轻量的模型处理部分交互，以降低 72 美元的平均输出 token 成本。

Athena 查询费用

你只需为运行的查询付费。根据每个查询扫描的数据量收费。控制台在每次查询后显示此信息，该信息也可以在 Athena 控制台的"最近查询"（Recent Queries）选项卡中找到。

Athena 查询按每 TB 扫描 5 美元收费（每个查询最低 10 MB）。由于我们的表自动对 billing_period 使用 Hive 分区投影，限定单个月的查询仅扫描该月文件夹中的 Parquet 文件。扫描通常远低于 10 MB，费用约为每次查询 0.00005 美元（10 MB 最低消费）。

为保持低成本，始终包含 WHERE billing_period = ... 过滤器，并仅选择你需要的列，而不是使用 SELECT *。

Cloud Intelligence Dashboards 框架

CUDOS 仪表板是开源 Cloud Intelligence Dashboards（CID）框架的一部分，你可以使用提供的基础设施即代码（IaC）模板部署到你的 AWS 账户。该框架帮助你推动财务问责制并提高 AWS 组织内的运营效率。CUDOS 仪表板提供详细且可操作的洞察，支持对 AWS 基础设施成本效率的数据驱动决策。

CUDOS 中的 Amazon Bedrock 成本和使用洞察

CUDOS 5.8 版本在 AI/ML 选项卡中引入了全面的 Amazon Bedrock 部分，支持完整的 IAM 主体成本归属。仪表板提供：

灵活的分组维度：按 IAM 主体、IAM 主体标签（如项目或团队）、模型/资源组、区域或仪表板部署期间配置的任何其他成本分类字段对 Amazon Bedrock 支出进行分组。

每百万 token 成本追踪：叠加在支出图表上的趋势线，显示每百万 token 成本随时间的变化，帮助你衡量模型选择变更或提示优化工作（如缓存）的影响。

下图展示了 CUDOS 仪表板 AI/ML 选项卡中的 Amazon Bedrock 摘要部分，按 IAM 主体分组，包含每个主体的成本明细和每百万 token 成本趋势。

交互式下钻过滤：在顶级支出图表中选择任意值（如特定项目、主体或账户），所有其他可视化会自动过滤到该选择，让你可以从高级概览深入到每个模型和每种使用类型的明细，而无需离开仪表板。

细粒度的模型和使用明细：按顶级图表过滤的其他可视化显示每个模型、每种使用类型以及每个模型的每百万 token 成本支出，帮助你识别哪些模型和 token 类型正在驱动特定团队或项目的成本。

当你将分组切换到 IAM 主体标签"项目"并选择特定项目（此例中为"chatbot-v2"）时，所有其他可视化都会过滤为仅显示该项目的支出。可视化按模型、使用类型和单位成本趋势细分该支出。

通过这些可视化，你可以快速回答以下问题："哪个项目的输出 token 成本最高？"、"我们的聊天机器人团队是否使用了成本效益高的模型？"或"自我们从 Opus 切换到 Sonnet 以来，每百万 token 成本发生了怎样的变化？"而无需编写任何 SQL。

CUDOS 入门

要开始使用 CUDOS，你可以探索交互式演示仪表板中的 Bedrock 部分。按照部署指南在你的组织中设置 CUDOS。

如果你已经在使用 CUDOS，请按照更新指南升级到 5.8 版本。你还可以使用添加组织分类功能将 IAM 主体数据添加到现有的 CUDOS 仪表板。

首先，删除 Athena 表和 AWS Glue 数据库（这些是元数据，因此没有计算在运行）：

警告：删除 Athena 表和 Glue 数据库将移除你查询 CUR 数据的能力。如果你想在未来分析账单数据，你需要按照前一部分的步骤重新创建这些资源。

aws glue delete-table --region us-east-1 --database-name your_cur_table_name --name curexport
aws glue delete-database --region us-east-1 --name your_cur_table_name

其次，如果你不再需要成本数据本身，请在 AWS Billing and Cost Management 控制台的数据导出（Data Exports）下禁用导出，并清空其写入的 S3 前缀。注意这是你的原始账单历史，因此只有在确定时才删除它。

最后，清除积累的所有 Athena 查询结果：

aws s3 rm s3://<your-cur-bucket>/athena-results/ --recursive

没有爬虫、AWS Lambda 函数或计划任务需要删除。分区投影意味着唯一持续产生的成本是 CUR 文件本身的 S3 存储，通常每月只需几分钱。

有关清理 CUDOS，请参阅 CUDOS 仪表板拆除说明。

结论和后续步骤

这个由两部分组成的系列文章完整介绍了一套用于理解和管理 Amazon Bedrock 推理成本的工具包：

第一部分介绍了细粒度成本归属：Amazon Bedrock 如何自动捕获每个推理调用背后的 IAM 主体，以及如何使用成本分配标签按团队、项目或租户聚合支出。

第二部分（本文）展示了如何充分利用这些数据：使用 IAM 主体数据设置 CUR 2.0、在 Amazon Athena 中查询成本模式，以及跨项目和主体比较支出以支持成本分配决策。它还介绍了 CUDOS 仪表板，该仪表板在类似的洞察方面提供了全面的 AI/ML 工作表。

在 AWS Billing 控制台中开启带有调用者身份数据的 CUR 2.0，使用提供的 agent.md 文件将其连接到 Athena，并运行你的第一个按主体分类的成本查询。使用 CUDOS 仪表板追踪整个组织的 Bedrock 采用情况。