Bedrock vs OpenAI cost — the real per-token math (2026).

IHow each platform charges — the shape of the bill

Before any numbers, get the billing model straight, because the two are more similar than most "X vs Y pricing" posts admit. Both Amazon Bedrock and the OpenAI API are usage-priced per token, metered separately for input and output, with the rate set by the specific model — so the structure is comparable and the differences live in model choice, discount levers, and a handful of surrounding costs.

Both bill per token, input and output priced separately. You pay for tokens in (your prompt: system instructions, retrieved context, conversation history, the user message) and tokens out (the model's response), at a per-model rate usually quoted per 1,000 or per 1,000,000 tokens. Output tokens are typically priced higher than input tokens on both platforms — often 3–5× — which is why long, verbose responses cost disproportionately more than long prompts.

On-demand is the default on both. Call the API, pay for what you used, no commitment. Amazon Bedrock calls this On-Demand; OpenAI's standard API is the same pay-as-you-go shape. This is where almost everyone starts, and where the per-token rates below apply.

Both add the same families of discount lever. A batch tier for non-urgent, asynchronous work at roughly half the on-demand rate (Bedrock Batch ~50% off; OpenAI's Batch API similarly discounted). Prompt caching to avoid re-billing the same repeated context (long system prompts, fixed instructions, reused documents) on every call — available on both. And a steady-capacity option for predictable high volume — Bedrock Provisioned Throughput (reserve model units, billed hourly/monthly) and OpenAI's committed/scale arrangements.

Where the bills diverge is mostly outside the per-token rate. Bedrock, being an AWS service, can carry adjacent AWS charges for the architecture around the model (Knowledge Bases storage and the vector store, fine-tuning/customization and custom-model storage, the Lambda/compute and data transfer in your app). OpenAI bundles more of its higher-level features into its own pricing and adds its own line items (for example, hosted retrieval/file storage and certain tool calls). Section VI breaks these "hidden costs" down on both sides. And one difference is not a fee at all but who you pay — which, as Section VII shows, is what makes Bedrock creditable and OpenAI not.

IIMapping comparable models: Claude and Nova vs GPT tiers

You cannot compare "Bedrock vs OpenAI" on cost without first deciding which models you are actually putting head to head — comparing a frontier model on one side to a small model on the other is the most common way these analyses go wrong. The fair method is to line up models by capability tier and price like-for-like.

On the OpenAI side you have a single provider's ladder: a small/cheap tier for high-throughput and simple tasks, a mid/standard tier that balances cost and capability, and a flagship/reasoning tier for the hardest work, plus specialized embedding, image, and audio models. On the Bedrock side you have many providers' ladders in one catalog — the relevant ones for a cost comparison are usually Anthropic's Claude family (a fast/cheap Haiku-class tier and a balanced Sonnet-class tier, with a top-end Opus-class tier for the hardest tasks) and Amazon's Nova family (Micro / Lite / Pro — explicitly positioned as low-cost, low-latency), alongside open-weight options like Llama and Mistral.

The practical mapping most teams use: put a small GPT tier against Claude Haiku or Amazon Nova Lite/Micro; put a mid/standard GPT tier against Claude Sonnet; and put a flagship/reasoning GPT tier against Claude Opus-class. Nova Micro and the smallest open-weight models often sit a notch below the cheapest GPT tier on price, which is exactly why high-volume, latency-sensitive workloads frequently route to Nova on Bedrock.

The candid caveat: the frontier ranking changes with every release, and "comparable" means comparable on your evaluation set, not on a leaderboard. The right way to decide is to take the two or three models you would realistically deploy, run them on your own prompts and quality bar, and only then compare their token rates. The table below lines the tiers up so you know which rates to put next to which.

IIIPer-token price tables (representative 2026 rates)

Here are representative per-1M-token rates by tier, so you can see the shape of the comparison. These are illustrative figures for reasoning about cost — NOT live quotes. Prices in this category change frequently; confirm current per-model rates on the AWS Bedrock pricing page and the OpenAI pricing page before you commit.

Read these as ranges, not gospel. The headline pattern that holds across the category: output tokens cost several times more than input tokens, and each step up the capability ladder multiplies the rate — often 4–6× per step. The gap between Bedrock and OpenAI at the same tier is usually small relative to the gap between tiers, which is the whole point: you save far more by right-sizing the model than by switching platforms.

The two tables below give on-demand rates by tier, then the discounted rates once you apply the two biggest levers (batch and caching). Use them to bracket your own numbers, then plug your real token volumes into the worked scenarios in Section IV.

IVThe discount levers: batch, caching, and committed capacity

On-demand rates are the sticker price. What you actually pay depends on three levers, and both platforms offer all three in similar shape — so the question is less "which platform discounts" and more "which levers fit your workload." Applied well, these cut a real bill by 50–90% without changing the model.

Batch (~50% off) — for anything not real-time. If a job can tolerate minutes-to-hours of latency (overnight document processing, bulk classification, dataset labeling, embeddings backfills), submit it through the batch path and pay roughly half the on-demand rate. Amazon Bedrock offers Batch inference at ~50% off on-demand; OpenAI offers a Batch API at a comparable discount with a turnaround window. For batch-heavy workloads this is the single largest lever and it is near-parity across the two.

Prompt caching — for repeated context. If every call repeats the same large prefix — a long system prompt, fixed few-shot examples, a reused policy document, a stable RAG context — caching lets you avoid paying full input price for those repeated tokens on subsequent calls. Both Bedrock and OpenAI support prompt caching; the savings scale with how much of your input is repeated and how often. For chat assistants with big static system prompts, caching commonly removes a large fraction of input cost. (CloudRoute's sibling reference page on Bedrock prompt caching goes deeper on the mechanics.)

Committed / provisioned capacity — for steady high volume. When throughput is large and predictable, reserving capacity beats per-token. Amazon Bedrock Provisioned Throughput reserves model units billed hourly or monthly (with term commitments lowering the effective rate); OpenAI offers committed/scale arrangements for high-volume customers. These only pay off above a utilization threshold — below it, on-demand is cheaper — so model your real duty cycle before committing. This lever is most relevant to mature, high-traffic products, not early-stage ones.

VThree worked total-cost scenarios at scale

Per-token rates only become decisions when you push real volume through them. Below are three end-to-end worked examples — a support chatbot, a RAG knowledge assistant, and an overnight batch job — using the representative mid/small rates from Section III. The arithmetic is the same on both platforms; what changes is the model you pick and how you apply the levers. Numbers are illustrative, to show the method.

For each scenario the recipe is identical: estimate monthly input and output tokens, multiply by the per-1M rate for the chosen tier, then subtract what batch or caching removes. Do this on the specific models you would actually deploy and you have a defensible budget on either platform.

VIHidden costs on each side

The per-token rate is the visible number; a real bill has more line items. These are the costs that surprise teams after they ship — listed honestly for both platforms so a budget reflects total cost of ownership, not just the model rate.

• Output-token blowout (both) — Output is priced several times higher than input, and verbose models or unbounded responses quietly multiply cost. Capping max output tokens and prompting for concise answers is a real, free saving on either platform.
• Retrieved context in RAG (both) — Every RAG call re-pays input cost for the chunks you stuff in. Loose retrieval (too many chunks, whole documents) is one of the largest avoidable costs; tight retrieval plus caching of stable context cuts it sharply.
• Bedrock — surrounding AWS services — Knowledge Bases adds vector-store + storage cost; fine-tuning/customization adds training + custom-model storage (and, for Provisioned Throughput, an hourly reservation); your app's Lambda/EC2 compute, S3, and data transfer are separate AWS line items. These are normal AWS charges, but they belong in the total.
• OpenAI — platform line items — Higher-level features carry their own charges: hosted retrieval/file storage, certain built-in tools, fine-tuning (training + usage), and realtime/audio modalities priced separately from text. Bundled convenience, but still line items to budget.
• Egress / networking (mostly Bedrock-adjacent) — Calling a model inside your AWS region over private networking avoids public-internet egress; cross-region or external calls can add data-transfer cost. Co-locating inference with your app is a small but real saving.
• Idle provisioned/committed capacity (both) — Reserved capacity (Bedrock Provisioned Throughput, OpenAI committed tiers) is billed whether or not you use it. Under-utilized reservations are a classic overspend — model the duty cycle before committing.
• Re-tuning and evaluation (both, one-time) — Switching models or platforms costs engineering time to re-tune prompts and re-run evals. It is a one-time cost, but it is real and worth naming when comparing a migration's payback.

VIIThe cost difference that is not per-token: creditability

Everything above is roughly symmetric — both platforms tie at a fixed tier and offer the same levers. There is one asymmetry that does not show up in any rate card and can dominate the real out-of-pocket cost for an early-stage company: who you pay, and therefore whether credits apply.

Amazon Bedrock usage is AWS spend. Bedrock is an AWS service billed on your AWS account, so Bedrock token costs draw down AWS credits exactly like EC2, S3, or RDS. If you hold an AWS Activate credit balance (up to $100K), a Bedrock/GenAI PoC pool ($10K–$50K), or a GenAI Accelerator award (up to $1M), your Bedrock inference is paid from those credits until they are exhausted — which for an eligible startup can make early GenAI inference effectively $0 out of pocket.

OpenAI API usage is billed by OpenAI. It is a separate vendor relationship paid on OpenAI's own billing, so AWS credits do not apply to it. Your OpenAI spend is real cash from day one regardless of any AWS credit balance you hold. (OpenAI runs its own startup/credit programs from time to time, but those are separate from, and not stackable with, AWS credits.)

Why this can outweigh the per-token comparison. Suppose your GenAI inference will run ~$1,500/month in year one. On OpenAI that is ~$18K of real cash over the year. On Bedrock, funded by an Activate balance, the same workload can be $0 out of pocket until the credits run out — at which point you are paying Bedrock's (competitive, per-tier-comparable) rates anyway. So even if a specific OpenAI model were marginally cheaper per token, the creditable path can be dramatically cheaper in actual cash for the period that matters most to a young company. This is the cost lever that the rate cards never show.

The honest framing: creditability is a timing-and-cash advantage, not a permanent per-token discount — once credits are spent, Bedrock is priced on its merits like any platform. But for a startup deciding where to run inference in the first 12–24 months, "fundable with AWS credits" is frequently the largest single factor in total cost.

VIIICost verdict — and how to switch on credits

A cost comparison has to end with a plain answer. Here it is, then the practical path if the answer points you to Bedrock.