DeepSeek on Amazon Bedrock — models, access & pricing.

IWhich DeepSeek models are available on Amazon Bedrock

DeepSeek is one of the foundation-model providers reachable through Amazon Bedrock's single managed API, alongside Anthropic's Claude, Meta's Llama, Mistral, Amazon's own Nova and Titan, Cohere, and others. What people are usually searching for when they look up "DeepSeek on Bedrock" is the reasoning family — so that is where this starts.

DeepSeek became a household name on the strength of two model lines. The first is the DeepSeek-V3 family — a large mixture-of-experts (MoE) general-purpose chat-and-instruction model, competitive with frontier proprietary models on a wide range of tasks while activating only a fraction of its total parameters per token (which is what keeps inference cost down). The second, and the reason DeepSeek dominated the news cycle, is DeepSeek-R1 — an explicit reasoning model trained to "think" through a problem step by step before answering, in the same category as other test-time-reasoning models, but released with open weights and at dramatically lower cost.

On Bedrock you will typically encounter DeepSeek in two forms. DeepSeek-R1 (the reasoning model) is the marquee option and the one AWS highlighted when DeepSeek arrived on Bedrock. Alongside the full models sit the DeepSeek-R1 distilled variants — smaller models (distilled onto compact Llama- and Qwen-based backbones, in a range of parameter sizes) that capture much of R1's reasoning behaviour at a far smaller footprint, which makes them attractive to import and self-host through Bedrock. Whether a given DeepSeek model is offered fully-managed, available only via import, or both, changes over time and by region — so treat the specifics here as the durable shape and confirm the current catalog in the Bedrock console.

The practical way to think about the DeepSeek lineup on Bedrock mirrors how you think about any model family: there is a large flagship reasoning model for the hardest analytical and multi-step work, a general chat/instruct model for everyday tasks, and smaller distilled reasoning models for when you want reasoning behaviour at high throughput and low cost. The reasoning models earn their place specifically on problems where showing work matters — math, logic, complex coding, planning — and are usually overkill (and slower) for simple, high-volume requests.

One caveat, stated once and meant throughout: which exact DeepSeek models and versions are on Bedrock, whether each is serverless or import-only, the regions they are available in, their context-window sizes, and their per-token prices all change over time as DeepSeek ships new releases and AWS updates Bedrock. Everything here is representative as of 2026 to convey structure and relative cost. Confirm the current DeepSeek models and IDs in the Bedrock model catalog and current rates on the AWS Bedrock pricing page before you build or budget.

IIWhat a "reasoning model" is — and why DeepSeek-R1 is the headline

DeepSeek-R1 is the reason this page exists, so it is worth being precise about what a reasoning model actually does, where it shines, and where it does not — because "reasoning model" gets used loosely and the trade-offs are real.

A reasoning model is trained to spend additional computation at inference time — generating an internal chain of intermediate steps (a "thinking" pass) before committing to a final answer. Instead of producing the answer in one shot, it works the problem out, which materially improves accuracy on tasks that genuinely require multi-step deduction: competition-grade math, formal logic, hard algorithmic coding, scientific and quantitative analysis, and planning. DeepSeek-R1 was notable for reaching this class of behaviour with open weights and at a cost point far below the proprietary reasoning models it was compared against.

The trade-off is the same one every reasoning model carries, and you should price it in. The internal "thinking" consumes output tokens, so a single answer can generate many times the tokens of a non-reasoning model, which raises both latency and cost per request. That is a worthwhile trade on a hard problem where a wrong answer is expensive — and a poor one on a simple, high-volume request where a cheaper non-reasoning model would have answered correctly and instantly. The discipline is to route reasoning models to the requests that need reasoning, not to make them the default for everything.

This is also why DeepSeek-R1 and the Claude/Bedrock world fit together rather than purely compete. Anthropic's Claude exposes an extended-thinking mode for exactly this kind of hard task; Amazon's Nova and others have their own reasoning options; DeepSeek-R1 is another entry in that category with a distinctive cost and openness profile. Because all of them sit behind the same Bedrock API, you can pick the reasoning model per workload — or per request — without re-plumbing anything.

IIITwo ways to access DeepSeek on Bedrock — serverless vs imported

Unlike a model that is only ever offered one way, DeepSeek on Bedrock has two genuinely different access paths, and the right one depends on whether you want zero operational overhead or full control over a specific (often distilled) variant. Both keep the model inside your AWS account.

Getting either path running starts the same way as any Bedrock model: foundation models are off by default, so you request access once in the console (free; you only pay on invocation). From there the two paths diverge.

• Want zero ops and a managed DeepSeek model exists for your region? Use Path A (serverless) — enable access, call Converse, pay per token.
• Need a specific distilled R1 variant, a fine-tuned version, or a model not offered managed? Use Path B — import the open weights via Custom Model Import and serve them through the Bedrock API.
• Either way: the model runs inside your AWS account and chosen region, under your IAM, with the same Bedrock security and governance as every other model.
• For very heavy or specialised serving needs you can also run DeepSeek open weights on Amazon SageMaker (e.g. via JumpStart) — more control, more ops; see the Bedrock-vs-SageMaker sibling for where that line sits.

IVData governance — does my data go to DeepSeek? (No.)

Of every model on Bedrock, DeepSeek is the one teams most often ask a pointed data-governance question about, because of its provenance. The answer on Bedrock is clear and worth stating plainly: running DeepSeek on Bedrock is not the same as using a hosted DeepSeek service.

When you run DeepSeek on Amazon Bedrock, the model executes inside AWS's environment within your account and the AWS region you choose. It is the open-weights model running on AWS infrastructure — there is no call-out to any external DeepSeek-operated API or server. Your prompts and the model's responses are processed in your selected region and stay in that jurisdiction; they are not sent to DeepSeek, and as with every model on Bedrock, your inputs and outputs are not used to train the underlying base model. This is the central distinction from typing into a public DeepSeek consumer app or calling a DeepSeek-hosted endpoint directly: on Bedrock, the provenance of the weights is separate from where the model runs and where your data goes.

On top of that you get the same AWS-native controls as any Bedrock workload. Calls are authenticated and authorized with IAM (your existing roles and least-privilege policies); you can keep traffic on your private network with VPC endpoints (PrivateLink); you can encrypt with your own KMS keys; and you get a full audit trail in CloudTrail. You choose the region for data residency (relevant for GDPR and regulated workloads), and you can layer Bedrock Guardrails on top to filter inputs and outputs and block disallowed content regardless of which model is behind the API.

The honest framing for a security or compliance reviewer: the question is not "is DeepSeek safe?" in the abstract — it is "where does this model run, where does our data go, and what controls apply?" On Bedrock the answers are: in your AWS account and region; nowhere outside it; the full AWS security and governance stack. That is why running an open-weights model like DeepSeek through Bedrock is a posture most enterprises are comfortable with, where a public hosted endpoint would be a non-starter.

VDeepSeek on Bedrock — what it costs

DeepSeek's appeal is reasoning-class capability at low cost, and that shows up in the pricing. How you are billed depends on which access path you use — serverless per-token, or capacity-based for an imported custom model.

On the fully-managed (serverless) path, DeepSeek is billed like other Bedrock models: a rate per 1,000 input tokens and a higher rate per 1,000 output tokens, on demand. The table below gives a representative 2026 picture of where DeepSeek-R1 sits relative to a cheap, a mid, and a premium reference point on Bedrock — the point is the relative position (frontier-class reasoning well below premium proprietary reasoning prices), not an audited quote. One thing to budget for specifically with a reasoning model: the internal "thinking" is generated as output tokens, so even at a low per-token rate, a hard request can produce many output tokens and cost more than the headline rate suggests. Estimate reasoning workloads on expected total output, not just the visible answer.

On the imported / custom-model path (Bedrock Custom Model Import), billing is not per-token in the same way — it is based on the compute capacity used to serve your imported model (charged for the model copies/units active over time), plus storage for the weights. That changes the economics: imported models can be very cost-effective at steady, high utilisation, but you are paying for provisioned serving capacity rather than purely per request, so they suit sustained workloads more than spiky low-volume ones. The general Bedrock cost levers still apply where relevant — Batch for non-interactive bulk work (~50% off on supported serverless models) and prompt caching for repeated context — see amazon-bedrock-pricing for the full breakdown.

VIWhen to consider DeepSeek vs Claude vs Llama on Bedrock

DeepSeek is one strong option among several on Bedrock, not a default. A neutral orientation versus the two other open-or-frontier names teams weigh it against — Anthropic's Claude and Meta's Llama — keyed to what each is genuinely best at, rather than leaderboard headlines.

DeepSeek vs Claude. Reach for DeepSeek-R1 when the workload is heavy, explicit reasoning — math, logic, hard algorithmic coding, quantitative analysis — and you want strong results at a low cost point on open weights, or you specifically want to import and self-host a (possibly fine-tuned or distilled) variant for control. Reach for Claude when you want a polished, broadly-capable assistant with mature tool use, vision, large context, prompt caching, and extended thinking, strong instruction-following and writing quality, and the smoothest path to Bedrock Agents and Knowledge Bases. Many teams use both behind one API: DeepSeek-R1 for a reasoning-heavy path, Claude for general product surfaces. See claude-on-amazon-bedrock.

DeepSeek vs Llama. Both are open-weights families you can run fully-managed where offered or import/self-host, which makes them natural comparisons for teams that value openness, customisation, and avoiding lock-in. The difference is emphasis: Llama is a broad, well-supported general-purpose family with a huge ecosystem and a wide size range (great defaults for general chat, RAG, and fine-tuning); DeepSeek's distinctive edge is the R1 reasoning line and its cost-efficient MoE design. If your problem is reasoning-shaped, DeepSeek-R1 (or a distilled R1) is the more pointed choice; if you want a general open model with the largest ecosystem and tooling, Llama is the safer default. See llama-on-amazon-bedrock.

The meta-point is the one that recurs across the cluster: because every model sits behind the same Bedrock API, this is not a one-way door. You can start on DeepSeek-R1 for a reasoning feature, A/B it against Claude or Llama on part of your traffic, and re-tier as prices and capabilities move — and the structural advantages of running on Bedrock (IAM/VPC, consolidated billing, data residency, and AWS credits) apply no matter which model you land on. Benchmark the candidates on your own task and prompts rather than trusting generic leaderboards, since relative strengths shift with every release.

VIIUse cases and caveats

Mapped to where DeepSeek actually earns its place on Bedrock — and, just as important, where it does not. The pattern throughout: send reasoning-shaped work to the reasoning model, and keep everything else on a cheaper general model.

• Hard reasoning, math, and logic — DeepSeek-R1 — Where multi-step deduction, formal logic, quantitative analysis, or competition-grade math is the core of the task, the R1 reasoning pass measurably improves accuracy. Good fit for analytical copilots, scientific/financial reasoning, and verification steps where a wrong answer is costly.
• Complex and algorithmic coding — DeepSeek-R1 — For non-trivial code generation, debugging tricky logic, and algorithm design, reasoning models tend to outperform one-shot models. A practical pattern: a cheaper model drafts and handles boilerplate, with R1 reserved for the genuinely hard coding sub-tasks.
• High-throughput reasoning at low cost — distilled R1 (imported) — When you want reasoning behaviour but at scale and on a budget, an imported distilled R1 variant can carry much of the capability at a far smaller footprint — well suited to self-hosting via Custom Model Import at steady utilisation.
• A fine-tuned or controlled open model — imported DeepSeek — When governance, customisation, or domain fine-tuning argues for owning exactly which weights run, importing DeepSeek open weights into Bedrock gives you that control while AWS still handles serving and the API surface.
• Caveat — do not use a reasoning model as your default — For simple, high-volume, latency-sensitive requests (classification, extraction, routing, short replies), a reasoning model is slower and more expensive for no quality gain. Route those to a cheap general model (Nova, Haiku, or small Llama) and escalate only reasoning-shaped requests to R1.
• Caveat — budget for "thinking" tokens and confirm specifics — A reasoning model's internal thinking is billed as output, so estimate on total output, not the visible answer. And confirm current model availability, access path (serverless vs import), context window, and pricing in the Bedrock console — DeepSeek's footprint on Bedrock evolves.

VIIIHow AWS credits make running DeepSeek $0

Everything above prices DeepSeek 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 DeepSeek usage on Bedrock draws those credits down before it ever touches your card.

DeepSeek inference on Bedrock — whether serverless per-token or capacity-based for an imported model — is ordinary AWS spend, so it is fully credit-eligible, and credits apply automatically against your bill until exhausted. They cover DeepSeek tokens (or imported-model capacity), any Batch and prompt-caching usage on supported models, plus the supporting services around the workload (Knowledge Bases, a vector store, S3 for imported weights, 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 — a DeepSeek reasoning pilot is a textbook fit; and the competitive Generative AI Accelerator (awards up to $1M for a small cohort of AI-first startups).

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 DeepSeek workload — enabling the managed model or importing the distilled weights via Custom Model Import, wiring the reasoning path into a router that sends only the hard requests to R1, layering Guardrails, and standing up the RAG or agent around it. 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.

With the routing discipline above, the picture for a startup is: run DeepSeek-R1 only on the requests that need reasoning, keep the bulk on a cheap general model, serve it all under your own IAM and region with your data staying put, and fund the whole thing from a $25K–$100K (or larger) credit pool while you find product-market fit — paying real money only once usage, and ideally revenue, scales past the credits. Related: AWS credits for generative-AI startups and Bedrock POC funding for the full credit mechanics.