Cloud Computing Architecture Guide

Why Placement Is an Architecture Decision

Goal

Cloud geography affects user experience, legal obligations, failure behavior, recovery, and cost. Placement therefore belongs in early requirements work, before a team commits to services that may not exist or behave identically in every location.

The Short Version

Placement is the decision about where requests are served, code runs, state is stored, copies are created, and recovery occurs. A design must balance five concerns:

  • Latency: distance and network paths affect response time.

  • Residency and sovereignty: policy or law may constrain where data is stored or processed.

  • Availability: components must be distributed across relevant failure boundaries.

  • Recovery: copies and failover capability must survive the failures the business cares about.

  • Cost and operability: distribution adds transfer, replication, testing, and support work.

No topology maximizes all five. Architecture makes the trade-off explicit.

Start With Workload Geography

Before selecting a region, map:

  1. Where users, devices, and dependent systems are located.

  2. Which data classes have location or movement restrictions.

  3. Which interactions are sensitive to latency.

  4. Which failures must the workload tolerate.

  5. Which staff can operate and recover the system, and when.

Users and dependencies
        |
        v
Latency and locality needs ---- Data placement constraints
        |                              |
        +------------+-----------------+
                     v
             Primary placement
                     |
                     v
       Availability and recovery design

The answer may not be one location. Static content can be cached globally while regulated records stay in one jurisdiction. Requests can enter through a global edge and then be routed to an approved regional application and data store.

Failure Boundaries, Not Map Pins

A region is useful because it represents a provider-defined deployment and failure boundary, not merely a city label. Availability zones provide separate infrastructure locations within a region. Edge locations bring delivery or selected processing closer to users. Exact definitions and service support differ by provider and service.

The important architecture questions are:

  • Which components share power, network, control, or regional dependencies?

  • Is a service zonal, zone-redundant, regional, or global?

  • Where is state replicated, and is failover automatic or operator-driven?

  • Can identity, keys, DNS, observability, and deployment systems function during recovery?

A diagram with two zones is not evidence of resilience unless the application, data, traffic path, and operating process can use both.

Example: A Global Customer Portal

Northstar serves customers in New Zealand, Australia, and the European Union. European customer records must remain in approved locations, while product images and public documentation should load quickly worldwide.

A reasonable first design separates concerns:

  • Cache public static content through an edge delivery network.

  • Run European request processing and customer data in an approved European region.

  • Run Australia/New Zealand processing in a suitable regional location after measuring user latency.

  • Keep administrative access, logs, backups, and analytics within their allowed data-movement rules.

  • Define recovery per data class rather than copying everything everywhere.

The provider catalog is consulted after this placement intent exists, to verify regional service availability and actual replication behavior.

Common Mistakes

  • Selecting the nearest region to headquarters instead of mapping users and dependencies.

  • Treating an advertised location as proof of data-residency compliance.

  • Assuming every service supports the same zones and regions.

  • Replicating data globally before defining consistency, privacy, and recovery requirements.

If Someone Asks You

Why decide placement before selecting services?

Because location and failure boundaries constrain latency, residency, availability, and recovery. A service is only a valid choice if its actual regional behavior can satisfy those constraints.

What You Should Remember

Placement decides where experience, risk, and recovery meet.

Questions to Check Your Understanding

  1. Which workload facts should be mapped before choosing a region?

  2. Why is a two-zone diagram not sufficient resilience evidence?

  3. Which parts of a global portal can have different placement strategies?

Further Study