Multi-Account Data Lake with Cross-Region Analytics and a Hard Residency Rule
A financial-services group runs 14 AWS accounts under AWS Organizations with consolidated billing. A central data account in eu-central-1 holds an S3 data lake (~90 TB, mostly parquet) that 9 analytics accounts read. Regulators require that customer transaction data never leaves the EU, and the security team requires that no analytics account hold standing write access to the lake. Today each analytics account has a bucket policy granting s3:* to a broad role, copied by hand into 9 policies. A new team in us-east-1 wants to join and run Athena queries. Symptoms: bucket policy is near the 20 KB limit, one account silently lost read access after a policy edit, and auditors cannot produce a per-account access report.
1. Design the access model for the lake. Which AWS mechanisms do you combine, and how does each requirement (EU residency, no standing write, per-account auditability, policy size) get satisfied?
Read the worked answer
Replace per-account bucket policies with S3 Access Points, one per analytics account (or per team), each with its own access-point policy that grants read-only actions on the required prefixes. This removes the single growing bucket policy as the bottleneck and makes each grant independently reviewable. Point each account's IAM role at its own access point ARN; the role policy allows only s3:GetObject/s3:ListBucket through that access point, so no analytics account ever holds write. Use S3 Access Grants or an attribute-based condition (aws:PrincipalOrgID plus a tag condition on the role) if the number of teams keeps growing, so onboarding is a tag change rather than a policy edit.
EU residency: keep the bucket and all access points in eu-central-1 and add a bucket policy that denies any request where aws:PrincipalOrgID matches but the request is not signed for the EU Region, or simply rely on the fact that access points are Regional and cross-Region access points are not used. Deny s3:* when aws:RequestedRegion is outside eu-*.
Auditability: enable S3 server access logging or CloudTrail data events to a log-archive account, and use access-point ARNs as the partition key in Athena so per-account usage is a one-line query. AWS Config can assert that no bucket policy grants s3:PutObject to non-data-account principals. The us-east-1 team queries Athena in eu-central-1 (Athena is Regional; the workgroup must be in the EU) - do not replicate data to us-east-1.
2. The data account owner wants to avoid managing 9+ access points by hand. What organizational structure and guardrails make onboarding a new account safe and repeatable?
Read the worked answer
Put analytics accounts in a dedicated OU under Organizations and attach an SCP that denies S3 access to buckets outside an approved list and denies any request outside EU Regions, so a misconfigured role cannot reach the lake from us-east-1 or touch another bucket. Use IAM Identity Center with permission sets that map to access points, so a new team gets a permission set assignment rather than a hand-edited policy. Provision access points and their policies with CloudFormation StackSets targeting the OU, so a new account joining the OU receives its access point automatically. Tag every analytics role with data-domain and cost-center; the access-point policy can then use a condition on aws:PrincipalTag instead of enumerating account IDs. Add a Control Tower or Config conformance pack that flags any access point policy granting write, and a monthly Access Analyzer for S3 report to prove no unintended external access. This turns onboarding into: create account, move into OU, assign permission set - no manual policy surgery.