Amazon Bedrock Marketplace — 100+ specialized models, one Bedrock API.

IWhat Amazon Bedrock Marketplace is — and the problem it solves

Amazon Bedrock Marketplace is a catalog inside Bedrock that gives you access to over 100 specialized and emerging foundation models — beyond the handful of core providers offered as always-on serverless endpoints — and lets you deploy and call them through the same Bedrock API, console, and security controls you already use.

The core Bedrock catalog is broad but curated: a set of provider families (Anthropic Claude, Meta Llama, Mistral, Amazon Nova and Titan, Cohere, Stability AI, AI21, DeepSeek) served as fully-managed, pay-per-token serverless endpoints. That covers the large majority of production needs. But it is not the whole frontier. There are hundreds of high-quality models in the world — vertical-domain models trained on medical, legal, financial, or scientific corpora; strong multilingual models for languages the core set under-serves; specialized embedding and reranking models; vision and document-understanding models; and brand-new research releases that appear weeks or months before (or instead of) landing in the serverless pool. The Marketplace exists so you can use those models without leaving Bedrock.

The problem it solves is the one that used to force teams off-platform. Before Bedrock Marketplace, reaching a specialized model that AWS did not offer serverless meant one of two awkward paths: stand the model up yourself on raw GPU instances and own the entire serving stack (autoscaling, containers, drivers, the perpetual scarcity of accelerators), or send your data to a third-party model API outside AWS and lose your data-governance boundary. Marketplace collapses both. AWS handles the container, the model artifact, and the deployment plumbing; you choose an instance type and click deploy. And because the model runs inside your AWS account and Region, your prompts and outputs stay within your governance boundary — governed by IAM, logged to CloudTrail, the same as any core Bedrock model.

The mental model that matters: Bedrock Marketplace widens the catalog; it does not change the front door. Discovery happens in the Bedrock console, access is governed by Bedrock and IAM, and compatible models answer through the same InvokeModel (and, where supported, Converse) APIs. What changes is underneath — how the model is served and how you pay for it. Put precisely: the core serverless catalog is "models AWS runs for everyone, billed per token"; the Marketplace is "100-plus more models AWS makes deployable into your account, billed per instance-hour." Both are Bedrock; you move between them by choosing which kind of model your task warrants.

IIServerless vs. marketplace — deploy-to-an-endpoint vs. pay-per-token

Almost every decision about the Marketplace comes back to one structural difference: a core serverless model is an always-on shared endpoint you pay for by the token, while a marketplace model is usually a dedicated endpoint you deploy onto an instance and pay for by the hour. Internalize this and the rest of the page follows.

With a core serverless model, there is nothing to provision. AWS runs the inference fleet; you call the model by its model ID and are billed per 1,000 input and output tokens. Capacity is elastic and shared, idle costs nothing, and a model you do not call costs you exactly zero. This is the model behind most of the core Bedrock catalog and the reason "serverless" is the default mental picture of Bedrock.

With a marketplace model served via a managed endpoint, you make a deployment decision first. You pick the model, choose an instance type (a GPU-backed accelerated-compute instance sized to the model) and an instance count, and Bedrock provisions a dedicated endpoint that loads the model and stays running until you delete it. You then invoke that endpoint through the Bedrock API. The endpoint gives you dedicated, predictable capacity — but it bills per instance-hour the entire time it is up, whether it is serving one request a minute or none at all. The economics resemble Amazon SageMaker real-time endpoints more than serverless tokens, which is the single most important thing to understand before you deploy one.

A useful nuance: the line is not perfectly binary. A subset of Marketplace models is also offered in a serverless (pay-per-token) mode, and AWS keeps broadening which models can run serverless. So the first thing to check on any marketplace model is whether it runs serverless in your Region — if it does, you may get the wider catalog without taking on endpoint economics at all. If it does not, you are trading per-token simplicity for access to a model the serverless pool lacks, and you accept the per-hour, capacity-managed billing that comes with it.

The practical consequence shows up in utilization. A per-token model is efficient at any volume, including spiky and near-zero. A per-hour endpoint is only efficient when kept reasonably busy: at high steady throughput it can be cheaper per request than tokens, but at low or bursty volume you pay for idle capacity. That is why "do I have enough sustained traffic to justify an endpoint?" is as central to the marketplace decision as "is this model better for my task?"

IIIDiscovery — how the catalog is organized and how to evaluate a model

A hundred-plus models is only useful if you can find the right one. Discovery happens in the Bedrock console, where marketplace models are presented alongside the core catalog and filterable by the attributes that actually narrow a shortlist — provider, modality, task, and deployment option.

In the Bedrock console, the model catalog surfaces both the core providers and the Marketplace in one place, so you browse the wider set the same way you browse the core one. You filter by provider, by modality (text, vision, embeddings, image), by task or domain, and — critically — by deployment option (serverless vs. deploy-to-endpoint), so you can immediately see whether a candidate can run pay-per-token or will require an instance. Each model has a detail page with its description, the provider, supported instance types, applicable end-user license terms, and the deployment paths available to you.

Two filters do most of the work. The first is deployment option: if a model offers serverless, you can trial it for the cost of a few tokens before committing to anything; if it is endpoint-only, your evaluation has a per-hour cost the moment you deploy, so you plan the trial accordingly. The second is modality and task: a marketplace model usually earns its place by being specialized, so you are typically searching for a specific capability — a clinical or legal language model, a particular multilingual or code model, a strong reranker, a document-vision model — rather than a general-purpose chat model the core catalog already covers well.

Evaluation should be empirical, not brochure-driven. The same discipline that applies to choosing among core models applies doubly here: a specialized model's advantage is real only on the tasks it was specialized for, so confirm it on your data. Run a candidate against a representative slice of your real traffic and compare it head-to-head with the best core serverless model for the same job, weighing quality, latency, and — because an endpoint bills per hour — total cost at your expected utilization, not just per-request cost. Bedrock's model-evaluation tooling helps make that comparison structured rather than anecdotal.

• Filter by deployment option first — Serverless-capable models can be trialed for pennies; endpoint-only models cost per hour from the moment you deploy. Knowing which you are dealing with shapes the entire evaluation plan.
• Search by capability, not brand — Marketplace models earn their place by specialization — a vertical-domain, multilingual, embedding, reranking, or vision model. Start from the exact capability the core catalog under-serves.
• Check supported instance types and license terms — The model detail page lists the instances it can run on (which sets your per-hour cost) and any provider end-user license terms you must accept before deploying.
• Benchmark against the best core model for the job — A marketplace model only makes sense if it beats the strongest core serverless option on your task by enough to justify endpoint economics. Always compare, never assume.
• Evaluate on your own representative traffic — Use Bedrock model evaluation on a real slice of your data, scoring quality, latency, and total cost at your expected utilization — not vendor benchmarks.

IVThe deploy-and-invoke flow — from catalog to a managed endpoint

Using a marketplace model that requires an endpoint is a short, repeatable path: subscribe, deploy to an endpoint on an instance you choose, invoke it through the Bedrock API, then manage (and eventually delete) the endpoint so it stops billing. Here is the flow end to end.

The whole flow is designed so the only genuinely new step versus serverless is provisioning the endpoint; access, authorization, and invocation reuse the Bedrock mechanics you already know.

VBilling — endpoint and instance-based economics

Marketplace billing is where the platform feels least like serverless and most like running infrastructure. The dominant cost is the instance-hour, the dominant lever is utilization, and the figures below are representative as of 2026 to show relative shape — always confirm current instance options and rates on the AWS pricing pages.

The headline number for an endpoint-deployed model is the per-instance-hour rate of the accelerated-compute instance it runs on, multiplied by the number of instances, multiplied by the hours the endpoint is up. Some models also carry a separate software/usage charge from the model provider layered on top of the underlying compute, surfaced through AWS Marketplace; the model detail page makes the all-in rate explicit before you deploy. Because the meter runs on wall-clock time rather than tokens, your effective cost per request is entirely a function of how busy you keep the endpoint.

That makes the cost comparison against a core serverless model a utilization question, not a sticker-price one. At high, steady throughput, a dedicated endpoint can be cheaper per request than per-token pricing — you are buying capacity wholesale and using all of it. At low or bursty volume, the same endpoint is far more expensive than serverless, because you pay full freight for the idle hours between requests. There is a crossover point for every workload, and finding it (rough traffic profile × endpoint hourly cost vs. expected tokens × per-token price) is the core of the marketplace cost decision.

A few practices keep endpoint bills sane. Prefer a serverless deployment option when the model offers one and your volume is not high and steady — you avoid endpoint economics entirely. Right-size the instance to the model so you are neither paying for unused accelerator nor throttling throughput. Tear down idle endpoints and, for intermittent jobs, deploy-then-delete around the work. And remember the dependent costs that surround any GenAI app — the vector store behind a Knowledge Base, data transfer, logging — apply here just as they do to core Bedrock.

VIWhen a marketplace model beats a core Bedrock model

The Marketplace widens what is possible, but a wider catalog is not a reason to leave the core serverless pool. The honest rule is narrow: choose a marketplace model only when a specialized or newly-released model clears a real quality bar your core options cannot — and your traffic can keep an endpoint busy.

Default to a core serverless model for the broad middle of GenAI work: general reasoning, chat, summarization, extraction, coding, and agents, especially at bursty or modest volume where per-token billing and zero idle cost are exactly what you want. The core catalog is deliberately strong across these jobs, and the operational simplicity of serverless is a real, ongoing advantage you give up the moment you take on an endpoint.

Reach into the Marketplace when one of a few specific conditions holds. Specialization: a vertical-domain model (clinical, legal, financial, scientific) or a specific multilingual, embedding, reranking, or vision model materially outperforms every core option on your task. Recency: a just-released research model you need is not yet in the serverless pool, and the Marketplace is the fastest compliant way to use it inside AWS. Control or portability: you need a particular open model you intend to standardize on, with dedicated capacity and predictable latency. In each case, the second test still applies — you need enough sustained throughput (or a tolerance for deploy-then-delete) to make per-hour billing rational.

When neither specialization nor recency nor control is in play, the Marketplace is usually the wrong tool, because you would be taking on endpoint economics and operational overhead to run a model a core serverless option already handles well. And if the marketplace model you want offers a serverless deployment option, prefer that — you get the wider catalog without the idle-cost downside. For the broader build-vs-buy framing across the platform, see Bedrock vs SageMaker; for the full serverless catalog you are comparing against, see the Bedrock model catalog.

VIISecurity and governance — the Bedrock boundary still holds

The reason to reach a specialized model through Bedrock Marketplace rather than a third-party API is governance. A marketplace model runs inside your AWS account and Region and inherits the same controls as the core catalog — so widening the model set does not widen your data-exposure surface.

Your data stays in your account and Region. A marketplace model deployed to an endpoint runs on instances inside your AWS account, in the Region you choose, and your prompts and outputs are processed there rather than being shipped to an external provider API. That is the central security advantage over calling a specialized model's own hosted endpoint outside AWS: the data-residency and data-control boundary you rely on for core Bedrock applies to the wider catalog too.

It plugs into your existing controls. Access is governed by IAM, scoped where useful to the specific endpoint and actions a service needs. Endpoints can be reached privately via VPC networking so traffic need not traverse the public internet. Every deploy, invoke, and delete is recorded in CloudTrail, and you can layer Bedrock Guardrails on top for content filtering and PII handling the same way you would for a core model. See Bedrock Guardrails for that safety layer.

Mind the differences that do come with self-served models. Two honest caveats. First, licensing: each marketplace model carries its own provider end-user license terms that you accept at subscription — read them, because permitted uses vary across models. Second, shared responsibility for capacity and patching of the model layer: a dedicated endpoint is more your infrastructure than a shared serverless model is, so monitoring its utilization, sizing, and lifecycle is on you in a way that a fully-managed serverless model is not. None of this changes the data-governance boundary; it just means an endpoint is operationally closer to running a service than to calling an API.

VIIIModel categories — examples of what the marketplace adds

The 100-plus models are not random; they cluster into categories that the curated serverless core deliberately leaves room for. These are representative examples of the kinds of models the Marketplace is for — the catalog evolves continuously, so treat them as categories to look for rather than a fixed list.

Across the categories below, the pattern is the same: each is a place where a specialized or newer model can beat a general-purpose core model on a specific job. Browse the Marketplace by these categories when the core catalog under-serves the exact capability you need.

• Vertical-domain language models — Models pre-trained or tuned on a specific field — clinical and biomedical, legal, financial, or scientific text — that can outperform a general model on in-domain terminology, reasoning, and formatting. The classic reason to leave the serverless core.
• Multilingual & region-specific models — Models with deep coverage of languages or scripts the core set under-serves, useful when you operate in markets a general-purpose model handles only adequately.
• Specialized embedding & reranking models — Task- or domain-specific embedding models and rerankers that can lift retrieval quality in a RAG pipeline beyond a general embedding model — the quiet workhorses of search-shaped systems.
• Code & developer-tooling models — Models specialized for code generation, completion, review, or a particular language ecosystem, where a code-tuned model can beat a general chat model on developer tasks.
• Vision & document-understanding models — Image-understanding, OCR-adjacent, and document-layout models for extracting structure from scans, forms, and complex documents.
• Frontier & emerging research models — Newly-released models — including strong open-weight reasoning models — that you want to evaluate or run inside AWS before, or instead of, they appear in the serverless pool.
• Open-weight models you intend to standardize on — Specific open models you want to run with dedicated capacity, predictable latency, and a clear license, rather than depending on a shared serverless endpoint. For deeper customization, contrast with custom model import and fine-tuning.

Two of these categories sit next to capabilities elsewhere in Bedrock, and it is worth keeping them distinct. If you have your own weights (a model you trained or heavily fine-tuned outside Bedrock) and want to serve them through the Bedrock API, that is Custom Model Import, not the Marketplace — the Marketplace is for third-party and provider models you discover and deploy, whereas Custom Model Import is for bringing your own. And if you mostly need to specialize a core model on your data rather than adopt a different one, Bedrock fine-tuning is often the simpler path. The Marketplace is specifically the answer to "I need a different model than the core catalog offers, and I want it inside Bedrock."

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

Endpoints make the marketplace powerful and make its bill less forgiving than serverless. This is where the catalog and the funding story meet.

The Marketplace inverts serverless cost in one important way: idle is expensive. A trial that left a large GPU endpoint running over a weekend, or a production endpoint sized for peak but mostly idle, can turn a modest experiment into a meaningful bill — precisely because you pay per instance-hour regardless of traffic. The levers throughout this page keep it sane: prefer a serverless deployment option when one exists, right-size the instance, tear down idle endpoints, and deploy-then-delete around intermittent work.

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, and they apply to marketplace endpoints and serverless calls alike: 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 — including choosing between a core serverless model and a marketplace endpoint, right-sizing the instance, and wiring the deploy-and-invoke flow 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.