Data Residency Architecture: Region Pinning, Customer-Held Keys and Cross-Border Data Flows

Most residency programmes fail an audit not because the database sat in the wrong region, but because something else quietly left it: a support engineer’s diagnostic bundle, a log stream shipped to a global analytics account, resource tags replicated to a control plane in another continent, or a backup vault configured for cross-region copy “just in case”. A credible data residency architecture treats the primary region as the easy part and every secondary data plane as the real attack surface.

This matters now because the sovereign cloud market moved from slideware to general availability in 2026. AWS launched its European Sovereign Cloud in January, Microsoft and Google have shipped layered sovereignty offerings, India’s DPDP Rules start biting in 2027, and the EU-US Data Privacy Framework is under appeal at the Court of Justice.

You will leave with a seven-plane model of where data actually goes, concrete guardrail patterns for AWS, Azure and Google Cloud, an honest cost and availability model for customer-held keys, and a decision path for cross-border transfers.

What this covers: definitions that hold up in front of a regulator, the 2026 offering landscape, a reference architecture, region pinning, external key management, metadata and support leakage, in-jurisdiction backup and DR, GDPR transfer mechanics, failure modes and a launch checklist.

This post is architecture analysis, not legal advice. Residency and transfer obligations depend on your sector, contracts and counsel’s reading of the law.

Context and Background

Three words get used interchangeably and should not be. Data residency is a statement about physical location: where bytes are stored and processed. It is usually a business or contractual choice, such as “all customer content stays in Frankfurt and Paris”. Data localization is a legal mandate that certain data must stay inside a country, sometimes with a copy requirement, sometimes with an outright transfer ban. Data sovereignty is broader: the data is subject to the laws, and only the laws, of a chosen jurisdiction, and no foreign authority or foreign operator can compel or obtain access to it.

The distinction is not academic. A US-headquartered provider running a region in Germany satisfies residency for most purposes. It does not, on its own, answer the sovereignty question, because a parent company may be subject to foreign legal process such as the US CLOUD Act regardless of where the server sits. That gap is what the Court of Justice’s 2020 Schrems II judgment exposed for personal data transfers, and it is why sovereignty offerings now emphasise operator residency, separate legal entities and customer-held keys rather than just geography.

The incumbents have converged on a layered menu. As of this writing (November 2026), the three hyperscalers offer roughly four tiers: standard public regions with residency commitments, a “sovereign controls” overlay on the public cloud, a physically and legally separate sovereign partition, and disconnected or partner-operated deployments. Our guide to cloud landing zone architecture with SCPs and organization policy covers the account and guardrail scaffolding this post builds on.

The regulatory tempo is also rising. The EU Data Act has applied since 12 September 2025 and, besides cloud switching rules, obliges providers to resist unlawful third-country government access to non-personal data held in the EU. India notified its Digital Personal Data Protection Rules on 13 November 2025 with most obligations, including the cross-border transfer rule, phasing in by 13 May 2027 according to Hogan Lovells’ summary. Regulated sectors add their own layers: financial supervisors, health data rules and public-sector cloud certifications such as France’s SecNumCloud.

My thesis is simple. A residency or sovereignty claim is only as strong as the weakest of seven data planes, and the only control that survives a legal compulsion order is one where the provider cannot technically produce plaintext. Everything else is a promise. Promises are useful, but they belong in the risk register, not in the architecture diagram as if they were controls.

The 2026 Sovereign Cloud Landscape, Dated

Before designing, know what you can buy. The following is a snapshot verified against vendor announcements; offerings change quarterly, so re-check before committing.

AWS. The AWS European Sovereign Cloud reached general availability on 15 January 2026 with its first region in Brandenburg, Germany, according to the AWS launch announcement. AWS states it is physically and logically separate from other AWS regions, operated exclusively by EU residents, run by a new European parent company with German subsidiaries, and that IAM, billing and usage metering run inside the EU. Customer-created metadata such as roles, permissions and configurations can stay in the EU. It launched with more than 90 services, and AWS announced sovereign Local Zones starting in Belgium, the Netherlands and Portugal. Separately, AWS KMS External Key Store (XKS), launched in November 2022, lets standard regions use root keys held in a customer HSM outside AWS.

Microsoft. Microsoft announced completion of the EU Data Boundary in February 2025, covering storage and processing of customer data, including pseudonymised personal data in system logs, inside the EU and EFTA for its core cloud services. In June 2025 it announced a Sovereign Public Cloud across European regions, a Sovereign Private Cloud on Azure Local, a “Data Guardian” control under which only Europe-resident Microsoft personnel control remote access with non-European engineer access approved, monitored and logged in a tamper-evident ledger, and External Key Management extending Azure Managed HSM to customer-held HSMs with Futurex, Thales and Utimaco. National partner clouds Bleu in France and Delos Cloud in Germany target public-sector certification. The June 2025 post gave preview status and “later this year” GA targets; confirm current availability per service and region before relying on it.

Google Cloud. In May 2025 Google restructured its offering into Google Cloud Data Boundary (sovereign controls on the public cloud, including Cloud External Key Manager and Key Access Justifications), Google Cloud Dedicated (partner-operated, starting with S3NS in France built with Thales and designed for SecNumCloud), and Google Cloud Air-Gapped (fully disconnected). Cloud EKM supports partners including Fortanix, Futurex and Thales, per the Cloud EKM documentation.

The pattern across all three is identical: residency is table stakes, operator control and key control are the differentiators, and full separation costs you service breadth. A sovereign partition with roughly 90 services is not the same platform as a public region with several hundred, and that gap drives most real-world architecture decisions.

The Seven-Plane Data Residency Architecture

Direct answer: A data residency architecture keeps every plane that can carry customer data inside the chosen jurisdiction: content, metadata, telemetry, identity, keys, backups and human support access. Region pinning enforces location, customer-held keys enforce sovereignty, and continuous evidence proves both. Residency fails at the weakest plane, not the primary database.

Figure 1: Seven-plane data residency architecture. Content, metadata, telemetry, identity, keys, backup and support access each need their own jurisdiction control.

The diagram shows users entering through an in-region edge, workloads running in a pinned region pair, and the planes that radiate from them. Content data is the obvious one. Metadata, telemetry, identity and backup flow alongside it and are where leaks usually hide. Keys sit in a customer-controlled HSM in the same jurisdiction. Provider support access arrives through an approval gate, and organisation-level guardrails constrain every region choice.

Why seven planes, not one

Each plane has a different default behaviour, and the defaults are rarely residency-friendly. Content data in a regional database stays where you put it. Metadata is different. Resource names, tags, IAM policy documents and configuration often live in a provider’s global control plane. Billing records and usage metering frequently flow to a central system. Telemetry is the worst offender, because observability tools are designed to aggregate everything into one place.

Here is the inventory I use in design reviews. Content is the customer payload: rows, objects, messages, model inputs. Metadata is everything that describes resources: names, tags, labels, schemas, policy documents. Telemetry is logs, traces, metrics, crash dumps and audit trails, which routinely contain user identifiers, IP addresses and request bodies. Identity is the directory, authentication logs and session data. Keys are the root keys and the HSM or KMS that holds them. Backup and DR covers snapshots, replicas and archive tiers. Support access covers provider engineers, your own SREs, and third-party vendors with console or API access.

A residency claim needs an answer for each one. A sovereignty claim needs the answer to be technical, not contractual, for at least content and keys.

Region pairs inside the jurisdiction

Pin workloads to a primary region and a secondary region that are both inside the jurisdiction. In Germany that might be Frankfurt plus Berlin-area capacity; in the EU more broadly it might be Frankfurt plus Paris or Ireland. For a single-country mandate with only one hyperscaler region in-country, you have three options: accept zone-level redundancy only, add a second provider or a sovereign Local Zone in-country, or run DR on customer-owned hardware.

The choice of pair should be driven by the strictest data class you will host, not by the average. If one dataset is under a national localisation rule, design the landing zone so that dataset’s accounts or projects can only reach in-country regions, while less sensitive workloads may use the broader EU set. That leads directly to data classification as the first architecture decision.

Keys are the sovereignty control

Location controls answer “where”. They do not answer “who can be compelled”. If the provider holds root keys, a lawful order directed at the provider can, in principle, produce plaintext regardless of region. If the root key lives in an HSM the customer operates, and the provider’s KMS must call out to it for every unwrap, then producing plaintext requires the customer’s cooperation, or at least the customer’s knowledge.

This is why customer managed keys for sovereignty come in three strengths, which we can label precisely. Provider-held customer-managed keys (standard CMEK) give lifecycle control and audit logs but no protection against the provider. Provider-hosted single-tenant HSMs, such as AWS CloudHSM, Azure Managed HSM or Google Cloud HSM, give dedicated hardware but still run inside the provider’s facility. External key management, such as AWS XKS, Google Cloud EKM or Microsoft’s announced External Key Management, keeps root key material outside the provider entirely. Only the third is “hold your own key” in a meaningful sense. Our deep dive on envelope encryption, KMS and HSM key management explains the wrapping hierarchy these products build on.

A subtle point: even with external keys, the service must hold plaintext data keys in memory while it processes your data. External keys protect data at rest and give you a kill switch. They do not protect data in use. If your threat model includes the operator reading memory during processing, you need confidential computing on top, which we cover in confidential AI inference with TEEs and GPU confidential computing.

Evidence is a first-class plane

Auditors and regulators do not accept “we configured it correctly”. They want continuous evidence: an inventory of every resource with its region, a record of every denied out-of-region API call, key usage logs with caller identity, and access approval records for support sessions. Design this evidence pipeline into the architecture from day one, and keep its own storage inside the jurisdiction. An evidence store in a US analytics account undermines the claim it is meant to prove.

Walk-through: Building Each Plane

This section builds the data residency architecture plane by plane, with the guardrail patterns, the leaks that bite, and the capacity and cost arithmetic that decides whether a design survives contact with production.

Region pinning as defence in depth

In any data residency architecture, region pinning is the act of making it impossible, not merely discouraged, to create resources outside the approved set. It works best as four layers, each catching what the previous one misses.

Figure 2: Region pinning in layers. Policy as code fails the merge, organisation guardrails block the API call, and continuous inventory catches drift and produces audit evidence.

The first layer is policy as code in the pipeline. A plan-time check, using a tool such as Open Policy Agent, Checkov or Terraform’s native validation, rejects any resource whose location is not in the approved list. This gives fast developer feedback, but it only covers changes that go through the pipeline.

The second layer is the organisation guardrail, which cannot be bypassed by a console click. On AWS this is a service control policy using the aws:RequestedRegion condition key. On Google Cloud it is the gcp.resourceLocations organisation policy constraint, which accepts value groups such as in:eu-locations. On Azure it is the built-in “Allowed locations” policy, plus “Allowed locations for resource groups”, assigned at management group scope with a deny effect.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideApprovedRegions",
    "Effect": "Deny",
    "NotAction": [
      "iam:*", "organizations:*", "sts:*", "support:*",
      "route53:*", "cloudfront:*", "budgets:*"
    ],
    "Resource": "*",
    "Condition": {
      "StringNotEquals": {
        "aws:RequestedRegion": ["eu-central-1", "eu-west-3"]
      },
      "ArnNotLike": {
        "aws:PrincipalARN": "arn:aws:iam::*:role/BreakGlassResidencyAdmin"
      }
    }
  }]
}

# Google Cloud organisation policy, applied at the folder for regulated workloads
name: folders/123456789/policies/gcp.resourceLocations
spec:
  rules:
    - values:
        allowedValues:
          - in:europe-west3-locations
          - in:europe-west10-locations

Notice the NotAction list in the SCP. Global services such as IAM, Organizations, Route 53 and CloudFront are not regional, so a naive region deny breaks them. Exempting them is necessary, and it is exactly where residency leaks begin. IAM policy documents, Route 53 records and CloudFront configurations live in global control planes. Treat that exemption list as a reviewed risk decision, not a copy-paste from a blog.

The third layer is service-level configuration that the guardrail cannot see. A bucket in Frankfurt can still have cross-region replication to a bucket in another approved region, which is fine, but a replication rule targeting an account in a different organisation is not caught by your SCP at all. Add explicit denies on replication and copy APIs that name destinations outside your organisation, and use resource-based policy conditions such as aws:ResourceOrgID where available.

The fourth layer is continuous inventory: AWS Config, Azure Resource Graph or Google Cloud Asset Inventory, queried on a schedule and on change events. Inventory produces two outputs. Drift alerts go to the platform team, and a daily signed snapshot goes to the evidence store. Auditors want the snapshot far more than they want your SCP JSON.

Metadata leakage: the plane nobody budgets for

Metadata leaks because engineers put data in it. A tag like customer=acme-gmbh-patient-cohort-3 or a DynamoDB table named after a client turns a residency-neutral control plane into a personal-data processor. Provider documentation typically warns against putting personal or sensitive data in resource names, tags and descriptions, precisely because those fields may be replicated or processed globally.

The fix is a naming and tagging standard enforced by policy: opaque identifiers in tags, a mapping table kept in-region, and a CI rule that rejects tag values matching patterns such as email addresses or national ID formats. The AWS European Sovereign Cloud explicitly advertises that customer-created metadata stays in the EU. In a standard region you should assume the opposite unless the provider documents otherwise.

Telemetry: the largest silent exporter

Telemetry pipelines are designed to centralise, which is the opposite of residency. Application logs routinely carry email addresses, IP addresses, session tokens and request payloads. A single OpenTelemetry exporter pointed at a SaaS endpoint in another continent can export more personal data per day than the application database holds.

Three patterns help. First, run collectors in-region and apply attribute processors that drop or hash identifiers before export; a hashed identifier is still pseudonymous personal data under GDPR, so hashing reduces risk but does not take data out of scope. Second, choose observability back ends with an in-jurisdiction tenant, or self-host. Third, route crash dumps and core files separately, because they can contain raw memory with plaintext customer data, and they are often uploaded to vendor support systems automatically.

The same logic applies to AI. Managed model endpoints increasingly offer “global” routing that sends a request to whichever region has capacity. Amazon Bedrock cross-region inference profiles and Azure OpenAI deployment types such as Global and Data Zone illustrate the spectrum: geography-scoped profiles keep processing inside a named geography, while global routing does not. Pick the geography-scoped option explicitly and pin it with policy, because defaults change between model versions.

Identity and support access

Identity is easy to forget because it feels like infrastructure. But authentication logs are personal data, and many identity providers are global services. If your IdP processes sign-ins in another jurisdiction, every login is a transfer. Check where your IdP tenant’s data is stored and where sign-in processing happens, and whether the provider offers a regional tenant.

Human access is the plane that sovereignty offerings target most directly. Microsoft’s Customer Lockbox and Google’s Access Approval and Access Transparency let customers approve or see provider engineer access in specific scenarios. Microsoft’s announced Data Guardian adds Europe-resident approval and a tamper-evident log for non-European engineers. The AWS European Sovereign Cloud addresses the same concern through EU-resident operations. Your own side matters as much: a follow-the-sun SRE rota with on-call engineers in another country makes every production session a cross-border access, which may be a transfer requiring a legal basis.

Customer-held keys: the flow and its cost

Figure 3: External key management flow. Every wrap and unwrap of a data key crosses to a customer-operated proxy and HSM, which can apply its own policy and act as a kill switch.

The sequence is the same across vendors. A storage service asks the provider KMS for a data key. The KMS forwards a wrap request to the customer’s proxy, including metadata such as the calling principal and, on Google Cloud, a Key Access Justification reason. The proxy applies its own policy, calls the HSM, and returns the wrapped key. Disabling the proxy stops new decrypt operations.

The AWS XKS announcement is unusually candid about the cost. It notes that when the external infrastructure is unavailable or slow, typically over 250 milliseconds, AWS KMS cannot operate, and failures cascade: you may be unable to start EC2 instances, invoke Lambda functions or read S3 objects. It also notes that services caching data keys, such as S3 Bucket Keys, keep working for a short period after you pull the plug. AWS recommends using XKS only where regulation or compliance demands it, and for the smallest set of critical keys. Google’s EKM documentation similarly warns that Cloud KMS does not cache external keys, that an unavailable key returns FAILED_PRECONDITION, and that some services, for example Spanner, delete a database whose CMEK key stays unavailable for more than 30 consecutive days.

Now the arithmetic, using clearly illustrative availability figures. Suppose one proxy instance is 99.9 percent available, one HSM is 99.95 percent, and one network path to the provider is 99.95 percent. In a single chain, availability is 0.999 x 0.9995 x 0.9995, about 99.80 percent, or roughly 17.5 hours of key unavailability per year. That outage takes down every dependent service, not just one application.

Duplicate each component. Two proxies in parallel give 1 – 0.001 squared, or 99.9999 percent. Two HSMs in a cluster and two diverse network paths give roughly 99.99998 percent each. The chain becomes about 99.9999 percent, close to 30 seconds a year, assuming independent failures. Real failures are correlated: a shared certificate expiry, a bad proxy deployment or a single data centre power event defeats the redundancy. So the honest planning number sits between these extremes, and the engineering effort goes into removing shared failure modes.

Request volume is the second cost. Without data key caching, each object read or write is a KMS call. An illustrative workload doing 2,000 object reads per second generates about 5.2 billion KMS requests per month (2,000 x 2,592,000 seconds). At a list price of $0.03 per 10,000 symmetric requests, which AWS published at the time of writing and you should re-verify, that is about $15,550 per month in KMS request charges alone, before your HSM costs, and every one of those requests hits your proxy. AWS states that S3 Bucket Keys can reduce KMS request costs by up to 99 percent by reusing a bucket-level key, which turns the same workload into a few hundred requests per second at most. For external keys, data key caching is not an optimisation; it is a prerequisite for both cost and availability.

Latency matters too. Keep the HSM close to the region. A customer data centre in the same metro as the cloud region typically adds single-digit milliseconds of round-trip time; an HSM in another country can add tens of milliseconds per unwrap. Those are illustrative ranges, but against a 250 millisecond ceiling they leave little room for proxy queuing under load.

Backup and DR inside the jurisdiction

Backups are where a good data residency architecture regresses during an incident. Teams turn on cross-region copy to “the nearest healthy region” in a panic, and that region is in another country. Prevent it structurally.

Configure backup vaults in two in-jurisdiction regions, with immutability such as AWS Backup Vault Lock, Azure immutable vaults or Google Cloud backup vault retention locks. Deny copy actions to any other destination at the guardrail layer. On Azure, check region pairs: geo-redundant storage replicates to the paired region, most pairs are in-country, but several newer regions have no pair and some replication options may cross borders. On Google Cloud, a multi-region bucket location such as EU keeps data within EU member states, while dual-region locations let you choose specific regions.

Encrypt backups with the same external keys, and accept the consequence: if you lose the HSM key, you lose the backups. Escrow key backups in the HSM vendor’s secure backup format, in a second in-jurisdiction facility, with a dual-control restore procedure that you actually test.

For DR capacity, size the secondary region for the critical tier only. If the sovereign partition offers one region, DR may require a second provider in-country or customer-operated hardware. Model recovery time honestly: restoring 50 TB over a 10 Gbps link at an effective 70 percent utilisation takes roughly 50 x 8,000 / (10 x 0.7) seconds, about 57,000 seconds or 16 hours, before you rehydrate indexes. If your recovery time objective is four hours, you need warm replicas, not backups.

Cross-Border Data Transfer: Where Architecture Meets Law

A sound data residency architecture reduces how often you need a transfer mechanism. It rarely eliminates the need, because support, analytics, sub-processors and global users all create flows. The architect’s job is to make each remaining flow deliberate, documented and protected.

Figure 4: Simplified GDPR transfer decision path. Adequacy and the Data Privacy Framework cover some flows; the rest need SCCs, a transfer impact assessment and technical measures such as EEA-held keys.

Under GDPR Chapter V, personal data can leave the European Economic Area on the basis of an adequacy decision, appropriate safeguards such as the Standard Contractual Clauses adopted in Commission Implementing Decision (EU) 2021/914, binding corporate rules, or narrow derogations. Schrems II, decided by the Court of Justice in July 2020, invalidated the earlier Privacy Shield and required exporters relying on SCCs to assess whether the destination’s law undermines them, which the EDPB’s Recommendations 01/2020 operationalised as a transfer impact assessment with supplementary measures.

For US recipients, the Commission adopted the EU-US Data Privacy Framework adequacy decision in July 2023. Transfers to US organisations that self-certify under the DPF rely on that decision. On 3 September 2025 the EU General Court dismissed the Latombe challenge and upheld the decision; an appeal was filed with the Court of Justice on 31 October 2025, according to WilmerHale’s analysis. As far as I could verify at the time of writing, that appeal is pending. Architecturally, that means the DPF is valid today but carries tail risk, so design flows that could fall back to SCCs without re-platforming.

Technical measures that change the legal analysis

The EDPB’s recommendations describe scenarios where encryption is an effective supplementary measure: data is strongly encrypted before transfer, and keys are retained solely under the exporter’s control in the EEA or an adequate jurisdiction. That is exactly the external key pattern. It also describes scenarios where encryption does not help: if the importer needs plaintext to provide the service, such as a support engineer reading tickets or a cloud service processing data in the clear, the keys must be available to the importer and the measure loses its force.

This is the most important architectural insight in the whole topic. External keys meaningfully reduce transfer risk for storage, backup and archive, where the provider never needs plaintext. They help far less for compute, analytics and AI inference, where the provider processes plaintext in memory. For those, the options are processing in-region, pseudonymisation with the re-identification table kept in-region, or confidential computing, where attestation proves that the operator cannot read memory. Our comparison of confidential VMs with Intel TDX, AMD SEV-SNP and Arm CCA explains how that attestation works.

Classification drives the topology

No data residency architecture scales without data classification. I recommend four residency tiers rather than the usual confidentiality tiers, because the question being answered is different. Tier R0 is public or non-personal data with no location constraint. Tier R1 is personal data where region-level residency plus standard transfer tools suffice. Tier R2 is sensitive or regulated data requiring in-jurisdiction processing, in-jurisdiction support and customer-held keys for storage. Tier R3 is data under a localisation mandate or sovereignty requirement, which lands in a sovereign partition, a partner-operated cloud or customer infrastructure.

Map each tier to a folder, management group or organisational unit, and attach the guardrails to that container. A workload’s tier then determines which regions it can use, which key protection level its CMEK must have, which telemetry exporters are permitted and which support model applies. The tier label lives on the account or project, not on individual resources, so engineers cannot downgrade it by editing a tag.

Mixed workloads are common. An IoT platform might keep device telemetry in R1, operator identities in R2 and a defence customer’s configuration in R3. Split them at the data boundary, with tokenised references crossing tiers, rather than forcing the entire platform into the most expensive tier. That split is also how you keep access to the newest managed services, which often arrive in public regions long before sovereign partitions.

Trade-offs, Gotchas, and What Goes Wrong in Data Residency Architecture

Service lag. Sovereign partitions and sovereign-control overlays support a subset of services, and new features arrive later. Teams discover mid-project that the managed vector database, the latest model family or a specific GPU type is unavailable. Check the per-partition service list before architecture sign-off, not after.

Key outages become platform outages. External key management converts your HSM team’s on-call quality into the availability of every dependent cloud service. A certificate expiry on the proxy is a full outage. Run the proxy like a tier-zero service with synthetic probes, staggered certificate rotation and game days that actually pull the plug.

Global control planes do not respect SCPs. IAM, DNS, CDN configuration and billing are global on most providers. CDN edge caches serve content from points of presence worldwide; geographic restriction features block viewers, they do not keep cached copies in one country. Use regional load balancers instead of global anycast front ends where TLS termination location matters.

Break-glass becomes the back door. Every region deny needs an exemption principal. If that role is widely assumable or lacks alerting, it becomes the standard path for “just this once” deployments. Require multi-party approval and alert on every use.

Residency washing. Marketing terms such as “sovereign” are not standardised. Ask concrete questions: who can access plaintext, under which legal entity, from which country, logged where, and what happens to operations if the parent company is ordered to comply with a foreign request? Ask for the answers in the contract.

Hashing is not anonymisation. Hashed emails in logs remain personal data if the controller can re-link them. Treat hashed or tokenised telemetry as in scope.

Exit and switching. Customer-held keys and in-jurisdiction backups are also your exit strategy. The EU Data Act limits switching charges to direct costs until 12 January 2027 and prohibits them after that date, but data gravity and proprietary formats still dominate exit cost. Our analysis of cloud data transfer and egress cost architecture covers the network side.

Practical Recommendations

Start your data residency architecture with classification, not with a product. Decide which data falls in each residency tier, which jurisdictions apply, and whether the requirement is residency, localisation or sovereignty. Only then choose between a public region with controls, a sovereign partition or a partner cloud. Most organisations end up with a mix, and that is fine as long as the tier boundaries are explicit.

Build guardrails in layers and generate evidence continuously. A single SCP is not a residency programme. Pair it with plan-time checks, service-level denies on replication and copy, an inventory scan and a signed daily evidence snapshot stored in-jurisdiction.

Use external keys narrowly and engineer them seriously. Apply them to R2 and R3 storage, backup and archive, where they change the legal analysis, and pair them with data key caching. For processing-heavy workloads, combine in-region processing with confidential computing or pseudonymisation rather than expecting keys to do the work.

Finally, treat telemetry and human access as data flows with owners. Most real residency incidents start there. For industrial and AI-heavy estates, our sovereign industrial AI cloud reference architecture shows how these ideas apply to GPU and edge workloads.

A launch checklist:

Residency tier assigned per account, project or subscription, with guardrails attached at the container.
Region deny active, with a reviewed global-service exemption list and alerted break-glass role.
Replication, snapshot copy and backup copy denied to out-of-jurisdiction or out-of-organisation destinations.
Tag and naming policy rejecting personal data patterns.
Telemetry collectors in-region, with identifier scrubbing and an in-jurisdiction back end.
External key proxy with redundant HSMs, diverse network paths, data key caching and a tested kill switch.
Support access approval enabled and your own on-call rota checked for cross-border access.
Transfer register listing every remaining cross-border flow with its legal basis and fallback.

Frequently Asked Questions

What is the difference between data residency and data sovereignty?

Data residency describes where data is physically stored and processed, usually as a business or contractual choice. Data sovereignty means the data is subject only to the laws of a chosen jurisdiction, so no foreign authority or foreign-controlled operator can compel access. A US provider’s German region gives you residency. Sovereignty additionally needs operator control, legal entity separation or, most robustly, customer-held keys the provider cannot use without your cooperation. Localization is a third concept: a legal mandate that data stays in-country.

No. GDPR does not require EU storage; it regulates transfers and processing. An EU region reduces the number of transfers, but logs, support access, sub-processors, identity providers and analytics tools can still move personal data abroad. Each of those flows needs a legal basis such as adequacy, the Data Privacy Framework or Standard Contractual Clauses. Region choice also does nothing for lawful basis, data minimisation, retention or data subject rights, which remain separate obligations.

Is the EU-US Data Privacy Framework still valid in 2026?

As of November 2026 the adequacy decision adopted in July 2023 remains in force. The EU General Court upheld it on 3 September 2025 in the Latombe case, and an appeal to the Court of Justice was filed on 31 October 2025 and was pending when this post was written. Organisations can rely on it for transfers to DPF-certified US recipients, but prudent architectures keep SCCs and technical measures ready as a fallback in case the Court of Justice rules differently.

What is hold your own key, and how is it different from customer managed keys?

Customer managed keys usually means you control the lifecycle of a key that still lives in the provider’s KMS or HSM. Hold your own key, implemented as AWS KMS External Key Store, Google Cloud EKM or Microsoft’s announced External Key Management, keeps root key material in an HSM you operate outside the provider. The provider must call your proxy for every wrap and unwrap, so you can audit, deny or cut off access. The price is availability risk and extra latency.

Do customer-held keys stop the cloud provider from reading my data?

Partly. External keys protect data at rest and give you a kill switch, so the provider cannot decrypt stored data without calling your key service. But while a service processes your data, it holds plaintext data keys and plaintext data in memory. External keys therefore help most for storage, backup and archive. For processing, combine them with confidential computing, which uses hardware isolation and attestation, or with pseudonymisation that keeps re-identification tables in-region.

Which cloud services usually break data residency?

The usual offenders are global control planes such as IAM and DNS, CDN edge caches, centralised logging and observability exporters, global AI inference routing, crash dump uploads, identity providers that process sign-ins abroad, and cross-region backup copies enabled during incidents. Resource tags and names also leak when engineers place customer names or identifiers in them. A residency review should inventory each of these explicitly rather than assuming the primary region choice covers them.

References

AWS, “AWS launches AWS European Sovereign Cloud and announces expansion across Europe”, 15 January 2026. https://press.aboutamazon.com/aws/2026/1/aws-launches-aws-european-sovereign-cloud-and-announces-expansion-across-europe
AWS News Blog, “Announcing AWS KMS External Key Store (XKS)”, November 2022. https://aws.amazon.com/blogs/aws/announcing-aws-kms-external-key-store-xks/
Microsoft, “Microsoft completes landmark EU Data Boundary”, 26 February 2025. https://blogs.microsoft.com/on-the-issues/2025/02/26/microsoft-completes-landmark-eu-data-boundary-offering-enhanced-data-residency-and-transparency/
Microsoft, “Announcing comprehensive sovereign solutions empowering European organizations”, 16 June 2025. https://blogs.microsoft.com/blog/2025/06/16/announcing-comprehensive-sovereign-solutions-empowering-european-organizations/
Google Cloud, “Google advances sovereignty, choice, and security in the cloud”, 21 May 2025. https://cloud.google.com/blog/products/identity-security/google-advances-sovereignty-choice-and-security-in-the-cloud
Google Cloud, Cloud External Key Manager documentation. https://docs.cloud.google.com/kms/docs/ekm
Google Cloud, Key Access Justifications overview. https://docs.cloud.google.com/assured-workloads/key-access-justifications
WilmerHale, “European Court of Justice to Review Challenge to EU-U.S. Data Privacy Framework”, December 2025. https://www.wilmerhale.com/en/insights/blogs/wilmerhale-privacy-and-cybersecurity-law-blog/20251201-european-court-of-justice-to-review-challenge-to-eu-us-data-privacy-framework
Hogan Lovells, “India’s Digital Personal Data Protection Act 2023 brought into force”, November 2025. https://www.hlc.com/en/publications/indias-digital-personal-data-protection-act-2023-brought-into-force-
Stephenson Harwood, “The EU Data Act: switching, interoperability and prevention of unauthorised access to non-personal data”. https://www.stephensonharwood.com/insights/the-eu-data-act-switching-interoperability-and-prevention-of-unauthorised-access-to-non-personal-data/
European Data Protection Board, Recommendations 01/2020 on measures that supplement transfer tools, version 2.0, adopted 18 June 2021. https://www.edpb.europa.eu/our-work-tools/our-documents/recommendations/recommendations-012020-measures-supplement-transfer_en

By Riju — about

Data Residency and Sovereign Cloud Architecture: Region Pinning, Customer-Held Keys and Cross-Border Data Flows (2026)

Data Residency Architecture: Region Pinning, Customer-Held Keys and Cross-Border Data Flows

Context and Background

The 2026 Sovereign Cloud Landscape, Dated