AWS Landing Zone Architecture: How to Design a Secure Multi-Account AWS Environment

    
      
      
        
        11 Sep 2026
      
    
      
      
      
        
        Updated: 11 Sep 2026
      
      
    
      
      
        
        
          Usman Ul-Haq
        
      
    
      
      
      
      
        
        
          AWS Landing Zone
        
      
      
    
      
      
        
        
        
        
        
        20 min read
      
    
    

An AWS environment often starts simply: one account, a VPC, a few workloads and a small number of people who need access.

That simplicity rarely lasts.

Production workloads arrive. Development and test environments grow. More engineers need access. Security requirements become stricter. Logs need to be retained centrally. AWS costs need clearer ownership. Another account gets created, followed by another.

At that point, the challenge is no longer simply deploying resources to AWS. It is deciding how the AWS environment itself should be structured and governed.

That is the purpose of an AWS Landing Zone architecture.

A well-designed Landing Zone provides the account structure, identity model, security controls, logging, networking and governance foundations on which workloads can grow without turning the AWS environment into a collection of loosely controlled accounts.

The important word is designed.

Deploying AWS Control Tower can form an important part of the foundation, but it does not make decisions about how your organisation should separate workloads, structure Organizational Units, grant access, connect networks or operate its environment.

Those architectural decisions still need to be made.

What Is an AWS Landing Zone Architecture?

An AWS Landing Zone architecture is the governed multi-account foundation used to organise and operate AWS workloads securely at scale. It defines how AWS accounts and Organizational Units are structured, how people gain access, which guardrails apply, where logs and security data are held, and how workload networks are designed and connected.

AWS recommends using multiple accounts as isolation boundaries where appropriate, particularly when separating workloads, environments and responsibilities.

The architecture therefore extends beyond a diagram showing a collection of AWS accounts.

A useful Landing Zone design should answer questions such as:

• Which resources belong in which AWS accounts?
• How should production be isolated from development?
• Which Organizational Units are required?
• Which policies should apply to each OU?
• Who can access each account and with what permissions?
• Where should CloudTrail and other security logs be stored?
• Which security services should be managed centrally?
• How will VPCs communicate where communication is required?
• How will new accounts be added without weakening governance?
• How will costs, backups and tagging be controlled?

The objective is to create a foundation that is secure enough to protect the organisation without becoming unnecessarily difficult or expensive to operate.

AWS Landing Zone Architecture Diagram

A practical Landing Zone for a growing organisation might begin with a structure similar to the following.

At the top sits the AWS Organization and its management account.

Beneath it, accounts can be organised into OUs according to their security, governance and operational requirements.

Capabilities such as IAM Identity Center, Service Control Policies, CloudTrail, AWS Config, GuardDuty, Security Hub, backup, tagging and cost controls operate across this structure.

A five-account AWS environment and a fifty-account environment should not be expected to have identical architectures.

The goal is to create enough separation to provide meaningful security and governance boundaries without creating operational complexity for its own sake.

Organisations that want this foundation designed and implemented rather than assembled incrementally can use CloudOps Studio's AWS Landing Zone design and implementation service to build the account, governance, identity, logging and security foundations around their actual requirements.

The Management Account

The AWS Organizations management account sits at the top of the organisation and has capabilities that member accounts do not.

That makes it powerful — and a poor place to run normal application workloads.

AWS recommends restricting access to the management account, using it only for tasks that require the management account and keeping ordinary AWS resources in member accounts.

There is another important reason for doing this: Service Control Policies do not restrict users or roles in the management account.

What belongs in the management account?

Keep its responsibilities narrow.

Depending on the environment, these can include:

• AWS Organizations administration
• AWS Control Tower administration
• organisation-level configuration that must originate there
• consolidated billing responsibilities
• carefully controlled administrative operations
• delegation of supported services to appropriate member accounts

Access should be restricted to the people who genuinely require organisation-level administrative capability.

What should stay out?

As a general principle, avoid putting normal workloads in the management account.

Application servers, databases, development systems and other workload resources should normally live in appropriate member accounts.

The management account is the control plane for the organisation, not a convenient place to deploy the next EC2 instance.

Keeping it clean reduces exposure, clarifies responsibility and prevents business workloads from becoming unnecessarily coupled to the most privileged account in the AWS environment.

AWS provides further guidance in its AWS Organizations management account best practices.

Designing Your AWS Organizational Unit Structure

AWS Organizational Units allow accounts with similar governance requirements to be grouped together.

This distinction matters.

If two sets of accounts require different controls, access patterns or compliance requirements, an OU boundary may make sense.

If the only reason for creating an OU is that the company has a department with the same name, reconsider whether the boundary provides useful AWS governance.

Security OU

A Security OU can contain accounts responsible for functions that should remain separated from normal workloads.

Typical examples include:

• Log Archive
• Security / Audit

These accounts can receive organisation-wide logs and security findings while access is restricted to appropriate security or audit roles.

Infrastructure OU

As the environment grows, shared infrastructure may justify dedicated accounts.

Examples include:

• networking
• DNS
• shared tooling
• selected platform services

This does not mean every organisation needs a dedicated network account from day one.

Centralised networking introduces its own operating model. For a smaller environment with a few independent VPCs, decentralised networking may be simpler and entirely appropriate.

Workloads OUs

Application accounts can be grouped according to the controls that should apply to them.

For example, an organisation might separate production and non-production accounts or use a more granular structure where regulatory requirements, teams or workload characteristics justify it.

Production generally deserves tighter controls than development.

Sandbox OU

Some organisations provide sandbox accounts for experimentation.

A Sandbox OU can give engineers room to test AWS services while still enforcing basic organisational requirements such as permitted Regions, cost limits or restrictions on sensitive services.

Sandbox does not have to mean uncontrolled.

Security and Log Archive Accounts

Centralised security is one of the strongest reasons to design the account architecture before an AWS estate becomes large.

In an environment where every workload administrator can alter the systems that record their own activity, the separation between operating a workload and auditing it becomes weak.

A dedicated Log Archive account provides somewhere to centralise and retain security and operational logs under more restrictive access controls.

AWS's Security Reference Architecture uses this approach and describes the Log Archive account as a dedicated location for ingesting and archiving security-related logs.

Typical log sources can include:

• AWS CloudTrail
• AWS Config
• VPC Flow Logs
• load balancer logs
• AWS WAF logs
• Route 53 DNS logs
• other infrastructure and application logs where appropriate

The objective is not simply to turn logging on.

The architecture should consider:

• who can access logs
• who can delete or alter them
• encryption
• retention periods
• storage lifecycle
• monitoring for unexpected changes
• how investigators retrieve information
• which logs genuinely need central retention

A separate Security or Audit account can then provide controlled administration and visibility for security tooling and findings.

The exact division of responsibilities depends on the organisation, but the principle is important: the people administering an application should not automatically have unrestricted control over the organisation's security evidence.

AWS documents this pattern in its Security Reference Architecture guidance for the Log Archive account.

Designing Workload Accounts

One of the most useful properties of an AWS account is that it provides a strong boundary.

AWS recommends account-level separation for workloads and environments where isolation is required, particularly between production and development or test environments.

Environment isolation

Suppose development and production run in the same AWS account.

Even if they use separate VPCs, IAM policies and naming conventions, they still share an account-level boundary.

Moving production into a separate account provides clearer separation.

A development mistake is less likely to affect production resources, and access policies can be designed independently.

Smaller blast radius

Account boundaries can limit the impact of compromised credentials, incorrect automation or accidental administrative actions.

They are not a substitute for good IAM and security controls, but they provide another meaningful boundary.

Clearer access

Developers might require broad permissions in a development environment but considerably narrower access to production.

Separate accounts make that distinction easier to express and audit.

Billing and quotas

Accounts also create useful boundaries for cost visibility and AWS service quotas.

A runaway development process is less likely to consume a quota needed by a production workload when those environments operate separately.

Does every workload need its own AWS account?

Not necessarily.

Account proliferation has an operational cost.

Every new account requires governance, access, security monitoring, lifecycle management and potentially networking.

A small organisation should not copy an architecture designed for hundreds of engineering teams simply because the diagram looks sophisticated.

Create an account when the boundary provides a meaningful benefit: security isolation, environmental separation, ownership, compliance, billing, quotas or a distinct governance requirement.

AWS's Well-Architected guidance on AWS account management and separation provides further guidance on using accounts as isolation boundaries.

Identity and Access Across the Landing Zone

Creating multiple AWS accounts solves one problem and can create another if access is managed independently inside every account.

A Landing Zone needs a central identity strategy.

AWS IAM Identity Center can centrally manage workforce access across multiple AWS accounts in an AWS Organization.

Rather than repeatedly creating unmanaged IAM users inside individual accounts, access can be designed around users, groups and permission sets.

A simple model might include groups such as:

• Platform Administrators
• Developers
• Security
• Read Only

Permission sets then define the level of AWS access those groups receive in particular accounts.

For example, a developer might receive substantial permissions in Development, read-only access in Production and no access to the Log Archive account.

An administrator might receive elevated access only where the role requires it.

The important architectural principle is to design access around job requirements and least privilege, not convenience.

A Landing Zone is significantly easier to govern when joining, leaving and role changes can be managed centrally instead of searching through individual accounts for IAM users and access keys.

AWS explains this multi-account model in its IAM Identity Center multi-account access guidance.

Guardrails and Service Control Policies

Service Control Policies, usually shortened to SCPs, are one of the most powerful governance mechanisms available through AWS Organizations.

They are also frequently misunderstood.

A user or role still requires the relevant IAM permissions.

A useful way to think about the relationship is:

IAM policy: What is this identity allowed to do?

SCP: What is the maximum that identities in this part of the organisation can be allowed to do?

That distinction is crucial when designing guardrails.

Potential SCP use cases include restricting:

• use of unapproved AWS Regions
• changes to critical security resources
• actions that would weaken central governance
• particular AWS services where policy requires it
• leaving the AWS Organization or closing member accounts outside the intended process

SCPs should be introduced carefully.

A policy that looks sensible on paper can block legitimate automation or administrative operations if its effects have not been tested properly.

A safer approach is to understand the required actions, test policies away from critical production accounts and introduce restrictions deliberately.

AWS provides the authoritative behaviour and limitations in its AWS Organizations Service Control Policies documentation.

Centralised Logging, Security and Monitoring

A governed AWS environment needs more than isolated accounts.

It also needs visibility across them.

Several AWS services contribute different parts of that answer.

AWS CloudTrail

CloudTrail records activity associated with API calls and account actions.

In a multi-account environment, centralising the appropriate CloudTrail logs gives security teams a more reliable audit trail than treating each workload account as an independent logging island.

AWS Config

AWS Config records resource configuration and configuration changes for supported resources.

An organisation can use aggregation to provide broader visibility across accounts and Regions rather than checking each account separately.

Amazon GuardDuty

GuardDuty provides threat detection capabilities using AWS data sources.

In a multi-account environment, AWS supports a delegated administrator model so configuration and findings can be managed across member accounts.

AWS Security Hub

Security Hub can aggregate and manage security findings and security posture across AWS accounts.

The important design decision is not simply enabling another service. It is deciding where security administration sits, which Regions are covered, who reviews findings and what happens when something requires action.

Amazon CloudWatch

CloudWatch supports operational monitoring, metrics, logs and alarms.

Not every CloudWatch log needs to be copied indiscriminately into a central account. The logging design should distinguish between security and audit evidence and high-volume operational telemetry, then define retention and access accordingly.

Centralisation without an operating process merely creates a bigger pile of data.

The architecture should connect collection, retention, visibility and response.

AWS Landing Zone Network Architecture

Networking is where a sensible Landing Zone can quickly become an over-engineered one.

A diagram containing Transit Gateway, inspection VPCs, multiple firewalls, Direct Connect, shared endpoints and centralised ingress might be appropriate for a large enterprise.

It does not follow that a growing SaaS company with three workload accounts needs all of it.

Start with requirements.

VPC and subnet design

A workload VPC commonly separates resources according to how they need to communicate.

A practical VPC design might use:

• a suitably sized VPC CIDR
• public subnets across more than one Availability Zone
• private application subnets across Availability Zones
• private database subnets
• an Internet Gateway where public connectivity is required
• controlled routes between tiers
• NAT or private AWS service connectivity where required
• load balancers as public entry points rather than exposing application instances directly

In one practical CloudOps Studio foundation build, a development workload was structured around a /16 VPC with public, private application and private database subnets distributed across Availability Zones.

The application EC2 instance remained private, administration used AWS Systems Manager Session Manager rather than exposing SSH to the internet, and a public Application Load Balancer provided the required application entry point.

That is not a universal template.

The useful lesson is the principle: expose only the components that need to be public and design the network around workload requirements rather than habit.

Centralised vs decentralised networking

As the number of accounts and VPCs grows, organisations need to decide whether networking remains largely within workload accounts or whether shared networking capabilities move into a dedicated infrastructure or network account.

Centralisation can improve consistency and separation of duties.

It can also increase complexity.

AWS documents patterns using dedicated network accounts, AWS Resource Access Manager and Transit Gateway for environments that need centralised connectivity.

Smaller estates may be better served by simpler patterns.

NAT considerations and cost

NAT Gateways solve a real networking requirement: allowing resources in private subnets to initiate connections outside the VPC without making those resources directly internet-accessible.

But NAT Gateways also have costs.

Do not deploy one, or several, merely because an architecture template contained them.

Ask what outbound connectivity the workload actually requires and whether alternatives such as VPC endpoints are appropriate for particular AWS services.

Availability requirements matter too. Removing every redundant network component to save money can be as inappropriate for a production workload as deploying enterprise-scale networking for a small development environment.

Architecture is a trade-off.

When Transit Gateway makes sense

AWS Transit Gateway provides a central hub for connecting multiple VPCs and on-premises networks.

It becomes useful when point-to-point connectivity becomes difficult to operate, or where central routing and network segmentation are architectural requirements.

It should not be treated as a mandatory Landing Zone component.

Three isolated VPCs that do not need to communicate do not require a Transit Gateway merely because they belong to the same AWS Organization.

AWS provides examples of these approaches in its multi-account network connectivity guidance.

AWS Control Tower's Role in the Architecture

One of the most important distinctions in Landing Zone design is this:

AWS describes Control Tower as an orchestration layer that works with other AWS services to establish and govern a multi-account environment.

It can help establish important foundations and provides controls and account-governance capabilities.

When setting up a Landing Zone, Control Tower can create the Audit and Log Archive accounts within the Security OU and integrate with AWS Organizations.

But Control Tower cannot decide your business requirements for you.

You still need to decide:

• how many accounts you require
• which workloads should be separated
• how OUs should be structured
• which controls belong on which OUs
• how administrators and developers should gain access
• how production access differs from development
• what your network topology should look like
• how security findings are handled
• what logs need to be retained
• how accounts are created and operated
• how costs and tagging are governed

Deploying Control Tower without answering those questions is not the same as designing a Landing Zone.

AWS provides further context in its AWS Control Tower multi-account Landing Zone guidance.

Common AWS Landing Zone Architecture Mistakes

Landing Zone problems are often caused less by missing AWS services than by weak design decisions.

1. Running workloads in the management account

The management account has privileged organisation-level responsibilities and should remain focused on the functions that require it.

Application workloads belong elsewhere.

2. Designing OUs around the company org chart

Finance, Sales and Marketing might make sense on an organisation chart.

They do not automatically make sense as AWS Organizational Units.

Group accounts around governance requirements and common controls.

3. Creating too many AWS accounts

More accounts do not automatically mean better architecture.

If a team cannot operate, monitor, secure and govern the structure it has created, additional separation can become an operational burden.

4. Creating too few AWS accounts

The opposite is equally problematic.

Keeping development, production, security tooling and shared infrastructure together simply because one account is easier can create unnecessary access and blast-radius risks.

5. Failing to centralise important logs

Security evidence should not depend entirely on the account being investigated remaining trustworthy and accessible.

Plan log collection and retention early.

6. Giving everyone broad administrator access

Multi-account architecture achieves little if every engineer has unrestricted access to every account.

Access should reflect roles and environments.

7. Deploying SCPs without understanding their impact

SCPs can affect large parts of an AWS environment at once.

Test policies and understand dependencies before applying restrictive controls broadly.

8. Copying an enterprise network architecture

More components mean more things to operate and usually more things to pay for.

Use Transit Gateway, centralised inspection and dedicated networking accounts when requirements justify them, not because they appear on an impressive reference diagram.

9. Treating Control Tower deployment as the finished architecture

Control Tower helps establish and govern the environment.

It does not remove the need for architecture and operational decisions.

10. Leaving cost governance until later

Cost is part of architecture.

Budgets, account-level visibility, tagging and decisions around components such as NAT Gateways should be considered during foundation design rather than after the first unexpectedly large AWS bill.

Example AWS Landing Zone Architecture for a Growing SaaS Company

Consider a fictional SaaS company that started in AWS with one account.

Its environment now contains:

• development resources
• production resources
• developers with broad IAM permissions
• several VPCs
• application logs
• customer data
• growing AWS spend

The company is also hiring more engineers.

Nothing necessarily failed because the company began with one account. A single AWS account may have been entirely reasonable at the beginning.

The problem is that the architecture no longer reflects the company's risk or scale.

Before: everything in one account

The original account might contain development, production, IAM users, networking, security tooling, logs and shared administrator access.

This creates several questions:

• Can developers change production resources?
• Can somebody responsible for a workload alter its audit trail?
• Can a development error affect production?
• Can AWS costs be separated cleanly?
• How are new employees given access?
• What happens when another application is added?

After: a governed multi-account foundation

A proportionate next architecture might separate the environment into:

• Management — AWS Organizations and Control Tower administration
• Security — Log Archive and Security / Audit accounts
• Non-production — Development and Staging where required
• Production — Production workload account
• Infrastructure — Shared network or services only where justified

Access is provided centrally using IAM Identity Center.

Production and non-production receive different access and governance controls.

CloudTrail and relevant security information are centralised.

GuardDuty and Security Hub can be administered across accounts.

SCPs provide organisation-level permission guardrails.

Budgets and tagging standards improve cost visibility.

The improvement is not that the company now has more boxes on an AWS diagram.

The improvement is that security, access and operational boundaries now reflect the importance of the workloads.

If the company later adds another product, regulated workload or engineering team, it has a foundation that can evolve instead of having to reinvent AWS governance every time.

When Should You Build an AWS Landing Zone?

There is no magic number of EC2 instances or employees at which an organisation suddenly needs a Landing Zone.

The better question is whether the existing AWS account model still matches the organisation's risk and operating requirements.

Common signals include:

• production and development resources are mixed together
• multiple teams require different levels of AWS access
• the organisation is creating additional AWS accounts
• production workloads need stronger isolation
• security or compliance requirements are increasing
• centralised logging and auditability are required
• AWS spending is becoming harder to attribute or control
• administrators have accumulated overly broad permissions
• a significant AWS migration is being planned
• multiple workloads will move to AWS
• there is no consistent process for creating new accounts
• governance differs between production and non-production
• the AWS estate has grown organically without an intentional account structure

A Landing Zone is often easier to establish before a large migration or rapid expansion than after dozens of workloads have already inherited inconsistent account, access and network designs.

That does not mean everything must be perfect before the first workload moves.

It means the organisation should establish enough foundation that subsequent workloads land somewhere intentional.

CloudOps Studio AWS Landing Zone Reference Architecture

CloudOps Studio's reference approach starts with a principle rather than a fixed number of AWS accounts:

A practical foundation can be designed around seven areas.

1. Organisation and account structure

Use AWS Organizations as the organisational foundation and AWS Control Tower where appropriate to establish and govern the multi-account environment.

Keep the management account focused on organisation-level administration.

Separate security, logging and workloads according to their responsibilities.

2. Governance boundaries

Design OUs around groups of accounts that need common controls.

Do not add hierarchy merely for appearance.

Use SCPs and Control Tower controls deliberately, with tighter policies where the risk justifies them.

3. Central identity

Use IAM Identity Center to provide workforce access across accounts.

Map groups and permission sets to actual responsibilities.

Administrative, developer, security and read-only access should not automatically be equivalent across every account.

4. Security and logging

Provide dedicated security and logging responsibilities rather than allowing each workload account to operate as an island.

A baseline can include:

• organisation-level CloudTrail strategy
• central log retention
• AWS Config and aggregation where required
• GuardDuty
• Security Hub
• controlled Security / Audit access
• appropriate encryption and retention controls

5. Workload isolation

Separate production from development and non-production where the risk warrants it.

Create additional workload accounts where there is a genuine isolation, ownership, compliance, cost or operational reason.

Do not create accounts simply to maximise the number of boxes in the architecture.

6. Network architecture

Start with the workload's connectivity requirements.

For a straightforward workload, this may mean a VPC with appropriately sized address space, public entry points, private application and database tiers, multiple Availability Zones and tightly controlled administrative access.

As the estate grows, networking can evolve towards shared network services, Transit Gateway, centralised routing or inspection where those patterns solve real requirements.

7. Operations, backup and cost governance

A Landing Zone needs to remain governable after implementation.

That means considering:

• backup policies
• budgets and cost visibility
• tagging standards
• account ownership
• monitoring
• account provisioning
• security findings
• changes to guardrails
• lifecycle management

The reference architecture should be viewed as a collection of connected layers:

• Organisation and Governance: AWS Organizations, Control Tower, OUs and SCPs
• Identity: IAM Identity Center, groups and permission sets
• Security: Security / Audit account, GuardDuty, Security Hub and AWS Config
• Logging: CloudTrail and security logs flowing to the Log Archive account
• Infrastructure: network and shared services where required
• Workloads: development, staging and production environments
• Operations: backup, monitoring, cost controls and tagging

Building the Foundation Before AWS Becomes Difficult to Govern

A good AWS Landing Zone architecture should make growth easier, not make AWS more complicated for its own sake.

Accounts provide meaningful security and operational boundaries. OUs give those accounts a governance structure. IAM Identity Center provides central workforce access. SCPs establish permission guardrails. Central logging and security services improve visibility. Network architecture determines how workloads communicate without exposing more than necessary.

AWS Control Tower can help establish and govern that multi-account environment, but the quality of the Landing Zone still depends on the decisions made around it.

The right architecture for a growing SaaS business may be considerably simpler than the right architecture for a regulated enterprise operating hundreds of accounts.

The goal is therefore not to reproduce the largest AWS reference architecture you can find.

It is to build the right foundation for the workloads, people, risks and growth the organisation actually has.

If you are planning a production AWS environment, preparing an AWS migration or restructuring an AWS estate that has grown without clear governance, CloudOps Studio's AWS Landing Zone and Foundation Build service can help design and implement the account structure, identity, guardrails, security, logging and governance foundation required to operate AWS with clearer control.