Landing zones

A landing zone is the multi-account foundation every workload runs on: the AWS Organization, its accounts, the network that connects them, the security services that watch them, identity for people and pipelines, and the state and delivery machinery that manages all of it. The BuiltForProd AWS Baseline is a landing zone delivered as code in one repository, acme-aws-platform-baseline.

Why it matters in production

A single account, or an ad-hoc sprawl of them, has no isolation between environments, no clear blast radius and no governance model that grows with the company. Accounts are the hardest boundary AWS offers: an IAM mistake, a leaked credential or a runaway workload in one account does not reach another. One account per stage gives every environment its own IAM and billing boundary; one account per shared concern (logs, security tooling, network, identity) keeps those concerns out of the accounts that run workloads and out of the management account.

The offerings note describes the result as conceptually similar to Cloud Posse architectures and AWS Control Tower Account Factory for Terraform, delivered as a turnkey customized product.

How the platform applies it

The organizations unit in environments/core/root/global creates one AWS Organization with two organizational units (OUs) and fourteen accounts: the management account plus thirteen members.

Account	Responsibility
core-root (management, 111111111111)	The Organization, OUs, service control policies and tag policy; the state bucket; the organization CloudTrail; delegation of every security service. Workloads stay out of it.
core-security (222222222222)	Delegated administrator for GuardDuty, Security Hub, Inspector, Macie, IAM Access Analyzer and Firewall Manager; KMS keys for secrets; automated remediation; the observability sink.
core-audit (333333333333)	The encrypted, write-protected audit bucket and the AWS Config aggregator.
core-identity (444444444444)	IAM Identity Center permission sets and group assignments.
core-network (555555555555)	IPAM, the hub VPC with centralized egress, the Transit Gateway, private DNS and the Client VPN endpoint.
core-dns (666666666666)	Public Route 53 hosted zones.
core-artifacts (777777777777)	Container registries with immutable tags and shared artifact buckets.
core-auto (888888888888)	GitHub OIDC federation, per-repository deployer roles, optional self-hosted runners.
core-corp (999999999999), core-public (101010101010)	Reserved for internal tools and intentionally public assets; baselined, nothing else deployed yet.
plat-sandbox, plat-dev, plat-staging, plat-prod	One workload account per stage, identical in shape, each with a spoke VPC attached to the Transit Gateway.

Every account receives the same account baseline from units/account-baseline: default EBS encryption, an account-wide S3 public-access block, AWS Config recording and the acme-terraform-deployer role CI assumes. Core accounts get it through the stacks/includes/account-common include; workload accounts get it through the stacks/plat-account template.

Naming

Thing	Pattern	Example
Account name	acme-core-<name>, acme-plat-<name>	acme-core-network, acme-plat-prod
Stage	core: the account name; plat: a three-letter slug	network; prd, stg, dev, sbx
Resource prefix	<namespace>-<region slug>-<stage>	acme-usw2-prd-vpc
Root email	plus-addressing on one mailbox	aws+acme-core-audit@company.com

Global and regional

Each account folder holds one folder per deployed region and a global/ folder for things that exist once per organization: Organizations, IAM Identity Center, GitHub OIDC, public DNS zones, the Shield Advanced subscription, IPAM, the Client VPN endpoint and the state backend. Global units are named acme-glob-<stage>-* and deploy to the home region. Everything else (VPCs, the Transit Gateway, detectors, CloudTrail, Config) is regional. A unit's folder therefore tells you both which account it deploys to and whether it is per region or per organization.

Delegation keeps the management account small

The management account is not subject to service control policies and is the highest-value target, so it holds Organizations, billing and state only. Every security and governance service is delegated to the account that owns it: GuardDuty, Security Hub, Inspector and Macie to core-security, AWS Config to core-audit, IAM Identity Center to core-identity. The one exception is organization conformance packs, deployed from core-root because they need a service-linked role only the management account holds.

Worked example: adding a workload account

A new stage such as plat-qa is added to the plat_accounts map in the organizations unit with its root email, then given an account.hcl (account_name, ou, stage), a region folder with region.hcl, and a stack file that instantiates stacks/plat-account. Its VPC gets an entry in the VPC map, and the stage is placed in one isolation domain in network.hcl. The seven landing-zone units every workload account has come from the template; Identity Center assignments and the blueprint repositories' stage lists follow. See hub-and-spoke networking for what the new spoke connects to and least privilege for who can reach it.

Common mistakes

• Running workloads in the management account. It is exempt from service control policies; keep it to Organizations, billing and state.
• Copying a global unit into a second region. Organizations, IAM, IPAM and the Client VPN endpoint exist once; a copy means a duplicate Organization or an EntityAlreadyExists error. Global units live in global/.
• Reusing a closed account's email. AWS keeps a closed account suspended for 90 days and its email cannot be reused for a new account.
• Making a bucket public outside core-public. Automated remediation re-blocks public buckets everywhere else, and the guardrail policy stops humans from changing the block.