BTP Regions
SAP BTP is available in 30+ data centre regions across AWS, Azure, GCP, and Alibaba Cloud. Region selection determines data residency, service availability, and latency. Once set at subaccount creation, the region is immutable.
Understanding BTP Regions
SAP BTP regions are the geographic data centres where BTP services are hosted. Each region is identified by a code that encodes the hyperscaler and geography — for example, eu10 is AWS Frankfurt (Europe, region 10), and ae1 is AWS UAE / Dubai (Arabian Emirates, region 1).
Region selection is the most consequential and irreversible decision when creating a BTP subaccount. Once a subaccount is created in a region, it cannot be migrated. Deleting and recreating the subaccount — with all its service instances and subscriptions — is the only path to changing regions.
Not all BTP services are available in every region. The SAP Discovery Center is the authoritative source for service availability per region — always verify before starting a project.
Quick Facts
- Total regions
- 30+ globally
- Hyperscalers
- AWS · Azure · GCP · Alibaba
- UAE region
- ae1 (AWS Dubai) — UAE PDPL
- EU GDPR regions
- eu10 / eu20 / eu30
- Region immutable?
- Yes — set at subaccount creation
- Multi-region HA
- No native — manual failover only
- Service check
- Discovery Center per-region filter
- Private Link
- Match BTP region to hyperscaler
SAP BTP Region ae1 (AWS UAE / Dubai) supports UAE data residency requirements under the UAE Personal Data Protection Law (PDPL). Available since 2023, it is the mandatory region for any UAE government or regulated-sector workload that cannot store personal data outside the UAE.
Services confirmed available in ae1:
Always verify the latest service availability in ae1 on Discovery Center before project kick-off, as new services are continuously added.
Region Reference Table
| Region Code | Location | Hyperscaler | Use Case | Data Residency |
|---|---|---|---|---|
| ae1 | Dubai, UAE | AWS | UAE/GCC production workloads | UAE PDPL |
| sa1 | Riyadh, Saudi Arabia | AWS | Saudi Arabia workloads | KSA NDMO |
| eu10 | Frankfurt, Germany | AWS | EU production, largest service catalog | EU GDPR |
| eu20 | Netherlands | Azure | EU + Azure Private Link | EU GDPR |
| eu30 | Frankfurt, Germany | GCP | EU + GCP Private Link | EU GDPR |
| us10 | Virginia, USA | AWS | Americas AWS production | US (no specific) |
| us20 | Virginia, USA | Azure | Americas Azure production | US (no specific) |
| us30 | Iowa, USA | GCP | Americas GCP production | US (no specific) |
| ap10 | Sydney, Australia | AWS | Australia / Pacific | AU Privacy Act |
| ap21 | Singapore | Azure | Southeast Asia | PDPA Singapore |
| jp10 | Tokyo, Japan | AWS | Japan production | APPI (Japan) |
| cn40 | Shanghai, China | Alibaba Cloud | China data residency required | China PIPL |
Hyperscaler Matching for Private Link
SAP BTP Private Link Service enables a private network connection between BTP and services running on the same hyperscaler — without traffic traversing the public internet. For Private Link to work, the BTP subaccount region and the connected system must be on the same hyperscaler:
Enterprise Example — DEWA Region Strategy
As a UAE government entity, DEWA must comply with the UAE Personal Data Protection Law (PDPL), which requires personal data to remain within UAE borders. This mandates region ae1 (AWS Dubai) for all production subaccounts processing personal data.
- All 6 production subaccounts hosted in ae1
- UAE data residency for all customer data
- HANA Cloud, CF, Kyma all confirmed in ae1
- S/4HANA on-premise connects via Cloud Connector to ae1
- Fulfils UAE PDPL and internal DEWA data governance policy
- All development subaccounts use eu10 for cost reasons
- Larger HANA Cloud instance selection in eu10
- No personal data in development environments
- Anonymised/synthetic data for dev testing
- Explicit data classification policy enforces no real data in dev
Region Selection Decision Framework
- 11. Data Residency RequirementDoes your workload have a legal or regulatory requirement to keep data within a specific geography? UAE PDPL → ae1. EU GDPR → eu10/eu20/eu30. Saudi NCA → sa1. China PIPL → cn40. If no requirement, proceed to step 2.
- 22. Hyperscaler AlignmentIs your SAP S/4HANA or other backend running on a specific hyperscaler? Use the matching BTP region for Private Link connectivity. AWS → eu10/us10/ae1/ap10. Azure → eu20/us20/ap21. GCP → eu30/us30.
- 33. Service Availability CheckVerify all required BTP services are available in the candidate region using the Discovery Center service catalog filter. Some services (e.g., newer AI services) may only be in eu10 or us10.
- 44. Latency to End UsersIf residency and hyperscaler don't constrain you, choose the region geographically closest to your primary end-user population for best Fiori/UI5 app responsiveness.
- 55. Contractual ConfirmationConfirm your chosen region is covered by your SAP BTP contract. Some regions require explicit contract addenda. Obtain a Data Processing Agreement (DPA) for regulated workloads.
Best Practices
Always resolve legal and regulatory data residency requirements before optimising for latency or cost. Getting this wrong post-go-live is extremely costly to fix.
Check all required BTP services are available in the target region on Discovery Center before starting development. Discovering a missing service late in a project is a critical risk.
For UAE government and regulated-sector workloads, ae1 (AWS Dubai) is the only BTP region that satisfies UAE PDPL data residency requirements as of 2025.
If S/4HANA RISE is on AWS, use an AWS BTP region. Private Link only works within the same hyperscaler — mismatching forces Cloud Connector usage instead.
Record the rationale (legal requirement, hyperscaler match, service availability) in an ADR. Future architects must understand why a specific region was chosen.