背景
生成式 AI 的成本管理是應用開發團隊與雲端支出負責團隊的共同責任。隨著代理式工作負載（agentic workloads，指 AI 能自主規劃、讀取檔案、呼叫工具並反覆迭代的流程）的普及，單一使用者互動可能觸發多次模型呼叫，且每次呼叫攜帶更大的上下文（context，指模型處理的對話或資料範圍），導致 Token（模型處理文字的最小單位）消耗量隨工作負載的自主程度與上下文大小而增加，而非僅與使用者互動次數成正比。 AWS ML Blog
發生什麼事
AWS 於 2026 年 10 月 30 日發布《端到端管理 Amazon Bedrock 成本：FinOps 與平台團隊的實務指南》，提出一套可重複執行的營運模型。該模型旨在將每一筆支出歸因於負責人、使每個請求可觀察、在超支前執行預算控制、優化平台預設值以減少浪費，並建立定期審查機制。 AWS ML Blog
重點內容
該指南將成本管理分為五個階段：歸因（Attribute）、觀察（Observe）、執行（Enforce）、優化（Optimize）與營運（Operate）。在歸因階段，Amazon Bedrock 支援將推論成本自動歸因於發起呼叫的 IAM principal（AWS 身份與存取管理中的主體，如使用者、角色或 API 金鑰）。透過在 AWS Cost and Usage Report (CUR) 2.0 中啟用 IAM principal 資料，並為 IAM principal 標記業務維度（如團隊、應用程式），使用者可在 AWS Cost Explorer 中按團隊或成本中心篩選費用。 AWS ML Blog
針對共用角色（shared-role）導致歸因失效的問題，指南建議透過每使用者會話管理來解決。閘道（gateway）應為每個使用者單獨承擔 Amazon Bedrock 呼叫角色，將使用者身份作為角色會話名稱，並將其屬性作為會話標籤傳遞，然後快取這些憑證最多一小時。這樣可在 CUR 2.0 的 line_item_iam_principal 欄位中恢復每個使用者或租戶的可見度。 原文
在觀察階段，Amazon Bedrock 支援將請求資料、回應資料與中繼資料記錄到 Amazon CloudWatch Logs 或 Amazon S3。CloudWatch 適用於快速營運查詢，而 S3 搭配 Amazon Athena 則適合長期商業智慧分析。此外，指南提到自 2026 年 4 月起，Amazon Bedrock 透過 CUR 2.0 支援 IAM principal 成本追蹤，使每個使用者的成本能自動出現在 Cost Explorer 中。 原文
對使用者的意義
此指南適用於 FinOps 從業者與平台工程團隊。FinOps 團隊負責歸因與預算審查，平台工程團隊負責記錄、請求中繼資料、執行機制與路由預設值。透過實施此模型，企業可以將每一美元支出歸因於特定負責人，並在超支累積前發出警報或執行硬性阻擋，從而將成本數據轉化為決策。 AWS ML Blog
限制與未定事項
指南指出，即時配額執行依賴從客戶端發出的遙測數據，而非 AWS 實際計量的成本，因此兩者數字可能存在差異。此外，CUR 歸因數據約有 24 小時的延遲，需搭配 CloudWatch 與 OpenTelemetry 才能實現近即時儀表板。 AWS ML Blog
