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.
What this is. One readiness gate for an Authorization to Operate. It checks every prerequisite an ATO package depends on — against your live account — and tells you exactly what's ready and what isn't. Why it matters. When nothing is failing it produces the full document set in one step. When something's missing it lists it, tells you how to close it, and lets you verify each item the moment you finish — so you always know precisely how far you are from an ATO.
What this is. The applications running across your organization and which accounts each one lives in — the authorization boundary and system component inventory (NIST CM-8) every SSP and ATO package starts from. Why it matters. Discover scans AWS Config (the organization aggregator when a landing zone is present, else the account TowerControls runs in) and groups resources into candidate applications by their Application tag or name prefix, with the accounts and sample resources behind each. Register the systems in scope; the inventory below then reads back per account, and the ATO Now “System boundary” gate turns green.
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, container images and Lambda) and IAM Access Analyzer external access (anything reachable publicly or cross-account).
What it does. Answers the two questions a disaster asks first: what fraction of your backupable fleet is actually protected (coverage, per resource type), and is the restore path exercised (restore-test age). Read live from AWS Backup — this is CP-9 (backup) and CP-10 (recovery) evidence.
How it works. Coverage is the real count of protected resources over the live inventory (EC2, EBS, RDS, DynamoDB, EFS), graded green ≥90% / amber ≥50% / red below. The unprotected list is exactly what has no recovery point. If AWS Backup isn't set up here, that's the finding — shown, not errored.
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.
What this is. The full NIST 800-53 Rev 5 catalog (1,000+ controls) with FedRAMP Low/Moderate/High baselines, plus derived frameworks — HIPAA, CMMC L2, SOC 2, ISO 27001 — each crosswalked to NIST so they inherit posture from your live Security Hub scorecard. Why it matters. One assessment, many authorizations: prove HIPAA or CMMC without re-scanning, and see exactly which baseline controls are covered vs. still need evidence in the coverage matrix.
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 deploys 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. Each OU is an expandable, health-graded row; open one to reveal the accounts, CT controls and guardrails it holds, with a colored rail flagging its posture at a glance. 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 deploys 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.
What this is. The cockpit for every landing-zone change. A change is one Proposal — a config edit on a branch — tracked from proposed through the policy gate to deployed. Why it matters. Nothing reaches your org without passing policy; here you see each change's gate verdict, approve or reject it (separation of duties + role gates enforced), and watch it land — the full audit trail is the record.
Downloadable documentation for TowerControls — the branded, screenshot-rich User Guide, Quick Start, Administrator and Deployment guides, generated on demand and kept current with the latest features (the DevSecOps software factory — Vend tenant, Wire tooling and Deploy platform — the AI assistant, roles & access, the live pipeline chip, the daily executive briefing, GUI settings). The product white paper is here too — what a signed image actually proves, why the receiving environment verifies it again before anything runs, and what has been demonstrated rather than described.
The Jira intake queue — tickets labeled 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 pipeline form (left). If you don't have a pipeline, use No pipeline? Create directly (the card lower down) to create straight through AWS Organizations.
Pipeline 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 pipeline path, which needs a pipeline to provision it.)
This screen only ever writes a pull request. Nothing is created here. The Landing Zone Accelerator creates and enrolls the accounts and deploys the tooling when the pull request merges, so a vend passes the same policy gate as every other landing-zone change. To read what a tenant has and what it is running, open Tenant; to score the five gates against a pipeline, open Image checks.
Vend a software factory. A tenant is one tooling account plus one account per environment you pick, each isolated in its own OU nested under the parent, all declared in a single gated pull request. Preflight is fail-closed and names the blocker — the parent OU, an account email already in use, a pipeline that hasn't settled — so you find out here rather than half way through a run.
Already have the accounts? Wire the tooling. Wire tooling adds the factory to a tenant whose accounts already exist. It creates no accounts, so it works even when the organization is at its account quota — and it is how a customer adopts a tenant they were already running. Re-wiring is safe and worth doing: it converges the tenant's configuration onto the current platform version instead of leaving it frozen at whatever was written the first time.
What gets deployed. A private image registry with immutable tags and continuous scanning, so a tag can never be repointed and a new vulnerability is found in an image already published. A signing key that never leaves the tenant's own account. A deploy role in each environment account that trusts only the tooling account — no static keys, no long-lived credential. Optionally a reference build, and optionally a small runtime service so a deploy can be proven end to end.
How an image earns its way to production. The build compiles the application, builds the image, and pushes it under a unique tag — immutable tags forbid reuse, so every build gets its own. It then produces an SBOM bound to the image digest, signs that digest, and verifies both the signature and the attestation before the build is allowed to succeed. A failure at that step fails the build, so an image that cannot be verified can never be promoted. Signing uses no public transparency log, which keeps the whole chain inside the boundary — it works air-gapped and in GovCloud.
The environment checks again, for itself. Everything above is our pipeline vouching for its own work. So before the workload exists, the receiving account finds the signature and the SBOM attached to the digest and verifies both against the tenant's key from inside its own account — using a grant that permits verification and never signing, so the account that checks a signature can never produce one. The service is declared to depend on that check, so a digest that fails, an attestation covering a different image, a missing SBOM or a scan result outside the policy stops the deployment instead of warning about it. The claim is not “the pipeline would not have promoted a bad image” but “this account refuses to run one”, and each verification is retained as a timestamped record — a gate answers whether an image is signed today, an authorization package has to answer whether it was signed the day it deployed.
The runtime has no way out, and still gets its image. No internet gateway, no address translation gateway, no public address, no default route — the registry, the image layers and the log stream all travel over private endpoints. Worth knowing because the failure is misleading: the path to the layers resolves to the storage service's own published address range rather than an address inside the private network, so a workload allowed to reach only its own network signs in to the registry successfully and then times out on every layer. It looks like a broken registry and is actually a closed door. The workload is given exactly two destinations — its own network, and that published range — and nothing is opened to the world.
Promotion is by digest, never by tag. A tag can be repointed, so a tag-pinned deployment cannot be verified by its content and the deploy gate refuses it outright; the digest is the only identity that compares across accounts. Give each environment its own image under What the tenant runs — that per-environment difference is what promotion is, and a set of environments that cannot lag one another cannot be promoted between. Versions are chosen against published end-of-life dates, currently Java 25 LTS, Ubuntu 24.04 and Spring Boot 4.1.0, so nothing arrives legacy or already sunsetting.
The task count and the scan policy are configuration, not console dials. Running tasks is a value in the tenant's configuration file: park an environment at 0 to have it defined but idle — which is also the safe way to stand one up before its image is known good — or run it at N, either way through a reviewed pull request. The deploy-time scan policy works the same way. It refuses any critical or high finding by default; accepting a number of them is a risk decision that gets written into the file and reviewed in the pull request, and that record is the acceptance.
Bring your own accounts. Under What the tenant runs you can point an environment at an account the organization already has instead of one we named. That is what makes this usable at the account quota, and for any customer whose accounts already exist.
We scaffold and govern; you own and run the pipeline. The reference build is off by default. Download starter pipeline gives you a working build-sign-promote pipeline to take, adapt and run in your own account, under your own role — nothing here ever invokes it. Assessment reads upward only: TowerControls reads a tenant's registry and running images through a read-only role, and no deployment ever opens a path back into a customer environment.
Run it in order. Fill the form, run read-only Preflight, Plan to see the exact accounts and the enrollment cost, then Open vend PR. The wizard's answers also open the tenant's authorization package — every field becomes a control assertion.
The tenant these two actions apply to. It follows whichever tenant you name below, and it stays in step with the Tenant and Image checks screens.
Add the private image registry, the signing key and the deploy role to a tenant whose accounts already exist. It creates no accounts, so it works when the organization is at its account quota — and it is how a customer adopts a tenant they were already running. Re-wiring is safe and worth doing: it converges the tenant onto the current platform version instead of leaving it frozen at whatever was written the first time.
Assessments, preflights and pull requests, most recent first, with what went wrong when something did.
One screen, three questions. What did we build, what is running in it right now, and is it compliant. Pick a tenant and everything below is read live from its own accounts — the accounts it declares, the container services running in each environment, the image each one is actually on, and the deploy-time verification record that environment wrote about it.
Nothing here changes anything. Every read is read-only and cross-account through the same access the posture screens use. An environment this app can't reach says so and the rest of the tenant still renders — one unreachable account never blanks the view.
Digests, not tags. A tag can be repointed after review, so an environment pinned to a tag can't be verified by its content. Digests are shown short; click one to copy the full value. The same digest running in two environments is the same artifact — that is what makes promotion provable.
Verified means verified at deploy time. Before an environment will run an image it checks the signature against the tenant's own key, checks the SBOM covers that exact digest, and checks the findings against the limits the deployment declared — then writes what it found into a store in its own account. That record is what an assessor is shown. Where no record exists yet, the view says so plainly rather than implying a pass.
Needs attention lists only what is worth acting on: an environment pinned to a tag, a digest running nowhere else, a digest with no verification record, findings outside the declared limits, a service below strength, or a runtime stack whose last deploy rolled back.
Generate diagram draws this tenant — its real account numbers, the registry and signing key in the tooling account, and for each environment the deploy role, the private network, the container service with the digest it is actually on, whether that digest verified in that account, and where the record is kept. It is drawn from the accounts, not from a picture we prepared, so it is a page you can hand to a reviewer instead of opening the AWS console with them. Only what this platform created is drawn: a customer's other networks and workloads are deliberately left out, because the question it answers is what the factory built and whether it is working. The button appears only once the tenant is deployed and working — accounts live, tasks running, and every running digest carrying a verification — since a diagram of a half-built tenant would show nothing, and one drawn over unverified images would assert something the accounts do not support.
Every account this tenant declares, the environment it carries, the live account it resolved to and the OU it sits in — read live, never cached.
Per environment: the image each container service is actually on, its task counts and health, the deploy-time verification record for that image, and its findings against the declared policy.
The five image checks, scored live against this tenant's tooling account and its environments, each mapped to the controls it evidences.
Only what is worth acting on. An empty list here is the good outcome.
Five gates, scored live. Registry hygiene, unresolved scan findings, image signing, SBOM coverage and promotion — read from the private image registry of a pipeline you already run, and mapped to the controls an assessor asks about.
It reads any account, not only a tenant. Point it at an account the organization already has and score the pipeline running there before you vend anything. Assess tenant in focus jumps straight to the tooling account of whichever tenant the other factory screens are on.
Reads only, and upward only. Scoring reads a registry and its images through a read-only role. Nothing here writes, and nothing it reads opens a path back into the account being assessed.
What a verdict means. Ready is evidence, Partial is evidence for some images and not others, and Gap is the absence of it. Each gate names what to do next, and where a value could not be read the gate says so rather than scoring it as a pass.
Score the container images of a pipeline you already run — read live from the registry, mapped to the controls an assessor asks about. Assess before you vend.
The day-2 half of the software factory. Where Vend tenant creates the governed accounts, Deploy platform fills one with a running, internal-facing platform. Pick an account you've already vended and stand up its environment through the same gated pull request — nothing is created here; the Landing Zone Accelerator deploys the stacks when the PR merges.
Built foundation-first, so each layer has what the next needs. Start with the network — a private, internet-isolated network with the endpoints a cluster needs to pull images and reach AWS with no internet gateway. The cluster lands on that network next, then the delivery controller comes up as the one bootstrapped component and syncs your apps from your repo. Infrastructure stays declarative; the apps stay in your repo, which you own.
Run it in order. Fill the form, run read-only Preflight (it names the specific blocker if anything's off), Plan to see the exact resources, then Open deploy PR. Everything is internal-facing by construction: no internet gateway, private API endpoint, internal load balancers only.
Foundation-first — each layer exports what the next imports. The network layer is live; the cluster and apps land on top of it.
Private network, 3 private subnets, private service endpoints, private DNS. No IGW/NAT.
Private-endpoint cluster on this network, managed nodes, core add-ons, workload identity. No public API.
Air-gapped delivery: the controller is mirrored into your private registry and bootstrapped from it, then syncs your repo (ingress controller, your apps).
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. Watches the AWS service limits that actually gate org operations — the account ceiling, VPCs and Elastic IPs per Region, IAM roles and users — and warns before you hit a wall, not when a create fails.
How it works. Each limit is read live: the adjustable value from Service Quotas (or the AWS default when it was never changed) against the real current usage, graded amber at 70% and red at 90%. The AWS Organizations account limit isn't published through Service Quotas — record it in Settings and the sentinel grades your live account count against it. Reads the account TowerControls runs in.
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. Everything about who can access what across the org. At the top, Console Access vends a just-in-time, time-boxed, fully-audited AWS console session for a member account — so when someone genuinely needs the console, TowerControls is the front door instead of ungoverned out-of-band federation. Below it, 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. Console Access is Admin-only and reason-required; each session is tagged so CloudTrail shows exactly what was done with it (AC-2 / AC-6 / AU-2 evidence), and ending it captures that recap. The Identity Center inventory below is read live — nothing is created or changed; to grant standing 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.
iam-config.yaml — break-glass, service and automation identities, separate from Identity Center (day-to-day SSO). Why it matters. These are standing credentials that live inside your accounts, so anything high-privilege here is real attack surface to own and watch.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, resource counts, 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, resource counts, 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. Shows, per account, which AWS Security Hub security standards are switched on — and specifically whether NIST 800-53 is enabled, because that's the standard TowerControls grades your posture against.
How it works. The baseline is NIST 800-53 plus the AWS Foundational Security Best Practices (FSBP). An account missing NIST won't be graded until it's turned on; the Landing Zone Accelerator pipeline enables the standards org-wide. Hit Refresh after a pipeline run to re-check.
| Account | Role | Standards enabled | NIST 800-53 | Baseline |
|---|---|---|---|---|
| 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.
What it does. Admin-only controls for who can use TowerControls and how it's configured. Users manages people and their role; Settings configures the whole app from the GUI.
Roles. Every user has one of four roles, enforced on the server: Admin (everything, incl. this panel), PowerUser (run all of Operate, read Security & Reports), User (view-only, scoped to one area), and Audit (the audit trail only). Add a user, set their role and area, disable or reset them here.
Settings. Change organization details, the sign-in method (Cognito username/password, or federate your own identity provider over SAML — Okta, Entra ID, Google Workspace, Active Directory, or PIV / smart-card), notification & daily-briefing recipients, account-creation caps, integrations, and the AI model — all at runtime, no redeploy. Secrets route to Secrets Manager and are never shown.
What it does. Your AI helper for this app and this AWS org. Ask how a screen works, how to do a task, what a grade or finding means, or how to make your org more secure — grounded in your live posture.
How it works. Read-only and inform-only: it explains and points you to the screen, but never changes anything or writes code, and it stays on topic. Scoped to this account only.