# Claude in Amazon Bedrock: Deployment + AWS Integration

> This 83-lesson course teaches the same Claude API surface as claude-api-foundations but accessed through Amazon Bedrock rather than the direct Anthropic API. The deployment-specific substance is the AWS boto3 SDK, IAM-bound auth, the Bedrock converse API shape, regional model availability with cross-region inference profiles, and Bedrock-only features (Guardrails, Knowledge Bases, Agents). Everything else (prompt engineering, evals, tool use, RAG, MCP) mirrors Course 6 lesson-for-lesson.

**Domain:** D5 · Context + Reliability (15%)
**Difficulty:** intermediate
**Skilljar course:** Claude with Amazon Bedrock (83 lessons)
**Canonical:** https://claudearchitectcertification.com/knowledge/claude-with-bedrock
**Last reviewed:** 2026-05-06

## Exam mapping

**Blueprint share:** 15% (D5) + 18% (D2)

Maps directly to D5 task statements about deploying Claude in customer-managed cloud environments, IAM-bound auth, regional model availability, cross-region inference profiles, and quota management on AWS. The API/prompt/tool/RAG/MCP/agent content is the same as Course 6, so this page focuses on what differs at the deployment seam.

## What you'll learn

- How to enable Claude models in Bedrock and authenticate via AWS IAM (access keys, IAM roles, or SSO)
- How the boto3 bedrock-runtime client and the converse API differ from the direct Anthropic SDK
- What inference profiles are and how cross-region inference solves Bedrock's regional availability problem
- Which Claude features ride on top of Bedrock unchanged (prompt caching, vision, PDF support, tool use, extended thinking) and which are AWS-specific add-ons (Guardrails, Knowledge Bases, Bedrock Agents)
- How AWS-native controls (IAM, VPC endpoints, CloudTrail, KMS) fit into a Bedrock-hosted Claude deployment
- When to choose Bedrock vs the direct Anthropic API vs Vertex AI for a given workload

## Prerequisites

- **Claude API Foundations (the platform-agnostic content)** (knowledge · `claude-api-foundations`)
- **Claude 101: First Principles** (knowledge · `claude-101`)

## Lesson outline

### 1. Introduction to the course

Course intro; originally produced for AWS employees, now public. Same Claude API content via Bedrock.

### 2. Overview of Claude models

Model family overview; same models, accessed via Bedrock.

### 3. Accessing the API

Request lifecycle: client to server to Bedrock to model and back; never call from browser.

### 4. Making a request

DEPLOYMENT-SPECIFIC: boto3.client('bedrock-runtime'), model id vs inference profile, converse API, regional availability.

### 5. Multi-turn conversations

Append assistant + user messages to maintain dialogue state; mirrors Course 6 with Bedrock content-block shape.

### 6. Chat bot exercise

Hands-on: build a minimal chat loop against Bedrock.

### 7. System prompts

DEPLOYMENT-SPECIFIC: Bedrock converse takes system=[{"text": "..."}] (list of blocks) instead of a plain string.

### 8. System prompt exercise

Hands-on: experiment with system prompts on Bedrock.

### 9. Temperature

Sampling control via inferenceConfig.temperature parameter on converse.

### 10. Streaming

DEPLOYMENT-SPECIFIC: Bedrock uses converse_stream (different method) returning EventStream.

### 11. Controlling model output

max_tokens via inferenceConfig.maxTokens; stop sequences via stopSequences.

### 12. Structured data

Coax JSON via prompting; introduce schema thinking before tool use.

### 13. Structured data exercise

Hands-on: extract structured fields with prompted JSON.

### 14. Quiz on working with the API

Section quiz on Bedrock API mechanics.

### 15. Prompt evaluation

Why systematic eval beats vibes; same content as Course 6.

### 16. A typical eval workflow

Test set + grader + iteration loop; canonical pattern.

### 17. Generating test datasets

Use Claude itself (via Bedrock) to synthesize test inputs at scale.

### 18. Running the eval

Loop the test set through your prompt and capture outputs.

### 19. Model-based grading

LLM-as-judge: rubric-driven grading with a separate Claude call.

### 20. Code-based grading

Deterministic graders for format, regex, schema validation.

### 21. Exercise on prompt evals

Hands-on: stand up a small eval harness.

### 22. Quiz on prompt evaluations

Section quiz on eval workflow.

### 23. Prompt engineering

Intro to the canonical Anthropic prompt-engineering techniques.

### 24. Being clear and direct

State the task plainly; ambiguity costs more than verbosity.

### 25. Being specific

Specificity collapses the response space; vague asks invite drift.

### 26. Structure with XML tags

XML tags as structural anchors Claude attends to reliably.

### 27. Providing examples

Few-shot examples in the prompt steer style and format.

### 28. Exercise on prompting

Hands-on: refactor a weak prompt using the four techniques.

### 29. Quiz on prompt engineering

Section quiz on the prompting toolkit.

### 30. Introducing tool use

Tools let Claude call your functions; Bedrock converse uses toolConfig shape.

### 31. Tool functions

Define the Python functions Claude will call.

### 32. JSON schema for tools

JSON schema for tool inputs; the model only sees this schema.

### 33. Handling tool use responses

Iterate the response content blocks (text + toolUse) and dispatch.

### 34. Running tool functions

Execute the tool function with the model-supplied arguments.

### 35. Sending tool results

Append toolResult content blocks and re-call converse to continue.

### 36. Multi-turn conversations with tools

Maintain the agentic loop across multiple tool calls.

### 37. Adding multiple tools

Register a tool list in toolConfig.tools; let Claude pick the right one per turn.

### 38. Batch tool use

Submit many tool-use requests at once for cost-and-throughput wins.

### 39. Structured data with tools

Tool schemas as the cleanest path to structured outputs.

### 40. Flexible tool extraction

Patterns for parsing tool use across varied inputs.

### 41. The text editor tool

Built-in text-editor tool for file-edit workflows.

### 42. Quiz on tool use

Section quiz on tool-use mechanics.

### 43. Introducing retrieval-augmented generation

RAG = retrieve relevant docs and add them to context; Knowledge mitigation.

### 44. Text chunking strategies

Fixed-size, sentence-boundary, and semantic chunking tradeoffs.

### 45. Text embeddings

Dense vector representations for semantic search; on AWS often Bedrock-hosted Titan or Cohere embeddings.

### 46. The full RAG flow

Embed -> store -> retrieve top-k -> augment prompt -> generate.

### 47. Implementing the RAG flow

Hands-on RAG pipeline. Note: Bedrock Knowledge Bases provides a managed alternative.

### 48. BM25 lexical search

Keyword/term-frequency retrieval as a complement to embedding search.

### 49. A multi-search RAG pipeline

Combine BM25 + embeddings with reciprocal rank fusion.

### 50. Reranking results

Cross-encoder rerank of top-k retrievals before context insertion.

### 51. Contextual retrieval

Anthropic's contextual retrieval: prepend a chunk-aware summary before embedding.

### 52. Quiz on retrieval-augmented generation

Section quiz on RAG components.

### 53. Extended thinking

Reasoning mode where the model thinks before answering; surfaced as a content block.

### 54. Image support

Vision: pass images as base64 or S3 references in content blocks.

### 55. PDF support

Native PDF inputs; large docs feed the Working Memory cliff.

### 56. Citations

Built-in citations: model returns spans tying claims back to source docs.

### 57. Prompt caching

Cache stable prefixes (system prompt, RAG context) for major cost wins.

### 58. Rules of prompt caching

TTLs, breakpoints, minimum sizes; cache-hit accounting on Bedrock.

### 59. Prompt caching in action

Hands-on: measure cache-hit savings on a realistic workload.

### 60. Quiz on features of Claude

Section quiz on cross-cutting features.

### 61. Introducing MCP

Model Context Protocol: standard for connecting tools/data to Claude.

### 62. MCP clients

Claude Desktop, Claude Code, custom clients; all speak the same protocol.

### 63. Project setup

Stand up an MCP server scaffold for the section.

### 64. Defining tools with MCP

Expose tools through MCP rather than per-app tool schemas.

### 65. The server inspector

Anthropic's MCP inspector for debugging server output.

### 66. Implementing a client

Build a custom MCP client around Claude on Bedrock.

### 67. Defining resources

MCP resources: model-pull data sources.

### 68. Accessing resources

Wire resources into the client and let Claude read them.

### 69. Defining prompts

MCP prompts: server-provided prompt templates.

### 70. Prompts in the client

Surface MCP-served prompts in client UI.

### 71. MCP review

Recap of tools/resources/prompts split.

### 72. Quiz on Model Context Protocol

Section quiz on MCP architecture.

### 73. Agents overview

Agentic loop intro. Note: Bedrock Agents is an AWS-managed alternative not covered in detail here.

### 74. Claude Code setup

Install + configure Claude Code; can be configured against Bedrock-backed deployments.

### 75. Claude Code in action

Live coding session demoing common workflows.

### 76. Enhancements with MCP servers

Plug MCP servers into Claude Code for repo/db/issue access.

### 77. Parallelizing Claude Code

git worktrees + multiple sessions for parallel feature work.

### 78. Automated debugging

Subagent-driven bug repro and fix loop.

### 79. Computer use

Computer-use tool: Claude controls a virtual desktop via screenshots + actions.

### 80. How computer use works

Action loop: screenshot -> reason -> click/type -> repeat.

### 81. Qualities of agents

What makes agents reliable vs brittle: scope, tools, evaluation, escalation.

### 82. Final assessment quiz

End-of-course assessment across all sections.

### 83. Course wrap-up

Recap and pointers to deeper Bedrock + Anthropic resources.

## Our simplification

This course is the platform-agnostic Claude API course (Course 6 claude-api-foundations) wrapped in AWS; same prompt engineering, same eval workflow, same tool-use mechanics, same RAG patterns, same MCP protocol. If you have done Course 6, roughly 75 of the 83 lessons will feel familiar verbatim. The ~8 lessons that *justify a separate Knowledge page* are the deployment seam: how you authenticate, which API shape you call, how regions and inference profiles work, and how AWS-native enterprise features (Guardrails, Knowledge Bases, IAM, VPC endpoints, CloudTrail, KMS) fit on top. This page focuses on those seams; for everything else, lean on claude-api-foundations as the canonical reference.

Authentication on Bedrock is IAM-bound, not API-key-bound. You get credentials the AWS way: an IAM user with access keys for development (set via aws configure or environment variables), or an IAM role attached to your compute (EC2 instance profile, ECS task role, Lambda execution role) for production. The boto3.client('bedrock-runtime', region_name='us-west-2') call picks up credentials from the standard AWS credential chain automatically. There is no ANTHROPIC_API_KEY; auth is bound to an AWS principal, which means your IAM policy is the security boundary. Grant bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream on the specific model ARNs you need, scope by region, and rotate via IAM Identity Center or short-lived STS credentials.

The SDK and API shape diverge from the direct Anthropic SDK in three load-bearing ways. First, the client: boto3.client('bedrock-runtime') instead of Anthropic() or AnthropicBedrock() (the latter exists as an Anthropic convenience wrapper, but the course uses raw boto3). Second, the API method: client.converse(modelId=..., messages=...) rather than messages.create(...). Third, the message shape: Bedrock's converse uses lists-of-content-blocks even for plain text, so a user message is {"role": "user", "content": [{"text": "What is 1+1?"}]} rather than the direct API's flat string. The system prompt is a list of blocks too: system=[{"text": "You are a helpful assistant."}]. Tool use uses toolConfig and toolUse/toolResult blocks. The semantics are identical to the direct API; the wrapping is verbose.

Regional model availability is the single biggest operational gotcha, and inference profiles are the AWS-specific fix. Not every Claude model is hosted in every AWS region; Claude Sonnet might be in us-west-2 while you are calling from us-east-1 and you will get a cryptic model not found error. The pre-2024 fix was to manually pin every call to the right region. The current AWS-native solution is inference profiles: a profile id (look under Cross-region inference in the Bedrock console, not under the main model catalog) that AWS automatically routes to a region where the model exists. You pass the inference profile id as modelId and AWS handles regional load balancing. This is a Bedrock-only concept; there is no analogue on Vertex or the direct API, so it is one of the most exam-relevant deployment-specific facts in the course.

AWS-side bonuses come in two flavors: managed services and enterprise controls. The managed-service tier sits on top of Bedrock and has no analogue on the direct API or Vertex: Bedrock Guardrails for content filters, PII redaction, and topic restrictions; Bedrock Knowledge Bases as managed RAG (ingest from S3, OpenSearch Serverless or Aurora as vector store); Bedrock Agents as higher-level agent orchestration with action groups, knowledge bases, and AWS-handled control flow. The Skilljar course teaches you the underlying primitives (tool use, RAG, agents) at the API level; the AWS-managed services are *alternatives* you can use instead of rolling your own. The control tier is the main reason regulated customers pick Bedrock: VPC endpoints (PrivateLink) keep traffic off the public internet, CloudTrail logs every InvokeModel call with caller identity, AWS KMS Customer-Managed Keys wrap inputs and outputs, AWS Config tracks compliance drift. The compliance story is Bedrock's, not Anthropic's directly: SOC, ISO, HIPAA-eligible (with a BAA), FedRAMP High in GovCloud, IRAP for Australia. Both tiers slot into existing AWS landing zones rather than requiring parallel security review.

Feature parity is high but not perfect, and the gaps move over time. Prompt caching, vision, PDF support, citations, extended thinking, and tool use generally land on Bedrock within weeks of the direct API release; the message-format protocol is identical though more verbose. The exceptions tend to be at the *tool* layer: the built-in web search tool and computer use have shipped with deployment-specific availability gates and may lag the direct API. The batch API is exposed as Bedrock's separate Batch Inference job runner rather than as inline messages.batches calls. Pricing is set by AWS and is typically priced per 1K input/output tokens at parity with the direct API, billed through your AWS invoice. Cache hits get the same multipliers; reserved throughput is an AWS-specific provisioned-capacity option for predictable high-volume workloads.

When to choose Bedrock vs the direct Anthropic API vs Vertex AI. Pick Bedrock when your stack is already on AWS; IAM, VPC endpoints, CloudTrail, KMS, billing, and your security review consolidate, and you avoid a second vendor relationship. The AWS-only managed services (Guardrails, Knowledge Bases, Agents) are real bonuses for regulated industries. Pick the direct Anthropic API when you want fastest access to new models and features, simpler key-based auth, and no cloud lock-in. Pick Vertex when you are on Google Cloud for the symmetric reasons. The application code is roughly 95% portable across all three; the differences are auth, the API method shape, the message wrapping, regional/inference-profile mechanics, and AWS-specific managed services. Picking a deployment platform is mostly an organizational decision (where your landing zone lives), not a technical one; and the exam expects you to recognize that.

## Patterns

### 6 things that change when you move from the direct Anthropic API to Bedrock

If you already know the direct API (Course 6), these are the deltas you actually need to internalize. Everything else is unchanged.

- **Auth: IAM, not API key.** No ANTHROPIC_API_KEY. Use aws configure, IAM roles on EC2/ECS/Lambda, or short-lived STS credentials. Auth is bound to an AWS principal and IAM policy is your security boundary. Required permission: bedrock:InvokeModel on the model ARN.
- **Client: boto3 `bedrock-runtime`.** client = boto3.client('bedrock-runtime', region_name='us-west-2'). Use AWS standard credential chain. The Anthropic SDK ships an AnthropicBedrock convenience wrapper, but the official Skilljar course teaches raw boto3.
- **Method: `converse`, not `messages.create`.** client.converse(modelId=..., messages=[user_message]). Streaming uses converse_stream. Response shape: response['output']['message']['content'][0]['text']. The semantics map 1:1 to the direct API but the wrapper is more verbose.
- **Content blocks are always lists.** User message: {'role': 'user', 'content': [{'text': '...'}]}. System prompt: system=[{'text': '...'}]. The list shape is so multimodal content (images, documents) can be mixed; plain text just looks more verbose.
- **Inference profiles for cross-region routing.** Models exist in specific regions. Use cross-region inference profiles (under Cross-region inference in the Bedrock console) so AWS auto-routes to a region where the model is available. Pass the profile id as modelId. Bedrock-only concept; no analogue on Vertex or direct API.
- **AWS-managed bonuses: Guardrails, Knowledge Bases, Agents.** Bedrock Guardrails for content controls, Bedrock Knowledge Bases for managed RAG, Bedrock Agents for managed agent orchestration. These are alternatives to rolling your own; useful for regulated industries that want managed compliance and operations.

## Key takeaways

- Bedrock deployment is the same Claude API surface as claude-api-foundations plus a different auth, API method, and message shape; about 75 of 83 lessons mirror Course 6 verbatim. (`tool-calling`)
- Authentication is AWS IAM (access keys, IAM roles, or STS short-lived credentials), not an API key; production uses an IAM role with bedrock:InvokeModel and the policy is the security boundary. (`system-prompts`)
- Bedrock uses boto3's bedrock-runtime client and the converse API; messages and system prompts are lists of content blocks even for plain text, which makes the API more verbose than the direct Anthropic SDK. (`tool-calling`)
- Cross-region inference profiles are the AWS-specific solution to regional model availability; pass an inference profile id as modelId and AWS routes to a region where the model exists. No analogue on Vertex or the direct API. (`claude-for-operations`)
- Bedrock-only managed services (Guardrails, Knowledge Bases, Agents) are alternatives to rolling your own; useful for regulated industries needing managed compliance, but the underlying primitives the exam tests are still tool use, RAG, and agents. (`evaluation`)
- Application code is roughly 95% portable across direct API, Bedrock, and Vertex; choosing a deployment platform is mostly an organizational decision (where your AWS or GCP landing zone lives), not a technical one. (`tool-calling`)

## Concepts in play

- **Tool calling** (`tool-calling`), Same protocol on Bedrock; tool schemas wrap into toolConfig / toolUse / toolResult blocks
- **Prompt caching** (`prompt-caching`), Available on Bedrock with same TTL/breakpoint rules as direct API
- **Batch API** (`batch-api`), Exposed on Bedrock as the separate Batch Inference job runner rather than inline calls
- **MCP** (`mcp`), Protocol-level, deployment-independent; works with Bedrock-backed Claude
- **Vision and multimodal** (`vision-multimodal`), Image and PDF inputs work via converse content blocks (base64 or S3 references)
- **Evaluation** (`evaluation`), Same eval workflow; AWS-specific tooling like CloudWatch metrics and Bedrock model evaluation jobs are optional add-ons

## Scenarios in play

- **Claude for operations** (`claude-for-operations`), Bedrock's IAM, CloudTrail, VPC endpoints, and KMS controls are the operational substrate this scenario depends on for AWS-native enterprise rollouts
- **Structured data extraction** (`structured-data-extraction`), Common Bedrock workload: route extraction jobs through Lambda or Step Functions backed by Claude on Bedrock, often with Knowledge Bases for the document corpus

## Curated sources

- **Claude on Amazon Bedrock; Anthropic API documentation** (anthropic-blog, 2025-09-01): Canonical reference for the SDK surface, model id formats, inference profile usage, and feature-availability table on Bedrock. Pair with Skilljar Lesson 4 when you start authenticating against a real AWS account.
- **Use Anthropic models in Amazon Bedrock; AWS documentation** (anthropic-blog, 2025-10-15): AWS's own integration docs covering model enablement, IAM permissions, cross-region inference profiles, and the converse API parameter reference for Anthropic models on Bedrock.
- **Building effective agents** (anthropic-blog, 2024-12-19): Anthropic's primitives-first take on agents; useful when deciding whether to use Bedrock Agents (managed) or roll your own with the raw tool-use primitives the course teaches.

## FAQ

### Q1. What is the difference between using Claude through the Anthropic API and through Amazon Bedrock?

The application code is roughly 95% identical; the differences are at the deployment seam. Bedrock uses AWS IAM instead of an ANTHROPIC_API_KEY, calls boto3.client('bedrock-runtime').converse(...) instead of Anthropic().messages.create(...), wraps content in lists of blocks even for plain text, uses inference profiles for cross-region availability, and gives you AWS-managed extras (Guardrails, Knowledge Bases, Agents). Choose Bedrock when your stack is on AWS; choose direct API for simpler auth and fastest access to new features.

### Q2. How do I authenticate with Claude on Amazon Bedrock?

Use AWS standard credentials. In dev, run aws configure with an access key + secret. In production, attach an IAM role to your compute (EC2 instance profile, ECS task role, Lambda execution role); boto3 picks up the role automatically. Required permission is bedrock:InvokeModel (and bedrock:InvokeModelWithResponseStream for streaming) on the specific model ARN. There is no API key; auth is bound to an AWS principal and IAM policy is your security boundary.

### Q3. Why does my Bedrock request return a model-not-found error when the model exists?

Almost always a regional availability mismatch. Not every Claude model is hosted in every AWS region; for example, Claude Sonnet might be in us-west-2 while you are calling from us-east-1. The fix is to use a cross-region inference profile rather than the raw model id. Look under Cross-region inference in the Bedrock console (not the main model catalog), copy the profile id, and pass it as modelId. AWS will route the request to a region where the model is available.

### Q4. What is a Bedrock inference profile and when should I use one?

An inference profile is an AWS-Bedrock-specific abstraction that bundles a model with one or more regions where it can be served. Use one whenever you do not want to manually track model-region availability; which in practice means almost always in production. Pass the profile id as modelId and AWS automatically routes your request to a region with capacity. There is no analogue on Vertex AI or the direct Anthropic API; this is a Bedrock-only concept and a frequent exam topic for D5 deployment questions.

### Q5. Should I use Bedrock Knowledge Bases or build my own RAG pipeline on Bedrock?

Knowledge Bases is AWS's managed RAG service: it handles S3 ingestion, chunking, embedding (Titan or Cohere), vector storage (OpenSearch Serverless or Aurora), and retrieval. Use it when you want managed operations and your corpus lives in S3. Build your own when you need custom chunking strategies, contextual retrieval, hybrid BM25+embeddings with reranking, or non-S3 sources. The Skilljar course teaches the underlying primitives so you can do either; Knowledge Bases is the managed shortcut, your own pipeline is the precision option.

### Q6. Does prompt caching work on Claude through Amazon Bedrock?

Yes. Prompt caching, vision, PDF support, citations, extended thinking, and tool use all work on Bedrock with the same TTLs, breakpoint rules, and pricing multipliers as the direct API. The message-format protocol is identical (just wrapped in content-block lists). The features that occasionally lag are at the tool layer; built-in web search and computer use have shipped with deployment-specific availability gates. The batch API is exposed as Bedrock's separate Batch Inference jobs rather than inline messages.batches.

### Q7. How do I install and use the boto3 SDK for Bedrock with Claude?

Run pip install boto3 (which most AWS Python projects already have). Then: client = boto3.client('bedrock-runtime', region_name='us-west-2'). Call client.converse(modelId=..., messages=...) to send a request. Extract the response with response['output']['message']['content'][0]['text']. For streaming, use client.converse_stream(...) and iterate the EventStream. There is also an AnthropicBedrock SDK from Anthropic that wraps boto3 with a more familiar Anthropic-style API surface; pick whichever feels more natural to your codebase.

### Q8. Can I use HIPAA, FedRAMP, or IRAP-compliant Claude through Bedrock?

Yes; the compliance posture is AWS's, and Claude on Bedrock inherits it. SOC 1/2/3, ISO 27001, HIPAA-eligible (with a BAA), FedRAMP High in GovCloud regions, and IRAP for Australia all extend to Anthropic models served through Bedrock. The compliance story is Bedrock's, not Anthropic's directly, which is one of the main reasons regulated industries pick Bedrock over the direct API. Confirm the specific certifications in the AWS compliance program for your target region before going to production.

---

**Source:** https://claudearchitectcertification.com/knowledge/claude-with-bedrock
**Vault sources:** Course_11/Lesson_03_accessing-the-api.md; Course_11/Lesson_04_making-a-request.md; Course_11/Lesson_05_multi-turn-conversations.md; Course_11/Lesson_07_system-prompts.md; Course_11/Lesson_10_streaming.md; Course_11/Lesson_30_introducing-tool-use.md; Course_11/Lesson_57_prompt-caching.md; Course_11/Lesson_61_introducing-mcp.md; Course_11/Lesson_73_agents-overview.md
**Last reviewed:** 2026-05-06