Region Selection Criteria
The factors determining where workloads run, in which data residency and latency usually dominate cost.
Region choice is made early, is expensive to change once data has accumulated, and is frequently decided by which region the first engineer's console defaulted to.
The criteria, in the order they usually bind:
Data residency and sovereignty. Regulation may require that personal or regulated data never leaves a jurisdiction. This is a constraint, not a preference, and it can force a multi-region topology regardless of scale.
User latency. Speed of light is not negotiable — London to Sydney is ~250 ms round trip. If users are distributed and the product is latency-sensitive, a single region cannot serve them, and no optimisation changes that.
Service availability. Not every service exists in every region, and new services reach the largest regions first. Choosing a small region can foreclose options later.
Cost. Prices differ meaningfully between regions for identical resources, and cross-region data transfer is charged in a way that can dominate a distributed design.
Failure independence and blast radius, and — for disaster recovery — a pair far enough apart to be genuinely independent while close enough for acceptable replication latency.
The design consequence: decide early whether the system will ever be multi-region, because retrofitting regional partitioning into a data model is a rewrite, and the choices that make it possible cost little if made at the start.