The AWS Bedrock pricing page has a region selector. Change it and the numbers change. Nothing warns you about this, no page puts two regions side by side, and the difference is not the rounding error you would assume: across the catalogue, 43 of the 54 models priced in more than one region cost different amounts depending on where you call them — with a median premium of +55% between the cheapest and dearest region.
The widest gap in today's snapshot is
Titan Embeddings G1 - Text:
$0.100 per 1M input tokens in
us-east-1 against $0.200 in
eu-central-1. Same model, same tokens,
+100%.
First, a correction most comparisons get wrong
It is easy to produce a much more dramatic version of this article by accident. When a model is reachable in a region only through a cross-region inference profile, the price attached to it is the profile's — and regional profiles carry roughly a 10% premium over the base rate. Compare a profile price in one region against a bare on-demand price in another and you have measured that premium, not geography.
Every figure here is computed over on-demand SKUs only, in both regions being compared. What is left is genuinely regional.
The models with the widest spread
| Model | Cheapest | Dearest | Premium |
|---|---|---|---|
| Titan Embeddings G1 - Text | $0.100 us-east-1 | $0.200 eu-central-1 | +100% |
| Mixtral 8x7B Instruct | $0.450 us-east-1 | $0.760 sa-east-1 | +69% |
| Mistral Large (24.02) | $4.00 us-east-1 | $6.70 sa-east-1 | +68% |
| Mistral 7B Instruct | $0.150 us-east-1 | $0.250 sa-east-1 | +67% |
| Ministral 3B | $0.100 us-east-1 | $0.160 eu-west-2 | +60% |
| Nova Lite | $0.060 us-east-1 | $0.096 eu-south-1 | +60% |
| Nova Micro | $0.035 us-east-1 | $0.056 eu-south-1 | +60% |
| Nova Pro | $0.800 us-east-1 | $1.28 eu-south-1 | +60% |
It is the region, not the model
Averaging each region's price against the cheapest price for the same model — so a $5 model cannot outvote a $0.10 one — the pattern is consistent enough to plan around:
| Region | Average premium | Models compared |
|---|---|---|
| EU (London) eu-west-2 | +51% | 39 |
| Asia Pacific (Singapore) ap-southeast-1 | +35% | 3 |
| EU (Paris) eu-west-3 | +34% | 7 |
| EU (Frankfurt) eu-central-1 | +31% | 14 |
| EU (Milan) eu-south-1 | +26% | 27 |
| Israel (Tel Aviv) il-central-1 | +25% | 3 |
At the other end, us-east-1 us-east-2 us-west-2 sit at the floor: they
are the cheapest region for essentially every model priced in them. US pricing is the
reference rate, and everywhere else is a markup on it.
When this is worth acting on, and when it is not
A 30% token premium sounds like something to fix immediately. Usually it is not the biggest number on the page, and it is worth being honest about the order of magnitude:
- Prompt caching beats geography. Cached input reads at roughly a tenth of the input rate. On an agentic workload that resends a long system prompt every step, turning caching on is a larger saving than any region move — and the two compose.
- Batch beats geography too, at half rate, when the work tolerates it.
- Latency and residency usually outrank both. Moving inference to
us-east-1to save 30% on tokens is a poor trade if it breaks a residency commitment or adds 120ms to every hop in a chatty agent loop.
Where it does matter is the case nobody models: a workload that has no residency or latency constraint — offline enrichment, batch classification, nightly summarisation — and that ended up in a European region because that is where the rest of the account lives. That workload is paying a premium for nothing, and it is often the highest-volume thing running.
How to check your own case
Per-region prices for a single model are on its model page, and the full catalogue for one region is on the region pages. To turn a premium into a monthly figure rather than a percentage, the cost calculator takes your token volumes, cache hit rate and batch share and prices two options against each other.
One caveat worth carrying: these are on-demand, standard-tier, published list prices excluding tax. Committed throughput and negotiated rates change the arithmetic, and they are the reason a large account's real numbers may not match this table.