Endpoints supported by Amazon Bedrock
Amazon Bedrock supports various endpoints for performing inference operations.
Note
Both endpoints run on the same underlying Mantle inference engine, so all Amazon Bedrock models benefit from Mantle's zero operator access (ZOA)bedrock-mantle endpoint name refers only to one of the two endpoint surfaces — not to whether the Mantle engine is used.
Inference operations
For new applications, we recommend the bedrock-runtime endpoint. It supports the Bedrock-native InvokeModel and Converse APIs, the OpenAI-compatible Responses and Chat Completions APIs, and the Anthropic Messages API, and it is where Amazon Bedrock features such as Guardrails, intelligent prompt routing, and cross-Region inference are available. Amazon Bedrock also supports a second endpoint, bedrock-mantle, which currently offers additional capabilities such as server-side and pre-configured tool use (including web search), asynchronous inference with background=true, and creating Projects and Workspaces. To see which endpoint each model supports, see Endpoint availability.
| Endpoint | Supported APIs | Description |
|---|---|---|
bedrock-runtime.{region}.amazonaws.eu (recommended) |
InvokeModel / Converse / Chat Completions / Responses API / Messages API | Region-specific endpoints for making inference requests for models hosted in Amazon Bedrock using the InvokeModel/Converse/Chat Completions/Responses/Messages APIs. For more information about the Bedrock-native operations, see Amazon Bedrock Runtime API operations. The OpenAI-compatible APIs are called on the /openai/v1 paths of this endpoint rather than through the AWS SDKs. |
bedrock-mantle.{region}.api.amazonwebservices.eu |
Responses API / Chat Completions API / Messages API | Region-specific endpoints for making inference requests for models hosted in Amazon Bedrock using the OpenAI-compatible endpoints and the Anthropic Messages API. |
Existing applications that use bedrock-mantle continue to be fully supported and do not need to change. Both endpoints let you bring an existing OpenAI SDK codebase to Amazon Bedrock by changing only the base URL and API key, and both support the OpenAI-compatible Responses and Chat Completions APIs and the Anthropic Messages API.
The following tables compare what's available on each endpoint.
| API | bedrock-runtime |
bedrock-mantle |
|---|---|---|
| InvokeModel |  |
 |
| Converse / ConverseStream | |
|
| Chat Completions (OpenAI-compatible) | |
|
| Responses API (OpenAI-compatible) | |
|
| Messages API (Anthropic-native) | |
|
Note
The Messages API is available on both endpoints, but the two surfaces do not have identical feature support. In particular, structured outputs (the output_config.format parameter) are not supported on bedrock-mantle — requests that include output_config.format are rejected with a 400 error. To use structured outputs with Anthropic Claude models, call the Converse or InvokeModel APIs on bedrock-runtime.
Note
The Responses API is also available on both endpoints without identical feature support. On bedrock-runtime:
Requests are always synchronous.
background=trueis rejected with a 400 error. Thestoreparameter is unaffected and keeps its default oftrue, so stored, multi-turn conversations work normally.Server-side tool use and pre-configured tools are not available, including web search. Client-side tool use works on both endpoints.
Only the default project is supported. See Projects (OpenAI-compatible).
A stored response belongs to the AWS Region that served it. Retrieving, cancelling, or deleting it, and continuing the conversation with
previous_response_id, are all handled by that Region.
| Capability | bedrock-runtime |
bedrock-mantle |
|---|---|---|
| Cross-region inference (geographic and global profiles) | |
|
| Stateful conversation management | |
|
| Asynchronous (long-running) inference | |
|
| Client-side tool use | |
|
| Server-side tool use | |
|
| Pre-configured ready-to-use tools | |
|
| Projects | Default project only | |
| Workspaces | |
|
| Item | bedrock-runtime |
bedrock-mantle |
|---|---|---|
| AWS SigV4 authentication | |
|
| Bedrock API key (also works with OpenAI SDK) | |
|
| Usage attribution | IAM principal, per-request metadata tagging, application inference profiles | Projects, Workspaces |
Note
On bedrock-runtime, the Responses API attributes usage by IAM principal only. Per-request metadata tagging and application inference profiles are not available on it — a request that names an application inference profile as its inference target is rejected with a 400 error. This does not affect cross-Region inference: the system-defined geographic and global inference profiles work normally.
| Feature | bedrock-runtime |
bedrock-mantle |
|---|---|---|
| Guardrails | |
|
| Prompt caching | |
|
| Intelligent prompt routing | |
|
Note
Prompt caching support on bedrock-mantle depends on the specific model — see each model card under Models at a glance for details.
Throughput and quota approach
Each endpoint uses a different approach to managing throughput.
-
bedrock-runtime– In many traditional multi-tenant services, the architecture is designed around per-account quotas to manage fair-share access to shared resources. This is the approach used withbedrock-runtime. Each model has fixed throughput quotas (RPM and TPM) that you can request increases for. For details, see Quotas for the bedrock-runtime endpoint. -
bedrock-mantle– This endpoint is architected with advanced scheduling and work-queueing mechanisms that deliver fair-share distribution while supporting higher initial throughput limits. This design also allowsbedrock-mantleto host a broad set of models and deliver the full breadth of capabilities available across the model catalog. In most cases, requests are served immediately. In some cases, a request may be briefly queued while in-flight workloads complete and throughput becomes available. For details, see Quotas for the bedrock-mantle endpoint and Scaling and throughput best practices.
Pricing
Per-token pricing for the same model is identical on bedrock-runtime and bedrock-mantle. Choose an endpoint based on the APIs and capabilities you need, not cost. For current pricing, see Amazon Bedrock pricing
When to choose each endpoint
Start with bedrock-runtime when you want to:
Call the OpenAI-compatible Responses or Chat Completions APIs, or the Anthropic Messages API.
Use the Bedrock-native InvokeModel or Converse APIs.
Use Amazon Bedrock features that are available only on this endpoint, such as Guardrails and intelligent prompt routing.
Use cross-Region inference to route requests across a geography or globally.
Use bedrock-mantle when you want to:
Build agentic workflows with server-side tool use or pre-configured tools, including web search.
Run asynchronous or long-running inference workloads, including Responses requests with
background=true.Create Projects (OpenAI-compatible) or Workspaces (Anthropic-compatible) to isolate workloads and track cost and usage at the application level.
Use a model that is available only on
bedrock-mantle. See Endpoint availability.
Both endpoints can be used together from the same application — choose per use case.
Reduce data egress costs with VPC interface endpoints
If you are calling Amazon Bedrock from within a VPC, consider using VPC interface endpoints (AWS PrivateLink) to keep traffic within the AWS network and avoid data egress charges associated with NAT gateways or internet gateways.