I Summarized the Configuration of Security Services in an AWS Multi-Account Environment
This page has been translated by machine translation. View original
Hello! I'm Yoshida from the Cloud Business Division.
When trying to design security services in an AWS multi-account environment, it can be difficult to grasp the whole picture.
There are articles explaining the design of each security service in a multi-account environment, but I get the impression that there are few articles that put it all together.
So in this article, assuming a multi-account environment using AWS Control Tower, I have organized the configuration of each security service from the perspective of organization-wide deployment.
Prerequisites
Target Audience
This article is intended for readers who understand the basics of Control Tower, AWS Organizations, and each security service.
Control Tower
We assume the use of Control Tower.
We also assume the landing zone version is 4.0.
Target Security Services
The following seven security services are covered in this article.
- CloudTrail
- Config
- Security Hub
- GuardDuty
- IAM Access Analyzer
- Detective
- Inspector
This article focuses on organization-wide deployment of security services, so it does not touch on detailed customization settings for each service.
Overall Architecture
The basic policies for configuring security services in a multi-account environment are as follows.
- Deploy across the organization through Control Tower integration and Organizations integration
- CloudTrail and Config use Control Tower integration
- Other security services use Organizations integration
- After setting the Control Tower region deny control, enable security services only in the home region
- However, enable them in all regions for the management account
- Make the Audit account the delegated administrator account for the security services
- Aggregate findings into the Tokyo region using the Security Hub region aggregation feature
- Ultimately, the findings of all accounts are aggregated into the Tokyo region of the Audit account
![[For blog use] Overall architecture diagram of security services.png](https://devio2024-2-media.developers.io/upload/2EhpY8qd5hFTzovoQgiIJ9/2026-05-11/TJZWLtr6n6Ow.png)
Delegation to the Audit Account
For AWS services that support a delegated administrator, setting a delegated administrator account is a best practice.
Creating a new account as the delegated administrator for security services is also fine,
but when using Control Tower, it is standard to set the Audit account as the delegated administrator account.
About Region Deny
In Control Tower, you can set a "region deny control" that denies API actions outside the home regions.
There are two types of region deny controls.※1
| Type | Scope | Characteristics |
|---|---|---|
| Landing zone region deny control | Control Tower management account | Simple, but exceptions cannot be configured |
| OU region deny control | Per OU | Exempt APIs and exempt IAM principals can be configured |
As for which region deny control to adopt, we basically recommend using the OU region deny control.
For example, when using cross-region inference in Bedrock, requests may be routed to regions that are not normally used, which can conflict with the Control Tower region deny control.
(I plan to write about this later.)
To handle cases like this, we recommend using the OU region deny control, which lets you set exception conditions and denied regions per OU.
Differences Between the Management Account and Member Accounts
SCPs cannot be applied to the management account.※2
The Control Tower region deny setting is not reflected, and API actions can be executed even in denied regions.
Also, if the management account is integrated as a member on the delegated administrator account (Audit account), a problem occurs.
In the Security Hub cross-region aggregation settings, the denied regions of the management account cannot be linked, so the security status of the management account's denied regions cannot be monitored.
The following articles summarize this matter clearly.
You need to consider which regions to monitor for the management account (whether to include denied regions in the monitoring targets).
In this article, the management account is organized under the following policy.
- Do not integrate the management account as a member on the delegated administrator account (Audit account)
- Enable security services standalone in all regions
- IAM Access Analyzer and Detective are handled as exceptions
- For Inspector, enabling itself is optional
- Aggregate findings into the Tokyo region using the Security Hub CSPM region aggregation feature
- Forward the aggregated findings cross-account to EventBridge
From here, I will explain the settings for each service.
Settings for Each Service
CloudTrail
An organization trail is created through Control Tower integration.
Since the created trail is both an organization trail and a multi-region trail, it can cover the home regions of member accounts and all regions of the management account.
Unlike other security services, no separate configuration is required in the management account.
Config
The settings differ between member accounts and the management account.
| Item | Member accounts | Management account |
|---|---|---|
| Enabled regions | Home regions only | All regions |
| Automatic creation by Control Tower | Yes | No |
| Changing settings | Not allowed | Allowed |
In member accounts, Config recorders are created only in the home regions through Control Tower integration.
Since they are Control Tower-managed resources, the recorded resources and recording frequency basically cannot be changed.
In the management account, no Control Tower-managed Config recorder is created. Therefore, you need to create a recorder separately.
The following article clearly summarizes which Config settings Control Tower handles and which it does not.
It also introduces how to create recorders in all regions on the management account, so please be sure to read it.
A service-linked Config aggregator is automatically created in the Audit account by Control Tower and aggregates the Config recorders of all accounts in the organization (including the management account).
Security Hub
Security Hub has two capabilities: CSPM and Advanced.
If you use both, separate configuration is required.
Security Hub CSPM is a capability split off as independent from the CSPM functionality of the conventional Security Hub.
For organization-wide deployment, you use "central configuration," and with Security Hub CSPM configuration policies you can centrally manage the security standards, enabling/disabling of controls, and the regions and accounts the policy applies to.※4
Security Hub Advanced is the Security Hub rebranded as a unified security solution.
For organization-wide deployment, you use the AWS Organizations management policy (Security Hub policies), and you can set in which regions to enable Advanced.※5
CSPM and Advanced share the delegated administrator.
When you designate a delegated administrator in one service, the same account becomes the delegated administrator in the other as well.
However, their enablement states are independent, and each capability must be enabled individually.
There is a blog that clearly organizes CSPM and Advanced from the AWS Organizations perspective, so please be sure to read it.
From here, I will focus on the organization-wide deployment of Security Hub CSPM.
| Target | Deployment method | Source regions | Aggregation destination |
|---|---|---|---|
| Member accounts | Central configuration on the Audit account | Control Tower home regions | Tokyo region |
| Management account | Enabled standalone | All regions | Tokyo region |
Set up Security Hub CSPM central configuration on the Audit account and deploy it to member accounts across the organization.
However, as described in the section "Differences Between the Management Account and Member Accounts,"
the denied regions of the management account cannot be linked in the Security Hub cross-region aggregation settings.
Exclude the management account from the accounts targeted by the Security Hub CSPM configuration policy, and enable Security Hub CSPM standalone in the management account.
After enabling it in all regions of the management account, you configure the region aggregation settings on the management account.
Findings on member accounts managed by central configuration are aggregated into Security Hub CSPM in the Tokyo region of the Audit account through Organizations integration.
Also, since the findings of security services other than Security Hub CSPM are aggregated into each account's Security Hub CSPM, the findings of the security services of all accounts are ultimately aggregated into the Audit account.
Because the management account is managed standalone, you need to forward its findings to the Security Hub CSPM of the Audit account via EventBridge.
GuardDuty
On the Audit account, configure the organization-level auto-enable setting that excludes the management account.※6
GuardDuty is automatically enabled in new and existing member accounts, and findings are aggregated into the Audit account.
This organization-level auto-enable setting must be configured for each region.
Since Security Hub is managed standalone in the management account, GuardDuty is also enabled standalone in all regions to match.
Findings are integrated into Security Hub and aggregated into the Tokyo region through the region aggregation feature.
IAM Access Analyzer
IAM Access Analyzer has three types of analyzers.
- External access findings: Detect resources accessible from outside the organization
- Internal access findings: Detect resources accessible from other accounts within the organization
- Unused access findings: Detect unused IAM roles and permissions
The internal access and unused access analyzers are charged per analyzed resource, so costs tend to be high. We recommend enabling them only when needed, such as during an IAM role inventory.
This article focuses on the external access analyzer.
Create an organization-level external access analyzer in the Audit account.
By setting the zone of trust to "organization," only access from outside the organization is targeted for detection.
With this configuration, there is no need to create analyzers or archive rules in member accounts.
However, if you want to detect access from other accounts even within the organization, you need to create an analyzer with the zone of trust set to "account" in each account.
The pros and cons of each configuration are summarized in the following blog.
Unless you have specific requirements, we recommend creating an analyzer with the zone of trust set to "organization" on the Audit account.
When the zone of trust is "organization," all accounts in the organization, including the management account, are covered.
Therefore, for the management account, the configuration differs between the home regions and the denied regions.
| Region | Configuration |
|---|---|
| Home regions | Analyzed by the Audit account's analyzer (zone of trust is "organization") |
| Denied regions | Create an analyzer with the zone of trust set to "account" |
If you also create an analyzer in the home regions, the findings will duplicate those of the Audit account's analyzer.
An analyzer is created on the management account only for the denied regions.
Detective
On the Audit account, configure the organization-level auto-enable setting.※7
It must be configured for each region.
Even if you remove the management account from the member accounts in the organization-level settings, you cannot enable Detective on the management account.
Therefore, the management account is configured as follows.
| Region | Configuration |
|---|---|
| Home regions | Add the management account as a member on the Audit account |
| Denied regions | Enable standalone |
Inspector
On the Audit account, create an Inspector policy, which is an AWS Organizations management policy, and deploy it across the organization.
This Inspector policy allows flexible settings, such as which Inspector scan types to enable and in which regions to enable those scan types.
In addition, since this policy can be attached per OU or per account, you can adjust the scan types enabled in each account.
If you also enable Inspector on the management account, create an Inspector policy for the management account and attach it to the management account.
However, if you follow AWS best practices and do not build workloads in the management account, there are no Inspector scan targets (EC2, Lambda, ECR, code repositories), so the need to enable it is low.
Notification Platform for Findings
Findings aggregated in Security Hub CSPM of the Audit account can be notified through EventBridge and SNS.
The notification targets are as follows.
- Security Hub CSPM: Control violations
- GuardDuty: Threat detection
- IAM Access Analyzer: External access findings
- Inspector: Vulnerability detection
However, with only EventBridge and SNS, you cannot customize subject lines or route notifications to each member account.
By inserting Step Functions before SNS, you can implement the above processing.
I plan to explain the notification platform for security services in a multi-account environment in a separate article.
Conclusion
I have summarized the security service configuration in a multi-account environment.
The handling of the management account in particular is a tricky point.
This is just the configuration I personally think is best, so please change it as appropriate according to your requirements.
I hope this article is helpful to someone.
That's all from Yoshida of the Cloud Business Division!
References
- ※1 Two types of region deny controls configurable in Control Tower (per landing zone or per OU)
- ※2 [AWS Organizations] SCPs are not applied to the management account | DevelopersIO
- Thinking about the management account when using Security Hub with region aggregation and Organizations integration | DevelopersIO
- Thinking about the management account when using Security Hub central configuration | DevelopersIO
- ※3 3. Created AWS resources | Members Service Specifications
- Opt out of Control Tower-managed CloudTrail to reduce CloudWatch Logs costs | DevelopersIO
- [AWS Control Tower] Points to note about CloudTrail costs when updating to landing zone v3.x | DevelopersIO
- Bulk-checking duplicate CloudTrail trails across an entire AWS Organization from the management account | DevelopersIO
- [AWS Config] A summary of the settings AWS Control Tower does and does not configure for you - Serverworks Engineer Blog
- ※4 [Update] AWS Security Hub deployment to organizations can now be configured with customized security standards and controls! #AWSreInvent | DevelopersIO
- ※5 Security Hub policies - AWS Organizations
- I organized the new AWS Security Hub (Advanced) and the conventional AWS Security Hub (CSPM) in relation to AWS Organizations | DevelopersIO
- ※6 [Update] The method for GuardDuty auto-enable settings for member accounts in AWS Organizations has changed | DevelopersIO
- ※6 [Update] Auto-enable options per protection plan, usable when managing multiple Organizations accounts with Amazon GuardDuty, have been expanded | DevelopersIO
- I checked the behavior when both Organizations integration and Security Hub integration are used | DevelopersIO
- I considered the configuration, notification methods, and operation of AWS IAM Access Analyzer in multi-account environments | DevelopersIO
- ※7 Trying to enable trusted access for Amazon Detective | DevelopersIO
- ※8 How to view Detective in an Organizations environment from member accounts | DevelopersIO
- [Update] "Inspector policies," which allow flexible management of Amazon Inspector scan settings, are now available in AWS Organizations | DevelopersIO
