Regions, residency, and sovereignty

Every cost comparison in this book so far has quietly assumed you can run the workload where it is cheapest. Compliance geography removes that assumption, and the first thing it removes is not a discount — it is a menu.

Resolving AWS's own pricing map across all 106 regions gives the numbers directly.

The constraint is availability, not price

Seventy-nine of AWS's 106 regions have none of these accelerators. Before any conversation about a regional price premium, the question is whether the silicon exists there, and three times out of four it does not.

This inverts how region decisions usually get made. Teams pick a region for latency or residency, then discover the instance type is unavailable and quietly fall back — often to a US region, which is precisely the outcome the residency requirement was meant to prevent.

The European picture, which is worse than the headline

Here is every AWS region carrying an "EU" label, against GPU availability (on-demand Linux, $/hour):

Three things fall out, and none of them appear on a pricing page.

Frankfurt and Ireland — the two default European landing zones — have no p5. If your architecture assumed H100s in Frankfurt because that is where your data lives, that assumption is wrong today.

EU (Milan) carries none of these GPUs at all. An entire region, empty for this workload.

And the label is not a jurisdiction. AWS's EU (…) prefix is a legacy naming convention, not a legal claim. EU (London) is in post-Brexit United Kingdom. EU (Zurich) is in Switzerland. Neither is in the European Union. If your obligation is genuinely EU-bound — GDPR data-boundary commitments, a public-sector procurement rule, a contractual EU-only clause — then of the eight regions above, EU (Stockholm) is the only one that is both inside the EU and has an H100.

That is a supply of one. It is the single most important fact in this chapter, and it is invisible unless you cross a price table against a map.

What the geography actually costs

Every p5 region prices as a clean multiplier of the US base of $55.04/hour:

Two readings worth having.

EU residency on H100s is cheap — if you take Stockholm. A 7% premium over Oregon is far less than most teams assume compliance geography costs. London is 1.30×, which is 21.5% more than Stockholm for the same hardware — so the expensive European choice is also the one that isn't in the EU.

You do not need a border to pay a premium. US West (N. California) is 1.25× US West (Oregon) — same country, same coast, 25% more, for identical silicon. Any "we're US-only so region doesn't matter" reasoning is already wrong by a quarter.

One caution against over-reading the multipliers: they are per-SKU, not per-region. São Paulo is 1.68× on p5 but 1.54× on a c5.24xlarge and 1.70× on a g5 — so you cannot learn a region's premium once and apply it to your whole fleet. Price the instance you actually run.

Residency compounds with commitment

Reservations and commitment maths established that Google's resource-based CUDs bind to "a specific region and with a specific machine configuration," and that no cloud lets you cancel. Put that beside a supply of one EU region with H100s and the exposure is structural rather than financial:

A three-year region-locked commitment in the only compliant region that has your hardware is a bet that the region keeps having it. You cannot move the commitment if capacity tightens, and you cannot exit it. The commitment chapter's advice — that the exit terms matter more than the discount — lands hardest here, because residency has already removed your alternatives.

The mitigation is not clever. It is to prefer the flexible instrument in constrained geographies even though it discounts less, and to treat the discount you give up as the price of not being trapped.

Sovereignty is a different product from a region

Choosing an in-country region addresses data location. Several requirements — particularly public-sector ones — are about operational control: who can access the infrastructure, under whose jurisdiction, operated by whom.

AWS's answer is a separate cloud, not a region. It describes the AWS European Sovereign Cloud as "a new, independent cloud for Europe, designed to help customers meet their evolving sovereignty needs, including stringent data residency, operational autonomy, and resiliency requirements," and claims it is "the only fully-featured, independently operated sovereign cloud backed by strong technical controls, sovereign assurances, and legal protections." A separate tier, Dedicated Local Zones, is "fully managed by AWS, built for exclusive use by a customer or community, and placed in a customer-specified location or data center," including "options to enforce security clearance or other criteria on local AWS operating personnel."

The cost consequence is the one to hold onto: these are distinct offerings with their own capacity and their own commercial terms, not a checkbox on the regions you already priced. Nothing in the public region price list above tells you what an accelerator hour costs inside them.

What I could not price, and am not estimating

Inter-region data-transfer rates are not quoted in this chapter. A multi-region residency design — a model served in Stockholm reading from a bucket in Ireland, or a fleet split across an EU region and a US region — pays a per-gigabyte egress charge on every crossing, and that charge is frequently the largest surprise in a residency architecture. AWS publishes it, but on client-rendered pages that did not resolve against the pricing feeds this book uses, and the metered-unit map carries no transfer keys. Rather than print a number I cannot stand behind, I am declaring it: price your own cross-region transfer before committing to a split design, and treat the figure as first-order, not incidental. The bill around the GPU covers why transfer charges deserve that suspicion.

No GCP or Azure region prices appear either. Both publish accelerator pricing on client-rendered pages I did not resolve in this pass. The Google commitment behaviour cited above is quoted from documentation, not inferred from prices. Sovereign offerings from those two are named nowhere here because I did not source them — not because they do not exist.

The diagnostic

1. Does your instance type exist in your compliance region? Check this before anything else. For p5, 79 of 106 regions fail immediately.
2. Is your "EU" region in the EU? London and Zurich are not. If a contract or regulator says European Union, the label will not defend you.
3. What is your region's multiplier on the instance you actually run? Not on the region generally — São Paulo swings from 1.54× to 1.70× depending on the SKU.
4. Have you compared in-jurisdiction alternatives? London costs 21.5% more than Stockholm for the same H100, and gives up EU membership doing it.
5. Are you paying a domestic premium you never chose? N. California is 1.25× Oregon. Same country.
6. If you are committing, how many compliant regions could serve you? If the answer is one, a region-locked multi-year commitment concentrates supply risk you cannot exit.
7. Have you priced cross-region transfer for the split design? This is the line item most likely to be missing from your model.
8. Is your requirement about location or control? If it is control, regions are the wrong product and sovereign clouds have their own economics.

What this chapter is not saying

It is not saying residency is unaffordable. The headline finding is genuinely reassuring on price: an H100 hour inside the European Union costs 7% more than the cheapest US region. Anyone who has been avoiding EU deployment on cost grounds has been avoiding a rounding error.

It is saying the cost was never the hard part. The hard part is that compliance geography collapses your options to a handful of regions, sometimes to one, and the pricing page cannot show you that — because a price you cannot buy is not displayed as a constraint, it is simply absent.