SOV 2. How do you decide where workloads and data are placed, and how do you know?
Zuletzt aktualisiert am
Placement is the most visible sovereignty decision and the easiest to believe you have made. The primary compute and the primary database are chosen deliberately. What surrounds them frequently is not, and a residency claim is only as strong as the dependency nobody checked.
The question is therefore less about choosing a region than about being able to demonstrate, for every component that touches the data, where it runs.
Best practices
Section titled “Best practices”SOV 2.1Choose region and availability zone deliberately, against the tierSOV 2.2Trace the processing location of every dependency, not only the obvious onesSOV 2.3Watch the paths that are not obviously data pathsSOV 2.4Re-establish residency when the architecture changes
SOV 2.1 Choose region and availability zone deliberately, against the tier
Section titled “SOV 2.1 Choose region and availability zone deliberately, against the tier”Risk if not established: High
Region choice usually happens once, quickly, and by default. For Tier 3 that is fine. For Tier 1
it is the decision the whole classification exists to drive, and it deserves to be recorded
alongside its reasoning under SOV 1.2.
Two separate concerns sit behind the same choice, and mixing them produces bad decisions. Where
the data legally resides is a sovereignty question. How the workload survives a zone failure
is REL 4. They are answered with the same controls, which is why they get conflated, and they
can pull in different directions when a jurisdiction has one region.
State the constraint as a boundary rather than as a specific region. “This data stays in the EU” and “this data stays in Germany” are different requirements with different available answers, and the architecture should record which one applies.
On STACKIT. The platform states that it hosts all
regions exclusively in Germany, as eu01, and
Austria, as eu02, with at least three physically separate availability zones per region. Both
are within the EU, which means an EU-boundary requirement is satisfied by either while a national
requirement narrows the choice to one.
Where the requirement is broader than a single country, ES³ publishes an Approved Jurisdictions List: a core group of the EU and EEA plus Switzerland, and an extended group of the United Kingdom, Canada, Israel, Andorra and Japan. It is a published starting point rather than a verdict on your obligations, and comparing against one beats each team drawing its own line from scratch. Recording which group a placement decision was made against, and which version of the list, is what makes the decision re-checkable when the list is updated.
The property that matters for design is that parity is maintained across locations but not guaranteed at every moment, because specialized services and newer features may be released in specific regions first. A residency constraint that forces a particular region can therefore constrain which services the architecture can use, and that is worth checking before the design depends on it rather than afterwards.
The Metro availability zone, written as <region>-m, is a further case of the same pattern. It
applies to the services that support synchronous replication at the storage level rather than
being universally available, which REL 4 uses from the reliability side and which here means a
placement option is service-dependent.
Tradeoffs. Reliability and Performance Efficiency. A narrow residency boundary reduces the placement options available for redundancy and for proximity to users. That is the cost the tier is accepting rather than a problem to solve.
Verify. Which region does each component of your workload run in, and who decided that? Is the residency requirement recorded as a boundary or as a region name?
SOV 2.2 Trace the processing location of every dependency, not only the obvious ones
Section titled “SOV 2.2 Trace the processing location of every dependency, not only the obvious ones”Risk if not established: High
The primary data store is almost never where a residency claim fails. It fails at a dependency that was added for a good reason and never assessed, because it did not look like a data decision.
Enumerate what actually touches the data. The application and the database are on the diagram. The cache, the message broker, the search index, the object store, the CDN, the backup destination, the log pipeline, the metrics store, the error tracker, the notification service and the analytics integration frequently are not, and every one of them holds or transports the same data.
Distinguish storage from processing. Data that is only in transit through a component still gets processed there, and a component that holds it for milliseconds is still a processing location for the purpose that matters here.
Produce the list as an artefact rather than as an exercise. It is the input to SOV 6, which asks
the harder question about jurisdiction, and it is the first thing an assessment will ask for.
On STACKIT. The most consequential case is the STACKIT Marketplace . The delivery model is software as a service: products are hosted and deployed in the vendor’s environment rather than in your project, and the customer uses the software without managing the underlying resources.
That is a normal and useful model, and it has a direct consequence here: a marketplace product
processes your data on the vendor’s infrastructure. Being purchasable through STACKIT does not
place the vendor where STACKIT is. Whether it is acceptable is a SOV 6 question about that
vendor specifically, and for Tier 1 data it is a question that has to be asked before the
integration rather than after.
Other delivery methods are under evaluation, including images deployed into the customer’s own project. Those would sit differently, so the delivery model of the specific product is what to check rather than carrying this one forward.
Tradeoffs. Operational Excellence. Maintaining a dependency inventory is continuing work,
and it is the same inventory SEC 6.3 and SOV 6 need, so it is paid once.
Verify. List every component that stores or transports your data. For each, where does it run, and how do you know rather than assume?
SOV 2.3 Watch the paths that are not obviously data paths
Section titled “SOV 2.3 Watch the paths that are not obviously data paths”Risk if not established: Medium
Some dependencies carry data without looking like they do, and those are where a carefully placed architecture leaks.
The recurring cases. Support and diagnostic channels, where a stack trace or a database dump attached to a ticket travels wherever the ticketing system is. Developer tooling, where an error tracker or a debugging session pulls production data to a workstation. Third-party libraries that phone home with telemetry. Content delivery and edge services that cache responses. Email and notification services that render personal data into a message.
None of these appear on an architecture diagram, and each has produced a residency finding somewhere.
The pattern is that operational convenience creates data paths that the design review never saw, because the tool was adopted by a team rather than architected in.
Address it by making the question part of tool adoption rather than by auditing afterwards.
Anything that can receive production data is in scope for SOV 6, whether or not it is
infrastructure.
On STACKIT. The platform-side control is egress restriction, which SEC 6.3 describes: a
workload that cannot reach an unapproved destination cannot leak to one, and the attempt becomes
visible rather than silent.
That is the only mechanism that finds these paths systematically, because it does not depend on somebody having remembered the dependency. What it will not cover is data leaving through a person rather than through the workload, which is process rather than architecture.
Tradeoffs. Operational Excellence. Restricting egress and reviewing tool adoption both slow teams down, which is the cost of knowing where the data is.
Verify. In the last incident, what data left your environment through a support ticket, a debug session or an error report? Where did it go?
SOV 2.4 Re-establish residency when the architecture changes
Section titled “SOV 2.4 Re-establish residency when the architecture changes”Risk if not established: Medium
A residency assessment describes the architecture on the day it was done. Architectures change weekly, and nothing about adding a cache or an integration looks like a sovereignty event.
Tie the check to change rather than to a calendar. A new dependency, a new integration, a new region in the design, a new backup destination and a new managed service each warrant the question, and each is a discrete moment where somebody can be asked.
The cheapest place to put it is the change process that OPS 5 already governs. A single question
about whether a change adds a processing location costs nothing when the answer is no, which is
most of the time.
Watch for changes made by the provider rather than by you. A service gaining a new region or a
managed component changing where it runs is outside your change process, which is one of the
things the shared responsibility split in SOV 8.3 should make explicit.
On STACKIT. No platform feature detects a residency change in your architecture. What the
platform supplies is the record of what was created and when, through the audit log in SOV 7,
which is what makes a retrospective answer possible when somebody asks how a component arrived.
Tradeoffs. Operational Excellence. One more question in a review that already has several. It is cheap in proportion to how rarely the answer is interesting.
Verify. When did your residency assessment last get updated, and how many architecture changes have shipped since?