Skip to main content
This document explains practical techniques for measuring and controlling Amazon Bedrock spend using AWS Budgets, CloudWatch metrics, and CloudWatch Logs Insights. Follow the diagnostic scenarios and recommendations to identify root causes of cost increases and apply targeted fixes.

​
AWS Budgets: track and alert on spend

AWS Budgets lets you create departmental or cost-center budgets and measure consumption against them. Most organizations implement budgets by tagging resources—virtual machines, containers, Lambda functions, and other services—with cost-allocation tags. Tagging enables you to correlate resource usage to the right budget and generate department-level reports.
Budgets are for tracking and alerting only — they do not enforce or cap spend. For example, a “VM budget” of 1,000willnotstopateamfromspending1,000 will not stop a team from spending 10,000. Budgets can predict overruns and send alerts, but they don’t block consumption.
Best practice: create budgets per product, team, or cost center and make cost-allocation tags mandatory in CI/CD or provisioning pipelines. Combine budgets with alerts to drive early investigation before month-end surprises.
Define as many budgets as needed, assign numeric limits, and apply tags so spending is reported against relevant owners. Budgets are especially useful for chargeback/showback processes and surfacing cost trends to business owners.

​
Monitor Bedrock usage with CloudWatch

Amazon CloudWatch collects metrics for many AWS services, including Bedrock. When you know the cost per token for a given model, CloudWatch metrics such as InputTokenCount and OutputTokenCount allow you to estimate spend at granular intervals (5 minutes, 10 minutes, or hourly). Combine token counts with model pricing to compute estimated spend for each interval and to identify spikes in average token usage.
A screenshot of an AWS CloudWatch metrics dashboard showing graphed InputTokenCount and OutputTokenCount over time and a list of model metrics (e.g., meta.llama3, anthropic models). The image has a large "CloudWatch" title on a dark background.
If you suspect particular requests are driving cost, use CloudWatch Logs Insights to query invocation logs (provided your application or service logs invocation details and token counts). Filter entries by token thresholds to surface the requests that generated the most tokens and therefore the most cost. Example CloudWatch Logs Insights query (adjust field names to match your logs):

​
Diagnostic scenarios and step-by-step guidance

Use the following scenarios to triage unusual or unexpected Bedrock costs. The images below illustrate the investigative workflows. Scenario 1 — Costs doubled over the last week with no traffic increase, no model change, and no deployment changes:
  • Inspect CloudWatch metrics to check token counts per request.
  • If per-request token counts increased, query CloudWatch Logs for model invocation details and token counts.
  • Common root cause: prompts have grown over time, increasing token usage per request.
  • Fixes: reduce prompt size, supply context via Bedrock knowledge bases (document chunking), or tighten output limits to lower generated tokens and preserve budget for necessary inputs.
An infographic titled "Workflow: Scenario 1" showing a four-step timeline diagnosing doubled Bedrock costs. It lists the problem, investigation (CloudWatch metrics/logs), root cause (prompts grew and increased token usage), and fixes (reduce prompt size, use knowledge bases, limit output length).
Scenario 2 — Costs are high even though token usage and request volume look normal:
  • Use CloudWatch metrics and Cost Explorer to drill into dimensions such as modelId, region, and usageType.
  • You may discover the application is using a more expensive model than necessary for routine tasks.
  • Fix: match the model to the task — adopt smaller or more cost-effective models for routine workloads and reserve larger models for tasks that require higher-quality outputs or deeper reasoning.
An infographic titled "Workflow: Scenario 2" that outlines four steps — problem, investigation, root cause, and fix — for diagnosing high costs despite reasonable token usage. It shows investigation tools (CloudWatch, Cost Explorer), identifies using a too-expensive model as the root cause, and suggests switching to a smaller or more efficient model.

​
Quick reference — investigation tools

Tip: instrument your application to log model name, prompt length (tokens), output length (tokens), and requestId. This makes Correlation between metrics and logs straightforward.

​
Expected outcomes from cost-management practices

By implementing these monitoring and control practices you should achieve:
  • Predictable spend as usage grows, reducing surprise end-of-month bills.
  • Engineering teams making conscious model choices (start with smaller models and scale up when necessary).
  • Lower token consumption by trimming prompts and constraining outputs (maxTokens and more focused prompts).
  • Clear visibility into linear costs as user counts increase, enabling better capacity and budget planning.
In short: control tokens and model choice, and you control Bedrock costs.
A presentation slide titled "Key Takeaway" that reads, "Control tokens and model choice, and you control Bedrock cost." The slide has a dark blue left panel, a light gray content area, and a small blue "01" badge.

​
Next steps and references

  • Instrument your application logs to include token counts and model identifiers.
  • Create budgets with cost-allocation tags and set alerts to drive early investigation.
  • Use CloudWatch dashboards and scheduled reports to monitor trends and runbooks for cost incidents.
Links and references: This concludes the short lesson on cost optimization and billing measurement. Additional material covers Bedrock Agents.

Watch Video