Every model on Amazon Bedrock — the complete 2026 catalog.

IHow the Bedrock model catalog is organized

Amazon Bedrock's defining feature is breadth: a single, fully-managed API in front of foundation models from eight-plus providers, covering text and chat, reasoning, image generation, video generation, and embeddings. Before the catalog table, it helps to understand the four axes that actually distinguish one model from another.

The first axis is provider. Each provider on Bedrock brings a distinct lineage and set of strengths: Anthropic (the Claude family) for frontier reasoning, coding, and agentic tool use; Amazon with two lines — the newer Nova family tuned for very low cost and latency, and the older Titan family still useful for text and especially embeddings; Meta (Llama) for strong open-weight, freely fine-tunable models; Mistral for fast, price-efficient throughput; Cohere for retrieval, embeddings, and reranking; Stability AI for image generation; AI21 for the long-context Jamba family; and DeepSeek for cost-efficient open reasoning models. You are never locked to one — they all live behind the same authentication, billing, and (for chat) request schema.

The second axis is modality: what kind of input and output the model handles. Most of the catalog is text/chat (some with vision input). A subset is reasoning-tuned for harder multi-step problems. A separate group does image generation (Amazon Nova Canvas, Stability's Stable Diffusion / Stable Image), one does video generation (Amazon Nova Reel), and a distinct class produces embeddings — the numeric vectors that power semantic search and retrieval-augmented generation rather than human-readable text.

The third axis is the context window — how many tokens of input (prompt plus retrieved documents plus conversation history) the model can consider at once. Larger windows let you stuff in whole contracts, codebases, or long chat histories without aggressive chunking, but a bigger window costs more per call because you are paying for every input token. Context windows differ widely across the catalog and are raised over time, so the table gives representative orders of magnitude rather than guarantees.

The fourth axis is cost, which on Bedrock is almost always per token (per 1,000 input tokens and per 1,000 output tokens), set per model, with output priced several times higher than input. Image models bill per image and video models per second of output. Because the cheapest text models are roughly two orders of magnitude cheaper than frontier ones, which model you send each call to is the single biggest driver of a Bedrock bill — which is why this catalog frames every family by relative cost as well as capability.

IIThe full model catalog — every family on Bedrock

This is the comprehensive map: every model family on Amazon Bedrock with its provider, representative models, modality, an approximate context-window order of magnitude, best-fit use, and relative cost on a $ (cheapest) → $$$$ (frontier) scale. Exact versions, context windows, and prices vary by Region and change continuously — confirm the live list under Model access in the Bedrock console and current rates on the AWS pricing page.

Two reading notes. First, relative cost is a position on a curve, not a rate: $ means an order of magnitude cheaper than $$$$, and the goal is to show where each family sits so you can route calls deliberately. Second, context windows are representative — they are raised over time and a few frontier models support very large windows in specific Regions or configurations, so treat the column as "roughly this scale," not a contractual ceiling. Each family links to its own deep page where one exists.

IIIThe catalog by modality — text, reasoning, image, video, embeddings

The single table above is sorted by family; in practice you choose by the job in front of you. Here is the same catalog sliced by what you are actually trying to produce, which is usually the faster way to land on a shortlist.

IVHow to choose a model (and why you usually pick several)

The most common Bedrock question is not "which platform" but "which model on the platform." There is no single right answer because the models sit at different points on a cost/capability curve — but there is a reliable decision procedure.

Start from the job, not the brand. Define the task (classify, extract, summarize, reason, write code, generate an image, embed for search), the quality bar it actually needs, the latency budget, and the volume. Then map those onto the curve: a high-volume, low-difficulty task wants the cheapest model that clears the quality bar; a low-volume, high-difficulty task can justify a frontier model; anything involving search or grounding needs an embedding model regardless of which chat model sits on top.

The second principle is that production systems rarely pick one model — they route. The dominant cost-control pattern sends the easy majority of calls (often 80–95%) to a small, cheap model and escalates only the hard remainder to a workhorse or frontier model, with an embedding model handling retrieval throughout. Because every chat model shares the Converse API, this routing is a configuration decision, not a rewrite: you change the modelId string per call path. A support assistant might run Nova Lite or Claude Haiku for intent classification, Claude Sonnet for the actual grounded answer, Titan or Cohere for retrieval, and reach for Claude Opus or Nova Premier only on escalations.

The third principle is to decide with evidence, not vendor benchmarks. Public leaderboards rarely reflect your data, your prompts, or your latency and cost constraints. Bedrock's built-in model evaluation lets you compare candidate models on your own datasets — using automated metrics or human review — before you commit. Run a short evaluation across two or three candidates from different tiers on a representative slice of your real traffic; the cheapest model that passes your bar is almost always the right production choice, with a more capable model wired in as the escalation path.

• Match the model tier to the task difficulty — Cheap small model for easy, high-volume calls; workhorse for production reasoning and agents; frontier only for the hardest steps. Over-provisioning the model is the most common source of avoidable Bedrock spend.
• Mind the context window — If you routinely feed whole documents, long histories, or large retrieved contexts, favor a larger-window model (Claude, Jamba, larger Nova) — but remember you pay per input token, so a big window plus a big prompt on every call adds up. Pair large windows with prompt caching.
• Pick embeddings for anything search-shaped — RAG, semantic search, clustering, and recommendations are embedding-model jobs (Titan, Cohere Embed). The chat model on top is a separate choice from the embedding model underneath.
• Prefer open-weight when you need fine-tuning freedom — Meta Llama and several open models can be fine-tuned freely and have a self-hostable lineage, which matters if portability or deep customization is a requirement.
• Use a dedicated media model for pixels — Do not try to coerce a text model into image/video work — route to Nova Canvas / Stable Image for images and Nova Reel for video.
• Evaluate on your own data before committing — Run a Bedrock model evaluation across a couple of candidate tiers on representative traffic. Choose the cheapest model that clears the bar and keep a stronger one as the escalation path.

VHow to access a model — Model access, IAM, Regions, and modelId

Models in the catalog are off by default. You explicitly request access per model, govern it with IAM, choose a Region, and then call the model with the shared Converse API (or InvokeModel for non-chat modalities). The catalog is large, but turning any one model on is the same short path.

Access is opt-in by design: AWS wants every model your organization can call to be a deliberate, auditable decision, and several models carry provider end-user license terms you must accept first. The flow has four parts.

VIWhat the models cost — the shape of Bedrock pricing

You do not need a price for every model to reason about cost — you need the shape. Bedrock has no platform fee and no minimum; you pay per use, and the catalog spreads across roughly two orders of magnitude from cheapest to frontier. The figures below are representative as of 2026 to show relative scale, not audited rates — always confirm on the AWS Bedrock pricing page.

Text models are billed per 1,000 input tokens and per 1,000 output tokens, at a rate set by the specific model, with output almost always several times more expensive than input. Embedding models are billed per 1,000 input tokens with no output-token charge (the output is a vector). Image models bill per image and video models per second of generated output. On top of per-call pricing, the same four levers apply across the whole catalog: on-demand (default), batch (asynchronous, typically ~50% cheaper), provisioned throughput (reserved capacity for high steady volume and for serving fine-tuned models), and prompt caching (a steep discount on repeated context). The detail lives on the Bedrock pricing page.

The practical takeaway is the same one that drives model selection: because a small model can be ~50–100× cheaper per token than a frontier model, routing the easy majority of calls to a small model is usually a bigger cost win than any negotiation or discount. The price table below exists to make that spread concrete.

VIIEach model family, in depth

This page is the catalog hub; each major family has its own reference page with the full version lineup, context windows, pricing, setup, and use-case detail. Use this section as the index into them.

Because the whole catalog shares one access model and one request schema, the deep pages differ mainly in the model lineups, context windows, and prices — the mechanics of enabling and calling them are identical to section V. Start from the family that fits your job, evaluate two or three candidates on your own data, and route accordingly.

• Claude on Amazon Bedrock — Anthropic's Claude family — the Haiku/Sonnet/Opus tiers, long-context behavior, tool use and agents, setup, and cost. The most widely deployed models on Bedrock for serious reasoning. See Claude on Amazon Bedrock.
• Amazon Nova — Amazon's own foundation-model family — Micro/Lite/Pro/Premier for text, Canvas for images, Reel for video, and Act for agentic actions — engineered for very low cost and latency. See Amazon Nova.
• Amazon Titan — Amazon's earlier family — Titan Text and, most importantly, Titan Text and Multimodal Embeddings, the economical default for RAG and semantic search. See Amazon Titan.
• The platform itself — How access, the Converse API, the feature suite (Agents, Knowledge Bases, Guardrails, fine-tuning, Flows, evaluation), and security fit together across every model. See Amazon Bedrock — the complete guide.
• Pricing across the catalog — The full breakdown of on-demand, batch, provisioned throughput, prompt caching, and customization costs for the models above. See Amazon Bedrock pricing.
• Meta Llama, Mistral, Cohere, Stability, AI21, DeepSeek — The remaining providers — open-weight Llama, fast Mistral, Cohere's retrieval and rerank models, Stability's image models, AI21's long-context Jamba, and DeepSeek's cost-efficient reasoning models — are all enabled and called the same way via Model access and the Converse/InvokeModel APIs described in section V.

VIIIThe cost reality — and how AWS credits fund your Bedrock build

Choosing the right models keeps unit cost sane; the harder problem is the aggregate bill once a real application serves real traffic. This is where the catalog and the funding story meet.

GenAI is cheap per call and expensive in aggregate. A retrieval-augmented assistant that resends a large system prompt and retrieved context on every turn, across thousands of users, can move from a rounding error to five or six figures a month faster than teams expect — especially if every call hits a frontier model. The levers throughout this page are how you keep it sane: route the easy majority to small models, run offline work as batch (~50% off), turn on prompt caching for repeated context, and reserve provisioned throughput only once volume is steady and high.

The other lever is funding the bill with someone else's money — specifically AWS's. AWS runs credit programs designed precisely for teams building generative AI on Bedrock: Activate Portfolio (up to $100K) for institutionally-funded startups, dedicated Bedrock / GenAI proof-of-concept funding ($10K–$50K) for a defined GenAI build, and the competitive Generative AI Accelerator (up to $1M) for AI-first companies. These pools are largely partner-filed and effectively invisible on the public Activate page.

This is exactly what CloudRoute does: we route you to a vetted AWS partner who files the credit application and, if you need hands, who can build the Bedrock workload with you — choosing and wiring the right models from the catalog above. Because AWS funds both the credits and the partner engagement, you pay $0. See AWS credits for generative-AI startups, AWS PoC / Bedrock POC funding, and $100K AWS credits.