【要約】Bedrockチャットボットを公開する前に、月額上限を自前で実装した話 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が、認証なしの状態でBedrockチャットボットを公開する際、悪意のあるリクエストによるコスト暴走のリスクに直面した。具体的には、以下の課題が存在する。
- ・Bedrockには、一定額に達した際に自動停止するアカウント単位の機能が存在しない。
- ・AWS Budgetsは通知のみであり、個人のデモ用途には設定が重すぎる。
- ・リクエスト回数のみの管理では、会話の長さに依存するトークンコストを正確に制御できない。
// Approach
開発者は、瞬間的な流量制限と、累積コストに基づく総量制限という、二段構えの防御策を採用した。
- ・API Gatewayのスロットリング設定により、ルート単位で秒間リクエスト数を制限した。
- ・Lambdaの予約済み同時実行数を設定し、並列実行によるリソース消費を抑制した。
- ・Converse Stream APIのmetadataからトークン使用量を取得し、DynamoDBで実コストを積算した。
- ・Bedrock呼び出し直前に、積算コストが予算を超えていないかを判定するロジックを実装した。
// Result
開発者は、最小限の工数で、実用的なコスト管理とUXの両立を実現した。
- ・スロットリングにより、秒間数百リクエスト規模の攻撃を物理的に遮断できる。
- ・トークンベースの積算により、会話の長さに依存するコスト変動を考慮した管理が可能になった。
- ・予算超過時、システムエラーではなくキャラクターの応答として伝えるUXを構築した。
Senior Engineer Insight
> 本実装は、個人開発における「コスト暴走への恐怖」を、最小工数で解消する極めて実践的な手法だ。厳密な整合性を一部犠牲にしつつ、スロットリングで被害を最小化する設計は、スピード重視の現場において合理的である。ただし、商用環境ではConditionExpressionによる厳密な整合性確保や、単価管理の自動化を検討すべきだ。