Data Residency
RebelCore™ deploys every customer to a single regional footprint chosen at provisioning time. Two pieces of customer profile drive that footprint:
- Country — picked when the customer record is created.
- Cloud platform — picked on the licence. One of Azure, AWS, or GCP. Defaults to Azure.
The country selects which RebelCore™ deployment region the customer belongs to. The cloud platform then picks which provider’s specific region SKU is actually used for compute, storage, and the agent.
The five deployment regions
RebelCore™ is provisioned in five regional footprints. Every supported country routes to exactly one of them.
| Deployment region | Azure | AWS | GCP |
|---|---|---|---|
| USA | westus · West US | us-west-2 · Oregon | us-west1 · Oregon |
| UK | uksouth · UK South | eu-west-2 · London | europe-west2 · London |
| Europe | westeurope · West Europe | eu-central-1 · Frankfurt | europe-west3 · Frankfurt |
| Australia | australiaeast · Australia East | ap-southeast-2 · Sydney | australia-southeast1 · Sydney |
| South Africa | southafricanorth · South Africa North | af-south-1 · Cape Town | africa-south1 · Johannesburg |
The left-hand value in each cell is the SKU that the platform sends to the cloud provider. The italic value is the nice name shown to users in the app and in this documentation.
Country to region mapping
These are the routing rules baked into dbo.lkp_country. Anything not in this list keeps NULL region columns and the Data Residency badge falls back to showing the country name only.
USA region
US, CA, MX, PR
UK region
UK, GG (Guernsey), JE (Jersey), IM (Isle of Man)
Europe region
IE, NL, DE, FR, BE, LU, ES, IT, SE, NO, DK, FI, IS, AT, CH, PL, PT, CZ, SK, HU, GR, RO, BG, HR, SI, EE, LV, LT, MT, CY
Australia region
AU, NZ
South Africa region
ZA, NA, BW, ZW, MZ, KE, NG
How it shows up in the app
Header badge
Every page in RebelCore™ carries a small Data Residency badge in the top header, immediately to the left of your initials avatar. It looks like this:
Data Residency🌐 UK South (uksouth - azure)Top line is the label. Bottom line is the resolved region rendered as <nice name> (<sku> - <cloud platform>). The cloud platform is the one selected on the customer’s licence.
Hover popover
Hover the badge and a popover slides out with:
- The current region heading
- Country — the country selected on the customer profile
- Cloud — the cloud platform from the licence
- Region SKU — the literal value sent to the provider
- A Request Migration button
The Request Migration button is a placeholder until the migration flow ships. Clicking it logs the current region context for diagnostic purposes; once migration is wired up it will trigger a workflow to move the customer’s data and resources to a different deployment region.
Regulatory alignment
Each deployment region is chosen so the customer’s data stays inside the legal jurisdiction it’s regulated under. The primary regulations that drive the regional split:
| Deployment region | Primary regulations satisfied |
|---|---|
| USA | State-level privacy laws (CCPA / CPRA, etc.) |
| UK | UK GDPR · Data Protection Act 2018 |
| Europe | GDPR · EU AI Act · DORA |
| Australia | Privacy Act 1988 · Australian Privacy Principles |
| South Africa | POPIA (Protection of Personal Information Act) |
Customers in the South Africa region have all personal information processed and stored within South African borders, satisfying POPIA’s cross-border transfer restrictions (sections 72 and 114). The audit chain, tenant database, blob storage and Cosmos account for a ZA-routed customer all live in southafricanorth (Azure) / af-south-1 (AWS) / africa-south1 (GCP).
Why the split
Separating country from cloud platform lets us serve compliance-driven and operational requirements independently:
- A customer can choose a region for data residency reasons (e.g. UK customer data must stay in the UK, South African personal information must stay in South Africa under POPIA) without picking a cloud first.
- The same regional intent can then be realised on Azure, AWS, or GCP — whichever the customer’s licence specifies — without changing where the data physically lives.
- A future migration only flips one of the two — country if the customer’s compliance scope changes, cloud platform if their procurement flips — and the other stays put.
Where to go next
- Roles & permissions — the permission flags that gate what a user can do inside the deployed region.
- Audit — review activity in your deployed region.
- Governance & access — the conceptual model behind the medallion / region split.