Local cloud, local zones, and six questions before choosing an architecture
Data location is only one variable. This six-question framework evaluates control boundaries, cost, and recovery for each workload.
When more infrastructure choices are available close to users, cloud selection can be reduced too quickly to a data-location question. That view is incomplete. A suitable architecture should be evaluated workload by workload, because data, operational authority, latency, and recovery paths can differ sharply across one organization.
Six questions that need evidence
- What data is processed? Classify the data, retention period, inputs, and every place where it is copied or exported.
- Who controls each layer? Separate data plane, control plane, identity, encryption keys, monitoring, and operational support; do not infer all of them from the location of one data copy.
- Where does latency matter? Measure real user journeys rather than only a ping to an infrastructure location.
- What is the three-year cost? Include connectivity, data transfer, integration, staffing, migration, and an exit option.
- Who restores service during an incident? Identify the accountable party, practical service commitments, escalation path, and the work that remains with the internal team.
- Can the workload move? Test data formats, infrastructure-as-code, proprietary dependencies, and the time needed to restore in another environment.
Decide by workload portfolio
Instead of choosing one provider for everything, divide workloads into groups: interactive systems that need low latency, data with high control requirements, analytics platforms with large elasticity needs, and services that suit a hybrid design. Each group benefits from a short decision record containing assumptions, measurements, remaining risk, and a review date.
Two tests often missed
First, test the management path: if the portal, DNS, identity layer, or control network fails, can the team still operate the workload? Second, test the full traffic cost: a system may be inexpensive at the compute layer and become costly through data replication or cross-environment integration. Both should be exercised with a realistic scenario before making a long commitment.
There is no universal answer for every application. The value of this framework is that it moves the discussion away from labels such as local or global and toward responsibility, technical evidence, and verifiable cost.
Published ; updated