AWS Organizations EU Alternative 2026: Multi-Account Governance, CLOUD Act Cascade, and GDPR

Post in the sota.io EU Compliance Series

AWS Organizations is Amazon's managed service for multi-account governance. It lets large teams and enterprises group AWS accounts under a central management structure — a management account (formerly called the master account) that controls billing, service control policies (SCPs), and governance across dozens or hundreds of member accounts. AWS Control Tower builds on Organizations to provide an automated "landing zone": a pre-configured multi-account environment with guardrails, baseline security controls, and account provisioning workflows.

These services are foundational infrastructure for enterprise AWS usage. Organizations manages the hierarchy that lets an EU fintech run separate AWS accounts for production, staging, analytics, and security — with central governance enforced by SCPs. Control Tower provisions new accounts with compliant baselines. The appeal is real: consistent governance, centralized billing, policy enforcement at scale.

European enterprises running this setup on AWS commonly assume that because their member accounts use EU regions — eu-central-1 (Frankfurt), eu-west-1 (Ireland) — their data is protected by EU law. This assumption ignores the organizational control plane.

Amazon Web Services, Inc. is a Delaware corporation headquartered in Seattle, Washington. The management account in AWS Organizations is the root of authority for the entire account hierarchy. It controls billing, can apply SCPs that override any IAM policy in any member account, and has access to consolidated logs across the organization. This management account — regardless of which AWS region you configure it in — is operated by a US company subject to the CLOUD Act (18 U.S.C. § 2713).

How AWS Organizations Creates a Jurisdiction Cascade

To understand why Organizations creates a unique GDPR problem, it is necessary to understand what the management account actually controls.

Service Control Policies (SCPs): SCPs are policies attached to organizational units (OUs) or individual member accounts. They define the maximum permissions any IAM identity in those accounts can have — they override account-level IAM policies. The management account creates and deploys SCPs across the entire organization. This means the management account has authoritative governance control over every resource in every member account: which services can be used, which regions can be accessed, and which operations are permitted. That governance control is subject to US jurisdiction.

Consolidated Billing and Cost Data: All billing flows through the management account. The consolidated billing records show which services all member accounts use, the volume of API calls, data transfer quantities, and resource utilization across the entire organization. At scale, this data profile reveals what your organization does with AWS — its compute patterns, storage volumes, data transfer flows, AI/ML workloads. This is organizational intelligence stored in and accessible to the management account under US jurisdiction.

AWS CloudTrail Organization Trails: Organizations supports "organization trails" — a single CloudTrail configuration in the management account that captures API activity across all member accounts. When an organization trail is enabled, every API call made in every member account is logged to a central S3 bucket. The identity of who did what, when, where, to which resource, across every account in your organization — consolidated under management account control.

AWS Config Aggregator: Organizations integrates with AWS Config to aggregate configuration data from all member accounts into a single management account dashboard. Every EC2 instance, every S3 bucket, every RDS database, every Lambda function configuration across all member accounts is visible in the aggregated Config view. This configuration data is stored in and accessible from the management account.

AWS Control Tower Data: Control Tower adds its own layer of organizational intelligence. The Account Factory records all account provisioning — who requested what account, when, for which purpose. Guardrail compliance data shows which accounts are compliant or non-compliant with baseline security controls. The Control Tower dashboard in the management account gives a real-time compliance view of the entire organization.

The Cascade Logic: A single CLOUD Act order served on Amazon and directed at the management account can reach: consolidated billing data showing your entire AWS footprint, organization trail logs showing all API activity across every account, Config aggregator data showing every resource configuration across every account, Control Tower compliance records, and the SCP definitions that govern your entire organization's permissions structure. None of this requires separate orders for each member account.

GDPR Analysis: Five Compliance Risks

1. Art.5(1)(f): Organizational Governance Data as Personal Data

AWS Organizations stores data that is personal data under GDPR Art.4(1). CloudTrail organization trails capture IAM principal identifiers (user ARNs, role ARNs, federated identity names) alongside every API call. These identifiers directly link to individual employees. A log entry showing that arn:aws:iam::123456789012:user/maria.mueller accessed a specific S3 bucket at a specific timestamp is personal data: it identifies an employee and records their activity.

Art.5(1)(f) requires appropriate security — including protection against unauthorized access. Where the authorization control for access itself resides with a US entity under CLOUD Act jurisdiction, the organizational governance data processed across all member accounts is reachable by US government order. This creates a structural tension with GDPR Art.46 requirements for transfers to third countries.

2. Art.44-49: Transfers via CLOUD Act Governance Control

The Schrems II ruling (C-311/18, July 2020) established that Standard Contractual Clauses cannot by themselves justify transfers to third countries where the law of that country prevents compliance with the clauses. The CLOUD Act creates an obligation on US-domiciled entities to disclose data regardless of where it is stored. AWS's Data Processing Addendum and SCCs cover customer data. They do not eliminate the structural disclosure obligation the CLOUD Act creates for Amazon as a US company.

For multi-account organizations, the legal complexity compounds: the management account's access to consolidated data across all member accounts creates a de facto cross-organizational data pooling that may not be adequately covered by the DPAs established for individual member accounts.

3. Art.35: DPIA Requirement for Large-Scale Cross-Border Processing

The combination of multi-account governance, organization trail logging, and consolidated Config aggregation constitutes large-scale systematic processing of personal data (employee activity data) across organizational boundaries. GDPR Art.35(1) requires a Data Protection Impact Assessment before processing that is likely to result in a high risk to natural persons. Running AWS Organizations with organization trails and Config aggregation — systematically processing employee API activity across all accounts — is precisely the kind of large-scale systematic monitoring that triggers a DPIA requirement.

Many enterprises running AWS Organizations have not conducted DPIAs for their organizational governance layer. The organizational trail and Config aggregator are often configured for operational convenience, not recognized as personal data processing.

4. NIS2 and DORA: Governance Infrastructure as Critical ICT

For enterprises covered by NIS2 (essential and important entities) or DORA (financial entities), the organizational governance layer is not peripheral — it is critical ICT infrastructure. A compromise of the management account, or a CLOUD Act disclosure of organization trail data, could expose the entire security configuration of an enterprise's AWS estate: every SCP, every guardrail configuration, every account provisioning record, every API activity pattern.

NIS2 Art.21 requires security measures proportionate to the risk. DORA Art.5-9 requires ICT risk management frameworks with specific provisions for cloud service providers. Both frameworks require identifying and managing the risks of critical ICT dependencies — which explicitly includes organizational governance infrastructure. Placing this governance layer in a US-controlled management account is a concentration risk that NIS2 and DORA-covered entities should explicitly document and assess.

5. Art.5(1)(e): Data Minimization and Retention in Consolidated Logs

Organization trail logs retained in centralized S3 buckets can accumulate years of employee activity data across all accounts. Art.5(1)(e) requires data to be kept no longer than necessary. Many organizations configure organization trails without explicit retention policies — the S3 lifecycle rules default to indefinite retention. The result is multi-year archives of all employee API activity across all accounts, stored in management account infrastructure under US jurisdiction.

AWS European Sovereign Cloud: Does It Solve This?

The AWS European Sovereign Cloud (ESC) is Amazon's response to EU data sovereignty concerns. It operates under AWS's European economic area structure and is subject to additional contractual data protection commitments.

For AWS Organizations and Control Tower, the ESC does not resolve the governance cascade problem for existing commercial AWS organizations. Enterprises running mixed commercial + ESC environments still have a management account structure. The ESC scope is limited — not all AWS services are available in the ESC, and the organizations that would benefit most from ESC governance (large enterprises with many accounts) are precisely those where migrating the management account to ESC is most complex.

EU-Native Alternatives for Multi-Account Governance

OpenTofu / Terraform Landing Zones on EU Infrastructure

The open-source alternative to Control Tower is an OpenTofu (Terraform-compatible) landing zone implemented directly on EU-jurisdiction cloud providers. This approach:

• Uses infrastructure-as-code to define account/project structure, billing boundaries, and security baselines
• Implements governance through code rather than a US-controlled SaaS control plane
• Runs on providers subject exclusively to EU jurisdiction: Hetzner Cloud, OVHcloud, Scaleway, IONOS

The tradeoff: higher initial implementation effort. The benefit: governance infrastructure that is not subject to CLOUD Act jurisdiction at any layer.

Scaleway Organizations: Scaleway provides an account organization feature for grouping projects under a common billing and governance structure. Scaleway is headquartered in Paris, France, and operates under French and EU law exclusively. For smaller organizations (under 20 projects), Scaleway Organizations covers the multi-account governance use case with full EU jurisdiction.

OVHcloud Projects and Vaults: OVHcloud provides project-level organization for resource management. OVHcloud is headquartered in Roubaix, France. For teams already running workloads on OVHcloud, the native project structure avoids the US jurisdiction problem entirely.

STACKIT (Schwarz Group): STACKIT is the cloud platform of the Schwarz Group (Lidl, Kaufland). It operates in German data centers under German law. STACKIT offers organization-level account structures for enterprise customers with explicitly EU-jurisdiction governance.

sota.io: Platform-Level EU Governance

For teams running applications rather than raw infrastructure, sota.io provides project-level isolation with EU-native infrastructure on Hetzner Cloud. Rather than managing AWS account hierarchies, governance boundaries are defined at the platform level — each environment (production, staging, preview) is isolated, billed separately, and runs on infrastructure subject exclusively to EU law.

The key difference: your application governance layer is not a US company's managed service. The control plane for your project structure is sota.io itself, operating on EU infrastructure.

Migration Path: Decoupling from AWS Organizations

For teams currently running multi-account AWS Organizations with EU data:

1. Audit the management account's data scope. Identify: what organization trail logs are retained, what Config aggregation is active, what data is consolidated in the management account.
2. Assess CLOUD Act exposure. Document which personal data flows through organizational trails and Config aggregation.
3. Conduct a DPIA if not already done. The combination of systematic cross-account employee activity logging and US jurisdiction governance control likely requires a DPIA under Art.35.
4. Evaluate ESC for the management account. For enterprises committed to staying on AWS, migrating the management account to the AWS ESC scope is the most direct CLOUD Act mitigation — with the caveats noted above.
5. For new architectures: build governance in code. New multi-project EU infrastructure should implement governance through OpenTofu landing zones on EU-jurisdiction providers from the start.

Summary

AWS Organizations and Control Tower solve a real enterprise problem — multi-account governance at scale — but they solve it by placing the governance control plane in a US company's managed service subject to the CLOUD Act. The organizational cascade effect means that a management account under US jurisdiction creates CLOUD Act reach across all member accounts and their consolidated logs, billing data, and configuration records.

For EU enterprises processing personal data across multi-account AWS architectures, this creates five concrete GDPR risks: personal data in organization trails, transfer compliance gaps under Schrems II, DPIA obligations for systematic employee activity monitoring, NIS2/DORA requirements for critical ICT governance, and data minimization failures in indefinitely retained consolidated logs.

EU-native alternatives — OpenTofu landing zones on Scaleway, OVHcloud, or Hetzner; Scaleway Organizations; STACKIT for German enterprises — address the jurisdiction problem by design. For teams that need a managed platform rather than raw infrastructure governance, sota.io provides EU-native project isolation without the CLOUD Act exposure of an AWS Organizations hierarchy.

Part of the sota.io AWS EU Alternative Series — the most comprehensive GDPR analysis of individual AWS services available.