Which region do you deploy in? The four forces that decide for you

In Part 1 we took apart how AWS physically distributes its infrastructure: isolated regions, availability zones separated by kilometers but joined by dedicated fiber, and a ladder of failures that tells you what each level protects you against.

But we took something for granted there. When you open the console and go to launch your first resource, AWS forces you to pick a region from a dropdown menu. And the vast majority do the same thing: they leave us-east-1 — the one that’s pre-selected — and move on without a second thought.

Is it a trivial decision? Or did you just commit, in a single click, your app’s speed, the size of your bill, your legal standing, and even which AWS services you’ll be able to use?

Spoiler: all four at once. Choosing a region means balancing four forces that almost never point in the same direction. Let’s go one by one.

Force 1: latency — how far away your users are

This is the most intuitive one. Data travels through fiber fast — but not instantly — and distance charges a toll: the farther your users are from the region, the more latency every request drags along, before your application has done anything. And that toll multiplies with every request, every hop, every image that loads. In AWS’s own words, “reduced network latency can make a substantial impact on enhancing the user experience,” and the guidance is to pick a region “with close proximity to your user base location.”

How much does distance really cost? AWS gives a concrete example: for users in Riyadh, Saudi Arabia, deploying in the Bahrain region delivered about 15 ms of latency — versus roughly 20 ms and 80 ms from farther alternatives. Same application, same request; the only thing that changed was how far the region sat from the user.

The conclusion seems obvious: always pick the region closest to your users. If your audience is in Mexico, us-east-1 or a Mexican region; if it’s in Germany, eu-central-1.

Except “the closest one” is sometimes also the most expensive. And that’s where the second force comes in.

Force 2: price — the same machine costs differently depending on where

This is the point that surprises anyone who has never looked at it. AWS states it plainly: “AWS services are priced differently from one Region to another. Some Regions have a lower cost than others.” The same EC2 instance, the same gigabyte of S3, exactly the same capacity, can carry a different price tag depending on the map.

So the same deployment can cost less in one region than in another for no reason other than where you placed it. The exact numbers live on AWS’s own pricing pages, region by region — the point here isn’t a specific figure, but that this difference exists and is large enough to matter.

Here the first real tension shows up. The region closest to your users — the one that wins on latency — might be exactly the most expensive one. And suddenly the decision is no longer technical but a business one: how many milliseconds is that extra cost worth?

But even if you accept paying more for proximity, there’s something that can forbid you a region entirely, no matter how much you’re willing to pay.

Force 3: regulation — sometimes you don’t choose, you obey

There are laws that dictate where your data is allowed to live. Europe’s GDPR, the data residency rules of sectors like healthcare or finance, sovereignty requirements of certain countries: if you handle data from European citizens and the law requires it not to leave the European Union, then the region isn’t a preference, it’s a legal obligation. It doesn’t matter that another one is faster or cheaper: it’s off the table.

And notice how this connects with Part 1. Remember that regions are isolated by design: nothing crosses from one to another unless you ask for it. That property, which back there seemed like an architectural detail, is exactly what makes legal compliance possible. If data could migrate on its own between regions, no data-residency promise would be credible. Regional isolation is the infrastructure that upholds the law.

Suppose you’ve already filtered: you picked a legally valid region that’s reasonable on cost. One last trap remains — the quietest of them all.

Force 4: service availability — not all regions are equal

You tend to imagine that AWS is identical everywhere. It isn’t. Not all services, not all features, not all instance types exist in every region.

us-east-1 gets practically everything first: new services, preview features, the latest instance types. Newer or smaller regions lag behind, sometimes by months or years. It can happen that the region that’s perfect on latency, price, and regulation simply doesn’t offer that machine learning service you need, or that specific GPU instance.

It’s the easiest force to forget and the one that hurts most to discover late: when you’ve already designed your architecture and it turns out the central piece isn’t available where you wanted to deploy.

The four forces, side by side:

Four forces, then, that contradict each other. How do you untangle the knot?

The us-east-1 case: why it’s the default and why that’s a trap

Before the decision framework, we have to talk about the region everyone picks without picking.

us-east-1 is the oldest and largest region, one of the lower-cost ones, the most complete in services — newer services roll out there first — and where many of AWS’s global control planes live. All of that makes it tempting as a default. And that’s exactly why it’s a trap:

• If your users aren’t on the US east coast, you’re giving away latency.
• It’s the busiest region on the planet — and remember from Part 1 why, when us-east-1 coughs, it looks like half the internet goes down.

Leaving the menu on us-east-1 because it came pre-selected is not choosing. It’s letting inertia decide all four forces for you at once.

How to decide in practice

The key is that the four forces don’t carry equal weight, nor are they evaluated at the same time. Two are hard constraints (they rule options out) and two are optimizations (they help you break ties among what’s left). The correct order goes from filter to fine-tuning:

1. Regulation  →  Where does the law ALLOW me?      (hard filter: rules regions out)
2. Services    →  Where does what I need EXIST?      (hard filter: rules regions out)
        ─────────  the viable regions remain  ─────────
3. Latency     →  Which is closest to my users?      (optimize)
4. Price       →  Among the good ones, which is cheapest?  (tiebreaker)

Regulation and service availability first, because they’re binary: either you can or you can’t; they trim the map down to the regions that are actually viable. Only after that do latency and price come in to pick the best among the survivors. Doing it the other way around — starting with the cheapest or the closest — leads you to fall in love with a region that the law or the service catalog later knocks out.

And if the answer isn’t one region, but several?

Sometimes the knot isn’t resolved by choosing one region, but by taking on several. It’s the answer to three concrete needs:

• Disaster recovery: replicate to a second region to survive an entire region going down — the last rung of Part 1’s failure ladder, the only one multi-AZ doesn’t cover.
• Global audience: serve users across several continents from the region closest to each.
• Multi-country compliance: keep each jurisdiction’s data within its legal borders.

But multi-region isn’t free. It’s more expensive, more complex, and remember that replication between regions does not enjoy the single-digit millisecond latency there was between AZs: it’s thousands of kilometers, with everything that implies for keeping copies in sync. Multi-region is a deliberate decision for a specific problem, never a default you turn on “just in case.”

Closing

You now have what you need to choose a region: four forces — latency, price, regulation, and services — an order for weighing them from filter to fine-tuning, and the warning not to let us-east-1 choose by inertia.

But remember the punchline of Part 1: choosing your infrastructure well protects you from infrastructure failures, not from your own mistakes. And so far everything has lived inside the classic model: regions and availability zones.

What happens when that isn’t enough — when you need to be closer to the user than any region, or inside a mobile network, or literally inside your own building? That’s where AWS extends its cloud beyond the traditional regions. We look at that in Part 3: when one region isn’t enough.