How We Reviewed and Restructured Our AWS Security Governance

This article is the entry for Day 6 in the KINTO Technologies Advent Calendar 2025.

Introduction

Hello. I'm Watanabe from the Cloud Security Group, Security and Privacy Division at KINTO Technologies.

Our company has been operating a multi-account environment using AWS Organizations and Control Tower. However, after years of changes, we found it necessary to revisit some of our design decisions. We therefore decided to reorganize our security governance design based on the existing environment.

In this project, rather than rebuilding everything from scratch, we adopted an approach of prioritizing the affected areas due to the rebuild and addressing them gradually. While prioritizing safety, we also incorporated some changes that will lead to future operational improvements, such as creating new OUs and leveraging AWS managed features.

The project is still in the design phase, and the final outcomes are yet to come. In this article, I'll share the decision-making process and background up to this point.

Note: This article is intended for readers with a certain level of understanding of AWS Organizations, AWS Control Tower, Security Hub CSPM, SCP, and OU design.
Note: The content is based on the design phase, which is the first half of the project and may change during the implementation phase.

---

Design Element Review and Analysis

First, we organized the security governance elements of our existing environment and prioritized the following five areas for review and analysis based on their impact and improvement potential.

The first three areas have a broad scope of impact and involve other areas that affect teams beyond cloud security. The latter two areas require consideration in conjunction with the former ones.

1. OU design
   -> OU structure directly affects guardrail design
2. Preventive guardrails
   -> This is a mechanism to proactively block undesirable operations and affects existing accounts
3. Detective guardrails
   -> This is a mechanism to detect undesirable configurations early and complements preventive guardrails
4. Configuration automation tool
   -> An internal tool that automates initial setup for new accounts
5. Account issuance Flow
   -> The process for provisioning new accounts

In this article, I'll introduce the issues and background of decision-making processes that emerged in reviewing and analyzing each of these areas.

---

Organizing the AWS Security Governance Structure

In this chapter, I'll organize how our company's AWS security governance is structured across different layers.

The following diagram shows:

• Settings applied in the management account (AWS Organizations / AWS Control Tower / AWS CloudFormation)
• Settings additionally applied to the management account and user accounts by the configuration automation tool

And how these settings work for the user account side as:

• Three-tier preventive guardrails (Tier 1: Control Tower standard, Tier 2: additional guardrails, Tier 3: custom SCPs)
• Two detection methods (using Security Hub CSPM or Control Tower)
• Pre-optimization of monitored/protected resources (initial settings by the configuration automation tool)

As shown in the diagram, our environment consists of three tiers of preventive controls: Control Tower's standard guardrails, additional guardrails supplemented by the configuration automation tool, and custom SCPs.

Additionally, we have two detection layers using Security Hub CSPM and Control Tower as well as pre-optimization of resources by the configuration automation tool. The combination of these tools establishes our overall governance structure.

Since they were introduced at different times and for different purposes, there are some variations in settings between OUs and accounts.

The main roles in this diagram can be organized into the following five categories:

• Control Tower standard guardrails
  -> Baseline for preventive and detective controls provided by AWS
• Additional guardrails (enabled by the configuration automation tool)
  -> Preventive and detective guardrails to supplement constraints not covered by the standard
• Custom SCPs (configured via the configuration automation tool)
  -> Company-specific restrictions for exceptional requirements
• Security Hub CSPM Stream (detection layer on the CSPM side)
  -> A service that integrates with AWS Config to continuously detect misconfigurations and best practice violations
• Detection using Control Tower (detection layer on the Control Tower side)
  -> Implements detective controls linked to Control Tower guardrails in coordination with AWS Config

While this multi-layer structure is not uncommon in AWS governance, the review and analysis process required clearly organizing which layer provides which controls and whether each setting belongs to Control Tower, Security Hub CSPM, or the configuration automation tool. This involved a certain level of complexity.

For this effort, we focused on bringing Control Tower's additional guardrails—especially the high-impact preventive controls—up to date. We plant to optimize overlaps and role allocation between layers as an improvement topic into the future to be addressed gradually.

---

Review and Analysis of OU Design

OU design is closely related to Control Tower's behavior, making it particularly difficult to assess the scope of impact in changing designs.

The following three points have specifically large impacts and made the assessment difficult:

1. Some operations are not documented, making us hard to fully predict behavior in advance
   -> For example, detailed specifications about what happens to a landing zone are not shared at the timing of the zone reset required after the change in an OU name
2. In addition to differences between OUs, past implementations and iterated operations have a large impact, requiring individual verification of which settings are reapplied and how the reapplication is performed when moving accounts within an OU to a different OU
3. Since accounts in our production environment and Control Tower record cannot be accurately reproduced in a testing environment, safety cannot be fully ensured through testing alone
   -> For example, in terms of accounts in the production environment, there are cases where resources necessary for Control Tower operations have been modified or deleted for some reason during past operations

Based on the above, we compared the following three patterns for where to place newly created accounts.

The three patterns are as follows:

• Existing OU (with its current state maintained): Continue placing new accounts in the current OU structure and guardrails without changes.
• Existing OU (applied to new guardrails): Apply new guardrails to the existing OU group and place new accounts there, aligning the state of the accounts with that of the existing ones all at once.
• New OU group: Maintain the existing OU group as it is while creating a new OU group with new guardrails applied, and place new accounts in that OU.

No	Placement	Impact of Change	Long-term soundness	Ease of Introduction	Comment
1	Existing OU (with its current state maintained)	Excellent: No impact on existing environment	Poor: Technical debt remains	Excellent: Easy to implement with the current state maintained	Temporarily safe but increases long-term debt
2	Existing OU (applied to new guardrails)	Poor: Major impact on all existing environment	Excellent: High soundness	Poor: High verification burden	Ideal but heavy impact, which requires gradual migration
3	New OU group	Excellent: No impact on existing environment	Fair: Risk of OU separation	Excellent: Easy to implement and verify	Need to resolve OU separation in subsequent phases

This time, we adopted Option 3, which avoids impact on the existing environment while making it easy to introduce new frameworks.

That said, this is not a permanent solution but the first step to verify new guardrail configurations and operational models without immediately reorganizing existing Ous all at once.

After gaining operational experiences and verification results with the new OU group, we plan to gradually migrate existing accounts with smaller impact, such as Sandbox OUs, and ultimately unify the OU structure and guardrails as much as possible as our medium- to long-term policy.

---

Review and Analysis of Preventive Guardrails

Preventive guardrails are frameworks to proactively prevent undesirable operations and configurations. In our environment, along with AWS Control Tower's standard guardrails, we enable additional guardrail and use custom SCPs through the configuration automation tool to supplement any gaps.

Tier	Name	Major tool	Role
Tier 1	Standard guardrails	AWS Control Tower	AWS standard preventive controls
Tier 2	Additional guardrails	Configuration automation tool (CDK)	Supplements gaps not covered by standard guardrails
Tier 3	Custom guardrails	Configuration automation tool (CDK)	SCPs tailored to our company’s specific requirements

Since we are going to place new accounts in newly created OUs, adding guardrails to new OUs does not affect the existing environment. Therefore, we examined if we should enable new preventive controls added to Control Tower after initial deployment.

However, only in terms of the severity level provided by AWS, we could not find why a particular evaluation was given or what operational impact might occur, as illustrated by the following three examples.

Examples of where severity is high with the adoption undetermined:

• (1) [CT.EC2.PV.4] Require that Amazon EBS direct APIs are not called
• (2) [CT.S3.PV.2] Require all requests to Amazon S3 resources use authentication based on an Authorization header

Examples where severity is medium but seemingly worth adopting:

• (3) [CT.EC2.PV.11] Disallow public sharing of Amazon Machine Images (AMIs)

Therefore, we used Amazon Q Developer Pro* for evaluating each control's SCP from the perspectives of operational impact, recommendation level, and adoption process. For the above items from (1) to (3), we gained the following insights:

1. Caution is needed due to potential impacts on backups using AWS Backup partner products that are applied to EBS direct APIs(CT.EC2.PV.4)
2. Presigned URLs will no longer work (CT.S3.PV.2)
3. Adoption is appropriate, but the behavior of a DECLARATIVE_POLICY differs from that of an SCP (CT.EC2.PV.11)

Through this organizing process, we decided to actively enable controls in new OUs whose activation are recommended with its lower impacts.

*We adopted Amazon Q Developer Pro because it appears to reference official AWS documentation for each response. This gives us a sense of security at a certain level even in areas with frequent specification changes, while the service response speed is slower compared to other AI tools.

---

Review and Analysis of Detective Guardrails

In our environment, we use Security Hub CSPM as the main pillar of security auditing from the perspectives of centralized management of security standards and automatic updates.

Control Tower's detective controls are a set of checks that include perspectives on guardrails and common infrastructure configurations provided by Control Tower. We set this as a framework that complements Security Hub CSPM.

In this review process, we examined Control Tower's detective controls added after operations began to determine whether we should enable the controls by targeting those with its severity critical or its guidance strongly recommended.

As a result, we confirmed that controls, such as the ones listed below, can be audited under Security Hub CSPM standards, deciding not to enable them redundantly on the Control Tower side:

• [CONFIG.KMS.DT.1] Checks if AWS Key Management Service (AWS KMS) keys are not scheduled for deletion in AWS KMS
• [CONFIG.KMS.DT.2] Checks if the AWS KMS key policy allows public access

On the other hand, for some controls that handle service-specific settings like the following, we decided to individually examine their necessity based on our actual usage and future plans:

• [CONFIG.EMR.DT.1] Checks if an account with Amazon EMR has block public access settings enabled

---

Review and Analysis of the Configuration Automation Tool

Our company has developed and operates a configuration automation tool (based on CDK) to automate initial setup for new accounts. For many years, this tool has greatly contributed to standardizing new accounts and preventing omissions in initial settings.

In this review and analysis, we assessed how much we can simplify this framework, considering the current account scale, team structure, and the expansion of AWS managed features.

In general, many cases expand the scope of automation, but we focused on maintainability to decide to narrow the scope down to necessary parts.

The configuration automation tool currently handles the following:

1. Applying additional preventive guardrails
2. Adding custom SCPs
3. Suppressing duplicate/unnecessary Security Hub CSPM alarms
4. Setting services focused on Security Hub CSPM compliance (e.g., default encryption and activation of public access blocks)
5. Automatically applying other security settings

Currently, we are going to proceed with a three-tier approach:

• Shift to the automation of as many processes that can be handled by AWS managed features as possible
• For parts irreplaceable by managed features, prioritize management with declarative IaC (CloudFormation, CloudFormation StackSets, Terraform, etc.)
• Leave exceptional processing that cannot be shifted to IaC as minimal code, with specific implementation methods to be determined in subsequent phases

This doesn’t simply aim to reduce code but to record limited responsibilities that the organization should maintain long-term in code.

For the above item 4 in particular, through a migration to Security Hub CSPM central configuration, some settings may be able to leverage AWS managed features. In terms of existing OUs, individual differences in control states remain, so the review and analysis process is required for their application, but we plan to gradually utilize OUs from new ones.

Additionally, for the S3 Block Public Access settings currently implemented as part of item 5, migration to the recently released S3 policies may similarly allow us to leverage AWS managed features. We plan to examine if we can adopt it, going forward.

Note that the configuration automation tool has unique strengths, such as CDK-based conditional branching, which may become decision-making points in this review. We plan to continue carefully verifying whether the above policy is appropriate.

---

Review and Analysis of the Account Provisioning Flow

Our company has previously operated with MFA enabled for root users when issuing new accounts. However, this involves physical work, requiring a certain amount of effort each time an account was issued.

With centralized root access management for member accounts released at the end of 2024, there is potential to update this operation itself.

In conjunction with the current redesign, we are considering organizing the account issuance flow into a form that is as simple and secure as possible.

---

Conclusion

In this review and analysis process, we organized what to change and what to maintain from both extensibility and maintainability perspectives, based on settings and frameworks repeatedly updated over years of operation.

It is not easy to rebuild our existing Organizations environment into an ideal configuration while maintaining it. This is because multiple layers—OU design, guardrails, and initial setup automation tools—are interdependent, and updating any one of them can affect other layers.

Therefore, rather than completely overhauling everything, we proceeded with this organization under the policy of gradually reducing technical debt while continuing improvements without stopping production. In particular, since we were not able to fully understand Control Tower's behavior and the scope of impact of some guardrails, according to public information alone, I feel that it is essential to take a step-by-step verification approach diversifying risks.

Going forward, we plan to actively leverage AWS managed features while focusing on areas to update in line with the existing environment and continuing gradual improvements.

For those redesigning governance based on existing environments, I hope this article provides some materials helping their decision-making processes and perspectives.