Finished the Claude on Bedrock course? Don't promise AWS clients yet

Anthropic did not build this course for beginners. The landing page for Claude with Amazon Bedrock on Anthropic Academy (anthropic.skilljar.com/claude-in-amazon-bedrock) states that it was created within an accreditation programme set up specifically for AWS, and that it is the first training of its kind for AWS employees.

In other words, the course was designed first and foremost for people who work at AWS.

There is a trap, though. Anthropic’s own documentation acknowledges that calling Claude through Bedrock differs somewhat from calling the Claude API directly. Take the course without knowing where those differences lie, and it is easy to promise a client a feature their environment does not have.

Who should take it, and in what order?

The course page asks for fluency in Python and a basic understanding of AWS services and Amazon Bedrock. If you have never opened the AWS console, do not start here. The Academy, now at academy.claude.com, promotes free courses made by Anthropic’s education team, so you can learn the Claude fundamentals there first.

The course page gives no release date; the 2026 copyright line in the footer is simply the page’s year and says nothing about when the course launched.

Because it is unclear when the course was written, its content may follow the legacy Bedrock documentation, while Anthropic has since added newer integration paths.

A sensible order: take the course to learn calling through boto3, tool use, agents, MCP and prompt caching.

Then read Anthropic’s “Claude on Amazon Bedrock” page and the Messages API guide in AWS’s Bedrock User Guide to learn which parts do not work exactly the same way.

A tool in the lecture is not necessarily in the client’s account

In the course, tool use, agents and MCP are general Claude knowledge. For the legacy Bedrock integration (InvokeModel/Converse), Anthropic’s documentation lists much that is unavailable: server-side tools such as code execution, web search and web fetch; agent infrastructure such as Agent Skills, the MCP connector and programmatic tool calling; and the Message Batches, Models, Admin, and Usage and Cost endpoints.

Picture an insurance client that wants an agent to read case files, search the web and run calculation code. On the Claude API, web search and code execution come ready-made as server-side tools, though you still have to design the agent and test it carefully.

On legacy Bedrock, you have to write client-side tools for both, and batch processing has to go through Bedrock’s own mechanism, so your effort estimate can be badly off.

Prompt caching is similar. Bedrock supports caching, but not the automatic mode set by a top-level cache_control field. You have to place cache breakpoints explicitly.

Model IDs and regions are architecture decisions

Newer models on Bedrock usually have to be called through an inference profile (cross-region inference) rather than the base model ID. This is an AWS-specific operational detail, so check it first when moving a demo into a client’s account.

Region is not just a technical matter either. Clients that need data residency will have to use regional endpoints, and Anthropic’s documentation states that regional endpoints cost 10 per cent more than the global endpoint. If the client is a bank required to keep data in one region, put that figure in the proposal from the start rather than waiting for the invoice.

The operational traps in AWS’s documentation

The course teaches calling through boto3, but AWS recommends the Converse API for messages rather than raw InvokeModel. You will meet both in client code, so you need to be able to read both.

The trap most worth remembering: the AWS SDK client times out after 1 minute by default, while a long inference can run for up to 60 minutes. The direct consequence is that with the default configuration, any request running longer than 1 minute will not wait for its result; AWS recommends raising the read timeout.

The code below shows the same call before and after moving to Bedrock. The IDs are placeholders; in real work, take the values from the client’s AWS account.

# Before: calling the Claude API directly
import anthropic

client = anthropic.Anthropic()
resp = client.messages.create(
    model="<model-id>",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Summarise this case file"}],
)

# After: calling through Bedrock with the Converse API
import boto3
from botocore.config import Config

bedrock = boto3.client(
    "bedrock-runtime",
    config=Config(read_timeout=3600),  # raised from the 1-minute default to 60 minutes
)
resp = bedrock.converse(
    modelId="<inference-profile-id>",  # an inference profile, not the base model ID
    messages=[{"role": "user", "content": [{"text": "Summarise this case file"}]}],
    inferenceConfig={"maxTokens": 1024},
)

The three lines to note are Config(read_timeout=...), the modelId pointing to an inference profile, and Converse’s list-shaped content structure. Put all three in the project template from day one.

Anthropic also points to two other paths: the new “Claude in Amazon Bedrock” Messages API endpoint, and “Claude Platform on AWS”, operated by Anthropic, billed through AWS Marketplace and usually getting new features on the day they ship. The legacy documentation page is labelled “Opus 4.6 and earlier”. Before settling on an architecture, ask the client which path they are on.

Turning the course into an edge when job hunting

On a CV, a course title persuades less than real work. A line such as “migrated a Claude application from the direct API to Bedrock via the Converse API, using inference profiles, configuring read timeouts for long inference and replacing server-side tools with client-side tools” shows you have touched the hard parts.

If the role you are applying for serves clients running on AWS, bring exactly this example to the interview and walk through each change you had to make.

The course teaches you to speak the same language as the client’s AWS team. The documentation page on the differences is what keeps you from making the wrong promise in the first meeting.