AWS发布Amazon Bedrock成本管理五步操作模型
AWS博客作者Aswath Ram A Srinivasan提出覆盖归因、可观测、预算强制、默认优化和定期复盘的闭环，面向FinOps与平台工程团队，并给出IAM会话标签、请求元数据和网关拦截等具体做法。
AI解读：AWS博客提出管理Amazon Bedrock成本的五阶段循环：把每笔费用归到身份、团队和应用；让每个请求可观测；用预算和强制手段控制支出；优化平台默认设置；建立定期复盘机制。FinOps团队主导第一、五阶段，平台工程团队主导第二至第四阶段，复盘由双方共同进行。
归因依赖Bedrock自动将推理成本记到发起调用的IAM主体，调用方ARN写入CUR 2.0的line_item_iam_principal列。通过单一IAM角色调用Bedrock的LLM网关会丢失按用户可见性，博客建议网关按用户代入角色、以用户名作会话名并附加会话标签，凭证缓存最长一小时。
可观测性方面，Bedrock支持将请求、响应和元数据记录到CloudWatch Logs或S3。博客建议平台团队在共享SDK包装或网关中统一注入请求元数据，因为Bedrock本身不强制元数据，各应用自行填写容易导致字段不一致。
预算强制分三档：仅用AWS Budgets监控告警；用Lambda统计用量并通过共享IAM拒绝策略阻断；在推理路径中放置网关，超限时同步返回HTTP 429。博客称IAM策略阻断需要数秒到数分钟生效，凭证检查则在下次刷新时生效。
优化默认设置的两项手段是模型路由和提示缓存。博客给出的定价示例称，截至2026年10月，Anthropic Claude模型5分钟TTL的缓存写入按基础输入价的1.25倍计费，缓存读取在Sonnet 4.6和Haiku 4.5上为0.1倍、在Sonnet 5.5和Opus 5.5上为0.05倍。
对于代理式编码工作负载，博客称超过一半调用落到更便宜模型是可实现的目标，但该说法没有附公开评测数据。博客建议用调用日志筛出调用次数超过50次且平均输入超过2000 token的工作流，作为缓存候选。
AWS于2026年发布博客文章，由Aswath Ram A Srinivasan撰写，介绍管理Amazon Bedrock成本的五阶段操作模型：归因、可观测、强制预算、优化默认设置和运营复盘。文章面向两类读者：负责归因、分摊、预算和异常审查的FinOps人员，以及负责日志、请求元数据、强制拦截和路由默认值的平台工程团队。
文章称，代理式工作负载每次任务会发起多次模型调用并携带更大上下文，token消耗随工作流自主程度和上下文规模增长，而非随用户交互次数增长。
费用归因：按IAM主体记账
博客称，Amazon Bedrock会自动把推理成本归到发起调用的IAM主体，覆盖所有模型，无需管理额外资源；调用方ARN进入CUR 2.0的line_item_iam_principal列，覆盖IAM用户、角色、联合身份和API密钥。
设置分四步：在CUR 2.0导出中开启IAM主体数据；给IAM主体打上团队、应用、成本中心等标签；联合访问时配置身份提供商通过OIDC或SAML传递会话名和标签；在AWS Billing中将标签激活为成本分配标签。文章称标签在激活后24至48小时出现在Cost Explorer的IAM类别下。
文章特别提到共享角色问题：一个通过单一IAM角色调用Bedrock的LLM网关会把所有费用记到该角色上，丢失按用户可见性。建议网关按用户代入Bedrock调用角色，以用户名作为会话名、用户属性作为会话标签，并缓存凭证最长一小时，即每用户每小时一次STS调用。
- 归因方式覆盖IAM用户、角色、联合身份和API密钥
- 标签激活后在Cost Explorer中需24至48小时出现
- 共享网关场景下，每用户每小时进行一次STS代入角色调用
请求可观测：日志与请求元数据
Blog称，CUR说明谁花了钱，调用日志说明发生了什么。Bedrock支持将请求数据、响应数据和元数据记录到CloudWatch Logs、S3或两者，文章建议用CloudWatch做快速运维查询，用S3加Athena做长期BI分析。
文章建议把日志当作基础设施，用代码创建日志组或存储桶，定义保留和加密策略，并在环境搭建时验证投递。文章称CUR归因约有24小时延迟，而CloudWatch加OpenTelemetry可以支持分钟级的按开发者支出现看板。
对于工作负载级别的归因，文章建议每次调用都写入请求元数据，例如应用、工作流、租户和代理名称，Bedrock会把元数据捕获到调用日志。文章提醒Bedrock不强制请求元数据，平台团队应在共享SDK包装或网关中统一注入，并把元数据覆盖率作为平台健康指标。
- 日志可投递到CloudWatch Logs、S3或两者
- 请求元数据字段包括application、workflow、tenant、agent
- 文章中的查询字段路径为示例，需按实际日志schema核对
预算强制：三档方案与生效延迟
文章列出三档强制方案。第一档用AWS Budgets做阈值告警，不阻断调用，无需部署，但只能在超支后发现问题。第二档由Lambda根据调用日志统计每用户token和美元计数并写入DynamoDB，超限后把该身份加入共享IAM拒绝策略；文章称该方式异步生效，IAM策略更新需数秒到数分钟，凭证检查在下次刷新时生效。
第三档在推理数据路径中放置网关，超限时同步返回HTTP 429，可实现亚秒级阻断、按用户模型白名单和token速率限制。代价是该组件需要部署、扩缩容和安全审查，客户端也要配置为经过网关发送请求。
文章给出选择依据：如果开发者直接调用Bedrock且无代理，只有前两档可行；如果月度支出已达数百万美元，应现在建设强制机制；如果告警还能支撑一个季度，可先投入归因和可观测。文章称多数组织应分阶段推进。
- 第一档：仅告警，无阻断
- 第二档：IAM拒绝策略，异步生效
- 第三档：网关同步拦截，返回HTTP 429
优化默认值：模型路由与提示缓存
文章称Bedrock的大部分浪费来自无人设置的平台默认值，影响最大的两项由平台控制：模型路由和提示缓存。常规补全、lint建议和小重构可路由到更小更便宜的模型，复杂推理保留前沿模型；哪些工作流可以降级需要实测，文章建议拉取工作负载排行，对更便宜模型做质量评估后再路由。
关于提示缓存，文章引用的定价示例称，截至2026年10月，美国东部（弗吉尼亚北部）Anthropic Claude模型的5分钟TTL缓存写入按基础输入价的1.25倍计费，1小时TTL为2倍；缓存读取在Claude Sonnet 4.6和Haiku 4.5上为0.1倍，在Sonnet 5.5和Opus 5.5上为0.05倍。文章提醒乘数因模型和区域而异，应查定价页。
文章称5分钟TTL下单次复用即可覆盖写入成本，对稳定前缀调用十次约为未缓存价格的五分之一；唯一亏损情形是写入后再无读取。
- 代理式编码工作负载中超过一半调用落到便宜模型是文章给出的目标，未附公开评测数据
- 缓存候选筛选条件示例：调用次数超过50次且平均输入超过2000 token
- 缓存读取比例低通常意味着前缀不稳定，例如缓存点前嵌入了时间戳或会话ID
运营循环：四个信号与复盘节奏
文章称前四阶段产出数据，第五阶段把数据转为决策。平台团队运行常设健康看板，跟踪四个信号，其中前两项为模型组合和失败请求率；模型组合衡量路由纪律，失败请求率关注错误、限流和超时。
文章提到，客户端超时但服务端仍完成的请求可能被计费两次。文章称完整看板包含四个信号，但来源文本在第四个信号处被截断。
- 看板信号包括模型组合与失败请求率
- 文章称客户端超时且服务端完成的请求可能重复计费