Actionable coding and infrastructure rules for implementing and maintaining strict data-residency, localization, and sovereignty requirements in modern cloud-native applications.
Your customers' data is crossing borders while you sleep. Every database write, every cache hit, every backup could be triggering a compliance violation worth millions in fines. If you're treating geography as an afterthought instead of a first-class architectural concern, you're building on quicksand.
Modern cloud development defaults to global by design. AWS services span regions automatically. Azure SQL replicates everywhere by default. Your CDN caches sensitive data at 200+ edge locations worldwide. Meanwhile, GDPR, data localization laws, and sovereignty requirements demand your data stays exactly where it belongs.
The gap between cloud-native defaults and compliance reality creates these daily developer nightmares:
us-east-1 when eu-west-1 has issuesTraditional approaches treat compliance as a post-development audit exercise. By then, your architecture is locked in, and retrofitting geographic constraints feels like performing surgery with a sledgehammer.
These Cursor Rules transform data residency from a compliance afterthought into a core development practice. Instead of hoping your deployment stays compliant, you build applications that cannot violate geographic constraints.
Here's how it works in practice:
Before: Your TypeScript service connects to whatever RDS endpoint is available
// Dangerous - region determined at runtime
const db = new RDS({ region: process.env.AWS_REGION || 'us-east-1' })
After: Geographic constraints are enforced at compile time
// Cursor Rules generate this pattern automatically
const REGION = process.env.DATA_REGION as 'eu-west-1' | 'us-gov-east-1';
if (!REGION) throw new Error('DATA_REGION env not set');
export function assertRegion(targetRegion: string) {
if (targetRegion !== REGION) {
throw new ResidencyError(`Cross-border write blocked: ${REGION} → ${targetRegion}`);
}
}
The rules establish geography as a first-class citizen in your codebase, with automatic enforcement patterns that prevent violations before they happen.
Before implementing these rules, teams typically discover compliance issues during quarterly audits. The rules prevent violations at development time - your code literally cannot compile if it attempts cross-border data operations.
Instead of manual policy reviews and post-deployment audits, compliance becomes automated. Your CI pipeline enforces residency rules the same way it enforces type safety.
When regulators demand data location proof, you have immutable audit trails automatically generated in-region. No more scrambling across multiple dashboards to prove compliance.
Developers stop second-guessing every database query or API call. The rules provide clear, enforceable boundaries that make compliant development the path of least resistance.
Traditional Approach: Developer builds export functionality, deploys to staging, discovers during security review that exported data gets temporarily stored in a cross-region S3 bucket for processing. Security team flags violation. Developer rebuilds with region-locked storage. Two-week delay.
With Cursor Rules: Developer implements export feature. Cursor automatically generates region-locked S3 client code. CI pipeline validates all storage operations stay in-region. Feature ships on schedule with built-in compliance.
// Auto-generated by Cursor Rules
const s3Client = new S3({
region: DATA_REGION,
config: new Config({ region: DATA_REGION }) // Prevents SDK fallback
});
// Cursor adds this check to every S3 operation
function putObject(bucket: string, key: string, body: any) {
assertRegion(extractRegionFromBucket(bucket));
return s3Client.putObject({ Bucket: bucket, Key: key, Body: body });
}
Traditional Approach: Product team wants to expand to EU customers. Engineering estimates 6 months to audit existing codebase, identify data flows, and implement region isolation. Legal blocks expansion until architecture review is complete.
With Cursor Rules: Existing codebase already has geographic constraints built-in. New EU region deployment requires updating configuration files and regional resource provisioning. EU customers onboarded in 3 weeks.
# Cursor Rules enforce this pattern across all data operations
@residency_required
def create_customer_record(data: CustomerRecord):
if data.classification == DataClass.CONFIDENTIAL_EU:
assertRegion('eu-west-1')
return customer_db.insert(data)
Traditional Approach: Integration with new payment processor requires data sharing. Legal and security teams spend weeks reviewing processor's data handling policies and geographic infrastructure. Integration delayed while teams negotiate data processing agreements.
With Cursor Rules: Integration code automatically includes residency validation. Third-party API calls include region verification. Integration can proceed immediately with automatic compliance validation.
.cursor-rules/data-residency.jsonexport DATA_REGION="eu-west-1" # or your compliance region
export ALLOWED_REGIONS="eu-west-1,eu-west-2"
// Cursor automatically suggests this pattern
const REGION = process.env.DATA_REGION as 'eu-west-1' | 'us-gov-east-1';
if (!REGION) throw new Error('DATA_REGION env not set');
Cursor Rules will automatically suggest geographic validation patterns when you:
Accept the suggestions to build compliance into your application architecture.
Add compliance validation to your deployment pipeline:
# .github/workflows/compliance.yml
- name: Validate Data Residency
run: |
terraform plan -var="allowed_regions=$ALLOWED_REGIONS"
npm run test:compliance
python -m pytest tests/residency/
AWS: Enable Service Control Policies to prevent resource creation outside approved regions
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": ["eu-west-1", "eu-west-2"]
}
}
}]
}
Azure: Implement resource policies at the Management Group level GCP: Configure VPC Service Controls with region restrictions
Ready to build applications that are compliant by construction? These Cursor Rules transform data residency from a development constraint into a competitive advantage. Your future self will thank you when the next regulatory audit becomes a non-event instead of a fire drill.
# You are an expert in data-residency-aware cloud development (AWS, Azure, GCP), TypeScript, Python, Kubernetes, Terraform, Data-Privacy Vaults, DSPM, and automated compliance tooling.
---
## Key Principles
- Treat geography as a first-class architectural concern; every datum has a lawful location.
- Design for **regional isolation by default**; cross-border traffic must be explicit, logged, and justified.
- Classify data at creation (e.g., `PUBLIC`, `CONFIDENTIAL-EU`, `PHI-US`); store classification alongside the record.
- Encrypt *everywhere*: HTTPS/TLS in transit, AES-256/KMS at rest, client-side field-level encryption for highly sensitive data.
- Minimise replication; if required, replicate only within allowed jurisdictions.
- Prefer managed regional services (RDS-regional, Azure SQL-zonal) over global endpoints.
- Fail fast on residency violations; never silently fall back to non-compliant regions.
- Comprehensive, immutable audit trails are mandatory; logs must stay in-region.
- Automate policy checks (OPA, HashiCorp Sentinel, AWS Config, Azure Policy).
- Foster continuous collaboration between Legal, Security, Ops, and Engineering.
---
## Language-Specific Rules
### TypeScript (Node.js)
- Keep region in process scope:
```ts
const REGION = process.env.DATA_REGION as 'eu-west-1' | 'us-gov-east-1';
if (!REGION) throw new Error('DATA_REGION env not set');
```
- Export a **single residency guard** for all I/O:
```ts
export function assertRegion(targetRegion: string) {
if (targetRegion !== REGION) {
throw new ResidencyError(`Cross-border write blocked: ${REGION} → ${targetRegion}`);
}
}
```
- Use typed enums for classification:
```ts
export enum DataClass { PUBLIC, CONFIDENTIAL_EU, PHI_US }
```
- Disallow wildcard `*` in AWS SDK calls (`s3.getObject({Bucket: '*', ...})`).
- Lint rule: `no-global-service-endpoint` – forbid endpoints without explicit region suffix.
- Unit tests must stub cloud SDKs with **region-locked mocks** (e.g., `aws-sdk-mock` + region assertion).
### Python (Data Jobs, Lambdas)
- Central constant:
```python
DATA_REGION = os.environ["DATA_REGION"] # raises KeyError if undefined
ALLOWED_REGIONS = {"eu-west-1", "us-gov-east-1"}
if DATA_REGION not in ALLOWED_REGIONS:
raise RuntimeError("Invalid deployment region")
```
- Use **boto3** with explicit `region_name=DATA_REGION`; disable SDK fallback:
```python
s3 = boto3.client('s3', region_name=DATA_REGION, config=Config(region_name=DATA_REGION))
```
- Create Pydantic models embedding classification:
```python
class CustomerRecord(BaseModel):
name: str
email: EmailStr
classification: DataClass = DataClass.CONFIDENTIAL_EU
```
- Decorator for enforcement:
```python
def residency_required(func):
def wrapper(*args, **kw):
if threading.current_thread().name != DATA_REGION:
raise ResidencyError('Thread off-region')
return func(*args, **kw)
return wrapper
```
---
## Error Handling & Validation
- **Detect early**: first lines of every data-access function call `assertRegion()` / `residency_required`.
- Return structured error objects: `{ code: 'RESIDENCY_VIOLATION', region: source→target }`.
- Implement **soft-delete** instead of sync replication across borders.
- Automated log alerts: 1 violation ⇒ page SRE + Compliance.
- Add retry logic for transient *in-region* failures; never retry by switching region.
- Maintain warm standby **inside** the jurisdiction (e.g., multi-AZ within eu-west-1).
---
## Framework-Specific Rules
### AWS
- Enable **AWS Organizations Service Control Policies** to *deny* `Create*` outside approved regions.
- S3: specify `LocationConstraint`, block public access, enable **Object Lock** + KMS key `X-EU-KMS`.
- RDS: use **Multi-AZ** but disable cross-region read replicas.
- DynamoDB GlobalTables: limit `replicaRegions` to compliant list.
- CloudTrail + CloudWatch logs stored in same region bucket.
### Azure
- Create **Management Group Policy**: `location == 'northeurope' || location == 'uksouth'`.
- Use **Customer-Managed Keys** in Azure Key Vault Hosted in region.
- Configure **Private Link**; deny public endpoint exposure.
### Google Cloud Platform
- Use **VPC Service Controls** with `restricted_services` for data APIs.
- Set bucket `locationType` to `single-region` (e.g., `europe-west3`).
- Cloud KMS keyrings per location; disallow dual-region keys.
### Kubernetes (on any cloud)
- Label nodes by region & zone (`topology.kubernetes.io/region`).
- Use `nodeSelector` / `affinity` to schedule workloads in-region.
- PersistentVolumeClaims must reference regional storage classes only.
- Disallow `hostNetwork: true` unless necessary and justified.
### Terraform
- Write a **`data_residency.tf`** module exporting allowed regions variable.
- Sentinel policy: `aws_instance.region in allowed_regions`.
- CI step `terraform compliance` must pass before merge.
---
## Additional Sections
### Testing
- CI pipeline stage `compliance-tests` executes OPA policies, Cloud Config Rules, GDPR unit tests.
- Quarterly penetration + red-team tests inside jurisdictional boundaries.
- Chaos engineering: simulate regional outage; verify failover remains in-region.
### Performance Patterns
- Prefer edge caches (CloudFront regional edge, Azure CDN POP) fronting in-region origins.
- Use **local processing** (Lambda@Edge, Cloudflare Workers) to avoid shipping raw PII.
### Security
- Secrets never leave region; use regional secrets manager.
- Rotate KMS/Key Vault keys at least every 90 days.
- Enable DLP scanners within vaults; quarantine non-compliant files instantly.
### Documentation & Transparency
- Maintain public-facing Residency Whitepaper detailing: regions used, encryption, audit process.
- Update after any architectural change within 30 days.
---
## Glossary
- **Residency**: Physical/geographic storage location of data.
- **Localization**: Restriction forcing storage/processing within a country.
- **Sovereignty**: Data subject to laws of hosting jurisdiction.
---
## Common Pitfalls & How to Avoid Them
- "Hidden" cross-region defaults (e.g., AWS Lambda snapshots) → always set `region` explicitly.
- Using global DNS that resolves to nearest edge → ensure edge forwards only to in-region origin.
- Mixing telemetry with app data → send logs to region-specific endpoints.
---
Follow these rules to ship fully compliant, transparent, and performant applications that respect every data-residency mandate while still enabling rapid feature delivery.