Amazon Bedrock Custom Model Import — bring your own fine-tuned model.

IWhat Custom Model Import actually is

Custom Model Import is the Bedrock feature for bringing your own model. If you have already fine-tuned an open-weights model somewhere else — your own GPUs, SageMaker, another platform — Custom Model Import lets you upload those weights and have Bedrock serve them behind its standard, fully-managed API, exactly as if they were a native Bedrock model.

Most of the customization story on Bedrock is about adapting models that AWS hosts for you. Custom Model Import inverts that: you supply the model. You have a checkpoint — a set of fine-tuned weights for a supported architecture, sitting in a directory of safetensors files and config — and you want to call it through Bedrock instead of standing up and babysitting your own inference server. Custom Model Import takes that checkpoint, registers it as a custom model in your account, and from then on you invoke it with the same Bedrock runtime API you use for everything else.

The crucial property is that the imported model runs on-demand and serverless. You do not create or manage an endpoint, you do not choose instance types, you do not run an autoscaler, and you do not pay a flat hourly fee to keep it warm. Bedrock loads your model onto managed accelerators when requests arrive, serves them, and releases the capacity when traffic stops — billing you only for the compute your model actually uses. From the application's point of view it is just another model ID behind InvokeModel; the fact that the weights are yours is an implementation detail.

This makes Custom Model Import the bridge between two worlds that used to be separate: the freedom of open-weights fine-tuning (you own the model, you trained it exactly how you wanted, on whatever data and recipe you chose) and the operational simplicity of a managed model API (no servers, one auth model, one bill, the same Bedrock features around it). You get to keep the model you built and stop operating the infrastructure to serve it.

One caveat, stated once and meant throughout: the exact list of supported architectures, the regional availability, the size limits, and the precise pricing for Custom Model Import change as the feature evolves. The specifics here are representative as of 2026 to convey the shape of the feature and its economics. Always confirm the current supported-architecture list, Regions, quotas, and Custom Model Unit pricing on the official AWS Bedrock documentation and pricing pages before you build around them.

IIWhy it exists — the gap between owning a model and serving one

Teams fine-tune open-weights models for good reasons: full control of the training recipe and data, no per-token vendor pricing, the ability to take the weights anywhere. The pain comes the day they have to put that model into production and keep it running. Custom Model Import is the answer to that second problem.

Serving an open-weights LLM yourself is real systems work. You provision GPU instances (often scarce and expensive), pick an inference server, handle model sharding and quantization, build autoscaling that reacts to traffic, manage health checks and rolling deploys, and pay for the accelerators 24/7 — including all the hours nobody is sending requests. For a small team, or for a model that only gets occasional traffic, that standing cost and operational load can dwarf the value of having fine-tuned the model in the first place.

The two managed alternatives each have a catch. Calling a hosted model API means giving up your own weights and accepting per-token vendor pricing. Hosting your model on a dedicated endpoint (whether SageMaker or your own cluster) means paying for that endpoint continuously, whether or not it is busy. Custom Model Import threads the needle: you keep your own fine-tuned weights, and Bedrock serves them without a continuously-running endpoint — you pay for active compute and the model scales to zero when idle. For intermittent or unpredictable workloads, that pay-for-what-you-use shape is the whole point.

It also unifies your stack. Once your model is imported, it lives alongside Claude, Nova, Llama, Mistral and the rest under one IAM boundary, one billing relationship, and the broader Bedrock toolset. The same governance, logging (CloudTrail, model-invocation logging), and many of the same Bedrock features apply. You stop maintaining a separate serving system that exists only to host one fine-tuned model, and you fold it into the platform you are already using for the rest of your generative-AI workload.

IIISupported architectures — what you can (and cannot) import

Custom Model Import does not accept arbitrary models. It supports a defined set of well-known open-weights architectures, and your model has to match one of them. The reason is mechanical: Bedrock has to know how to load and run the weights, so the architecture must be one it has built serving support for.

The supported set centers on the popular open text architectures. As a practical 2026 guide, Custom Model Import has supported architectures in the Meta Llama family, the Mistral and Mixtral families, and encoder-decoder/text models such as Flan-T5, along with other widely-used open architectures that AWS adds over time. The key word is architecture: support is keyed to the model's structure, not its name. Any model whose architecture matches a supported one — including your own fine-tune, a continued-pre-trained variant, or a community model built on that architecture — can generally be imported. A model built on an unsupported or bespoke architecture cannot.

There are practical requirements on the artifacts themselves. You import a model in the standard open-weights layout: the weights (commonly safetensors), the configuration files, and the tokenizer files that together define the model, staged in Amazon S3. The model has to be a compatible precision and size for Bedrock to serve, and there are parameter-count and context-length ceilings on what can be imported (see the limits in §VIII). The important discipline is the same one that trips up every customization plan: confirm your exact architecture and size are on the current supported list before you design around importing it, because this is the most common place an import plan breaks.

What you bring is typically a model you fine-tuned or further-trained yourself outside Bedrock — on SageMaker, on your own accelerators, or anywhere you had the freedom to train exactly the way you wanted. Custom Model Import does not train anything; it assumes you have already produced the weights. (If you want AWS to do the training for you, that is Bedrock fine-tuning, covered in §VII and in the amazon-bedrock-fine-tuning sibling.)

IVThe import workflow — from S3 weights to a callable model

The mechanics are deliberately simple: stage the model files in S3, run a one-off import job, and then invoke the imported model through the standard Bedrock runtime API. No endpoints, no containers, no instance configuration.

The whole flow is a one-time setup followed by ordinary inference. Here is what each step actually involves.

VHow billing works — Custom Model Units and active compute

This is the part that distinguishes Custom Model Import from every dedicated-hosting option, and the part most worth understanding before you commit. You are not billed a flat hourly rate to keep an endpoint warm. You are billed for the compute your model actively uses, in short windows, with no charge while it is idle.

Custom Model Import meters serving in Custom Model Units (CMUs). A larger or longer-context model needs more of this dedicated compute to serve a request than a small one, so the number of CMUs your model requires scales with its size and context length. The billing shape that matters: you pay for CMUs only while the model is actively processing, charged in roughly 5-minute increments of active inference compute, rather than as a continuous hourly reservation. When no requests are in flight and the model has scaled to zero, that compute charge stops.

Contrast this with serving a Bedrock fine-tuned model on Provisioned Throughput, which bills a flat hourly rate continuously for as long as the model is deployed, whether or not you send it traffic. For an intermittent workload — a model that is busy in bursts and idle the rest of the day — the Custom Model Import economics are dramatically better, because you are not paying for all the idle hours. For a workload that is busy essentially all the time, the comparison narrows, and a reserved option can become competitive again at the top end.

Two things to keep in mind beyond the per-compute charge. First, there is typically a storage charge for keeping your imported model artifacts available to Bedrock — a small recurring cost separate from inference. Second, because billing tracks active compute in short windows, a stream of sporadic single requests can each pull the model onto compute and incur a minimum window, so very spiky one-off traffic is not always as cheap per request as steady bursts. As always, the figures and the exact unit definitions here are representative for 2026 — confirm current CMU pricing, the window granularity, and storage charges on the AWS Bedrock pricing page.

VICold-start behaviour — the price of scaling to zero

Scaling to zero is what makes the economics good, and it is also the one behaviour you have to design for. When an imported model has gone idle and been released from compute, the next request has to wait for it to be loaded back onto an accelerator. That is the cold start.

The mechanism is straightforward. Because Bedrock is not holding your model warm on dedicated capacity around the clock, a request that arrives after a period of inactivity triggers the model to be loaded onto an accelerator before it can respond. That load adds latency to the first request — on the order of seconds, and longer for larger models, since more weight has to be moved into memory. Once the model is warm, subsequent requests are served at normal speed; the cold start is a property of the first request after idleness, not of steady traffic.

Whether this matters depends entirely on your workload. For asynchronous and batch-like use — background document processing, enrichment jobs, internal tools, anything where a few extra seconds on the first call is invisible — the cold start is a non-issue and the scale-to-zero savings are pure upside. For latency-critical, user-facing paths where every interaction must respond instantly even after a quiet period, an unpredictable first-request delay can be a real problem, and you should test it against your latency budget rather than assume it away.

There are sensible ways to manage it. You can keep the model warm with a low-rate heartbeat of synthetic requests so it rarely scales fully to zero during business hours (trading a little compute cost for predictable latency), route latency-critical traffic to an always-available base model and reserve the imported model for tolerant paths, or simply accept the cold start where the workload allows. The honest framing: Custom Model Import is at its best for intermittent, latency-tolerant workloads. If you truly need constant, instant, sustained serving, that is the profile where a reserved option (Provisioned Throughput, or a dedicated SageMaker endpoint) earns its standing cost — which is exactly the decision §VII lays out.

VIICustom Model Import vs Bedrock fine-tuning vs SageMaker hosting

These three are easy to confuse and serve genuinely different needs. The cleanest way to choose is to ask two questions: did you already train the model yourself, and how steady is the traffic? Match the answer to the right tool rather than to whichever sounds most capable.

Here is the diagnostic, in plain terms:

• You already fine-tuned open weights yourself, want them on the Bedrock API, and traffic is intermittent → Custom Model Import — You own a Llama/Mistral/Flan-T5-class fine-tune and want managed serverless serving with scale-to-zero economics — no training, no endpoint, pay for active compute. This page's tool.
• You want AWS to do the training, and you have steady high volume → Bedrock fine-tuning — Bedrock trains a base model from your JSONL dataset and serves the result on Provisioned Throughput (a flat hourly bill). Right when you want managed training and your volume is high and steady enough to keep reserved capacity busy. See the amazon-bedrock-fine-tuning sibling.
• You need full control of the serving stack, custom containers, or an unsupported architecture → SageMaker hosting — SageMaker real-time/async/serverless endpoints let you bring any model, any container, any architecture, with full control over instances, scaling, and the inference pipeline — at the cost of operating it. See the deploy-open-source-llm-on-aws sibling.
• Your traffic is constant and latency-critical → a reserved option, not import — If the model must serve instantly around the clock with no cold start, the scale-to-zero model is the wrong fit. Provisioned Throughput (for a Bedrock model) or a dedicated SageMaker endpoint earns its standing hourly cost at constant high volume.
• You only need a style/format tweak and have no weights yet → fine-tune (or even just prompt/RAG) — If you have not trained anything and only need a behaviour change, Bedrock fine-tuning — or, cheaper still, prompt engineering and RAG — may be the answer, not importing a model you would have to train first.

VIIILimits, quotas, and operational notes

Custom Model Import is powerful but bounded. Knowing the limits up front prevents the two most common failures: designing around an architecture or model size that cannot be imported, and being surprised by cold starts or Region gaps in production.

The constraints worth checking before you commit:

• Architecture must be on the supported list — Only specific open architectures (Llama-family, Mistral/Mixtral, Flan-T5-class, and others added over time) can be imported. A bespoke or unsupported architecture is a hard stop — verify yours first.
• Size and context-length ceilings apply — There are upper bounds on parameter count and context length for an importable model, and a supported precision/format for the artifacts. Very large or unusual models may exceed them; check the current quotas.
• Artifacts must be complete and well-formed in S3 — You need the full set — weights (commonly safetensors), config, and tokenizer files — in the expected layout, in the same Region, readable by the import job's IAM role. Incomplete or mismatched artifacts fail the job.
• Regional availability is limited and evolving — Custom Model Import is available in a subset of AWS Regions, and your imported model serves in the Region you import it into. Confirm the feature is offered in the Region your data residency and latency requirements need.
• Cold start is inherent to scale-to-zero — The first request after idleness incurs load latency (seconds; more for larger models). It is a feature trade-off, not a bug — design latency-critical paths accordingly (keep-warm, or route hot paths elsewhere).
• Per-account quotas and concurrency limits — There are limits on the number of imported/custom models and on concurrent serving capacity per account, some of which are soft and raisable via a support request. Plan for them if you intend to import many models.
• You manage model governance and updates — An imported model is a static snapshot of the weights you uploaded; improving it means training a new version and re-importing. Bedrock serves what you gave it — versioning and retraining are your responsibility.

IXHow AWS credits fund the import — and the inference

Everything above prices Custom Model Import if you pay AWS directly. For most startups and many companies the relevant number is different, because AWS will frequently fund the work with credits — and the import job, the per-compute inference, the artifact storage, and anything you pair around the model draw those credits down before they ever touch your card.

The whole Custom Model Import workload is credit-eligible: the import job, the Custom Model Unit charges for serving your model, the S3 storage for the artifacts, and any surrounding services — a Knowledge Base for RAG, embeddings, Guardrails — all draw down AWS credits, which apply automatically against your bill until exhausted. The relevant pools are AWS Activate (general startup credits, commonly up to $100K for institutionally-funded startups), a dedicated Bedrock / Generative-AI POC pool ($10K–$50K) aimed specifically at proving out a GenAI use case — which is exactly what importing and evaluating a fine-tuned model is — and the competitive Generative AI Accelerator (awards up to $1M for a small cohort of AI-first startups).

Credits matter here for a specific reason. Custom Model Import already has the friendliest cost shape of the hosting options — scale-to-zero, pay-for-active-compute — but if you are running a real evaluation, comparing your imported fine-tune against base models, and ramping traffic during a launch, those compute charges are still the kind of spend a seed-stage team would rather not pull from runway. Credits cover exactly that proof-out and ramp period, so you can import the model, run a proper head-to-head, and only commit real money once the workload is proven and growing.

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 ML partner who both files the credit application and does the work: preparing the artifacts, running the import job, wiring the model into your application behind the Bedrock API, setting up evaluation, and advising honestly on whether Custom Model Import, Bedrock fine-tuning, or SageMaker hosting is the right home for your model. 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. Related: AWS credits for generative-AI startups and Bedrock POC funding.