Choosing a Cloud Region: Latency, Cost, and Resilience

A team can pick the closest cloud region, get everything deployed, and still make the wrong infrastructure decision.

Say you are serving users in Europe.

One region looks obvious. It is nearby, compute is reasonably priced, and latency looks good.

So the team deploys the API, database, and Kubernetes cluster there.

Then, close to launch, someone discovers that the managed database in that region does not support the replication mode the product depends on.

Now the team has three choices:

Nothing technically failed.

The architecture just did not fit the region.

That is why I do not think of a cloud region as a point on a map.

A region is an operating boundary.

It shapes what services and features are available, where data can live, what traffic costs, what latency users experience, and what remains available when something breaks.

The question I care about is not:

It is:

That usually changes the order in which you make the decision.

A common mistake is choosing the region first and discovering constraints later.

Geography looks right.

Pricing looks fine.

Deployment succeeds.

Then you discover that a required database feature is missing, the GPU type you need has no capacity, your recovery region has insufficient quota, or your data residency requirement rules out the design entirely.

By that point, changing regions can mean moving data, rebuilding automation, revisiting contracts, or changing the product itself.

I would decide in roughly this order:

That does not mean every application needs multiple regions.

Most do not.

A well-understood single-region design with multi-zone redundancy may be completely reasonable.

But the team should be able to say this explicitly:

A full regional outage is outside our current recovery target.

That is an accepted risk.

It is different from discovering during an outage that nobody ever made the decision.

Physical distance matters.

It just does not tell you enough.

A user might connect to a nearby CDN edge while the actual request still travels to a backend region hundreds or thousands of kilometres away.

A cache hit and a dynamic API call can therefore have completely different latency even though both start at the same public endpoint.

This is why I would not choose a region from a provider latency map alone.

Those maps are useful for removing obviously bad candidates.

They do not tell you whether checkout, login, an API call, or a database-backed request will meet your SLO.

Measure the path your users actually depend on.

That may mean looking at:

A CDN or global load balancer can make every region look similar from the browser while hiding a much longer backend path.

And even good measurements expire.

Traffic moves to new countries. Internet routes change. Provider routing changes.

Region selection is not a number you measure once and forget.

Cloud consoles make this easy to misunderstand.

You search for a region, see that Kubernetes or the managed database exists there, and assume the design is supported.

But "service available" is a very weak requirement.

The real question is whether your exact version of the design works there.

For Kubernetes that could mean:

For a database:

For GPUs, even seeing the accelerator listed in a region does not mean you can provision the quantity you need when production fails over.

This distinction becomes especially important for recovery.

Quota and capacity are not the same thing.

Having quota means the provider will allow you to request the resources.

It does not mean the hardware will necessarily be available at the moment you need it.

A recovery region that cannot run the workload when the primary fails is not a recovery region.

It is an architecture diagram.

Compute pricing is only one part of the topology.

What matters is where the bytes move.

Before choosing a region, I would draw the normal path:

Then draw it again during failure.

Where is state replicated?

Where are backups stored?

Where do users connect after failover?

Does the recovery region read state locally or across regions?

Do logs, metrics, artifacts, or analytics continuously cross regional boundaries?

Those decisions can create ongoing transfer cost long after everyone forgets why the cheaper region was selected.

The exact billing rules are provider-specific, but the reasoning is simple:

Model each important path separately.

Do not hide all network movement inside one line called "egress."

If the design uses continuous cross-region replication, validate its actual managed-service pricing before approval.

And include failure traffic.

A cost model that only describes the healthy system is incomplete.

This gets blurred surprisingly often.

Multi-zone deployment helps with failures inside a region.

Regional recovery answers a different question.

Depending on the service, multi-zone may protect against infrastructure or zone failure while still leaving the application unavailable if the whole regional dependency disappears.

Cross-region recovery introduces a different set of problems:

A provider calling something "multi-region" does not answer those questions for your application.

Neither does having a second region drawn in Terraform.

I would want concrete answers:

If those answers do not exist, you do not have regional recovery yet.

You have the intention to build it.

This is where the region decision becomes more interesting than simple availability.

A workload can continue serving traffic while the team loses the ability to deploy, scale, rotate certificates, fetch secrets, ship logs, or execute failover.

The opposite can happen too.

A control-plane issue may stop new operations while the existing data plane continues serving traffic.

So instead of asking:

I would ask:

AWS's July 2024 Kinesis incident is a useful example.

It was not an entire AWS region going down. The issue affected a Kinesis cell, while other cells and other regions continued operating.

But the impact propagated into services that depended on Kinesis, including CloudWatch Logs, Firehose, ECS, Lambda, Redshift, and Glue.

One particularly useful detail from the incident was ECS logging.

Tasks using the awslogs driver in blocking mode could block when logs could not be delivered, fail health checks, and become unhealthy.

With non-blocking logging, applications could continue but potentially lose logs.

That is a much better way to think about dependencies.

The question is not simply:

Can logging fail?

It is:

If logging fails, does the application keep serving traffic? Can new instances start? Can operators still understand what is happening?

Those are different failure modes.

And they should not be hidden behind one box labelled "regional services."

Adding another region sounds like increasing reliability.

Sometimes it does.

Sometimes it adds another system that has never been tested.

Now you also depend on:

If those pieces are untested, the second region gives you more architecture without necessarily giving you more recoverability.

I would rather have a clearly understood single-region system with an explicit recovery boundary than a multi-region diagram that nobody has exercised.

The final output of region selection should not be a giant architecture document.

It should be a decision someone else can challenge later.

Something like:

That tells me much more than:

It shows what was measured.

What was rejected.

What risk was accepted.

And what is still unproven.

That is what I want from a region decision.

Not a provider map.

Not the cheapest VM price.

Not "this is the region we normally use."

The region is part of the architecture.

Choose it only after the assumptions that matter are visible.

👋 Find me on Twitter | Linkedin | Connect 1:1

Thank you for supporting this newsletter.
Y’all are the best.