On most AWS services, choosing a region answers the residency question: the service runs there, so processing happens there. Claude Platform on AWS breaks that intuition by design. It is Anthropic-operated — AWS provides the authentication front door, IAM, and billing, while the models themselves run on Anthropic-managed infrastructure. Data may not reside in AWS at all, and inference may route to Anthropic's primary cloud. That architecture means two separate settings control two separate things, and residency-minded teams need to know which is which.
What the workspace's AWS region controls
Every workspace is bound to a single AWS region, visible in its ARN: arn:aws:aws-external-anthropic:{region}:{account-id}:workspace/wrkspc_.... That region pins the AWS side of the system:
- The gateway endpoint your requests enter through —
aws-external-anthropic.{region}.api.aws— and the region your SigV4 signatures must match; - IAM scoping, since workspace ARNs carry the region;
- CloudTrail, where your request audit events land;
- Billing attribution for the AWS Marketplace charges.
What it explicitly does not do, per Anthropic's documentation, is pin where model inference runs. The region is about the front door, not the kitchen.
What inference_geo controls
inference_geo is a request parameter (also settable as a workspace default) that constrains which of Anthropic's data centers may process the request. Two values are documented:
| Value | Inference runs in | Pricing |
|---|---|---|
global | Any Anthropic-operated data center | Standard rates |
us | US data centers only | 1.1x multiplier on standard rates |
The 1.1x premium on us is the price of constrained capacity: you are forgoing Anthropic's freedom to route your request wherever there is headroom. Whether a 10% uplift is worth it is a policy question, not an engineering one — but it should be answered deliberately, because the default is not the pinned option. If a request omits inference_geo, the workspace's default_inference_geo applies if configured; otherwise the request runs as global.
from anthropic import AnthropicAWS
client = AnthropicAWS() # AWS_REGION + ANTHROPIC_AWS_WORKSPACE_ID env vars
message = client.messages.create(
model="claude-opus-4-8",
max_tokens=512,
inference_geo="us", # pin inference to US data centers (1.1x pricing)
messages=[{"role": "user", "content": "Summarize this contract clause."}],
)Model support has a floor: inference_geo works on Claude Opus 4.6, Claude Sonnet 4.6, and later models; sending it with Opus 4.5, Sonnet 4.5, or Haiku 4.5 returns a 400 error.
Making the pin organizational, not per-request
A parameter every developer must remember is a control that will eventually be forgotten. The platform provides workspace-level guardrails: set default_inference_geo so unpinned requests inherit the right geography, and set allowed_inference_geos to make the restriction mandatory rather than advisory — a workspace allowing only us cannot be quietly routed globally by one team's code. Teams running multiple workspaces often dedicate one to residency-sensitive workloads with these controls locked, a pattern covered in the multi-workspace strategy guide.
inference_geo tells you where your prompts are processed. A review that checks only the first has not addressed data residency — and platform-level residency settings are one input among many, so confirm your overall obligations with your own counsel and providers.How the other platforms compare
This dial is distinctive: per the availability matrix, inference_geo exists on the first-party Claude API and Claude Platform on AWS, but not on Bedrock, Vertex AI, or Foundry. Those platforms handle residency with their own mechanisms — Bedrock with geographic inference profiles, Vertex with regional endpoints and org policy, and Foundry with Data Zone deployments, where Anthropic's docs note a US Data Zone Standard deployment is equivalent to inference_geo: "us".