AWS Cloud Operations & Migrations Blog

Identify AWS resources at risk across your multi-account environment with AWS Organizations integrations

With numerous AWS accounts in an organization, receiving an external security finding like a vulnerability assessment or pen test report impacting multiple resources can be challenging. Without a centralized resource viewing and search capability, identifying the affected resources require switching and inspecting each account individually, which is time-consuming and inefficient. Security vulnerabilities are time-sensitive, and promptly identifying and narrowing down the problem area is crucial for effective remediation.

To identify the security vulnerability, understand your compliance, audit, and security requirements and check whether you are meeting these requirements, you need visibility of the resources you have. You also need the visibility of who is accessing those resources, and what they are doing with them.

Using AWS Organizations, and following the best practice guidance, you can enable integration with other AWS services to centrally scan your resources and identify security risks across all your AWS accounts in your organization.

In this blog post, we will cover AWS services such as AWS Config, Amazon GuardDuty, AWS Resource Explorer, AWS CloudTrail, AWS Control Tower, integrated with AWS Organizations, that can help identify risks associated with your AWS resources across your organization. This blog post will walk you through the best practices for identifying security risks quickly through these AWS services enabled across multiple accounts in your organization.


You are familiar with AWS Organizations, and AWS Control Tower services, and have set up a multi-account environment on AWS already using either of these services.

Set up your AWS environment following a multi-account strategy

Most customers start on AWS with a single account. With growing usage to multiple teams with multiple workloads, securely segregating resources can be challenging. An AWS account act as security boundary, enabling you to implement access controls and isolate resources. By having multiple accounts, you can effectively segregate environments, enforce granular permissions, and enhance overall security posture, to have better access management and resource separation. If you haven’t set up your multi-account environment following best practices, you can set it up using AWS Control Tower and AWS Organizations. Setting up your multi-account environment with AWS Control Tower orchestrates AWS Cloud Trail and AWS Config services automatically.

Next, you can also consider following a meaningful account naming convention to locate your resources easily. You can then organize your AWS accounts into organizational units (OUs) based on common use cases so that you can apply common controls across the OUs for efficient administration and governance. To allow you to further group resources over other dimensions, such as access controls, targeting automations, or some other operational purpose, you can consider implementing a tagging strategy.

Establish visibility across resources in your multi-account environment using AWS Resource Explorer

For evaluating risks or to investigate an incident, it is important to have visibility across your AWS resources. AWS Resource Explorer is a resource search and discovery service that helps you explore your resources with metadata like names, tags, and IDs. You can set up free-text and filtered search for resources over multiple Regions and multiple accounts using Resource Explorer.

To search resources across your organization, set up Trusted Access via the Resource Explorer console with AWS Organizations from the management account. For decentralized management of resource search and flexibility, we recommend you set up a delegated administrator for Resource Explorer to create multi-account resource views and scope it to an organizational unit or your entire organization as needed.

Lastly, create a Resource Explorer view that is scoped to your organization (or to a particular OU), as shown in the Image 1. You can configure Resource Explorer across all your member accounts by following the Quick Setup.

You can configure the new Org-wide view as the default view for your delegated administrator account and then, assuming you have the appropriate IAM permissions, you can search across all the resources in your organization from this account.

Image 1: Create a Resource Explorer view scoped to you organization

Image 1: Create a Resource Explorer view scoped to your organization

Once you have your AWS Resource Explorer set up, you can now query resources across your entire organization to identify vulnerabilities across your resources centrally and avoid accessing individual accounts, saving you time. AWS Resource Explorer is offered at no additional charge. There are no set-up fees or upfront commitments. You may, however, incur charges if a service that is being called charges for List or Describe API calls, for example, the Amazon Simple Queue Service (SQS).

Next, let’s set up an audit trail to monitor API activity across all of your AWS accounts with AWS CloudTrail.

Create an audit trail for AWS account activities and data events

To ensure all these actions are recorded across your multi-account AWS environment, you can create a centrally managed AWS CloudTrail trail, so that all your logs go to a single log archive account and you can query them from that account. As it’s a shared log archive account, you only have to set up your log analysis tooling, such as Amazon Athena or AWS CloudTrail Lake once and it works for all your accounts.

Please note that if you have set up your organizational trail using AWS Control Tower as an optional feature, you have this setup already and you may skip and proceed to the next step.

You can send the events pertaining to your resources, regions, services, and data across your organization to a central location. For example, an Amazon Simple Storage Service (Amazon S3) Bucket in your Log Archive account that serves as an immutable source of truth for auditing access to your environment. See this documentation to understand what all actions are supported for CloudTrail delegated administrator for a decentralized management of CloudTrail across your organization. You can also refer to the best practices in CloudTrail for more information.

To enable organizational level trail, you can go to the account where the delegated administrator is enabled, and create org level trail for management events, data events, and CloudTrail Insights.

Now, from the delegated administrator account, go to CloudTrail and select Trails from the left section and follow the details as shown in Image 2 to configure it.

Image 2: Configure to create CloudTrail event for the organization from the delegated account

Image 2: Configure to create CloudTrail event for the organization from the delegated account

It’s a best practice to aggregate your CloudTrail data within your Log Archive account, and provide the URI of an S3 bucket already created in that account. You can use the sample S3 Bucket policy from the AWS CloudTrail documentation. If you want to learn other types of events that CloudTrail captures, see the type of events.

Since events are being aggregated centrally, you can easily monitor them and create event rules based on certain events, like root login, access to production environments, specific actions on S3 buckets, and access to other regions based on CloudTrail event logging. For this, you can follow the principles of an event driven architecture to track security across your environment. We will dive into this topic at a later time.

At this point, you can explore resources across your entire organization, collect events across your environment, API actions, data events, and get API insights. Next, we’ll explore how you can keep track of your resource configuration using AWS Config.

Monitor resource configurations across multiple-accounts and multiple-Regions using AWS Config Aggregator

You can monitor and evaluate resource configuration centrally using AWS Config Aggregator set up across your organization to simplify the process of monitoring and evaluating resource configurations against defined rules. With AWS Config Aggregator created for the entire organization using integration with AWS Organizations, you can aggregate your entire Config rules and inventory. Doing so, you’ll be able to visualize AWS resource compliance across your organization to quickly identify and remediate any non-compliant resources. See Image 3 for more information.

Image 3: AWS Config Aggregator Dashboard showing the aggregated compliance report across an organization

Image 3: AWS Config Aggregator Dashboard showing the aggregated compliance report across an organization

To avail the benefits mentioned here and for decentralized management of AWS Config, you can set up AWS Config Aggregator across your organization using your delegated administrator account for AWS Config.

You should periodically review the AWS Config rules and compliance reports to ensure they remain effective and aligned with your organization’s requirements. Update the rules as needed to reflect changes in resource configurations, compliance policies, or best practices. You can also consider documenting the AWS Config rule configurations, compliance findings, and remediation actions for auditing and compliance purposes. Communicate the compliance status and remediation efforts to the relevant stakeholders within your organization. Please see the blog post for more information and best practices on AWS Config.

Identify potential threats and generate security findings using Amazon GuardDuty

You can leverage Amazon GuardDuty to detect potential security threats and anomalies within your AWS environment. This empowers you with a setup in you AWS environment that continuously monitors to help you identify and respond to potential security threats in near real-time. For example, you can identify security findings such as unauthorized access attempts; deviations from normal usage or activity patterns; suspicious network traffic with known malicious IP addresses port scanning activities, or other suspicious network patterns; potential data exfiltration with transfer of large amounts of data outside of your AWS environment; compliance violations, such as using disallowed APIs or services, which may violate your organization’s security policies.

Configure GuardDuty across your organization using integration with AWS Organizations and set up a delegated administrator for it. From the delegated administrator account, set the preference to auto-enable GuardDuty on behalf of member accounts within the organization.

Image 4: Setting the options for auto-enabling GuardDuty

Image 4: Setting the options for auto-enabling GuardDuty

To mitigate the findings quickly, you can get recommendations for the remediation steps using Guarduty. We will not be covering the remediation steps in this blog post and only focus on identifying the security findings. You can read about remediation best practices here. Please note that you can integrate GuardDuty with services like Amazon CloudWatch, AWS Lambda, and Amazon Simple Notification Service (Amazon SNS), for automated responses, notifications, and custom workflows based on the findings.

You can send these findings from GuardDuty to a preferred channel using Amazon EventBridge. GuardDuty creates an event for EventBridge for newly generated high priority findings. Since all findings are dynamic, when GuardDuty detects new activity related to the same security issue, it will aggregate findings to avoid duplicate notifications, and they will be delivered to you automatically.
Delegated administrators can adjust the frequency of publishing new findings to EventBridge under GuardDuty Settings> Findings export options to meet their business needs. The default value is 6 hours, but it can be adjusted to 1 hour or 15 minutes intervals.


By enabling AWS Resource Explorer, AWS Config, AWS CloudTrail, and Amazon GuardDuty across multiple accounts through AWS Organizations integrations, you can get a complete view of risks associated with the resources across your organization and be better informed to take action on the findings. Automating the deployment of controls, and integrating identification and detection tools allow you to build towards your operational excellence, and focus on building new features for your customers, letting AWS take care of the undifferentiated heavy lifting. Read how Volkswagen Financial Services scaled its governance and security management practices using AWS Organizations.

If you are interested in learning more about security services, review our Security Learning plan in skill builder, or review our Security Incident response whitepaper, and deploy our Automated Security Response solution to remediate some of the security and compliance findings in your AWS environment!

About the authors

Caroline Johnston

Caroline is a Senior Technical Account Manager at AWS. Originally from the UK, she is now based in Wellington, NZ. She holds a PhD in Bioinformatics and her roles before joining AWS include building bioinformatics tools for neuroscientists and running a high performance compute cluster. These days she works with Public Sector organisations to help them operate successfully on AWS.

Pujah Goviel

Pujah Goviel is a Technical Account Manager at Amazon Web Services (AWS). She spends her day working with the Enterprise Support customers, solving their operational challenges, and helping them to accelerate innovation on AWS. She was a DevOps specialist prior to joining AWS and actively contributed to various technical blogs on her own blog site as well as developed various Terraform modules in the Terraform registry.

Sailesh Kadam

Sailesh Kadam is a Sr. Solutions Architect at Amazon Web Services. He works with customers early in their AWS journey help them migrate and modernize their applications in the cloud. Outside of work, he loves to make and eat sourdough bread.

Samir Behara

Samir Behara is a Senior Cloud Infrastructure Architect with AWS Professional Services. He is passionate about helping customers accelerate their IT modernization through cloud adoption strategies. Samir has an extensive software engineering background and loves to dive deep into application architectures and development processes to drive performance, operational efficiency, and increase the speed of innovation.

Amey Bhavsar

Amey Bhavsar is a Sr. Solutions Architect at AWS, specializing in guiding enterprise clients across diverse industries. He is a core member of the Next Gen Developer Experience TFC, a Segment Retail Ambassador, and a GenAI Hero. He helps accelerate AWS cloud adoption by designing and implementing scalable and resilient architectures.