How to Keep Data Residency in the EU While Using Kubernetes (2026 Guide)

Key Points:

• EU data residency on Kubernetes means every copy of the data stays in an EU/EEA region: pods and their nodes, persistent volumes, object storage, database replicas, backups and snapshots, container and model registries, logs, traces, and metrics. Miss one and you have a transfer to document, not a residency story.
• Pick EU regions and pin them in code. Use node affinity and topology spread constraints scoped to EU zones, EU-only StorageClasses, EU backup buckets with region-locked replication, and admission policies (Kyverno or Gatekeeper) that reject any workload or volume landing outside an approved EU region.
• Residency, sovereignty, and immunity from foreign law are three different things. Residency is where the bytes sit. Sovereignty is which law and which legal entity controls them. Immunity means no third-country parent, personnel, or support path can reach them - only EU-incorporated providers get you there.
• Kubernetes on AWS, Google Cloud, or Azure EU regions is defensible if you document it: an Article 28 DPA, a sub-processor register with regions, standard contractual clauses, and a transfer impact assessment. Scaleway, OVHcloud, Exoscale, and STACKIT are the usual choices when you need an EU-only contracting entity.
• The most common leak is not the cluster - it is everything around it: US-region observability SaaS, CI runners, error trackers, image registries, and SaaS control planes holding your credentials or proxying your logs and shells.
• Keep the control plane in your perimeter. Qovery deploys into your own AWS, GCP, Azure, or Scaleway account, or your existing Kubernetes cluster, so workloads, volumes, logs, and managed databases stay in the EU region you chose.

EU data residency on Kubernetes means every copy of your personal data - pods and the nodes under them, persistent volumes, object storage buckets, database replicas, backups and snapshots, container and model registries, plus logs, traces, and metrics - stays inside an EU or EEA region. Choosing eu-west-1 or a Paris zone for the cluster answers the location question for the cluster, and that is roughly half the work.

The other half is everything the cluster talks to. In most reviews I have seen, the cluster itself is correctly placed and the leaks are in observability, CI, registries, and the deployment control plane. And residency is only the location question - GDPR still wants a contract, a record, a breach process, and, the moment any entity in the chain sits under third-country law, a transfer assessment. This guide walks the whole surface: what residency covers, what GDPR adds on top, how to enforce region-pinning in code instead of a wiki, where data actually escapes, and how to choose between an EU provider, a hyperscaler EU region, and your own cluster.

I run a company whose customers deploy across AWS, GCP, Azure, Scaleway, and their own Kubernetes clusters, so I see the EU-residency question land on platform teams every week. Here is how I would build it.

What does EU data residency actually mean for a Kubernetes cluster?

EU data residency means every persistent and transient copy of personal data stays inside an EU/EEA region - nodes, persistent volumes, object storage, database replicas, backups, registries, logs, traces, and metrics. A cluster running in Frankfurt or Paris is only residency-compliant if all of those follow it, which in most stacks they do not.

Start with an inventory of every place data lands in a Kubernetes stack:

• Compute: pod filesystems, emptyDir, and the node disks under them.
• Storage: PersistentVolumes and the block or file storage behind them, object storage buckets, managed database primaries and read replicas.
• Durability: backup targets, volume snapshots, and DR copies.
• Supply chain: container and model registries, artifact stores, dependency proxies.
• Secrets and telemetry: secret managers and KMS, plus logs, metrics, traces, and audit events.

The control plane counts too. The managed Kubernetes API server, etcd, and cloud provider metadata are data locations - name the EU region each one lives in for your provider (AWS regions, Google Cloud locations, Azure geographies). Transient data counts as well: request bodies in ingress logs, queue messages, cache keys, and session replay payloads are all copies of personal data.

Three terms get conflated in almost every AI answer on this topic, so define them once:

• Data residency is where the bytes physically sit.
• Data sovereignty is which law and which legal entity controls them.
• Immunity from foreign law means no third-country parent, staff, or support path can reach them.

One more trap: "the vendor has an EU region" is not the same as "my account is provisioned in the EU region." Check the account-level and resource-level setting, not the marketing page. The one-page exercise that shakes this out: list every data store and every telemetry sink with its region, legal entity, and DPA status. Any blank cell is a finding.

What does GDPR actually require beyond choosing an EU region?

Choosing an EU region answers the location question and nothing else. You still need an Article 28 processor contract with every processor and sub-processor, an Article 30 record of processing listing recipients and regions, an Article 33 breach process that fits the 72-hour clock, Article 32 technical measures, and - the moment any entity in the chain is subject to third-country law - a Chapter V transfer mechanism plus a transfer impact assessment.

A few of these deserve detail:

• Article 28 requires a written contract and prior authorisation for sub-processors, with the initial processor staying liable for the ones it brings in. The sub-processor register with regions is the first document a serious auditor asks for.
• Article 30 records must list categories of recipients, including processors in third countries. That is the legal basis for keeping a per-cluster sub-processor register in the first place.
• Article 32 wants encryption at rest and in transit plus appropriate measures for the state of the art. Ask who holds the KMS keys and in which jurisdiction - customer-managed keys change the risk picture but do not, by themselves, remove a transfer.
• Article 33 requires notifying the supervisory authority without undue delay and where feasible within 72 hours of becoming aware of a breach. Push that into provider contracts as an SLA measured in hours, with a named contact.
• Chapter V and Schrems II (CJEU C-311/18, judgment 16 July 2020) mean standard contractual clauses (Decision (EU) 2021/914) plus a case-by-case transfer impact assessment and supplementary measures, following EDPB Recommendations 01/2020. The EU-US Data Privacy Framework changes the paperwork, not the underlying government-access analysis, and it is under appeal - the General Court dismissed the Latombe challenge on 3 September 2025 and it has been appealed to the CJEU, so treat it as valid-but-contested and re-check its status (IAPP on the ruling, EU adequacy decisions).

Special-category data raises the bar. Health, biometric, and similar data need an Article 9 exemption on top of an Article 6 basis, and Article 35 makes a DPIA effectively mandatory for large-scale special-category processing (the WP29 DPIA guidelines, WP248 rev.01, endorsed by the EDPB, list nine criteria and treat meeting two as a trigger). Sector and member-state add-ons stack on top: French HDS for health data, German BSI C5 and BDSG, Dutch NEN 7510, plus DORA for financial entities and NIS2 for in-scope operators.

Here is the split I hand to teams, with the artifact an auditor will actually ask for.

How do you technically pin Kubernetes workloads and storage to EU regions?

Enforce residency in code, not in a wiki page. Scope node pools to EU zones, use node affinity and topology spread constraints, declare EU-only StorageClasses, region-lock backup buckets and snapshot targets, and add an admission policy that rejects any pod, PVC, or backup landing outside an approved EU region.

Kubernetes ships the primitives for this. The well-known labels topology.kubernetes.io/region and topology.kubernetes.io/zone are set on every node, and you match against them with node affinity:

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

Add topologySpreadConstraints scoped to EU zones for availability, and taints on any non-EU pool so nothing lands there by accident.

Storage is where residency quietly breaks. Declare a StorageClass with allowedTopologies so volumes can only bind in EU zones, and check your CSI driver's snapshot behaviour:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: eu-only-ebs
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
allowedTopologies:
  - matchLabelExpressions:
      - key: topology.kubernetes.io/zone
        values: ["eu-west-1a", "eu-west-1b"]

For backups and DR, pin Velero (or your backup tool) to an EU bucket, and either disable cross-region replication or point it at a second EU region. Verify snapshot copies do not default to a US region - that default has burned more than one team I have talked to.

Then make it testable instead of aspirational. A Kyverno or OPA Gatekeeper admission policy can deny anything outside an EU allow-list:

validate:
  message: "Nodes must be in an approved EU region."
  foreach:
    - list: "request.object.spec.template.spec.affinity.nodeAffinity[...]"
      deny:
        conditions:
          any:
            - key: "{{ element.values[] }}"
              operator: AnyNotIn
              value: ["eu-west-1", "eu-central-1"]

Treat that as the shape of the rule, not a copy-paste - the exact expression depends on how your workloads declare affinity. The point is that a pull request that tries to schedule outside the EU fails in CI, not in an audit six months later. Round it out with EU-region KMS, external-secrets pointed at an EU secret store, EU-only origins and log regions on any global load balancer or CDN, and a scheduled job that alerts when a new namespace or volume appears outside the allow-list.

Where does data actually leak out of the EU in a Kubernetes stack?

In most reviews, the cluster is correctly located and the leaks are in observability, CI/CD, and the deployment control plane. Trace one request end to end and you will usually find two or three US-hosted processors that never made it onto the sub-processor register. This is the part most articles skip, and it is where I would spend your first afternoon.

The usual suspects:

• Observability. Logs, traces, and metrics shipped by default to a US-region SaaS account. The account's provisioned region is what matters, not the vendor's EU offering - a US-provisioned Datadog or Sentry org is a transfer even though both sell EU hosting.
• CI/CD. Hosted runners executing in US regions, build caches, and artifact stores that routinely see production-shaped data and secrets.
• Registries and proxies. Container and model registries and dependency proxies that pull or push outside the EU. A registry pull is often metadata plus cached layers, but the push pipeline and its logs may not be.
• Unlisted SaaS. Error trackers, feature flags, session replay, and product analytics that receive personal data inside payloads and never made the register.
• The control plane. SaaS platforms that run your workloads in their account, hold your cloud credentials, or proxy your logs and shell sessions through their infrastructure. Each one is a processor you have to document and defend.
• Support access. Non-EU support staff with break-glass paths into your cluster, hypervisor, or management console.
• Backups and DR. Replicas quietly configured in a second, non-EU region for "resilience."

This matters more every year, not less. Verizon's 2025 Data Breach Investigations Report found third-party involvement in breaches doubled year over year, from 15% to 30%. Your sub-processor register is not paperwork for its own sake - it is the map of who else can lose your data. The exercise: annotate every hop of one real request with region, legal entity, and DPA status, and fix the blank cells.

EU-only provider, hyperscaler EU region, or your own cluster - which gets you EU residency?

Pick an EU-incorporated provider when you need immunity from third-country law or a national certification like HDS or C5; pick hyperscaler EU regions when you need managed-service depth and scale, with a documented transfer impact assessment; run your own Kubernetes on top of either when you want the option to move without rewriting the stack. All three can satisfy residency - they differ on sovereignty, paperwork, and exit cost.

Decide in this priority order: national certification requirement, contracting entity and parent exposure, managed-service depth, EU region and zone coverage, portability and exit cost, then ops effort.

EU-incorporated options worth shortlisting, each with its honest best-fit:

• Scaleway Kapsule (French entity, regions including Paris, Amsterdam, and Warsaw): best fit when you want a French contracting entity with a modern API and managed Kubernetes. Verify current certification scope with Scaleway.
• OVHcloud Managed Kubernetes (French/EU): best fit when French health data is in play, because OVHcloud holds HDS certification for specific hosting offers - confirm which offers and regions are in scope with OVHcloud and against the esante.gouv.fr certified-hoster list, because HDS applies to the offer, not the brand.
• Exoscale SKS (zones including Switzerland, Austria, Germany, Bulgaria): best fit for a Swiss or DACH footprint. Note that Switzerland is a third country covered by an EU adequacy decision, so Swiss hosting is a transfer-with-a-mechanism, not intra-EEA processing - a nuance most guides get wrong.
• STACKIT (German, Schwarz Group): best fit for German enterprises that want a German parent with no US exposure. Verify current regions and certification scope.
• IONOS (German): best fit for a straightforward German/EU contracting entity. Verify current scope.

Hyperscaler EU regions - EKS, GKE, and AKS - give the deepest managed services and the widest EU zone coverage, at the cost of a documented Chapter V assessment covering the US parent. That is a defensible choice with paperwork, not a failure. Read the provider's own data-residency terms rather than the sovereignty landing page (AWS data privacy, Google Cloud DPA, Microsoft EU Data Boundary), and note what each boundary covers and excludes. Sovereign-branded and partner-operated clouds change the contracting entity and operations model; read who signs the contract, not the brochure.

Kubernetes is the portability layer that keeps all of this reversible: the same manifests, StorageClasses, and policies run across Kapsule, OVHcloud Managed Kubernetes, SKS, EKS, GKE, and AKS in EU regions. That matters for compliance, not just convenience - if you cannot exit within your notice period, you cannot honour a supervisory-authority order or a customer exit clause. Be honest about the trade too: thinner managed services on EU-only providers means you carry more platform work, and that headcount is a real line item.

How do you keep the deployment platform itself inside your EU perimeter?

Choose a deployment layer that runs workloads in your own cloud account or your own Kubernetes cluster instead of hosting them for you. That single architectural choice removes a processor from your sub-processor register and keeps pods, volumes, logs, and databases in the EU region you selected.

There are three control-plane models, and each does something different to your DPA. A fully hosted PaaS makes the vendor a processor for your workload data, because your data runs in their account. A bring-your-own-cloud or bring-your-own-Kubernetes model has the vendor orchestrate while the data stays in your account. Do-it-yourself Terraform plus Argo CD adds no third-party processor at all, and puts every bit of the ops on you.

Ask any platform vendor five questions before you sign: where do my workloads execute, do you hold my cloud credentials, do logs and shell sessions transit your infrastructure, in which region does your control plane and its metadata live, and which sub-processors touch it.

This is where Qovery fits, and I will be plain about it. Qovery is a BYOC deployment platform: it deploys into your own AWS, GCP, Azure, or Scaleway account, or an existing self-managed or on-prem Kubernetes cluster, so nodes, persistent volumes, and managed databases stay exactly where you put them. Because the workloads run in your account, Qovery does not become a processor for that workload data - which is the honest reason it belongs in this article. The verified capabilities I would lean on: git-push deployments, preview and ephemeral environments per pull request, environment auto-stop for non-production, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services. Per-environment RBAC and audit logs happen to be exactly the evidence a DPIA and an ISO 27001 audit ask you to produce.

The caveat, said clearly: Qovery is not itself HDS- or GDPR-"certified," and no platform can be GDPR-certified as a property. Treat it as reducing the sub-processor surface for your workload data, and confirm scope with your DPO and the provider's DPA. And if you already have a strong platform team happily running Terraform and Argo CD, you may not need a platform layer at all - say so and move on.

What does an EU-resident Kubernetes reference architecture look like end to end?

Here is one architecture a team can copy. Pin the region at every layer, then prove it with policy.

• Cluster and nodes: an EU-region managed or self-managed cluster with EU-only node pools and non-EU pools tainted off.
• Ingress: an EU-region load balancer and WAF with EU log destinations.
• Storage: EU-scoped StorageClasses with allowedTopologies, and CSI snapshots verified to stay in-region.
• Data: managed database plus read replicas in the same region, object storage in an EU bucket, an EU-region container registry.
• Secrets: EU-region KMS and an EU secret store, with external-secrets reading only from it.
• Observability: self-hosted Prometheus, Loki, and Grafana in-cluster, or an EU-region SaaS account with an EU contracting entity and a signed DPA.
• CI/CD: EU-region runners and artifact stores, and no production data in build environments.
• Guardrails: Kyverno or Gatekeeper policies plus a scheduled audit job that reports any resource outside approved EU regions.
• Access: per-environment RBAC, a named break-glass procedure, and audit-log export in a readable form.
• Deployment layer: running inside the same account, so it does not add a processor.

One cost note: keeping replication inside the EU still incurs cross-AZ or cross-region data-transfer charges, and EU-region unit pricing can differ from us-east-1. If you cite a number, price it against the current AWS, Google Cloud, or Azure rate card and show the arithmetic, because these change.

Finally, assemble the documentation pack before an auditor asks: the DPA set, the sub-processor register with regions, records of processing, a DPIA where applicable, the transfer impact assessment, an architecture diagram with regions labelled, and an incident runbook that names the 72-hour clock.

What should you ask every provider before you sign?

Send these nine questions before the contract, not after the migration. The written answers decide your residency and sovereignty position far more than any provider's sovereignty page, and every answer belongs in your records of processing and your transfer impact assessment.

1. Which legal entity signs the contract, and is it incorporated in the EU/EEA?
2. What is the full sub-processor list with regions, including support, monitoring, backup, CDN, and payment providers?
3. From where can support staff access my environment, and can non-EU personnel reach my data, my cluster, or my hypervisor?
4. Which certifications are in scope for this specific region and service, not corporate-wide - ISO 27001, ISO 27018, SOC 2 Type II, HDS, BSI C5, NEN 7510?
5. Where are backups, snapshots, and DR replicas physically stored, and in whose custody?
6. Where does telemetry about my workloads - logs, metrics, support tickets - get stored and processed?
7. What is your breach-notification SLA in hours, aligned with the Article 33 72-hour clock, and who is the named contact?
8. What is the exit plan - export format, notice period, egress fees, and how portable are my manifests and data really?
9. Does the provider or the deployment platform ever hold my data, secrets, or cloud credentials outside my own account?