AWS regional pricing has no uniform multiplier: model price gaps within the same region can reach 1.6x

The "regional multiplier" you've been using to estimate cloud costs may not exist at all

If you've ever estimated the cost of deploying a model in Frankfurt or Tokyo, you've probably done the same thing I have: take the us-east-1 price, multiply by a regional factor, done. Nearly every cloud cost model I've seen treats regions as a multiplier on the base rate.

But someone did something more rigorous: they read through all 1,586 on-demand, in-region token billing items in Amazon Bedrock, one by one, and compared each against its us-east-1 price. The result: 1,424 of them were comparable, spanning 32 regions and producing 123 distinct multipliers.

If a region really were a single multiplier, there should be at most 32. The extra 91 show that the "regional multiplier" mental model itself is broken.

Amazon Bedrock is AWS's fully managed generative AI service, letting developers call foundation models from multiple vendors—Anthropic Claude, Meta Llama, Mistral, Amazon Nova, and others—through a unified API. Its pricing uses on-demand token billing: input tokens and output tokens are priced separately, and unit prices can differ by hundreds of times across models. So-called "in-region" deployment means inference requests are completed entirely within the data centers of the user-specified region; the opposite is "cross-region inference," where requests may be routed to other regions for processing, and the two use separate price lists. The 1,586 "billing items" repeatedly mentioned in this article refer to each individual price record for every combination of model, direction (input/output), and region. Understanding this granularity is the prerequisite for understanding the article's conclusion: the reason there are so many multipliers is precisely because the billing items themselves are split this finely.

The multiplier distribution: a third are priced identically, the top reaches 1.7

First, the overall distribution:

• 30.3% of billing items are exactly the same as us-east-1
• First quartile (Q1): ×1.000
• Median: ×1.183
• Third quartile (Q3): ×1.200
• Minimum: ×0.964
• Maximum: ×1.700

Nearly a third of billing items cost exactly the same in overseas regions as in Virginia. At the top of the range is São Paulo, where Mistral 7B output pricing rises from $0.20 to $0.34.

Interestingly, four billing items are actually cheaper outside us-east-1—two Nova Sonic models in us-west-2, with input and output multipliers of ×0.967 and ×0.964, respectively. The magnitude is small, but it's enough to show that even the 1.0 floor doesn't exist for this "uplift."

Quartiles are statistics that describe the position of values in a distribution. After sorting all multipliers from smallest to largest: Q1 (first quartile) means 25% of the multipliers are below that value, Q3 means 75% are below it, and the median is the 50th percentile. Here Q1 = 1.000, median = 1.183, and Q3 = 1.200 mean: at least a quarter of billing items are exactly the same price as us-east-1, half rise by no more than 18.3%, and three-quarters rise by no more than 20%. But the maximum of ×1.700 shows the distribution has a clear long tail. Budgeting with the median amounts to assuming your usage happens to fall in the middle of the distribution—but the actual bill is a weighted sum of billing items, and a high-multiplier item in the tail will dominate total costs if usage is heavy.

London: one region, 25 distinct multipliers

London is the most telling case. Here are the multipliers for eu-west-2 input prices relative to the same models in Virginia:

Multiplier	Model	Price change
×1.000	Kimi K3	$3.300 → $3.300
×1.000	Grok 4.7	$2.200 → $2.200
×1.300	Llama 3 8B	$0.300 → $0.390
×1.333	Mistral 7B	$0.150 → $0.200
×1.412	Nova Pro	$0.800 → $1.130
×1.500	Gemma 3 4B	$0.040 → $0.060
×1.533	Qwen3 32B	$0.150 → $0.230
×1.550	Devstral	$0.400 → $0.620
×1.600	Ministral 3B 3.0	$0.100 → $0.160

This is just 9 of London's 47 comparable input billing items; counting both input and output directions, it has 94 billing items and 25 distinct multipliers.

Two models cost the same as in Virginia, while most of the rest are about 50% more expensive. The statement "London is 55% more expensive" is simultaneously true and false within the same table—which answer you get depends on which model you happen to pick.

Looking across all 32 regions, only 9 regions charge a single consistent multiplier—and 7 of those 9 have only 4 billing items each. That's a sample, not a policy. Only two have real coverage: us-east-2 (129 billing items, all ×1.000) and me-central-1 (13 billing items, all ×1.000).

In other words: 23 of the 32 regions price different models differently relative to Virginia.

The Azure comparison: the first axis isn't the region

Azure is a useful comparison because its organization is completely different from AWS's.

A Global Standard deployment has only one price. Not one price per region—just one price, applicable to all regions Azure lists. You pay extra only if you pin the same model to a specific region or data zone:

• Regional deployment: median ×1.100, range 1.100–1.320, 10 distinct multipliers
• Data zone deployment: median ×1.100, range 1.100–1.200, 6 distinct multipliers

So on Azure, the question is "am I pinning this to a geographic area," and the answer is usually a uniform 10% uplift. On AWS, the question is "which model, in which region," and there are 123 answers.

Azure isn't perfectly uniform either—18 of the 21 regionally priced models vary across regions. But with a similar number of billing items, 10 distinct multipliers versus AWS's 123 is a difference in kind, not degree.

Azure's deployment types are key to understanding how it differs from AWS. Global Standard is the default deployment method, with model weights hosted on Microsoft's global infrastructure, and requests may be processed by any region, so there is only one uniform price and region choice doesn't affect the bill. Regional deployment pins the model to a specific region, keeps data from leaving the country, and costs extra. Data Zone deployment sits in between, pinning the model within a geographic area (such as Europe or the US), with a surcharge lower than regional deployment. Azure's pricing logic is therefore "choose the deployment type first, then look at the region," whereas AWS Bedrock's in-region pricing has no such deployment-type dimension (standard, Batch, Flex, and Priority are a separate, orthogonal set of service tiers). The two have their cost axes in a different order, and applying the same regional multiplier model to both will fail.

What you should actually do

Don't estimate regional prices from a reference price. This is the most practical conclusion and the core of the whole article. No single coefficient holds for more than a small fraction of the model catalog. Read the number directly for the model you actually call, in the region you actually call it in.

Check your two most-used models, not the average. A median of ×1.183 is nearly useless for budgeting: your bill is the weighted sum of the billing items you actually hit, and those range from ×0.964 to ×1.700.

On Azure, price the deployment type first. If you're using Global Standard, the region isn't a cost axis for you at all, and moving between regions has zero impact on your bill. It's worth figuring that out before spending a sprint on it.

Measurement methodology and the first pitfall I hit

The data scope was limited to Bedrock's on-demand standard tier and in-region deployments only. Batch, Flex, and Priority are separate tables, and so is cross-region inference.

This exclusion is the entire methodology, and it's emphasized here because I ignored it the first time. Grouping without locking down the deployment type produces a beautiful headline—"Nova 2.0 Lite is 6.16x more expensive in some regions"—that's actually comparing Flex in one region against Priority in another. No data was fabricated; the rows are real, they just answer a question nobody asked. A price list with four tiers will hand you a dramatic number if you let it.

A billing item is only counted when a model and direction exist in both regions, so a model missing from a region contributes zero rather than an infinite ratio. Prices are always read from the vendor's published tables and never derived from reference numbers—which is exactly what this article argues you shouldn't do either.

Data as of 2026-10-11. For per-region tables (including a region switcher and notes on methodology on the page), see aichangewatch.com/aws/pricing.

A common assumption in cloud cost modeling was overturned by this comprehensive check: regions are not the multiplier—models are the variable. For any team that needs to make budgeting decisions across regions, deleting the "regional multiplier" from your estimation formula and replacing it with a check of specific billing items is a more reliable first step.

AWS Bedrock's service tiers are an easy source of confusion: Standard is the default on-demand inference; Batch is for large-volume asynchronous tasks and is usually cheaper; Flex and Priority correspond to requests that can tolerate longer latency and requests that need higher priority, respectively, and are priced differently. These four tiers each maintain separate price lists, and the same model may differ by several times in unit price across tiers. Therefore, mixing billing items from different tiers into the same multiplier calculation artificially amplifies or shrinks regional differences, producing numbers that look alarming but are meaningless. The emphasis on "locking down the deployment type" is precisely to ensure every comparison happens between like-for-like services, so that the multiplier genuinely reflects regional differences rather than tier differences.