Use Claude on AWS Bedrock

The Same Models, Inside Your Cloud Account

So far every request in this course has gone to the Anthropic API directly. Many organizations run their infrastructure on a cloud platform, and they want model calls to flow through the same account, the same billing, and the same security controls as everything else. Amazon Bedrock provides that path: Claude models are available inside AWS, and the SDK includes a client that speaks to Bedrock in the same vocabulary as the direct API.

This lesson explains what changes when Claude runs on Bedrock, how the SDK's Bedrock client is created, how model identifiers and regions differ, and how to validate that configuration before the first request. The Messages API you have learned remains the core, and most of the code in earlier lessons carries over with a different client and different model names.

What Changes and What Stays

The application logic stays the same. The request has the same parts (model, messages, system prompt, tools), the response has the same shape, and the errors follow the same classes (Lesson 141). What changes is the layer underneath:

The table shows the differences that matter in practice. Authentication and identifiers change almost everywhere, while the feature set can differ by platform and date, so it should be checked for each feature a project relies on.

Installing the Bedrock Client

The Bedrock client is installed as an extra of the SDK. The extra pulls in the AWS dependencies the client needs:

python -m pip install -U "anthropic[bedrock]"

The extra is required because the Bedrock client depends on AWS libraries that the base package does not install.

Creating the Client

The client is created with a region, and the AWS credentials are read from the standard AWS chain, the same one other AWS tools use:

from anthropic import AnthropicBedrock

client = AnthropicBedrock(aws_region="us-east-1")

message = client.messages.create(
    model="us.anthropic.claude-sonnet-4-5-20250929-v1:0",
    max_tokens=256,
    messages=[{"role": "user", "content": "Say hello."}],
)

The credentials are never passed in the code. The client looks for them in the environment, in a named profile, or in the role attached to the running machine, which is why production deployments usually rely on an IAM role rather than stored keys (Lesson 164 covers this in detail).

The model identifier in this example is a Bedrock identifier. It has a geographic prefix, us., that selects a cross-region inference profile, and a version suffix. The exact identifiers for each model are listed in the Bedrock documentation and in the model access settings of the AWS account, and they should be copied from there.

Model Access and Permissions

Bedrock requires two kinds of permission before a model can be used. The account must have access to the model enabled, which is a setting in the AWS console. And the identity making the call must have permission to invoke the model, granted by an IAM policy. A request that fails for either reason returns an error that names the problem, and the error handling in Lesson 168 maps those failures to clear actions.

Validating the Configuration

Configuration mistakes on Bedrock are common: a region without model access, an identifier copied from the wrong platform, or a prefix that does not match the region. Catching them before the first request is cheaper than debugging an error. The checks below verify the shape of the region and the model identifier. They are sanity checks, not a substitute for the platform's own list of valid values:

"""bedrock_config.py: sanity-check a Bedrock region and model identifier before use."""

import re

REGION = re.compile(r"^[a-z]{2}(-[a-z]+)+-\d+$")
MODEL = re.compile(r"^(?:(?:us|eu|apac|global)\.)?anthropic\.claude-[a-z0-9.:-]+$")


def check_bedrock(region: str, model_id: str) -> list[str]:
    problems = []
    if not REGION.match(region):
        problems.append(f"region {region} does not look like an AWS region")
    if not MODEL.match(model_id):
        problems.append(f"model id {model_id} does not look like a Bedrock Claude model id")
    return problems


if __name__ == "__main__":
    cases = [
        ("us-east-1", "us.anthropic.claude-sonnet-4-5-20250929-v1:0"),
        ("us-east-1", "claude-opus-5-5"),
        ("useast1", "anthropic.claude-opus-5-5"),
    ]
    for number, (region, model_id) in enumerate(cases, start=1):
        print(f"case {number}:", check_bedrock(region, model_id) or "ok")

Output:

case 1: ok
case 2: ['model id claude-opus-5-5 does not look like a Bedrock Claude model id']
case 3: ['region useast1 does not look like an AWS region']

How It Works

1. The region pattern expects the AWS form: two letters, then one or more hyphenated words, then a number, such as us-east-1. The value useast1 lacks the hyphens, so it fails.
2. The model pattern expects a provider prefix, anthropic.claude-, optionally preceded by a geographic prefix such as us.. The bare name claude-opus-5-5 is the direct API's form, and it fails here, which is the mistake this check is designed to catch.
3. Each problem is reported separately, so a configuration with two faults shows both.
4. The patterns are deliberately loose. They catch the shape errors that cause most mistakes, and they do not claim to know which identifiers exist. A current list from the platform remains the source of truth.

Summary

Claude on Bedrock uses the same Messages API, with a different client, the AWS credential chain, AWS billing, and Bedrock model identifiers. The client is installed as an extra, created with a region, and it reads credentials from the environment rather than from code. Model access and IAM permissions must both be in place, and a configuration check catches shape errors before any request is made. The next lesson covers the equivalent path on Google Cloud.