What Anthropic teaches in this course
This course is the platform-agnostic Claude API course (Course 6 claude-api-foundations) wrapped in Google Cloud; same prompt engineering, same eval workflow, same tool-use mechanics, same RAG patterns, same MCP protocol, same agent design. If you have done Course 6, roughly 85 of the 93 lessons will feel familiar verbatim. The ~8 lessons that *justify a separate Knowledge page* are the deployment seam: how you authenticate, how you address models, how regions and quotas work, and how Vertex's enterprise controls (IAM, VPC-SC, Cloud Logging) fit on top. This page focuses on those seams; for everything else, lean on claude-api-foundations as the canonical reference.
Authentication on Vertex is gcloud-mediated, not API-key-mediated. You install the gcloud CLI, run gcloud init and gcloud auth application-default login, set a project with gcloud config set project YOUR_PROJECT_ID, and from then on the AnthropicVertex SDK picks up Application Default Credentials automatically. There is no ANTHROPIC_API_KEY. The implication for your architecture is that auth is bound to a Google Cloud identity (a user account in dev, a service account in production), which means your IAM model becomes the security boundary. Grant roles/aiplatform.user to the service account, scope it to the project, and rotate via Google Cloud's normal service-account-key lifecycle (or Workload Identity Federation if you are running outside GCP).
The SDK surface differs in three load-bearing ways. First, the import: from anthropic import AnthropicVertex instead of from anthropic import Anthropic. Second, the constructor: AnthropicVertex(region="global", project_id="your-project-id"); the region and project_id are mandatory and bind every request to a specific Vertex tenant. Third, the model id format: Vertex uses claude-sonnet-4@20250514 rather than claude-sonnet-4-20250514 (note the @ instead of trailing dash). Everything below those three lines (messages.create, content blocks, tool schemas, streaming, prompt caching) is byte-for-byte identical to the direct API. pip install "anthropic[vertex]" pulls the right extras.
Regional model availability is a real operational concern. Not every Claude model is hosted in every Vertex region; new models often launch in us-east5 or us-central1 first and roll out elsewhere over weeks. The Vertex region="global" setting routes to the nearest available region and is usually the right default for production unless you have data-residency constraints. If you do need a specific region (EU data residency, regulated workloads), check the Model Garden listing for that region before you commit; a model that exists in us-east5 will return a not found error in europe-west4 even though both are valid Vertex regions. Quotas are per-project per-region and are managed in the Cloud Console under Quotas & system limits; default quotas are conservative and you will likely raise them before production traffic.
Enterprise controls ride on top of Vertex unchanged. This is the main reason customers choose Vertex over the direct Anthropic API: VPC Service Controls confine traffic to a security perimeter, Cloud Audit Logs capture every messages.create invocation with caller identity, Customer-Managed Encryption Keys (CMEK) wrap inputs and outputs, and Private Service Connect avoids public-internet egress. None of those are Anthropic features per se; they are GCP features that Vertex inherits because Claude is served as a first-class Vertex AI model. The compliance story is Vertex's, not Anthropic's: SOC 2, ISO 27001, HIPAA BAA (where applicable), FedRAMP for government workloads. If your org has a Google Cloud landing zone, deploying Claude on Vertex slots into existing policy controls instead of standing up a parallel data-flow review.
Feature parity is high but not perfect, and the gaps move over time. Prompt caching, vision, PDF support, citations, extended thinking, and the batch API generally land on Vertex within weeks of the direct API release; the message-format protocol is identical. 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, so check the Anthropic on Vertex docs before depending on them. Pricing is set by Google Cloud (not Anthropic) and is typically priced per 1M input/output tokens at parity with the direct API, billed through your GCP invoice. Cache hits and batch requests get the same multipliers you see on direct API.
When to choose Vertex vs the direct Anthropic API vs Bedrock. Pick Vertex when your stack is already on Google Cloud; the auth, billing, IAM, audit, and data-residency stories all consolidate, and you avoid a second vendor relationship. 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 Bedrock (covered in claude-with-bedrock) when your stack is on AWS for the symmetric reasons. The application code is roughly 95% portable across all three; the differences are auth, model id format, the SDK constructor, and operational integrations. Picking a deployment platform is mostly an organizational decision, not a technical one; and the exam expects you to recognize that.
You'll walk away with
- How to enable Claude models in Vertex AI Model Garden and authenticate via gcloud Application Default Credentials
- How the AnthropicVertex Python SDK differs from the direct Anthropic SDK (project_id, region, model name format)
- Which Claude features ride on top of Vertex unchanged (prompt caching, vision, PDF support, citations, extended thinking, batch)
- How regional model availability and quota management work on Vertex compared to the direct API
- How IAM, VPC Service Controls, and Cloud Logging fit into a Vertex-hosted Claude deployment
- When to choose Vertex AI vs the direct Anthropic API vs Amazon Bedrock for a given workload
93 lessons, with our annotations
6 ideas to carry into practice
Lines worth keeping
Auth: gcloud ADC instead of API key
No ANTHROPIC_API_KEY. Run gcloud auth application-default login in dev; use a service account with roles/aiplatform.user in prod. Auth is bound to a Google Cloud identity, which means IAM is your security boundary.
SDK constructor: `AnthropicVertex(region, project_id)`
from anthropic import AnthropicVertex and pass region and project_id. region="global" is a sensible default unless data residency dictates otherwise. Install with pip install "anthropic[vertex]".
Model id format uses `@` not `-`
claude-sonnet-4@20250514 on Vertex, claude-sonnet-4-20250514 on the direct API. A small but easy-to-trip-on difference; copy from the Model Garden listing rather than from the Anthropic docs.
Regional availability is real
Not every model is in every region. New models tend to launch in us-east5 first. Check Model Garden for your target region before you commit. region="global" routes to nearest available.
Enterprise controls come from GCP
VPC-SC, CMEK, Cloud Audit Logs, Private Service Connect, and the GCP compliance posture (SOC 2, ISO 27001, HIPAA BAA, FedRAMP) all apply because Claude is served as a Vertex model. Compliance story is GCP's, not Anthropic's directly.
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, and quota management on Vertex AI. The API/prompt/tool/RAG/MCP/agent content is identical to 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 Google Vertex AI?
The application code is roughly 95% identical; the differences are at the deployment seam. Vertex uses gcloud Application Default Credentials instead of an ANTHROPIC_API_KEY, requires AnthropicVertex(region, project_id) instead of Anthropic(), uses @ in the model id (e.g. claude-sonnet-4@20250514), and inherits Google Cloud's IAM, audit, VPC-SC, and compliance controls. Choose Vertex when your stack is on GCP; choose direct API for simpler auth and fastest access to new features.
How do I authenticate with Claude on Vertex AI?
Install the gcloud CLI, run gcloud init and gcloud auth login, set your project with gcloud config set project YOUR_PROJECT_ID, then run gcloud auth application-default login. The AnthropicVertex SDK picks up Application Default Credentials automatically. There is no API key; auth is bound to a Google Cloud identity (your user account in dev, a service account with roles/aiplatform.user in production).
Why does my Vertex AI 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 Vertex region, and new models often launch in us-east5 or us-central1 first. Check the Model Garden listing for your target region before you commit. The fix is usually to switch to region="global", which routes to the nearest available region, unless data residency dictates a specific region. Also confirm the model id format; Vertex uses claude-sonnet-4@20250514 with an @, not a trailing dash.
Does prompt caching work on Claude through Vertex AI?
Yes. Prompt caching, vision, PDF support, citations, extended thinking, and the batch API all work on Vertex with the same TTLs, breakpoint rules, and pricing multipliers as the direct API. The message-format protocol is identical. The features that occasionally lag are at the tool layer; the built-in web search tool and computer use have shipped with deployment-specific availability gates, so check the Anthropic on Vertex docs before depending on them.
Should I use Vertex AI or the direct Anthropic API for my production deployment?
Pick Vertex when your stack is already on Google Cloud; the auth, billing, IAM, audit, VPC-SC, and data-residency stories all consolidate into your existing GCP landing zone. Pick the direct Anthropic API when you want the fastest access to new models and features, simpler key-based auth, and no cloud lock-in. The application code is portable both ways, so this is mostly an organizational decision (where does your security review live, who pays the invoice) rather than a technical one.
How do I install the right Anthropic SDK for Vertex AI in Python?
Run pip install "anthropic[vertex]"; the [vertex] extras pull in the Google Auth dependencies needed to connect to Vertex. Then import AnthropicVertex (not Anthropic) and instantiate it with region and project_id. The same messages.create API works on both clients, so application code below the constructor line is unchanged.
What IAM permissions does my service account need to call Claude on Vertex?
At minimum, roles/aiplatform.user on the project. For production, scope tightly: grant only that role on only the project hosting your AI workloads, and rotate service-account keys via Workload Identity Federation if your code runs outside GCP. Auth is bound to identity, so any IAM policy you apply to the service account flows through to your Claude calls; including organizational policies on which regions are allowed and which models are enabled.
Can I use HIPAA, SOC 2, or FedRAMP-covered Claude through Vertex?
Yes; the compliance posture is Google Cloud's, and Claude on Vertex inherits it. SOC 2, ISO 27001, HIPAA BAA (where applicable), and FedRAMP for government workloads all extend to Anthropic models served through Vertex AI. The compliance story is Vertex's, not Anthropic's directly, which is one of the main reasons regulated industries pick Vertex over the direct API. Confirm the specific certifications in the Google Cloud Compliance Resource Center for your target region before going to production.