When 'cloud' is not the same as 'cloud in your region'

A workload sold to a regulated buyer as "hosted in eu-west-1" has its IAM principals replicated to every region in the AWS commercial partition, its CloudTrail organisation logs aggregating in us-east-1 by default, its DynamoDB Global Tables actively replicating to ap-southeast-2 for a resilience SLA the buyer once asked for, its AWS Backup configured to copy weekly snapshots to eu-central-1 for disaster recovery, its CloudFront distributions terminating at edge locations on every continent, and its Premium Support tickets handled by an engineer in Bengaluru. Every one of those is a deliberately documented AWS feature. None of them are bugs. All of them are residency events. The "in eu-west-1" claim is technically true and operationally hollow at the same time.

The companion article on data residency as a deployment decision walked through why the broad residency promise fails under regulator scrutiny: backups land elsewhere, telemetry ships elsewhere, support engineers connect from elsewhere, multi-region failover moves data across borders during stress events. That article framed the problem at the procurement layer. This one goes one level lower: into the actual mechanics of how AWS, Azure, and Google Cloud Regions are built, what each provider's Sovereign Cloud SKU actually delivers (and what it does not), why the US CLOUD Act survives every regional claim a US-parented provider can make, and where the four control surfaces customers most commonly miss when they sign a "cloud in your region" deal.

How cloud Regions actually work

The AWS, Azure, and Google Cloud Region story shares a common shape. A Region is a physically separate geographic area composed of multiple Availability Zones. Each Availability Zone is one or more discrete data centres with independent power, cooling, and physical security, connected by low-latency private fibre. AWS operates roughly thirty-four commercial Regions and one hundred eight Availability Zones as of 2026. Azure operates sixty-plus Regions across thirty-five-plus geographies. Google Cloud operates roughly forty Regions. The architecture is consistent: physical isolation between Regions, fast interconnect within Regions, customer choice of Region at provisioning time.

The story diverges immediately when you look at which services are Regional and which are global. AWS splits its catalogue explicitly. Regional services (EC2, RDS, S3, DynamoDB, Lambda) store and process data only in the selected Region by default. Global services include Identity and Access Management (IAM data is replicated across all Regions in the AWS commercial partition; there is no way to pin IAM data to a single Region), Route 53 DNS (records replicated globally to edge locations), CloudFront (by design global), AWS Organizations (control-plane data global within the partition), AWS Artifact, AWS Marketplace, and Billing. Azure has its own equivalents: Microsoft Entra ID (tenant directory data lives in a home geography but the service plane is global), Azure Front Door, Azure DNS, and Azure Resource Manager (the management plane that handles every API call is a global endpoint). Google Cloud follows a similar pattern with Cloud DNS, Cloud CDN, IAM, Cloud Identity, and the Console all operating globally.

The audit gap is structural rather than configurable. A workload provisioned to a specific Region is automatically using global services that, by design, are not Region-pinned. The IAM principal that signs into the EU Region exists in every Region of the partition. The management API call that creates an EU resource routes through a global endpoint that may terminate in the US. The CDN that serves the EU application caches at edges on every continent. None of these are violations of the Region promise; they are the Region promise as the provider defined it. The disconnect lives in the word "in".

Cross-region replication is the second mechanism that quietly breaks the Region claim. S3 Cross-Region Replication is opt-in but routinely enabled "for disaster recovery". DynamoDB Global Tables provide fully managed multi-Region, multi-active replication; data lives in every selected Region simultaneously. RDS cross-Region read replicas and Aurora Global Database support sub-second cross-Region replication to up to five secondary Regions. AWS Backup cross-Region copy is off by default but disaster recovery runbooks routinely turn it on. CloudWatch cross-account observability and metric streams fan out across Regions. AWS Config aggregators pull configuration data from many Regions into one central account. CloudTrail organisation trails deliver to a single S3 bucket in a single Region by default. Azure's Geo-Redundant Storage replicates to a paired Region by default for some SKUs (the paired-Region model means selecting West Europe pairs to North Europe, which is correct for EU, but other geography pairings cross borders). Google Cloud Storage multi-region and dual-region buckets are explicit configuration choices but routinely selected for resilience.

The architectural point is simple: the default knob for resilience in every hyperscaler is more replication, and replication is the thing that breaks residency. Resilience and residency pull in opposite directions, and the provider's marketing assumes the customer wants the first.

The Sovereign Cloud SKUs

Every major cloud provider responded to the regulator pressure with a Sovereign Cloud product. Each one is structurally different from the others and from the parent commercial cloud. None of them is a complete answer to the CLOUD Act question.

AWS European Sovereign Cloud. Announced 25 October 2023, with the first Region in Brandenburg, Germany, targeted for end of 2025. Operated by a separate EU legal entity, staffed exclusively by EU residents physically located in the EU. Control plane, billing, support, and operations all EU-resident. Independent of the AWS commercial partition; it is its own partition, like GovCloud or AWS China. What it delivers is operational independence: support, root access, and customer service operate only from EU territory. What it does not change is the parent corporate structure: Amazon.com Inc remains a US-incorporated entity, and the US CLOUD Act applies extraterritorially to US companies regardless of where their subsidiaries operate the data. AWS argues the EU entity structure narrows the exposure; legal commentary from the German BSI and the French ANSSI has not endorsed that view. Customers still need to configure for residency: enabling cross-Region replication out of the sovereign partition negates the sovereignty promise.

Microsoft Azure sovereign offerings. Microsoft splits the product into multiple sovereign tiers. Azure Government runs as a separate cloud for US Federal and Department of Defense workloads, with US-citizen-only operations and US-soil data centres. Azure China is operated by 21Vianet as a separate cloud, Chinese-owned and operated, fully decoupled identity and billing. Microsoft Cloud for Sovereignty became generally available in 2024 as a policy and architecture overlay on commercial Azure with sovereign landing zones, customer lockbox enforced, confidential computing, transparency logs, and a "Sovereign Public Cloud" architecture. It is not a separate partition; it runs on top of standard Azure commercial Regions. The Microsoft EU Data Boundary, announced 2022 and fully operational February 2025, commits Microsoft to storing and processing all customer data, system-generated logs, technical support data, and telemetry for Microsoft 365, Dynamics 365, Power Platform, and most of Azure within EU/EFTA boundaries. Completed in three phases (customer data 2023, pseudonymised personal data 2024, technical support data February 2025). Specific services excluded include certain AI services and parts of the Microsoft Threat Intelligence pipeline that depend on global signal. In June 2025, Microsoft France's legal director publicly conceded to a French Senate inquiry that EU customer data could be subject to US CLOUD Act demands regardless of EU storage. The admission was widely reported and reignited the EU sovereignty debate.

Google Cloud Sovereign Controls. Google's approach is to license its software stack to local partners who operate sovereign Regions independently. S3NS (a Thales and Google Cloud joint venture in France) achieved SecNumCloud qualification in 2024, with public regions becoming available in 2025. T-Systems Sovereign Cloud powered by Google Cloud (Germany) has been in production for German public sector since 2021. Telefónica Tech with Google Cloud Sovereign Cloud (Spain) was announced in 2023. Google Cloud Sovereign Controls also includes assured workloads, customer-managed encryption keys with external key managers, access transparency logs, and access approval, where the customer must approve Google engineer access before it happens. Confidential Computing uses AMD SEV-SNP and Intel TDX to encrypt data in use. What the partner model delivers that AWS and Azure sovereign offerings do not is a non-US legal entity operating the cloud: S3NS is majority French-owned and operated under French law. The limit is that software updates, vulnerability patches, and product evolution still originate from Google's US engineering; the sovereign operator has operational control but not source-code custody.

European-owned sovereign clouds. No US parent, no CLOUD Act exposure. OVHcloud (France) is European-headquartered and EU-listed, SecNumCloud qualified, and used by the French public sector and healthcare (the Health Data Hub migrated to OVHcloud in 2023 after a multi-year controversy over Microsoft Azure hosting). Scaleway (France, Iliad group) is SecNumCloud qualified for specific offerings. IONOS (Germany) is EU-owned with BSI C5 attestation. STACKIT (Germany, Schwarz Group) is positioned for German-jurisdiction workloads. T-Systems Open Telekom Cloud (Germany) is a sovereign OpenStack offering separate from the Google partnership. The GAIA-X initiative coordinates interoperability and data exchange standards between European clouds; industry views in 2025 and 2026 remain mixed on whether GAIA-X has delivered operational outcomes or served as a coordination forum.

MENA sovereign deployments. G42 Cloud in the UAE partnered with Microsoft in 2024 with a $1.5 billion Microsoft investment for sovereign Azure capacity in the UAE; it hosts UAE government and healthcare workloads. ADHICS V2 references UAE-region cloud capacity, which in practice means Azure UAE, AWS UAE (the Bahrain Middle East Region plus the UAE Region), and G42 Cloud. Oracle committed to two sovereign cloud regions in Riyadh and a third in Neom under Saudi data residency commitments, and launched a separate sovereign cloud Region in Israel with Israeli-resident operations. Saudi-owned alternatives include stc Cloud and Bahri Cloud, aligned with SAMA's requirements.

Five frameworks of sovereign-cloud, four hyperscaler answers, and a dozen regional alternatives. None of them removes the question; each shifts where the residual exposure lives.

Schrems II and the CLOUD Act tension

The European Court of Justice's Schrems II judgment of 16 July 2020 (Case C-311/18) invalidated Privacy Shield and held that Standard Contractual Clauses alone are insufficient where the destination country's surveillance regime permits disproportionate access. The European Data Protection Board's Recommendations 01/2020 on supplementary measures, adopted 18 June 2021, made Transfer Impact Assessments mandatory for transfers to third countries. The US CLOUD Act of 23 March 2018 allows US authorities to compel US companies and their global subsidiaries to produce data regardless of where it is physically stored. This is the single line of legal exposure that no amount of EU regional capacity solves for a US-parented cloud provider.

The EU-US Data Privacy Framework adequacy decision of 10 July 2023 currently provides a transfer mechanism, but it is under challenge in Latombe v Commission (T-553/23), and NOYB has signalled a fresh challenge. EU supervisory authorities (CNIL in France, BfDI in Germany, Garante in Italy) have consistently treated US-cloud-hosted personal data as transfer-risk regardless of Region. EDPB Guidelines 05/2021 on the interplay between Article 3 and Chapter V are explicit on a point that often surprises customers: remote access from a third country counts as a transfer. A US-based support engineer connecting to an EU Region to troubleshoot is a transfer event. This is the structural reason why "EU data centre plus US support team" is a Chapter V problem, not just an Article 28 processor problem.

The Health Data Hub controversy in France (2020 through 2023) was the canonical real-world example. CNIL and the Conseil d'État repeatedly challenged the French national health-data warehouse's hosting on Microsoft Azure on Schrems II and CLOUD Act grounds. Migration to OVHcloud was announced in 2023 and completed in stages. The pattern recurred across European public sector procurement: the BSI and ANSSI consistently distinguished "SecNumCloud-qualified sovereign cloud" (S3NS, OVHcloud, Outscale) from US-parent-operated sovereign offerings. The SecNumCloud requirement explicitly excludes US-parent control. The market signal across 2024 and 2025 was unambiguous: for the strictest European regulators, the sovereign-cloud SKU from a US-parent provider is not the answer.

The four control surfaces customers usually miss

Even customers who have made the right Region choice for their primary workload routinely miss four adjacent surfaces that produce residency events outside the Region they paid for.

Backups and disaster recovery. AWS Backup defaults to in-Region backup vaults; cross-Region copy is opt-in but routine for disaster recovery. Azure Backup and Site Recovery's geo-redundant storage replicates to a paired Region by default for some SKUs. Google Cloud Storage multi-region and dual-region buckets are explicit configuration choices but routinely selected for resilience. The architectural point is that the default knob for resilience is "more replication", and the replication is what produces the residency exposure.

Provider logs and telemetry. CloudTrail is a Regional service, but organisation trails by default deliver to one S3 bucket; if that bucket is in a non-aligned Region, every audit log is a cross-Region transfer. Azure Monitor and Log Analytics workspaces are Regional, but diagnostics settings can target a different Region. Microsoft Sentinel sits on top of Log Analytics. Google Cloud Logging and Cloud Audit Logs use Logs Router to route logs to specific Buckets; defaults are project-scoped, not Region-pinned. For a regulated workload, telemetry placement is a deployment decision that needs explicit configuration. Default behaviour rarely matches residency requirements out of the box.

Provider personnel access. AWS Premium Support is distributed globally across thirteen or more countries in a follow-the-sun model; Enterprise Support customers can negotiate jurisdictional restrictions but the standard tier does not. Azure Customer Support Services are distributed across Microsoft's global support footprint, with the EU Data Boundary committing most technical support to EU-resident engineers for in-scope services. Google Cloud Premium Support is distributed globally, with Access Approval and Access Transparency logging every engineer touch. The trade-off is real: Azure with Customer Lockbox plus EU Data Boundary offers the most prescriptive operational control; Google Cloud with Access Approval and external key managers offers the most transparent control; AWS standard tier offers the least granular, with the sovereign partition raising the bar.

AI and machine-learning services. The 2024 and 2025 surprise frontier. Provider-hosted foundation-model services often span Regions. AWS Bedrock model availability varies by Region; some foundation models are only in us-east-1 or us-west-2, with EU Region availability lagging through 2024 and 2025. Azure OpenAI Service is Region-specific for deployment, with data staying in the deployment Region, but content filtering and abuse-monitoring traffic flows through Microsoft's global abuse-detection pipeline, documented in the service-specific Azure OpenAI documentation. Google Cloud Vertex AI offers Regional models, but Gemini availability varies by Region. For a customer who has done the residency work for storage and compute, plugging in a US-Region-only foundation model is a fresh transfer event that often goes unnoticed.

What the major frameworks now require, by jurisdiction

The pattern is consistent across jurisdictions. The vocabulary differs. The direction does not.

GDPR (European Union). Article 28 governs processor relationships; Chapter V governs transfers. EDPB Guidelines 05/2021 confirm remote access from a third country counts as a transfer. Schrems II requires Transfer Impact Assessments with supplementary measures. A US-cloud-hosted EU workload requires both an Article 28 DPA and a Chapter V transfer mechanism, plus the supplementary measures the EDPB has documented since 2021.

ADHICS V2 (United Arab Emirates). Protected health information must be stored within UAE borders. Cross-border transfer, including for backup, support, or analytics, requires explicit Department of Health approval. The expanded V2 scope formally authorises Azure UAE, AWS UAE, and G42 Cloud as sovereign-region options. A US cloud provider's EU support engineer connecting to a UAE Region to fix an issue is, on a strict reading of ADHICS V2, a cross-border transfer requiring DoH approval.

FINMA Circular 2018/3 (Switzerland). Paragraphs 28 through 31 require that information necessary for restructuring and resolution remain accessible in Switzerland at all times. The phrasing is "in Switzerland", not "from Switzerland". Remote access to data physically held abroad does not satisfy. Circular 2023/1 introduced the critical-data concept with enhanced classification and protection. A Swiss bank using a US cloud's Zurich Region must demonstrate the resolution-required data set is recoverable inside Switzerland independent of the provider's continued cooperation.

SAMA Cloud Computing Regulatory Framework (Saudi Arabia). Customer data, transaction records, and business continuity backups must reside in Saudi Arabia for Saudi banks and the Saudi branches of foreign banks. The framework permits public-cloud use only where the provider operates a certified KSA Region and signs enforceable agreements granting SAMA inspection rights and prohibiting unilateral data movement. SAMA inspection rights directly against the cloud provider are unusual; most cloud providers' standard contracts disclaim direct regulator inspection. Saudi banks accordingly need cloud providers willing to sign side letters granting SAMA inspection access.

The architectural answer

The provider-agnostic conclusion is that the only way to remove the residency question from the provider's marketing is to remove the provider from the data path entirely, or to make the customer the actor who configures storage, keys, Region, and the four adjacent surfaces directly. The companion article on data residency named the same conclusion from a different angle: residency is a deployment decision, not a vendor promise. This article arrives at it from the technical underside, where every "in your Region" claim turns out to depend on default behaviours the customer never configured.

Novantra's BYO Storage makes the customer's own storage account, in the customer's selected Region, the only place customer data lives. The provider's regional presence becomes irrelevant to the residency question; the customer's storage placement is what answers it. The four adjacent control surfaces (backups, telemetry, support access, AI services) move under the same regime: backups go to a customer-controlled vault in the customer's Region, telemetry routes to a customer-controlled destination, vendor-personnel access is logged at per-record granularity into the customer's audit stream, and AI features run on provider Regions the customer pinned rather than on global model endpoints.

Novantra's customer-controlled encryption keys close the residual cooperation loop on the data plane. Even if a CLOUD Act request were served on a US-parent provider operating an EU sovereign Region, the data would be unreadable without the customer's key service responding. The companion article covers the architecture in depth.

Novantra's database-per-organisation isolation means each organisation's database lives in its own Region under its own keys with its own audit stream. A multi-jurisdictional deployment (German subsidiary plus Abu Dhabi facility plus Riyadh branch) becomes three separate Region-pinned databases, each verifiable independently by its own regulator.

For customers whose jurisdiction or threat model requires more than a customer-controlled Region inside a public cloud, Novantra's Sovereign deployment runs the entire platform inside the customer's own infrastructure, removing the cloud provider from the data path entirely.

None of this is a feature. Each is the architectural answer to a question every regulator is now asking under the words "cloud in your region": not whether the Region label is real, and not whether the provider has a Sovereign Cloud SKU, but whether the customer can demonstrate, against every control surface that actually moves data, that the data stayed where it was supposed to stay. The Region claim is a marketing label until the customer owns the configuration that makes it true. The architecture either makes the configuration the customer's, or it leaves the customer carrying the audit finding when the regulator walks past it.