Claude Sonnet on Amazon Bedrock — the balanced default for production.

IWhat Claude Sonnet is — and why it is the default tier

Claude Sonnet is the middle of Anthropic's three-tier Claude family on Amazon Bedrock, sitting between Opus (the most capable, most expensive tier) and Haiku (the fastest, cheapest tier). It is engineered to be the model you reach for first: strong enough for the large majority of production work, fast enough for interactive use, and priced low enough to run at scale.

If you take only one thing from this page: Sonnet is the sensible default. The discipline that governs all Bedrock cost is "match the model to the task," and for most tasks the right match is Sonnet. It clears the quality bar for RAG assistants, customer-support agents, content generation, coding help, document analysis, and the reasoning behind most agents — while costing a fraction of Opus and responding fast enough to sit in a live request path. The two other tiers are the exceptions you reach for deliberately: Opus when a request is genuinely hard, Haiku when a request is genuinely easy and high-volume. Sonnet is the broad middle where most real traffic should live.

Sonnet runs on Bedrock exactly like every other foundation model there — behind Bedrock's single managed Converse API, governed by AWS IAM, callable over private networking with VPC endpoints, encryptable with your own KMS keys, and audited in CloudTrail. Your prompts and responses stay in your AWS account and the region you choose, and your inputs and outputs are not used to train the base model. This page focuses on Sonnet specifically; for the full Claude-on-Bedrock picture — the whole family, the deep "why Bedrock vs the Anthropic API direct" argument, and the shared mechanics — see the claude-on-amazon-bedrock sibling.

The reason Sonnet works so well as a default is that the route-and-escalate pattern is cheap to build on Bedrock. Because switching tiers is a one-line change to the model ID on the same Converse API, you can start every request on Sonnet and either drop the easy ones to Haiku or escalate the hard ones to Opus without rewriting anything. Sonnet anchors that pattern: it is the baseline the cheaper and more expensive tiers are measured against.

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

IIThe balance: quality, speed, and cost in one tier

Sonnet earns the "workhorse" label because it is the tier where the three things you actually trade off — answer quality, response latency, and price per token — meet at a point that fits the widest range of production workloads. None of the three is the absolute best in the family, and that is exactly the point.

Think of the Claude family as a single dial from cheap-and-fast to deep-and-expensive. Haiku is at one end, Opus at the other, and Sonnet is the deliberately-chosen middle. What makes the middle valuable is that most real work does not need the extreme of either end. A customer-support answer, a RAG response grounded in retrieved documents, a code suggestion, a document summary — these need solid reasoning and reliable instruction-following, which Sonnet provides, but they rarely need Opus-grade depth, and they usually need more nuance than you would trust to the cheapest tier.

IIIClaude Sonnet model ID and how to enable access

Before you can call Sonnet on Bedrock you have to request model access in your account — foundation models are off by default — and you have to invoke Sonnet by its model ID. Both are quick; neither costs anything until you actually call the model.

Enabling access. In the Bedrock console, open Model access, find Claude Sonnet, and request access. For Sonnet this is typically granted effectively immediately (some Claude models prompt for brief use-case details). There is no charge for enabling access — you pay only when you invoke. Access is per-account and per-region, so enable Sonnet in each region you will call from. If you want Bedrock to spread Sonnet traffic across a set of regions for better availability and throughput, use a cross-region inference profile (see the amazon-bedrock-pricing sibling for how that interacts with rates, and the cross-region-inference page in the cluster for the mechanics).

The Sonnet model ID. Sonnet is invoked by a model ID — a string identifying the provider, model, and version, namespaced under Anthropic (of the shape anthropic.claude-…sonnet… with a version suffix). You pass this ID to the Converse API to select Sonnet for a request; moving that same request to Haiku or Opus is just a change of the model-ID string. Because the ID advances with each Sonnet generation, do not hard-code a guessed value — read the current Sonnet ID from the Bedrock model catalog in the console (or list it via the API/CLI) and treat it as configuration rather than a literal in your code. Storing the three tier IDs (Haiku, Sonnet, Opus) as config is what makes route-and-escalate a one-line decision at runtime.

Permissions. The IAM principal making the call needs permission for the Bedrock invoke actions on the Sonnet model ARN (and, if you use a cross-region inference profile, permission on the profile). A least-privilege policy scoped to the specific Sonnet ARN you intend to call is the recommended posture; widen it to include the Haiku and Opus ARNs only if you actually route across tiers. Once access is granted and IAM is in place, you are ready to call Sonnet.

• Open the Bedrock console → Model access → request access to Claude Sonnet (free; usually instant).
• Enable Sonnet in each region you will call from; consider a cross-region inference profile for availability.
• Get the current Sonnet 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 Sonnet model ARN (least privilege).
• Store the Haiku / Sonnet / Opus IDs as config so escalation is a one-line change; you are billed only on invocation.

IVClaude Sonnet pricing on Bedrock — and the levers that lower it

Sonnet on Bedrock is billed per token: a rate per million input tokens (everything you send) and a higher rate per million output tokens (everything Sonnet generates), with output priced several times higher than input. The headline on-demand rate is only the starting point — two levers, Batch and prompt caching, can cut the effective rate substantially.

As a representative 2026 reference, Sonnet's on-demand rate sits near $3 per million input tokens and $15 per million output tokens — output about 5× input, which is why output length is a real cost lever. The table below places Sonnet against the tiers on either side so you can see the order-of-magnitude steps that make tiered routing pay; treat it as relative comparison, not an audited price sheet. Beyond the table sit two levers that change Sonnet's effective cost: Batch — submit non-interactive Sonnet work as an asynchronous job for roughly half the on-demand price — and prompt caching — stop re-paying full input price for a repeated prefix such as a long system prompt, instruction set, reference document, or tool definitions. On a Sonnet chatbot or RAG service with a large fixed context, caching can remove a large fraction of the input bill. For the full pricing model, including how Provisioned Throughput and cross-region inference interact with these, see the amazon-bedrock-pricing sibling.

VWhen Sonnet is right — and when to reach up to Opus or down to Haiku

The single most valuable skill in using the Claude family well is knowing the decision boundary around Sonnet: when Sonnet is the right default, when a request is hard enough to justify Opus, and when a request is easy enough to hand to Haiku. Getting this boundary right is what turns the family into a cost-efficient system instead of an expensive default.

Start every request on the assumption that Sonnet is the answer, then look for a specific reason to move off it in either direction. The reasons to move are concrete, not vibes — they are about the nature of the request, not a general preference for "the best model." Below are the boundaries in both directions.

VISonnet capabilities: vision, tool use, long context, prompt caching, extended thinking

Sonnet is not just strong text-in/text-out — it carries the capabilities that make modern GenAI applications possible, and several of them double as cost or quality levers. Availability of any specific capability can vary by Sonnet version, so confirm specifics for the exact Sonnet model you enable.

VIIProduction use cases — the work Sonnet carries

The clearest way to see why Sonnet is the default is to look at the production workloads that land on it. These are the cases where Sonnet's quality is enough, its latency fits a live path, and its cost is low enough to run at scale — the broad middle of real GenAI applications.

• RAG knowledge assistants: Sonnet is the typical default for retrieval-augmented generation: it reasons well over retrieved passages, follows grounding instructions reliably, and handles the large contexts that RAG produces — with prompt caching on the fixed system prompt keeping cost down. The reasoning engine behind most Bedrock Knowledge Bases deployments lives here.
• Customer-support agents: Support automation needs solid reasoning, reliable tone and policy-following, and fast-enough responses for a live conversation — Sonnet's exact balance. It is capable enough to use tools (look up an order, check a policy) and cheap enough to handle high ticket volume, with the hard or sensitive cases escalated to Opus or a human.
• Coding assistance: For most day-to-day coding help — explaining code, writing functions, fixing bugs, drafting tests — Sonnet clears the bar at a fraction of Opus cost and fast enough to sit in an IDE flow. Reserve Opus for large, intricate refactors and genuinely hard algorithmic work where its depth pays off.
• Content generation and transformation: Drafting, rewriting, summarizing, translating, and reformatting at production quality — Sonnet handles the bulk of content workloads well, with concise-output discipline and caching keeping the per-item cost low. Truly throwaway bulk generation can drop to Haiku.
• Document analysis and extraction: Summarizing long documents, answering questions over them, and extracting structured data (including from images via vision) — Sonnet's long context and multimodal input make this a single-call job for most documents. Very high-volume, simple extraction can move to Haiku; unusually complex analysis can escalate to Opus.
• The reasoning engine inside agents: Most Bedrock Agents run Sonnet as the planner-and-tool-caller: capable enough to decompose a task and call tools reliably, cheap enough that a multi-call agent loop stays affordable. High-stakes individual steps within an agent can be routed to Opus while the loop stays on Sonnet.

VIIICost tips: getting the most out of Sonnet

Sonnet is already the cost-efficient default, but a handful of concrete practices compound to lower its effective rate substantially. None require a different model — they are about how you call Sonnet and what you route to it.

These are the levers, in roughly the order of impact for a typical production system. The first is about tier discipline around Sonnet; the rest are about calling Sonnet efficiently once a request is correctly on it.

• Route, don't default-up: Keep Sonnet as the default and move only deliberately: drop easy, high-volume requests to Haiku (~10× cheaper) and escalate only genuinely hard ones to Opus. The single biggest avoidable cost is leaving easy bulk work on Sonnet (or worse, Opus) when Haiku would clear the bar. Because tiers are a one-line model-ID change, this routing is cheap to build and tune.
• Cache the fixed prefix: If your Sonnet requests share a long system prompt, instruction block, reference document, or tool definitions, turn on prompt caching so you stop re-paying full input price for that prefix on every call. On chatbots and RAG with a large fixed context this is often the largest single saving available on Sonnet.
• Batch the non-interactive work: Any Sonnet work that does not need an immediate answer — overnight document processing, bulk classification, backfills, evaluations — should go through Batch for roughly half the on-demand price. Reserve real-time (and streaming) Sonnet calls for the requests a user is actually waiting on.
• Shorten outputs: Output is priced several times higher than input, so cap and tighten generations: set a sensible maxTokens, ask for concise answers, and avoid having Sonnet restate large inputs. On output-heavy workloads this is a direct, immediate saving.
• Trim and structure the input: Long context costs per token. Retrieve only the passages a request actually needs rather than stuffing the window, and reuse a cached prefix for the stable parts. Good retrieval is a cost lever as much as a quality one on Sonnet.
• Pay with funding, not runway: For a startup, funding is the largest lever. Sonnet on Bedrock is AWS spend, so AWS Activate credits can pay for it, and partner-filed POC or IW funding can cover the build when the workload qualifies and AWS approves. Covered next.

IXHow to fund Sonnet usage, and who files it

Everything above prices Sonnet as if you pay AWS directly. Two kinds of AWS money can pay that bill instead, and different people file them.

AWS Activate credits. Sonnet on Bedrock is AWS spend, so Activate credits can pay for it. AWS made them redeemable for third-party models on Bedrock, Anthropic’s included, in April 2024 (AWS announcement). They do not apply to the direct Anthropic API. You apply for Activate credits yourself. Activate Founders is $1,000 to start, up to $5,000, with no investor needed. Activate Portfolio is up to $200,000, using the Org ID from your VC, accelerator or angel group if it is an AWS Activate Provider. A consulting partner cannot file Activate for you.

Partner-filed funding. Your matched AWS partner can file POC (proof of concept) funding to test the workload, or incremental workload (IW) funding if you already run on AWS and this is new work. For startups that is $50K to $150K. Depends on the workload; AWS approves. A partner can also build the workload with you: the tiered router that keeps Sonnet as the default, the RAG pipeline, the agent with tool use, and prompt caching.

Startups pay CloudRoute nothing. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding. For the details, see how POC funding works.