A global enterprise collects and processes customer data from various regions worldwide. Due to strict data sovereignty laws (e.g., GDPR, CCPA), the enterprise must ensure that customer data originating from a specific country or economic bloc (e.g., European Union) is processed and stored exclusively within that geographic boundary. The solution needs to prevent data from being accidentally or maliciously moved outside its designated region. Which combination of AWS services and features provides the most robust and scalable solution for enforcing this data sovereignty?
- AAWS Organizations Service Control Policies (SCPs) with `Deny` rules on cross-region data transfers, combined with S3 Bucket Policies restricting `PutObject` operations to specific source IP ranges.
- BDesign separate AWS accounts for each sovereignty zone, enforce `Deny` SCPs within AWS Organizations for cross-region actions, and use S3 Bucket Policies with `aws:RequestedRegion` conditions.
- CImplement AWS PrivateLink for all inter-service communication to prevent data egress, and use AWS WAF to block traffic from non-compliant geographic locations.
- DUtilize Amazon S3 Object Lock for immutability and configure S3 Cross-Region Replication (CRR) with delete markers for disaster recovery within the same sovereignty zone.
Show answer & explanationAnswer & explanation
Correct answer: B. Design separate AWS accounts for each sovereignty zone, enforce `Deny` SCPs within AWS Organizations for cross-region actions, and use S3 Bucket Policies with `aws:RequestedRegion` conditions.
Creating separate AWS accounts per sovereignty zone provides a strong administrative and logical boundary. Enforcing `Deny` SCPs within AWS Organizations at the OU level prevents principals in those accounts from performing actions (like `s3:PutObject` or `ec2:RunInstances` in unauthorized regions) outside their designated zone. S3 Bucket Policies with `aws:RequestedRegion` further reinforce this at the resource level, preventing objects from being uploaded to a bucket if the request originated from an unauthorized region, thereby creating a multi-layered defense for data sovereignty.
Why the other options are wrong
- A. While SCPs are good, restricting `PutObject` to specific source IP ranges is not a robust solution for data sovereignty, as IP ranges can change, be spoofed, or not cover all potential data ingress points. It doesn't prevent data from being moved within AWS services to another region.
- C. AWS PrivateLink ensures private connectivity but doesn't prevent data from being moved between AWS regions if the services themselves allow it. AWS WAF is for filtering web traffic and cannot enforce data sovereignty for internal AWS service operations or cross-region data transfers at the API level.
- D. S3 Object Lock is for immutability, not data sovereignty. S3 Cross-Region Replication, even with delete markers, is explicitly designed to move data *between* regions, which directly contradicts the requirement for data to remain within a specific geographic boundary.
AWS Data Sovereignty Enforcement
Enforcing data sovereignty on AWS involves preventing data from leaving specific geographic regions, often achieved through a combination of organizational boundaries, global policy controls, and resource-level restrictions.
- AWS Organizations SCPs are key for broad 'deny' rules.
- Separate AWS Accounts/OUs create clear administrative boundaries.
- S3 Bucket Policies can enforce region-specific API calls.
- Avoid services designed for cross-region data movement.
Memory trick: Separate 'Zones' with 'SCPs' and 'Bucket Guards' to keep data home.