How to Meet Data Residency Without a Local Region

The situation

A regional bank operates in a country where the financial regulator has mandated that all customer data, including backups and replicas, reside within the country’s physical borders. AWS does not operate a Region in-country. The regulatory window is narrow: data cannot traverse outside the country, even temporarily, even encrypted.

The engineering team has a shortlist:

• AWS Local Zones in a major city within the country (where one exists).
• AWS Outposts in a data centre the bank operates.
• Building physical servers in a co-location, bypassing AWS entirely for the regulated workloads.
• Hybrid: keep regulated workloads on-prem / in Local Zone, unregulated workloads in the nearest parent Region.

The parent Region is 200ms away in network terms and in a different jurisdiction. Using it for anything customer-data-bearing is non-negotiable: the regulator will not accept it regardless of encryption.

What actually matters

The core trade in jurisdictional compute is locality in exchange for service breadth. Running in-country gives regulatory compliance; using parent-Region services gives breadth. The middle paths offer some services in-jurisdiction with async persistence to parent Region for what isn’t available locally, provided we carefully scope what goes where.

The first thing to ask is: what data exactly is regulated? Customer PII, account balances, transaction records, the regulator’s definition. Operational logs without PII: usually unregulated. Aggregated analytics: ambiguous, often unregulated if genuinely aggregate. Mapping data classes to workloads determines which must stay in-jurisdiction and which can live in parent Region.

The second is: which AWS services exist in the chosen in-country footprint? Every extension model offers a subset of the parent Region’s catalogue, and the subset varies by location. Compute, block storage, and load balancing are usually available; managed databases, object storage, and serverless are uneven. The specific catalogue for the specific site is the constraint that shapes the design.

The third is: what about services that don’t exist locally? For a regulated workload, reaching back to a parent-Region service is compliance-failing. The answer is either:

• Run the service’s function on local compute (e.g., a database on a VM rather than the managed variant that isn’t local).
• Skip the service for regulated data; use it only for unregulated operational work.
• Design the workload around what’s available.

The fourth is: data-residency enforcement. Preventing accidental data movement, a misconfigured bucket in parent Region, a backup job that replicates across borders, requires organisation-level guardrails that deny provisioning in non-local Regions for regulated accounts, plus detective rules that alert on data-movement patterns.

The fifth is: availability. In-country extension footprints are often single-AZ. For HA, the choices are: accept single-AZ risk within the footprint, deploy across two in-country sites if the country has multiple (rare), or fall back to the parent Region for DR with a data-sovereignty waiver signed by the regulator (rare again). Most regulated deployments end up accepting single-AZ regulatory availability.

What we’ll filter on

1. Data residency enforcement, is there a hard boundary?
2. Service breadth, what runs natively in the Local Zone?
3. Availability profile, single-AZ, multi-AZ, cross-Region?
4. Operational model. AWS-managed vs customer-managed?
5. Cost premium, markup over parent-Region pricing?

The residency-compliant landscape

1. AWS Local Zones. AWS-managed infrastructure in specific metros. Subset of AWS services. Data in a Local Zone stays in that metro (subject to customer-controlled backups/replicas). Carrier-agnostic. AWS operates the hardware.

2. AWS Outposts Rack / Servers. Customer-sited AWS hardware in a customer-chosen data centre. Data stays where the rack is. AWS-managed but customer-provisioned infrastructure. Covered in depth in a companion post.

3. AWS Dedicated Local Zones (newer product; location-specific AWS infrastructure for a specific customer or government, with different residency guarantees). Relevant for certain national-security / sovereign-cloud use cases.

4. Self-operated infrastructure in a co-location. Rent rack space in-country, run your own Kubernetes or VMware. Maximum flexibility, maximum overhead, no AWS-managed operations.

5. Partner “sovereign cloud” offerings. Some countries have national cloud providers (OVH in France, T-Systems in Germany). Non-AWS; not in scope for this post.

6. Parent Region with data-residency controls. Using parent Region with KMS/HSMs and signed attestations. Sometimes accepted by regulators; not usable here because the regulator has explicitly required physical in-country.

Side by side

For this regulator’s requirements: Local Zone if one exists in-country; Outposts if not. Let’s assume a Local Zone exists in the capital.

The in-country architecture

The picks in depth

Local Zone enablement. AWS accounts opt into a Local Zone through the console or API. Once enabled, the Zone appears as a “zone” alongside regular AZs. VPC subnets can be created in the Local Zone; the VPC’s CIDR must include the Local Zone’s subnet.

Instance types available in the Zone are listed in the AWS docs; not every family is present, and capacity is bounded (though typically sufficient for city-scale workloads).

The workload segmentation. All regulated workloads (customer-facing app, customer database, document storage) run in the Local Zone. Unregulated workloads (marketing site, internal dashboards for regulator reporting, CI/CD, aggregate analytics) run in parent Region.

Every resource is tagged with data-classification: regulated, public, operational, or aggregate. The tagging is required by SCP (cannot create without tag) and enforced by Config rule.

The database. RDS PostgreSQL in the Local Zone (assuming PostgreSQL is available there). Multi-AZ HA isn’t available because most Local Zones are single-AZ. Options:

• Single-AZ RDS in LZ with frequent automated backups to LZ-resident S3.
• Two EC2 instances running PostgreSQL with streaming replication if tighter control is needed than RDS gives.
• Accept the availability risk as the cost of residency; the regulator’s priority is data location, not uptime.

Backups go to an S3 bucket in the Local Zone (or, if LZ doesn’t have native S3, an EBS-backed snapshot kept in the Zone). Cross-Region snapshot copy is explicitly disabled.

S3 in the Local Zone. Some Local Zones offer S3 on Outposts-style local buckets; others require using parent-Region S3 (which is then a residency fail for regulated data). Check the specific Zone.

If native S3 isn’t available, the workaround is EBS-based storage (e.g., MinIO on EC2 in the LZ) or careful workload redesign to put only references (hashes, IDs) in a parent-Region service and the actual blob in LZ-resident storage.

The SCP layer. SCPs applied to the OU containing regulated accounts:

{
  "Sid": "DenyRegulatedResourcesOutsideLocalZone",
  "Effect": "Deny",
  "Action": [
    "rds:CreateDBInstance",
    "rds:CreateDBCluster",
    "ec2:RunInstances",
    "dynamodb:CreateTable",
    "s3:CreateBucket"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": { "aws:RequestTag/data-classification": "regulated" },
    "StringNotEquals": { "aws:RequestedRegion": "country-region-name" }
  }
}

Creating a regulated resource outside the Local Zone’s parent Region is denied. Applies uniformly, no workload in a regulated account can accidentally provision regulated data in the wrong place.

Plus:

{
  "Sid": "DenyCrossRegionBackup",
  "Effect": "Deny",
  "Action": [
    "rds:CopyDBSnapshot",
    "ec2:CopySnapshot",
    "s3:PutBucketReplication"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": { "aws:ResourceTag/data-classification": "regulated" }
  }
}

KMS and residency. KMS CMKs for regulated data are created only in the Local Zone’s parent Region. The key policies explicitly deny kms:CreateGrant for cross-Region retiring-principal patterns. Data-at-rest encryption uses these local-only keys; decryption outside the Region is impossible because the keys don’t exist there.

Config rules for drift detection. AWS Config in the regulated account with rules:

• rds-snapshot-destination-region, alert if any regulated snapshot is destined for a non-local Region.
• s3-bucket-replication-enabled, alert if regulated bucket replication goes cross-Region.
• required-tags, alert if any resource in the account is missing the data-classification tag.

Non-compliant resources generate a Security Hub finding; the SOC reviews.

Sanitised cross-border metrics. Operational monitoring (CPU, latency, error rates) doesn’t contain PII. These metrics flow from Local Zone to parent Region via CloudWatch; the auditor accepts this after a review of what’s in the metric stream. Logs with customer data are kept in-Zone; only sanitised logs cross.

A Lambda running in the Local Zone strips PII from log lines before forwarding. The stripping logic is audited annually.

A worked compliance trace

A technician in parent Region (outside the country) tries to create an RDS snapshot-copy from the regulated database to parent-Region S3.

1. API call: aws rds copy-db-snapshot --source-region <lz> --source-db-snapshot-identifier prod-backup --destination-region <parent>.
2. IAM evaluates the technician’s permissions. Assume the IAM policy allows rds:CopyDBSnapshot.
3. SCP evaluation. The regulated account’s SCP includes DenyCrossRegionBackup with resource tag regulated=true. Match.
4. API call denied with AccessDenied. CloudTrail records the deny, with the caller’s principal, the source resource tags, and the denied action.
5. A Security Hub finding is created from the Config rule monitoring such attempts. The SOC reviews. The technician is contacted; usually this is a mistake, occasionally it’s a genuine need that requires a regulator-waived exception.

The SCP prevents the outcome even if IAM allows it, the guardrail doesn’t rely on every engineer having correctly-scoped IAM.

A worked non-regulated cross-border path

A marketing-team analyst queries “how many customers signed up this month?” via a dashboard in parent Region. The query runs against an aggregated metric table (customer counts per week, no PII) that lives in parent Region. The aggregated table is populated by a daily job running in the Local Zone that reads the regulated database, computes aggregates, strips anything reidentifiable, and emits a Kinesis stream to parent Region.

The aggregate table is classified as aggregate (not regulated). SCPs don’t block its creation in parent Region. The auditor reviewed the aggregation function once and signed off; any change to it requires re-audit.

Regulated data never leaves; aggregate data does; the business gets its dashboard.

What’s worth remembering

1. Local Zones are metro-specific AWS infrastructure. Subset of services, typically single-AZ, data stays in the metro unless you replicate it out.
2. Check the service catalogue for each Zone. They vary. RDS might be there; DynamoDB probably isn’t; S3 may or may not be available locally.
3. Data classification tags drive enforcement. Every resource tagged; SCPs deny cross-Region creation of regulated resources; Config rules detect drift.
4. Availability is the residency trade. Single-AZ means RDS single-AZ, Fargate single-AZ, uptime calculations need to include the Zone’s AZ failure probability.
5. SCPs enforce what IAM policies can’t. IAM grants permissions; SCPs take them away even when IAM says yes. The boundary between regulated and unregulated workloads is built on SCP.
6. KMS key locality is a silent residency control. Keys only in the local Region; no grants that let cross-Region principals use them. Data at rest outside is undecryptable regardless of whether anyone tries.
7. Sanitised metrics can cross. Operational telemetry without PII, audited annually, is usually regulator-acceptable. Business analytics based on truly aggregate data likewise.
8. Waivers are a formal process. Exceptions to the SCPs require a written regulator waiver, a timed SCP modification, and automatic revert when the waiver expires.

The data stays here because the infrastructure, the keys, the SCPs, and the tags all say so, and the auditor can verify each one independently. The Local Zone gives us the cloud experience for regulated workloads; the parent Region still serves everything else that doesn’t cross the line.