Introduction
Cloud security operations often require ensuring consistent and compliant network access for security tools across hundreds of Amazon EC2 instances distributed across multiple AWS accounts and regions.
In large-scale environments managed through AWS Organizations, what seems like a simple requirement can quickly become operationally complex.
Many security tools depend on network connectivity to perform their functions. Without the correct inbound rules configured on EC2 Security Groups, these tools cannot reach the instances they are supposed to monitor and access.
Common examples include:
Privileged Access Management (PAM) such as BeyondTrust or CyberArk, which require network connectivity to EC2 instances to rotate credentials and manage privileged sessions.
Vulnerability management platforms such as Qualys or Tenable, which require network connectivity to perform authenticated vulnerability scans and deeper security assessments.
Configuration compliance and hardening tools which connect via SSH or RDP to EC2 instances to verify system configurations, validate security baselines, and assess compliance with standards such as CIS Benchmarks.
In large multi-account AWS environments, maintaining this connectivity manually becomes unmanageable.
The traditional manual approach quickly breaks down for several reasons:
Slow onboarding: Every new AWS EC2 on any AWS account required manual configuration of Security Group rules.
Operational fragility: If someone accidentally removed a rule, the security tool immediately lost access reducing visibility into the environment.
Lack of scalability: Managing scanner IP ranges across dozens of AWS accounts and multiple regions through the console simply doesn't scale.
As the environment grows, these issues compound, creating gaps in security monitoring and increasing operational overhead for security teams.
Objective
The goal was to guarantee network accessibility in a reliable and automated way for approved security tools to EC2 instances across all AWS regions and accounts.
The solution needed to meet the following requirements:
Automatic coverage for new resources: Newly launched EC2 instances should always receive the required connectivity without manual intervention.
Operational scalability: The mechanism must work seamlessly across multiple regions and accounts without requiring per-account configuration.
Auto remediation configuration: If a rule is accidentally removed, it should be automatically restored.
Centralized management : Security teams should be able to update security tools IP ranges in a single location and propagate those changes across all accounts.
Solution Architecture
To achieve this, I built an automated daily compliance mechanism that validates and enforces security group rules across the entire AWS Organizations.
Architecture Diagram
The following diagram illustrates the high-level architecture used to automate Security Group compliance across multiple AWS accounts and regions.
The automation runs from a dedicated security account, where AWS Lambda functions handle two main tasks: building an inventory of AWS accounts by assuming a role in the Organizations management account and performing remediation actions by assuming roles in member accounts.
In this example, the diagram shows two fictional member accounts (Account X and Account Y) containing EC2 instances and Security Groups. In real environments, this approach can scale to dozens or even hundreds of accounts.
The architecture also demonstrates a multi-region setup (us-east-1, us-east-2, and sa-east-1), where Security Groups reference regional Prefix Lists to allow connectivity from centralized security tools.
Core Components
The solution relies on a small set of AWS services working together to provide centralized control, automation, and scalability across all accounts in the organization.
AWS Lambda: Acts as the automation engine. The function assumes cross-account IAM roles to audit EC2 Security Groups and automatically remediate missing rules when necessary.
Amazon S3: Stores a daily-generated inventory of all AWS accounts. This inventory is used by the automation workflow to determine where audits and remediations should be executed.
AWS VPC Prefix Lists: Provides a centralized and scalable way to manage the IP ranges used by security tools. Instead of hardcoding IPs in Security Group rules, the rules reference a Prefix List. This allows security teams to update the IP ranges in a single place and AWS automatically propagates the changes to every Security Group referencing the list.
AWS Organizations: Provides the centralized account structure that allows the automation to discover and operate across all AWS accounts.
AWS Resource Access Manager (RAM): Enables the Prefix List to be shared with all accounts in the organization, allowing Security Groups in any account to reference the centralized list.
AWS CloudFormation StackSets: Used to deploy the required IAM roles across all AWS accounts in the organization. This ensures that newly created accounts automatically receive the permissions required for the automation to operate.
How It Works
1. AWS account inventory collection
A scheduled AWS Lambda function (triggered by Amazon EventBridge) runs in the management account and queries AWS Organizations to retrieve the list of active accounts. The function also enumerates enabled AWS regions and stores this inventory in an Amazon S3 bucket. Maintaining this inventory allows the automation to dynamically adapt as new accounts are added or removed from the organization.
2. Cross-Account Security Group Audit and Remediation
The main Lambda function consumes the account inventory stored in S3 and iterates through each AWS account and region. Using cross-account role assumption, the function inspects EC2 instances and their associated Security Groups to verify whether inbound access from the authorized Prefix List is allowed. If the required rule is missing, the Lambda automatically injects the appropriate inbound rule into the Security Group, ensuring the instance remains accessible to the approved security tools.
As a result, EC2 instances will have a Security Group rule similar to the following:
In this example, the rule allows all ports to simplify connectivity for security tools. However, depending on your environment and the requirements of each tool, you can restrict the rule to only the specific ports that are required.
Deployment Steps
The full implementation for this project is available in the GitHub repository.
Below is a high-level guide to deploy this solution in a multi-account AWS environment.
1. Create the Prefix List
Start by creating a Prefix List in each region where your workloads run. This list will contain the IP ranges used by your security tools and will be referenced by Security Group rules instead of hardcoding individual IP addresses.
With this approach, security teams can update IP ranges centrally through the Prefix List, without needing to modify Security Groups across multiple accounts or regions.
2. Share the Prefix List Across Accounts
Use AWS Resource Access Manager (RAM) to share the Prefix List with all accounts in your AWS Organization.
This allows Security Groups in other accounts to reference the centralized Prefix List. After sharing, Security Groups in all accounts can reference the Prefix List.
3. Deploy the Cross-Account IAM Role
The automation Lambda requires permissions to describe and modify Security Groups across multiple AWS accounts.
To enable this, use AWS CloudFormation StackSetsto deploy a receiver role in all accounts of the organization. This ensures that newly created AWS accounts automatically receive the required role.
The following custom IAM policy is attached to the role:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowEC2",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeSecurityGroups",
"ec2:AuthorizeSecurityGroupIngress"
],
"Resource": "*"
},
{
"Sid": "AllowOrganizations",
"Effect": "Allow",
"Action": [
"organizations:ListAccounts",
"organizations:ListAccountsForParent"
],
"Resource": "*"
}
]
}
The role must also allow sts:AssumeRole from the central security account where the Lambda runs.
4. Deploy the Lambda functions
Deploy the two Lambda functions in the security account.
The first Lambda is responsible for building an inventory of AWS accounts by retrieving the list of accounts from AWS Organizations and storing this inventory in Amazon S3.
The second Lambda consumes this inventory, assumes the cross-account role in each account, audits EC2 Security Groups across regions, and automatically adds the missing inbound rule referencing the Prefix List when necessary.
5. Deploy the EventBridge Schedule
Create an Amazon EventBridge rule to trigger the Lambda functions on a schedule, for example once per day.
Extra: Security by Default with IaC
While the automation remediates missing rules, the best control is preventing the misconfiguration from happening in the first place.
To achieve this, a security-by-default approach can be implemented in the Infrastructure as Code layer using Terraform.
When new EC2 Security Groups are created, the rule allowing access from approved security tools is added by default. This ensures that new workloads are compliant from the moment they are deployed, reducing the need for remediation.
Example Terraform Configuration
Instead of hardcoding scanner IP addresses directly in Security Group rules, the configuration references AWS Managed Prefix Lists. This allows security teams to update scanner IP ranges centrally without modifying infrastructure code.
ingress {
from_port = 0
to_port = 65535
protocol = "-1"
description = "Allow security scanning tools"
prefix_list_ids = local.security_pl
}
Because Managed Prefix Lists are regional resources in AWS, the Terraform configuration dynamically selects the correct Prefix List ID based on the region where the infrastructure is deployed.
security_pl = lookup({
"us-east-1" = "pl-xxx"
"us-east-2" = "pl-yyy"
"sa-east-1" = "pl-zzz"
}, local.region)
This approach ensures that:
- Security tools have immediate access to newly created instances.
- IP changes are managed centrally through the Prefix List instead of individual Security Group rules.
Conclusion
Maintaining network access for security tools across multiple AWS accounts can quickly become an operational burden if handled manually.
By combining Managed Prefix Lists, cross-account automation, and Infrastructure as Code, we transformed this into a scalable and self-healing control.
Instead of relying on manual Security Group management, connectivity for security tooling becomes part of the platform itself automatically enforced and continuously verified.
Top comments (1)
Have you considered using could formation stack sets to reduce the complexity, similar to this dev.to/aws-builders/securing-cicd-...