亚马逊AWS官方博客
·
基于 Application Inference Profile 为 Amazon Bedrock 构建分业务单元的近实时成本告警
内容提要
本文介绍了一种基于Application Inference Profile的近实时成本告警方案，适用于Amazon Bedrock。该方案通过直接连接Bedrock，利用CloudWatch监控各业务单元的用量，实时计算成本，并通过Lambda函数将告警信息发送至协作工具，具有轻量高效的特点，适合多个团队共享模型时使用。
关键要点
-
本文介绍了一种基于Application Inference Profile的近实时成本告警方案，适用于Amazon Bedrock。
-
该方案通过直接连接Bedrock，利用CloudWatch监控各业务单元的用量，实时计算成本。
-
告警信息通过Lambda函数发送至协作工具，具有轻量高效的特点，适合多个团队共享模型时使用。
-
实现目标的常见做法包括基于账单的方式和代理/网关方式，但都有各自的缺点。
-
方案分为共享层和分BU层，使用通用通知组件，告警信息来源于告警名称和SNS消息体。
-
前置条件包括具备Amazon Bedrock、CloudWatch、SNS、Lambda和IAM权限的AWS账户。
-
部署方案需要使用AWS CloudFormation模板，分为共享基础设施和每个业务单元的栈。
-
成本告警通过metric math表达式计算，CloudWatch每分钟评估一次告警状态。
-
方案不做硬性预算阻断，展示的成本是基于token数和配置的单价估算得出。
-
清理步骤包括删除BU栈和共享栈，确保没有调用方引用被删除的profile。
延伸解读
方案的适用场景
该近实时成本告警方案特别适合多个团队共享Amazon Bedrock模型的场景。通过分业务单元（BU）监控成本，团队可以及时发现异常支出，避免因延迟而导致的预算超支。这种灵活性使得团队能够更好地管理资源，优化成本结构。
技术实现的优势
方案通过直接连接Amazon Bedrock，避免了传统代理或网关方式带来的延迟和单点故障风险。利用CloudWatch的metric math功能，实时计算成本并发送告警，确保团队能够快速响应。这种轻量级的实现方式降低了技术复杂性，适合快速部署和迭代。
注意事项与限制
虽然该方案提供了实时告警功能，但并不具备硬性预算阻断能力。若需要在预算耗尽时拦截请求，仍需结合其他限额方案。此外，BU名称和模型名称的命名规则需遵循特定格式，以确保告警系统正常工作。
延伸问答
什么是基于Application Inference Profile的近实时成本告警方案？
该方案通过直接连接Amazon Bedrock，利用CloudWatch监控各业务单元的用量，实时计算成本，并通过Lambda函数发送告警信息，适合多个团队共享模型时使用。
如何部署基于Application Inference Profile的成本告警方案？
方案通过两个AWS CloudFormation模板部署，首先部署共享基础设施，然后为每个业务单元部署独立栈。
该方案的前置条件是什么？
需要具备Amazon Bedrock、CloudWatch、SNS、Lambda和IAM权限的AWS账户，并安装配置AWS CLI。
如何通过CloudWatch监控成本？
通过metric math表达式计算token数换算成估算成本，CloudWatch每分钟评估一次告警状态。
该方案的告警信息是如何发送的？
告警信息通过一个通用的通知Lambda函数发送至协作工具，如飞书、微信等。
该方案有哪些限制和注意事项？
方案不做硬性预算阻断，展示的成本基于token数和配置的单价估算，BU名和模型名不能包含'-'。
