Standing Up a Landing Zone for Eighty Accounts

The situation

An established enterprise has been on AWS for ten years. They grew organically, one account to start, then one per project, then whatever anyone asked for. Today they have ~80 AWS accounts inside a single AWS Organization that someone turned on five years ago, with no consistent OU structure, no central logging, no uniform IAM, and no guardrails.

The business has five BUs (Retail, Wholesale, Logistics, Data, Platform) each running prod and non-prod workloads. A new platform team of four engineers has six months to formalise the foundation. They want a coherent OU structure aligned with the BU/env shape, centralised security tooling (Config, GuardDuty, Security Hub aggregator in a dedicated account), centralised logging (an organisation CloudTrail plus a central CloudWatch destination), preventive guardrails (no public S3, no Internet Gateways in security accounts, a region allow-list), self-service account provisioning, and SSO via IAM Identity Center federated to the corporate IdP.

The question is how to stand all of that up while also migrating 80 existing accounts into it.

What actually matters

Foundations are easy to pick in isolation and hard to pick together. Five lenses are worth holding the candidates against.

Time-to-value versus surface area. A team of four with six months cannot build a landing zone from scratch and migrate 80 accounts and wire centralised security and author guardrails and stand up self-service provisioning. Every month spent on plumbing is a month not spent on the migration. The foundation that ships the most of those pieces out of the box buys months. The one that makes the team write them from scratch is charging those months back.

Fit, not features. The richer foundation is often the more regulated one, there are options on the menu that carry pre-built configuration aligned to specific compliance frameworks (NIST, CMMC, HIPAA, FedRAMP, industry-specific forks). Beautiful if any of those acronyms matter. Overhead if none of them do. A small team should pick the foundation whose shape matches the problem they have, not the problem they might have if they worked somewhere else.

Inheritance as an architectural property. “Centrally managed” isn’t one thing. It’s either a pattern the team must enforce (write SCPs, apply them to OUs, watch for drift) or a pattern the service enforces (plans attach to OUs and inherit to members automatically, including new accounts joining later). The second shape costs dramatically less to run because new accounts don’t require a per-account deploy. Every candidate needs to be evaluated on what happens when account 81 joins, not only on what’s true when 80 are already in.

The migration shape of existing accounts. 80 accounts is a lot of history. Some have Config recorders with custom rules. Some have their own CloudTrail trails. Some have bespoke IAM roles the owning team depends on. A foundation that requires a “brand-new greenfield” isn’t an option; a foundation that adopts existing accounts via a documented enrolment workflow is. The enrolment story decides whether migration takes a month or takes the full six.

Where bespoke ends. Every real environment has requirements the foundation won’t cover out of the box. The question is whether customisations layer cleanly on top (a framework that listens for lifecycle events and deploys extra stacks) or whether they forked the foundation and the team now maintains the fork. The first is sustainable; the second is how teams end up owning their platform forever.

And underneath all of this: cost as a secondary concern, not a primary one. The managed-service variants are typically free in themselves; what gets paid is the underlying Config, CloudTrail, S3, and CloudWatch usage they orchestrate. The landing zone is almost never the line item on the bill that gets discussed. What gets discussed is engineering time spent operating it.

What we’ll filter on

1. Prescriptive OU structure that maps to the BU/env shape without a design committee.
2. Security tooling aggregated automatically. Config, GuardDuty, Security Hub wired via delegated administrator.
3. Built-in preventive guardrails for the common controls, not a library project.
4. Self-service account provisioning a non-engineer can use.
5. New accounts inherit policy automatically when they join the OU.
6. Fits four engineers in six months alongside a migration of 80 existing accounts.

The multi-account foundation landscape

1. AWS Control Tower. A managed landing-zone service. Launching it produces an Organization with a prescriptive OU structure, a Log Archive and Audit account in a Security OU, a baseline of CloudTrail, Config, and IAM Identity Center, preventive controls via SCPs, detective controls via Config rules, and proactive controls via CloudFormation Hooks. Account Factory fronted by AWS Service Catalog provides self-service provisioning. The service itself is free; you pay only for underlying usage.

2. Landing Zone Accelerator on AWS (LZA). An open-source solution maintained by AWS, built on CDK (TypeScript). Target audience: highly-regulated workloads, government, financial services, healthcare. Positioned as complementary to Control Tower: deploy Control Tower for the foundational landing zone, then layer LZA on top for the expanded control set. For an ordinary enterprise, LZA is overkill, larger configuration surface, ongoing commitment to track upstream releases.

3. The legacy AWS Landing Zone solution. The pre-Control Tower predecessor. An AWS Solutions CloudFormation bundle, similar conceptual structure but every piece stitched together as customer-owned templates. AWS announced end-of-life years ago; new deployments are not recommended.

4. Do-it-yourself: Organizations + StackSets + Config + IAM Identity Center. The platform team writes everything: OU tree, StackSets to deploy baselines, Config + GuardDuty + Security Hub wired by hand, Identity Center from scratch, SCPs hand-authored, a home-grown request pipeline. A six-engineer-year project, not a four-engineer-six-month one.

Side by side

Option	Prescriptive OUs	Security aggregated	Built-in guardrails	Self-service	Inherits to new accounts	Fits 4 eng / 6 mo
AWS Control Tower	✓	✓	✓	✓	✓	✓
Landing Zone Accelerator	✓	✓	✓	✓	✓	✗
Legacy AWS Landing Zone	✓	✓	—	✗	—	✗
DIY Organizations + StackSets	✗	✗	✗	✗	✗	✗

The survivor is AWS Control Tower, with LZA as the layered answer if regulated-industry controls ever surface. DIY is the wrong shape for this team. The legacy Landing Zone is the wrong shape for any new deployment.

Matching the shape to the foundation

Control Tower, in depth

The landing zone. When the management account launches Control Tower, the service creates or adopts an AWS Organization with a prescriptive shape: a management account, a Security OU holding a Log Archive account (S3 buckets receive the organisation-wide CloudTrail and Config snapshots, write-only from other accounts) and an Audit account (delegated administrator for Security Hub, GuardDuty, Config aggregation), a Sandbox OU for experimental accounts, and whatever custom OUs the customer adds. For this scenario: ten BU-shaped OUs (5 BUs × prod/non-prod).

The Security OU is Control Tower’s only structural opinion that matters. Everything else is the customer’s choice.

The control catalogue. Controls come in three shapes: preventive (Service Control Policies attached to OUs, deny API calls outright), detective (AWS Config rules evaluating resources after they exist, reporting compliance to Security Hub), and proactive (CloudFormation Hooks evaluated at stack-create time, blocking non-compliant CloudFormation before API calls land).

The three stack: a preventive SCP blocks the API call, a proactive hook blocks the CloudFormation earlier, a detective rule alerts on anything that slipped through.

The specific guardrails all exist by default. Block-public-access is a preventive SCP (CT.S3.PR.1) plus a detective Config rule. IGW-in-Security is a preventive SCP denying ec2:AttachInternetGateway attached to the Security OU. The region allow-list is the landing-zone Region Deny control, a preventive SCP with a Region NotIn condition.

Account Factory and self-service. Account Factory is the account-vending mechanism, surfaced through AWS Service Catalog. A product team submits a “new account” request as a Service Catalog product launch, account name, email, target OU. Control Tower creates the account, places it in the requested OU, deploys the seven baseline stacks (CloudTrail, CloudWatch, Config, Roles, Service Roles, Service-Linked Roles, VPC), enables mandatory controls, and registers the account with Identity Center.

Account Factory for Terraform (AFT) is the GitOps-oriented cousin: a separate AFT management account hosts a Terraform pipeline that turns a git push into an Account Factory provisioning action, with per-account customisation modules afterwards.

Customisations for Control Tower (CfCT). The framework for attaching your own CloudFormation and SCPs to the landing zone. CfCT listens for Control Tower lifecycle events and fires a pipeline that deploys customer templates to the right targets. CfCT fills the gap between Control Tower’s built-in baseline and your complete baseline.

Centralised security. Control Tower designates the Audit account as delegated administrator for Security Hub, GuardDuty, and Config aggregation via Organizations delegated-admin. Every enrolled account has its findings pointed at the aggregator by the baseline.

Centralised logging. Control Tower 3.0+ creates an organisation CloudTrail writing to the Log Archive’s S3 bucket, covering every account automatically.

A worked rollout

Six months, four engineers, 80 existing accounts.

Month 1, foundation. A greenfield Organization isn’t on the table (five years of billing history, an MSP relationship), so the team launches Control Tower into the existing Organization. The existing root becomes Control Tower’s root. A brand-new Log Archive account and a brand-new Audit account are created in the Security OU. Control Tower requires these fresh. The landing zone completes in under an hour from the button; the surrounding review takes a week.

BU-shaped OUs are created and registered: Retail-Prod, Retail-NonProd, through Platform-Prod, Platform-NonProd. Ten OUs beside the built-in Security and Sandbox.

The three required preventive controls get applied: public-S3 block on all BU OUs, IGW-deny on the Security OU (not the BU OUs, application accounts legitimately need IGWs), Region Deny at landing-zone level with us-east-1, eu-west-1, ap-southeast-2 allow-listed.

Identity Center is federated to Entra via SAML. Permission sets defined centrally and mapped to Entra groups.

Month 2. Account Factory and Service Catalog. Account Factory is configured with the naming convention, the baseline network, and the default tags. A Service Catalog portfolio holds the Account Factory product, with a JIRA-to-Service-Catalog bridge so “new account” tickets trigger a launch once approved. CfCT gets deployed pointing at a Git repository holding customisations: organisation-wide GuardDuty, the Security Hub aggregator, a baseline DeveloperRole, the chosen Config conformance pack.

Months 3-5, migrating the 80 existing accounts. Control Tower’s account enrolment workflow adopts existing accounts, with constraints: the target OU must be registered with Control Tower, the account must have no existing Config recorder or delivery channel, the AWSControlTowerExecution IAM role must exist, pre-existing CloudTrail trails should be removed.

The team batches the 80 accounts by BU and env. Retail’s seven non-prod accounts go first; by end of week one they’re enrolled and baselined. Config drift is recorded as non-compliant in Security Hub and becomes a tracked remediation backlog, not a blocker.

By end of month 5, all 80 accounts are enrolled.

Month 6, hardening and handover. Runbooks, alarms, quarterly control-catalogue reviews, product teams trained.

When LZA earns its keep

• Federal / government. FedRAMP Moderate/High and CMMC compliance require specific SCP templates, flow-log configurations, session-manager SSH patterns that LZA ships as named configuration sets.
• Financial services. GLBA, SOX, and PCI-DSS controls map directly onto LZA’s configuration files.
• Healthcare. A dedicated Landing Zone Accelerator for Healthcare fork bundles HIPAA/HITRUST-aligned controls.

LZA uses Control Tower’s landing zone as its foundation and layers CDK-generated CloudFormation on top. An ordinary enterprise doesn’t need that layer; a regulated one can’t live without it.

What’s worth remembering

1. Control Tower is a managed service; LZA is an AWS-maintained open-source solution; the legacy Landing Zone is retired; DIY is always available. Four distinct things.
2. Control Tower’s landing zone is prescriptive about the Security OU and flexible about everything else. BU-shaped OUs sit alongside the built-ins.
3. Controls come in three shapes: preventive SCPs, detective Config rules, proactive CloudFormation Hooks. They stack; use the earliest-binding control available.
4. Account Factory + Service Catalog is the self-service path; AFT is the GitOps equivalent; CfCT is the customisation framework.
5. Existing accounts enrol via a workflow with prerequisites, no pre-existing Config recorder, AWSControlTowerExecution role in place, no competing CloudTrail. Log archive and audit accounts must be fresh.
6. Security Hub, GuardDuty, and Config are delegated-administered from the Audit account, wired without per-account configuration.
7. LZA fits regulated industries and deploys on top of a Control Tower landing zone, not instead.
8. Pricing for Control Tower itself is zero, charges come from underlying Config, CloudTrail, S3, CloudWatch, SNS.
9. New accounts inherit policy automatically once placed in the right OU, the operational win that compounds over years.