Which Azure Services Will Be Available in Saudi Arabia East?

01 / The current answer

What does the launch announcement confirm about services?

Microsoft has announced customer workload availability from Q4 2026 and three availability zones in the Eastern Province. The announcement describes cloud and AI capabilities, but does not provide a complete day-one catalogue of services, SKUs, and features.

That means the announcement alone cannot confirm whether your exact application fits the new region. It also does not establish that a service is unavailable; it leaves a question to verify.

Use the live Azure products-by-region catalogue, the regions list, and the individual service documentation. For subscription-specific access, use written confirmation or an actual deployment test.

Record when each check was made. Availability can change between an initial assessment and a production cutover.

02 / Go beyond the product name

Check the configuration your application uses

“We use Azure SQL” describes a product family. It does not identify the service tier, compute model, size, database features, network access, or recovery arrangement your workload depends on.

The same applies to a VM. A different family may have enough memory but different processor behaviour, disk limits, or licensing implications. Replacing it with an available size is a design change that needs testing.

• Product and SKU: the exact service and tier you need.
• Version and features: engine version, extensions, deployment type, and required integrations.
• Reliability: zone support, replicas, backup, and restore options.
• Access: networking, subscription eligibility, permissions, and provider registration.
• Scale: quotas, expected capacity, and a workable fallback.

Apply the same discipline to AI services. Check the exact model, version, deployment type, quota, and processing-location terms. A local Azure region does not confirm local availability or processing for every model.

03 / Make a useful record

Build a service register your team can act on

Create one row per meaningful dependency. Record the current configuration, required target capability, evidence link, date checked, owner, and any fallback.

Use clear status values. “Unconfirmed” means more evidence is needed. “Unavailable” means you have evidence that the required capability cannot currently be used. Keeping those separate prevents guesses from becoming design constraints.

For a small workload, a spreadsheet is often enough. Keep it linked to the deployment design so a service change does not leave the register describing an old architecture.

04 / Can you actually deploy it?

Availability, quota, and capacity are separate checks

A service may exist in a region while your subscription needs additional access or quota. The quota is the usage allowance; the platform still needs capacity to satisfy the deployment.

Check quotas for the intended region and service. For VMs, this can include both regional and family-specific limits. For other services, the relevant limit may be instances, throughput, or another unit.

Request necessary increases early enough for review, and verify the outcome before a production window. A request being submitted is not the same as approved capacity being usable.

Keep an approved alternative where appropriate. A different VM size might work after testing, while changing a database tier could require a larger redesign. Treat those alternatives according to their real impact.

05 / The less visible dependencies

Include the services used to operate the application

Teams tend to check the web application and database first. A production service also needs deployment, identity, secrets, monitoring, and recovery.

Include the build agent's access path, container registry if used, certificate source, log collection, alert delivery, backup protection, and external integrations. Review global or externally hosted components under their own data and access requirements.

A useful check is to walk through an incident. If the app fails in Saudi Arabia East, can the team see the error, access the right diagnostics, deploy a repair, and restore the data? Each step exposes another dependency.

The Saudi landing zone guide helps organise those shared foundations before the first workload moves.

06 / Deal with a gap

What if a required capability is missing?

Choose among a small number of explicit options. Wait for the capability, redesign that part of the application, keep an approved dependency elsewhere, or choose another pilot.

Evaluate the full effect of a workaround. A remote database may introduce latency and a data-transfer question. A replacement service may require new code and new operational knowledge. A simpler tier may fail the recovery requirement.

Record the cost and owner of the workaround, along with the conditions for removing it. Temporary architecture tends to become permanent when nobody has responsibility for revisiting it.

If no acceptable option exists, mark that workload blocked by a specific capability. Other workloads may still be able to move.