Introduction

Hello everyone, this is Akaike.
This is sudden, but don't you think Control Tower has too many controls...?

Looking at the control catalog as of October 30, 2026, there are a total of 1,613 controls, as follows.

• Preventive controls: 69
• Detective controls: 1,309
• Proactive controls: 235

If you're seeing this for the first time, you wouldn't know where to start and would be left lost, right...???

So in this post, I'll organize how to think about which Control Tower controls to set up first, along with their priorities.

Prerequisites

This blog assumes the following.

• The Control Tower landing zone is already enabled
• The landing zone version is 4.0

https://docs.aws.amazon.com/controltower/latest/userguide/key-changes-lz-v4.html

Overview of Controls

Controls in Control Tower are a mechanism that provides governance rules for your AWS environment, managed by AWS.

For example, rules like the following are prepared in advance.

• Prohibit operations by the root user (SCP)
• Detect public read access to S3 buckets (AWS Config rule)

Many of these controls are based on AWS best practices, and mappings to compliance frameworks such as CIS and NIST are also provided.
This means that without designing governance rules from scratch, you can simply select and enable the controls you need to build an environment that follows best practices to a certain degree.

https://docs.aws.amazon.com/controltower/latest/controlreference/controls.html

When you enable a control, resources are created in the following places depending on its behavior.

• Preventive controls: Attached to OUs as AWS Organizations policies
• Detective controls / Proactive controls: Deployed to the registered accounts under the OU

Classification of Controls

Controls can be broadly classified along the following three axes.
By understanding these axes, you'll be able to tell what the large number of controls listed on the console's list screen actually do.

Classification by Behavior

The first axis is Behavior, which indicates what the control does.

https://docs.aws.amazon.com/controltower/latest/controlreference/control-behavior.html

Arranging the timing at which each behavior's controls perform evaluation along the flow until a resource is created gives the following.

Note that because proactive controls run on CloudFormation Hooks, operations that don't go through CloudFormation are basically not evaluated. Therefore, as shown in the diagram above, operations from the Management Console or Terraform do not pass through Hooks.

Classification by Guidance

The second axis is Guidance, which indicates the level of recommendation by AWS.
It is a classification independent of behavior, so you get combinations such as "preventive and elective."

Mandatory controls were applied uniformly up to landing zone 3.3, but from 4.0 they are applied according to the features you have enabled.

• When you enable the AWS Config or CloudTrail service integration, the mandatory controls that protect those resources are applied
• When you register an OU (apply a baseline), the mandatory controls are applied to that OU

https://docs.aws.amazon.com/controltower/latest/controlreference/mandatory-controls.html

Classification by Owner

The third axis is Control owner, which indicates who manages the control.
Depending on the owner, the service that manages the actual deployed resources differs.

Of these, controls owned by Security Hub and AWS Config have the following characteristics.

• Controls owned by Security Hub (SH.)
  • When enabled from Control Tower, a standard called "Service-Managed Standard: AWS Control Tower" is created on the Security Hub side, and the controls are added to it
  • If you disable them directly from the Security Hub console, the Control Tower side goes into a drifted state, so enable and disable them from Control Tower
• Controls owned by AWS Config (CONFIG., consolidated Config controls)
  • You can search for Config managed rules in the control catalog and enable them
  • This is an option when you want to add checks not included in the Security Hub standards

https://docs.aws.amazon.com/controltower/latest/controlreference/security-hub-controls.html

https://docs.aws.amazon.com/controltower/latest/controlreference/config-controls.html

Relationship Between Controls and OUs

So far, we've organized the classification of the controls themselves.
Next, we'll organize how inheritance works and how to think about OU structure, regarding OUs, which are the unit to which controls are applied.

About the Unit of Control Application

As a premise, controls are enabled per OU.
When you attach SCPs or RCPs yourself, you can specify accounts directly, but controls cannot be enabled individually per account.

In other words, the OU structure becomes the unit of governance application as is.
Therefore, before considering controls, you first need to decide on the OU structure.

Regarding the OU structure itself, the best practices published by AWS are a useful reference.

https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_manage_ous_best_practices.html

Inheritance to Nested OUs

When thinking about OU structure, one thing you must know is that whether controls are inherited by nested OUs differs by control behavior.

https://docs.aws.amazon.com/controltower/latest/userguide/nested-ous.html

For example, if you enable preventive controls and detective controls on the Workloads OU, the application to the Prod OU beneath it looks like the following.
(If you don't know this difference, accidents happen such as enabling detective controls only on the Workloads OU and finding that they aren't applied to the Workloads/Prod OU beneath it...)

This inheritance can also be used as a measure against the SCP limit.
OUs under a Control Tower landing zone have an SCP limit of 10 per OU.
Rather than enabling preventive controls on each lower-level OU, enabling them together on a higher-level OU saves that much of the quota.

https://docs.aws.amazon.com/controltower/latest/userguide/limits.html

How to Think About OU Structure

Based on the above, the OU structure and how to apply controls can be organized as follows.

Real organizations probably have OUs other than these, but the way of applying controls is similar for every OU. Therefore, once the thinking for the following basic OUs is decided, the way to apply controls to the other OUs will naturally follow.

• Root
  • Enable controls you want to apply to the entire organization
• Workloads OU
  • Enable controls you want to apply commonly to all workloads. However, only preventive controls are inherited by the OUs beneath it, so enable detective controls and proactive controls individually on the child OUs as well
• Dev/Stg/Prod OUs (under Workloads)
  • Enable controls whose strength you want to vary by environment individually on each OU
• Sandbox OU
  • Since it is for experimentation, allow a high degree of freedom
• PolicyStaging OU
  • Used to try new controls before rolling them out to production, so it is normally not used

Priorities for Setting Up Controls

Now, as mentioned at the beginning, there are simply a lot of controls, so let's decide what to use starting from the highest priority.
Note that mandatory controls are enabled forcibly in the first place, so you can exclude them from consideration.

When you line them up like this, you'll find that the number of controls you actually need to choose yourself from the control list during initial setup is not that large.

1. Preventive Controls

Preventive controls are the strongest form of governance, as they can stop operations that lead to violations at the time of the API call.
However, for that reason they tend to affect a wider scope than expected, so you need to be careful about the following points.

• If APIs that are actually needed get denied, resource deployments and application execution will fail
• They consume the quota of 10 SCPs per OU

Therefore, unless there are operations you clearly want to prohibit or specific requirements, enable only the minimum necessary, such as region restrictions, during initial setup.
Consider the other "strongly recommended" and "elective" preventive controls individually after operations begin, and leave anything that is fine to be detected after resource creation to the detective controls described next.

The following are the main controls that can restrict regions.

Note that if you block a region you're already using, you will no longer be able to operate resources in that region, so check the regions in use before enabling it.

https://docs.aws.amazon.com/controltower/latest/controlreference/primary-region-deny-policy.html
https://docs.aws.amazon.com/controltower/latest/controlreference/ou-region-deny.html

2. Detective Controls

Control Tower's detective controls and Security Hub CSPM's FSBP both perform checks using Config rules.
Therefore, if you enable both without planning, the same checks are executed on both the Control Tower side and the Security Hub CSPM side, and you are charged twice: the Config rule evaluation fees on the Control Tower side and the check fees of Security Hub CSPM.

So, let's divide the roles as follows.

Basically, enable FSBP in all accounts with Security Hub CSPM and use it as the baseline.
Control Tower's detective controls are sufficient if added only when there are checks that FSBP lacks.

Also, when adding Control Tower detective controls, note that you cannot specify parameters.
Config rules that would normally have their conditions adjusted via parameters are also deployed without parameters, so the evaluation may be stricter than expected.

3. Proactive Controls

Proactive controls run on CloudFormation Hooks, so whether to use them depends on the deployment method.

However, even in environments that deploy only with CloudFormation or CDK, manual operations from the console can't be stopped, so in the end preventive controls are still needed.
Therefore the priority is lower, and I think it's enough to use them when needed, such as when you want to strictly check configurations before deployment.

https://docs.aws.amazon.com/controltower/latest/controlreference/proactive-controls.html

4. Areas Not Covered by Controls

For unique restrictions such as "our organization won't let people use this AWS service," there is mostly no control that fits exactly.

Therefore, those need to be implemented outside of controls using features such as the following.

Control Tower's controls are also, under the hood, features of individual services such as SCPs and Config rules.
The only difference is whether you use what Control Tower has wrapped as a control or use the original service's feature as is.

When using the original service's feature as is, it helps to keep the following two points in mind.

• For SCPs and RCPs, if you add Statements to a single policy rather than splitting them by requirement, you won't strain the attachment limit (10 for SCPs, 5 for RCPs including RCPFullAWSAccess). However, a single policy also has a size limit (10,240 characters for SCPs, 5,120 characters for RCPs), so be careful not to consolidate too much
• Declarative policies are a mechanism for enforcing the configuration of AWS services themselves. Settings that are hard to control with SCPs or RCPs, such as enforcing IMDSv2 and prohibiting public sharing of AMIs and EBS snapshots, should be controlled with declarative policies

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html

Conclusion

That's it for organizing which Control Tower controls to set up first and in what priority.

At first glance the number of controls is enormous, but if you keep in mind the classifications and priorities organized in this blog, selecting controls should become much easier.

Next time, I'd like to talk about some red-hot controls that I personally recommend setting up.

I hope this is helpful for those who are about to start working with Control Tower.