Data Residency

Data residency refers to the legal requirement that data must be stored and processed within specific geographic boundaries. Different countries and regions have strict data sovereignty laws that dictate where citizen data can reside.

Data sovereignty requirements vary by jurisdiction. GDPR requires that personal data of EU residents be processed within the EU or in countries with adequate protection. China's PIPL requires personal data to be stored domestically. Brazil's LGPD follows similar principles to GDPR. India's DPDP Act restricts transfer of personal data outside India.

AWS region selection is the primary mechanism for data residency. When you deploy resources in eu-west-1, data physically resides in Ireland. AWS provides region-specific isolation guarantees: data in eu-west-1 never leaves that region unless you explicitly move it. Use AWS Organizations SCPs to deny resource creation outside approved regions.

SCP region restriction example: Deny all actions where aws:RequestedRegion is not in the approved list. This prevents engineers from accidentally creating resources in non-compliant regions. The SCP applies organization-wide or per-OU.

Region-specific services: Some AWS services have region-specific compliance certifications. AWS GovCloud provides FedRAMP High authorization. AWS EU regions comply with EU data protection laws. AWS China regions operate under Chinese law with separate infrastructure.

Data residency challenges: Cross-region replication for DR requires explicit approval. Logging services that aggregate data across regions may violate residency requirements. Third-party integrations that transfer data to non-approved regions need careful configuration.

Example: A European bank must store all customer data within the EU. They configure SCPs to deny resource creation outside eu-west-1, eu-central-1, and eu-west-2. CloudTrail logs are stored only in eu-west-1 S3 buckets. DynamoDB tables use only EU regions. Cross-region replication is disabled. The compliance team audits quarterly to verify no data has left the EU.

Encryption boundaries control where cryptographic keys are stored and used. Even if data is encrypted, the location of the decryption key determines data residency compliance in many jurisdictions.

AWS KMS key residency: KMS keys are region-specific. A KMS key created in us-east-1 can only encrypt and decrypt data in us-east-1. The key material never leaves the region. This provides an additional layer of data residency control: even if data were somehow accessible in another region, it cannot be decrypted without the key.

Customer-managed keys (CMKs) give you control over key policies and rotation. For compliance, use CMKs in approved regions only. The key policy can restrict usage to specific IAM principals, preventing cross-region key usage.

CloudHSM provides dedicated hardware security modules for sensitive workloads. CloudHSM clusters are region-specific and single-tenant. The key material never leaves the HSM. For the strictest compliance requirements (financial services, healthcare), CloudHSM ensures key material stays within the approved geographic boundary.

External key stores (XKS) enable use of external key management systems. If your organization requires keys to be managed in a specific on-premises HSM or third-party KMS, XKS integrates with KMS while keeping key material external. This satisfies requirements where keys must be under organizational control.

Encryption in transit: Data traveling between regions crosses the AWS global network. AWS encrypts inter-region traffic, but for strict compliance, use VPC endpoints and private connectivity to minimize data traversing public networks. TLS 1.2 or higher for all API calls.

Key rotation: Automate KMS key rotation annually. The new key version is created within the same region, maintaining residency compliance. For CloudHSM, rotate keys manually or using custom automation within the HSM.

Example: A government agency requires that all encryption keys be stored within US borders. They use KMS CMKs in us-east-1 and us-gov-west-1 only. Key policies restrict usage to specific IAM roles. Annual rotation is automated. CloudHSM is used for the most sensitive workloads, ensuring key material never leaves US-based HSMs.

Cross-border data transfer is the movement of personal data from one jurisdiction to another. GDPR restricts transfers of EU personal data to countries without adequate protection.

GDPR transfer mechanisms: EU Standard Contractual Clauses (SCCs) provide a legal framework for transfers. AWS offers SCCs as part of the Data Processing Addendum. Binding Corporate Rules (BCRs) are internal policies approved by data protection authorities. The EU-US Data Privacy Framework provides adequacy for US organizations that certify.

AWS compliance with GDPR: AWS provides GDPR-compliant infrastructure and signs Data Processing Addendums (DPAs) with customers. AWS acts as a data processor; the customer is the data controller. AWS does not access customer data without authorization.

Technical safeguards for transfers: Encryption at rest and in transit ensures data remains protected during transfer. Tokenization replaces sensitive data with non-sensitive tokens. Data masking obscures sensitive fields. These techniques reduce the sensitivity of transferred data.

AWS data processing locations: AWS publishes data processing locations for each service. For example, Amazon Rekognition processes images in the region where the API call is made. Amazon Comprehend processes text in the configured region. Review data processing locations for each service to ensure compliance.

Data localization requirements: Some countries require all data about their citizens to be stored within their borders. India, China, Russia, and Indonesia have strict data localization laws. Use AWS regions within those countries for data processing and storage.

Cross-border architecture: A global company processes EU customer data. EU data is processed in eu-west-1. Non-EU data is processed in us-east-1. Data transfer between regions is encrypted and covered by SCCs. A data classification layer identifies data origin and routes processing to the appropriate region.

EU data protection best practices: Store EU personal data in EU regions only. Implement data classification to identify personal data. Use encryption with EU-region KMS keys. Implement access controls limiting who can view personal data. Maintain records of processing activities (ROPA) as required by GDPR Article 30. Conduct Data Protection Impact Assessments (DPIAs) for high-risk processing.