UAE cloud region: 55 services AWS doesn't run there

Microsoft's own availability table says Azure UAE Central — the region Microsoft offers as the in-country disaster-recovery partner for UAE North — carries 66 generally available products against UAE North's 108, has no availability zones at all, and is access-restricted. Choosing a UAE cloud region buys you residency and costs you the ability to fail over into anything resembling your primary stack. The latency was never the interesting part.

Everything below comes from each provider's own published regional availability tables, read on 9 October 2026, with the table named on every figure. What the PDPL requires to stay inside the country is a separate post, and so is health-sector hosting. This one assumes you have already decided you must be in-country and are working out what that does to your architecture.

What a UAE cloud region costs you in services, not milliseconds

AWS's regional product services table is served as JSON from api.regional-table.region-services.aws.a2z.com. Reading it on 9 October 2026, Middle East (UAE) — me-central-1 — lists 144 services. US East (N. Virginia) lists 199. Fifty-five services present in N. Virginia are absent from the UAE region.

Microsoft's products-by-region table ships its data as a JSON array inside the page, which makes it countable. On the same date, UAE North listed 108 products at GA, 7 in preview and 12 marked "Closing Down". East US listed 131 at GA. Twenty-four products GA in East US have no GA entry against UAE North.

Provider's own table	In-country region	Listed	Compared with
AWS regional services table	me-central-1	144 services	us-east-1: 199 — 55 absent
Azure products by region	UAE North (Dubai)	108 GA	East US: 131 GA — 24 absent
Azure products by region	UAE Central (Abu Dhabi)	66 GA	UAE North: 108 GA — 42 absent
Read 9 October 2026. AWS's JSON carried source:version 20251113063700; Azure's table is undated in the page.

One honesty note before anyone builds a slide out of that table: 144 and 108 are not comparable to each other. AWS counts "services" and Microsoft counts "products", the two vendors slice their catalogues differently, and AWS's table lists several Elemental Media components as separate rows where Azure would list one. The numbers are only meaningful within a provider — in-country against a reference region of the same provider. Compare them across vendors and you are measuring taxonomy, not capability.

The layer that breaks a residency commitment first is observability

Work down a typical stack and almost all of it has an in-country answer: compute, managed Postgres, object storage, queues, Kubernetes, secrets, CDN are all present on both hyperscalers in the UAE. Then you reach the layer that watches the rest of it, and the answer changes.

On AWS me-central-1, Amazon Managed Service for Prometheus is present but Amazon Managed Grafana is not. You can keep the metrics in-country and have nowhere managed to draw them. Also absent from the UAE region: AWS Audit Manager, Amazon Security Lake, Amazon Detective and AWS Resilience Hub — four of the services you would reach for precisely when you have to demonstrate to someone that your controls work.

Azure's version of the same hole sits one step further in. Azure Grafana Service is GA in UAE North, so Dubai is fine. It has no GA entry in UAE Central. Neither does Network Watcher. So the region Microsoft nominates for your in-country failover is the one where you cannot stand up the managed dashboard or run the managed network diagnostic — during the incident that sent you there.

This is what the service gap actually costs. An absent managed service is not a missing feature; it is an operational transfer. You run Grafana on your own nodes, patch it, back it up, page someone when it falls over, and carry the compliance evidence for it yourself. None of that appears in a pricing calculator. Much of our DevOps and cloud engineering work is this kind of self-operated substitute, and each one is a small permanent tax rather than a one-off build.

Two more absences to know before you promise anything. Azure Chaos Studio has no GA entry in either UAE region, so Microsoft's managed failure-injection service cannot test the failover you just designed — AWS Fault Injection Service is present in me-central-1. And Azure Cloud HSM and Azure Payment HSM are absent from both UAE regions, which matters if your rule is about key custody rather than data location.

The strongest case against caring about any of this

Here is the argument we would make against ourselves, and it is a good one. Most applications use perhaps twenty cloud primitives — compute, a relational database, object storage, a cache, a queue, a load balancer, DNS, secrets, a CI runner, logs — and every one of those is in both UAE regions on both hyperscalers. If your workload is a web application with a Postgres behind it, the 55-service gap is noise.

That argument is right for most workloads. It fails in two places. The first is the evidence layer — audit, SIEM, security analytics, resilience assessment — whose whole job is to prove the in-country claim, so running it from a foreign region undercuts the claim it exists to support. The second is anything where the absent service is the product rather than the plumbing: you cannot operate your own Textract, and Amazon Textract, Transcribe, Translate, Comprehend and Rekognition are all absent from me-central-1. If document extraction is your feature, the region choice is a product decision.

Multi region failover within the UAE is a real option on exactly one provider

Provider	In-country regions	Fault isolation inside the region
AWS	1 — Middle East (UAE), me-central-1	3 Availability Zones; opt-in required
Azure	2 — UAE North, UAE Central	UAE North: 3 zones. UAE Central: none listed
Oracle OCI	2 — me-dubai-1, me-abudhabi-1	1 availability domain each
Alibaba Cloud	1 — UAE (Dubai), me-east-1	2 zones

On AWS there is no in-country second region. The AWS Regions reference lists exactly one UAE region with three Availability Zones and marks its opt-in status "Required" — disabled by default, so organisation policies and IaC pipelines need it explicitly enabled. The nearest other AWS region is Middle East (Bahrain), a different country. If your residency rule is national, AZ-level redundancy is your entire resilience story, which is narrower than most DR plans assume. Our write-up on AWS Middle East data loss and disaster recovery for UAE workloads works that scenario through.

AWS's price list makes the point sharper. Inter-region data transfer out of me-central-1 is $0.085 per GB to Middle East (Bahrain) — and $0.085 per GB to US East (N. Virginia), EU (Ireland) and Asia Pacific (Mumbai) as well. There is no price incentive to keep the second copy nearby, because AWS charges the same to cross the Gulf as to cross the Atlantic. That is how backups quietly end up offshore: nobody decided it, the price list was indifferent and the cheapest destination won.

Azure does offer two in-country regions, and Microsoft's region list pairs UAE North (Dubai) with UAE Central (Abu Dhabi). Read the footnote. UAE Central is flagged as a Reserved Access Region — "Certain regions are access restricted to support specific customer scenarios, for example in-country disaster recovery" — and shows no availability zones. So the DR target is a region you must request access to, with no internal fault isolation, running 66 of the 108 GA products your primary runs. The subset is strict: every GA product in UAE Central is also in UAE North, so there is nothing you can only do in Abu Dhabi. Azure Container Apps, Data Factory, Databricks, Synapse, Microsoft Fabric, Microsoft Foundry and Azure AI Search are all GA in UAE North and absent from UAE Central. If your data platform or retrieval layer lives in any of those, the failover plan needs a separate answer for them.

Oracle is the one provider with two ordinary commercial regions in the country. Its regions and availability domains table lists UAE East (Dubai) as me-dubai-1 and UAE Central (Abu Dhabi) as me-abudhabi-1, both in the OC1 realm and both with a single availability domain, where London has three. Oracle inverts the trade: real region-to-region failover inside the UAE, and nothing to fall back on within either region. Alibaba Cloud lists one UAE region, UAE (Dubai) me-east-1 with two zones, leaving it where AWS is on cross-region failover.

Where we could not establish parity, we are saying so. AWS and Microsoft publish a consolidated, countable table of what runs where. Oracle and Alibaba do not. Oracle's service-availability page returned 403 to every fetch we tried, and its documentation says only that core services run in all public regions while "certain specialized or emerging services are available only in select regions". Alibaba's region list is scoped to Elastic Compute Service and states that supported regions vary by product. For those two we can report the published region and zone topology and nothing more — treat any service count you see for them as invented.

Cost difference of a UAE cloud region, quoted only from the price lists

The in-country premium is published, and it is bigger on the data-movement lines than on compute. These come from the vendors' own pricing APIs — Microsoft's unauthenticated retail prices endpoint and the AWS price list bulk JSON — queried on 9 October 2026.

Line item	In-country	Reference region
Azure Standard_D4s_v5, Linux, pay-as-you-go	UAE North $0.235/hr	East US $0.192/hr — +22%
Azure Standard_D4s_v5, Linux, pay-as-you-go	UAE Central $0.306/hr	UAE North $0.235/hr — +30%
Azure standard inter-region data transfer out	UAE North $0.16/GB	East US $0.02/GB — 8x
AWS internet egress, first 10 TB/month	me-central-1 $0.11/GB	us-east-1 $0.09/GB — +22%
AWS S3 Standard, first 50 TB/month	me-central-1 $0.025/GB-mo	us-east-1 $0.023/GB-mo — +8.7%
Azure figures from prices.azure.com/api/retail/prices, 9 Oct 2026. AWS figures from the price list JSON, publication dates 2026-09-16 (transfer) and 2026-09-28 (S3).

The third line is the one that should change a design. Moving a gigabyte out of UAE North to another region costs eight times what the same move costs out of East US, and it is priced identically from UAE Central. A nightly cross-region replication that is a rounding error in Virginia is a budget item in Dubai. Meanwhile the Abu Dhabi DR region — restricted, no zones, two-thirds of the catalogue — is also the more expensive of the two per compute hour, by 30%. You pay more for less: defensible as the price of in-country continuity, a bad surprise in month three.

Two things we did not price because we could not source them cleanly: a like-for-like AWS EC2 instance comparison, which the price list makes awkward across instance generations and tenancy, and anything about Oracle or Alibaba regional pricing.

The compliance certificates do not answer the question you are asking

AWS enumerates. Its 2026 DESC audit announcement says the certificate, validated by BSI and valid to 22 January 2027, covers the AWS Middle East (UAE) Region and brings the total to 108 services in scope, adding 10 — among them AWS Elastic Beanstalk, Amazon Inspector, Amazon Managed Service for Prometheus and Amazon Bedrock. You can read that list and check whether the service you are about to use is on it.

Microsoft names a family. Its UAE DESC compliance page gives the services in audit scope as "Azure Core Services", "Dynamics 365 Core Services" and "Office 365 Services", covering both UAE Central and UAE North, and refers you to the Microsoft Privacy and Security Terms for what Core Online Services means. That is a broader claim across two regions and a less resolvable one: you cannot read it off and get a yes or no for a named service. The page also carries a document date of 4 April 2023 and a last-updated stamp of 10 October 2024, so check the certificate rather than the page.

Neither is wrong. They answer different questions, and only one of them answers "is this specific service in scope". If your obligation is service-level, enumeration is worth more than breadth.

Amazon Bedrock is in scope; Bedrock Marketplace is not

The AI-inference detail shows why the enumerated list matters. Amazon Bedrock entered AWS's DESC scope only in the 2026 audit, and the wording is "Amazon Bedrock (excludes Amazon Bedrock Marketplace)". Bedrock is on the regional table for me-central-1; Amazon Bedrock AgentCore is not. So "our inference runs in the UAE region on a DESC-certified service" can be true of a Bedrock call to a first-party model and false of the same architecture routed through Marketplace or built on AgentCore — a distinction nobody notices until an auditor reads the integration. Our post on OpenAI data residency in India and the UAE covers the equivalent question on the other side of the AI stack.

What we would check before committing a workload in-country

Take your actual service inventory — not a reference architecture — and run each entry against the provider's own region table on the day you decide. Then ask three things of the gaps. Does this one hold regulated data, or is it plumbing you can legitimately call cross-border? If it is absent and does hold regulated data, what does operating it ourselves cost in on-call load rather than instance hours? And how hard is it to get back out — a reversibility question rather than a vendor one, and the one that decides whether a self-operated substitute is a bridge or a fixture.

The answers move. AWS added 10 services to DESC scope in one audit cycle and the regional tables change without announcement, which is why every number here is stamped 9 October 2026 and why you should re-check rather than cite us. Our reading of the rules comes from the published regulations and the providers' primary sources, not a consultancy summary; if you want to see the kind of work this sits inside, that is our software development practice in Dubai. Make the decision once, with the table open in front of you.