Amazon Bedrock is a Regional service: every model you call runs in a specific AWS Region, and which models exist where is uneven and changes constantly. This is the full reference — how Bedrock Regions work, a representative 2026 map of which model families land in which geographies, how to choose a Region for latency, data residency, and sovereignty, how cross-region inference profiles smooth out availability, the EU / US / APAC trade-offs, and the AWS GovCloud picture.
Amazon Bedrock is a Regional AWS service, not a single global endpoint. When you call Bedrock, you call a specific Region (for example us-east-1 or eu-central-1), and your request — prompt in, completion out — is processed inside that Region. The model you can call, the latency you experience, and the legal location of your data all follow from that one choice.
This is the first thing to internalize: there is no “global” Bedrock. Each Region runs its own Bedrock control plane, its own inference fleet, and its own set of enabled models. You request model access per Region, your IAM policies and CloudTrail logs are Regional, and a request to one Region never silently spills into another. That isolation is exactly what makes data residency possible — but it is also why the model catalog you see is uneven from one Region to the next.
Why is availability uneven? Three structural reasons. First, capacity: serving a frontier model needs scarce accelerator capacity, and AWS brings that online Region by Region rather than everywhere at once. Second, provider terms and licensing: each model provider (Anthropic, Meta, Mistral, Cohere, and the rest) agrees where their model may be served, so a model can be legally available in some geographies before others. Third, demand and operational readiness: AWS launches new models where adoption is highest first — almost always the large US Regions — then expands outward to EU and APAC as capacity and demand justify it.
The practical consequence is a recurring pattern: a new Claude, Llama, Nova, or Mistral model appears in us-east-1 (N. Virginia) and us-west-2 (Oregon) first, reaches the major EU Regions (Frankfurt, Ireland, Paris) and APAC Regions (Tokyo, Sydney, Singapore, Mumbai) over the following weeks to months, and arrives in smaller or specialized Regions later — if at all. So the question is never just “is this model on Bedrock?” It is “is this model on Bedrock in the Region I am allowed to use?”
Two mechanisms exist precisely because of this unevenness, and the rest of this page returns to both. Cross-region inference profiles let a single request be served from one of several Regions within a defined geography, so you get the capacity and availability of a whole geography while staying inside it. And Region selection itself becomes a deliberate trade-off between residency, availability, and latency rather than a default you never revisit.
Amazon Bedrock is Regional: every request is processed in the Region you call, your data stays in that Region, and the model catalog differs Region to Region — so choosing a Region is choosing your data-residency boundary, your latency, and the set of models you can actually reach, all at once.
Teams often pick a Region by habit (“we already use us-east-1”) and discover the constraints later. The disciplined approach evaluates three axes in priority order: data residency / sovereignty, model availability, and latency. The order matters because the first axis is usually a hard legal constraint, the second is a hard technical one, and the third is an optimization.
Run the axes in order and the right Region usually falls out quickly. Start with where the data is allowed to be, narrow to the Regions in that boundary that actually host the model you need, then among the survivors pick the one closest to your users. Skipping the order is how teams end up rebuilding: choosing the lowest-latency Region first, only to find it cannot legally hold the data, or does not have the model.
Because Bedrock processes each request in-Region, the Region you choose is your data-residency answer. If your contract, regulator, or customer requires that personal or regulated data never leave the EU, you call an EU Region and the prompts and completions stay there. Sovereignty goes a step further than residency: it concerns not just where the data sits but who can operate the infrastructure and under whose jurisdiction — the concern behind GDPR, schemes like Germany’s C5, and the EU’s push for digital sovereignty. AWS addresses residency with its standard Regions and addresses sovereignty with dedicated offerings (the AWS European Sovereign Cloud and Dedicated Local Zones), covered in section V. Resolve this axis first: it can eliminate most Regions before you consider anything else.
Within the Regions your residency rules allow, the next question is whether the specific model you need is actually there. If your application depends on a particular frontier model and that model is currently live only in US Regions, an EU-residency requirement and that model are in direct tension — and you must resolve it deliberately (wait for the model to reach the EU, choose a different model that is in the EU, or use a cross-region inference profile scoped to EU Regions). Never assume parity: check the per-Region model-support list in the Bedrock console and the AWS docs for the exact models and versions you intend to call, in the exact Regions you are allowed to use.
Once residency and availability have narrowed the field, pick the Region closest to your users (or to the AWS services your application already runs in) to minimize round-trip latency. The dominant cost in a generation request is usually the model’s own inference time, but network round-trips still matter for chat-style interactivity and for retrieval-augmented flows that make several calls per turn. Co-locating Bedrock with your application tier, your vector store, and your users keeps the experience snappy. Latency is the axis you optimize after the two hard constraints are satisfied — never before.
Residency first (where is the data legally allowed to live?), availability second (is the model actually in those Regions?), latency third (which surviving Region is closest to users?). Decide in that order and you avoid the most expensive Bedrock mistake: building in a Region you later discover cannot hold your data or does not have your model.
The table below is a representative map of how Bedrock model availability tends to distribute across geographies as of 2026. It is deliberately shown at the level of provider families and geographies rather than exact model IDs per Region, because the precise per-Region list changes continuously — this map shows the <em>shape</em> of availability, not a guarantee. Always confirm the live, exact list under Model access in the Bedrock console and in the AWS model-support documentation.
Read the map as a tendency, not a contract. The reliable pattern is that us-east-1 (N. Virginia) and us-west-2 (Oregon) carry the broadest and earliest catalog — new models and capabilities almost always appear there first. The major EU Regions — eu-central-1 (Frankfurt), eu-west-1 (Ireland), and eu-west-3 (Paris) — and the major APAC Regions — ap-northeast-1 (Tokyo), ap-southeast-2 (Sydney), ap-southeast-1 (Singapore), and ap-south-1 (Mumbai) — typically follow with strong but slightly trailing coverage. Other Regions (additional EU, APAC, Canada, South America, Middle East) vary the most and should always be checked directly.
The second pattern worth noting: Amazon’s own families (Nova and Titan) tend to roll out broadly and relatively quickly across Regions, since AWS controls them end to end. Third-party frontier models — particularly the newest tier — are the ones most likely to be US-first with a lag elsewhere. Embeddings models (Titan, Cohere) are usually among the most widely available, which matters because retrieval-augmented generation depends on them. If you are RAG-heavy, confirm that both your chat model and your embeddings model are present in the same Region.
| Geography (example Regions) | Catalog breadth | New-model timing | Typical strengths | Notes |
|---|---|---|---|---|
| US — us-east-1 (N. Virginia), us-west-2 (Oregon) | Broadest | First (day-one) | Every provider; newest frontier tier; cross-region US profile | Default for earliest access; not a data-residency fit for EU/other regulated data |
| EU — eu-central-1 (Frankfurt), eu-west-1 (Ireland), eu-west-3 (Paris) | Strong | Following weeks–months | Claude, Llama, Mistral, Nova/Titan, Cohere; EU cross-region profile | GDPR residency; EU Sovereign Cloud for stricter sovereignty (section V) |
| APAC — ap-northeast-1 (Tokyo), ap-southeast-2 (Sydney), ap-southeast-1 (Singapore), ap-south-1 (Mumbai) | Strong, varies by Region | Following weeks–months | Major providers; APAC cross-region profile | Country residency laws vary — pick the in-country Region where required |
| Other — Canada, South America, Middle East, additional EU/APAC | Varies most | Later / selective | Amazon Nova & Titan most likely; embeddings often present | Always verify the exact model + version per Region before committing |
| AWS GovCloud (US) — us-gov-west-1, us-gov-east-1 | Curated subset | Trails commercial | Models cleared for the GovCloud partition | Isolated partition for US public sector / ITAR / FedRAMP High (section VI) |
Cross-region inference is the feature that makes uneven, capacity-constrained model availability workable in production. Instead of pinning every request to one Region, you call an inference profile that can serve the request from one of several Regions within a defined geography — adding throughput headroom and resilience while keeping the request inside that geography’s boundary.
Mechanically, a cross-region inference profile is an inference target you call in place of a single-Region model ID. Behind it sits a set of Regions within one geography — for example a US profile spanning US Regions, or an EU profile spanning EU Regions. When you send a request to the profile, Bedrock routes it to a Region in that set that has capacity, transparently, with no routing logic of your own. The point is twofold: higher effective throughput (you draw on the combined capacity of several Regions, which raises your practical rate limits and absorbs bursts) and better availability (if one Region is constrained, another in the geography can serve the call).
The residency guarantee is the part that matters most for regulated teams: a cross-region inference profile only routes within its defined geography. An EU profile keeps requests in EU Regions; a US profile keeps them in US Regions. So you get geography-wide capacity without crossing the residency boundary you committed to. This is the standard answer when an EU-residency requirement collides with a model that is throughput-constrained in any single EU Region: use the EU profile and let Bedrock spread the load across EU Regions, never leaving the EU.
When should you reach for it? Use a single-Region call when your volume is modest and the model is comfortably available where you are. Reach for a cross-region profile when you hit throughput or availability limits, when you want resilience against single-Region capacity pressure, or when a model’s capacity within your geography is easier to obtain in aggregate than in one Region. For deeper mechanics — exactly how profiles are configured, how they interact with provisioned throughput, and the billing nuances — see the companion page Amazon Bedrock cross-region inference.
A cross-region inference profile routes a request across several Regions within one geography (US, EU, APAC), giving you that geography’s combined capacity and availability without ever leaving it. It is the standard fix when a residency requirement and a throughput-constrained model are in tension — and the first thing to try before assuming a model “isn’t available enough” in your geography.
The three major geographies each carry a distinct mix of availability, residency, and sovereignty considerations. Here is how the decision tends to play out in each, plus where AWS’s sovereignty offerings change the EU picture.
No geography is strictly “best” — the right one is dictated by your data rules and your users. What follows is the practical shape of each.
us-east-1 (N. Virginia) and us-west-2 (Oregon) are where the Bedrock catalog is widest and where new models appear first. If your users are in the Americas and your data has no non-US residency requirement, a US Region is usually the path of least resistance and the best place to access the newest frontier models on day one. The US cross-region inference profile spreads load across US Regions for throughput and resilience. The caveat is the obvious one: US Regions are not a residency fit for EU or other regulated data that must stay in-geography.
eu-central-1 (Frankfurt), eu-west-1 (Ireland), and eu-west-3 (Paris) give you GDPR-aligned data residency simply by calling them — prompts and completions stay in the EU. Coverage of the major providers is strong, typically trailing US availability by weeks to months for the newest models; the EU cross-region inference profile pools EU-Region capacity while preserving the EU boundary. For organizations whose requirements go beyond residency into sovereignty — EU-based operations and personnel, jurisdictional independence — AWS offers the AWS European Sovereign Cloud, a separate, EU-operated cloud designed for the most stringent sovereignty and regulatory needs, and Dedicated Local Zones for in-country or on-premises-adjacent control. If your driver is GDPR residency, a standard EU Region is usually sufficient; if your driver is full digital sovereignty, evaluate the European Sovereign Cloud. Confirm current Bedrock model coverage for whichever EU option you choose.
APAC is where residency rules are most fragmented across countries, so Region choice is often dictated by a specific national law. ap-northeast-1 (Tokyo), ap-southeast-2 (Sydney), ap-southeast-1 (Singapore), and ap-south-1 (Mumbai) — among others including Seoul, Jakarta, and Hyderabad — carry strong but Region-varying Bedrock coverage. The rule of thumb: if a country’s law requires data to stay in-country, pick that country’s Region specifically rather than a regional hub. Where you have geography-wide latitude, an APAC cross-region inference profile pools APAC-Region capacity. As with the EU, the newest frontier models can trail US availability, so verify the exact model is present in the specific APAC Region your residency rules require.
AWS GovCloud (US) is a separate AWS partition built for US government agencies, the public sector, and contractors handling sensitive, regulated, or export-controlled workloads. It is operated by vetted US persons and designed to support compliance regimes such as FedRAMP High, DoD frameworks, ITAR, and CJIS. Bedrock’s presence in GovCloud follows different rules from the commercial Regions, so it warrants its own note.
The first thing to understand is that GovCloud is a distinct partition, not just another Region. It has its own us-gov-west-1 and us-gov-east-1 Regions, its own account namespace, its own console endpoints, and isolation from the commercial AWS partition. That isolation is the entire point: it is what lets agencies run workloads with strict export-control and authorization requirements. It also means GovCloud has its own, curated subset of services and models — capabilities reach GovCloud after they have been cleared for that environment, so the Bedrock model catalog in GovCloud trails the commercial Regions and is deliberately narrower.
For a team with a US public-sector or ITAR/FedRAMP-High requirement, the implication is concrete: plan around the models that are cleared and available in GovCloud rather than assuming commercial parity, and confirm the current GovCloud Bedrock model list directly, since it expands on its own schedule. The cross-region considerations above apply within the GovCloud partition’s own Regions, not across the commercial/GovCloud boundary — the two partitions do not mix, by design. If your workload does not carry these specific federal requirements, you do not need GovCloud; a standard US Region with the appropriate compliance attestations (SOC, ISO, FedRAMP Moderate, and so on, available via AWS Artifact) is the right home.
The decision rule is simple: GovCloud when an explicit federal authorization, ITAR/export-control, or FedRAMP-High mandate requires the isolated partition; a commercial Region otherwise. Where Bedrock model availability in GovCloud does not yet cover what you need, the timeline question (“when does this model reach GovCloud?”) is best answered with your AWS account team and the AWS GovCloud documentation.
AWS GovCloud (US) is an isolated AWS partition (us-gov-west-1 / us-gov-east-1) for US public-sector, ITAR, and FedRAMP-High workloads, operated by vetted US persons — with a curated, trailing subset of Bedrock models. Use it only when a federal/export-control mandate requires it; confirm the current GovCloud model list directly, since commercial parity is not guaranteed.
The Region decision is durable: it sets your residency posture, your achievable model set, and your latency floor, and it is awkward to change once data and dependencies accrete. Run this checklist before you build, then read the cost note — because the bill, not the Region, is usually the next surprise.
The cost reality is the same as for Bedrock generally, and Region choice does not change it much: GenAI is cheap per call and expensive in aggregate, and the levers that control it — routing cheap calls to small models, running offline work as batch (~50% off), turning on prompt caching for repeated context, and reserving provisioned throughput only at steady high volume — are Region-independent. What Region does affect is whether you can run the workload at all under your residency rules and which models you can reach to apply those levers. Get the Region right first; then optimize the bill, or fund it outright.
Funding the bill with AWS’s own money is the lever most teams miss. AWS runs credit programs aimed precisely at teams building generative AI on Bedrock — Activate Portfolio (up to $100K) for institutionally-funded startups, dedicated Bedrock / GenAI proof-of-concept funding ($10K–$50K) for a defined build, and the competitive Generative AI Accelerator (up to $1M) — and they are largely partner-filed and invisible on the public Activate page. CloudRoute routes you to a vetted AWS partner who files the credit application and, if you need hands, architects the Bedrock workload in the correct Region for your residency rules. Because AWS funds both the credits and the partner engagement, you pay $0. See AWS credits for generative-AI startups, AWS PoC / Bedrock POC funding, and $100K AWS credits.
The most common Bedrock Region question is not “which exact Region” but “which geography fits my constraints.” This is a scannable map of the major geographies across the three axes that decide the choice, plus the cross-region and sovereignty options each carries. Confirm exact per-Region model availability in the Bedrock console before committing.
| Geography | Model availability | Residency / sovereignty fit | Cross-region profile | Reach for it when |
|---|---|---|---|---|
| US (us-east-1, us-west-2) | Broadest, earliest (frontier day-one) | No EU/in-country residency; US public sector → GovCloud | US profile (pools US Regions) | Americas users, no non-US residency rule, want newest models first |
| EU (Frankfurt, Ireland, Paris) | Strong; newest models trail US by weeks–months | GDPR residency by default; full sovereignty via EU Sovereign Cloud | EU profile (stays in EU) | EU data must stay in-geo; GDPR or sovereignty driver |
| APAC (Tokyo, Sydney, Singapore, Mumbai…) | Strong but Region-varying; frontier can trail | Country-specific — pick the in-country Region when required | APAC profile (stays in APAC) | APAC users / country residency laws; verify the exact Region |
| AWS GovCloud (US) | Curated subset; trails commercial | US public sector, ITAR, FedRAMP High; isolated partition | Within GovCloud Regions only | Federal/export-control mandate requires the isolated partition |
| Other (Canada, SA, ME, more) | Varies most; Amazon Nova/Titan most likely | Local residency where the Region is in-country | Varies — check availability | A specific local residency or latency need points to that Region |
Situation: The team needed a grounded assistant over sensitive patient data, but their compliance reviewer required that all data stay in Germany under GDPR and C5-aligned controls, with documented sovereignty — no processing outside the EU, ever. They had defaulted an early prototype to us-east-1 because that is where the model they wanted appeared first, then discovered it could not legally hold the data. They needed the Region question answered correctly and the workload rebuilt around it, without a frontier-model gap derailing the roadmap.
What CloudRoute did: Routed within 20 hours to an EU AWS partner with a healthcare data-residency track record. The partner re-architected the workload onto Amazon Bedrock in eu-central-1 (Frankfurt) so every request — prompt, retrieval, completion — stayed in the EU, used the EU cross-region inference profile to add throughput headroom while keeping requests inside EU Regions, selected an EU-available workhorse model for answers with a small EU-available model for classification, and added a Guardrail for PII handling. Where one needed capability was newer in the US, the partner mapped the EU availability timeline and chose an EU-present model in the interim. In parallel they filed a Bedrock/GenAI proof-of-concept credit application and an Activate Portfolio application.
Outcome: GenAI POC credits ($25K) approved in under 2 weeks, Portfolio ($100K) shortly after — the first several months of EU-resident Bedrock inference were fully credit-funded. The assistant reached production in 6 weeks with all data resident in Germany and a documented EU-only processing path that satisfied the compliance reviewer. CloudRoute’s commission was paid by the partner from AWS engagement funding; the customer paid $0.
time-to-match: < 24h · Region: eu-central-1 (EU-only) · credits secured: $125K · cost to customer: $0
CloudRoute routes you to a vetted AWS partner who architects your Bedrock workload in a residency-correct Region and files your GenAI credit application (Activate Portfolio up to $100K, GenAI POC $10K–$50K, GenAI Accelerator up to $1M). AWS funds the credits and the engagement. You pay $0.