AWS landing zone services built on Control Tower

An AWS landing zone is a pre-configured, multi-account AWS environment that every workload you deploy afterwards inherits. It sets the organizational unit structure, the account baselines, identity and access, network topology, centralized logging, and the guardrails that decide what teams can and cannot do. The point is to make security and governance a property of the environment rather than something each team re-implements per account.

A landing zone is the architecture pattern; AWS Control Tower is the AWS service that builds and governs one for you. The original AWS Landing Zone solution was a CloudFormation-based deployment that customers maintained themselves. Control Tower replaced it with a managed service that orchestrates AWS Organizations, IAM Identity Center, AWS Config, and CloudTrail, and keeps the controls applied as you add accounts. If you still run the legacy AWS Landing Zone solution, migrating to Control Tower is a supported path and one we run regularly.

There is no additional charge for AWS Control Tower itself. You pay for the AWS services it turns on in your landing zone — AWS Config recording and rule evaluations, CloudTrail events beyond the free tier, S3 storage in the Log Archive account, Service Catalog for Account Factory, and any Security Hub or GuardDuty coverage you enable. Config is usually the largest line item, and it scales with the number of accounts and resources under governance, so we size it during design rather than after the first bill.

Control Tower deploys the landing zone itself in roughly 30 to 60 minutes. The engagement around it takes longer, because the decisions are the hard part: OU structure, account boundaries, network topology, permission sets, and which guardrails you can enforce without blocking delivery. A typical greenfield engagement runs three to six weeks. Enrolling an existing estate takes longer, since accounts have to be assessed and moved into OUs without breaking running workloads.

Enough that a blast radius, a bill, and a permission boundary line up. The AWS baseline is a management account that runs nothing, plus dedicated Log Archive and Audit accounts, then separate accounts per environment for each workload — production, staging, and development at minimum. Shared services such as networking, CI/CD, and security tooling usually get their own accounts. Most teams end up with more accounts than they expected and fewer IAM exceptions than they had before.

Yes. Account Factory for Terraform (AFT) is the AWS-supported open-source pipeline that provisions and customizes Control Tower accounts from Terraform, so new accounts arrive with VPCs, IAM roles, tags, and baselines already applied. We use AFT where the team already runs Terraform, and keep the OU structure and controls in Control Tower where they belong. Control Tower governs; Terraform builds what sits inside each account.

Yes, and you do not have to rebuild them. Existing accounts are enrolled into a governed OU, which applies the Control Tower baseline — CloudTrail, Config, and the OU's guardrails. The work before enrollment is the part that matters: checking for conflicting Config recorders, CloudTrail trails, stack sets, and IAM roles that will collide with the baseline. We run that check per account and remediate first, then enroll in waves rather than all at once.

Guardrails, now called controls, are governance rules applied to a whole organizational unit rather than account by account. Preventive controls are Service Control Policies that deny an action outright — for example blocking changes to internet gateways or deleting CloudTrail. Detective controls are AWS Config rules that flag drift, such as an unencrypted EBS volume. Proactive controls check CloudFormation resources before they deploy. Control Tower ships mandatory controls plus a library of optional ones, and we add custom SCPs on top.

Control Tower is enough for most commercial estates. Landing Zone Accelerator on AWS (LZA) is worth adding when you need heavy network and security orchestration out of the box, or when you have to satisfy a specific compliance framework such as US federal, CCCS, or healthcare baselines. LZA also works in regions where Control Tower is unavailable. AWS recommends deploying Control Tower as the foundation and layering LZA on top, which is how we scope it — we do not add LZA unless the requirement is real, because it is a lot of machinery to own.

It removes a large amount of the evidence-gathering work. Auditors ask who can do what, whether logs are tamper-resistant, and how separation of duties is enforced. A Control Tower landing zone answers those with an org-level CloudTrail landing in a dedicated Log Archive account, Config rules evaluating continuously, and SCPs that make the non-compliant action impossible rather than discouraged. It is not a certification on its own — you still need policies, processes, and testing — but the technical controls stop being screenshots.

Engagements are scoped as a fixed-price project rather than an hourly rate. A greenfield landing zone with a standard OU structure, account vending, and a security baseline is a three-to-six-week project. Enrolling an existing multi-account estate, migrating off the legacy AWS Landing Zone solution, or adding LZA extends that. On the AWS side, budget for AWS Config as the main new running cost. We give a fixed scope and price after the assessment, not before it.

Yes. Accounts can be unenrolled from Control Tower and the landing zone deleted, and the accounts themselves survive — they stay in AWS Organizations with their resources intact. What you lose is the governed baseline: the OU controls stop applying and the centralized logging configuration has to be replaced. It is a real exit path rather than a one-way door, which matters when a board asks about lock-in before approving the design.