Cloud · AWS
AWS in Saudi Arabia: what you can run today, and what changes when the Saudi Region opens
AWS has announced its first infrastructure Region in the Kingdom and says it is on track to launch in December 2026. Until it is live, AWS's Middle East Regions are in Bahrain and the UAE. This page sets out how to decide, workload by workload, where each one should run now and later, and how Interkey, an AWS partner, plans, builds and operates that from Riyadh.
In short
- The Saudi Region: announced. AWS says it is on track to launch in December 2026. On 2 November 2026 it was not yet in AWS's list of available Regions.
- AWS Middle East Regions available today: Middle East (Bahrain), me-south-1, and Middle East (UAE), me-central-1, each with three Availability Zones. Both must be enabled in your AWS account before you can use them.
- Inside the Kingdom today: Amazon CloudFront edge locations in Jeddah and Riyadh, for delivering web content and APIs to users, and AWS Outposts racks, which are AWS-managed infrastructure installed in your own data centre. An edge location is not a Region: you do not run servers or databases there.
- What decides placement: the classification of the data each workload holds, not a preference for a provider or a location.
Where AWS workloads can run for a Saudi organisation today
Until the Saudi Region is available, every AWS Region you can use is outside the Kingdom. Inside it, the AWS options are content delivery edge locations and Outposts racks installed at your own site, alongside infrastructure you run yourself.
| Option | What it is | Suits | Check before using |
|---|---|---|---|
| Middle East (UAE), me-central-1 | AWS Region with three Availability Zones; must be enabled in your account | Workloads whose data your policy allows outside the Kingdom | Data class, latency for your users, and that the services you use are offered there |
| Middle East (Bahrain), me-south-1 | AWS Region with three Availability Zones; must be enabled in your account | The same | The same |
| Amazon CloudFront edge locations, Jeddah and Riyadh | Content delivery locations; AWS Shield Standard protects all CloudFront edge locations, and AWS WAF can be added | Serving web content and APIs closer to users in the Kingdom | They deliver and cache content; your application and data still run in a Region, on an Outposts rack or on your own infrastructure |
| AWS Outposts rack | AWS-managed infrastructure installed at your site, relying on a connection to a parent AWS Region | Workloads that need AWS services on premises in the Kingdom | AWS notes that deployments in the Kingdom may require additional authorization; some limited metadata flows back to the parent Region; confirm the services you need run on Outposts |
| Your own infrastructure in the Kingdom | On-premise or in-Kingdom hosting you control | Data your policy requires to stay in the Kingdom | It needs the same operating discipline as a cloud platform: patching, capacity, backup that is tested by restoring |
What changes when the AWS Saudi Region opens
The Region adds a place in the Kingdom for workloads whose data has to stay here. It does not move anything by itself, and it is not automatically the right home for every workload.
- A new placement option. Workloads held back because of their data class become candidates, provided the AWS services they use are offered in the new Region. Check that list for each workload at launch rather than assuming it.
- An account change before the first workload. AWS requires Regions introduced after 20 March 2019 to be enabled before use, which is the case for both Middle East Regions today. Plan for the Saudi Region to follow the same rule, and for your guardrails, identity and network design to be extended to it.
- Moving an existing workload is a migration. A system already running in Bahrain or the UAE moves with a cut-over, a data transfer and a period of running in two places. Sequence it by dependency, like any other migration.
- The landing zone comes first. If your landing zone is written as code, extending it to a second Region is a change you can review and test. If it was built by hand, that is the first piece of work.
Read more
Should you wait? Workloads your policy already allows outside the Kingdom do not need to wait. For workloads that must stay in the Kingdom, the AWS option before launch is an Outposts rack at your own site; otherwise use the time before launch to classify them, design the landing zone and plan the migration, so the move can start when the Region and the services they need are available.
A placement worksheet, one workload at a time
Answer these in order for each workload. The first "no" usually tells you where the work is.
| Question | If yes | If no |
|---|---|---|
| Does the workload hold data your policy allows outside the Kingdom? | Bahrain or UAE are candidates now | It stays in the Kingdom, on your own infrastructure or an Outposts rack, until the Saudi Region is available and suitable |
| Are all the AWS services it uses offered in the target Region? | Continue | Redesign that part, or wait |
| Is response time from the target Region acceptable for your users? | Continue | Consider in-Kingdom hosting, or content delivery through the in-Kingdom edge locations for the parts that can be cached |
| Does it depend on systems that will stay on-premise? | Design the connection between the two before moving | Continue |
| Is there a named owner to operate it after the move? | Ready to plan | Not ready to move |
Four costs to include in an AWS estimate
These four are consistently missed in first estimates:
- Running both estates at once. Old and new environments overlap during migration and cut-over.
- Moving data out again. Data transferred out to the internet is charged beyond a monthly free allowance, and that matters for reporting, backups and any later move.
- The operating model. Someone has to patch, watch capacity, keep identities clean and review the bill every month.
- Rehosted inefficiency. A server moved as it is keeps its oversizing, and now you pay for that oversizing for as long as it runs.
How Interkey works on AWS
Interkey is an AWS partner. The work is the programme around the platform, delivered from Riyadh in Arabic and English:
Read more
- Classification and placement. An inventory in which every application has a placement decision and a reason, including the ones that stay where they are.
- Landing zone as code. Identity, network boundaries and guardrails built so they can be rebuilt, and extended to a second Region.
- Migration in dependency order. Rehost, replatform or rewrite, decided per workload rather than for the whole estate.
- Operation after the move. Patching, capacity, identity hygiene, guardrail changes and a monthly cost report, as a managed service on an agreed scope. Coverage hours and response targets are written into each agreement.
- The platforms on top. Containers and Kubernetes, observability, and data platforms, for workloads that need them.
Questions buyers ask
Is the AWS Saudi Region live?
Not on 2 November 2026. AWS lists it as announced and says it is on track to launch in December 2026. This page will be updated when it appears in AWS's Region list.
Should we wait for the Saudi Region before moving to AWS?
Only for workloads whose data must stay in the Kingdom and that cannot use an Outposts rack. The others can be placed in Bahrain or the UAE now if your policy allows. For the ones that wait, classification, landing-zone design and migration planning can all be done before launch.
Can we keep Saudi customer data in the Bahrain or UAE Region?
That depends on your data classification and the rules that apply to your sector, so there is no general answer. The placement worksheet above is how we work it out with you, one workload at a time.
Do the CloudFront edge locations in Jeddah and Riyadh keep our data in the Kingdom?
No. An edge location delivers and caches content for users; it is not where your application and database run. Those still run in a Region, on an Outposts rack or on your own infrastructure.
Who runs the environment after migration?
Your team, Interkey, or both. Interkey operates platforms it implements as a managed service on an agreed scope, with what you keep and what Interkey takes written down before day one.
Next
Related pages
Next step
Plan your AWS workload placement
List the workloads you are considering and any data your policy keeps in the Kingdom. We will reply with the questions that decide placement and a proposed first step.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia