AWS Multi-Account Strategy: Setting Up Governance That Scales

Why Multi-Account Strategy Is Now Critical

The trend is clear: according to AWS Enterprise Strategy, 90% of enterprise customers with significant AWS usage already operate more than one account — but many do so without a coherent strategy. The result: organically grown structures, unclear cost ownership, and guardrail gaps that only surface during compliance audits or security incidents.

For DACH enterprises, requirements are further tightened by GDPR data separation mandates, BSI Grundschutz conformity requirements, and the NIS2 directive — all of which demand demonstrable isolation of sensitive workloads. A multi-account architecture is not an end in itself: it is the technical means to enforce governance at the account level, rather than relying on manual processes and individual IAM policy maintenance.

Cost pressure is also a driving factor: without consolidated billing through AWS Organizations, FinOps lacks a foundation. Cost allocation tags and service quotas can be centrally managed and enforced at the organizational level — a prerequisite for scalable cloud governance.

Key Concepts: The Multi-Account Governance Vocabulary

Organizational Unit (OU)

A logical grouping of AWS accounts within AWS Organizations. OUs form a tree structure under the management account. Service Control Policies assigned to an OU apply to all accounts in that OU and all subordinate OUs.

Service Control Policy (SCP)

An AWS Organizations policy that defines the maximum permitted actions for accounts or OUs. SCPs are not grant policies — they restrict the allowed action space. IAM policies within an account must additionally explicitly permit what the SCP allows. SCPs do not apply to the management account.

Guardrail

In the context of AWS Control Tower: a pre-configured governance rule. Guardrails are either preventive (blocking non-compliant actions, implemented as SCPs) or detective (detecting and reporting non-compliant state, implemented as AWS Config rules). Control Tower distinguishes between mandatory, strongly recommended, and optional guardrails.

Account Vending

The automated process for provisioning new AWS accounts from a defined template. An account vending mechanism (AVM) ensures every new account is immediately provisioned with the correct baseline configurations, SCPs, logging hooks, and SSO assignments — without manual intervention. AWS Control Tower's Account Factory is the native implementation.

Landing Zone

A pre-configured, secure multi-account AWS environment based on best practices. A landing zone defines account structure, network design (Transit Gateway, VPC sharing), centralized logging and audit accounts, and guardrails. AWS Control Tower delivers an opinionated landing zone; teams can also build custom implementations via the AWS Landing Zone Accelerator.

AWS Organizations and AWS Control Tower in Detail

AWS Organizations (AWS documentation) is the foundation of every multi-account strategy. It enables:

• Consolidated billing: All accounts in an organization are billed through the management account. Reserved Instance and Savings Plan discounts apply automatically across all accounts in the organization.
• Service Control Policies (SCPs): Policies applied at OU or account level that define the permission boundary.
• Delegated administration: Certain AWS services (e.g., Security Hub, GuardDuty, AWS Config) can be delegated to a dedicated admin account, avoiding use of the management account for operational tasks.
• Account Factory: Automated account provisioning via AWS Service Catalog or Control Tower.

AWS Control Tower builds on Organizations and delivers an implementation layer with the following core components:

An important note for existing AWS customers: Control Tower can be applied to existing Organizations structures (enrolling existing accounts). This process requires careful planning, as account enrollment activates guardrails and can override existing configurations (AWS Control Tower: Enrolling existing accounts).

OU Design for DACH Enterprises

OU design is the most important architectural decision in a multi-account strategy. OUs should be structured primarily by governance requirements — not by organizational charts or cost centers. The core principle: accounts in the same OU share the same SCPs and guardrails.

AWS recommends the following baseline OU structure (AWS Whitepaper: Organizing Your AWS Environment):

For DACH enterprises with regulated workloads, Storm Reply recommends additional OUs:

• OU: Regulated — Accounts for GDPR-sensitive processing or BSI Grundschutz-relevant systems. Custom SCPs that restrict usage to EU regions and block certain data transfer services.
• OU: Transitioning — Accounts being moved from a legacy structure into the new OU architecture. Temporary OU with defined SLAs for the migration timeline.

Guardrails and Service Control Policies

Guardrails and SCPs are the heart of the governance architecture. They define what is permitted and prohibited in accounts — both preventively and detectivelly.

Preventive Guardrails (SCPs)

Key SCPs for DACH enterprises include:

1. Region restriction: Permits only AWS regions within the EU (eu-central-1, eu-west-1, eu-north-1, etc.). Prevents accidental resource creation in non-European regions — essential for GDPR compliance.
2. Block root usage: Prevents use of the root user in member accounts. All actions must go through IAM Identity Center (SSO).
3. Block CloudTrail disabling: Ensures audit logging cannot be disabled in any account — a baseline requirement for BSI Grundschutz and NIS2.
4. Block S3 public access: Prevents enabling public S3 access at the organization level.
5. Service restrictions for sandbox OUs: Blocks production-critical services (e.g., Route 53 private hosted zone creation) in development environments.
6. Enforce billing alerts: Every new account must have budget alerts configured.

Detective Guardrails (AWS Config)

Detective guardrails check current state and report deviations. Control Tower provides over 65 pre-configured detective guardrails (AWS Control Tower Controls Reference). Critical examples:

• MFA enforced for all IAM users
• No unencrypted EBS volumes
• VPC Flow Logs enabled
• Security Hub active in all accounts
• GuardDuty enabled and centralized

SCP Architecture: Deny Lists vs. Allow Lists

There are two fundamental approaches:

• Deny list: All services permitted; specific services blocked. More flexible, but higher risk that new services are inadvertently allowed.
• Allow list: Only explicitly permitted services and actions are usable. More rigorous, requires more maintenance, but significantly more secure for regulated environments.

Storm Reply recommends an allow-list approach for regulated OUs (Prod, Regulated) and a deny-list approach for Non-Prod OUs — combined with regular SCP reviews as part of the Storm Roadmap.

Automating Account Vending

Manually provisioned accounts are an anti-pattern: they are error-prone, inconsistent, and do not scale. An automated account vending mechanism (AVM) ensures every new account is immediately compliant and operationally ready.

AWS Control Tower Account Factory

Control Tower's Account Factory (AWS documentation) provides:

1. Account provisioning via AWS Service Catalog — self-service for authorized users
2. Automatic assignment to the correct OU
3. Baseline guardrails active immediately after account creation
4. IAM Identity Center assignment for immediate SSO access
5. Standardized VPC setup as an option (Account Factory Customization)

Account Factory for Terraform (AFT)

For teams that prefer infrastructure as code, Account Factory for Terraform (AFT) is the recommended solution. AFT enables account provisioning via Terraform pipelines — including account-specific customizations, global customizations for all accounts, and account-specific provisioning steps. This integrates seamlessly with existing GitOps workflows.

Required Baseline for Every New Account

Regardless of the chosen AVM, every new account should automatically receive the following baseline:

• CloudTrail enabled, logs written to the central log archive account
• AWS Config enabled and aggregator configured
• Security Hub enrolled (delegated admin)
• GuardDuty enrolled (delegated admin)
• Budget alert at the defined threshold
• IAM password policy per company standard
• Root MFA enforced (via SCP)
• Standard tags (CostCenter, Environment, Owner, Project)

Storm Reply Perspective: Multi-Account as Part of the Storm Roadmap

A multi-account strategy is not a one-time implementation — it is a continuous governance program. At Storm Reply, multi-account design is therefore a core component of the Storm Roadmap: a structured plan that systematically addresses technical debt and synchronizes account governance with the company's growth strategy.

The typical Storm Roadmap engagement for multi-account governance involves:

1. Assessment (weeks 1–2): Inventory of the existing account structure, IAM policies, tagging state, and compliance gaps. Classification by OU categories.
2. OU design workshop (weeks 2–3): Joint definition of the OU hierarchy, SCP strategy, and guardrail selection. Alignment with security, compliance, and FinOps stakeholders.
3. Pilot rollout (weeks 4–6): Control Tower setup or Organizations hardening on a non-production account segment. Validation of guardrails and Account Factory templates.
4. Incremental enrollment (months 2–4): Onboarding existing accounts into the new structure — prioritized by risk class. Sandbox and non-prod first, then prod.
5. Continuous governance review: Quarterly SCP reviews, guardrail updates for new AWS services and compliance requirements. Integration into the FinOps program.

Storm Reply is an AWS Premier Consulting Partner DACH with AWS Migration Competency and Cloud Operations Competency — and brings over 15 years of AWS experience in multi-account architectures for DACH enterprises.

Regulatory Considerations: GDPR, BSI Grundschutz, and NIS2

For DACH enterprises, a multi-account strategy is not merely technical best practice — it is often a regulatory necessity.

GDPR and Data Separation

The GDPR does not prescribe a specific technical architecture, but the data security principle (Art. 32 GDPR) and the privacy-by-design principle (Art. 25 GDPR) require appropriate technical measures. Account isolation ensures that personal data in one system cannot inadvertently interact with other systems. SCPs that restrict data processing to EU regions are a direct technical means of GDPR compliance.

BSI IT Grundschutz

BSI IT Grundschutz (modules OPS.1.2.6 for cloud usage and CON.1 for cryptographic concepts) recommends clear tenant separation and traceable logging. A multi-account architecture with a central log archive account and immutable audit trail fulfills these requirements structurally. Control Tower's mandatory guardrails — particularly blocking CloudTrail disabling — map directly to BSI requirements.

NIS2 Directive

The NIS2 directive (EU 2022/2555), transposed into German law via the NIS2UmsuCG, requires critical and important entities to implement network and information security measures — including access controls, incident response, and monitoring. A multi-account strategy with segregated networks, centralized Security Hub and GuardDuty forms the technical foundation for NIS2-compliant cloud operations. Particularly relevant: account isolation prevents lateral movement during a security incident and limits the blast radius.

Benefits and Challenges at a Glance

Frequently Asked Questions

How many AWS accounts does a mid-sized enterprise need?

A typical mid-sized enterprise starts with 6–12 accounts: management account, log archive, audit, shared services, and one workload account per environment (dev/test/prod) for the first 2–3 applications. As cloud maturity grows, account counts scale to 20–50+. The right granularity depends on blast radius, compliance requirements, and team ownership.

What is the difference between AWS Organizations and AWS Control Tower?

AWS Organizations is the foundation: it manages the account hierarchy and enables consolidated billing and Service Control Policies. AWS Control Tower builds on top and delivers an opinionated landing zone implementation — including pre-configured guardrails, Account Factory, and a compliance dashboard. Organizations is the prerequisite; Control Tower is the recommended implementation layer.

Can SCPs override existing IAM policies?

No. Service Control Policies define the maximum permission boundary for accounts and OUs. An SCP cannot grant permissions — it can only restrict the scope that IAM policies within an account are allowed to permit. If an IAM policy allows an action that the SCP blocks, the action is denied. SCPs do not apply to the management account.

How long does it take to set up an AWS Landing Zone with Control Tower?

A greenfield Control Tower landing zone can be technically set up in 1–2 days. For enterprises with existing accounts, custom tagging policies, SSO integration, and regulatory requirements (GDPR, BSI, NIS2), 4–8 weeks for design, rollout, and validation is realistic. Storm Reply recommends conducting an OU design workshop before provisioning Control Tower.

Sources and Further Reading

• AWS Organizations: Introduction and Concepts (AWS documentation)
• AWS Control Tower: What is Control Tower? (AWS documentation)
• AWS Whitepaper: Organizing Your AWS Environment Using Multiple Accounts
• AWS Control Tower: Controls Reference (Guardrails)
• AWS Control Tower: Account Factory for Terraform (AFT)
• BSI IT Grundschutz (Federal Office for Information Security)
• NIS2 Directive (EU 2022/2555) in the EU Official Journal