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

IWhat Custom Model Import is

If you already customized an open-weights model somewhere else, Custom Model Import lets Bedrock serve it behind its standard managed API.

AWS describes it as importing foundation models you customized in other environments, such as SageMaker, for example a model with proprietary weights (see the Custom Model Import guide). You supply the checkpoint; Bedrock registers it as a custom model in your account, and you call it with InvokeModel or InvokeModelWithResponseStream.

The imported model runs on demand. You do not create an endpoint, pick instance types or run an autoscaler. Bedrock runs model copies as requests arrive and scales them with demand.

AWS lists three patterns it supports: a fine-tuned model (new weights, same configuration as the base), a domain- or language-adapted model (often with vocabulary changes), and a model pre-trained from scratch on a supported architecture (with changed heads, layers or context length).

IIWhy it exists

Training an open-weights model gives you control. Serving it yourself is the hard part.

Self-hosting an LLM means GPU instances, an inference server, sharding and quantization, autoscaling, health checks and deploys, and paying for accelerators around the clock, including idle hours. For a small team or a model with occasional traffic, that cost and effort can outweigh the value of the model.

Custom Model Import keeps your weights and removes the always-on endpoint. The model also sits under the same IAM, CloudTrail and invocation logging as the rest of your Bedrock use.

IIISupported architectures

Your model must match a supported architecture, because Bedrock has to know how to load and run it.

• Mistral and Mixtral: Decoder-only transformers, including sparse mixture-of-experts (Mixtral).
• Flan (T5): Encoder-decoder transformer.
• Llama: Llama 2, Llama 3, 3.1, 3.2, 3.3 and Mllama.
• GPTBigCode: An optimized GPT-2 variant.
• Qwen: Qwen2, Qwen2.5, Qwen2-VL, Qwen2.5-VL, and Qwen3 (Qwen3ForCausalLM and Qwen3MoeForCausalLM only; Converse is not supported for Qwen3).
• GPT-OSS: 20B- and 120B-based custom models, US East (N. Virginia) only.

Limits AWS lists: weights under 200 GB for text models and 100 GB for multimodal models; maximum context length under 128K; transformers version 4.51.3 when you fine-tune. Embedding models cannot be imported. Check the current list before you plan around a model, because this is where import plans most often fail.

IVThe import workflow

Stage files in S3, run one import job, then call the model.

• 1. Stage the files in S3: Hugging Face-format model files: weights in .safetensors, plus the config and tokenizer files the transformers library creates. Use a supported Region and an IAM role that can read the bucket.
• 2. Run a model import job: In the console or API, point the job at the S3 URI and name the model. Bedrock detects the architecture, ingests the weights and registers a custom model.
• 3. Invoke it: Call InvokeModel or InvokeModelWithResponseStream with the imported model's ARN. Converse works for many architectures but not Qwen3. Custom chat templates and tokenizers are documented separately.
• 4. Bedrock serves it on demand: Bedrock runs and scales model copies with demand. You deploy nothing.

VBilling: Custom Model Units and 5-minute windows

You pay for running model copies, not for a reserved endpoint.

A Custom Model Unit (CMU) is AWS's measure of the hardware needed to host one copy of your model; Bedrock sets the CMUs per copy at import. AWS gives this formula (see calculate the cost of a custom model): total cost = running model copies × CMUs per copy × price per CMU per minute × (number of 5-minute windows ÷ 60). Billing runs in 5-minute windows from the first successful inference call.

Bedrock raises or lowers the number of running copies as demand changes (track it with the CloudWatch ModelCopy metric). That suits intermittent traffic better than a model on Provisioned Throughput, which bills hourly while deployed. For constant high volume the gap narrows. Check the Custom Model Import tab on the Bedrock pricing page for current per-CMU rates, and budget for artifact storage in S3.

VICold starts

When no copy is running, the next request waits while Bedrock loads the model onto an accelerator.

The first request after an idle period is slower, and larger models take longer to load. Warm requests are not affected.

For asynchronous work, internal tools and background processing, this rarely matters. For latency-critical user paths, test it against your latency budget. Options: send a low-rate keep-warm request during busy hours, route hot paths to a base model that is always available, or use a reserved option.

VIICustom Model Import vs Bedrock fine-tuning vs SageMaker hosting

Ask two questions: who trains the model, and how steady is the traffic?

• You already customized open weights and traffic is intermittent → Custom Model Import: Managed on-demand serving with no endpoint.
• You want AWS to run the training → Bedrock fine-tuning: Bedrock trains a supported base model on your data. You serve the result on Provisioned Throughput, or, for some base models (such as Amazon Nova Lite, Micro and Pro, and Llama 3.3 70B), as an on-demand custom model deployment. See Bedrock fine-tuning.
• You need full control or an unsupported architecture → SageMaker: Any model, any container, your choice of instances and scaling, and the work of running it. See deploying an open-source LLM on AWS.
• You have no weights yet and only need behavior or facts → prompts or RAG first: Prompt engineering and RAG on a base model are cheaper than training anything.

VIIILimits and operational notes

Check these before you commit.

• Regions: AWS lists eu-central-1, us-east-1, us-east-2 and us-west-2. The model serves in the Region you import it into. GPT-OSS is us-east-1 only.
• Features that do not work: Batch inference and CloudFormation cannot be used with imported models.
• Size and context: Under 200 GB for text, under 100 GB for multimodal, context under 128K. No embedding models.
• Artifacts: Complete Hugging Face-format files (safetensors, config, tokenizer) in S3, readable by the job's role.
• Licensing: You are responsible for complying with the license of the model you import.
• Updates: An imported model is a snapshot. To improve it, train a new version and import again.

IXWho can fund an import project

The import, the CMU charges and the S3 storage all draw down AWS credits automatically.

Partner-filed funding: a vetted AWS partner can file POC (proof of concept) funding to test your model on Bedrock, MAP funding if you are moving a self-hosted model from another cloud, or incremental workload (IW) funding if you already run on AWS and this is new work. For startups this is typically $50K to $150K. Depends on the workload; AWS approves.

AWS Activate: you apply yourself. Activate Founders gives self-funded startups $1,000 to start, up to $5,000. Activate Portfolio gives up to $200,000 with the Org ID from your VC, accelerator or angel group, if it is an Activate Provider. A consulting partner cannot file Activate for you.

CloudRoute matches you with one vetted AWS ML partner who can check architecture support, run the import, wire the model into your app, and tell you whether import, fine-tuning or SageMaker fits best. Startups pay CloudRoute nothing. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.