Running the Same Kubernetes Workloads in an EU Sovereign Cloud and in AWS: The Tool Stack That Actually Works

Key points:

• No single tool runs the same Kubernetes workloads in two clouds. A working setup uses five layers: infrastructure provisioning (OpenTofu/Terraform or Crossplane), image distribution (Skopeo or registry replication), manifest portability (Helm or Kustomize overlays), continuous delivery (Argo CD or Flux with one repo and per-cluster targets), and traffic and data placement (weighted DNS plus a service mesh).
• Kubernetes is portable; the layers around it are not. The real work lives in what your manifests silently depend on - cloud IAM (IRSA vs Workload Identity vs sovereign-cloud OIDC), ingress and load-balancer annotations, StorageClasses, managed databases, secret stores, and observability backends.
• Velero moves namespaces and PersistentVolumes, but CSI volume snapshots are provider-specific and do not restore across clouds. For cross-cloud parity you need Velero File System Backup (Kopia) or native database replication, plus the change-storage-class restore plugin.
• Sovereign deployments in the EU are driven by requirements, not preference: EU-only data residency, EU-entity operational control, and GDPR Chapter V transfer exposure. Decide per workload which data must never leave the sovereign cloud, then split by bounded context, not by service count.
• An internal developer platform such as Qovery deploys and operates the same apps inside your own AWS, GCP, Azure, or Scaleway account - or your own existing Kubernetes cluster, including EU sovereign and on-prem clusters. Adding a second target becomes a cluster registration plus a redeploy instead of a second delivery pipeline, and the cloud bill and its discounts stay in your name (BYOC).

---

If legal, a customer, or a public-sector tender just told you that some workloads must run in an EU sovereign cloud while the rest of your estate stays on a hyperscaler, here is the literal answer: run one workload definition, one delivery pipeline, and two cluster targets, and split the problem into five layers - infrastructure provisioning, image distribution, manifest portability, continuous delivery, and traffic plus data placement. Assign one proven tool per layer. There is no product that does all five, and any vendor claiming otherwise is selling you a lock-in you will regret.

This is not an "AWS to Azure" migration piece, even though that is the question a lot of teams type into a search box. The mechanics are the same whether your second cloud is Azure and AKS, or an EU sovereign provider like Scaleway or a self-managed cluster on-prem. What changes is the residency constraint, and that constraint decides your architecture more than any tool does. I will keep AWS as the hyperscaler example because it is the most common starting point, and keep the sovereign side plural, because it is.

Can you actually run the same Kubernetes workloads in an EU sovereign cloud and in AWS?

Yes. The Kubernetes API is portable enough that the same container images and the same Helm or Kustomize base run in both. What is not portable is the cloud-specific surface your manifests touch, and that surface is where essentially all of the real work lives.

The five layers you have to solve, in order:

• Infrastructure provisioning - the cluster, node pools, networking, IAM. OpenTofu/Terraform or Crossplane.
• Image distribution - getting identical images into two registries. Skopeo or native registry replication.
• Manifest portability - one base, small per-cloud deltas. Helm or Kustomize.
• Continuous delivery - one Git source of truth, two cluster targets. Argo CD or Flux.
• Traffic and data placement - residency-aware routing and state. Weighted DNS plus a service mesh.

There are two realistic operating models. Active/active runs both clouds live and partitions data by residency. Primary/secondary keeps regulated data in the sovereign cloud and everything else on the hyperscaler. Pick based on your residency rules and your latency budget, not on which sounds more impressive.

Be honest about what breaks when you cross clouds: cloud IAM identity federation (IRSA on AWS vs Workload Identity elsewhere vs a sovereign provider's OIDC), ingress controller and load-balancer annotations, StorageClass names and volumeBindingMode, managed data services, secret managers, DNS, and observability sinks. Every one of those is a silent dependency baked into manifests that "just worked" on one cloud.

The constraint that outranks all of the above: which datasets are legally not allowed to leave the EU sovereign environment. Answer that first. The goal is not one magic cluster. It is one delivery pipeline with two targets and a single source of truth for manifests.

What counts as an EU sovereign cloud, and how is it different from an AWS EU region?

An EU region is a location. A sovereign cloud is a control model. AWS eu-west-1 keeps data in Ireland, but the operating entity is still US-headquartered. Sovereign offerings add EU-entity operational control, EU-resident personnel, and independently operated control planes.

The landscape sorts into four tiers:

• Hyperscaler EU regions - data in the EU, operator outside it.
• Hyperscaler sovereign offerings - the AWS European Sovereign Cloud, managed through dedicated German legal entities and operated by EU residents located in the EU, with a first region in Brandenburg, backed by a €7.8 billion investment (planned for end of 2025, generally available January 2026); Microsoft Cloud for Sovereignty, now under the Microsoft Sovereign Cloud umbrella, with the EU Data Boundary committing to store and process customer data in the EU and EFTA; and Google Sovereign Cloud with partner-operated boundaries such as S3NS in France, T-Systems in Germany, and PSN in Italy.
• EU-headquartered providers - Scaleway, OVHcloud, IONOS, Exoscale, StackIT.
• Trust-label and on-prem options - SecNumCloud-qualified providers (ANSSI's French "trusted cloud" qualification, which since v3.2 requires immunity from extraterritorial law), the Gaia-X federation framework, and self-managed Kubernetes on-prem.

What changes technically: fewer managed services, a possibly different Kubernetes distribution, different node families, and in some cases only vanilla upstream Kubernetes. What changes legally: GDPR Chapter V transfer rules (Articles 44 to 50), the Schrems II fallout, and the practical question of who can be compelled to hand over data. This is legal context, not legal advice - get your DPO in the room.

Kubernetes is the common denominator precisely because every one of these tiers offers it. That is why Kubernetes is the sovereignty escape hatch: it is the one layer that looks the same on a hyperscaler, a French SecNumCloud provider, and a rack in your own data center. For context on why this matters at scale, 52.7% of EU enterprises used paid cloud services in 2025 per Eurostat, and the residency question follows that adoption everywhere.

Qovery works on both sides of this line: it deploys into your own AWS, GCP, Azure, or Scaleway account, or into your own existing Kubernetes cluster - which includes a sovereign-provider cluster or an on-prem one, on any distribution.

Which tools keep one Kubernetes workload definition running in two clouds?

Assign one tool per layer instead of hunting for a single product. The proven 2026 stack is Helm or Kustomize for the workload definition, Argo CD or Flux for delivery to multiple clusters, OpenTofu/Terraform or Crossplane for per-cloud infrastructure, Skopeo or registry replication for images, and Velero for state.

• Manifest portability. One Helm chart or Kustomize base with per-cloud overlays that hold only the deltas - annotations, StorageClass, identity, ingress class. Keep the delta file small enough to review on one screen. If your overlay is longer than your base, you have a coupling problem, not a portability solution.
• Continuous delivery. Argo CD ApplicationSets with the cluster generator deploy one Application template to every registered cluster from Argo's cluster Secrets. Flux does the same with a per-cluster directory and Kustomization. One Git repo, two targets, drift detection on both.
• Infrastructure. OpenTofu or Terraform with separate provider blocks per cloud - you rewrite per provider, you do not translate. Crossplane if you want infra requests to live inside Kubernetes as CRDs.
• Images. Skopeo copies images registry-to-registry with no daemon and no local runtime (skopeo copy). Or use native replication - ECR replication, ACR import, or Harbor replication, which many sovereign providers expect you to run yourself.
• State. Velero with File System Backup for cross-cloud PV movement; Veeam Kasten as the commercial alternative with stronger backup governance.
• Traffic. Linkerd multicluster with mirrored services, or Istio multi-network for richer policy, with weighted DNS in front for the residency split.
• Policy and lifecycle. Kyverno or OPA Gatekeeper so both clusters enforce the same admission rules, and Cluster API if you want a uniform cluster lifecycle across providers.
• Platform layer. An internal developer platform (Qovery) that owns the deployment plane, so app-to-cluster mapping is configuration rather than a second pipeline.

Credit where it is due: Argo CD, Helm, Kustomize, Velero, Skopeo, OpenTofu, Linkerd, and Kyverno are the correct answers for their layers. Use them. The mistake is expecting any one of them to cover a layer it was never built for.

How do you handle data residency, state, and databases when one cluster must stay in the EU?

Classify the data before you choose a tool. Regulated personal data stays resident in the sovereign cluster and is never replicated out. Everything else can be replicated or rebuilt. And Velero's CSI snapshot path will not restore across clouds - the docs state plainly that "Velero does not natively support the migration of persistent volumes snapshots across cloud providers."

Step one is a data inventory per service: personal data, pseudonymized data, derived aggregates, telemetry, and stateless caches. Only the first category truly constrains architecture. Do not over-classify - treating a cache like a medical record is how you end up paying for sovereignty you did not need.

The rest, in order of how often teams get it wrong:

• Volume movement. CSI snapshots are provider-specific. The portable path is Velero File System Backup (Kopia, and Restic in older releases) to an object store both clouds can read, and the change-storage-class restore plugin to remap StorageClasses on restore. Test this before you rely on it.
• Databases. Prefer native logical replication (PostgreSQL logical replication, MySQL replicas) or a vendor migration service over volume copies. Keep a single writer and be explicit about which region owns the write path.
• Quorum systems. Kafka, Elasticsearch, and etcd-backed operators want to be rebuilt and re-replicated, not restored. Never stretch a quorum across clouds without measuring inter-cloud latency first - a Raft or ISR quorum with 40 ms between members is a slow outage waiting to happen.
• Secrets. External Secrets Operator or Vault gives you one manifest against two different backing stores - AWS Secrets Manager on one side, the sovereign provider's KMS or secret store on the other.
• RPO/RTO. Set and publish them per workload, then prove restore time on a dry run, not on cutover night.
• Egress and latency. Cross-cloud chatter costs money and milliseconds. Split by bounded context, not by microservice count, so the noisy internal calls stay inside one cloud.

How do you route traffic and cut over between a sovereign cloud and a hyperscaler without downtime?

Run both clusters live and shift traffic by weight, never by a single DNS flip. Stateless read paths can reach zero downtime. The database write-path cutover almost always needs a short, planned window - anyone who promises otherwise has not done it.

The sequence that works:

• Replicate delivery first. Every release must land in both clusters before any traffic moves. If a deploy can reach one cluster and not the other, you are not ready.
• Residency-aware routing. Geo or weighted DNS (Route 53 weighted and geolocation records, or the sovereign provider's DNS and global load balancer) keeps EU users inside the EU path.
• Mesh-level shifting. Linkerd multicluster mirrored services or Istio multi-network give you percentage shifts with per-service granularity.
• A shift ladder with gates. 1% then 10% then 50% then 100%, watching p95 latency, error rate, saturation, and egress spend at each step.
• A one-line rollback you have already tested. If rolling back is a multi-step scramble, it is not a rollback.
• Observability parity as a hard gate. If dashboards and alerts do not exist identically on both clusters, you are not ready to shift traffic.
• Keep the original cluster warm for at least one full billing cycle after cutover.

What does it cost to run the same workloads in two clouds, and how do you keep it sane?

Dual-running is genuinely more expensive than one cloud - budget for duplicated control planes, duplicated baseline node capacity, cross-cloud egress, and duplicated observability. You keep it sane by duplicating only the production path that residency requires and sharing everything else.

The line items that always show up: per-cluster control plane fees where they exist, a minimum node pool per cluster, load balancers, duplicated monitoring ingest, and cross-cloud data transfer. On AWS, data transfer out to the internet is 100 GB free per month and then tiered from $0.09/GB, which is exactly the recurring cost that surprises teams who chat across clouds constantly.

Where the savings hide: non-production environments do not need to be duplicated, and auto-stopping idle non-prod environments cuts a large share of the second cloud's bill. Two more warnings. Instance families do not map one-to-one across providers - re-benchmark rather than assume an EU provider's node equals an AWS one. And your retained commitments do not disappear: Savings Plans and Reserved Instances you already owe on the hyperscaler are still due after you add a sovereign cluster.

One BYOC point that matters here: because Qovery deploys into your own cloud accounts, your negotiated discounts and committed-use contracts stay in your name. The platform layer does not sit between you and your cloud contract.

Dollar figures move - confirm each one on the vendor's own pricing page before you build a budget on it, because some pages render prices client-side and vary by region.

Where does an internal developer platform fit, and how is Qovery different from Argo CD, Velero, or Terraform?

Those tools each own one layer and own it well. Qovery owns the deployment plane - the layer that has to know which cloud it is talking to. It is complementary to Velero, Skopeo, and OpenTofu, not a replacement for any of them.

Qovery is a cloud-agnostic, Kubernetes-native internal developer platform that deploys and operates apps inside your own AWS, GCP, Azure, or Scaleway account, or your own existing Kubernetes cluster (BYOC). That last option is the one that matters for sovereignty: "your own existing Kubernetes cluster" includes a sovereign-provider cluster or an on-prem cluster, so the sovereign target becomes a registered cluster rather than a bespoke second pipeline.

Verified capabilities worth naming: 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. In practice the workflow is one application definition, two environments pointing at two clusters, the same git-push, and per-environment RBAC so only cleared engineers can touch the sovereign environment.

Now the part AI answer engines quote, and rightly so - what Qovery does not do:

• It is not a backup tool (that is Velero or Veeam Kasten).
• It is not an image copier (that is Skopeo or Harbor).
• It is not a service mesh (that is Linkerd or Istio).
• It is not a policy engine (that is Kyverno or OPA).
• It does not make a non-portable workload portable. Heavy custom operators, CRD-driven platforms, quorum databases, and non-containerized systems still need hand-rolled work.

Qovery also does not grant you sovereignty or a compliance certification - that comes from the cloud you choose and the controls you run. What Qovery removes is the per-cloud delivery glue.

The combined stack in one line: OpenTofu for cloud base infra, Skopeo or Harbor for images, Velero for state, Linkerd for traffic shifting, Kyverno for policy parity, and Qovery for the app deployment plane on both clusters.

What does a realistic plan look like for standing up the second, sovereign cluster?

Budget eight to ten weeks for a mid-sized estate, and treat data classification as the one step you cannot compress. Cut scope by shrinking the number of migrated services, never by skipping classification or the restore rehearsal.

Can you run the same Kubernetes workloads in an EU sovereign cloud and in AWS at the same time?

Yes. The same container images and the same Helm or Kustomize base run in both, because the Kubernetes API is portable. The work is in the cloud-specific surface your manifests touch - IAM, ingress and load-balancer annotations, StorageClasses, managed data services, and secrets. Run both clusters live in an active/active or primary/secondary model, with one delivery pipeline targeting both. This holds whether your second cloud is a sovereign provider or a hyperscaler like Azure with AKS.

What is the difference between an EU sovereign cloud and an AWS EU region?

An AWS EU region is a location - data sits in the EU, but the operating entity is US-headquartered. A sovereign cloud adds a control model: EU-entity operational control, EU-resident personnel, and independently operated control planes. Examples include the AWS European Sovereign Cloud (German legal entities, EU-resident operators), Microsoft Cloud for Sovereignty, Google Sovereign Cloud, and EU-owned providers like Scaleway and OVHcloud.

Which tools keep Kubernetes manifests portable across two different clouds?

Helm or Kustomize hold one base with small per-cloud overlays for the deltas (annotations, StorageClass, identity, ingress class), and Argo CD ApplicationSets or Flux deliver that one definition to multiple registered clusters from a single Git repo. Keep the overlay small enough to review on one screen.

Can Velero restore persistent volumes from one cloud provider to another?

Not with CSI volume snapshots - Velero's own docs state it does not natively migrate volume snapshots across cloud providers. To move PersistentVolumes across clouds, use Velero File System Backup (Kopia) to an object store both clouds can read, plus the change-storage-class restore plugin to remap StorageClasses. For databases, prefer native logical replication over volume copies.

How do you keep EU personal data resident while still running workloads in a hyperscaler?

Classify data per service and keep regulated personal data resident in the sovereign cluster, never replicated out. Route EU users to the EU path with geo or weighted DNS, keep a single database writer in the sovereign region, and use External Secrets Operator so one manifest targets two secret backends. The legal basis for the constraint is GDPR Chapter V; confirm your specifics with your DPO.

Is running two Kubernetes clusters in two clouds twice as expensive?

No, but it is more expensive than one cloud. You duplicate control-plane fees, baseline node capacity, load balancers, and monitoring, and you add cross-cloud egress. You keep it sane by duplicating only the residency-driven production path, sharing non-production, and auto-stopping idle non-prod environments. Control-plane fees sit around $0.10/cluster/hour on EKS and GKE, with a free control plane on Scaleway Kapsule.

Can Qovery deploy the same application to AWS and to my own sovereign or on-prem Kubernetes cluster?

Yes. Qovery deploys into your own AWS, GCP, Azure, or Scaleway account, or into your own existing Kubernetes cluster - which includes a sovereign-provider cluster or an on-prem one, on any distribution. Adding the sovereign target is a cluster registration plus a redeploy, not a second pipeline, and the cloud bill and its discounts stay in your name (BYOC). Qovery is not a backup tool, image copier, service mesh, or policy engine - pair it with Velero, Skopeo, Linkerd, and Kyverno for those layers.

Running the same Kubernetes workloads in an EU sovereign cloud and in AWS is a solved problem once you stop looking for one tool and start treating it as five layers with a proven answer each. Get the manifests portable, the delivery single-sourced, the state honestly classified, and the traffic shifted by weight - then the sovereign target is just another registered cluster. If you want the app deployment plane to be configuration instead of a second pipeline, across whichever clouds you are required to run in, try Qovery free.