Amazon Bedrock Cost Optimization: A Simple Guide to Cutting Your AI Bill
Learn how to reduce Amazon Bedrock costs with model right-sizing, prompt caching, batch inference, service tiers and a 90-day plan to track AI spend by team and application.
AWS FinOps Amazon Bedrock

Amazon Bedrock makes it easier to build generative AI applications through a managed API to foundation models. But as usage grows, costs can become difficult to explain: a longer prompt, a more expensive model, an AI agent that makes extra calls or an underused capacity commitment can all affect your bill.
Effective Amazon Bedrock cost optimization means understanding what drives usage, matching each workload to the right model and service option, and making spending visible by team and application. This guide covers the main cost drivers, practical optimization strategies and a 90-day plan.
Quick answer: To reduce Amazon Bedrock costs, test lower-cost models for routine tasks, shorten prompts and outputs, use prompt caching when prefixes repeat, move eligible background work to batch inference or a suitable lower-cost tier, review committed capacity, keep retrieval lean, limit agent loops and allocate spend to teams or applications. Verify current model availability and pricing on the Amazon Bedrock pricing page before making changes.
Why Amazon Bedrock Bills Surprise Teams
Bedrock removes much of the infrastructure work involved in calling foundation models, but each request can still generate billable usage. Costs may rise when prompts become longer, features add model calls, agents retry tasks, or teams use premium models for work that does not need them.
A token is a small unit of text processed by a model. Billing commonly distinguishes input tokens—the prompt and context sent to the model—from output tokens—the response it generates. Exact rates vary by model, Region and pricing option, so check current AWS pricing.

Key Takeaways
- Use the least expensive model that meets the task’s quality and reliability requirements.
- Reduce unnecessary context and set appropriate response-length limits.
- Choose pricing options according to each workload’s latency and cost needs.
- Evaluate prompt caching and batch inference for eligible workloads.
- Make spending attributable with consistent tags and application-level reporting where supported.
- Recheck pricing and feature availability because models, Regions and rates can change.
How Amazon Bedrock Pricing Works
Bedrock costs depend on the model and Region, how the model is invoked, and any additional services or capacity options used. Separate inference charges from related costs such as storage, retrieval, evaluation, guardrails or customization.
Service tiers and request priorities
Bedrock offers four service tiers for on-demand inference: Reserved, Priority, Standard and Flex. You choose a tier per request with the optional service_tier setting; if you leave it out, the request runs on Standard.
- Standard is the default, at the normal per-token rate.
- Priority carries a 75% premium over Standard and is served ahead of Standard and Flex requests, so it suits latency-sensitive, user-facing features.
- Flex is priced 50% below Standard and suits work that can wait, such as evaluations and background summaries.
- Reserved is capacity you commit to for 1 or 3 months, billed as a fixed price per 1K tokens-per-minute. It has minimum sizes (100,000 input and 10,000 output tokens per minute), traffic above the reservation overflows to Standard, and it is arranged through your AWS account team.
Availability varies by model and Region, so check the service tiers documentation for the model you use.

Do not move every workload to the same option automatically. Match the choice to latency requirements, traffic patterns, supported models and total cost.
Batch inference
Batch inference can fit tasks that do not need an immediate response, such as scheduled summaries, bulk classification, evaluation runs or backlog processing. AWS prices batch jobs 50% below on-demand for selected models from Anthropic, Meta, Mistral AI and Amazon, with results written to Amazon S3. Check eligibility for your exact model in the batch inference documentation.
Provisioned capacity and custom models
Provisioned Throughput is billed per model unit per hour, with no commitment or with 1-month or 6-month terms at a lower hourly rate. Custom Model Import is free to import; you pay for the model copies while they are active, billed per minute in 5-minute windows. Compare commitments and expected utilization with the actual workload baseline.
Customization and supporting services
Fine-tuning, model distillation, evaluations, guardrails and knowledge retrieval can add costs beyond inference. For retrieval-augmented generation (RAG), include the underlying vector store, embeddings and extra context sent to the model. Compare total workflow cost, not token rates alone.
Where Amazon Bedrock Costs Actually Come From
| Cost driver | Why it grows | What to check |
|---|---|---|
| Output tokens | Long responses increase generated-token usage. | Average response length and max-token settings. |
| Context size | Prompts, chat history and retrieved content may be resent. | Prompt size, history window and retrieved chunk count. |
| Model choice | Premium models may handle routine tasks. | Share of traffic on the most expensive models. |
| Agent loops and retries | Each step or retry can create additional calls. | Calls per task, step limits, retries and timeouts. |
| Committed capacity | Capacity may be billed even when underused. | Utilization versus commitment. |
| Vector stores and retrieval | Storage and added prompt context both contribute. | Store type, size, query patterns and retrieved content. |
| Missing ownership tags | Unattributed spend is harder to investigate. | Share of spend assigned to a team or application. |
Illustrative Savings: How to Read the Numbers
The examples below use assumed rates of $1 per million input tokens and $4 per million output tokens. These are illustrative rates, not actual Amazon Bedrock prices, and the results are not forecasts for a real account. Replace the rates with those for your own model, Region and pricing option.
| Scenario | Assumptions | Before | After | Monthly saving |
|---|---|---|---|---|
| A. Support assistant | 250,000 requests, 300 tokens in and 500 out; cap answers at 350 tokens | $575 | $425 | $150 (26%) |
| B. Document Q&A | 100,000 requests, 4,000-token fixed prefix, 500 new tokens in and 400 out; cache the prefix at a 90% discount | $610 | $250 | $360 (59%) |
| C. Overnight summaries | 200M tokens in and 20M out; move from on-demand to batch (50% off) | $280 | $140 | $140 (50%) |
In scenario A, output is $500 of the $575 bill, so trimming answers is the biggest lever. In B, the fixed prefix is identical on every call, so caching it removes most of the input cost; the example ignores cache-write fees, so real savings will be a little lower. In C, quality is unchanged and the work simply runs later. Account for cache-write fees, storage, routing and other associated costs in your own estimates.
10 Ways to Optimize Amazon Bedrock Costs
1. Use the right-sized model for each task
Test lower-cost models for classification, extraction, routing and short Q&A. Keep stronger models for tasks that need their reasoning or output quality. Evaluate with representative prompts and a quality baseline.

2. Match pricing options to workloads
Use latency-sensitive options only where response speed matters. Consider lower-cost options for work that can wait, where supported. Check throttling, latency and quality before changing tiers.
3. Use batch inference for work that can wait
Assess scheduled summaries, bulk classification, content processing and evaluation jobs for eligibility. Confirm supported models, output handling and current prices. Add an S3 lifecycle rule to expire old batch output.
4. Use prompt caching when content repeats
Caching may reduce repeated processing of stable prompt prefixes on supported models. AWS cites up to 90% lower cost and up to 85% lower latency for cached input. Put reusable instructions and reference material in the stable prefix, and changing content later. Check cache lifetime (5 minutes by default, with a 1-hour option on some models), minimum prefix size, hit rate and cache-write costs. See the prompt caching documentation; note that caching applies to on-demand inference, not to batch jobs.
5. Shorten prompts and control response length
Remove redundant instructions, avoid unnecessary conversation history, retrieve only relevant context and set response limits. Keep prompts versioned so changes can be measured.
6. Evaluate intelligent prompt routing
Routing may send simpler requests to less expensive models and harder requests to stronger ones. AWS says it can cut costs by up to 30% without hurting accuracy, and lists routing at $1 per 1,000 requests, so compare the savings with that fee. Test against a fixed-model baseline, verify availability, and measure quality as well as cost.
7. Commit capacity only for predictable demand
Estimate the stable baseline before committing. Compare commitment with on-demand spending, account for overflow behavior and review utilization regularly.
8. Be selective with customization
Try prompt improvements and retrieval before fine-tuning. Run small experiments, include training and hosting costs, and remove unused versions where appropriate. Consider distillation for narrow, high-volume tasks.
9. Keep retrieval-augmented generation lean
Tune chunk size and retrieved chunks so each request includes only relevant information. Compare vector-store options, such as Amazon S3 Vectors for new knowledge bases, and include storage, embedding and inference costs.
10. Set limits on agents and guardrails
Set maximum steps, retry limits and timeouts. Track cost per completed task, not tokens alone. Apply guardrails where they provide value and measure their processing cost. For wider GPU and AI-workload spend, see our guide to GenAI and GPU cost optimization on AWS.
Track Bedrock Spend by Team and Application
Cost visibility is a prerequisite for meaningful optimization. Bedrock supports IAM principal cost allocation (announced in April 2026 and extended to the bedrock-mantle endpoint in August 2026): tag your IAM users and roles, activate the tags as cost allocation tags, and create a CUR 2.0 data export with “Include caller identity (IAM principal) allocation data” turned on. Application inference profiles add a second view by giving each application its own line in cost reports. Follow the AWS guides on IAM principal cost allocation and application inference profiles for the current setup steps. For the wider approach, see our AWS cost allocation guide.
- Use consistent tag keys and values, such as team, application, environment and cost center. Tags are case-sensitive, so mixed spellings split your reports.
- Activate cost allocation tags early. Reporting is not retroactive, and for Bedrock a tag becomes available to activate only after the tagged principal has made at least one API call.
- Use CUR 2.0 and the appropriate Cost Explorer views; the older CUR format does not include the IAM principal fields.
- Use application inference profiles where supported to separate workloads in reporting.
- Set budgets and anomaly alerts; monitor invocation counts, token usage and latency in Amazon CloudWatch.
- Use the AWS Pricing Calculator to estimate proposed changes before deploying them.
A Practical 90-Day Amazon Bedrock Cost Optimization Plan
Days 1–30: See the spend
- Establish a baseline for spend, input/output tokens, cost per feature and calls per completed task.
- Assign owners using tagging and reporting features available in the account.
- Build cost views and set budgets or anomaly alerts.
- Identify the largest workloads and cost drivers before prioritizing changes.
Days 31–60: Reduce avoidable usage
- Trim unnecessary prompt context and set suitable output limits.
- Test prompt caching for repeated prefixes and measure cache-hit rates and associated charges.
- Evaluate batch inference or lower-cost options for eligible background jobs.
- Benchmark lower-cost models on major workloads against a documented quality baseline.
Days 61–90: Validate and sustain savings
- Compare measured costs and quality against the baseline.
- Evaluate capacity commitments only where demand is predictable and the break-even case is supported.
- Pilot routing, retrieval or agent-limit changes where justified.
- Assign an owner to review costs regularly and revisit model choices and prices.
The TruCost.Cloud Perspective
At TruCost.Cloud, we view AI cost control as a visibility and ownership challenge as much as a pricing challenge. Token rates matter, but costs are harder to manage when teams cannot see which application generated them or why a workload uses a particular model or configuration. Our platform is built to make that spend traceable.
- Ownership before optimization: make spend traceable to a team or application.
- Fit the workload, not just the price: meet quality, latency and reliability needs at an appropriate cost.
- Review decisions over time: models, features and pricing can change, so yesterday’s best choice may not remain the best choice.
Start with changes that are easy to measure, compare results against your own baseline and keep the changes that improve cost without compromising the outcome.
Frequently Asked Questions
How is Amazon Bedrock priced?
Mainly per token, with separate rates for input and output, by model and Region. You can also choose a service tier per request, use batch inference at a discount, rent dedicated capacity or import your own model. Features such as guardrails and evaluations can add separate charges. Check the current AWS pricing page for the model and Region you plan to use.
What are the Amazon Bedrock service tiers?
Reserved, Priority, Standard and Flex. Reserved gives committed capacity on 1 or 3 month terms, Priority serves requests faster for a 75% premium, Standard is the default, and Flex costs 50% less for work that can wait. Availability varies by model and Region.
What is the difference between Reserved tier and Provisioned Throughput?
Reserved tier is sold as tokens-per-minute capacity on 1 or 3 month terms, and extra traffic overflows to Standard. Provisioned Throughput is sold as model units billed per hour, with no commitment or 1-month and 6-month terms, and is used to serve custom models.
How much can batch inference save?
AWS lists batch inference at 50% below on-demand pricing for eligible models. Actual savings depend on current rates, eligibility and whether the work can wait for results.
How much can prompt caching save?
AWS cites up to 90% lower cost on cached input and up to 85% lower latency for supported models. Treat this as a maximum, not a guaranteed reduction to your whole bill: real savings depend on model support, how often the same prefix repeats, cache duration and cache-write charges.
How can I track Bedrock spend by team?
Tag your IAM users and roles, activate the tags as cost allocation tags, and use application inference profiles to separate workloads. Then review the results in Cost Explorer or a CUR 2.0 export.
Can I use a custom model with Amazon Bedrock?
Yes. Custom Model Import is free to use; you pay only while model copies are active. Other customization options, such as fine-tuning and Provisioned Throughput, have their own charges, so check the documentation for the feature you plan to use.
What should I do first to reduce Bedrock costs?
Identify the largest workloads and measure cost per feature or completed task. Then test model right-sizing, shorter prompts, caching or batch processing where appropriate, and compare cost and quality against a baseline.
Final Thoughts: Make AI Spend Visible, Measurable and Owned
Teams are better positioned to control Amazon Bedrock costs when they can see spend by application, match each workload to an appropriate model and pricing option, and review decisions as usage and prices change. Start with measurable improvements—limiting unnecessary output, testing caching and batch eligibility, and assigning cost ownership—then expand based on results.
Amazon Bedrock models, features and prices change. Confirm current AWS documentation and pricing for your model and Region before making a commitment.
Ready to Take Control of Your Amazon Bedrock Costs?
Understanding where your AI budget goes is the first step toward improving it. TruCost.Cloud can help your team build visibility into cloud spending, investigate potential waste and make more informed optimization decisions as AI workloads grow.
Review your cloud costs with TruCost.Cloud or contact the team.
Related reading

Why Your Cloud Invoice Keeps Growing While Your Business Stays the Same
Cloud costs can rise even when your business has not changed. Learn how to review compute, storage, non-production environments and old infrastructure using uti…

AWS EC2 T8i Instances: Low-Cost Burstable Compute for AWS Workloads
Learn about AWS EC2 T8i instances, including pricing considerations, specifications, CPU credits, T8i vs T3 performance, use cases, Free Tier availability, and …

AWS Savings Plan Utilization: 4 Steps to Avoid Commitment Waste
Learn how to improve AWS Savings Plan utilization, avoid unused commitment, size plans correctly, and monitor coverage to reduce AWS cloud costs.
See your own bill allocated to 100%
Thirty minutes with a FinOps engineer, on your AWS data if you like. No slideware.