The control surface for AWS Landing Zone Accelerator. Sign in to manage your account fleet.
LZA + account migration · aws-accelerator-config @ …
Pre-flight and post checks are built into every create, migrate and close flow — and available on their own under Checks.
Click any stage for action details + CFN events.
What it does. Stands up a brand-new AWS Control Tower landing zone from scratch — the Day-0 substrate that LZA runs on — optionally with Bedrock drafting the design.
How it works. Describe your org (or fill the form), run read-only preflight checks, forecast the cost, and generate the CreateLandingZone manifest + CLI. Generate-and-guide by default; with writes on you can launch it directly behind a typed confirmation. Then generate a starter LZA config repo so you land in the day-2 flows.
Tell us about your org in plain English and let Bedrock draft the plan — or skip and fill it in below.
ct-intake tickets, preps each, and comments the plan back. Approve here, or add ct-approve on the ticket in Jira.
No work yet — click Sync from Jira.
Run safety checks before an action or verify the result after. These are the same checks built into the create, migrate and close flows — here you can run them on their own, against any account.
What it does. Propose a brand-new workload AWS account — and, optionally, deploy existing IAM roles and groups to it at the same time.
How it works. Fill the form and click Preview YAML to see the exact change to accounts-config.yaml (and iam-config.yaml if you pick assignments). Apply opens a feature-branch pull request in CodeCommit — you review and merge, then the AWS Accelerator-Pipeline creates the account (~25–40 min). The dashboard only assigns roles and groups that already exist, never creates them, and requires a justification (logged) with per-day and total account caps.
What it does. Change an account that already exists, two ways: unassign roles or groups currently deployed to it, or remove its workloadAccounts entry from the config.
How it works. Pick the account, tick what to unassign (or confirm the removal), Preview, then Apply to open a PR. Removal is refused if the AWS account already exists in Organizations — at that point use the Closure tab instead. Same dry-run and PR gate; the dashboard never merges.
What it does. A read-only view of the IAM roles and groups LZA provisions into accounts from iam-config.yaml.
How it works. Lists each role set and group set and where it is deployed. These are LZA-managed IAM — not AWS Identity Center (SCIM) groups. To map an Identity Center group to a permission set, use the Tenant Access tab.
These are the IAM roles and groups LZA provisions from iam-config.yaml (deployed into accounts). They are not AWS Identity Center groups — those come from your IdP via SCIM and live outside LZA. To map an Identity Center SCIM group to a permission set across accounts, use the Tenant Access tab.
| Role | Target | Assumed by | AWS managed | Customer managed | Inst. profile |
|---|
| Group | Target | AWS managed | Customer managed |
|---|
What it does. A read-only, filterable list of every account declared in accounts-config.yaml.
How it works. Filter by OU or Type, or search by name or email. Type reads infrastructure for the platform accounts and shows the account's Organizational Unit for workload accounts.
| Name | Type | GovCloud | Warm |
|---|
What it does. A read-only count of Service Control Policies attached per OU, against the AWS limit of 5 per OU.
How it works. Reads the declared SCPs and shows the slots used and what is attached per OU. The dashboard never modifies SCPs — the write path refuses any change to service-control-policies/.
Read-only. The dashboard never modifies SCPs in this account — the write path refuses any change to service-control-policies/ or serviceControlPolicies:.
| OU | SCPs (slots) | Attached | RCPs |
|---|
What it does. Compares what is declared in the config repo against what is live in AWS Organizations.
How it works. Click Recompute to flag two kinds of drift: missing_in_aws (declared but not provisioned, or a failed creation) and orphan_in_aws (exists in AWS with no YAML entry). Read-only.
aws-accelerator-config vs AWS Organizations)Two kinds of drift: missing_in_aws = declared but not provisioned (or creation failed), orphan_in_aws = exists in AWS but no YAML entry. Refresh to re-check.
| Kind | Name | Declared | Live AWS |
|---|---|---|---|
| no data yet | |||
What it does. Verifies an account is actually provisioned, correctly placed, governed by SCPs, and covered by the declared baseline — the assurance a green pipeline run does not give you.
How it works. Enter an account id or name and Run. It checks Organizations placement, attached SCPs, org CloudTrail, the security-config.yaml baseline, assignments and drift, and (if it can assume into the account) live in-account settings. It also flags accounts that exist in AWS but have no accounts-config.yaml entry. Nothing is changed; the verdict is recorded to the audit log.
Confirms an account is actually provisioned, correctly placed, governed by SCPs, and covered by the declared baseline — the assurance the pipeline's green light doesn't give you. Nothing is modified; every result is recorded to the audit log.
What it does. A guided checklist for closing an existing AWS account. Guidance only — the dashboard never runs closures.
How it works. Enter the account id and Dry-run all checks to run the automatable verifications (account age ≥ 7 days, OU placement, YAML state) without changing anything, then work through the manual-only steps yourself. The dashboard records that you ran each step.
For removing an existing AWS account. The Dry-run all checks button runs every automatable verification (account age, OU placement, YAML state) without changing anything — use it before you start. Each step is then yours to run manually; the dashboard records that you ran it.
What it does. Grant a tenant's Identity Center (SCIM) group a permission set across one or more accounts — e.g. give a customer's operators access to both their dev and prod in one step.
How it works. Pick the group, an LZA-managed permission set, and the accounts, then Preview and Apply. It adds an identityCenterAssignment to iam-config.yaml via a PR; merge it and the pipeline provisions the access. Access is only ever added here — permission sets are never edited. If the permission-set list is empty, the set has to be defined in LZA first.
Grant a tenant's SCIM group an Identity Center permission set across one or more accounts. Adds an identityCenterAssignment to iam-config.yaml via a feature branch and PR — merge it and the pipeline provisions the access. Permission sets are never edited here; access is only added.
What it does. Configure a two-org account migration: the source org the accounts leave, the destination (FISMA-High) org they join, member-account access, the accounts to move, the baseline toggles, and Control Tower enrollment.
How it works. Fill it in and Save — the config persists to .migration/migration-config.json and every other Migration tab reads from here. Live moves only run when LZA_ALLOW_WRITES=1.
What it does. Confirms every credential context in your migration config actually works, before you run a phase.
How it works. Calls sts:GetCallerIdentity against the source org, the destination org, and each member account. Read-only and safe to run any time — green when every context resolves, red lists the failures. Run it before any phase.
Calls sts:GetCallerIdentity on every credential context in the config — source org, dest org, and each member account. Read-only; safe to run any time. Run before any phase.
Read-only “will it break” report for one account before it leaves the org — SCPs, RAM shares, delegated-admin roles, Identity Center assignments and security-tooling membership that don't follow the move.
What it does. Phase 1. A read-only assessment of one account before you move it — org attachment, IAM surface, integrations, footprint, and SCP exposure.
How it works. Pick the account and Dry-run (Apply behaves the same; there are no destructive calls). It surfaces anything that could block the move and writes a report to .migration/reports/.
Read-only assessment of one account: org attachment, IAM surface, integrations, footprint, SCP exposure. Writes a report to .migration/reports/<account>.inventory.json. Safe to run anytime.
What it does. Phase 2 (destructive). Actually moves the account out of the source org and into the destination org's target OU.
How it works. Removes the account from the source org, waits for it to go standalone, invites it to the destination, accepts the handshake, and moves it into the OU. It is atomic but irreversible — you cannot put an account back. Always dry-run first; live runs require LZA_ALLOW_WRITES=1 and can poll for up to 5 minutes.
Removes the account from source org, waits for it to go standalone, invites it to dest org, accepts the handshake, moves it into the target OU. Atomic but irreversible — you can't "put back" an account that left an org. Live runs require LZA_ALLOW_WRITES=1.
What it does. Phase 3. Applies the FISMA-High control baseline to the account.
How it works. Sets up SCPs, AWS Config, Security Hub, GuardDuty, CloudTrail (verify), the IAM password policy, default EBS encryption, and the S3 public-access block — each control idempotent, with toggles set in Setup. Writes a baseline report. Live runs require LZA_ALLOW_WRITES=1.
Applies FISMA High controls to the account: SCPs, AWS Config, Security Hub, GuardDuty, CloudTrail (verify), IAM password policy, EBS default encryption, S3 public-access block. Live runs require LZA_ALLOW_WRITES=1.
What it does. Phase 4. Verifies the account is governed by Control Tower and that its networking and security actually took effect.
How it works. Confirms the account is in the Control Tower-registered OU, that a shared subnet is attached, and that Security Hub is on, then emails a summary of all the checks. Account Factory enrollment via Service Catalog stays operator-gated.
Verify the account lives in the Control Tower-registered OU, then confirm a shared subnet is attached (networking plumbed) and that Security Hub is turned on. If Account Factory mode is on, surfaces the launch parameters — actual enrollment via Service Catalog is operator-gated.
What it does. Finds accounts already in your AWS Organization that LZA does not manage (not declared in accounts-config), and generates the entry to adopt each one — bringing it under the baseline + guardrails. No account is created.
How it works. Reads organizations:ListAccounts and subtracts what's declared in the LZA config. Pick a destination OU and it generates the accounts-config.yaml entry — commit it and the pipeline enrolls the account.
What it does. The "after" bookend to the dependency scan — confirms an account landed under management post-move: active, in a managed OU + declared in the LZA config, has a Config recorder, SSO access and security-tooling membership. Then bundles a FISMA evidence pack.
How it works. Read-only reads across Organizations / Config / Identity Center / GuardDuty / Security Hub. The evidence pack combines the pre-move scan + this verification + who-approved/when into a downloadable audit artifact.
What it does. Orders a set of accounts into dependency-aware waves — infrastructure / shared first, then non-production, then production — with a gate between each, so a big migration moves safely in batches.
How it works. Classifies by a name heuristic and groups into ordered waves. Read-only — it produces the plan; each account still runs through the migration phases. Pull the unmanaged set or paste your own list.
What it does. A local log of every Apply (dry-run or live) the dashboard has performed, newest first.
How it works. Each row shows the action, the files touched, and the branch and commit. Revert restores the file(s) from the pre-change snapshot, through the same dry-run / PR gate as a forward change.
Every Apply (dry-run or live) appears here. Newest first. Revert restores the file(s) from the snapshot pre-image, through the same dry-run / live + PR gate as a forward change.
| Timestamp (UTC) | Action | Target file(s) | Branch | Commit | Revert |
|---|---|---|---|---|---|
| loading… | |||||
This will create a feature branch on and commit the YAML below. It will not merge to main. Pipeline will not run until you merge.