Course: Claude with Google Cloud's Vertex AI

Mirrors: Anthropic Academy — Claude with Google Cloud's Vertex AI · https://anthropic.skilljar.com/ Audience: Developers and enterprise teams already on Google Cloud. Comfortable with a GCP project, gcloud, and a terminal. · Time: ~75 min + project Prereqs: building-with-the-claude-api (you should know the Messages API shape), a GCP project with billing enabled, and the gcloud CLI installed. · Backing notes: claude-bedrock (the analogous cloud-deployment note), messages-api Project: p05-first-api-call — Vertex variant (make your first Claude call through Vertex AI instead of the first-party API)

This course re-points your existing Claude API skills at Google Cloud's Vertex AI — GCP's managed ML platform, which serves Claude through its Model Garden. The Messages API shape is the same; what changes is GCP-native authentication, a project + region setup, GCP billing and governance, and Vertex-style model IDs. By the end you can enable Claude in Vertex, authenticate with Application Default Credentials, and call Claude with the Anthropic Vertex SDK.

Learning objectives

After this course you can:

Explain why a team runs Claude on Vertex AI (GCP-native auth, governance, billing) instead of the first-party API.
Enable Claude in the Vertex AI Model Garden for your project.
Authenticate with gcloud / Application Default Credentials (ADC) and service accounts.
Set up the project ID and region every Vertex call needs.
Call Claude with the Anthropic Vertex SDK (AnthropicVertex) using the same messages.create(...) surface.
Use the correct Vertex model ID pattern and region values, and name the differences vs. the first-party API.

Module 1 — Why Vertex AI

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

🎬 Scene — Two diagrams: one app calls api.anthropic.com; the other calls a Vertex endpoint inside the customer's GCP project. Same Claude behind both.

🧠 Concept — Vertex AI is a delivery channel for Claude on Google Cloud, not a different model. The model and the Messages API request shape are the same; GCP supplies the authentication, the endpoint, the billing, and the governance. (Analogous note: claude-bedrock.)

🖼 On screen

First-party:  your app ──► api.anthropic.com ──────────────► Claude
Vertex AI:    your app ──► <region>-aiplatform.googleapis.com ──► Claude
                          (inside your GCP project / IAM / billing)

✅ Checkpoint — In one sentence: what stays the same on Vertex, and what changes?

🎞 Frame 2 · Why GCP shops choose Vertex · ⏱ ~3 min

🎬 Scene — A checklist fills in: ADC/service-account auth, one GCP bill, Cloud IAM + audit logging.

🧠 Concept — Vertex exists for organizations standardized on Google Cloud. Running Claude through Vertex reuses GCP's identity, billing, and governance instead of adding a separate vendor relationship.

🖼 On screen

Driver	What it means in practice
GCP-native auth	No separate Anthropic API key — access is governed by Cloud IAM, ADC, and service accounts you already manage.
Governance	Cloud Audit Logs, VPC Service Controls, and org policies wrap every Claude call.
Billing	Claude usage lands on your existing GCP invoice and committed-spend agreements, not a second bill.
Co-location	Claude sits next to your other Vertex models, BigQuery, and GCS in the same project and region.

⚠️ Gotcha — As with any cloud channel, this is about operational fit — Claude's capabilities are the same.

✅ Checkpoint — Your platform team mandates "all model access via service accounts, billed to our GCP org." Which two drivers does that map to?

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

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

🧠 Concept — Vertex trades a little immediacy for GCP integration. New Claude models and features generally appear on the first-party API first and reach Vertex on a lag; some features differ or aren't available.

🖼 On screen

Choose Vertex       → already on GCP, need ADC/service accounts, GCP billing/governance
Choose first-party  → want the latest model/feature fastest, simpler setup,
                      not building a GCP-native product

✅ Checkpoint — Name one situation where the first-party API beats Vertex even for a GCP shop.

Module 2 — Access and authentication

🎞 Frame 4 · Enabling Claude in the Model Garden · ⏱ ~3 min

🎬 Scene — The Vertex AI Model Garden in the GCP console; the user finds Anthropic's Claude card and clicks "Enable."

🧠 Concept — Claude is offered through Vertex's Model Garden. Before any call works you enable the Claude model(s) for your project and ensure the Vertex AI API is turned on. This is a one-time, per-project step.

🖼 On screen

GCP console → Vertex AI → Model Garden → search "Claude" (Anthropic)
  → Enable / accept terms
  → ensure the Vertex AI API is enabled for the project

⚠️ Gotcha — A call that fails on a fresh project is usually "Model Garden not enabled" or "Vertex AI API disabled," not a credential problem.

✅ Checkpoint — What two things must be enabled in a project before a Vertex Claude call can succeed?

🎞 Frame 5 · gcloud, ADC, and service accounts · ⏱ ~3 min

🎬 Scene — A terminal runs gcloud auth application-default login; later, a service-account key path is set in the environment for a server.

🧠 Concept — Vertex auth is GCP auth. There is no Anthropic API key. The SDK obtains a Google OAuth token via Application Default Credentials: locally you run gcloud auth application-default login; on servers you use a service account (workload identity, or a key file). IAM roles (e.g. the Vertex AI User role) authorize the calls.

🖼 On screen

Local dev:   gcloud auth application-default login   → ADC for your user
Server/CI:   service account → workload identity OR GOOGLE_APPLICATION_CREDENTIALS=key.json
IAM role:    grant "Vertex AI User" (aiplatform.user) to the identity

⚠️ Gotcha — ADC is a credential discovery mechanism, not a credential type. If the SDK can't find ADC (no gcloud login, no service account), the call fails before it reaches Claude.

✅ Checkpoint — What's the difference between how you authenticate locally vs. on a production server?

🎞 Frame 6 · Project and region setup · ⏱ ~3 min

🎬 Scene — Two values get pinned: a GCP project_id and a region; the SDK client takes both.

🧠 Concept — Every Vertex call is scoped to a project and a region. The project decides billing and quota; the region decides where inference runs (data residency) and which models/snapshots are available. Both are required to construct the client.

🖼 On screen

project_id = "my-gcp-project"     # billing + quota
region     = "us-east5"           # a specific region, OR
region     = "us" / "eu"          # a multi-region, OR
region     = "global"             # global routing (often recommended for availability)

⚠️ Gotcha — Not every model is in every region. If a model ID validates in one region but not another, it's a regional-availability issue — check Model Garden for the regions that serve it.

✅ Checkpoint — What does the project control, and what does the region control?

Module 3 — Calling Claude on Vertex

🎞 Frame 7 · The Anthropic Vertex SDK · ⏱ ~3 min

🎬 Scene — A Python snippet builds an AnthropicVertex client with a project and region; it looks almost identical to first-party code.

🧠 Concept — The Anthropic SDK ships a Vertex client (AnthropicVertex) that exposes the same messages.create(...) surface you already know. It handles the Google OAuth token (from ADC) and the Vertex endpoint for you — you pass project_id and region, and a Vertex model ID.

🖼 On screen

from anthropic import AnthropicVertex

client = AnthropicVertex(project_id="my-gcp-project", region="us-east5")
# credentials come from ADC (gcloud login or service account)

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

⚠️ Gotcha — Install the Vertex extra (e.g. pip install "anthropic[vertex]"). The plain Anthropic() client with a custom base_url is not the supported path — use AnthropicVertex.

✅ Checkpoint — Which two constructor arguments does AnthropicVertex require, and where do credentials come from?

🎞 Frame 8 · First-party code → Vertex code · ⏱ ~3 min

🎬 Scene — A side-by-side diff: first-party Anthropic() becomes AnthropicVertex(project_id=..., region=...); everything inside messages.create(...) stays the same.

🧠 Concept — Porting first-party code to Vertex is a small, mechanical change: swap the client class, add project + region, and use a Vertex model ID. The request body — system prompt, messages, tools, max_tokens — is unchanged.

🖼 On screen

# First-party
client = Anthropic()                                    # ANTHROPIC_API_KEY
client.messages.create(model="claude-<family>-<ver>", ...)

# Vertex
client = AnthropicVertex(project_id="proj", region="us-east5")  # ADC, no API key
client.messages.create(model="claude-<family>-<ver>", ...)      # same body

✅ Checkpoint — What three things change between first-party SDK code and Vertex SDK code? (Client class, project+region, model ID — auth comes from ADC.)

🎞 Frame 9 · Vertex model IDs & regions · ⏱ ~3 min

🎬 Scene — Two model strings: a bare first-party-style ID for a current model, and a dated snapshot with an @-version separator.

🧠 Concept — Vertex model IDs take no provider prefix (unlike Bedrock's anthropic.). Current-generation models use the bare first-party ID; dated-snapshot models use an @ version separator (e.g. claude-<family>-<ver>@<date>, not a trailing -<date>).

🖼 On screen

Current model:    claude-<family>-<ver>
Dated snapshot:   claude-<family>-<ver>@<YYYYMMDD>     # '@', not a trailing dash
Region values:    "global" (recommended) | "us"/"eu" (multi) | "us-east5" (specific)

⚠️ Gotcha — Don't hardcode an exact model ID from memory. Confirm the live model ID and the regions that serve it in Model Garden. The patterns (bare ID, @-dated snapshot, no prefix) are stable; the specific strings are not.

✅ Checkpoint — How does a Vertex model ID differ from a Bedrock one, and how is a dated snapshot written?

Module 4 — Differences, governance, and good habits

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

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

🧠 Concept — Vertex serves the same Messages API shape, but it is partner-operated, so auth, IDs, and feature timing differ. Build to the Vertex parity reality, not to the assumption that everything first-party works identically.

🖼 On screen

Aspect	First-party	Vertex AI
Auth	API key (`x-api-key`)	GCP ADC / service account (OAuth token)
Model ID	`claude-<family>-<ver>`	bare ID; dated snapshots use `@<date>` (no prefix)
Scope	single endpoint	per-project + per-region (or `global`)
Tool use	native	native (same shape)
Latest models / features	first	slight lag — land first-party first
Some features	available	may be absent or exposed differently (check Vertex docs)

⚠️ Gotcha — A feature in the first-party docs (e.g. a particular server-side tool or beta) may not be on Vertex yet. Verify in Vertex's Claude docs before depending on it.

✅ Checkpoint — Name two concrete differences between a first-party Messages call and a Vertex AnthropicVertex call.

🎞 Frame 11 · GCP governance you inherit · ⏱ ~2 min

🎬 Scene — Cloud Audit Logs scroll; a VPC Service Controls perimeter blocks egress; an org policy denies a disallowed region.

🧠 Concept — Because calls are GCP API calls, they inherit GCP governance: Cloud Audit Logs for an audit trail, VPC Service Controls to keep traffic inside a perimeter, IAM for least-privilege access, and org policies / committed billing — all without changing your Claude request.

🖼 On screen

Your call ─► (Cloud Audit Logs record it) ─► (VPC-SC perimeter contains it) ─► Claude
            └─ IAM least-privilege + org policy on region/project

✅ Checkpoint — Which GCP feature gives you an audit trail of every Claude call, and which keeps the traffic inside a network perimeter?

🎞 Frame 12 · Pick a region, pin a model, you're done · ⏱ ~2 min

🎬 Scene — A recap slide: enable in Model Garden → ADC/service account → project + region → AnthropicVertex → live model ID.

🧠 Concept — The whole Vertex path is five steps. Once Claude is enabled and ADC is in place, your code is first-party code with a different client and a project/region — the request body never changed.

🖼 On screen

1. Enable Claude in Model Garden (+ Vertex AI API)
2. Authenticate with ADC (gcloud) or a service account
3. Pin project_id + region (consider "global")
4. Build AnthropicVertex(project_id, region)
5. Call messages.create(model=<live Vertex ID>, ...)

✅ Checkpoint — Without looking, list the five steps from enabling Claude to making a call.

🛠 Project

Complete p05-first-api-call — your first Claude API call, Vertex variant. Instead of the first-party API, you'll: enable Claude in the Model Garden, set up ADC (or a service account), choose a project + region, and make the same "hello" call with AnthropicVertex. Capture the response and journal one Vertex-specific difference you hit vs. the first-party path (auth, model ID, or region).

🧪 Self-check quiz

What stays the same between first-party Claude and Claude on Vertex, and what changes?
Name two of the drivers for choosing Vertex over the first-party API.
Which two things must be enabled in a GCP project before a Vertex Claude call works?
How do you authenticate locally vs. on a production server?
What does the project control, and what does the region control?
Which client class and which two constructor args do you use to call Claude on Vertex?
How does a Vertex model ID differ from a Bedrock one, and how is a dated snapshot written?
Name two differences from the parity table between first-party and Vertex.
List the five steps from enabling Claude to making a call.

<details><summary>Answers</summary>

The model and Messages API shape stay the same; auth (ADC/service account), scope (project+region), model-ID convention, and billing/governance change. 2. Any two of: GCP-native auth, GCP governance, GCP billing, co-location with other Vertex/GCP services. 3. The Vertex AI API and Claude in the Model Garden. 4. Locally: gcloud auth application-default login (ADC for your user); on a server: a service account (workload identity or key file). 5. Project controls billing/quota; region controls where inference runs (residency) and which models are available. 6. AnthropicVertex, with project_id and region; credentials come from ADC. 7. Vertex has no provider prefix (bare first-party ID), and dated snapshots use an @<date> separator (not a trailing dash); Bedrock uses an anthropic. prefix. 8. Any two of: API key vs. ADC, model-ID convention, per-project/region scoping, latest-feature timing, feature availability differences. 9. Enable Claude in Model Garden (+ Vertex AI API) → authenticate with ADC/service account → pin project + region → build AnthropicVertex → call messages.create with a live Vertex model ID.

</details>

🎓 Certificate criteria

You've "passed" Claude with Google Cloud's Vertex AI when you can:

Explain the GCP-native drivers and when first-party is the better choice.
Enable Claude in the Model Garden and authenticate via ADC / a service account.
Set up a project + region and construct an AnthropicVertex client.
State the Vertex model-ID and region conventions and the caveats vs. first-party.
Complete p05-first-api-call (Vertex variant) and journal one Vertex-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 (analogous cloud note), messages-api, model-family
Official model/ID and region details: Vertex AI Model Garden and Anthropic's Vertex docs (look up live model IDs and regions — don't hardcode).
Project: p05-first-api-call · Sibling course: claude-with-amazon-bedrock
Catalog: catalog