Enforcing Regional Endpoints with a GCP Org Policy Constraint

Claude on Vertex AI can be reached through three endpoint types. The global endpoint routes dynamically for maximum availability — Google states it "can process and serve your requests from any region that is supported by the model." Multi-region endpoints (currently us and eu) route dynamically within a geography, for data residency with high availability. Regional endpoints guarantee routing through one specific region.

For teams with residency requirements, the global endpoint is the one to worry about: any developer who sets region="global" — or copies a quickstart that does — sends traffic that may be served from anywhere the model is supported. Google Cloud provides an organization-policy answer.

The constraint: gcp.restrictEndpointUsage

An organization policy constraint is a rule an administrator applies at the organization, folder, or project level that limits how Google Cloud services can be used underneath it — regardless of what IAM permissions individual callers hold. Google's partner-model documentation names the relevant one for this problem: admins can force regional routing by blocking the global endpoint with constraints/gcp.restrictEndpointUsage.

Applied to the resource hierarchy covering your Claude workloads, the constraint turns "please don't use the global endpoint" into an error for any request that tries. Developers get fast, unambiguous feedback instead of silently non-compliant traffic. For the exact policy syntax and scoping options, work from Google's org-policy documentation — the constraint name above is the piece specific to this use case.

Pointing clients at the compliant endpoints

Enforcement without a migration path just breaks things, so pair the constraint with client configuration. The multi-region endpoints use dedicated regional-endpoint domains, different from the default aiplatform.googleapis.com host:

In the Python SDK, the switch is the region parameter, which accepts "global", "us"/"eu", or a specific region such as "us-east1" or "europe-west1":

from anthropic import AnthropicVertex

# Multi-region: stays within the US geography
client = AnthropicVertex(project_id="my-project", region="us")

message = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello, Claude"}],
)

Know the costs of pinning before you enforce

Three documented trade-offs to put in the design review:

• A 10% pricing premium. Regional and multi-region endpoints cost 10% more than global for Claude Sonnet 4.5 and later models — Google's pricing page shows, for example, Opus 4.8 at $5.50/$27.50 per 1M tokens on us versus $5/$25 global.
• Model coverage differs. Multi-region endpoints support Claude models version 4.7 and later (e.g. claude-opus-4-7, claude-opus-4-8, claude-fable-5); the global endpoint carries a longer back-catalog. Teams on older models may need specific regional endpoints instead.
• Availability is the thing you're trading away. Google positions global routing as reducing errors and improving availability; pinning narrows the serving pool. Quotas are also independent buckets per endpoint type, so a migration shifts which quota you consume.

One residency nuance worth quoting to your compliance team verbatim: Google documents that data at rest is stored within the selected region or multi-region for partner models, but "the regionalization of data processing may vary." Confirm what that means for your specific obligations with Google rather than assuming pinning settles every residency question.

Where to go next

This is the Vertex sibling of Bedrock's region-pinning story — compare the SCP article. For the rest of the Vertex lockdown kit, see the VPC-SC logging gap and regions and availability.

Sources

• Vertex AI — Use partner models (endpoints, org policy constraint)
• Claude on Vertex AI (Anthropic docs)
• Generative AI on Vertex AI — Pricing