The landing zone deploys through three CDK stacks in a fixed order, split across two AWS accounts. The organization phase deploys one stack to your management account. The landing-zone phase deploys the other two from a dedicated landing zone account, which acts as the CloudFormation StackSets delegated administrator. The management account owns the organization, and the landing zone account does the provisioning.
Each landing-zone stack depends on outputs from LandingZoneOrganizationStack, so the first deployment runs in two steps: the organization must exist, and the landing zone account must be registered as the StackSets delegated administrator, before the landing-zone stacks can target the organization's accounts.
Every stack deploys in your primary Region with termination protection enabled. The StackSets that fan out from the landing-zone stacks run in the primary Region plus any secondaryRegions you set in landing-zone-settings.ts. Together these are the landing zone's active Regions. Which StackSets use every active Region and which use only the primary Region is listed per StackSet below and on the StackSets page.
Accounts and OUs
The starter's organization-structure.ts defines this topology. Every OU and account below is yours to rename, add to, or remove. See Organization structure.
| Account | OU | Role |
|---|---|---|
| Management | Root | Owns the organization, runs the organization phase, and receives its own baseline through ProvisionManagementStackSet |
| Security | Security | Delegated administrator for the security services; runs OrganizationSecurityStackSet |
| Observability | Security | CloudTrail and AWS User Notifications delegated administrator; holds the organization trail, its log buckets, and the CIS alarms, and emails the organization's alerts; runs ObservabilityStackSet |
| FinOps | FinOps | Delegated administrator for Compute Optimizer, Cost Optimization Hub, and Resource Explorer; runs FinOpsStackSet |
| Landing zone | Infrastructure | CloudFormation StackSets delegated administrator; runs the landing-zone phase |
| Workload accounts | Development, Production | Receive the account baseline, CDK bootstrap, and service quota requests |
There is no separate log archive account: the observability account stores the organization trail's logs. The five service control policies the starter ships attach at three levels. The root carries criticalSecurityGuardrailsSCP, protectTaggedCloudFormationStacksSCP, and denyAllOutsidePrimaryAndSecondaryRegionsSCP. The security account carries protectSecurityHubConfigurationSCP, and the Suspended OU carries lockdownSuspendedAccountsSCP. See Service control policies.
Organization phase: LandingZoneOrganizationStack
Deploys to the management account. It runs first: it publishes the organization identifiers every later stack consumes and sets up what the landing zone account needs to take over provisioning.
| What it creates | Details |
|---|---|
| AWS Organization | Feature set ALL. Enables the organization policy types (SCP, resource control, tag, backup, Inspector, Security Hub, and GuardDuty by default) |
| Trusted service access | Enables trusted access for the AWS services listed in trusted-access.ts so org-wide features and delegated administration can operate |
| Organizational Units | As defined in organization-structure.ts. Moving an account to another OU keeps its SCP attachments and delegated-administrator registrations |
| AWS accounts | Created and moved to their target OUs |
| Service Control Policies | Authored in service-control-policies/, attached at root/OU/account level |
| Cost budgets | A monthly AWS Budgets cost budget for each budget you set on the root, an OU, or an account in organization-structure.ts, created in the management account. An OU budget covers every account under it combined. Alerts go to the budget's own recipients, else the nearest budgetAlertRecipients, else the email of each account it covers |
| Delegated administrators | Registers the accounts in delegated-admins.ts: the security account for Config, Config multi-account setup, GuardDuty, IAM, IAM Access Analyzer, Inspector, Macie, and Security Hub; the observability account for CloudTrail and AWS User Notifications; the FinOps account for Compute Optimizer, Cost Optimization Hub, and Resource Explorer; and the landing zone account for CloudFormation StackSets. GuardDuty, Inspector, and Macie register in every active Region |
| Landing zone account bootstrap | Through LandingZoneBootstrapStackSet: CDK toolkit resources and the landingzone GitHub Actions deploy role in the landing zone account, in the primary Region |
| GitHub Actions OIDC provider | GitHubActionsOidcConstruct, creates the OIDC provider and GitHubActionsServiceRole, scoped to your repository |
| Alternate contacts | Applied to every account via SetAlternateContactConstruct |
| Marketing email unsubscribe | Unsubscribes account root emails from AWS marketing mail via UnsubscribeMarketingMailsConstruct |
| Management-account drift detection | Daily CloudFormation drift detection over the landing zone's own StackSets and stacks in the management account, via DetectCloudFormationDriftConstruct |
| Close-account reconcile | When the organization structure includes CloseAccountOU, an 8-hour reconcile that closes any active accounts in that OU, via CloseAccountConstruct |
| Organization stack outputs | Every OU ID as a <Key>Id output, plus an account <Key>Id output for each account marked publishAccountIdOutput |
LandingZoneBootstrapStackSet is a service-managed StackSet the organization phase targets at the Infrastructure OU intersected with the LandingZoneAccount. It gives the landing zone account the CDK toolkit resources and deploy role it needs before the landing-zone phase runs. See Delegated Administrators for what gets registered here.
Landing-zone phase: LandingZoneFoundationStack
Deploys from the landing zone account. It prepares the shared infrastructure that every other StackSet depends on, then provisions the landing zone's own accounts: management, observability, security, and FinOps. Each of those accounts is targeted directly, so these are self-managed StackSets.
| What it creates | Details |
|---|---|
| StackSet IAM roles | Administration and execution roles for self-managed StackSets, managed by the landing-zone foundation |
| Regional asset buckets | One asset bucket per active Region in the landing zone account, which the StackSets deploy their assets from. Adding a Region is one landingzone deployment; a removed Region keeps its bucket until no StackSet uses it there |
| Landing-zone-account drift detection | Daily CloudFormation drift detection over the landing zone's own StackSets and stacks in this account |
| ObservabilityStackSet | The organization trail, its log buckets, the Athena table, and the 14 CIS alarms in the observability account, with the security-alerts topic the alarms notify, and the User Notifications alerts to the security and operations contacts |
| ProvisionManagementStackSet | Management-account secure defaults, Resource Explorer indexes, the optional AWS Organizations account quota request, and Compute Optimizer and Cost Optimization Hub enrollment (the management account cannot receive service-managed StackSets, so this self-managed StackSet handles it) |
| OrganizationSecurityStackSet | Organization-wide security run from the security account: IAM centralized root access, the IAM Access Analyzer organization analyzer, and Security Hub V2 management for Security Hub CSPM, GuardDuty, Inspector, and Macie |
| FinOpsStackSet | Cost Optimization Hub organization preferences and the Resource Explorer organization view in the FinOps account |
| Optional ExternalAccessStackSet | Grants a third-party account admin access across the organization (only when externalAdmins is set in settings) |
| StackSet | Account | Regions |
|---|---|---|
| ObservabilityStackSet | Observability | Primary |
| ProvisionManagementStackSet | Management | All active |
| OrganizationSecurityStackSet | Security | All active |
| FinOpsStackSet | FinOps | Primary |
FinOpsStackSet always deploys after ProvisionManagementStackSet, which enrolls the organization in Cost Optimization Hub. ObservabilityStackSet deploys to the primary Region only; its organization trail covers every Region. Inside OrganizationSecurityStackSet, the IAM Access Analyzer analyzer is Regional and deploys in every active Region, while IAM centralized root access and Security Hub V2 are managed once from the primary Region.
A single organization trail, created in the observability account, covers every account in the organization, including the management account. There are no per-account trails.
CloudFormation drift detection runs in both administrator accounts: this stack watches the landing zone account, and the organization phase watches the management account. See Constructs for the drift-detection construct.
Landing-zone phase: LandingZoneMemberAccountsStack
Also deploys from the landing zone account, after the foundation stack. It rolls out the member-account baseline. These StackSets are service-managed, so an account that joins a targeted OU receives them automatically.
| StackSet | Targets | Details |
|---|---|---|
| AccountSecurityStackSet | All member accounts (root OU), all active Regions | Per-account hardening with no org-wide control: deletes default VPCs, enables EBS encryption by default, hardens default security groups, configures SSM service settings, sets S3 Block Public Access and password policy |
| ResourceExplorerStackSet | All member accounts (root OU) except the FinOps account, primary Region | An AWS Resource Explorer index in every active Region and the aggregator index in the primary Region, so the FinOps account can search every account |
| CdkBootstrapStackSet | Development and Production OUs (excluding the landing zone account), all active Regions | CDK bootstrap roles, asset bucket, ECR repository, and a daily asset cleaner for CDK deployments |
| ServiceQuotasStackSet | Development, Production, and Security OUs, all active Regions | Quota increase requests, Lambda concurrent executions (L-B99A9384) by default |
The management account and the FinOps account get their Resource Explorer indexes from ProvisionManagementStackSet and FinOpsStackSet, since service-managed StackSets do not deploy to the management account and the FinOps account runs its own organization view.
The organization output contract
LandingZoneOrganizationStack publishes every OU ID as a <Key>Id CloudFormation stack output (e.g. SecurityOUId), plus an account <Key>Id output for each account marked publishAccountIdOutput: true in the organization structure (e.g. SecurityAccountId, ObservabilityAccountId). The foundation package reads these back and exposes them to the landing-zone stacks as typed orgVars properties.
The landing-zone stacks read the organization outputs cross-account at deploy time. OU IDs are always available; an account ID is available only when its account opts in. The organization phase always deploys first.
Keep published organization identifiers within the CloudFormation per-stack output limit. Enable publishAccountIdOutput only for accounts that other stacks reference by ID.
Tags
The landing zone tags what it owns so you can find and protect it. The keys come from src/config/tags.ts:
| Tag key | What it marks |
|---|---|
cdk-landing-zone:managed | Every landing-zone stack, StackSet, and resource. Drift detection checks the stacks and StackSets that carry it, and protectTaggedCloudFormationStacksSCP protects them |
cdk-landing-zone:stack | The parent stack that owns a resource, including resources StackSets roll out to member accounts |
cdk-landing-zone:automation | The landing zone's own automation and the roles it runs as. lockdownSuspendedAccountsSCP exempts principals that carry it |
Enabling and disabling StackSets
For Security Hub CSPM, GuardDuty, Inspector, and Macie, keep OrganizationSecurityStackSet deployed and change enabled in security-services.ts. Workload quota requests are configured separately in service-quotas.ts.
Each StackSet is registered with a landingZone.createStackSet(...) call in its deployment stack. To disable a StackSet, remove (or comment out) its createStackSet block and redeploy. CloudFormation deletes the StackSet and its stack instances. To re-enable it, add the block back. See Customize StackSets for the full workflow.
Key dependencies to respect:
FinOpsStackSetrelies on the organization phase having registered the FinOps account as the delegated administrator for Compute Optimizer, Cost Optimization Hub, and Resource Explorer, and onProvisionManagementStackSethaving enrolled the organizationOrganizationSecurityStackSetrelies on the organization phase having registered the security account as the delegated administrator for IAM, IAM Access Analyzer, GuardDuty, Security Hub, Inspector, and MacieObservabilityStackSetrelies on the organization phase having registered the observability account as the CloudTrail delegated administratorResourceExplorerStackSetskips the management account and the FinOps account. KeepProvisionManagementStackSetandFinOpsStackSetdeployed so every account has an index- The management account is excluded from service-managed StackSets and receives its secure-defaults baseline, Resource Explorer indexes, optional account-quota request, and Compute Optimizer and Cost Optimization Hub enrollment through
ProvisionManagementStackSet; its CloudTrail coverage comes from the organization trail, and its IAM centralized root access fromOrganizationSecurityStackSet