An AWS landing zone is the multi-account baseline you build once and keep.

IWhat an AWS landing zone is, and why multi-account

A landing zone is not a product and not a single service. It is a well-architected, multi-account environment your applications land in, set up so every new account is governed, logged and locked down from the first minute.

It bundles five things teams otherwise bolt on late: accounts under AWS Organizations, preventive guardrails through Service Control Policies (SCPs), central tamper-resistant logging (CloudTrail and AWS Config delivered to a dedicated log-archive account), central security findings (Security Hub and GuardDuty), and federated human access through IAM Identity Center so nobody has long-lived IAM users. The network spine usually comes with it.

Why many accounts instead of one with tags? In AWS the account is the strongest isolation and billing boundary. An SCP on the production OU can make it impossible to disable CloudTrail, even for an account admin. A leaked credential or a bad IaC apply stays inside one account. And per-account billing is the cleanest cost signal AWS gives you.

More accounts means more to provision, which is exactly what a landing zone automates: Control Tower's Account Factory (or LZA, or your Terraform) makes a fully governed new account a minutes-long, templated step. Split along the seams that matter: production vs non-production, security tooling vs the workloads it watches, shared infrastructure vs app teams, and a throwaway sandbox.

IIThe account structure: Organizations, OUs and where things go

Organizational Units (OUs) are how you apply policy to groups of accounts at once. SCPs attach to OUs and flow down to every account inside, so the OU layout is a security decision. This is the common default, drawn from AWS's multi-account guidance:

• Security OU: The Log Archive account (write-only destination for org-wide CloudTrail and Config) and the Audit or Security Tooling account (where Security Hub and GuardDuty findings collect). Access is tight and rarely interactive.
• Infrastructure OU: Shared services: networking (Transit Gateway, shared VPCs, Route 53 Resolver, egress), CI/CD tooling, container registries, image pipelines. Often a Network account and a Shared-Services account.
• Workloads OU: Where applications run, split into Prod and Non-Prod child OUs so production gets stricter SCPs. One account per workload and environment is a common granularity.
• Sandbox OU: Disposable accounts for experiments, cut off from production networks and data, with a hard budget and loose guardrails.
• Suspended OU: A deny-everything SCP to neutralize a compromised or retired account instantly, without deleting it.

A young startup can launch with Security (log archive and audit), one Shared-Services account, Prod and Staging workload accounts and a Sandbox, and grow into the rest. Model your security and environment boundaries in OUs, not your org chart.

IIIGuardrails: preventive and detective

Preventive guardrails make an action impossible. Detective guardrails flag a misconfiguration. A real landing zone uses both.

Preventive guardrails are SCPs. An SCP does not grant permissions; it caps them, and no IAM policy inside the account can override an SCP deny. A typical starter set:

• Deny disabling CloudTrail, AWS Config, GuardDuty and Security Hub.
• Deny deleting or changing the central log buckets and their policies.
• Restrict the Regions an account may use, so resources and bills do not accumulate where you never meant to run.
• Deny everyday use of the root user, and deny leaving the organization.
• Optionally, require encryption and deny public IPs or open security groups in production OUs.

Detective guardrails are AWS Config rules and Security Hub controls that check resources against a baseline (CIS AWS Foundations, AWS Foundational Security Best Practices) and raise a finding on drift: a public bucket, an open SSH port, an unrotated key. Control Tower ships a managed library of both kinds; LZA and Terraform builds wire the equivalents explicitly. The design question is the same: what must be impossible, and what must be visible.

IVCentral logging and security: CloudTrail, Config, Security Hub, GuardDuty

Centralization turns a pile of accounts into a governed estate: every account ships its audit trail and security findings to one place workload teams cannot tamper with.

For compliance, "show me that logging is central, immutable and complete, and threat detection is on everywhere" is the first question SOC 2, ISO 27001, HIPAA and PCI assessors ask. A landing zone answers it with a screenshot.

VIdentity (IAM Identity Center) and networking (Transit Gateway)

Two concerns cut across every account: how people get in, and how accounts talk to each other.

VIHow to build one: Control Tower vs LZA vs DIY Terraform

Most teams should start with Control Tower. A regulated or complex estate may need LZA. A platform team with the staff to maintain it may go pure Terraform or OpenTofu.

AWS Control Tower is the managed, opinionated front door. It sets up Organizations, the Log Archive and Audit accounts, a curated library of preventive and detective controls, IAM Identity Center and Account Factory. You give up some flexibility for a known-good, AWS-supported baseline in days, with AWS maintaining the controls.

The Landing Zone Accelerator on AWS (LZA) is a configuration-driven deployment (CloudFormation and CDK) for heavier requirements: public sector, healthcare, finance, multi-Region or sovereign needs, controls mapped to specific frameworks. More explicit than Control Tower and more to operate: you own a large config repo and pipeline.

DIY Terraform or OpenTofu (Terraform is BSL-licensed since 2023; OpenTofu is the open fork) gives total control as code, and you maintain the account vending and control mapping Control Tower would maintain for you. Without dedicated platform engineers it tends to become a system one person understands. A common middle path: Control Tower owns the governed baseline, and Terraform or OpenTofu manages everything inside the accounts.

VIIWhen you need a landing zone, and when you do not yet

Too early and it is ceremony; too late and you retrofit under audit pressure.

• You have more than one account: A second environment in its own account needs consistent guardrails and central logs.
• More than a couple of people have console access: Role-scoped, centrally offboardable access stops being optional. Shared root credentials are a breach and an audit failure waiting to happen.
• A compliance deadline is within a year: Central immutable logging, org-wide threat detection and SSO are the foundational controls auditors check first.
• You are about to grow the team or the estate: Account Factory makes a new account a safe, minutes-long step.
• You are migrating to AWS: Build the foundation before the workloads arrive. AWS's Migration Acceleration Program describes a Mobilize phase where you build your operational foundation.
• You inherited an ungoverned estate: Root keys in use, admin IAM users named after people who left, CloudTrail off in some Regions: retrofitting a landing zone is the highest-leverage cleanup.

You do not need one yet for a solo prototype in a single account with no customer data and no compliance timeline. Turn on CloudTrail and GuardDuty, avoid the root user, set a billing alarm, and build the landing zone when the second account, first hire or first customer contract arrives.

VIIIDoing it yourself, or with a partner

A landing zone is a routine engagement for a good AWS partner. The alternative is hiring and ramping a platform engineer, which takes months.

CloudRoute matches you with one vetted AWS partner with the right track record: Control Tower, LZA, SOC 2, or your source platform if you are migrating. We reply within 24 hours; your matched partner reaches out within 5 business days. The deliverable is the organization itself (OU structure, guardrails, central logging and security, IAM Identity Center wired to your IdP, the network spine) handed over with documentation and, where it fits, IaC.

Who pays: a landing zone on its own is normal paid work. AWS funding that a partner can file comes through three routes: MAP when you migrate to AWS, POC when you test something, and incremental workload (IW) funding when you launch new work on AWS. If you are migrating, AWS's MAP page describes a Mobilize phase where you build your operational foundation, so your matched partner checks whether your migration qualifies: typically $50K to $150K for startups. Depends on the workload; AWS approves. CloudRoute is free for startups; partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.

AWS Activate credits are separate, and you apply for them yourself: AWS Activate Founders ($1,000 to start, up to $5,000) if no investor backs you, or AWS Activate Portfolio (up to $200,000) with the Org ID from an Activate Provider. A consulting partner cannot file Activate for you, and credits pay for AWS usage, not a partner's invoice. See the startup path.