A region is a geographic location where your cloud provider runs infrastructure. When you call Claude through a third-party platform such as Amazon Bedrock, Google Vertex AI, or Microsoft Foundry, your request is handled by infrastructure associated with the region you selected. That single dropdown or parameter is worth understanding before launch, because it is much easier to choose well up front than to move a production workload later.
Three different questions hiding in one setting
Teams often treat region as a single decision, but it actually answers three separate questions. First, latency: requests to a region physically closer to your users or your application servers generally complete faster. For interactive apps, this is the part users notice. Second, availability: capacity and model access can differ by region, so the region you pick affects which models you can use and how much headroom you have. Third, residency: many organizations have policies or contractual commitments about where data is processed. Region choice is the main lever you have for aligning Claude usage with those commitments.
These three pull in different directions surprisingly often. The region that satisfies your residency policy may not be the one with the lowest latency or the most available capacity. Naming the trade-off explicitly, in writing, is usually enough to get the right stakeholders (engineering, security, legal) to a decision quickly.
How each platform expresses region
The mechanics differ by platform, though the concept is the same. On Amazon Bedrock, you pass an AWS region when you create the client. On Claude Platform on AWS (the Anthropic-operated option that runs on AWS), the region comes from the AWS_REGION environment variable alongside your workspace ID. On Microsoft Foundry, region is tied to the Foundry resource you create, so it is decided at provisioning time rather than in code. On Google Vertex AI, you pass a region to the client, and Vertex also offers a global endpoint: instead of pinning your traffic to one location, you set the region to global and let Google route the request.
from anthropic import AnthropicVertex
client = AnthropicVertex(project_id="my-project", region="global")
response = client.messages.create(
model="claude-sonnet-5",
max_tokens=256,
messages=[{"role": "user", "content": "Summarize this policy update."}],
)
print(response.content)When the global endpoint helps, and when it doesn't
The global endpoint is attractive for availability: you are not betting your uptime on a single location having capacity at the moment you need it. For workloads without strict data-location requirements, it is a sensible default because it removes a whole class of capacity planning questions.
The trade-off is control. If your organization needs to state precisely where requests are processed, a global routing option is harder to describe in a compliance document than a fixed region. Verify with your cloud provider exactly what location guarantees, if any, apply to global routing before relying on it for regulated data.
Practical questions to answer before launch
You do not need a long study, just clear answers to a short list. Which models do you need, and are they offered in your candidate region? Does your data-handling policy restrict processing to specific geographies, and does that apply to prompts sent to an LLM? What happens to your app if your chosen region has an incident: do you fail over to another region, queue work, or degrade gracefully? And who owns the decision record, so that when someone asks in a year "why us-east-1?", there is an answer written down.
Note that region choice interacts with quotas and pricing conversations too. Quota increases are typically granted per region, and committed-use discussions with your cloud provider will reference where your usage runs. Keeping your Claude footprint concentrated in one or two well-chosen regions makes both conversations simpler.
Where to go next
For the legal side of this topic, read Data Residency Questions Your Legal Team Will Ask. If your concern is keeping traffic off the public internet entirely, see Private Networking, and for the broader platform comparison, start at the platforms overview.