Deep dive 6.8 · Claude on Bedrock & Vertex

Part 0

Why this page exists

The three 8-hour engineering courses share ~85% of their curriculum - that shared core is pages 6.1-6.7. What remains is the platform-specific 15%: how to enable, authenticate and call Claude inside AWS and GCP. Thirty minutes here saves you the classic first-week losses: the wrong region, the missing IAM action, the model ID that isn't quite the one in the docs.

Core - the Bedrock lane (our estate) Advanced - Vertex mirror + portability Covers the setup/access modules of both cloud courses

★ What you walk out with Working Bedrock calls two ways (Anthropic SDK and boto3 converse), the identical-vs-different map so your 6.1-6.7 knowledge transfers cleanly, the Vertex equivalent, and a provider-portable client wrapper.

Part 1 · the enterprise reasons

Why cloud-hosted Claude at all 5 min

If api.anthropic.com works fine on your laptop, why do enterprises route through Bedrock or Vertex? Not for the model - it's the same Claude. For everything around it.

CoreThe five reasons enterprises pick the cloud front door5 min▶

Data residency: requests are processed inside a cloud region you choose. When legal says "this data does not leave our region/account boundary", the cloud-hosted route is how you comply without a debate per project.
Private networking: with VPC endpoints (AWS PrivateLink / GCP Private Service Connect), traffic to the model never touches the public internet - it stays on the cloud backbone inside your network perimeter. Security teams stop asking about egress.
IAM-native auth: no API keys to issue, rotate, leak or revoke. Access is an IAM role/service account like every other cloud resource - your existing least-privilege review process just works, and CloudTrail/Cloud Audit Logs record who called what.
Unified billing and commitments: Claude usage lands on the cloud bill you already have, counts toward negotiated marketplace spend commitments, and needs no new vendor onboarding through procurement.
Compliance inheritance: the model endpoint sits inside the cloud's existing certification scope (the SOC/ISO/HIPAA-eligible machinery your auditors already accepted), which shortens security review from months to a form.

Real world

A bank's data science team prototyped happily on the first-party API for six weeks - then the production review asked three questions: does data leave our AWS account boundary? who holds the credentials? which bill does it land on? The Bedrock answers (no - VPC endpoint; nobody - IAM role; ours - consolidated billing) closed the review in one meeting. Same prompts, same model, different front door.

🔍 Click to zoom - same Claude, same prompts; Bedrock changes who holds the keys and the bill

Part 2 · our production lane

Claude on Amazon Bedrock 15 min

Three things to get right: model access in the console, IAM permissions, and the model ID format. Then two ways to call it.

CoreBedrock setup: access, IAM, model IDs5 min▶

Enable model access: in the AWS console, Bedrock → Model access → request the Anthropic models you need. This is per-region - a model enabled in us-east-1 is NOT enabled in eu-west-1. "AccessDeniedException" on your first call is almost always this or the next bullet.
IAM permissions: the caller's role needs bedrock:InvokeModel (and bedrock:InvokeModelWithResponseStream for streaming) on the model resources. Scope the Resource to specific models rather than * - it's an easy least-privilege win and exactly what a security review checks.
Model IDs: Bedrock model IDs are not the first-party names. Current convention is the cross-region inference-profile prefix format - a geography prefix plus the Anthropic ID, e.g. the us.anthropic.claude-... naming pattern - which lets AWS route your request across regions in that geography for capacity. IDs evolve with model releases: check the Bedrock console for the current ID rather than copying one from a blog post (including this one).

Region is part of the address Pin the region deliberately and early: model access, quotas, model availability and your VPC endpoint are all per-region. Teams that let each script default to a different region spend their first week debugging phantom permission errors.

CoreCalling Claude on Bedrock, way 1: the Anthropic SDK4 min▶

The anthropic python package ships an AnthropicBedrock client. Auth comes from the standard AWS credential chain (env vars, SSO profile, instance role) - no API key. Everything after the constructor is the same messages.create you know from 6.1.

★ AnthropicBedrock: your 6.1 code, new front doorfrom anthropic import AnthropicBedrock client = AnthropicBedrock(aws_region="us-east-1") msg = client.messages.create( model="us.anthropic.claude-...", # check the console for the current ID max_tokens=1024, system="You are a concise data-engineering assistant.", messages=[{"role": "user", "content": "Explain VPC endpoints in 3 bullets."}], ) print(msg.content[0].text) # Streaming, tool use, vision: same shapes as the first-party API. with client.messages.stream( model="us.anthropic.claude-...", # check the console max_tokens=1024, messages=[{"role": "user", "content": "Stream me a haiku about IAM."}], ) as stream: for text in stream.text_stream: print(text, end="")

CoreCalling Claude on Bedrock, way 2: boto3 converse4 min▶

The AWS-native route: boto3 with the bedrock-runtime service and the converse API - one uniform request shape across every Bedrock model, Claude included. Note the shape differences: content is a list of blocks with a text key, system is a list, and generation params live in inferenceConfig.

★ boto3 converse: the AWS-native shapeimport boto3 brt = boto3.client("bedrock-runtime", region_name="us-east-1") resp = brt.converse( modelId="us.anthropic.claude-...", # check the console for the current ID system=[{"text": "You are a concise data-engineering assistant."}], messages=[ {"role": "user", "content": [{"text": "Explain VPC endpoints in 3 bullets."}]}, ], inferenceConfig={"maxTokens": 1024, "temperature": 0.5}, ) print(resp["output"]["message"]["content"][0]["text"])

Which way? The Anthropic SDK if your team lives in Anthropic's docs and wants code that stays close to 6.1-6.7 (and ports to first-party or Vertex with one line changed). The converse API if you're an AWS-native shop that wants one client, one IAM story and one request shape across all Bedrock models. Both are production-grade; pick one per codebase and stop.

CoreWhat's identical vs different on Bedrock4 min▶

The point of this table is relief: your 6.1-6.7 knowledge transfers almost entirely. What changes is the plumbing around the call, not the call.

Aspect	First-party API	Bedrock
Messages, system prompts, multi-turn	Yes	Identical
Tool use, streaming, vision	Yes	Identical shapes
Auth	x-api-key header	SigV4 via IAM roles - no API keys
Model IDs	claude-sonnet-... style names	Inference-profile IDs (us.anthropic.... style)
Availability	One global endpoint	Per-region: access, models and quotas all vary
Quotas & limits	Anthropic rate limits	AWS service quotas - raise via the console
Newest features	Land here first	Some features lag the first-party API
Logging & audit	Your own	CloudTrail, CloudWatch out of the box

Part 3 · the GCP mirror + choosing your lane

Vertex AI, lanes, and portability 10 min

Vertex is the same story with GCP nouns: Model Garden instead of Model access, service accounts instead of IAM roles, an @-versioned model name instead of an inference profile.

AdvancedVertex AI setup and the AnthropicVertex client4 min read▶

Enable: in the GCP console, find Claude in the Vertex AI Model Garden and enable it for your project. As with Bedrock, availability is per-region - pick a region that hosts the model you want.
Auth: Application Default Credentials - a service account with the Vertex AI user role, or your gcloud login locally. No API keys here either.
Model names: Vertex uses an @-version convention - a name like claude-sonnet-5@ plus a version marker. Same caveat as Bedrock: names evolve, check the Model Garden page for the current one.

★ AnthropicVertex: the GCP mirrorfrom anthropic import AnthropicVertex client = AnthropicVertex( project_id="my-gcp-project", region="us-east5", # a region where the model is available ) msg = client.messages.create( model="claude-sonnet-5@...", # check Model Garden for the current name max_tokens=1024, messages=[{"role": "user", "content": "Explain Model Garden in 2 lines."}], ) print(msg.content[0].text)

Notice what didn't change: messages.create, the message shapes, tool use, streaming. The Anthropic SDK makes the three front doors nearly interchangeable at the code level - which is exactly what the portability card below exploits.

CoreChoosing your lane3 min▶

First-party API: fastest access to new models and features, simplest setup (one API key). The default for prototypes, evals and anything that hasn't met a security review yet.
Bedrock: the choice when you're an AWS shop - IAM auth, VPC endpoints, CloudTrail, AWS billing. Production workloads that touch governed data belong here.
Vertex: the same argument for GCP estates. If your data lives in BigQuery and your workloads run on GKE, Vertex keeps Claude inside that perimeter.

Real world

Our context makes this a short conversation: the estate is AWS, and the WorkSpaces reality from Session 5 means our production workloads already live inside AWS-managed boundaries with IAM everywhere. So Bedrock is our production lane - private networking, roles instead of keys, usage on the AWS bill. The first-party API stays in the toolkit for prototyping and for trying features before they reach Bedrock. Build on first-party, ship on Bedrock.

🔍 Click to zoom - build on first-party, ship on Bedrock once it clears review

AdvancedMigration notes: keeping code portable3 min read▶

Since prototype and production live on different front doors, make switching a config change, not a refactor:

Thin wrapper over the client: exactly one function in the codebase constructs a client. Business logic imports the wrapper, never a provider class.
Model ID as config: IDs differ per provider (claude-sonnet-... vs us.anthropic.... vs ...@version), so they live in env vars or config files - never hardcoded in application code.
No provider-specific params in business logic: stick to the shared surface (messages, system, max_tokens, tools, streaming). Anything provider-specific stays inside the wrapper, behind a comment explaining why.

★ Provider-portable client factoryimport os def make_client(): provider = os.environ.get("CLAUDE_PROVIDER", "anthropic") if provider == "bedrock": from anthropic import AnthropicBedrock return AnthropicBedrock( aws_region=os.environ.get("AWS_REGION", "us-east-1")) if provider == "vertex": from anthropic import AnthropicVertex return AnthropicVertex( project_id=os.environ["GCP_PROJECT"], region=os.environ["GCP_REGION"]) from anthropic import Anthropic return Anthropic() # first-party: reads ANTHROPIC_API_KEY client = make_client() MODEL = os.environ["CLAUDE_MODEL"] # provider-specific ID lives in config msg = client.messages.create( model=MODEL, max_tokens=1024, messages=[{"role": "user", "content": "Same code, three front doors."}], )

Test the wrapper on day one Run your eval set (6.2) through both lanes before you depend on the portability. Same model family through a different front door should score the same - and if a feature you rely on lags on Bedrock, you want to learn that from a failing eval, not a production incident.

35-45 · hands on

Try it yourself ◐ 3 exercises

1 · Same prompt, two front doors. Run one identical prompt via the first-party client and via AnthropicBedrock. Diff the two scripts: the delta should be the constructor line and the model ID, nothing else. If more changed, your code has provider details where they don't belong.
2 · Least-privilege IAM. Create an IAM role whose policy allows bedrock:InvokeModel on exactly ONE model resource. Verify the happy path works, then try a different model ID and confirm the AccessDenied - now you've seen the guardrail from both sides.
3 · The PROVIDER switch. Wrap client creation behind the CLAUDE_PROVIDER env var (factory above), run the same script with anthropic and bedrock values, and confirm identical behavior. Commit the wrapper - it's the first file of your production lane.

Source material

Official courses covered

This page covers the platform-specific setup and access modules of the two cloud courses at claude.com/resources/courses; their shared-core modules are pages 6.1-6.7.

✓Claude with Amazon Bedrock - setup/access modulesmodel access, IAM, inference-profile IDs, SDK + converse; shared-core modules → 6.1-6.7

✓Claude with Vertex AI - setup/access modulesModel Garden, project + region, AnthropicVertex; shared-core modules → 6.1-6.7

Deep dive 6.8 cheat sheet · pin this

Why cloud-hostedData residency, VPC endpoints, IAM auth, unified billing, compliance inheritance - the plumbing, not the model.

Bedrock setupEnable model access per REGION, grant bedrock:InvokeModel, use inference-profile IDs (us.anthropic....) - check the console.

Two ways to callAnthropicBedrock (Anthropic-native, ports easily) or boto3 converse (AWS-native, one shape for all models). Pick one per codebase.

Identical vs differentMessages, tools, streaming, vision: identical. Auth, model IDs, regions, quotas, feature timing: different.

Our laneAWS estate → Bedrock for production, first-party API for prototyping. Build on first-party, ship on Bedrock.

PortabilityOne client factory, model ID as config, no provider params in business logic. Switching lanes = changing env vars.