Amazon Bedrock free tier — is it free, and how far does it go?

IIs Amazon Bedrock free? The honest answer

People arrive at this question expecting a yes/no and a free-tier allowance like "750 hours" or "5 GB." For Bedrock specifically, the honest answer is: no, there is no standing free tier — but the cost of learning it is small enough that "free" is almost true at the experiment stage. Both halves of that sentence matter.

First, the precise version. Amazon Bedrock is a pay-per-token service with no perpetual free allowance. Unlike the AWS services people associate with the words "free tier" — EC2 (750 compute hours/month for 12 months), S3 (5 GB), Lambda (1M requests/month), DynamoDB (25 GB) — Bedrock does not publish an always-free monthly quota of tokens. The moment you send a real inference request to a foundation model, the per-token meter starts, billed exactly as described on the amazon-bedrock-pricing sibling.

So why do so many people believe Bedrock "has a free tier"? Three honest reasons. (1) The AWS Free Tier umbrella. AWS markets a broad "Free Tier" program across dozens of services, and it is reasonable to assume a flagship service like Bedrock is in it. It mostly is not, in the always-free sense. (2) New-account free credit. AWS has at various points offered new accounts a time-bounded, dollar-capped free-credit grant that can be spent across many services — Bedrock usage can draw it down, which feels like a free tier but is really a one-time, expiring grant. (3) Sibling-service confusion. Amazon Q has a free tier on some capabilities, SageMaker Studio has a free tier for notebooks, and the AWS console itself is free to open — so "I used an AWS AI thing for free" is often true of a neighbor, not of Bedrock inference.

Second, the reassuring version. The reason this distinction does not panic most builders is that Bedrock experimentation is genuinely cheap. Because the cheapest models cost cents per million tokens, a developer can run hundreds of test prompts through the console or the API and spend a fraction of a dollar. "No free tier" does not mean "expensive to try" — it means "you pay for exactly what you use, and at the experiment stage that is a rounding error." The danger is not the experiment; it is the moment a workload quietly scales (see §V on surprise bills).

The practical takeaway: treat Bedrock as cheap-to-learn, not free-to-run. Use the small-volume paths in the next section to learn it for cents, understand exactly where cost begins, and — for any build that matters — skip the free-tier framing entirely and fund it with AWS credits, which is the path the rest of this page builds toward.

IIWhat the AWS Free Tier actually covers for a Bedrock build (and what it does not)

Even though Bedrock inference itself is not in the always-free tier, a real Bedrock application touches a handful of supporting AWS services — and several of those genuinely are. Knowing which line items are free and which are not is the difference between an accurate budget and a surprise.

A Bedrock workload is rarely just model calls. A typical RAG app or agent also uses storage, a vector store, some compute glue, logging, and IAM. The AWS Free Tier helps with parts of that supporting cast — and notably not with the model tokens themselves. The table below splits a representative Bedrock stack into "free-tier covered," "partially covered," and "never free," using representative 2026 allowances.

Read the table as a map, not a quote. AWS Free Tier allowances and structure change, and several services moved to a unified credit-style free model in recent updates — so confirm specifics on the AWS Free Tier page. The shape, however, is stable: the plumbing around Bedrock has meaningful free allowances; the foundation-model inference does not.

IIIFree and near-free ways to actually experiment with Bedrock

No standing token allowance does not mean you cannot start for nothing. There are several legitimate ways to learn Bedrock at zero or near-zero cost — and knowing them is more useful than a mythical free tier, because they map to how you would really evaluate the service.

These range from truly free (opening the console, reading model cards, using the playground UI which itself is free to load) to effectively free (a handful of small calls on the cheapest models that cost a fraction of a cent). Use them in roughly this order to go from "never touched Bedrock" to "have a working prototype" without a meaningful bill.

IVThe real cost beyond free — where the meter actually starts to matter

The experiment is cheap; the gap to a real bill opens at scale. Understanding exactly which transitions take a workload from "cents" to "thousands a month" is what lets you plan — and is exactly the gap that AWS credits are designed to fill.

Three transitions turn a near-free experiment into a real cost. (1) Volume. Cents-per-million-tokens is trivial at a thousand test requests and material at ten million production ones. The per-token rate did not change; your traffic did. (2) Model tier. Moving from Nova Micro to a frontier model is a 100×+ jump in per-token cost; doing so for every request rather than only the hard ones is the most common avoidable cost. (3) The recurring lines around the model. A custom fine-tuned model on Provisioned Throughput bills hourly whether used or not; a vector store for RAG bills hourly; logging and storage accrue. None of these are in any free tier.

To make the scale concrete: a prototype support assistant on Claude Haiku might cost a few dollars a month at low traffic, while the same assistant at 50,000 conversations a month is still only tens of dollars — but a RAG knowledge assistant on Claude Sonnet pulling large retrieved context can reach hundreds of dollars a month, and a high-volume product on a frontier model for every call climbs into the thousands. The full worked examples live on the amazon-bedrock-pricing page; the point here is the order of magnitude jump from experiment to production, and that the free tier covers none of it.

The good news is that the same levers that control a paid bill also stretch any free credit: right-size the model (cheap model for the easy 80% of requests), move bulk work to Batch (~50% off), turn on prompt caching for repeated context, and shorten prompts / cap output. These do not make Bedrock free, but they routinely cut a bill several-fold — and they make a fixed pool of AWS credits last far longer.

VHow to avoid a surprise Bedrock bill

Because there is no free-tier wall to stop you, the discipline shifts to you: set up cost guardrails before you scale, not after the invoice. None of this is Bedrock-specific magic — it is standard AWS cost hygiene applied to a service that meters fast.

A surprise Bedrock bill almost never comes from the experiment — it comes from a workload that scaled silently (a loop that retried, an agent that fanned out, a batch job left running, a frontier model used where a cheap one would do, or a custom model left hosted on Provisioned Throughput after the test ended). The fixes are cheap and worth setting up on day one.

• Set an AWS Budget with alerts — Create a monthly Budget (e.g. $20 while experimenting) with email/SNS alerts at 50% / 80% / 100%. This is the single most important guardrail — it turns a silent overrun into an early warning.
• Watch cost by service in Cost Explorer — Tag Bedrock workloads and check Cost Explorer regularly so you can see token spend, vector-store hours, and custom-model hosting as separate lines — the surprise is usually the line you were not watching (often the vector store or a standing Provisioned Throughput model).
• Tear down Provisioned Throughput and custom-model hosting after tests — Reserved capacity and hosted custom models bill hourly whether used or not. The most expensive "free tier" mistake is leaving one running over a weekend. Delete it the moment the test ends.
• Default to the cheapest model that works — Make Nova Micro/Lite or Haiku the default and promote to a frontier model only per-request when needed. Using a frontier model for everything is the most common avoidable overrun.
• Cap output and trim input — Set sensible max-output-token limits and trim retrieved context and history. Output is the pricey direction; runaway generation is a real bill.
• Use Guardrails and rate limits to bound runaway loops — Bedrock Guardrails plus application-level rate limiting stop an agent or retry loop from quietly multiplying token spend. See amazon-bedrock-guardrails.

VIFree tier vs AWS credits — why credits win for any real build

For a weekend of learning, "near-free on a cheap model" is fine. For anything you intend to ship, the free-tier framing is the wrong tool entirely — AWS credits are categorically better, and they exist specifically to fund generative-AI builds like yours.

The mismatch is structural. The AWS Free Tier is built for learning the plumbing — small, capped, mostly-12-month allowances on supporting services, with nothing for Bedrock inference. AWS credits are built for funding a real workload — pools measured in tens of thousands to a million dollars that apply against your actual AWS bill, including Bedrock inference, fine-tuning, embeddings, and every supporting service. One is a sample; the other is a budget.

Concretely, the relevant credit pools are: AWS Activate (general startup credits, commonly up to $100K for institutionally-funded startups), a dedicated Bedrock / Generative-AI POC pool ($10K–$50K) aimed squarely at proving out a GenAI use case, and the competitive Generative AI Accelerator (awards up to $1M for a small cohort of AI-first startups). Any of these dwarfs what the free tier offers, and credits apply automatically against your bill until exhausted — so a build that would have cost thousands runs at $0 out of pocket.

The catch — and the reason most teams do not simply self-serve their way to a large credit pool — is that these pools are largely partner-filed through the AWS Partner Network (the ACE program), not a public form. That is the gap CloudRoute fills, and it is the bridge from this page: rather than stretching a non-existent free tier, route to the credit pool that fits your stage and a vetted AWS partner who files the application and helps build the workload. With credits in place, Bedrock is not "almost free at tiny scale" — it is effectively $0 at real scale while you prove the product out.

VIIHow AWS credits make Bedrock effectively $0

The previous section argued credits beat the free tier; this one explains the mechanic, because the part that surprises people is that the customer pays nothing — not a discounted rate, but $0 — and the model is structurally sound rather than too-good-to-be-true.

AWS runs these credit programs precisely to put generative-AI workloads on AWS, and Bedrock usage is fully credit-eligible. Credits apply automatically against your AWS bill — Bedrock inference, fine-tuning, embeddings, the vector store, storage, logging — drawing the balance down before anything touches your card. While a pool is live, a Bedrock build that would otherwise cost thousands a month is simply $0 out of pocket.

The mechanic that makes it $0 to the customer rather than merely cheaper is the routing structure. Most of these pools are partner-filed via the ACE program, so teams route through an AWS partner rather than applying alone. CloudRoute matches you to the right credit pool for your stage and to a vetted AWS DevOps/ML partner who both files the credit application and helps build the Bedrock workload — the RAG pipeline, the agent, the cost-tuned model routing. The customer pays $0: AWS funds the credit pool, AWS pays the partner through engagement-funding programs, and the partner pays CloudRoute a routing commission. You never see an invoice.

Put it together and the answer to "is Bedrock free?" becomes practical rather than pedantic. There is no free tier — but for a startup or company with a real use case, Bedrock is effectively free to build, because AWS credits cover it and the credits cost you nothing to obtain through a partner. Related: see the cross-cluster pages on AWS credits for generative-AI startups and Bedrock POC funding for the full credit mechanics, and the aws-innovation-sandbox sibling for a safe, budget-capped place to run the experiments.