AWS Control Tower: What It Governs, What It Costs, and When It Is Enough

Lukas Pour
|
Cloud computing
AWS Control Tower multi-account governance illustration

Most teams discover weaknesses in their AWS governance during an audit. Control Tower can address many of them in about 30 minutes, but only if you understand what it manages and what it leaves to you.

The problem is not the cloud, it is the chaos

Once you are running fifteen AWS accounts, simple questions become harder to answer. Which accounts send their logs to a central location? Who can launch resources in a Region you have not approved? Are there public S3 buckets, and where? Each account may have been created for a good reason, but together they can create a governance gap that surfaces at the worst possible moment: during an audit, a security review, or when you receive a bill nobody can explain.

AWS Control Tower exists to help close that gap. It is worth understanding how it works, because what Control Tower manages automatically and what it leaves to you are two different things.

What Control Tower actually sets up

Control Tower does not replace the underlying AWS services. It brings them together and manages how they are used. AWS Organizations provides the account hierarchy, IAM Identity Center handles access, and CloudTrail and AWS Config provide logging and configuration history.

Setup takes about 30 minutes and creates three shared accounts: a management account, a log archive account that centralizes logs from governed accounts, and an audit account for security tooling. Account Factory then provisions new accounts using the same baseline, so account forty can follow the same standards as account four. You can also automatically enroll existing accounts by moving them into a governed organizational unit.

One decision is permanent: your home Region. Choose it before you start, because you cannot change it later.

Controls: preventive, detective, proactive

AWS replaced the term "guardrail" with "control", but the three types work in very different ways.

  • Preventive controls stop an action before it happens, using service control policies in AWS Organizations. A preventive control is either enabled and enforced or not enabled.
  • Detective controls identify issues after they occur, using AWS Config rules. They show whether a resource is compliant, in violation, or not being monitored.
  • Proactive controls check resources before CloudFormation creates them, using CloudFormation hooks. Non-compliant resources can be blocked before they are created.

Each control also has a guidance level: mandatory, strongly recommended, or elective. The Control Catalog now contains more than 750 managed controls, including Security Hub controls and hundreds of Config rules mapped to frameworks such as CIS. For many common requirements, you no longer need to build your own detection logic.

What it costs, and where the expenses hide

Control Tower itself has no additional charge. You pay for the AWS services it uses, including AWS Config, CloudTrail, S3, CloudWatch, SNS, Service Catalog and VPC.

AWS Config is where costs can easily grow. It charges per configuration item, and short-lived workloads can create many of them. Spot Instances, EMR jobs and Auto Scaling groups can constantly create and remove resources, with each change generating configuration data. Landing zone version 3 records global resources only in your home Region, which makes keeping the landing zone current more important than many teams realize.

CloudTrail can also create unnecessary costs if you are not careful. If you keep your own trails alongside the Control Tower organization trail, you may end up paying for duplicate logging.

When Control Tower is enough, and when it is not

For most organizations running standard workloads, Control Tower with a carefully chosen set of elective controls is enough. Building something fully bespoke should be a decision you can justify.

Control Tower may not be enough when you need a prescriptive network architecture, deeper compliance requirements, or extensive per-account customization. Three AWS options can extend it rather than replace it: Customizations for AWS Control Tower, Account Factory for Terraform, and Landing Zone Accelerator for regulated workloads.

The usual approach is simple: deploy Control Tower as the foundation, then extend it where your requirements demand more.

If you still run the older AWS Landing Zone solution, it is now in long-term support and receives no new features. AWS recommends moving to Control Tower. Our guide to building an AWS landing zone that lasts covers what that foundation should look like.

Get the structure right before the tooling

Control Tower will enforce a bad account structure just as effectively as a good one. Design your organizational units around functions and shared controls rather than your org chart. Start with foundational OUs for security and infrastructure instead of trying to map the entire company on day one.

Get that structure wrong, and you may spend years moving accounts between OUs and untangling permissions along the way.

Trustsoft designs and operates AWS landing zones for enterprises across Europe as an AWS Premier Tier Services Partner. If you are setting one up or have inherited one that has drifted, see our Managed Landing Zone service or talk to our team.

Lukas Pour
CTO at Trustsoft
LinkedIn