Multi-region architectures serve two goals that are easy to conflate: availability (if one region degrades, traffic keeps flowing) and capacity (more total throughput than one region allows). Every Claude platform can help with the first goal. Only some multi-region setups help with the second — because the platforms account for quota differently. This article walks through the accounting model on each platform, since it determines whether adding a region adds headroom.
Bedrock: routing spreads, the bucket stays one
On Amazon Bedrock, multi-region routing works through inference profiles: a profile defines a model plus the set of AWS regions requests can be routed to. Geographic profiles (US, EU, APAC and others) keep data within a geography; global profiles can route to any supported commercial region. Routing happens on the AWS network, and CloudTrail records which region actually processed each request.
The quota accounting, however, does not multiply with the destination regions. On the bedrock-runtime endpoint, cross-region traffic is governed by per-model quotas with names like "Cross-Region InvokeModel tokens per minute for model" — one allocation that your cross-region traffic draws against, however many regions the profile can route to. In other words, an inference profile is a wider pipe into the same bucket: it improves availability and lets AWS place your requests where capacity exists, but it is not a way to stack multiple regional quotas. If you need a larger allocation, that is a quota-increase request, not an architecture change (adjustable bedrock-runtime quotas go through the Service Quotas console; the newer bedrock-mantle endpoint takes increases via an AWS Support case instead — and its quotas are tracked separately from bedrock-runtime even for the same model).
Vertex AI: independent buckets you can genuinely add together
Google Cloud takes the opposite approach. Claude on Vertex AI offers three endpoint types — global (dynamic routing for maximum availability), multi-region (us and eu, dynamic routing within a geography), and regional. Google documents that the global-endpoint quota and each multi-region-endpoint quota are independent buckets: usage on one does not consume the other.
That makes Vertex the platform where a multi-endpoint design can genuinely increase total available capacity, not just resilience. An application that sends primary traffic to the global endpoint and fails over to (or actively splits load with) the us multi-region endpoint is drawing on two separate allocations. Two caveats keep this honest: multi-region and regional endpoints carry a 10% pricing premium over global for Claude Sonnet 4.5 and later models, and if you adopted multi-region for data-residency reasons, failing over to the global endpoint would defeat that purpose — capacity and residency have to be designed together. See multi-region failover strategies for Vertex for the patterns.
Foundry: pooled per subscription, per deployment type
Microsoft Foundry sits closer to the Bedrock model. Quota is managed at the Azure subscription level and shared: all Global Standard deployments of the same model and version in a subscription draw from one pool across regions, while Data Zone Standard deployments share a pool within each data zone. Creating a second Global Standard deployment of the same model in another region gives you a second endpoint, not a second quota — useful for latency and blast-radius isolation, but the RPM/ITPM ceiling is unchanged.
The platform-level escape hatch
There is one more isolation boundary worth knowing: entire platforms are independent capacity pools. Anthropic documents that Claude Platform on AWS uses a separate capacity pool from both the first-party Claude API and Amazon Bedrock, and explicitly notes that workloads can run on multiple platforms and fail over between them. When single-platform quota is the binding constraint, multi-platform failover adds capacity the way multi-region on a pooled platform cannot (see also Claude Platform on AWS's isolated pool).
| Setup | Quota accounting | Adds capacity? |
|---|---|---|
| Bedrock inference profile (geographic or global) | One pooled cross-region allocation | No — availability only |
| Vertex global + multi-region endpoints | Independent buckets per endpoint type | Yes — allocations are additive |
| Foundry Global Standard, multiple regions | One pool per subscription per model+version | No — availability only |
| Different platforms (e.g. Bedrock + Claude Platform on AWS) | Separate pools per platform | Yes |
Where to go next
Cross-region inference profiles on Bedrock covers the routing mechanics in depth, and the quota-monitoring guide shows how to watch each bucket you end up with.