What is a sovereign cloud? 8 essential building blocks

A sovereign region is a good start. It isn’t a sovereign cloud.

Many sovereignty projects begin with storage. A team picks a region, turns off cross-region replication and has the contracts reviewed. Then someone asks who can reach the data, whose laws apply to the company that runs the platform, and where the logs, backups and AI assistants send copies. Some of the answers can sit outside the region the team just chose.

A sovereign cloud is a cloud environment where data, operations and control stay under the jurisdiction and governance you choose. This guide explains what that takes, the eight building blocks it needs, and the two that are easiest to overlook: observability and AI.

What is a sovereign cloud?

Sovereignty covers four questions: where data is stored and processed, who operates the platform and can access it, which laws apply to the provider, and who holds the encryption keys.

Location is only one part of it. A service can store every byte in the right country and still be operated, supported or legally reachable from somewhere else. Sovereignty asks about all of those at once.

The European Commission now scores providers this way. Its Cloud Sovereignty Framework (version 1.2.1, October 2025) rates cloud services on eight sovereignty objectives, and the Commission used it in a sovereign cloud tender worth up to EUR 180 million, awarded in April 2026.

Data residency vs data sovereignty

Three terms get used as if they mean the same thing. They answer different questions.

Picking an in-country region gives you residency. It doesn’t change who operates the platform or which laws reach the provider. Those are building blocks 1 and 4 below.

The 8 building blocks of sovereign cloud architecture

A sovereign cloud depends on more than where your data lives. These eight decisions determine where data can travel, who can access it, and how much control you retain.

This is Kloudfuse’s practical sovereign-cloud evaluation framework. It is informed by the European Commission’s Cloud Sovereignty Framework but is not a reproduction of its eight official objectives, which also cover strategic, supply-chain and technology sovereignty.

Each block below ends with the question to put to every provider.

1. Legal jurisdiction

Where a provider is incorporated, and where its parent company is, helps determine which governments can demand access to your data. Storing data in-country doesn’t change that. A provider subject to US law can be compelled under the CLOUD Act to disclose data in its possession, custody or control, wherever the data is stored. Providers can challenge some orders on conflict-of-law grounds, and other regimes, such as FISA Section 702, raise similar questions. Contracts can limit and report such requests, but they can’t cancel the law. A provider’s incorporation, operations and corporate structure all affect which laws can reach it, and its architecture affects what data it can actually access.

How to check: Where are the provider and its parent incorporated, and which laws can compel it to disclose our data?

2. Data residency

Residency is the familiar part: choosing the regions where workloads run and data is stored. What trips teams up is processing. Data can rest in one region but be processed in another, by a managed service, a support tool or a batch job running somewhere cheaper. Map every service that touches the data, not only the primary database.

How to check: In which regions is our data stored and processed, including by managed services and support tools?

3. Encryption and keys

Encryption supports sovereignty to the extent that you control the keys. Provider-managed keys give you the least control, because the provider generates, stores and rotates them. Whether the provider can actually reach plaintext depends on its architecture and the access permissions in place. With customer-managed keys in the cloud provider’s key management service (KMS), you control key policies, rotation, auditing and revocation, but the provider still operates the service that holds them. External key management, where keys sit in a hardware security module (HSM) or key service outside the provider’s infrastructure, separates that control further. Which level you need depends on your requirements and threat model. Keys alone don’t stop access to plaintext, though: the permissions granted to services and administrators still matter. Check which services support your keys, and whether backups and logs use them too.

How to check: Who generates, holds and rotates the keys, and can the provider read our data without them?

4. Identity and operations

Most access to data happens through people with legitimate credentials. Use your own identity provider, enforce least privilege and log every privileged action. Then look at the vendor’s side: who at the provider can reach your environment for support, upgrades or emergencies, from which countries, and with whose approval. Ask for access that is time-limited, approved by you and logged.

How to check: Who at the provider can access our environment, from where, and how is each access approved and logged?

5. Network boundaries

Data leaves through the network, so the network defines the real boundary. Use private endpoints where services support them, and restrict outbound traffic to approved destinations. Then list the third parties your services call: licence servers, update services, telemetry endpoints and external APIs. Each one is a path out. A service that breaks when outbound traffic is blocked is telling you about its dependencies.

How to check: What traffic leaves our boundary, to which destinations, and can we block it without breaking the service?

6. Backup, recovery and exit

Disaster-recovery copies are full copies of production, and they are easy to place in another region by default. Keep backups, snapshots and archives under the same residency and key rules as primary data. Plan your exit at the same time: data formats, export tools and how long a move would take. From 12 January 2027, the EU Data Act bars providers of cloud and data processing services from imposing switching charges, though other migration costs, such as engineering time, remain yours.

How to check: Where do backups and recovery copies live, and how do we get all of our data out, in what format?

7. Observability

Logs and traces record what happens in the requests your systems handle, so they often carry IP addresses, user IDs and business detail. Metrics are usually aggregated, but their labels can still hold identifiers. They are easy to send to a monitoring service hosted outside your boundary without treating that as a data transfer. The next section shows how a single log line can undo a careful sovereignty plan.

How to check: Where are our logs, metrics and traces stored, queried and displayed, and who can access them?

8. AI processing

AI assistants are the newest path out. A copilot that summarizes an incident or answers a question about your systems may send logs, records or code to a model hosted somewhere else. Check which AI features are on by default, where the model runs, what context it receives and whether prompts are kept. Treat the model provider like any other data processor.

How to check: Which AI features are on by default, where do the models run, and what data are they sent?

Why observability is easy to overlook

Applications generate logs, metrics and traces that can reveal detailed information about production requests, users and transactions. That telemetry is a second copy of production, and it often holds personal data. Here’s a synthetic log line from a payments service running in an EU region:

{
  "service": "payments-api",
  "region": "eu-central-1",
  "level": "error",
  "msg": "card authorization failed for m.schulz@example.com",
  "customer_id": "c_48213",
  "client_ip": "203.0.113.24"
}

That one line holds an email address, a customer ID and an IP address, which GDPR Recital 30 names as an online identifier. If the observability platform stores and queries it in the provider’s cloud, the application can be sovereign while its telemetry isn’t. Masking fields in the collector helps, but free-text messages and stack traces carry data nobody planned for.

To check an observability platform, follow a log line across six boundaries:

Keeping telemetry in your own cloud doesn’t automatically keep ingestion, queries, exports and AI processing inside the same boundary. Check each of the six separately, and read the architecture docs, not only the product page.

Rules that shape sovereign cloud decisions

Few laws say “use a sovereign cloud”. Several decide where data can go and what contracts must say:

• GDPR applies to personal data wherever it appears, logs included. It doesn’t require EU-only storage, but transfers outside the EEA need a transfer mechanism, such as the adequacy decision for the EU-US Data Privacy Framework, which is under appeal at the EU Court of Justice.
• DORA Article 30 requires EU financial entities’ contracts with ICT providers to state where data is processed and stored.
• The EU Cloud Sovereignty Framework is a procurement tool, not a law, but it shows how the Commission scores providers: eight objectives, weighted from supply chain (20%) to environmental sustainability (5%), and assurance levels from SEAL-0 (no sovereignty) to SEAL-4 (full digital sovereignty).
• India’s CERT-In directions require covered entities to keep ICT system logs for 180 days within Indian jurisdiction. That puts observability data squarely in scope.
• The US CLOUD Act and the EU Data Act are covered above: one decides who can be compelled to hand over data, the other bars switching charges from 12 January 2027.

This isn’t legal advice. Check the rules that apply to you with your counsel.

Where Kloudfuse fits

Kloudfuse covers the observability layer of a sovereign cloud, building block 7. It doesn’t replace the controls around jurisdiction, infrastructure, identity or encryption. Kloudfuse is a US company, so the block 1 question applies to us too, and the answer depends on how you deploy it. In its architecture, the observability data plane (ingestion, query and the UI) runs inside your VPC, and telemetry is kept in object storage in your own cloud account. You can encrypt it with your own KMS keys, configured at installation. Health monitoring of your deployment by Kloudfuse is optional. When it is on, Kloudfuse receives operational metrics and logs about Kloudfuse services and infrastructure components.

Access runs through your own single sign-on, local login can be turned off, and the audit log records configuration changes, sign-ins and query activity. Who at Kloudfuse can reach your environment depends on how you run it. In self-operated deployments, Kloudfuse engineers have no access. In co-managed and fully managed deployments, access typically goes through infrastructure you provide and control, such as a jump host or a designated laptop. Kloudfuse holds SOC 2 Type II and ISO/IEC 27001:2022, lists PCI DSS as current, has completed a HIPAA audit, and uses cryptographic modules validated to FIPS 140-3 under NIST CMVP certificates #5186 and #5209. These cover Kloudfuse itself; your compliance still depends on how you configure and run it. The security page has the details.

Dexter, our AI SRE, runs as a separate deployment and reads telemetry through the Kloudfuse MCP (Model Context Protocol) server, whose tools are read-only. You choose where the model runs. With a model you host, inference stays in infrastructure you control. With Amazon Bedrock, it runs in an AWS-managed model service, in the region you configure. With Anthropic’s hosted models, investigation context is sent to Anthropic’s API. Check the processing region and data handling for whichever option you choose.

How Kloudfuse maps to the eight building blocks:

Pricing is a fixed annual tier based on terabytes ingested per day. You also pay for the compute and storage it runs on in your own account, where eligible cloud commitments may apply, depending on your agreements. The pricing calculator models both.

Frequently asked questions

Is a sovereign region the same as a sovereign cloud?

No. A region gives you data residency. Sovereignty also depends on who operates the platform, which laws reach the provider, who holds the keys, and where copies such as backups, logs and AI prompts go.

Can a public cloud be sovereign?

Yes, if the eight building blocks are under the control you need: jurisdiction, residency, keys, identity and operations, network, backup and exit, observability and AI. How far each provider goes varies, so assess the service, not the label. Sovereign cloud providers come in three kinds: sovereign regions or partitions run by large public clouds, regional or national cloud providers, and infrastructure you operate yourself. None of them guarantees all eight building blocks on its own.

Are logs and traces personal data under GDPR?

Often, yes. Email addresses, user IDs and IP addresses regularly appear in log messages, trace attributes and session data.

Is BYOC the same as sovereign?

No. Bring-your-own-cloud describes where the data plane runs. Sovereignty depends on every boundary, including the UI, the control plane and the AI layer. Our guide to BYOC observability covers the deployment model.

Does running software in our own cloud cost more?

Not necessarily. Total cost includes platform licensing, compute, storage, network transfer and the operational effort to run it. Eligible cloud commitments and discounts may apply to the infrastructure in your own account, depending on your agreements. Compare that total with your current bill at the same data volumes. The Kloudfuse pricing calculator can help you estimate it.

Your cloud may be sovereign. Check what’s watching it.

Map your stack against the eight building blocks. Where data or control crosses a line your policy doesn’t allow, that’s your gap.

Not sure where your observability data travels? Review your telemetry architecture with our engineers and find where data, queries or AI investigation context cross your cloud boundaries. To estimate cost first, try the pricing calculator.