AWS、Bedrock費用の五段階管理を提示、帰属とログを整えてから予算制御と最適化へ

AWSは10月30日、Amazon Bedrockの費用を管理する五段階の運用方法を発表した。11月1日は本サイトの技術号の日付で、原文の発表日を変更しない。段階は帰属、観測、予算の執行、既定値の最適化、定期的な運用である。これはAWSがプラットフォーム担当者とFinOps担当者へ示した手順であり、本サイトが削減額を実測した報告ではない。エージェントの一つの仕事は多くのモデル呼び出しを含み得るため、利用者との会話回数だけでは費用を捉えられない。

第一段階では支出の持ち主を決める。AWSによれば、Bedrockの推論費用はCUR 2.0の`line_item_iam_principal`列で呼び出したIAM主体へ結び付けられる。主体データをエクスポートし、チームやアプリのタグを付け、費用配分タグを有効化して分析する。Cost Explorerへの表示には有効化後24～48時間かかる場合がある。全員が一つのゲートウェイ役割で呼ぶと、その役割に全費用が集中して利用者別の内訳が消える。原文は利用者ごとに役割を引き受け、セッション名とタグを渡し資格を一定時間再利用する方法を示す。

第二段階では各要求の内容を見えるようにする。CURは請求額の帰属を示すが、一つの要求がなぜ多くのトークンを使ったかは分からない。AWSはモデル呼び出しログを設定し、保存期間、暗号化、配信を確認するよう勧める。アプリ、Workflow、テナントなどの共通metadataを要求に付けることも必要だ。Bedrockはアプリ側にmetadataの記入を強制しないため、共有SDKやゲートウェイで挿入し、欠落率を測る。ログには機密の要求情報が含まれ得る。CURにはおよそ一日の遅延があり、運用ログによる早い推定と最終請求は同じ数字とは限らない。

第三段階の予算制御は三層ある。Tier 1はAWS Budgetsなどの警告で、呼び出しを止めない。Tier 2は利用量からIAMの拒否規則を更新するか、資格の更新時に発行を拒む。制限はできるが非同期で、超過後の規則反映には数秒から数分、資格方式では次の更新までの遅れがある。Tier 3はゲートウェイを推論経路へ置き、限度を超えた時にHTTP 429を同期的に返す。そのため別の重要な構成要素の設置、拡張と安全審査が必要となる。Bedrockへ直接接続するクライアントは、経路を変えずにゲートウェイの同期遮断を得られない。

第四段階はモデル選択、トークン上限、プロンプトのキャッシュという既定値を見直す。安いモデルへの振り分けは実際の作業で品質を検査して決める。キャッシュも安定した共通の先頭部分が再読される時に意味を持つ。AWSが2026年10月の米国東部で挙げた一部Claudeモデルの例では、五分の保存で書き込みは基本入力料金の1.25倍、読み出しはモデルによって0.1倍または0.05倍で、一時間の書き込みは2倍だ。地域、モデル、時期で料金は異なり、永続的な世界共通価格ではない。再読されない先頭部分を書けば、かえって費用が増える。

第五段階ではモデルの組み合わせ、失敗と再試行、キャッシュの読書比、metadataの記入率を定期的に見る。AWSの例示表には開発者一日当たり100ドルと300ドルの区分があるが、同社はこれを各組織が調整する出発点とする。成功した成果一件当たりの費用を考えるべきで、単価だけでは品質低下や再試行の増加が見えない。まず帰属とログを整えるからこそ、超過の原因と最適化の効果を確かめられる。本記事は実際の請求でその効果を再現していない。

AWS の別文書には監査上の前提条件もある。CloudTrail の証跡とイベントデータストアはデータイベントを既定で記録せず、Event history が表示するのは管理イベントだけである。Bedrock のデータ操作を CloudTrail で追うには、該当するデータイベントのセレクターを明示的に設定する必要がある。モデル呼び出しログは別途有効化する情報源で、プロンプトや応答に機密情報が含まれ得る。アクセス、要求、請求、アプリ側の記録を照合し、一つのログだけを完全な監査とみなさない。