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 free token allowance. Accounts opened before 15 July 2025 kept the older Free Tier, with 12-month allowances on services such as EC2 and S3. Accounts opened since then get Free Tier credits instead: $100 at sign-up and up to $100 more for trying services, on a Free plan that ends after 6 months or when the credits run out, or on a Paid plan. Neither version includes a monthly Bedrock token allowance. The moment you send a real inference request, the per-token meter starts.

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. Knowing which changes take a workload from cents to thousands a month is what lets you plan, and fund it.

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.

VIWho can file AWS funding for a Bedrock build

There are two kinds of AWS money for a Bedrock build. A partner files one. You apply for the other yourself.

Partner-filed funding. An AWS consulting partner can file POC (proof of concept) funding to test a Bedrock workload, whether or not you run on AWS today. If you already run on AWS and are adding new AI work, the partner can file incremental workload (IW) funding instead. For startups this is often $50K to $150K. Depends on the workload; AWS approves. The work has to be real, and the partner has to be the one doing it.

AWS Activate, which you apply for yourself. Activate Founders gives $1,000 to start, up to $5,000, with no investor needed. Activate Portfolio gives up to $200,000 if your VC, accelerator or angel group is an Activate Provider and gives you its Org ID. A consulting partner cannot apply for Activate on your behalf. AWS made Activate credits usable for third-party models on Bedrock in April 2024.

For most startups without a VC, the partner route is the larger of the two. CloudRoute matches you with one vetted AWS partner for free. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.