You'll walk away with
- How to enable Claude models in Bedrock and authenticate via AWS IAM (access keys, IAM roles, or SSO)
- How the boto3
bedrock-runtimeclient and theconverseAPI 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
Read these first
Lesson outline
Every lesson from Claude with Amazon Bedrock with our one-line simplification. The Skilljar course is the source; we summarize.
Show all 83 lessons
| # | Skilljar lesson | Our simplification |
|---|---|---|
| 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. |
The course in 7 paragraphs
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.
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. Useaws 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:InvokeModelon 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 anAnthropicBedrockconvenience wrapper, but the official Skilljar course teaches raw boto3. - Method: `converse`, not `messages.create`
client.converse(modelId=..., messages=[user_message]). Streaming usesconverse_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
Concept: tool-calling ↗Cross-region inferencein the Bedrock console) so AWS auto-routes to a region where the model is available. Pass the profile id asmodelId. 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.
6 takeaways with cross-pillar bridges
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.
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.
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.
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.
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.
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.
How this maps to the CCA-F exam
3 hand-picked extras
These amplify the Skilljar course beyond what the course itself covers. Each was picked for a specific reason.
Claude on Amazon Bedrock; Anthropic API documentation
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.
Read source ↗Use Anthropic models in Amazon Bedrock; AWS documentation
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.
Read source ↗Building effective agents
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.
Read source ↗Concepts in this course
Tool calling
Same protocol on Bedrock; tool schemas wrap into `toolConfig` / `toolUse` / `toolResult` blocks
Concept: tool-calling ↗Prompt caching
Available on Bedrock with same TTL/breakpoint rules as direct API
Concept: prompt-caching ↗Batch API
Exposed on Bedrock as the separate `Batch Inference` job runner rather than inline calls
Concept: batch-api ↗MCP
Protocol-level, deployment-independent; works with Bedrock-backed Claude
Concept: mcp ↗Vision and multimodal
Image and PDF inputs work via converse content blocks (base64 or S3 references)
Concept: vision-multimodal ↗Evaluation
Same eval workflow; AWS-specific tooling like CloudWatch metrics and Bedrock model evaluation jobs are optional add-ons
Concept: evaluation ↗Where you'll see this in production
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
Scenario: claude-for-operations ↗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
Scenario: structured-data-extraction ↗Other course mirrors you may want next
8 questions answered
Phrased as the way real students search. Tagged by intent so you can scan to what you actually need.
ComparisonWhat is the difference between using Claude through the Anthropic API and through Amazon Bedrock?
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.How-toHow do I authenticate with Claude on Amazon Bedrock?
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.TroubleshootWhy does my Bedrock request return a model-not-found error when the model exists?
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.DefinitionWhat is a Bedrock inference profile and when should I use one?
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.ComparisonShould I use Bedrock Knowledge Bases or build my own RAG pipeline on Bedrock?
ScopeDoes prompt caching work on Claude through Amazon Bedrock?
Batch Inference jobs rather than inline messages.batches.How-toHow do I install and use the boto3 SDK for Bedrock with Claude?
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.