TowerControls for your AWS org — stand up landing zones, migrate accounts, and stay continuously compliant, all without the console.
…
Judging your environment…
Click any stage for action details + CFN events.
Start with the wizard. Answer a couple of questions — what you want to do (create, bring accounts in, manage, close) and, for an existing account, its id. The wizard picks the right ordered path and grounds the recommendation in a live dependency scan.
Then follow the steps. Click Open on a step and the wizard pre-fills that screen with the account you gave it. Steps marked gate are go/no-go: hit Run check and the next step only unlocks once the dependency scan, readiness, or verify passes. Prefer to drive yourself? Use the Or jump straight to a task tiles, or the left nav.
A vetted library of Service & Resource Control Policies and the Control Tower controls catalog, each mapped to NIST. Get an AI blast-radius read before you attach anything. Applying is generate-and-guide — the dashboard emits the exact command; it never silently attaches an org-wide deny.
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 AI 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 AI draft the plan — or skip and fill it in below.
Control Tower needs an all-features org, the two shared accounts (Log Archive + Audit), and no conflicting Config recorder in the governed regions. Check here, then fix each in place — fixes are gated on writes.
A snapshot of your NIST 800-53 / FedRAMP posture — the ATO readiness score, control coverage, and what needs your attention first.
High-risk security events detected across the org — root sign-ins, CloudTrail/Config/GuardDuty tampering, security groups opened to the world, KMS key deletions, public S3, new admin roles. Each is triaged by AI with the risk, blast radius and exact response.
The two attack-surface axes beyond config state: Amazon Inspector software vulnerabilities (CVEs on EC2 / ECR / Lambda) and IAM Access Analyzer external access (anything reachable publicly or cross-account).
FedRAMP 20x readiness — the new automation-first authorization model. Your live posture is mapped to the Key Security Indicators (KSIs); each KSI's readiness blends the pass rate of the NIST controls it covers with your supporting evidence. Generate the AO-ready PDF from Reports.
Every NIST 800-53 control with its live pass/fail from Security Hub. Filter by family or status, open the evidence, fix with AI, override a false positive, or raise a POA&M.
Third-party attestations (pen tests, SOC 2, DR/IR exercises, training, access reviews) plus the live AWS-native evidence behind your controls — each tracked for freshness.
AI-drafted NIST 800-53 policy documents you draft, review and approve on a review cycle. Set the AI customization once to fill in your organization’s names and position titles.
Give the AI your details and it fills them into every policy it drafts — organization name, position titles and the people who hold them (ISSO, ISSM, System Owner…), system name, and review cadence. Leave anything out and the AI keeps a bracketed placeholder for it. The AI is restricted to customizing these NIST policies only — it ignores anything here that isn’t a value to fill in.
Plan of Action & Milestones — track remediation of open findings to closure and sync them two-way with Jira.
A live map of every account in your AWS Organization, grouped by OU and graded for NIST posture. Click an account for its detail; the Audit account is where org-wide posture is read from.
What each governance boundary contains and enforces. Move accounts, target guardrails, and add (nested) OUs — every change ships as a config PR through the pipeline.
Organizational Units are the governance boundaries Control Tower and the Landing Zone Accelerator enforce against — baselines, SCPs and account membership all target an OU. Here you see each OU, what it contains, and what's enforced on it. Add a new (or nested) OU with the field below; move an account into an OU from Account Ops → Manage. Every change is written to organization-config.yaml and ships as a config PR through the pipeline, which creates and registers the OU with Control Tower — nothing is changed live by hand.
loading…
Audit-ready reports built from your live assessment — OSCAL SSP, SAR and POA&M, plus a posture summary. They pull in your controls, evidence artifacts and POA&M items. Download as a rich PDF, or JSON for the OSCAL models.
Downloadable documentation for TowerControls — a Quick Start for onboarding, the full User Manual, and an Administrator Guide, each branded and rich with screenshots and step-by-step directions, plus the product white paper under Documents.
The Jira intake queue — tickets labelled ct-intake are pulled in here so you can review the prepared plan and approve account actions before they run.
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 the safety checks built into the create / migrate / close flows on their own, against any account — pre-flight before an action or verify the result after.
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.
Reads AWS Security Hub's NIST 800-53 Rev 5 controls and reports a compliance score, the failing controls, a severity breakdown, and a breakdown by control family. The Migrate → Baseline phase turns this monitoring on; here you see what its ongoing scanning produces.
Two ways to create. If you run a Control Tower / LZA pipeline, use the GitOps form (left). If you don't have a pipeline, use No pipeline? Create directly (the card lower down) to create straight through AWS Organizations.
GitOps form. Fill it in 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 needs a justification (logged) with per-day and total account caps.
Direct create. Enter a name, a unique email, and a justification, then Create account. It calls organizations:CreateAccount and shows the new account id when it lands (about a minute) — gated on writes being enabled. The new account gets OrganizationAccountAccessRole and joins the org.
For an org without a Control Tower / LZA pipeline — create the account straight through AWS Organizations, gated. (The form above is the GitOps path, which needs a pipeline to provision it.)
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, filterable list of every live account in the AWS Organization — the same accounts the Org Map shows, with each account's NIST grade and whether it's declared in accounts-config.yaml.
How it works. Filter by OU or role, or search by name or account id. Declared = present in the LZA config; live only = exists in the org but not in the declared config.
| Name | Account ID | OU | Role | NIST | Declared |
|---|
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.
orphan_in_aws = a live account with no config entry — this is what halts the LZA pipeline. Quarantine parks it in the ignored holding OU so LZA leaves it alone; Close retires it. parked = already in the holding OU. missing_in_aws = declared but not provisioned yet.
| Kind | Account | Placement | Resolve |
|---|---|---|---|
| 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 pre-flight checklist for closing an existing AWS account, plus the real, gated close.
How to. Enter the account id and Dry-run all checks to run the automatable verifications (OU placement, YAML state, status) without changing anything. Then, in the Close this account card, click Pre-flight & close: it shows the guards (it refuses the management account and delegated administrators), and if they pass you type CLOSE <id> to confirm. The account is suspended immediately and AWS permanently deletes it after 90 days (reversible via AWS Support during that window). The 7-day minimum people remember is for removing an account from the org, not closing it.
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.
Runs the real organizations:CloseAccount on the id above — gated by a typed confirmation. It refuses the management account and delegated administrators. The account is suspended immediately and AWS permanently deletes it after 90 days (reversible via AWS Support during that window).
What it does. A read-only view of who can access what across the org. AWS IAM Identity Center (SSO) is the primary Control Tower access model — the permission sets (the roles users assume in an account), the groups, and the assignments that grant a group a permission set on specific accounts.
How it works. Everything here is read live from IAM Identity Center — nothing is created or changed. To grant access, make the assignment in Identity Center. The classic IAM roles & groups LZA provisions from iam-config.yaml (break-glass, service/automation) are shown at the bottom when present — most Control Tower orgs use Identity Center and leave those empty.
| Account | Group / user | Permission set (role) | Managed by |
|---|---|---|---|
| loading… | |||
iam-config.yaml — break-glass, service and automation roles. Separate from Identity Center. Read-only.| Role | Target | Assumed by | AWS managed | Customer managed | Inst. profile |
|---|
| Group | Target | AWS managed | Customer managed |
|---|
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.
| Account | Role | Standards enabled | NIST 800-53 | Baseline |
|---|---|---|---|---|
| loading… | ||||
| Time (UTC) | User | Result | Action | Detail |
|---|---|---|---|---|
| loading… | ||||
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) | User | 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.