CyphrQ
Menu

GCC Cloud Regions and Data Residency: Who Hosts Where

Which cloud providers list regions in the UAE, Saudi Arabia, Qatar and Bahrain as of 25 Oct 2026, and what local rules mean for where your data sits.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

11 min read

As of 25 October 2026, provider documentation lists GCC cloud regions in the UAE (AWS, Microsoft Azure, Oracle), Bahrain (AWS), Qatar (Azure) and Saudi Arabia (Oracle), and AWS says more are planned for Saudi Arabia. A region in your country does not by itself satisfy a data residency rule. The rule depends on the type of data, your sector and the regulator, so check both the map and the law.

Data residency means data is stored and processed in a stated country. It is different from data sovereignty, which asks whose law and whose control the data sits under. This post covers residency first and sovereignty in the practitioner section.

Which cloud providers have regions in the UAE, Saudi Arabia, Qatar and Bahrain?

I checked four providers' own documentation on 25 October 2026. The table lists only what those pages show. Where a page was silent, the row is absent rather than guessed.

Country Provider Region (code) Status as listed
UAE AWS Middle East (UAE), me-central-1 Listed as an available Region, 3 AZs, opt-in required
Bahrain AWS Middle East (Bahrain), me-south-1 Listed as an available Region, 3 AZs, opt-in required
Saudi Arabia AWS No region code listed AWS says it has "announced plans" for more Regions in the Kingdom of Saudi Arabia; no code or date shown
UAE Microsoft Azure UAE North, Dubai (uaenorth) Listed, 3 availability zones
UAE Microsoft Azure UAE Central, Abu Dhabi (uaecentral) Listed, access restricted to specific customer scenarios such as disaster recovery
Qatar Microsoft Azure Qatar Central, Doha (qatarcentral) Listed, 3 availability zones
UAE Oracle Cloud UAE East, Dubai (me-dubai-1) Listed, 1 availability domain
UAE Oracle Cloud UAE Central, Abu Dhabi (me-abudhabi-1) Listed, 1 availability domain
Saudi Arabia Oracle Cloud Saudi Arabia Central, Riyadh (me-riyadh-1) Listed, 1 availability domain
Saudi Arabia Oracle Cloud Saudi Arabia West, Jeddah (me-jeddah-1) Listed, 1 availability domain

Sources, all checked 25 October 2026: AWS Regions documentation, AWS global infrastructure page, Microsoft Learn list of Azure regions (page timestamp 13 October 2026) and Oracle's regions documentation.

What the table does not show.

  • Google Cloud. Google's geography and regions page (last updated 22 October 2026) says its services run in locations that include the Middle East, but it names no Middle East region and does not mention Doha. It links a separate "Dammam region access" document, which suggests a Saudi region with its own access rules. I did not open that document, so Google is not in the table. Check Google's current region list before you plan around Doha or Dammam.
  • Bahrain beyond AWS. None of the four pages lists a Bahrain region from Azure or Oracle.
  • Saudi Arabia on Azure and AWS. Neither Microsoft's regions list nor AWS's available-Regions table shows a Saudi region today.

What do the region lists tell you in practice?

Three details in the provider pages matter more than the region names.

AWS: one region per country in the GCC, and both require opt-in. AWS's table counts 34 Regions, and the UAE and Bahrain Regions are among those disabled by default. You enable them per account in the Global View console or the Billing and Cost Management console. A team that does not enable them cannot deploy there, which is one practical control.

Azure: Qatar has one region with no paired region. Microsoft lists Qatar Central with 3 availability zones and "N/A" for its paired region. In the UAE, UAE North pairs with UAE Central, but UAE Central is a restricted-access region. If your disaster recovery plan assumed the pair, you need to request access first through Microsoft's region access process.

Oracle: one availability domain per region. Oracle says new regions launch with one availability domain, so you cannot spread across domains for high availability. You would use fault domains, or a second region. In the UAE and Saudi Arabia, Oracle lists two regions in each country, which gives an in-country second region.

What does the UAE require for cloud and data location?

The UAE has no single "all data stays in the UAE" rule. It layers requirements by data type and entity.

  • Personal data. The federal PDPL restricts transfers abroad unless the destination offers adequate protection or safeguards apply. Our UAE PDPL guide explains the transfer rules and the DIFC and ADGM regimes.
  • Cloud users and providers. The UAE's National Cloud Security Policy is summarised on the government portal, with domains for cloud consumers and for cloud service providers in the UAE. Both include "Data Location and Sovereignty". For consumers, the page describes it as being aware of where data is stored, processed and managed from. For providers, it describes transparency about processing and storage locations. The portal summary does not mention an in-country hosting requirement. The full policy is a linked PDF, which I did not read, so check it before relying on this.
  • Federal and emirate rules. The portal page does not say whether Dubai or Abu Dhabi government entities follow emirate rules, the federal policy, or both. Confirm that with your own regulator.
  • Sector rules. Health and financial regulators add their own conditions. I have not opened those texts for this post, so I do not summarise them.

What does Saudi Arabia require for cloud hosting?

The Communications, Space and Technology Commission (CST, formerly CITC) publishes the Cloud Computing Regulatory Framework (CCRF). CST's announcement, dated 22 December 2020, says the updated framework sets out mechanisms for handling and classifying data, defines the responsibilities of cloud subscribers and providers, and revises the registration categories for providers. The announcement does not name the data levels or say which data must stay in the Kingdom. I could not open the framework text itself, so this post makes no claim about a specific level. Read the current CCRF on CST's site for the level names and any in-Kingdom rule.

Personal data has its own rule under the Saudi PDPL, covered in our Saudi PDPL guide.

What does Qatar require?

A Qatari cloud security policy document is linked from the QCERT site, but I could not open the policy text when checking, so this post states none of its rules. When you read it, look for four things: who it applies to, what it requires in provider contracts, any breach-notification deadline, and whether any data class is barred from the cloud or from leaving Qatar. Also check that you have the latest version.

What does Bahrain require?

Bahrain's Information and eGovernment Authority (iGA) posts a Cloud First Policy. I could not read the text of that PDF, so I do not summarise what it requires.

For personal data, Bahrain's national portal page on the Personal Data Protection Law says that transferring personal data outside the Kingdom needs permission from the Ministry of Justice, Islamic Affairs and Waqf, which carries out the Personal Data Protection Authority's tasks, and that the permitted countries and regions are set by ministerial decision. The page does not say where personal data must be stored.

This post does not cover the Central Bank of Bahrain's rules for financial firms. If you are CBB-licensed, check its rulebook separately.

Regions are also where the large AI capacity is being placed. Our post on GCC AI investment in Stargate UAE and Humain covers the capital side. For a company buying cloud services, the point is simpler: a region listed today is not the same as every service being available there. Check the service list for each region before you design around it.

Going deeper: for security and IT teams

Residency is a location claim. Sovereignty is a control claim. A provider can store your data in Dubai and still be subject to another country's legal demands, or manage the keys from elsewhere. For data that matters most, ask four separate questions: where is the data stored, where is it processed (including support access and AI inference), who holds the encryption keys, and which legal systems can compel the provider. A region page answers only the first.

Key management is where residency becomes enforceable. If the provider holds the keys, residency rests on a promise. If you hold them under your control, in a key store or hardware security module you manage, you decide whether the provider can read the data at all. Ask each provider: can I bring or hold my own keys, where is the key store physically, and what happens to my data if I revoke the key? I have not opened each provider's key management documentation for this post, so confirm the options for the services you use. Whichever route you choose, write down who can administer the key, where the key operations are logged, and how you would test a revocation.

Choosing regions: use the documentation, then enforce it.

  • Read the region list for the cloud you use (AWS's table, Microsoft's list, Oracle's page) and note opt-in, restricted access and zone counts.
  • On AWS, the UAE and Bahrain Regions are disabled by default. You can check an account with aws account list-regions --region-opt-status-contains ENABLED_BY_DEFAULT ENABLED and a single Region with aws account get-region-opt-status --region-name me-central-1, as AWS documents.
  • On Azure, list the locations your subscription can use with az account list-locations, and note that UAE Central needs an access request.
  • On Oracle, trial, free tier and pay-as-you-go tenancies can subscribe to one region only (Oracle docs); pay-as-you-go tenancies can request more, so a two-region DR design needs the right tenancy type.
  • Add a policy guardrail in your cloud's governance tool that denies resource creation outside approved regions, and alert on any attempt. Test it by trying to create a resource in a blocked region.

Disaster recovery across borders. The region lists create real gaps.

Situation Reading from the provider pages
AWS in the UAE or Bahrain One region per country is listed, so a second region means leaving the country
Azure in Qatar Qatar Central has no paired region listed
Azure in the UAE The pair, UAE Central, is restricted-access
Oracle in the UAE or Saudi Arabia Two regions per country are listed, one availability domain each

If a rule requires data to stay in-country, including for backup and redundancy, a plan that fails over to Frankfurt or Mumbai may breach it. Settle three things before an outage: whether your regulator allows copies abroad, whether those copies can be encrypted with keys that never leave the country, and who can authorise an emergency failover. Run a recovery test inside the allowed geography and record the recovery time you actually measured. Compare it with the target in your continuity plan, as described in ISO 22301 explained.

Evidence and standards to ask for. Ask for the provider's current ISO/IEC 27001 certificate and scope statement, and check whether the in-scope list names the specific region. Our ISO 27017 and 27018 post explains what those cloud standards do and do not prove. Ask for the subprocessor list and the data location commitments in your contract.

Questions for vendors and your own team.

  1. Which services are available in this region today, and which are not?
  2. Does support, logging, backup or AI inference leave the country, and can I switch that off?
  3. Who holds the keys, and can I revoke them?
  4. If this region fails, where does my data go, and who approves it?
  5. Does my regulator treat the region as enough, or does it also require local control?

What should a GCC organisation do next?

Start with an inventory of what you store and where, then classify it. Match each class to the strictest rule that applies to you, whether national, sector or contractual. Then pick regions and keys to fit, rather than the reverse. Re-check the provider pages every quarter, because region lists change and the table above is dated.

Learn more

Key takeaways

  • As of 25 October 2026, provider pages list regions in the UAE (AWS, Azure, Oracle), Bahrain (AWS), Qatar (Azure) and Saudi Arabia (Oracle); AWS says more are planned for Saudi Arabia.
  • A region in your country is not proof of compliance. Residency rules depend on data type, sector and regulator.
  • Residency says where data sits. Sovereignty asks who controls it, and key management is where you enforce it.
  • Disaster recovery can force data across a border: check pairings, zone counts and what your regulator allows.
  • Re-check region lists and the government texts before each project. Region availability changes.

Sources