What Anthropic teaches in this course
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.
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-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
83 lessons, with our annotations
6 ideas to carry into practice
Lines worth keeping
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.
Related concept →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.
How this course shows up on the exam
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.
Blueprint weight15% (D5) + 18% (D2)Check the pattern
Your agentic loop keeps running after Claude has clearly finished its task. Which control was most likely missed?
Frequently asked
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.
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.
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.
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.
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.
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.
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.
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.