UAE cloud sovereignty rules in 2026: how to deploy Kubernetes workloads for Gulf customers

Key points:

• The "new rules" are mainly the UAE Cyber Security Council's National Cloud Security Policy v2.0, published in September 2025 to replace the May 2023 version, with its official page updated in June 2026. It sets three tiers of requirements: Baseline Secure Cloud for all cloud providers, Partial Sovereign Cloud for data classified Confidential/Restricted, and Sovereign Cloud for data above that.
• Data classification decides which sovereignty tier applies. Cloud consumers in scope have to classify their data, work out which tier it triggers and confirm their providers meet the matching localisation, encryption key, foreign access and incident reporting obligations. Sector rules stack on top: the Central Bank requires banks to keep their Master System of Record, including all Confidential Data, in the UAE.
• For Kubernetes, "in-country" covers more than the cluster. Nodes and persistent volumes, container images, encryption keys, backups, logs, metrics, CI runners, support access and any SaaS control plane all have to be mapped. A cluster in me-central-1 that ships logs to a US observability SaaS is not a UAE-only deployment.
• In-country hyperscaler capacity is thin, and 2026 tested it. AWS has one UAE region and Azure has two; Google Cloud's nearest regions are Doha and Dammam. After the March 2026 strike on AWS's UAE facilities, AWS said it could not restore resources held only in one zone and advised customers to restore from backups in other regions. For data that must stay in the UAE, the resilience plan has to stay in the UAE too, which means multi-zone at minimum and a second in-country provider for critical systems.
• Portable Kubernetes in your own account is the practical answer for most tiers. Qovery runs your applications on Kubernetes inside your own AWS, Azure, GCP or Scaleway account, or an existing in-country cluster, so workloads, data, logs and backups stay where you put them. Its control plane is a separate SaaS that holds configuration, so for the Sovereign tier you have to assess it like any foreign-operated service, and it may not fit.

Every Gulf deal we see now comes with the same question in the security questionnaire: "Where exactly does our data live, and who can access it from outside the country?" For a long time the honest answer for most SaaS vendors was "in Frankfurt, mostly". In the UAE, that answer has stopped working for a growing share of customers.

The UAE has tightened its cloud rules in layers: a national cloud security policy with explicit sovereignty tiers, a federal data protection law, sector regulators with their own localisation rules, and, since June 2026, a new federal authority for AI and data. None of them mention Kubernetes; they say where data, keys and operations must sit. Below I translate that into decisions about clusters, regions, storage, keys, logs and control planes.

I am not a lawyer, and nothing here is legal advice. Where I could only confirm a detail through a law firm's summary rather than the regulator's own text, I say so.

What are the UAE's new cloud data sovereignty rules?

The core instrument is the National Cloud Security Policy issued by the UAE Cyber Security Council. Version 2.0 was published in September 2025, updating the first version from May 2023, and the official government page was last updated on 18 June 2026 (UAE Government portal; Cyber Security Council).

The policy sets three tiers of requirements, as described by the Council and by Al Tamimi & Company's analysis:

• Baseline Secure Cloud Requirements: the foundation every cloud service provider has to meet.
• Partial Sovereign Cloud Requirements: additional requirements for providers storing or processing data classified as Confidential/Restricted.
• Sovereign Cloud Requirements: the strictest controls, for data classified above Confidential/Restricted.

The government portal lists the policy domains that apply to cloud consumers: cloud governance, contractual agreements, data security and lifecycle management, data location and sovereignty, interoperability and portability, cloud architecture and virtualization, identity and access management, incident management and forensics, and cloud resilience. Providers get two more: cloud operation and maintenance, and integration with UAE initiatives (u.ae).

On data location, the portal's summary asks providers to "ensure that cloud consumers are aware about the location at which data is stored, processed, and managed from", and to "protect data with encryption and best practices for key management throughout its lifecycle". Al Tamimi's reading of v2.0 adds three points I would treat as the operational core:

• the location of data has to be known at all stages and handled under UAE law;
• in the Sovereign tier, foreign access requests to hosted data should be denied by default;
• cloud consumers in scope must classify their data, determine which tier it triggers and confirm their providers can meet the matching localisation, encryption, access request and incident reporting obligations.

The governance around these rules also moved in 2026. On 14 June 2026, the UAE approved a Federal Authority for Artificial Intelligence and Data that brings together the AI Office, the Information and Digital Government Sector of the TDRA and the Emirates Data Office, reporting to the Cabinet (WAM; The National). Expect data standards for federal entities to come from that authority.

Which UAE rules apply to my workload?

Several regimes overlap, and the strictest one that applies to a given dataset wins. A SaaS company serving a Dubai bank can be pulled into the bank's sector rules by contract even if no regulator ever writes to the SaaS company directly.

Sources: Cyber Security Council, UAE Government portal on data protection laws, US International Trade Administration on PDPL cross-border rules, CBUAE Rulebook, Article 6.

The Central Bank text is the most concrete in the whole stack. Article 6.1: "Banks must ensure that the Master System of Record, which includes all Confidential Data, is continuously maintained and stored within the UAE." Article 6.3: customer Confidential Data "must not be shared outside the UAE without Central Bank approval and obtaining prior written consent from the customer." Article 6.5: any outsourcing agreement with a party outside the UAE must ensure the bank and the customer keep ownership of the data and "that the Central Bank can access the Bank's data upon request" (CBUAE Rulebook).

If you sell to UAE banks, those three sentences will show up in your contract, whatever your own licence says.

Which hyperscaler regions actually keep data in the UAE?

AWS and Microsoft Azure have regions in the UAE; Google Cloud does not. That single fact shapes most architecture decisions for Gulf workloads.

Sources: AWS Regions list, Capacity on AWS's 2026 Middle East damage, Azure regions list, Google Cloud regions and zones, Google Cloud locations.

So if your customer requires UAE residency and your stack is on Google Cloud, you have two options: run that customer's workloads on AWS or Azure in the UAE (or on an in-country provider), or run Kubernetes on infrastructure in the UAE that you manage yourself. Kubernetes is what makes the first option cheap, because the same images and manifests run on EKS, AKS and GKE.

What did the 2026 AWS UAE incident change for in-country resilience?

It showed that "stay in the UAE" and "survive a regional disaster" pull in different directions, and that you have to plan for both. On 1 March 2026, objects struck an AWS data centre in the UAE, causing sparks and a fire; the fire department cut power and the mec1-az2 zone of me-central-1 went offline (Khaleej Times). AWS's advice at the time was to "use alternate Availability Zones or other AWS Regions where applicable".

In September 2026, AWS told customers it could not restore access to resources and data held only in mec1-az2, and advised them to "migrate all accessible resources to other Regions and restore inaccessible resources from remote backups as soon as possible", according to Capacity's reporting of AWS's status updates.

This was an act of war against physical infrastructure, not an engineering failure, and no provider designs a single site to withstand it. Our thoughts are with the teams in the region who have been working through it, at AWS and at their customers. It could have happened to any provider, in any conflict zone.

For engineering teams, three lessons follow:

• Zonal storage is a single point of failure. Block volumes are zonal. A database whose only copy sat on one zone's disks went with that zone.
• "Fail over to another region" may not be legal for your data. For Confidential/Restricted data, or a bank's Master System of Record, moving to Bahrain, Doha or Frankfurt is not a default option. Your disaster recovery target must itself be in the UAE.
• One in-country provider is a concentration risk. With one AWS region in the UAE, an in-country second site means Azure UAE North or UAE Central, a local sovereign cloud, or your own data centre.

This is the strongest argument I know for running portable Kubernetes rather than provider-specific services for UAE workloads. If your standby is a second cloud in the same country, your application has to run on both without a rewrite.

How do I keep a Kubernetes workload inside the UAE end to end?

You map every path data can take and pin each one to the UAE, then prove it. The cluster region is the easy part. Here is the list I walk through with teams, from the most obvious to the most often forgotten.

Cluster, nodes and storage

• Region and zones. Run the cluster in me-central-1 or Azure UAE North, with nodes spread across all three zones using topology spread constraints.
• Persistent volumes. Use storage classes bound to in-region zones, and never rely on a single zonal volume for data you cannot lose. Replicate databases across zones (for example a Multi-AZ managed database, or a replicated PostgreSQL operator).
• Backups. Back up to object storage in the UAE, and for critical data copy backups to a second in-country provider. Test restores before you need them.

Images, keys and secrets

• Container registry. Pull images from a registry in the same region (for example Amazon ECR in me-central-1 or Azure Container Registry in UAE North). Images rarely hold personal data, but a registry outside the country is a runtime dependency outside the country.
• Encryption keys. Create KMS keys in the UAE region. For partial sovereign and sovereign data, published analyses of v2.0 report that hosted keys and their backups must be generated, stored and managed in the UAE, and that consumers should assess whether they need to hold their own keys. Check the policy text for your tier. Cloud key management services offer external key store options if you must keep keys outside the provider.
• Secrets. Keep secret values in an in-region secret manager and give your deployment tooling references, not values.

Observability, CI and support access

• Logs, metrics and traces. Application logs are the most common leak of personal data out of a country. Run your log and metrics stack in the cluster or in-region, or confirm your observability vendor processes data in the UAE.
• CI/CD runners. Builds pull source code and sometimes test fixtures with real data. Use self-hosted runners in the UAE region for anything that touches production data.
• Support and operator access. "Foreign access" includes people. Know which operators, at your company, your cloud provider and your vendors, can reach production from outside the UAE, and log every session.

Network and egress

• Egress control. Default-deny egress with Kubernetes NetworkPolicies, and allow only known destinations. It is the only way to prove a pod is not sending data abroad.
• Edge and DNS. Global CDNs and DNS are designed to serve from everywhere. Decide what may be cached at edge locations outside the UAE, and keep personal data responses uncached.

Write this down as a data flow map per service. When a customer's security team or a regulator asks "where does this data go?", that map is the answer, and it is also what you test against.

Which tier can a Kubernetes platform in my own cloud account serve?

Running Kubernetes in your own account in a UAE region, with the controls above, covers Baseline and is a credible base for Partial Sovereign data. The Sovereign tier usually needs more: an in-country provider that meets the Council's sovereign requirements, keys under UAE-based control and no foreign-operated control planes in the path. This is my own reading of the tiers.

Sources for tier definitions: Cyber Security Council and Al Tamimi & Company. Read the policy PDF itself for the exact control wording that applies to your classification.

What about Saudi Arabia, Qatar and the rest of the Gulf?

Each Gulf state runs its own data protection and cloud regime, so "Gulf customers" means one deployment per jurisdiction that requires residency. Saudi Arabia has its own personal data protection law and national cybersecurity controls, and Google Cloud's Dammam region gives Saudi customers an in-country hyperscaler option that the UAE does not have on Google Cloud. I have not covered those regimes in detail here; check each regulator's own text before you commit.

The architectural pattern is the same everywhere: one standard Kubernetes deployment, repeated per country, each with its own region, keys, backups and logs. If the second or third country means rewriting the stack, you will lose deals to the vendor who can just stand up another cluster. We wrote about the EU version of this problem in how to keep data residency in the EU with Kubernetes, and about proving that portability works in a cloud portability drill.

Where does Qovery fit for UAE and Gulf deployments?

Qovery runs your applications on Kubernetes inside your own cloud account, so the data plane sits wherever you put it: AWS me-central-1, Azure UAE North or UAE Central, or an existing in-country cluster at a local provider or in your own data centre. Qovery is not a PaaS and never hosts your applications.

What that gives a team serving Gulf customers:

• One deployment model per country. The same applications, images and configuration deploy to a cluster in the UAE, another in Saudi Arabia and another in the EU. Environment cloning lets you start a new country from an existing environment.
• Any cluster, not only the big three. Qovery deploys to AWS, GCP, Azure and Scaleway, and to existing Kubernetes clusters (EKS, AKS, GKE, k3s, on-premise) through the Qovery Operator. In the UAE, the right answer for sovereign data is often an in-country provider.
• Data, logs and backups stay in your account. Workloads, databases, logs, metrics and TLS keys run in your cluster. Secret values can stay in your cloud's secret manager in-region, with Qovery holding only a reference (how that works).
• Evidence for the questionnaire. RBAC per environment, audit logs of every change, and OPA-based API Policy Tokens so AI agents deploy with a scoped, named identity.
• Runtime independence. Your cluster connects out to the Qovery control plane. If the control plane is unavailable, running services keep serving; only new deployments wait.

Where to be careful:

• The control plane is a SaaS outside your account. It holds configuration, environment metadata and any secrets you choose to store in it. For Baseline and most Partial Sovereign workloads, that is a normal third-party assessment. For the Sovereign tier, treat it like any foreign-operated service with access to your environment, and expect that it may not be acceptable.
• Qovery does not make you compliant. It helps you meet controls (region choice, your own account, audit logs, RBAC). Data classification, contracts and regulator relationships stay with you.
• Cross-cloud networking is not built in. A standby on a second in-country provider is configurable with VPN, Cilium Cluster Mesh, Tailscale or your own interconnect.

How do I set this up with Qovery from Claude Code or Cursor?

Install the Qovery Agent Skills and ask your coding agent to set up a cluster in your own account in a UAE region and deploy your services there. You approve each install command, and the MCP Server opens an OAuth login in your browser.

curl -fsSL https://skill.qovery.com/install.sh | bash

# 2. Or scope the skills to the current project only
curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

# 3. MCP Server for Claude Code over OAuth, read-only by default
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

# 4. Write access, only when you explicitly want it (also needs write access enabled in the Qovery Console)
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

Then ask in plain language: "set up Qovery on our AWS account in me-central-1" (the qovery-onboard skill), "deploy this app to the UAE cluster with Qovery" (qovery-deploy), or "generate Terraform for this environment so we can recreate it on Azure UAE North" (qovery-terraform). The skills deploy; the MCP Server operates what already exists. See the AI agent quickstart and the Claude Code integration.