--- type: tradeoffs pillar: sovereignty code: SOV title: "Sovereignty & Compliance: tradeoffs" description: What sovereignty controls cost operations, cost and reliability, plus the two that pay for themselves regardless of regulation. status: draft sidebar: label: "Tradeoffs" order: 2 source_url: "https://framework.stackit.cloud/architecture/pillars/sovereignty/tradeoffs/" source_file: "docs/architecture/pillars/sovereignty/tradeoffs.mdx" --- Sovereignty is frequently presented as free: a matter of choosing the right provider and signing the right agreement. It is not. Sovereignty constrains architecture, and constrained architectures cost more, move slower, and forgo capabilities that are genuinely useful. Those costs are worth paying where the classification warrants it. They are waste where it does not, which is why [`SOV 1`](/architecture/pillars/sovereignty/sov-01-sovereignty-tier/) insists on classification first: the expensive controls should apply to the data that needs them, not uniformly out of caution. --- ## Against Operational Excellence **The largest cost, and the least anticipated.** Customer-managed keys mean you now operate a key lifecycle: generation, rotation, revocation, backup of key material, and a procedure for the day someone deletes a key that a live database depends on. Provider-managed keys are one setting; customer-managed keys are a system with an on- call rotation. Restricting operator access has a direct cost in support. The paths that let provider engineers diagnose your problem are the same paths sovereignty asks you to close. Close them and troubleshooting becomes slower and more of it becomes yours. Preferring open interfaces over proprietary managed capabilities frequently means operating something yourself that you could otherwise have consumed. That is straightforwardly more work, permanently. **How to resolve it:** scope by classification rather than applying uniformly. Customer-managed keys for the regulated data set, provider-managed for the rest. And budget the operational load honestly at design time: a key management practice that is under-resourced becomes an availability incident, which is a worse outcome than the provider-managed key you were avoiding. ## Against Cost Optimization Sovereignty costs show up in several places at once: - **Confidential computing** carries a compute premium and constrains instance choice. - **Key management** has per-operation costs that become significant on hot paths. - **Restricted placement** removes the option of chasing cheaper capacity elsewhere. - **Extended audit retention** accumulates storage indefinitely. - **Foregone proprietary services** means building and operating what you could have bought. - **Exit testing** consumes real engineering time producing nothing customers see. **How to resolve it:** classification-driven scoping again, plus honesty about the alternative. The comparison is not "sovereign architecture versus cheap architecture". It is "sovereign architecture versus a compliance finding, a supervisory proceeding, or a migration you did not plan". Price the sovereignty controls against that, not against zero. ## Against Performance Efficiency - **Customer-managed keys** put a key service on the path of operations that would otherwise be local. Usually cached and amortized; occasionally material on high-volume workloads. - **Confidential computing** imposes measurable overhead, varying by workload shape. - **Regional constraints** can prevent placing compute close to users. For a European user base this is rarely binding, and for a global one it is. - **Data minimization**, collecting less, retaining less, sometimes removes data an optimization depended on. **How to resolve it:** measure the specific case. Key operation overhead is dominated by caching strategy, and confidential computing overhead varies enough by workload that a general figure is not useful. Both are frequently smaller than assumed in design discussions. ## Against Reliability Two genuine conflicts, one of them severe. **Key custody is a durability risk.** Holding your own keys means you can lose your own keys, and losing a key destroys the data it protects as thoroughly as losing the data. Key backup, escrow, and rotation procedures need the same rigour as [`REL 8`](/architecture/pillars/reliability/rel-08-backup-and-restore/), and they need testing for the same reason. **Placement constraints limit recovery options.** A workload restricted to one jurisdiction has fewer places to fail over to. On STACKIT this is mild: `eu01` and `eu02` are both inside EU jurisdiction, so cross-region recovery does not force a sovereignty tradeoff the way it can elsewhere. It is still a constraint that has to be checked rather than assumed. **How to resolve it:** treat key material as the most critical state in the system, because it is. And verify explicitly that your backup and DR destinations satisfy the classification, rather than discovering during an audit that recovery works and is not permitted. ## Against Security Aligned in mechanism, divergent in question, see the [Security tradeoffs](/architecture/pillars/security/tradeoffs/) for the same point from the other direction. The practical risk is that satisfying one is mistaken for satisfying the other. Encryption at rest with provider-managed keys is good security and does not address [`SOV 4`](/architecture/pillars/sovereignty/sov-04-key-ownership/). Conversely, holding your own keys addresses sovereignty and does nothing about an attacker who has compromised a workload identity that is permitted to use those keys. One real friction: restricting operator access reduces sovereignty exposure and can also reduce the provider's ability to help you during a security incident. That is a tradeoff to decide before the incident. ## Against Sustainability Small and mostly indirect. Confidential computing consumes more energy per unit of work. Extended audit retention keeps storage occupied for years. Placement constraints remove the option of running workloads where energy is cleanest. None of these should drive a sovereignty decision. They are worth knowing about for reporting purposes. --- ## Where sovereignty pays back Not everything here is a cost, and two of these questions pay for themselves regardless of regulatory pressure. [`SOV 7`](/architecture/pillars/sovereignty/sov-07-auditability/), designed-in auditability, produces exactly the record you need to investigate a security incident or a data corruption, which is why it is worth building before an auditor asks. [`SOV 10`](/architecture/pillars/sovereignty/sov-10-open-interfaces/), open interfaces, is also the question that keeps your architecture legible and your engineers' skills transferable. Portability and simplicity tend to arrive together. --- ## Related - Design principles - [Overview](/architecture/pillars/sovereignty/): the questions this pillar asks - Security tradeoffs