Course: Claude with Amazon Bedrock

Mirrors: Anthropic Academy — Claude with Amazon Bedrock (aka Claude in Amazon Bedrock) · https://anthropic.skilljar.com/ Audience: Developers and enterprise teams already on AWS. Comfortable with an AWS account, IAM, and a terminal. · Time: ~75 min + project Prereqs: building-with-the-claude-api (you should know the Messages API shape), an AWS account with Bedrock access, and the AWS CLI configured. · Backing notes: claude-bedrock, messages-api Project: p05-first-api-call — Bedrock variant (make your first Claude call through Bedrock instead of the first-party API)

This course takes the Claude API skills you already have and re-points them at Amazon Bedrock — AWS's managed model-inference service. Same Messages API shape, but AWS authentication, AWS-region endpoints, and AWS-native billing and governance. By the end you can enable Claude in Bedrock, authenticate with IAM, and call Claude two ways (the Bedrock Converse API and InvokeModel), and you'll know exactly where Bedrock differs from the first-party Anthropic API.

Learning objectives

After this course you can:

• Explain why an organization runs Claude through Bedrock instead of the first-party API (enterprise auth, data residency, AWS-native billing/governance).
• Enable Claude model access in the Bedrock console and confirm it in a region.
• Authenticate with IAM / the AWS credential chain and pick the right region.
• Call Claude through the Bedrock Converse API and through InvokeModel, and say when to use each.
• Translate a first-party model ID into a Bedrock model ID and look the current one up in the console.
• Name the differences and caveats vs. the first-party API (feature-parity timing, headers, batch surface) and use cross-region inference for capacity and availability.

---

Module 1 — Why Bedrock

🎞 Frame 1 · Same Claude, different front door · ⏱ ~2 min

🎬 Scene — Two architecture diagrams side by side: one app calls api.anthropic.com; the other calls a Bedrock endpoint inside the customer's AWS account. Same Claude model behind both.

🧠 Concept — Bedrock is a delivery channel for Claude, not a different model. The model and the Messages API request shape are the same; what changes is who authenticates you, where the endpoint lives, and who bills you. (Deeper: claude-bedrock.)

🖼 On screen

First-party:  your app ──► api.anthropic.com ──► Claude
Bedrock:      your app ──► bedrock-runtime.<region>.amazonaws.com ──► Claude
                          (inside your AWS account / IAM / billing)

✅ Checkpoint — In one sentence: what stays the same between the first-party API and Bedrock, and what changes?

🎞 Frame 2 · The four reasons enterprises choose Bedrock · ⏱ ~3 min

🎬 Scene — A checklist fills in: IAM auth, data residency, one AWS bill, AWS-native governance.

🧠 Concept — Bedrock exists because large organizations already standardized on AWS. Using Claude through Bedrock lets them reuse that machinery instead of bolting on a separate vendor.

🖼 On screen

Driver	What it means in practice
Enterprise auth	No separate Anthropic API key to provision and rotate — access is governed by IAM roles/policies you already manage.
Data residency	Inference runs in the AWS region you choose; data stays in-region for compliance.
AWS-native billing	Claude usage shows up on your existing AWS bill (and AWS Marketplace agreements), not a second invoice.
Governance	CloudTrail audit logs, VPC PrivateLink for private connectivity, and Bedrock Guardrails sit on top of Claude.

⚠️ Gotcha — None of these change Claude's capabilities. Choose Bedrock for the operational fit, not for a "better" model.

✅ Checkpoint — Your security team says "no third-party API keys, and data must stay in eu-central-1." Which two drivers does that map to?

🎞 Frame 3 · When NOT to use Bedrock · ⏱ ~2 min

🎬 Scene — A decision arrow: "Need the newest model the day it ships? / Not on AWS?" points back to the first-party API.

🧠 Concept — Bedrock trades a little immediacy and simplicity for AWS integration. New Claude models and new features generally land on the first-party API first and reach Bedrock on a lag.

🖼 On screen

Choose Bedrock      → already on AWS, need IAM, data residency, AWS billing/governance
Choose first-party  → want the latest model/feature fastest, simpler billing,
                      not building an AWS-native product

✅ Checkpoint — Name one situation where the first-party API is the better call even for an AWS shop.

---

Module 2 — Access and authentication

🎞 Frame 4 · Enabling Claude model access · ⏱ ~3 min

🎬 Scene — The Bedrock console "Model access" page; the user requests access to Anthropic's Claude models and the status flips to "Access granted."

🧠 Concept — Unlike the first-party API (where any valid key can call any model), Bedrock requires you to explicitly enable model access per provider in each region before any call will succeed. This is a one-time, account-level step.

🖼 On screen

Bedrock console → Model access → Manage model access
  → check the Anthropic / Claude models you want
  → submit request → status: Access granted
(Repeat per region you intend to call from.)

⚠️ Gotcha — A call that 403s on a brand-new account is almost always "model access not enabled in this region," not a credential problem.

✅ Checkpoint — You enabled Claude in us-east-1 but your code calls us-west-2 and fails. What's the fix?

🎞 Frame 5 · IAM, the credential chain, and regions · ⏱ ~3 min

🎬 Scene — An IAM policy granting bedrock:InvokeModel; the SDK quietly resolves credentials from the environment.

🧠 Concept — Bedrock auth is AWS auth. There is no Anthropic API key. Requests are signed with AWS SigV4 using credentials resolved through the standard AWS credential chain, and the region is part of the address — every call targets a specific region's endpoint.

🖼 On screen

Credential chain (first match wins):
  env vars (AWS_ACCESS_KEY_ID/SECRET/SESSION_TOKEN)
  → shared profile (~/.aws/credentials)
  → assumed role / EC2/ECS instance metadata

IAM policy must allow (at least):
  bedrock:InvokeModel            (and InvokeModelWithResponseStream for streaming)
  bedrock:Converse / ConverseStream   (for the Converse API)

⚠️ Gotcha — Region is not optional and there's no global endpoint. Pick the region deliberately; it drives data residency and which models are available.

✅ Checkpoint — Where does the Bedrock SDK get its credentials if you never pass a key in code?

🎞 Frame 6 · Bedrock model IDs vs. first-party model IDs · ⏱ ~3 min

🎬 Scene — Two strings stacked: a short first-party ID and a longer Bedrock ID with a provider prefix.

🧠 Concept — Bedrock namespaces every model by provider, so Claude model IDs carry an anthropic. prefix and often a version suffix. The first-party ID won't work on Bedrock, and vice-versa.

🖼 On screen

First-party ID:   claude-<family>-<ver>
Bedrock ID:       anthropic.claude-<family>-<ver>...   (provider-prefixed)

⚠️ Gotcha — Exact current IDs change as models ship. Don't hardcode an ID from memory — list available models in the Bedrock console (or aws bedrock list-foundation-models) for the live string in your region. The pattern (anthropic. prefix) is stable; the suffix is not.

✅ Checkpoint — Why will a first-party model ID 404/validation-error on Bedrock, and where do you find the right one?

---

Module 3 — Calling Claude on Bedrock

🎞 Frame 7 · Two ways to call: Converse vs. InvokeModel · ⏱ ~3 min

🎬 Scene — A fork in the road. One path is labeled "Converse API — unified," the other "InvokeModel — raw passthrough."

🧠 Concept — Bedrock gives you two surfaces. The Converse API is AWS's unified multi-turn chat interface that works the same across providers. InvokeModel sends the model's native request body straight through — for Claude, that's the Anthropic Messages API JSON.

🖼 On screen

Surface	Request shape	Use when
Converse	AWS-unified messages/tools schema	You want one code path across Bedrock providers; portability matters.
InvokeModel	Native Anthropic Messages JSON (anthropic_version, messages, max_tokens, …)	You want full access to Claude-specific fields and parity with first-party request bodies.

✅ Checkpoint — You're sending the exact Anthropic Messages JSON you'd send first-party. Which surface?

🎞 Frame 8 · boto3 + the Converse API · ⏱ ~3 min

🎬 Scene — A short Python snippet using the boto3 bedrock-runtime client and converse(...); a response prints.

🧠 Concept — With the AWS SDK (boto3), you build a bedrock-runtime client for a region and call converse(). Messages and tools use the AWS-unified schema; the Bedrock model ID goes in modelId.

🖼 On screen

import boto3

client = boto3.client("bedrock-runtime", region_name="us-east-1")

resp = client.converse(
    modelId="anthropic.claude-<family>-<ver>...",   # look up live ID in console
    messages=[{"role": "user", "content": [{"text": "Hello, Claude"}]}],
    inferenceConfig={"maxTokens": 1024},
)
print(resp["output"]["message"]["content"][0]["text"])

⚠️ Gotcha — Converse uses AWS field names (inferenceConfig.maxTokens, content as {"text": ...}), not the Anthropic field names. Don't mix the two schemas.

✅ Checkpoint — In Converse, where does max_tokens live, and what is it called?

🎞 Frame 9 · boto3 + InvokeModel (native Messages JSON) · ⏱ ~3 min

🎬 Scene — The same task via invoke_model, where the body is the literal Anthropic Messages API JSON, serialized.

🧠 Concept — InvokeModel is a raw passthrough: you serialize the native Anthropic Messages request as the body, and Bedrock returns the native response. This is the closest match to first-party code — only the auth and the model ID change.

🖼 On screen

import json, boto3

client = boto3.client("bedrock-runtime", region_name="us-east-1")

body = {
    "anthropic_version": "bedrock-2023-05-31",   # Bedrock-specific version string
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "Hello, Claude"}],
}

resp = client.invoke_model(
    modelId="anthropic.claude-<family>-<ver>...",
    body=json.dumps(body),
)
payload = json.loads(resp["body"].read())
print(payload["content"][0]["text"])

⚠️ Gotcha — On InvokeModel you set anthropic_version to the Bedrock value (bedrock-2023-05-31), not the first-party anthropic-version header. Auth is SigV4, so there is no x-api-key.

✅ Checkpoint — On InvokeModel, which two header/field things differ from a first-party Messages call (hint: version + auth)?

🎞 Frame 10 · The Anthropic SDK's Bedrock client · ⏱ ~2 min

🎬 Scene — A snippet using the Anthropic SDK's Bedrock client that looks almost identical to first-party code.

🧠 Concept — You don't have to drop to boto3. The Anthropic SDK ships a Bedrock client that exposes the same messages.create(...) surface you already know, handling SigV4 and the Bedrock body for you — you just pass a region and a Bedrock model ID.

🖼 On screen

from anthropic import AnthropicBedrock

client = AnthropicBedrock(aws_region="us-east-1")   # credentials via AWS chain

resp = client.messages.create(
    model="anthropic.claude-<family>-<ver>...",      # Bedrock model ID
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello, Claude"}],
)
print(resp.content[0].text)

✅ Checkpoint — Which two things must change to turn first-party SDK code into Bedrock SDK code? (The client class + the model ID; auth comes from the AWS chain.)

---

Module 4 — Parity, governance, and scale

🎞 Frame 11 · Differences and caveats vs. first-party · ⏱ ~3 min

🎬 Scene — A comparison table scrolls; a few cells are highlighted where Bedrock lags or differs.

🧠 Concept — Bedrock serves the same Messages API shape, but it is partner-operated, so feature availability and timing differ. Build to the parity table, not to the assumption that everything first-party works identically here. (Deeper: claude-bedrock.)

🖼 On screen

Aspect	First-party	Bedrock
Auth	API key (x-api-key)	AWS IAM / SigV4
Model ID	claude-<family>-<ver>	anthropic.claude-<family>-<ver>...
Version field	anthropic-version header	anthropic_version: "bedrock-2023-05-31" (InvokeModel)
Region	single endpoint	per-AWS-region endpoint
Tool use	native	native (same shape)
Latest models / features	first	slight lag — land first-party first
Batch	Batches API	Bedrock Batch (a different surface)

⚠️ Gotcha — A feature you read about in the first-party docs may not be on Bedrock yet, or may be exposed differently. Check the Bedrock-specific docs before relying on it.

✅ Checkpoint — Name two concrete things that differ between a first-party Messages call and a Bedrock InvokeModel call.

🎞 Frame 12 · Governance you get for free · ⏱ ~2 min

🎬 Scene — CloudTrail entries scroll past; a Guardrail config blocks a disallowed prompt; a PrivateLink diagram shows traffic never leaving the VPC.

🧠 Concept — Because calls are AWS API calls, they inherit AWS governance: CloudTrail audit logging, Bedrock Guardrails for content policy, Bedrock Knowledge Bases for grounding, and VPC PrivateLink for private connectivity — all without changing your Claude request.

🖼 On screen

Your call ─► (CloudTrail logs it) ─► (Guardrails screen it) ─► Claude
            └─ optional: Knowledge Bases for retrieval, PrivateLink for no public egress

✅ Checkpoint — Which AWS feature gives you an audit trail of every Claude call, and which lets you enforce a content policy?

🎞 Frame 13 · Cross-region inference · ⏱ ~3 min

🎬 Scene — A request to a "US" inference profile fans out across multiple regions for capacity; latency and throughput hold steady under load.

🧠 Concept — Cross-region inference lets you target an inference profile (e.g. a "US" or "EU" geography) instead of one fixed region. Bedrock routes the request to an available region within that geography, improving throughput and resilience during demand spikes — while keeping data within the chosen geography for residency.

🖼 On screen

Single region:        modelId = anthropic.claude-...            → one region's capacity
Cross-region profile: modelId = us.anthropic.claude-...         → routed within the US geography
                      (geo-prefixed inference profile ID)

⚠️ Gotcha — Cross-region inference uses a geo-prefixed inference profile ID (e.g. a us. / eu. prefix), not the plain model ID. Confirm the exact profile ID and the regions it spans in the console; residency still applies at the geography level.

✅ Checkpoint — What problem does cross-region inference solve, and how does it still respect data residency?

---

🛠 Project

Complete p05-first-api-call — your first Claude API call, Bedrock variant. Instead of calling the first-party API, you'll: enable Claude model access in one region, configure AWS credentials, and make the same "hello" call three ways — Converse (boto3), InvokeModel (boto3, native Messages JSON), and the Anthropic SDK's Bedrock client. Capture the response and note one difference you hit vs. the first-party path.

🧪 Self-check quiz

1. What stays the same between first-party Claude and Claude on Bedrock, and what changes?
2. Name two of the four enterprise drivers for choosing Bedrock.
3. What one-time, per-region step must you do before any Bedrock Claude call succeeds?
4. Where does the Bedrock SDK get its credentials if you pass no key?
5. Give the pattern for a Bedrock Claude model ID and say where to find the exact current string.
6. Converse API vs. InvokeModel: which one takes the native Anthropic Messages JSON?
7. On InvokeModel, what do you set for anthropic_version, and why is there no x-api-key?
8. Name two differences from the parity table between first-party and Bedrock.
9. What does cross-region inference give you, and how do you address it (model ID vs. profile ID)?

<details><summary>Answers</summary>

1. The model and Messages API shape stay the same; auth (IAM/SigV4), endpoint (per-region), model ID (prefixed), and billing/governance change. 2. Any two of: enterprise/IAM auth, data residency, AWS-native billing, AWS-native governance. 3. Enabling Claude model access in the Bedrock console for that region. 4. The standard AWS credential chain (env vars → shared profile → assumed role / instance metadata). 5. anthropic.claude-<family>-<ver>... — look up the live ID in the Bedrock console or aws bedrock list-foundation-models; don't hardcode from memory. 6. InvokeModel. 7. anthropic_version: "bedrock-2023-05-31"; auth is AWS SigV4, so there's no API-key header. 8. Any two of: API key vs. IAM/SigV4, model-ID prefix, version field, per-region endpoints, batch surface, latest-model timing. 9. It routes a request to an available region within a geography for capacity/resilience; you address a geo-prefixed inference profile ID (e.g. us.anthropic.claude-...), and residency is preserved at the geography level.

</details>

🎓 Certificate criteria

You've "passed" Claude with Amazon Bedrock when you can:

• Explain the four enterprise drivers and when first-party is the better choice.
• Enable Claude model access and authenticate via IAM in a chosen region.
• Call Claude via the Converse API and via InvokeModel, and say when to use each.
• State the model-ID pattern and the parity caveats vs. first-party.
• Complete p05-first-api-call (Bedrock variant) and journal one Bedrock-specific difference you hit.

Tick this course off in progress and record the date you earned Anthropic's official certificate (if offered).

🔗 Sources & deeper notes

• Vault notes: claude-bedrock, messages-api, model-family
• Official model/ID and feature details: the Bedrock console and Anthropic's Bedrock docs (look up live model IDs — don't hardcode).
• Project: p05-first-api-call · Sibling course: claude-with-vertex-ai
• Catalog: catalog