AWS Control Tower EU Alternative 2026: Multi-Account Governance, GDPR Landing Zone Gaps, and CLOUD Act Access to Your Entire AWS Organization

Post #794 in the sota.io EU Compliance Series

AWS Control Tower is the managed service for setting up and governing multi-account AWS environments. It provisions a Landing Zone — a baseline AWS Organizations structure with dedicated accounts for logging, auditing, and governance — and enforces mandatory and elective guardrails across every account in your organization. It automates the infrastructure that AWS's own Well-Architected Framework recommends for any serious multi-account deployment.

It is not in the AWS European Sovereign Cloud service catalog.

That absence is more significant than it might appear, because Control Tower is not just another service running in your AWS accounts. It is the governance layer that sits above your entire AWS organization. Control Tower's Audit Account aggregates CloudTrail logs from every child account. Its Log Archive account stores six years of your organization's configuration history. Its Account Factory automates the provisioning of new accounts using blueprints you define. If any single service represents "the entire AWS organization," it is Control Tower.

When Control Tower is not in the ESC catalog, the governance layer that spans your entire multi-account AWS estate — including any ESC-compliant workloads within it — operates outside the enhanced data residency and access control guarantees that ESC provides.

This guide examines the five GDPR issues that AWS Control Tower raises, explains why the ESC catalog gap matters structurally, and identifies the EU-sovereign approaches to multi-account governance that avoid the US-jurisdiction dependency.

What AWS Control Tower Does

AWS Control Tower automates the setup and ongoing governance of multi-account AWS environments according to AWS's best practices.

Core components:

• Landing Zone: A baseline multi-account structure with a Management Account, a Log Archive account, an Audit account, and a Security account. Control Tower provisions these automatically during setup.
• Account Factory: An automated account provisioning service that creates new AWS accounts within your organization using Account Factory for Terraform (AFT) or the native Control Tower console, with baseline controls applied automatically.
• Guardrails (Controls): Policy rules implemented as AWS Config rules or Service Control Policies (SCPs) that enforce security and compliance requirements. Mandatory guardrails cannot be disabled; elective guardrails can be enabled per organizational unit.
• Audit Account: A dedicated account that aggregates AWS Config findings and CloudTrail logs from all member accounts into a centralized location. It provides cross-account visibility into compliance status across your entire organization.
• Log Archive Account: A dedicated S3-based logging account that stores all CloudTrail logs and AWS Config snapshots from every member account, with a default retention of six years.

Scale context: A large organization running 50 AWS accounts through Control Tower generates centralized CloudTrail and Config data covering all compute actions, API calls, configuration changes, and security findings across every account. That aggregated governance data is stored in the Log Archive account indefinitely (up to the configured retention), giving AWS control over a comprehensive record of everything your organization has done in AWS.

ESC status: AWS Control Tower is absent from the AWS European Sovereign Cloud service catalog. The governance layer that spans your entire AWS organization — including ESC-catalog services running in child accounts — operates without ESC-level data residency and operator access restrictions.

GDPR Issue 1 — Art. 30: The Cross-Account Audit Aggregation Accountability Gap

GDPR Art. 30 requires controllers to maintain a Record of Processing Activities (RoPA) documenting the purposes, categories of data subjects, data categories, recipients, transfers, and retention periods for each processing activity. Control Tower's architecture creates a RoPA compliance problem that most DPAs do not anticipate.

The aggregation problem: Control Tower's Audit Account and Log Archive Account collect data from every member account in your organization. That data includes CloudTrail records of API calls made by human users — developers, administrators, automated processes running under named service accounts — and AWS Config snapshots that record the configuration state of every resource those users created or modified. This aggregated log is a record of the personal data processing activities of your entire technical workforce.

The accountability question: Who is the data controller for the consolidated audit record in the Log Archive Account? Your organization provisioned the Log Archive Account. But AWS operates the infrastructure, stores the data, and retains the ability to access it. The consolidated audit record is stored in an S3 bucket that AWS manages at the infrastructure level. This is a standard processor relationship for the storage — but the data aggregation and cross-account collection was automated by Control Tower itself.

The RoPA documentation gap: Most organizations document their AWS deployments in their RoPA at the service level — "we use EC2 for compute, S3 for storage." Very few document the centralized audit collection function of Control Tower specifically, with its cross-account scope, six-year retention, and the categories of personal data embedded in CloudTrail events (user identifiers, IP addresses, session tokens, operation timing). The Log Archive Account's contents — which include personal data across your entire organization's AWS footprint — need their own RoPA entry with explicit purpose documentation.

Practical exposure: If a DPA conducts an audit of your data processing records and finds that your RoPA does not account for the centralized collection and six-year retention of cross-account CloudTrail personal data in the Log Archive Account, you have an Art. 30 documentation gap. This is not hypothetical — Log Archive Account contents are systematically overlooked in GDPR documentation programs because they are provisioned automatically by Control Tower and perceived as "just logging infrastructure" rather than a personal data store.

GDPR Issue 2 — CLOUD Act: Your Entire AWS Organization's Governance Layer Is a Single Disclosure Target

The US CLOUD Act allows US law enforcement to compel US companies to produce stored communications and records regardless of physical data location. AWS is a US company. Control Tower's Log Archive Account stores CloudTrail logs from every account in your organization — typically six years of complete API history.

What a CLOUD Act production order against your Log Archive Account reveals:

The CloudTrail data in the Log Archive Account is not just security telemetry. It contains:

• Every API call made by every user in every AWS account across your organization
• The identity of the user making each call (IAM user ARNs, Identity Center user IDs, role assumption chains)
• The timing, source IP, user agent, and request parameters of each API call
• Error responses that reveal what actions users attempted but were denied
• Cross-account role assumption events that show which users accessed which accounts when

For a US law enforcement agency, a single production order covering the Log Archive Account is more informative than production orders against individual services — it provides a unified view of everything your organization did in AWS, correlated by identity and time.

The ESC gap: ESC-catalog services come with restricted operator access controls. Control Tower is not in the ESC catalog. The Log Archive Account that stores six years of your organization's complete activity is standard AWS infrastructure without ESC-level access restrictions.

Transfer Impact Assessment requirement: Post-Schrems II, your TIA for AWS services must assess CLOUD Act risk realistically. Control Tower's Log Archive Account is a high-value CLOUD Act disclosure target — its centralized, cross-account, multi-year scope makes it more sensitive than any individual AWS service's logs. Most TIAs for AWS do not identify Control Tower specifically as a risk concentration point.

GDPR Issue 3 — Art. 5(1)(e): Six-Year Log Retention Without Purpose Review

GDPR Art. 5(1)(e) (storage limitation) requires that personal data be kept in a form that permits identification of data subjects no longer than necessary for the purposes for which the personal data are processed.

Control Tower's Log Archive Account default configuration retains CloudTrail logs for six years and AWS Config snapshots for seven years. These are AWS's recommended defaults, derived from general regulatory guidance for financial services and government sectors.

The purpose-retention mismatch: The stated purpose of the Log Archive Account is security auditing and compliance verification. Six-year retention is justified under financial sector regulations (MiFID II, SOX) and government compliance frameworks. But most organizations running AWS Control Tower are not financial services firms or government agencies — they are software companies, SaaS providers, and enterprises whose regulatory retention requirements do not mandate six-year CloudTrail retention.

The personal data scope: CloudTrail logs contain personal data: user identifiers, IP addresses, session context, and behavioral patterns are all personal data under Art. 4(1) GDPR if they are linked to identifiable individuals. For organizations with employee turnover, the Log Archive Account will contain personal data of former employees extending back to the date of Control Tower deployment — potentially years past the end of the employment relationship and thus beyond the retention basis.

The default-acceptance problem: When organizations deploy Control Tower using AWS defaults, they inherit the six-year retention without explicitly assessing whether that retention period is proportionate to their actual security and compliance requirements. Under Art. 5(1)(e), the default is not a legal basis — the organization must independently determine and document a retention period that is "no longer than necessary" for its specific purposes, even if that period is shorter than AWS's recommended default.

Practical requirement: Your Control Tower deployment should document an explicit retention period for the Log Archive Account that reflects your organization's actual regulatory requirements and purpose scope — not AWS's general defaults — and configure S3 lifecycle policies accordingly. For most software companies, 90-day to 2-year CloudTrail retention is sufficient for security investigation purposes; six years is rarely justified outside regulated sectors.

GDPR Issue 4 — Art. 25: Landing Zone Guardrails Have No GDPR-Specific Privacy Controls

GDPR Art. 25 (data protection by design and by default) requires that data protection principles be embedded into the design of processing systems from the outset. Control Tower's guardrail library includes security controls, configuration enforcement, and operational best practices — but it does not include GDPR-specific privacy controls.

What Control Tower guardrails cover:

• Security baseline (root account MFA, CloudTrail enabled, S3 public access blocked)
• Infrastructure configuration (EC2 encryption, RDS backup, EBS encryption)
• Detective controls (AWS Config rules for resource compliance)
• Operational controls (IAM password policy, access key rotation)

What Control Tower guardrails do not cover:

• Data subject rights workflows (no guardrail enforces right-to-erasure capability for data stored in member accounts)
• Data minimization (no guardrail prevents collection of personal data fields beyond stated purposes)
• Consent management (no guardrail enforces consent tracking for personal data processing)
• Privacy Impact Assessment triggers (no guardrail requires DPIA documentation for high-risk processing)
• Cross-border transfer controls (no guardrail prevents personal data from being transferred to non-EU regions via cross-account replication)

The Art. 25 design gap: AWS Control Tower embeds security by design into your multi-account architecture. But GDPR requires privacy by design — a broader obligation that includes the data subject rights infrastructure, minimization controls, and purpose limitation enforcement. A Landing Zone built purely on Control Tower guardrails is secure by design but not privacy-by-design in the GDPR sense.

Practical implication: Organizations deploying Control Tower should supplement AWS's guardrail library with custom Config rules or SCPs that enforce GDPR-specific controls: blocking data replication to non-EU regions, requiring encryption key ownership in EU-jurisdiction KMS, enforcing tagging of resources that process personal data, and triggering review workflows for services associated with high-risk processing. None of these are provided by Control Tower out of the box.

GDPR Issue 5 — Art. 17: Account Closure via Account Factory Does Not Erase Your Data

GDPR Art. 17 (right to erasure) and Art. 5(1)(e) (storage limitation) require that personal data be erased when the legal basis for processing ends or upon a valid erasure request. Control Tower's Account Factory provides account provisioning and closure workflows — but account closure in AWS is not data erasure.

The account closure sequence in Control Tower:

1. Account removal initiated via Account Factory or Control Tower console
2. AWS Organizations removes the account from the organization
3. The account enters a suspended state for 90 days before final closure
4. CloudTrail logs from the closed account's pre-closure activity remain in the Log Archive Account
5. AWS Config snapshots for the closed account remain in the Log Archive Account
6. S3 data, database contents, and application data in the closed account are deleted when the account is finally closed — but only after the 90-day suspension period

The data erasure gap: Closing an AWS account through Account Factory does not erase the audit records in the Log Archive Account that accumulated during that account's existence. If the closed account processed personal data — as virtually all production accounts do — the CloudTrail records of that processing persist in the centralized Log Archive Account for the configured retention period (default: six years) after the account is closed.

Practical scenario: A company acquires a startup, integrates its infrastructure into the corporate AWS organization via Control Tower, processes that startup's customer data in the acquired accounts for two years, then divests the business unit and closes the acquired accounts. The customer data in the acquired accounts is deleted with account closure. But the CloudTrail records of all personal data processing that occurred in those accounts — API calls that touched customer records, user identities that accessed customer data, IP addresses of customers who accessed the service — remain in the corporate Log Archive Account for years.

The GDPR obligation: When the legal basis for processing personal data ends (business divestiture, contract termination, customer erasure request), the obligation to erase extends to audit records that identify data subjects — not just to application databases. The Log Archive Account's persistent CloudTrail records represent a structural erasure gap that Control Tower's account lifecycle management does not address.

The ESC Catalog Gap: Governance Outside the Sovereign Boundary

The AWS European Sovereign Cloud catalog covers services that AWS operates with enhanced data residency, restricted AWS personnel access, and EU regulatory alignment. Control Tower is not in that catalog.

The structural consequence: organizations can deploy ESC-compliant workloads — running on ESC-catalog EC2, RDS, and S3 services in eu-central-1 — but their governance layer operates outside the sovereign boundary. The Log Archive Account that stores six years of those workloads' audit data is not under ESC-level controls. The Audit Account that aggregates Config findings from those workloads is not under ESC-level controls. The Account Factory that provisions new accounts into the organization is not under ESC-level controls.

The sovereignty gap: A multi-account AWS organization using Control Tower has a split compliance posture: ESC-sovereign workloads governed by a non-sovereign governance layer. From a CLOUD Act and data residency perspective, the governance layer represents the organization's most sensitive data concentration — it is the meta-record of everything the organization does in AWS — yet it operates with less protection than the workloads it governs.

EU-Sovereign Alternatives to AWS Control Tower

Full feature parity with Control Tower — including managed guardrail enforcement, integrated Account Factory, and centralized compliance dashboards — is not available from EU-based managed services. The alternatives fall into two categories: infrastructure-as-code approaches that provide governance without a managed control plane dependency, and open-source policy-as-code frameworks that can be self-hosted on EU infrastructure.

OpenTofu + GitLab CI — EU-Sovereign IaC Governance

Provider: OpenTofu (Linux Foundation project, community-governed)
Deployment: Self-hosted — any EU infrastructure (Hetzner, Scaleway, OVH)
Licensing: MPL-2.0

OpenTofu is the open-source Terraform fork under Linux Foundation governance. It provides the same HCL-based infrastructure-as-code capability as Terraform without HashiCorp's BSL licensing restrictions or US-company dependency.

Governance approach: Replace Control Tower's guardrail library with OpenTofu modules that provision and configure AWS accounts with GDPR-specific controls baked in. Use GitLab CI (self-hosted on EU infrastructure) for policy enforcement — every account configuration change passes through a pipeline that validates against your compliance requirements before applying.

Advantages over Control Tower:

• All governance automation runs on EU infrastructure you control — no AWS control plane dependency
• Custom compliance rules including GDPR-specific controls (erasure workflows, data minimization checks, cross-border transfer blocks)
• Version-controlled, auditable account configurations with git history as the compliance record
• No six-year log retention default — you define retention explicitly in the IaC

Disadvantages: Higher operational complexity than managed Control Tower; requires maintaining IaC modules and CI pipelines.

Crossplane — Kubernetes-Native Multi-Account Governance

Provider: CNCF (Cloud Native Computing Foundation) project, community-governed
Deployment: Self-hosted on any Kubernetes cluster (including EU-hosted clusters)
Licensing: Apache 2.0

Crossplane provides a Kubernetes-native control plane for managing cloud infrastructure. AWS accounts, organizations, and resources can be declared as Kubernetes custom resources and managed through the Kubernetes API from a control plane cluster running on EU infrastructure.

Governance approach: Deploy a Crossplane control plane cluster on EU-hosted Kubernetes (Hetzner k3s, OVH Managed Kubernetes, Scaleway Kapsule). Use Crossplane's AWS Provider to manage AWS account provisioning, SCP enforcement, and baseline configuration through Kubernetes manifests. Policy enforcement via OPA/Gatekeeper on the Crossplane cluster applies compliance rules before changes reach AWS.

GDPR advantage: The control plane that governs your AWS organization runs entirely on EU infrastructure. Audit logs of governance operations — equivalent to Control Tower's Audit Account — are stored on your EU infrastructure, subject only to EU jurisdiction.

Disadvantages: Crossplane adds Kubernetes operational complexity; mature AWS account management via Crossplane requires significant initial investment in custom compositions.

AWS Landing Zone Accelerator on Open Source Stack

For organizations that must use AWS native tools but want maximum transparency and control, the Landing Zone Accelerator (LZA) is AWS's open-source alternative to managed Control Tower. LZA is a configuration-driven framework that deploys the same Landing Zone architecture as Control Tower using CloudFormation and AWS native services, but with the full configuration expressed as code that you own and modify.

GDPR relevance: LZA allows you to replace the default six-year Log Archive retention with your organization-specific retention periods, add custom Config rules for GDPR controls, and modify guardrails that Control Tower does not expose for customization. The governance automation still runs in your AWS accounts (not on EU-sovereign infrastructure), but you have complete visibility and control over what it does.

When to use: Organizations already committed to AWS that need more control over governance configuration than managed Control Tower provides, without moving governance automation off-cloud entirely.

Migration Path: From Control Tower to EU-Sovereign Governance

Phase 1 — Audit the Log Archive Account: Inventory what personal data categories exist in your Log Archive Account CloudTrail records. Identify which accounts processed personal data, which users are identified in those logs, and whether any former employees' activity records exist. Assess against your actual retention requirements.

Phase 2 — Right-size Log Archive retention: Configure S3 lifecycle policies on the Log Archive Account to align with your documented retention requirements — not AWS defaults. For most organizations, 90-day to 2-year retention is justified; document the legal basis for whatever period you choose.

Phase 3 — Supplement guardrails with GDPR controls: Add custom AWS Config rules or SCPs to enforce GDPR-specific requirements: block replication to non-EU regions, require personal data resource tagging, enforce erasure capability for high-risk data stores.

Phase 4 — Evaluate control plane migration: For organizations with strict sovereignty requirements, assess whether OpenTofu/GitLab CI or Crossplane on EU infrastructure can replace Control Tower as the primary account provisioning and governance mechanism.

Phase 5 — Document for RoPA: Add explicit entries for the Log Archive Account and Audit Account to your RoPA — cross-account audit aggregation, personal data categories, retention period, legal basis, and transfer risk assessment for CLOUD Act.

Summary: AWS Control Tower GDPR Checklist

AWS Control Tower solves a genuine operational problem: consistent, automated governance across a growing multi-account AWS organization is hard to maintain manually. But it does so by concentrating six years of your organization's complete operational history in a centralized AWS-managed log archive, outside the AWS European Sovereign Cloud boundary, with the CLOUD Act exposure of a single high-value disclosure target. The EU-sovereign alternatives — OpenTofu on EU infrastructure, Crossplane on EU-hosted Kubernetes, or at minimum the Landing Zone Accelerator with explicit retention controls — provide multi-account governance without ceding your organization's meta-record to US-jurisdiction infrastructure.

sota.io helps European development teams run PaaS workloads on EU-sovereign infrastructure. See how sota.io handles multi-account governance for your deployments.