Regional isolation

AWS Regions are independent of one another by design. They have separate infrastructure, separate control planes for most services, and a failure in one is not supposed to propagate to another. A design that keeps each workload’s traffic inside a single Region inherits that isolation; one that reaches across Regions casually gives it up and pays for the privilege.

The default position is therefore: everything a request touches lives in the Region that serves the request.

Why

Latency. A cross-Region call adds tens to hundreds of milliseconds in each direction, and it adds them to every request that makes the call, not to an average. Chains of two or three such calls are what turn an acceptable response time into an unacceptable one.

Cost. Data leaving a Region is billed. Traffic within an Availability Zone or between services in the same Region is cheaper or free depending on the path, so a chatty cross-Region dependency shows up as a recurring bill line rather than a one-off.

Data residency. Where personal data physically sits is a legal question in the UK, the EU and a growing number of other jurisdictions. Keeping a Region’s data in that Region is far easier to evidence to an auditor than a design that moves data around and then argues about which copy is authoritative.

Blast radius. A workload contained in one Region fails in one Region. A workload that depends on a service in another Region fails when either Region does, which is a worse availability figure than either alone.

Cross-Region work that is worth doing

Isolation by default does not mean never replicating. It means replicating deliberately, for a stated reason:

• Disaster recovery. A second Region is the standard answer to a Region-level failure. What is replicated, how often, and how failover is triggered is a design decision with a cost attached — see disaster recovery.
• Serving a distant audience. Users on another continent are better served by an endpoint near them, or by CloudFront in front of a single origin.
• A regulatory copy. Sometimes a second copy in a named jurisdiction is the requirement itself.

In each case the replication is scheduled or event-driven and asynchronous. What should not happen is a synchronous request path that crosses a Region boundary to complete.

Practical rules

• Pin every stack to an explicit Region in its infrastructure code rather than relying on a default from a profile or environment variable.
• Keep the data and the compute that reads it in the same Region; move the compute, not the request.
• Remember which services are global rather than regional — IAM, Route 53, CloudFront and organisation-level controls among them — because they are the exceptions that make an otherwise regional diagram wrong.
• Where a copy in another Region exists, be explicit about which one is authoritative and what the replication lag is. Two writable copies of the same data in two Regions is a consistency problem, not a resilience feature.