AWS Architecture Guide

Regional Design and Data Residency Scenario

Goal

Apply the chapter's placement model to a realistic scenario with low latency, data residency, and failover requirements.

The Short Version

Good regional design usually starts with one clear question: what must stay close to users, and what can stay centralized?

The durable idea is:

The best regional design is the one that satisfies latency and residency requirements without over-engineering recovery.

Scenario

A company serves customers in two nearby geographies. Most users are happy as long as the portal is responsive, but a subset of the workload stores regulated data that must stay within a specific country. Leadership also wants a reasonable recovery strategy if a local Availability Zone fails.

The team asks whether it should deploy everything in multiple Regions immediately.

A Better Answer

The first answer is not to multiply Regions by default. The first answer is to separate the requirements:

  1. Which data must remain in the required jurisdiction?

  2. Which user-facing paths need low latency?

  3. What failure scope must the system survive?

  4. Which parts of the application really need cross-Region recovery?

That usually produces a smaller, more defensible design.

A Possible Design Shape

Primary Region
  -> Multi-AZ application and data tier
  -> Country-specific data residency boundaries
  -> Edge delivery for static or repeat content
  -> Regional backups and tested recovery

Optional secondary Region
  -> Warm or cold recovery target
  -> Limited failover scope for critical services

This shape keeps the main workload simpler while leaving room for recovery.

Practical Meaning

The design could use:

  • a primary Region that satisfies the residency requirement

  • Multi-AZ deployment inside that Region

  • CDN or edge delivery for globally requested static content

  • a secondary Region only for the parts that truly need regional failover

That avoids a common mistake: building a large multi-region architecture before proving that the business needs it.

Example Decision

If the team can meet the business requirement with a single Region, Multi-AZ, edge delivery, and tested backups, that is usually the right first design.

If the business later asks for a geographic failover target with clearly defined RTO and RPO, then a secondary Region can be added deliberately rather than guessed at the start.

Common Mistakes

  • Designing for two Regions before understanding the residency rule.

  • Over-sharing sensitive data across locations because the app is "global."

  • Confusing latency reduction with disaster recovery.

  • Failing to test recovery assumptions.

If Someone Asks You

If someone asks, "How would you design AWS placement for low latency and data residency?" a clear answer is:

Start with the residency boundary, then place the primary workload in a Region that satisfies it, use Multi-AZ for local resilience, add edge delivery where it reduces latency safely, and add a second Region only if the recovery requirement really needs it.

What You Should Remember

Geography is a constraint, not a design goal.

Questions to Check Your Understanding

  1. Why should data residency be separated from latency concerns?

  2. When is Multi-AZ enough for a regional design?

  3. Why should a secondary Region be added deliberately?

Further Study