---
title: AWS Multi-Account Strategy: Landing Zone Best Practices
description: A single AWS account is fine for week one. By month six, audit teams, security reviewers, and your CFO will all want their own boundary. How to structure AWS Organizations with Control Tower and a landing zone that doesn't have to be re-architected at scale.
url: https://www.joinhorizon.co/blog/aws-multi-account-strategy-landing-zone-best-practices/
datePublished: 2026-02-01T00:00:00.000Z
dateModified: 2026-10-28T00:00:00.000Z
author: palaniappan-p
category: Cloud Architecture
tags: aws, security, architecture, multi-account
---

# AWS Multi-Account Strategy: Landing Zone Best Practices

> A single AWS account is fine for week one. By month six, audit teams, security reviewers, and your CFO will all want their own boundary. How to structure AWS Organizations with Control Tower and a landing zone that doesn't have to be re-architected at scale.

A single AWS account is fine for experimentation. For anything production-grade, it is a liability. A multi-account strategy is one of the biggest architectural decisions you can make. It improves security isolation, simplifies compliance, enables per-team cost attribution, and keeps blast radius from spreading across environments.

**May 2026 refresh:** AWS Control Tower landing zones ship breaking-change upgrades periodically, so schedule drift checks between Control Tower, Organizations SCPs, and security tooling accounts whenever AWS pushes mandatory baseline updates.

Most organizations delay multi-account adoption because it seems complex. This guide gives a practical framework for structuring your AWS organization.

## Why Multiple Accounts?

AWS accounts are the strongest isolation boundary available. Unlike IAM policies (which can be misconfigured), VPCs (which can be peered), or resource tags (which can be forgotten), accounts provide hard isolation for:

- **Security:** a compromised development account cannot access production data
- **Billing:** per-account cost attribution without relying on tagging discipline
- **Service limits:** each account has independent service quotas, preventing one workload from exhausting limits for another
- **Compliance:** regulated workloads (HIPAA, PCI) go into dedicated accounts with stricter controls
- **Blast radius:** an infrastructure misconfiguration in one account does not affect other accounts

## Recommended Account Structure

### Organizational Units (OUs)

AWS Organizations groups accounts into Organizational Units (OUs). Each OU can have service control policies (SCPs) that define the maximum permissions available to any IAM entity within accounts in that OU.

```
Root
├── Security OU
│   ├── Log Archive account (centralized CloudTrail, Config logs)
│   ├── Security Tooling account (GuardDuty delegated admin, Security Hub)
│   └── Audit account (read-only access for compliance teams)
├── Infrastructure OU
│   ├── Networking account (Transit Gateway, shared VPCs, Direct Connect)
│   ├── Shared Services account (CI/CD pipelines, artifact repositories, DNS)
│   └── Identity account (IAM Identity Center, IdP federation)
├── Workloads OU
│   ├── Production OU
│   │   ├── Product A Production
│   │   ├── Product B Production
│   │   └── Data Platform Production
│   ├── Staging OU
│   │   ├── Product A Staging
│   │   └── Product B Staging
│   └── Development OU
│       ├── Product A Development
│       └── Product B Development
├── Sandbox OU
│   ├── Developer Sandbox 1
│   └── Developer Sandbox 2
└── Suspended OU (decommissioned accounts)
```

### Core Accounts

**Management account:** the root of your AWS Organization. This account should contain nothing except Organizations, SCPs, and billing configuration. No workloads, no user access. It is the most privileged account in your organization and should have the fewest people with access.

**Log Archive account:** centralized storage for CloudTrail logs, Config snapshots, VPC Flow Logs, and other audit data from all accounts. S3 buckets in this account are locked down with bucket policies that allow writing from other accounts but prevent deletion.

**Security Tooling account:** runs GuardDuty (delegated administrator), Security Hub, and other [security monitoring tools](https://www.joinhorizon.co/services/aws-cloud-security/) that aggregate findings across all accounts.

**Networking account:** owns shared networking infrastructure: Transit Gateway, Direct Connect gateways, Route 53 hosted zones, and centralized VPC endpoints. Other accounts peer to this account's Transit Gateway for inter-account and on-premises connectivity.

**Shared Services account:** hosts CI/CD pipelines, container registries (ECR), artifact repositories, and other shared [DevOps infrastructure](https://www.joinhorizon.co/services/devops-pipeline-setup/) that serves multiple workload accounts.

![Architecture diagram of an AWS Organization with Control Tower guardrails, a workload account, a log archive bucket, GuardDuty, and IAM Identity Center](../../assets/images/blog/aws-multi-account-strategy-landing-zone-best-practices-accounts.webp)

_Figure: SCPs on the workload account restrict permissions. They do not grant them. Logs are written to the archive account. Identity Center issues temporary credentials. This figure does not peer the accounts. [Open the draw.io source](https://www.joinhorizon.co/examples/architecture-blog-2026/aws-multi-account-strategy-landing-zone-best-practices/account-structure.drawio)._

## Service Control Policies

SCPs are the guardrails that prevent accounts from doing things they should not. They do not grant permissions. They restrict what IAM policies can do within an account.

### Essential SCPs

**Deny Region restriction:** restrict all API calls to approved Regions only. This prevents workloads from running in unapproved Regions, which matters for data residency compliance:

```json
{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": ["us-east-1", "us-west-2"]
    }
  }
}
```

**Deny root user actions:** prevent the root user from performing actions in member accounts (root should only be used for initial account setup):

**Deny leaving the organization:** prevent accounts from being removed from the organization without management account approval.

**Deny disabling security services:** prevent anyone from disabling CloudTrail, GuardDuty, Config, or Security Hub within member accounts.

### Environment-Specific SCPs

**Production OU:**

- Deny deletion of RDS instances without final snapshot
- Deny modification of backup policies
- Deny public S3 bucket creation
- Require encryption on all new resources

**Development OU:**

- Allow broader permissions but restrict expensive instance types
- Limit maximum spend per account
- Restrict access to production data

**Sandbox OU:**

- Maximum flexibility for experimentation
- Hard spending limit enforced via AWS Budgets + Lambda auto-remediation
- Auto-cleanup of resources older than 7 days

## AWS Control Tower

Control Tower automates the setup of a multi-account landing zone with pre-configured guardrails:

**What it provides:**

- Pre-built account factory for provisioning new accounts with standardized configurations
- Mandatory guardrails (CloudTrail enabled, log archive configured) applied automatically
- Strongly recommended guardrails (encryption, public access blocks) available as opt-in
- Dashboard for monitoring guardrail compliance across all accounts

**When to use it:**

- You are starting a new AWS organization from scratch
- You want automated account provisioning with standardized baselines
- You have compliance requirements that benefit from pre-built guardrail catalogs

**When to build custom:**

- You have an existing organization that is difficult to retrofit into Control Tower
- You need guardrails that Control Tower does not provide out of the box
- Your networking architecture does not align with Control Tower's default VPC design

### Control Tower 2025 Updates

AWS has continued expanding Control Tower's capabilities. Updates in 2025 include:

- **Proactive controls:** Controls that check resources before provisioning (not just after), so non-compliant resources are blocked instead of remediated after the fact
- **Account Factory for Terraform (AFT) improvements:** Better drift detection and automated remediation for account baselines managed via AFT
- **Extended Region support:** Control Tower now covers all commercial AWS Regions, closing gaps that previously forced some organizations to manage certain Regions outside of Control Tower

## Cross-Account Access Patterns

### IAM Identity Center (SSO)

IAM Identity Center provides centralized user authentication across all accounts:

- Engineers sign in once and switch between accounts via a portal
- Permission sets define what users can do in each account
- Integration with external identity providers (Okta, Azure AD, Google Workspace)
- Temporary credentials, with no long-lived access keys

**2025 improvements to IAM Identity Center:**

- **Trusted identity propagation:** Identity Center can now propagate user identity claims to supported AWS services (like Amazon Redshift and AWS Analytics services) without requiring service-specific IAM roles, which enables attribute-based access control that follows the user's identity across services
- **Improved permission set versioning:** Changes to permission sets now show a diff view before deployment, reducing the risk of unintended permission changes across multiple accounts

**Example permission sets:**

- `AdministratorAccess` → Management team → Production account
- `PowerUserAccess` → Engineers → Development accounts
- `ReadOnlyAccess` → Engineers → Production account (for debugging)
- `SecurityAudit` → Security team → All accounts

### Cross-Account IAM Roles

For service-to-service communication between accounts, use IAM roles with trust policies:

```
CI/CD Pipeline (Shared Services account) → Assumes deployment role → Production account
```

The deployment role in the production account trusts the CI/CD pipeline role in the shared services account. This provides least-privilege access without sharing credentials.

### Resource Sharing

AWS Resource Access Manager (RAM) shares resources across accounts without duplication:

- **VPC subnets:** share networking account subnets with workload accounts
- **Transit Gateway:** share connectivity infrastructure
- **Route 53 Resolver rules:** share DNS resolution rules
- **License Manager:** share software licenses across accounts


![Diagram of IAM Identity Center permission sets, a shared-services pipeline assuming a production role, and RAM sharing a transit gateway](../../assets/images/blog/aws-multi-account-strategy-landing-zone-best-practices-access.webp)

_Figure: people use permission sets. The shared-services pipeline assumes a deploy role in production. RAM shares the transit gateway. No long-lived access keys are shown. [Open the draw.io source](https://www.joinhorizon.co/examples/architecture-blog-2026/aws-multi-account-strategy-landing-zone-best-practices/cross-account.drawio)._

## Cost Management Across Accounts

### Consolidated Billing

AWS Organizations automatically enables consolidated billing, so all accounts receive a single bill. Volume discounts and Reserved Instance/Savings Plan benefits are shared across the organization.

### Per-Account Cost Attribution

With multiple accounts, [cost attribution](https://www.joinhorizon.co/services/aws-cloud-cost-optimization-services/) is built into the structure:

- Each account's costs are naturally separated in Cost Explorer
- No reliance on tagging (though tags provide additional granularity)
- Per-team and per-product cost visibility without additional tooling
- Budget alerts per account to catch runaway spending early

### Reserved Instance and Savings Plan Sharing

By default, RI and SP discounts apply across the entire organization. You can optionally disable sharing and restrict discounts to specific accounts, which is useful when different business units manage their own cloud budgets.

**RI/SP Group Sharing (November 2025):** AWS launched RI/SP Group Sharing as generally available, allowing organizations to define sharing groups that determine which accounts within the organization can consume each other's RI and Savings Plan discounts. This gives fine-grained control over discount allocation in organizations where different teams manage separate cost budgets.

### Multi-Account AI/ML Governance

As organizations adopt Amazon Bedrock and SageMaker, multi-account governance extends to AI/ML workloads:

- **Bedrock delegated admin:** Similar to GuardDuty, Bedrock organizational features can be administered from a central account
- **Model access control:** SCPs can restrict which Bedrock foundation models specific accounts or OUs can invoke, preventing unauthorized use of expensive models
- **AI cost attribution:** Bedrock token usage is visible per account in Cost Explorer, enabling per-team AI cost tracking within your organization structure

## Common Multi-Account Mistakes

### Mistake 1: Too Few Accounts

Running production, staging, and development in a single account gives you no isolation. A developer's misconfigured IAM policy could access production databases. Separate environments into separate accounts, at minimum production and non-production.

### Mistake 2: Too Many Accounts Without Automation

Creating 50 accounts manually without Infrastructure as Code leads to configuration drift. Use Account Factory (Control Tower) or custom CloudFormation/CDK/Terraform to provision accounts with standardized baselines. Every account should be identical except for workload-specific resources.

### Mistake 3: No Centralized Logging

If each account stores its own CloudTrail logs, a compromised account can delete its audit trail. Centralize all logs to the Log Archive account with deletion protection. This is the first thing an auditor or incident responder will look for.

### Mistake 4: Networking Sprawl

Creating separate VPCs in every account without a networking strategy leads to overlapping CIDR ranges, inconsistent routing, and inability to communicate between accounts. Centralize networking in a dedicated account with Transit Gateway.

## Getting Started

Proper account isolation improves [security](https://www.joinhorizon.co/services/aws-cloud-security/), cost management, compliance, and operational efficiency.

If you are running workloads in a single account or a small number of accounts without formal structure, an [AWS Architecture Review](https://www.joinhorizon.co/services/aws-architecture-review/) can assess your current state and design a migration path to a well-structured organization.

For ongoing management of multi-account environments, see our [AWS Managed Services](https://www.joinhorizon.co/services/aws-managed-services/).

Once the landing zone exists, the day-two question is how to operate it without duplicating resources per account. See [cross-account patterns beyond the landing zone](https://www.joinhorizon.co/blog/aws-cross-account-patterns-beyond-landing-zone-2026/) for AWS RAM sharing, delegated administrators, Route 53 Profiles, and the SCP vs RCP vs declarative-policy decision. For org-wide compliance baselines (not per-account hand-managed Config rules), deploy [Config conformance packs via Quick Setup or StackSets](https://www.joinhorizon.co/blog/aws-continuous-compliance-automation-config-audit-manager-2026/) from the security delegated admin account.

[Contact us to design your AWS multi-account strategy →](https://www.joinhorizon.co/contact-us/)

## Related reading

- [AWS Cloud Center of Excellence (CCoE): Operating Model, RFCs, and How WAR + FinOps Connect](https://www.joinhorizon.co/blog/aws-cloud-center-of-excellence-operating-model-2026/)
- [AWS for Retail: The Complete Guide for eCommerce Teams](https://www.joinhorizon.co/blog/aws-for-retail-complete-guide/)
- [AWS Global Accelerator vs CloudFront & Route 53 (2026)](https://www.joinhorizon.co/blog/aws-global-accelerator-when-to-use-multiregion/)
- [AWS IoT Greengrass v2: Edge Computing for Factory Floors](https://www.joinhorizon.co/blog/aws-iot-greengrass-v2-edge-computing-factory-floor/)
- [AWS IoT SiteWise Native Anomaly Detection for Predictive Maintenance](https://www.joinhorizon.co/blog/aws-iot-sitewise-native-anomaly-detection-predictive-maintenance/)
- [AWS IoT Solutions: Architecture Patterns for Connected Devices](https://www.joinhorizon.co/blog/aws-iot-solutions-architecture-guide/)
- [AWS IoT TwinMaker: Digital Twin Architecture for Manufacturing](https://www.joinhorizon.co/blog/aws-iot-twinmaker-digital-twin-manufacturing/)
- [AWS Managed Services vs AWS Support Plans: What](https://www.joinhorizon.co/blog/aws-managed-services-vs-aws-support-plans-difference/)
- [AWS Architecture for Black Friday: How Retail Teams Prepare for Peak Traffic](https://www.joinhorizon.co/blog/aws-retail-architecture-black-friday-peak-traffic/)
- [AWS Retail Competency: What It Is and Why It Matters When Choosing a Cloud Partner](https://www.joinhorizon.co/blog/aws-retail-competency-what-it-means-for-your-business/)
- [AWS Service Announcements Worth Knowing: March 2026 Edition](https://www.joinhorizon.co/blog/aws-service-announcements-march-2026/)
- [AWS Service Announcements: May 2026 Roundup](https://www.joinhorizon.co/blog/aws-service-announcements-may-2026/)
- [AWS Service Announcements: June 2026 Roundup](https://www.joinhorizon.co/blog/aws-service-announcements-june-2026/)
- [Amazon SES for eCommerce: Scaling Promotional and Transactional Email That Actually Reaches the Inbox](https://www.joinhorizon.co/blog/aws-ses-ecommerce-email-marketing/)
- [12 Benefits of Hiring a Certified AWS Consultant — With Real ROI](https://www.joinhorizon.co/blog/benefits-of-hiring-certified-aws-consultant/)
- [Custom AWS Development for Retail: When Off-the-Shelf Is Not Enough](https://www.joinhorizon.co/blog/custom-aws-development-retail-ecommerce/)
- [How to Optimize EC2 for High-Performance APIs](https://www.joinhorizon.co/blog/ec2-high-performance-api-optimization/)
- [How to Migrate from SendGrid to Amazon SES (Step-by-Step)](https://www.joinhorizon.co/blog/how-to-migrate-from-sendgrid-to-amazon-ses/)
- [Microservices Design Patterns on AWS: 10 Patterns That Actually Matter in 2026](https://www.joinhorizon.co/blog/microservices-design-patterns-aws-production-guide-2026/)
- [How to Choose Between Nginx, FrankenPHP, and Modern Web Runtimes (2026)](https://www.joinhorizon.co/blog/nginx-frankenphp-modern-runtimes-comparison/)
- [OPC-UA on AWS: SiteWise Edge Gateway Setup and Best Practices](https://www.joinhorizon.co/blog/opc-ua-aws-iot-sitewise-edge-gateway-setup/)
- [OT/IT Convergence on AWS: Architecture Patterns for Smart Manufacturing](https://www.joinhorizon.co/blog/ot-it-convergence-aws-architecture-patterns/)
- [How to Build Reliable Queue Systems on AWS (SQS, Kafka, Redis)](https://www.joinhorizon.co/blog/reliable-queue-systems-aws-sqs-kafka-redis/)
- [How to Tune PHP, Node.js, Python, and Go for High Concurrency on AWS](https://www.joinhorizon.co/blog/tune-php-node-python-go-high-concurrency/)
- [AWS Blocks Preview: Local Backends, Zero-Change Deploy](https://www.joinhorizon.co/blog/aws-blocks-application-backends-preview/)
- [Hybrid & Edge on AWS (2026): Outposts vs Local Zones vs Wavelength — Placement, Connectivity, and the Latency Bill](https://www.joinhorizon.co/blog/aws-hybrid-edge-integration-outposts-local-zones-wavelength-2026/)
- [Media & OTT Streaming on AWS (2026): Live vs VOD Architecture, Egress Math, and When IVS Beats Elemental](https://www.joinhorizon.co/blog/aws-media-ott-streaming-architecture-live-vod-2026/)
- [Bloom Filters and HyperLogLog in Production on ElastiCache Redis](https://www.joinhorizon.co/blog/bloom-filters-hyperloglog-production-elasticache/)
- [B-Tree vs LSM and Query Planner Internals on AWS Databases](https://www.joinhorizon.co/blog/btree-lsm-query-planner-database-engine-internals/)
- [CAP Theorem in Practice on AWS: What Architects Actually Need for Multi-Region](https://www.joinhorizon.co/blog/cap-theorem-practice-aws-multi-region/)
- [Paxos, Raft, and Byzantine Fault Tolerance: What Cloud Architects Need](https://www.joinhorizon.co/blog/consensus-paxos-raft-byzantine-fault-tolerance-cloud/)
- [CPU Cache Coherence and False Sharing for Cloud Backend Engineers](https://www.joinhorizon.co/blog/cpu-memory-model-cache-coherence-false-sharing-cloud/)
- [CRDTs and Eventual Consistency Anti-Patterns on AWS](https://www.joinhorizon.co/blog/crdts-eventual-consistency-anti-patterns-aws/)
- [Database Deadlocks, Connection Pool Exhaustion, and Prepared Statements on RDS](https://www.joinhorizon.co/blog/database-deadlocks-connection-pools-prepared-statements-rds/)
- [Distributed Cache Invalidation and Multi-Level Caching on AWS](https://www.joinhorizon.co/blog/distributed-cache-invalidation-multi-level-caching-aws/)
- [Distributed Locking, Redlock, and Consistent Hashing on AWS](https://www.joinhorizon.co/blog/distributed-coordination-redlock-consistent-hashing-elasticache/)
- [EC2 M9g and M9gd (Graviton5) GA: When to Move Off M8g — and When to Wait](https://www.joinhorizon.co/blog/ec2-m9g-m9gd-graviton5-ga-2026/)
- [Exactly-Once, CQRS, and Event Sourcing Replay on AWS](https://www.joinhorizon.co/blog/exactly-once-cqrs-event-sourcing-replay-aws/)
- [gRPC, GraphQL, Protobuf, and API Contracts on AWS](https://www.joinhorizon.co/blog/grpc-graphql-protobuf-api-contracts-aws/)
- [High-Concurrency Server I/O: epoll, Syscalls, and Zero-Copy on AWS EC2](https://www.joinhorizon.co/blog/high-concurrency-server-io-epoll-syscalls-zero-copy-aws/)
- [JVM G1 and ZGC Tuning on AWS Corretto for ECS and EKS](https://www.joinhorizon.co/blog/jvm-g1-zgc-garbage-collection-tuning-aws/)
- [Kafka on MSK: Partition Rebalancing and Exactly-Once Semantics](https://www.joinhorizon.co/blog/kafka-msk-partition-rebalancing-exactly-once-semantics/)
- [Message Ordering, Backpressure, and RabbitMQ DLQs on AWS](https://www.joinhorizon.co/blog/message-ordering-backpressure-rabbitmq-dlq-aws/)
- [Modern Web Transport on AWS: TCP Congestion, HTTP/2, HTTP/3, and QUIC](https://www.joinhorizon.co/blog/modern-web-transport-tcp-congestion-http2-http3-quic-aws/)
- [OAuth2 Token Introspection vs JWT Validation on Cognito and API Gateway](https://www.joinhorizon.co/blog/oauth2-introspection-vs-jwt-validation-cognito-api-gateway/)
- [PostgreSQL Transaction Isolation and ACID vs BASE on AWS RDS and Aurora](https://www.joinhorizon.co/blog/postgresql-transaction-isolation-acid-vs-base-aws/)
- [PostgreSQL Vacuum, Index Bloat, and Sharding Hot Partitions on AWS](https://www.joinhorizon.co/blog/postgresql-vacuum-index-bloat-sharding-hot-partitions-aws/)
- [Rate Limiting: Token Bucket vs Leaky Bucket on AWS WAF and API Gateway](https://www.joinhorizon.co/blog/rate-limiting-token-bucket-leaky-bucket-aws-waf-apigw/)
- [TLS 1.3 Handshake Internals on AWS: ALB, CloudFront, and ACM](https://www.joinhorizon.co/blog/tls-13-handshake-internals-aws-alb-cloudfront-acm/)
- [Virtual Threads, Lock-Free Structures, and High-Throughput Runtimes on AWS](https://www.joinhorizon.co/blog/virtual-threads-lock-free-concurrency-high-throughput-aws/)

## FAQ

### Why use multiple AWS accounts instead of one?
AWS accounts are the strongest isolation boundary in the platform, stronger than IAM policies, VPCs, or tags. Multiple accounts give hard isolation for security (a compromised dev account cannot reach production data), billing (per-account cost attribution without tagging discipline), service quotas (one workload cannot exhaust limits for another), compliance (HIPAA/PCI workloads in dedicated accounts), and blast radius (an IaC mistake stays contained).

### What is an AWS Landing Zone?
A Landing Zone is the baseline multi-account environment you provision before workloads exist: AWS Organizations with OUs (Security, Infrastructure, Workloads, Sandbox), core accounts (Management, Log Archive, Security Tooling, Networking), service control policies as guardrails, and centralized logging/monitoring. AWS Control Tower automates most of this; for higher-customization environments, Terraform-based landing zones (Customizations for AWS Control Tower, AWS Landing Zone Accelerator) extend it.

### AWS Control Tower vs AWS Organizations alone: which should I use?
Use Control Tower if you are starting fresh or have under ~30 accounts. It gives a guided setup, mandatory and strongly-recommended guardrails, and Account Factory for governed account provisioning. Use Organizations alone (with a Terraform-managed landing zone) when you have stronger customization needs, hundreds of accounts, or already-existing complex SCP and OU layouts that Control Tower would not preserve cleanly.

### How do Service Control Policies (SCPs) work?
SCPs sit at the OU or account level in AWS Organizations and define the maximum permissions any IAM entity in scope can hold. They restrict, never grant. The most useful SCPs deny region usage outside compliance boundaries, deny disabling CloudTrail/Config/GuardDuty, deny root-credential usage, deny IAM user access-key creation, and deny disabling EBS encryption-by-default. SCPs apply to the management account only when explicitly attached.

### How many AWS accounts should an organization have?
There is no fixed number. The right answer is "enough that each isolation requirement is met." A typical small SaaS lands around 6 to 10 accounts (Management, Log Archive, Security Tooling, Networking, Shared Services, Prod, Staging, Dev, Sandbox). Larger organizations end up with one production account per product or business unit. AWS Organizations supports up to 10,000 member accounts, so over-creating is rarely the constraint.

---

*Source: https://www.joinhorizon.co/blog/aws-multi-account-strategy-landing-zone-best-practices/*