Companies in Saudi Arabia moving to AWS run into the same three questions early on: where the data will physically live, which Saudi rules decide that, and how to avoid migrating twice once AWS opens its region inside the Kingdom. This guide answers all three, based on what AWS and the Saudi regulators have published.
Which AWS regions serve Saudi Arabia today
Until the Saudi region opens, the two closest AWS regions are in the Gulf:
- Middle East (UAE), region code
me-central-1, with three Availability Zones. - Middle East (Bahrain), region code
me-south-1, with three Availability Zones.
Both are opt-in regions: they have to be enabled on an AWS account before anything can be created there. Not every AWS service is available in every region, so check the services your workload needs against AWS's regional services list before you choose.
The AWS Saudi Arabia region: status and what it changes
AWS announced the Saudi region in March 2024 with three Availability Zones at launch and a planned investment of more than US$5.3 billion. AWS said the region would let organisations keep their content in the Kingdom while running applications on local infrastructure. Once it opens:
- Workloads whose data has to stay in the Kingdom can run on AWS directly, without a hybrid workaround.
- Applications serving users in the Kingdom can run closer to them.
- Regulated organisations get a native AWS option for in-country hosting.
In 2026, AWS said the region was on track to launch in December 2026. Until it appears as live on AWS's Regions and Availability Zones page, treat any date as a plan rather than a commitment, and keep the UAE or Bahrain region as the working option for workloads that cannot wait. Our guide to the AWS Saudi Arabia region tracks its status and compares it with the Gulf regions.
New AWS regions usually launch with a core set of services and add more over time. A workload that depends on a specific managed service should confirm that service is available in the Saudi region at launch rather than assume it.
Companies in Egypt face a different version of the same decision: our guide to choosing an AWS region in Egypt compares the options, and MAP for companies in Egypt and Saudi Arabia covers migration funding.
The rules that decide where your data can live
The Personal Data Protection Law (PDPL)
The PDPL is overseen by the Saudi Data and AI Authority (SDAIA). It covers the processing of personal data relating to individuals in the Kingdom, including processing by organisations based outside it. It came into force in September 2023, with a one-year period to comply.
The PDPL does not ban moving personal data out of the Kingdom, but transfers have to meet conditions. Under SDAIA's Regulation on Personal Data Transfer outside the Kingdom, issued in August 2024 and amended the following month, a transfer needs a permitted purpose and either a destination SDAIA considers adequate or an appropriate safeguard:
- Saudi standard contractual clauses (SCCs), in modules for controllers and processors.
- Binding common rules, for transfers within a corporate group.
- A certificate of accreditation from an approved body.
A controller relying on a safeguard has to carry out a risk assessment before the transfer. SDAIA published guidance on how to do it in February 2025. Penalties for breaching the law reach SAR 5 million per violation and can double for repeat offences.
National Cybersecurity Authority (NCA) controls
The NCA's Essential Cybersecurity Controls (ECC) and Cloud Cybersecurity Controls (CCC) apply mainly to government entities, operators of critical national infrastructure, and the cloud providers that serve them. The current cloud controls, CCC-2:2024, replaced the 2020 version and moved authority over data localisation to the National Data Management Office at SDAIA. If you are in scope, these controls shape both where data can be hosted and how the environment has to be secured.
Sector regulators
Some sectors add their own requirements on top. Banks, insurers and fintechs regulated by the Saudi Central Bank (SAMA), for example, have specific cloud and outsourcing rules. Check with your regulator early, because a sector rule can override what the PDPL alone would allow.
Choosing a region: a practical guide
| Your situation | Where to run now | What to plan for |
|---|---|---|
| Mostly non-personal data, users across the Gulf | UAE or Bahrain region | Move later only if latency or a customer requirement calls for it |
| Personal data of people in the Kingdom, no sector rule requiring in-country hosting | UAE or Bahrain region, with a documented transfer basis, safeguards and risk assessment | Reassess once the Saudi region opens |
| Government, critical infrastructure, or a sector rule requiring in-Kingdom hosting | Keep in-scope data on in-Kingdom infrastructure until the Saudi region opens | Move to the Saudi region at launch, once the services you need are available there |
How to avoid migrating twice
If you start in the UAE or Bahrain now and may move into the Saudi region later, the second move should be a planned change, not a second project. Build for it from the start:
- Define everything as code. Terraform, AWS CDK or CloudFormation, with the region as a parameter rather than a constant.
- Never hard-code regions. No region names, endpoints or ARNs baked into application code or configuration.
- Classify and tag data first. Knowing which stores hold regulated data tells you exactly what has to move.
- Keep regulated data stores separable. Stateless compute is easy to move; databases and object storage need a replication plan.
- Prefer services that will exist in both regions. Confirm availability before you depend on a newer managed service.
- Plan the data move now. Tools such as AWS Database Migration Service and S3 replication make a later regional move routine if they are part of the design.
Migration steps for a Saudi company
- Assess and classify. Inventory the workloads and classify the data each one holds.
- Choose a region per data class. Apply the rules above with your counsel, and write the decision down.
- Cost it in writing. Estimate the AWS spend and the migration effort before anything moves.
- Check credit programmes. Migration credits, Activate for startups or POC funding for a trial run may offset part of the cost. See our credit programmes guide.
- Build the landing zone. Set up a multi-account structure with guardrails, including policies that block regulated accounts from using regions they should not.
- Migrate workload by workload. Move in waves, with cutovers scheduled around the Sunday-to-Thursday working week.
- Verify and document. Confirm each workload runs as intended, and keep the evidence your compliance team will ask for.
Working with Alventara
We plan and run AWS migrations for companies in Saudi Arabia and across the Gulf, from Cairo, in English or Arabic. Discovery and planning run remotely, and the cost is in writing before you commit. Start with our free credit eligibility check and we will come back with a view on region, scope and the credit programmes that could apply.