Amazon Bedrock currently exposes Claude through two surfaces. The newer "Claude in Amazon Bedrock" surface serves Anthropic's Messages API directly at https://bedrock-mantle.{region}.api.aws/anthropic/v1/messages, with the same request shape as Anthropic's first-party API. The classic surface — the one this article covers — is the bedrock-runtime endpoint, where InvokeModel passes a model-specific JSON body straight through to the model. If you are integrating with existing Bedrock tooling, an API gateway, or invocation logging, InvokeModel is often the operation you'll be signing.
Endpoint, path, and headers
InvokeModel lives on the regional runtime endpoint, bedrock-runtime.{region}.amazonaws.com. The model is identified in the request URL — the path takes the form /model/{model-id}/invoke — not inside the JSON body. Requests are authenticated with AWS Signature Version 4, which every AWS SDK handles for you. The request and response bodies are JSON, so the operation's content-type and accept values should both be application/json (SDKs default sensibly; when in doubt, set them explicitly). The IAM action your caller needs is bedrock:InvokeModel on the model's foundation-model ARN — and if you route through a cross-region inference profile, on the inference-profile ARN as well.
The JSON body Claude expects
For Anthropic models, the InvokeModel body is the Anthropic Claude Messages API format with one Bedrock-specific addition: the body must include "anthropic_version": "bedrock-2023-05-31" alongside max_tokens and messages. Messages alternate user and assistant roles; each message's content can be a plain string or an array of typed content blocks (text, images, and so on). System prompts do not go in the message list — they go in the top-level system field. A trailing assistant message, where the model supports it, prefills the start of the response.
import boto3, json
client = boto3.client("bedrock-runtime", region_name="us-east-1")
body = {
"anthropic_version": "bedrock-2023-05-31",
"max_tokens": 1024,
"system": "You are a concise assistant for an IT team.",
"messages": [{"role": "user", "content": "Explain VPC endpoints in one paragraph."}],
}
resp = client.invoke_model(
modelId="global.anthropic.claude-opus-4-6-v1",
body=json.dumps(body),
contentType="application/json",
)
print(json.loads(resp["body"].read()))The response body is the familiar Messages API response: a content array of blocks plus usage metadata. For token-by-token output, the sibling operation InvokeModelWithResponseStream takes the identical body.
Model IDs on this surface are different
The runtime surface uses ARN-versioned model identifiers with a routing prefix — for example global.anthropic.claude-opus-4-6-v1 for global routing, or us.anthropic.claude-sonnet-4-5-20250929-v1:0 for US geographic routing. This matters more than it used to: Claude Fable 5, Opus 4.8, and Opus 4.7 have no ARN-versioned IDs, and Claude Sonnet 5 is not available on the legacy surface at all. To use those models you go through Claude in Amazon Bedrock (the bedrock-mantle endpoint, dateless IDs like anthropic.claude-opus-4-8) or Claude Platform on AWS. You can list what's available to your account with aws bedrock list-foundation-models --by-provider anthropic.
Limits and operational details worth knowing
Three numbers save debugging time. First, Bedrock limits request payloads to 20 MB — relevant once you embed base64 images or documents. Second, the inference timeout for Claude 3.7 Sonnet and Claude 4-generation models is 60 minutes, but AWS SDK clients default to roughly a 1-minute read timeout, so AWS recommends raising it (for example, botocore read_timeout of 3600 or more) for long generations. Third, context windows differ by model: Claude Opus 4.6 and Sonnet 4.6 get 1M tokens on Bedrock, while Sonnet 4.5 and older top out at 200K.
Every InvokeModel call is recorded as a CloudTrail management event (identity, timing, model ID — not prompt content), and if you enable model invocation logging, full request and response bodies can be captured to CloudWatch Logs or S3. Both are useful once this API is in production.
Where to go next
Compare this raw approach with the higher-level option in InvokeModel vs Converse, get your Python environment ready with the boto3 setup guide, or start from your first Bedrock API call.