How do you keep cloud and Kubernetes data inside the EU?

EU data residency means that every copy of your data, including backups, logs, metadata and encryption keys, is stored and processed in EU locations, and that nobody reaches it from outside the EU. Picking an EU region covers your servers, but a Kubernetes platform also copies data into its control plane, snapshots, observability tools, container registry and support channels. Residency holds only when each of those paths stays in the EU and a policy, not a convention, enforces it.

Why an EU region is not enough

The GDPR does not regulate where servers stand. Chapter V of the GDPR regulates transfers of personal data to countries outside the EU and EEA. The European Data Protection Board treats remote access from a third country as such a transfer, even when the data is only displayed on a screen during a support session (EDPB Guidelines 05/2021). A cluster in Frankfurt that an operations team administers from another continent is therefore not “EU only” in the legal sense.

Residency is also separate from jurisdiction. Data can sit in an EU region and still be reachable under foreign law if the provider is subject to it. See data sovereignty vs data residency and how the US CLOUD Act applies to EU data.

Where data leaves the region

Location What it holds Control
Control plane and etcd Every Kubernetes object, including Secrets, ConfigMaps and annotations Choose the control plane region; encrypt objects with a KMS key you control
Backups and volume snapshots Full copies of databases and volumes Write to an EU bucket; check that cross-region replication is off
Logs, metrics and traces IP addresses, user IDs, request payloads, error messages Use an EU observability backend; scrub personal data before export
Container registry Images, and sometimes configuration or test data baked into them Use a registry region in the EU and disable global replication
DNS, CDN and load balancers Client IP addresses, cached responses Restrict CDN caching of personal data to EU points of presence, or skip the CDN for it
KMS or HSM The keys that decide who can read everything else Keep keys in an EU key store, ideally one you operate
Disaster recovery site A full replica Pick a second EU region, not the provider’s default pair
Support and sub-processors Access to any of the above Read the data processing agreement and the sub-processor list, and ask where support staff log in from

Teams usually find the gaps in the last rows: a SaaS error tracker in the US, a backup tool that replicates to a global bucket, or a vendor support engineer in a third country.

Pin workloads and storage with Kubernetes

Kubernetes gives you the primitives to make placement explicit.

  • Topology labels. Cloud providers set the well-known labels topology.kubernetes.io/region and topology.kubernetes.io/zone on every node. A required node affinity on those labels keeps Pods on EU nodes.
  • Storage topology. A StorageClass with allowedTopologies and volumeBindingMode: WaitForFirstConsumer creates volumes only in the listed zones.
  • Admission policies. A ValidatingAdmissionPolicy, stable since Kubernetes 1.30, or a policy engine such as Kyverno or OPA Gatekeeper, rejects workloads that lack the EU affinity. Without this step, one missing selector places a Pod anywhere.
  • Encryption at rest. The KMS v2 provider encrypts Secrets and other objects in etcd with a key held in an external KMS. Whoever controls that key controls who can read stored copies of cluster data.

A minimal node affinity that allows only two EU regions looks like this:

yaml 
affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
            - key: topology.kubernetes.io/region
              operator: In
              values: ["eu-central-1", "eu-west-1"]

Region names differ per provider, so a multi-cloud cluster needs the EU region names of every provider in the list. Secrets management is covered in more depth in how to manage secrets in Kubernetes.

Residency by architecture vs residency by contract

Residency by contract Residency by architecture
How it works The provider promises to store data in the EU The system cannot place data outside the EU
What fails silently A new feature, region default or support process Very little: violations are rejected at admission or by bucket policy
Evidence for auditors Contract clauses and certifications Policies as code, admission logs, storage configuration
Who holds the keys Usually the provider You, in an external KMS or HSM

Most organizations need both. The contract defines liability. The architecture makes a breach of the contract hard to commit by accident. To test a provider’s claim, ask four questions: where the control plane and its backups run, which sub-processors receive data, where support and operations staff are located, and whether you can hold the encryption keys yourself.

For a broader look at sovereignty options and providers, see the guide to cloud sovereignty, data residency and portability.

How Cloudfleet handles residency

Cloudfleet runs each cluster’s control plane, data store and backups in the control plane region you choose, including europe-central-1a in Frankfurt, Germany, and all staff with production access are located in Germany. Your nodes, volumes and Pod logs stay on the infrastructure you choose, and Fleet constraints restrict node auto-provisioning to the regions you allow.

Next
What is the difference between data sovereignty and data residency? →
On this page