Amazon Bedrock for SMBs: profitable use cases and the costs to plan for

Amazon Bedrock crossed a threshold in 2026: a wider model catalog (Nova 2, Anthropic’s latest models, and this year OpenAI models available natively on the platform), AgentCore to orchestrate agents in production, S3 Vectors generally available since December 2025. On paper, an SMB can ship a RAG chatbot or a document-summarization pipeline in a few days.

The tech isn’t the problem — it works. The problem is that a Bedrock bill doesn’t look like any other AWS bill: it mixes token consumption with vector-store infrastructure billed hourly whether you use it or not, plus half a dozen ancillary components you discover on the first invoice. That’s exactly what we audit on Bedrock engagements: the question is never “does this work technically,” it’s “does this use case stay profitable once the real bill is on the table.”

The use cases that are actually profitable for an SMB

Not every GenAI use case is economically equal. Across the engagements we run, three patterns consistently come back with a positive net ROI:

• High-volume document extraction and summarization (contracts, invoices, archived support tickets). Asynchronous processing, no real-time latency constraint: the ideal candidate for batch inference, priced 50% below on-demand. A firm processing 2,000 contracts/month with Claude Haiku in batch mode pays a fraction of an equivalent synchronous run.
• Augmented customer support on an internal knowledge base (RAG over product docs, FAQs, procedures). The business gain is measurable (resolution time, escalation rate), but this is also the use case where infrastructure cost inflates the fastest — more on that below.
• Internal search and business copilots (chat over a company wiki, extraction from SharePoint/Salesforce via Knowledge Bases connectors). Low volume, high perceived value — a good candidate to justify a first Bedrock deployment before scaling further.

Conversely, a one-off, low-volume content-generation use case (marketing drafts, rewriting) often has no reason to go through the full Bedrock stack: a direct API call to the model, with no Knowledge Base or Guardrails, costs less and ships in an hour. It’s the same “pay a third party vs. keep it simple” arbitration we apply everywhere else in FinOps: only stand up managed infrastructure once the volume justifies it.

How Bedrock actually bills you

Three billing modes coexist, and picking the right one is the first optimization lever:

On current on-demand rates, the gap between model families is significant — and that’s often where a use case’s profitability is decided:

• Amazon Nova (the cheapest tier): Micro at roughly $0.035 / $0.14 per million tokens (input/output), Lite at $0.06 / $0.24, Pro at $0.80 / $3.20.
• Claude on Bedrock: Haiku around $1 / $5 per million tokens, Sonnet around $3 / $15, Opus around $5 / $25 — the same rates as the direct Anthropic API; Bedrock doesn’t add a token markup.

A useful reference point: summarizing a 3-page contract (≈4,000 input tokens, 500 output tokens) with Nova Lite costs a fraction of a cent; the same job with Claude Opus costs roughly 30 times more per token. Across 2,000 documents/month, the model choice matters far more than the batch-vs-on-demand choice — there’s no point optimizing the billing mode before picking the right model for the task.

Prompt caching (caching repeated context — system prompt, reference documents reused across calls) adds a further discount of up to 90% on cached input tokens. Worth using as soon as a large shared context (knowledge base, long instructions) serves multiple successive requests.

Pitfall #1: the fixed floor cost of Knowledge Bases

This is the point Bedrock’s documentation doesn’t lead with, and the one we run into most often in audits: creating a Bedrock Knowledge Base for RAG provisions, by default, an Amazon OpenSearch Serverless collection as the vector store — and that collection bills hourly, regardless of traffic.

The technical minimum is 2 OCUs (OpenSearch Compute Units) at $0.24/hour each, or roughly $345/month as a floor — even at zero queries. At the production-recommended configuration (4 OCUs), that climbs to roughly $690/month. For an SMB wanting to pilot a RAG chatbot over a few thousand documents, that floor often exceeds the token cost itself for several months.

Two things worth checking on every engagement:

1. Deleting a Knowledge Base does not delete the underlying OpenSearch Serverless collection. It keeps billing indefinitely until manually deleted — from a different console screen entirely. This is the most frequent “ghost line item” we find on Bedrock bills during audits.
2. S3 Vectors, generally available since December 2025, is now the default alternative to consider. Up to 90% cheaper than OpenSearch Serverless for standard RAG usage, with no fixed hourly floor. Unless you have a specific OpenSearch dependency (advanced hybrid search, complex filtering), it’s the choice that should come first for any new Knowledge Base in 2026.

Other costs to budget before launching

Beyond the vector store, a Bedrock bill aggregates several line items that need pricing out at the scoping stage:

• Retrieval queries: roughly $0.01 per Knowledge Base query, on top of the model cost for generating the final answer.
• Embeddings: billed on document ingestion (input tokens only), re-run every time the corpus is meaningfully updated.
• Bedrock Data Automation (parsing complex documents — scanned PDFs, tables): roughly $0.01 per page.
• Guardrails: content filtering and sensitive-topic detection, billed separately per use.
• Cross-region inference: sometimes required to access certain models or smooth out capacity, with pricing and data-residency implications worth checking — a particular concern for a GDPR-bound SMB.

None of these lines is dramatic on its own. Stacked up without a planned budget, they explain most of the gap between the initial estimate (usually built on token cost alone) and the actual first-month bill.

Bedrock vs. alternatives: when to stay native, when to simplify

Bedrock isn’t always the right level of abstraction. Three trade-offs come up repeatedly on engagements:

• Simple chat, low volume, no sensitive proprietary data → a direct API call to the model (Anthropic or otherwise), with no Knowledge Base or managed infrastructure, is often faster to ship and cheaper as long as volume stays low.
• RAG over a corpus of a few thousand documents, tight budget → S3 Vectors + Bedrock rather than OpenSearch Serverless, or a self-hosted open-source vector store (pgvector on RDS, already present in many SMB stacks) if the team has the skills to operate it.
• High, predictable volume, stable usage over several months → only here does Provisioned Throughput become worthwhile; below a certain volume threshold, the hourly commitment costs more than on-demand.

The case for staying on Bedrock rather than calling APIs directly: compliance and data residency (processing stays inside your AWS account, no additional subprocessor to qualify under GDPR), native IAM integration, and the ability to swap models without rewriting the integration. Those benefits have a price — that’s the price to quantify before you start, not after.

Method: pricing a use case before committing

The sequence we apply during engagement scoping:

1. Estimate real volume (documents/month, requests/day) — not the marketing-pitch peak, the average volume observed over 3 months of real or conservatively projected usage.
2. Pick the cheapest model that meets the quality bar — test Nova Lite/Micro before defaulting to Sonnet or Opus; the per-token price gap is often a factor of 10 to 50.
3. Price the vector store separately from token cost for RAG — S3 Vectors by default, OpenSearch Serverless only if a specific functional need justifies it.
4. List the ancillary line items (retrieval, embeddings, Data Automation, Guardrails, cross-region) and add them to token cost before presenting an estimate to the project sponsor.
5. Revisit at 30 days against the actual bill — not the estimate — to adjust model, billing mode, and vector store configuration.

Conclusion

Bedrock makes generative AI accessible to an SMB with no dedicated MLOps team, and the high-ROI use cases genuinely exist — batch document processing, internal RAG, business copilots. But a Bedrock bill has a fundamentally different structure from an EC2 or RDS bill: it mixes variable per-token cost with fixed infrastructure costs (the vector store chief among them), and the latter can exceed the model cost itself on a low-volume use case.

If you’re planning a Bedrock deployment, or a Knowledge Base is already running without the bill ever having been audited, that’s typically the scope of a Bedrock AI Audit — architecture, vector-store choice, and a cost-reduction plan in two weeks. Let’s start scoping it.