AWS Bedrock Production Cost: What You Will Actually Pay in 2026

AWS Bedrock cost in production is not a single model-rate calculation. A credible forecast combines input tokens, output tokens, caching, retrieval, orchestration, storage, logging, and the traffic pattern your application must survive. At 1 million requests, a small change in average prompt size or response length can move the monthly bill materially.

KUMO runs CampaignHQ on AWS at production scale, with more than 50 million messages delivered. That experience shapes how we forecast AI systems: start with the unit economics of one successful task, then model normal traffic, peak traffic, failure retries, and non-model infrastructure separately.

Pricing snapshot: The model figures below were checked against the official AWS Bedrock pricing page on 13 July 2026. AWS changes rates, regions, model availability, and promotional terms. Recheck the live AWS page before approving a budget.

If you need a workload-specific estimate rather than a token spreadsheet, Book a 60-Min AI Scoping Session. KUMO will map the workload, region, model options, integrations, evaluation plan, and operating controls.

The short answer

For an on-demand text workload, use this base formula:

monthly model cost = input token cost + output token cost + cache writes + cache reads + retry overhead

Then add the cost of:

• knowledge retrieval and embeddings;
• object and vector storage;
• Lambda, containers, queues, or workflow orchestration;
• API Gateway and network transfer where applicable;
• CloudWatch logs, traces, evaluation jobs, and alerts;
• security controls, secrets, backups, and data retention;
• engineering support and incident response.

The model can be the largest line item, but it is not always the largest. Retrieval-heavy systems may spend heavily on indexing and storage. High-volume support systems may spend more on observability, data processing, and downstream integrations than a simple token estimate suggests.

Current Claude pricing examples on Bedrock

AWS listed the following rates when this pricing snapshot was prepared:

AWS states that the Claude Sonnet 5 promotional rate applies through 31 August 2026, after which its stated standard rate takes effect. The table is a planning snapshot, not a quote. Region, access mode, batch processing, latency options, and model lifecycle can change the answer.

A worked token example

Assume 100,000 monthly tasks, each using an average of 3,000 uncached input tokens and 600 output tokens. At $3 per million input tokens and $15 per million output tokens:

• Input: 300 million tokens × $3 = $900
• Output: 60 million tokens × $15 = $900
• Base model total: $1,800 per month

That excludes retries, cache operations, retrieval, infrastructure, and logs. If 8% of tasks retry once, add the tokens consumed by those retries. If a long system prompt is reused on every request, caching may materially reduce repeated-input cost, but only when the cache hit rate and request timing support it.

Before committing to a model or region, Book a 60-Min AI Scoping Session to pressure-test the request volume, token distribution, cache assumptions, and fallback architecture.

Prompt caching: forecast the hit rate, not the marketing claim

Prompt caching can reduce repeated processing of stable context such as system instructions, policy text, tool definitions, or a large shared document. It also introduces separate write and read rates.

Model these four values:

1. Cacheable tokens per request. Separate stable text from dynamic user and retrieved context.
2. Cache write frequency. A cache that is rewritten too often can erase the expected saving.
3. Cache hit rate. Traffic must arrive within the applicable cache window and reuse the same prefix.
4. Read-to-write ratio. The economics improve when many reads reuse each write.

For example, if 2,000 of 3,000 input tokens are stable and reused, the uncached portion is only 1,000 tokens per request. But do not apply a flat percentage reduction to the whole AI bill. Output tokens, retrieval, workflows, and observability are unaffected by prompt caching.

On-demand, batch, reserved, and provisioned capacity

On-demand

On-demand inference is the simplest starting point for variable traffic. You pay according to usage and avoid a capacity commitment. It is usually appropriate for pilots, company tools, and workloads with unpredictable demand.

Batch

Batch processing can suit offline classification, summarisation, enrichment, and back-office jobs where immediate response is unnecessary. AWS publishes model-specific batch rates. The trade-off is latency and workflow complexity, not just a lower token figure.

Reserved tier and latency-optimised inference

AWS presents reserved and latency-focused options for supported models. These make sense when traffic is steady enough to justify a commitment or when response-time requirements are commercially important. Ask for a workload-specific quote rather than converting an on-demand estimate into a capacity estimate yourself.

Provisioned throughput

Provisioned throughput allocates model capacity for supported cases. AWS directs customers to their account team for some provisioned pricing. Consider it only after load tests establish request rate, token distribution, concurrency, latency target, and seasonal peaks.

Three illustrative production cost profiles

These are planning scenarios, not client invoices or vendor quotes.

Scenario 1: operations assistant

Workload: 12,000 tasks per month, 4,000 input tokens and 700 output tokens per task, moderate retrieval, business-hours usage.

Likely cost drivers:

• token usage is relatively small;
• document ingestion and vector storage are modest;
• logs can become wasteful if full prompts and responses are retained indefinitely;
• identity, permissions, and audit history matter more than raw scale.

A sensible architecture starts on demand, applies strict retention, and measures cost per accepted answer rather than cost per generated answer.

Scenario 2: customer-support copilot

Workload: 250,000 tasks per month, 5,000 input tokens and 500 output tokens, high prompt reuse, CRM and helpdesk integration.

Likely cost drivers:

• repeated policy and tool context makes caching worth testing;
• retrieval quality affects both token count and resolution rate;
• retries, tool failures, and human escalation create hidden work;
• support analytics and quality evaluation add processing and storage.

The useful business unit is cost per resolved or correctly escalated case. A cheaper model response that creates more support-team rework can be the expensive option.

Scenario 3: multi-market AI workflow

Workload: 1.5 million tasks per month, 6,000 input tokens and 900 output tokens, multiple languages, peak events, strict monitoring.

Likely cost drivers:

• model usage becomes substantial;
• peak concurrency may shape the capacity decision;
• routing simple tasks to a lighter model can matter;
• regional architecture, security, retention, and incident controls add cost;
• a small retry-rate increase produces a large token increase.

At this scale, run load tests and evaluate model routing before negotiating capacity. Track cost by workflow, tenant, market, and model rather than one blended AWS total.

If one of these profiles resembles your workload, Book a 60-Min AI Scoping Session and turn it into a production forecast with peak, retry, retrieval, monitoring, and support assumptions.

Costs a Bedrock calculator often misses

Retrieval and data preparation

A RAG system needs document parsing, chunking, embeddings, indexing, refresh jobs, access controls, and deletion workflows. Poor retrieval can also increase prompt size because teams compensate by sending more context.

Tool calls and downstream systems

A production assistant may read from a CRM, create a ticket, update an ERP, or call a payments service. Each integration needs authentication, timeouts, retries, idempotency, and audit logs.

Evaluation and quality monitoring

Teams need test sets, regression checks, human review, error classification, and model-change evaluation. Without them, the first indication of a quality problem may be a customer complaint.

Logging and retention

CloudWatch and storage costs can grow quickly when every prompt, retrieval result, tool payload, and response is retained. Decide what is operationally necessary, what contains personal data, and how long each class should live.

Failure and retry overhead

Forecast timeouts, throttling, invalid tool outputs, and downstream API failures. A retry policy without limits can multiply both token spend and customer latency.

Bedrock versus a direct model API

Do not compare token prices alone. Bedrock can be attractive when your organisation values AWS identity controls, procurement, regional architecture, monitoring integration, and access to multiple model providers. A direct API can be attractive when it offers a needed feature, release timing, or commercial term.

Use a weighted decision table:

Read KUMO's AI infrastructure service, AI integration service, AI workflow automation service, custom software development approach, and CampaignHQ case study for related production patterns.

For adjacent planning decisions, use KUMO's AI implementation roadmap, AI chatbot development cost guide, AI automation approval workflow guide, custom software ROI guide, and AI development partner checklist.

Implementation investment versus AWS run cost

Do not mix the cloud bill with the implementation investment. AWS consumption is an operating cost. Discovery, product design, integrations, evaluation, security, deployment, and production support are engineering work.

• A focused Starter Build has a typical investment of $15K to $50K and usually takes 4 to 16 weeks.
• A Grow Build for a production AI workflow has a typical investment of $50K to $100K and usually takes 16 to 24 weeks.
• Larger multi-workstream systems can take 24+ weeks. The final quote follows workload and integration scoping.

The smallest responsible release is usually one workflow with measurable business value, defined approval boundaries, and a cost-per-accepted-outcome metric. It should prove the architecture before the team scales traffic or commits to reserved capacity.

What to Do This Week: A Six-Step Bedrock Cost Forecast

1. Define the task. Specify a successful output and the human fallback.
2. Measure tokens from real samples. Averages alone hide expensive long-tail requests.
3. Model traffic. Include normal volume, peak concurrency, seasonality, and retries.
4. Add the surrounding stack. Include retrieval, storage, compute, APIs, logs, and security.
5. Run a controlled load test. Validate latency, quotas, failure behaviour, and cache hit rate.
6. Set budget alerts by workflow. A blended account alert arrives too late to explain the cause.

If you want an architecture and cost model before committing to production, Book a 60-Min AI Scoping Session. We will map the workload, integrations, evaluation plan, and operating cost drivers.

Proposal Review Questions for AWS Bedrock Projects

How is AI evaluated?

The proposal should define test cases, expected answer quality, confidence thresholds, failure scenarios, and the review cadence for model or prompt changes.

What can AI do automatically?

The proposal should separate safe automated actions from prepared responses, recommendations, and decisions that still need human review.

What requires human approval?

High-risk actions involving customer records, payments, permissions, compliance, or irreversible system changes should have explicit approval queues and audit trails.

What happens after launch?

The proposal should name the owner for monitoring, drift, cost anomalies, model updates, integration failures, incident response, and ongoing evaluation.

Questions engineering leaders ask

Is AWS Bedrock charged per request or per token?

Text-model on-demand pricing is generally based on input and output tokens, while other model types and capabilities can use different units. Always check the exact model table and region.

Does prompt caching always reduce Bedrock cost?

No. It helps when a meaningful stable prefix is reused often enough to justify cache writes. Low reuse or frequent changes can reduce the benefit.

When should we consider provisioned throughput?

After load tests show stable high demand, known concurrency, and a latency or capacity requirement that on-demand operation does not meet economically.

What should a production estimate include beyond model tokens?

Retrieval, storage, compute, orchestration, integrations, security, logging, evaluation, monitoring, retries, support, and data-retention obligations.

Can KUMO provide a fixed AWS bill before discovery?

No responsible team can quote a reliable bill without workload data. KUMO can build a forecast from sample traffic, token distributions, integrations, retention, and performance requirements.

How often should we refresh the forecast?

Refresh it after model or prompt changes, major traffic changes, new integrations, pricing updates, and at least monthly during early production.

Make the cost model operational

A Bedrock estimate is useful only when it becomes a production control. Instrument cost per workflow, accepted outcome, tenant, and model. Add alerts for token growth, cache misses, retry spikes, and unusually long outputs. Review those signals alongside quality and business outcomes.

KUMO builds production AI and custom software for growing businesses. If your Bedrock workload needs architecture, integration, load testing, and cost controls rather than only a spreadsheet, Book a 60-Min AI Scoping Session.

Book a 60-Min AI Scoping Session to discuss your Bedrock production plan.