Claude on Amazon Bedrock — pricing, access & setup.

IThe Claude family on Amazon Bedrock

Anthropic's Claude is available natively on Amazon Bedrock — it is one of the foundation-model providers behind Bedrock's single managed API, alongside Amazon's own Nova and Titan, Meta Llama, Mistral, Cohere, and others. On Bedrock the Claude lineup follows a clear three-tier shape, and choosing the right tier is the most important cost-and-quality decision you will make.

The Claude family is organized as a ladder of three tiers, each a deliberate trade-off between intelligence, speed, and cost. As of 2026 the current generation on Bedrock spans: Claude Opus — the most capable tier, built for the hardest reasoning, complex multi-step analysis, and agentic work where quality dominates; Claude Sonnet — the balanced workhorse that handles the large majority of production traffic with strong reasoning at a fraction of Opus cost and latency; and Claude Haiku — the fast, low-cost tier for high-throughput, latency-sensitive, or simpler tasks. The exact version names and identifiers advance over time as Anthropic ships new generations; this page describes the durable tier structure and points you to the model catalog for current IDs.

The practical discipline is the same one that governs all Bedrock cost: match the model to the task. Use Haiku for the easy, high-volume requests; use Sonnet as the default for real work; reserve Opus for the genuinely hard requests where its extra reasoning earns its higher price. Many production systems route across all three — a cheap model triages and handles the bulk, escalating only the hard cases to a stronger one. That single pattern routinely cuts Claude spend several-fold with little quality loss.

Because all three are served through the same Bedrock API, switching between them is usually a one-line change to the model ID — which makes the route-and-escalate pattern easy to build and easy to tune. The capabilities (vision, tool use, long context, prompt caching, extended thinking) and the security model are consistent across the family, so you design once and choose the tier per request.

One caveat, stated once and meant throughout: exact model version names, model IDs, regional availability, context-window sizes, and per-token prices all change frequently as Anthropic ships new Claude generations and AWS updates Bedrock. The figures and identifiers here are representative as of 2026 to convey the structure and relative cost. Always confirm the current model IDs in the Bedrock model catalog and current rates on the AWS Bedrock pricing page before you build or budget.

IIWhy run Claude via Bedrock instead of the Anthropic API direct?

Claude is available both directly from Anthropic's own API and through Amazon Bedrock. The model is the same Claude either way — so the choice is about everything around the model: security posture, billing, data control, and funding. For teams already on AWS, Bedrock usually wins on all four.

This is the central question this page exists to answer, and the honest framing is that it is an operational decision, not a model-quality one. You are choosing where Claude runs and how it is governed, billed, and paid for. Here is what running Claude through Bedrock buys you over the direct API:

• AWS-native security and identity — Calls are authenticated and authorized with IAM — the same roles, policies, and least-privilege model you already use across AWS. You can keep traffic on your private network with VPC endpoints (PrivateLink), encrypt with your own KMS keys, and get a full audit trail in CloudTrail. No separate API key to provision, rotate, and secure outside your AWS account.
• Consolidated billing — Claude usage lands on your existing AWS invoice, in the same Cost Explorer and budgets as the rest of your stack — no separate vendor bill, no separate payment relationship, no extra procurement. For finance and FinOps that single-invoice consolidation is a real simplification.
• Data residency and privacy — You choose the AWS region Claude runs in, so prompts and responses stay in the jurisdiction you select — important for GDPR, data-residency, and regulated workloads. As with all of Bedrock, your inputs and outputs are not used to train the base model and stay within your account and region.
• One API across many models — Through Bedrock's Converse API, Claude sits behind the same interface as Nova, Llama, Mistral, Cohere, and Titan. You can build a model-agnostic application and switch or mix models — including routing easy requests to a cheaper model and hard ones to Claude — without rewriting your integration.
• The decisive one — AWS credits apply — Claude usage on Bedrock draws down AWS credits (Activate, Bedrock/GenAI POC, the GenAI Accelerator) like any other AWS spend. The direct Anthropic API does not. For a startup with a credit pool, running Claude via Bedrock can be effectively $0 during the build — which is exactly why this is CloudRoute's tightest fit.

When is the direct API the better pick? If you are not on AWS, want the very newest Claude release the day it ships (new generations sometimes appear on the direct API first), or rely on an Anthropic-specific feature before it lands on Bedrock, going direct can make sense. But for the large population of teams already building on AWS — and especially any startup eligible for AWS credits — Bedrock is usually the stronger home for Claude.

IIIModel IDs and how to enable model access

Before you can call Claude on Bedrock, you have to do one small but mandatory thing: request model access in your account. Foundation models on Bedrock are off by default; turning Claude on is a one-time, no-cost step in the console.

Enabling access. In the Bedrock console, open Model access, find the Claude models you want, and request access. For most Claude models this is granted effectively immediately; some models prompt for brief use-case details. There is no charge for enabling access — you only pay when you actually call a model. Access is per-account and per-region, so if you operate in several regions, enable Claude in each one you will call from. This is also where cross-region inference profiles come in: they let Bedrock route your Claude calls across a set of regions for better availability and throughput (see the amazon-bedrock-cross-region-inference sibling).

Model IDs. Every model on Bedrock is invoked by a model ID — a string identifying the provider, model, and version (Claude IDs are namespaced under Anthropic, e.g. an identifier of the shape anthropic.claude-…, with a version suffix). You pass this ID to the API to choose which model and tier answers a request, so moving a request from Haiku to Sonnet to Opus is just a change of model-ID string. Because IDs advance with each Claude generation, do not hard-code a guessed value — read the current ID from the Bedrock model catalog (console) or list it via the API/CLI, and treat it as configuration rather than a literal in your code.

Permissions. The IAM principal making the call needs permission for the relevant Bedrock invoke actions (and, if you use cross-region inference profiles, permission on the profile). A least-privilege policy scoped to the specific Claude model ARNs you intend to use is the recommended posture. Once access is granted and IAM is in place, you are ready to call Claude — the next section shows the minimal request.

• Open the Bedrock console → Model access → request access to the Claude models you need (free; usually instant).
• Enable access in each region you will call from; consider a cross-region inference profile for availability.
• Get the current model ID from the model catalog or via the API — do not hard-code a guessed version string.
• Attach an IAM policy granting the Bedrock invoke actions on the specific Claude model ARNs (least privilege).
• You are billed only on invocation — enabling access costs nothing.

IVClaude on Bedrock — per-model pricing

Claude on Bedrock is billed per token: a rate per 1,000 input tokens (everything you send) and a higher rate per 1,000 output tokens (everything Claude generates), with output typically priced several times higher than input. The rate depends entirely on the tier — and the spread across tiers is wide enough that model choice is the dominant cost lever.

The table below gives representative 2026 on-demand rates for the three Claude tiers, shown per 1,000 and per 1,000,000 tokens (the per-million column is simply the per-1K figure × 1,000; providers increasingly quote per-million). Use it to rank the tiers by cost and sanity-check a budget — not as an audited price sheet. Two cost levers sit on top of these rates and are not shown in the table: Batch (submit non-interactive work as an async job for roughly half the on-demand price) and prompt caching (stop re-paying full input price for a repeated prefix like a long system prompt). Both can substantially lower the effective rate — see amazon-bedrock-pricing and amazon-bedrock-prompt-caching.

VCapabilities: vision, tool use, long context, prompt caching, extended thinking

Claude on Bedrock is not just text-in/text-out. The current generation brings a set of capabilities that materially expand what you can build — and several of them are also cost or quality levers. Availability of any given capability can vary by Claude tier and version, so confirm specifics for your chosen model.

VIA minimal Converse API call

The recommended way to call Claude (and any chat model) on Bedrock is the <strong>Converse API</strong> — a single, model-agnostic interface for multi-turn messages, system prompts, tool use, and multimodal input. Because it is model-agnostic, the same code calls Haiku, Sonnet, or Opus by changing only the model ID.

A minimal text request with the AWS SDK looks like the snippet below (Python / boto3). You create a Bedrock Runtime client, call converse with a model ID and a list of messages, and read the reply from the response. Swapping modelId between the Haiku, Sonnet, and Opus IDs is the only change needed to move a request across tiers — which is what makes tiered routing a one-line decision.

import boto3
client = boto3.client("bedrock-runtime", region_name="us-east-1")
resp = client.converse(
  modelId="anthropic.claude-<tier>-<version>", # from the model catalog
  messages=[{"role": "user", "content": [{"text": "Summarize this contract clause: ..."}]}],
  system=[{"text": "You are a concise legal assistant."}],
  inferenceConfig={"maxTokens": 512, "temperature": 0.2},
)
print(resp["output"]["message"]["content"][0]["text"])

That is the whole pattern for a basic call. From here you add multi-turn history (append assistant and user messages), tool use (a toolConfig describing your functions, with a streaming or multi-step loop to feed results back), vision (image blocks in the message content), and streaming (the converse_stream variant for token-by-token output). The same shape holds throughout — the API surface barely changes as you add capabilities, which is the point of Converse. The exact model ID string must come from the Bedrock model catalog; the placeholder above is illustrative, not a literal value.

VIIUse cases — which Claude for which job

The clearest way to think about the family is by mapping common production workloads to the cheapest tier that does them well. Start a request on the smallest tier that clears your quality bar and only escalate when it does not.

• Claude Haiku — high-volume, latency-sensitive, simpler tasks — Classification, routing and triage, data extraction, short-form generation, real-time chat where speed matters, the cheap first stage of a tiered router, and bulk processing (especially via Batch). When good-enough quality at the lowest cost and fastest response is the goal, start here.
• Claude Sonnet — the production workhorse — The sensible default for most real work: RAG knowledge assistants, customer-support agents, content generation, coding assistance, document analysis, and the reasoning behind most Bedrock Agents. Strong quality at a fraction of Opus cost and latency — where the majority of production traffic should live.
• Claude Opus — hardest reasoning and complex agents — Reserve for the genuinely difficult: deep multi-step reasoning, complex analysis, hard coding and refactoring, research-style synthesis, and agentic workflows where a wrong step is expensive. Pricier and a bit slower — worth it only for the requests that actually need its depth, ideally reached via escalation rather than as a default.
• Tiered routing — use all three — The highest-leverage pattern: a cheap model triages and handles the easy majority, escalating only hard cases to Sonnet or Opus. Because switching tiers is a one-line model-ID change on the Converse API, this is straightforward to build — and it routinely cuts Claude spend several-fold with little quality loss.

VIIIClaude vs Amazon Nova vs GPT on Bedrock — briefly

Claude is one strong choice among several on Bedrock. A quick, honest orientation versus the two other names people ask about — Amazon's own Nova family, and OpenAI's GPT models — without turning this into a full shootout.

Claude vs Amazon Nova. Nova is Amazon's own foundation-model family on Bedrock (Micro / Lite / Pro / Premier for text, plus Canvas for images and Reel for video), engineered for low cost and low latency. At the cheap end, Nova Micro and Lite undercut even Haiku and are excellent for very high-volume, simple, latency-sensitive work. Claude tends to be the pick when you want the strongest reasoning and the specific Claude behaviour and capability profile, particularly Sonnet and Opus for harder tasks. A common pattern is to mix them: Nova for the cheapest bulk path, Claude for the quality path — trivial to do behind one Converse API. See the amazon-nova sibling.

Claude vs GPT. The Bedrock-specific point is availability: Bedrock's value is its catalog of providers, and which exact third-party frontier models are offered changes over time, by region, and by provider agreement. Where multiple frontier families are available on Bedrock, the right choice is workload-specific — benchmark the candidates on your task and prompts rather than on leaderboard headlines, since relative strengths shift with each generation. The structural advantages of running on Bedrock (IAM/VPC, consolidated billing, data residency, and AWS credits) apply regardless of which model you land on. For a fuller treatment, see amazon-bedrock-vs-openai.

The meta-point: Bedrock lets you defer and revisit this choice cheaply. Because every model sits behind the same API, you can start on Claude, A/B a Nova or other model on part of your traffic, and re-tier as prices and capabilities move — without re-plumbing your application.

IXHow AWS credits make running Claude $0

Everything above prices Claude on Bedrock if you pay AWS directly. For most startups and many companies the relevant number is different — because AWS will frequently fund the build with credits, and Claude usage on Bedrock draws those credits down before it ever touches your card. This is the single tightest fit in CloudRoute's whole offer.

Claude inference on Bedrock is ordinary AWS spend, so it is fully credit-eligible and credits apply automatically against your bill until exhausted — covering Claude tokens, any Batch and prompt-caching usage, plus the supporting services (Knowledge Bases, vector store, S3, logging). The relevant pools: AWS Activate (general startup credits, commonly up to $100K for institutionally-funded startups); a dedicated Bedrock / Generative-AI POC pool ($10K–$50K) aimed 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). This is precisely the advantage Bedrock has over the direct Anthropic API for a funded startup: credits apply to Claude on Bedrock; they do not apply to the direct API.

The practical mechanic is that most of these pools are partner-filed — requested through the AWS Partner Network (the ACE program), not a public self-serve form — which is why teams route through an AWS partner rather than applying alone. That is the gap CloudRoute fills. 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 Claude workload — the tiered model router, the RAG pipeline behind Knowledge Bases, the agent with tool use, prompt caching on the fixed context. 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 together with the tiered-routing and caching levers above, the picture for a startup is: build on the Claude tier each request actually needs, cache the repeated context, and run the whole thing on a $25K–$100K (or larger) credit pool while you find product-market fit — paying real money only once usage, and ideally revenue, has scaled past the credits. Related: AWS credits for generative-AI startups and Bedrock POC funding for the full credit mechanics.