Granular Account and Region Control over Data Collection

Last Updated

March 2026

Author

Controlling Data Collection Scope

This guide explains how to customize which AWS accounts and regions the Cloud Intelligence Dashboards Data Collection framework processes. You can limit data collection to specific accounts, exclude certain accounts, or apply granular rules to accounts and OUs per module and region. No changes to the deployed CloudFormation stack are required. You only need to supply configuration files, per the description below and The Account Collector Lambda automatically detects and applies them.

Overview

The Data Collection framework provides three methods to control how accounts are processed:

All configuration files should be placed in your CID data S3 bucket. The CID-DC-account-collector Lambda defines default values for these in the environment variable parameters. You may customize as needed. By default, the prefix will be account-list/. These files are not created or deployed automatically but must be manually created, per instructions below.

Inclusion and Exclusion Lists

These simple list-based methods apply globally to all data collection modules.

Inclusion List

Use an inclusion list when you want to collect data from only a specific set of accounts, and not use AWS Organizations to retrieve the list of all accounts in the Organization. This is useful if you have restrictions to accessing AWS Organizations. See also Data Collection without AWS Organizations.

The data fields needed are: account_id, account_name, and payer_id. Note the inclusion list config can be either a CSV or a JSON structure but you must ensure the file suffix matches the format.

File location (default): s3://<your-cid-bucket>/account-list/account-list.csv or account-list.json

CSV format:

account_id,account_name,payer_id
123456789012,Production Account,111122223333
234567890123,Development Account,111122223333
345678901234,Staging Account,111122223333

JSON format:

[
  {"account_id": "123456789012", "account_name": "Production Account", "payer_id": "111122223333"},
  {"account_id": "234567890123", "account_name": "Development Account", "payer_id": "111122223333"}
]

When an inclusion list is present, the framework collects data only from the accounts in this file and ignores your AWS Organization structure.

Exclusion List

Use an exclusion list when you have access to your AWS Organizations but want to universally exclude specific accounts. For example, you may want to exclude one or more accounts that are used for security purposes. Note, this functionality does not process OUs. If you wish to exclude an entire OU, either specify each account in the file or consider the Granular Execution Control option described later.

File location (default): s3://<your-cid-bucket>/account-list/excluded-linked-account-list.csv

Format:

The format is a simple comma-separated list of 12-digit AWS account IDs (Note: ensure any leading 0s are included):

123456789012,234567890123,345678901234

List account IDs separated by commas on a single line. The framework will skip these accounts when iterating through your Organization.

Choosing Between Inclusion and Exclusion

Granular Execution Control

For advanced scenarios, granular execution control allows you to define allow and deny account-based rules at the module level, with optional region filtering. This approach follows IAM-style policy evaluation where deny rules always take precedence over allow rules, no matter where they are defined in a sequence. For example, if your first rule is to deny using a specific module, account, and region combination and your tenth rule is to allow that combination (or vice versa), that particular combination will still be denied unless you remove the deny-based line.

File location (default): s3://<your-cid-bucket>/account-list/granular-execution-config.csv

File Format

module,policy_type,principal,regions,payload

Examples

Allow all modules at the root OU level, then deny all regions to one accounts but only us-east-1 to another:

*,A,r-xxxx,,
*,D,345678901234,*
*,D,456789012345,us-east-1

Deny a specific account for the budgets module (all regions):

budgets,D,123456789012,*

Deny a specific account for the ec2 inventory in us-east-1 only:

inventory-ec2-instances,D,234567890123,us-east-1

Allow an entire OU for the backup module:

backup,A,ou-abc1-12345678,*

Allow an OU but deny a specific account within it:

backup,A,ou-abc1-12345678,*
backup,D,345678901234,*

Deny multiple regions for a specific account for all modules:

*,D,456789012345,us-east-1:eu-west-1

Deny specifc regions for all accounts for all modules:

*,D,*,us-east-1:eu-west-1

Deny all regions for all accounts for all modules. This rule would produce an error because nothing would be allowed:

*,D,*,*

Wildcards and Blank Fields

The module and regions fields support a wildcard (*) or can be left blank:

Region Scope and Restrictions

The regional restriction in the granular policy works in conjunction with the top-level Regions in Scope parameter defined in the Data Collection Stack deployment. The granular policy can only restrict regions that are already included in that top-level scope — it cannot add regions that are not defined there.

For example, if your Data Collection Stack is deployed with us-east-1:us-west-2:eu-west-1 as the regions in scope, a granular policy can deny eu-west-1 for a specific module, but it cannot enable ap-southeast-1 if that region is not in the top-level scope.

Ensure that the Regions in Scope parameter in your Data Collection Stack includes all regions you may want to collect from. Then use the granular policy to restrict specific modules or accounts to a subset of those regions as needed.

Best Practices

If you wish to deny one or a few specific accounts across all modules while allowing everything else, a recommended approach is:

For example:

*,A,r-xxxx
*,D,345678901234
*,D,456789012345

This ensures all accounts in the Organization are allowed by default, and you can then pare down the scope by adding targeted deny rules.

Policy Evaluation

The granular configuration follows IAM-style policy evaluation:

This allows you to create broad allow rules (such as allowing an entire OU) and then carve out specific exceptions with deny rules.

Precedence

When a granular execution config file exists and contains rules for a module:

If the granular config file exists but has no rules for a specific module, that module falls back to the standard inclusion/exclusion list behavior.

Troubleshooting