This chapter covers AWS Config Aggregator for multi-account and multi-region compliance management, a critical topic for the SOA-C02 exam under Domain 4 (Security) Objective 4.2: Implement and manage security and compliance controls. Expect 3-5% of exam questions to touch on AWS Config Aggregator, often in scenarios involving centralized compliance auditing across an organization. You will learn the architecture, configuration steps, querying capabilities, and common pitfalls to ensure you can design and troubleshoot aggregated compliance views in a multi-account AWS environment.
Jump to a section
Imagine you are the compliance officer for a large corporation with 50 regional offices (AWS accounts), each maintaining its own set of local policies and fire safety logs (AWS Config rules and resources). Without a central view, you would have to visit each office individually, request their logs, and manually compile a report — error-prone and time-consuming. Instead, you deploy a corporate audit dashboard (AWS Config Aggregator) that automatically pulls compliance data from every office into a single pane of glass. Each office must grant read-only access to the dashboard by installing a secure data collector (AWS Config Aggregator source account authorization). The dashboard does not store raw logs; it queries each office's database in real-time via a standardized API (AWS Config advanced queries). When you want to see which offices have fire extinguishers that are overdue for inspection (noncompliant resources), the dashboard runs the same query across all offices simultaneously. If a new office is acquired (new account), you simply grant access and it appears on the dashboard within minutes. The dashboard also logs who accessed which office's data (CloudTrail integration). This is exactly how AWS Config Aggregator works: it provides a centralized view of resource compliance across multiple accounts and regions by aggregating configuration snapshots and compliance data, without duplicating the data, using authorized source accounts and advanced queries.
What is AWS Config Aggregator and Why Does It Exist?
AWS Config Aggregator is a feature of AWS Config that enables you to aggregate configuration and compliance data from multiple AWS accounts and regions into a single, centralized account. This solves a fundamental challenge in multi-account environments: without an aggregator, you must log into each account and region separately to view compliance status. The aggregator collects data from source accounts (member accounts) and makes it available in the aggregator account (central account) via AWS Config advanced queries and the AWS Config console.
How It Works Internally
The aggregator does not copy or store raw configuration data. Instead, it maintains metadata about where data resides and uses API calls to query source accounts on demand. When you run an advanced query against the aggregator, it sends the same SQL-like query to each authorized source account/region combination, collects the results, and returns a unified response. This design ensures data sovereignty and minimizes storage costs, but it also means that query performance depends on the number of source accounts and regions, as well as the latency of each source Config API.
Key Components and Defaults
Aggregator Account: The central AWS account where the aggregator is created. This account must have the necessary permissions to call ConfigService:SelectAggregateResourceConfig and similar APIs on source accounts.
Source Accounts: Individual AWS accounts that share their Config data with the aggregator. Each source account must authorize the aggregator account by creating an authorization with the aggregator account ID and region.
Aggregator Regions: The aggregator can aggregate data from multiple source regions. The aggregator itself is created in a single region, but it can query data from any region where Config is enabled in source accounts.
Authorization: Source accounts must explicitly authorize the aggregator by calling PutAggregationAuthorization. This creates an authorization object that specifies the aggregator account ID and the aggregator region. The authorization expires after 24 hours by default, but you can set a custom expiration period (1-24 hours). This is a security measure to prevent unauthorized access.
Aggregator Resource: Created in the aggregator account using PutConfigurationAggregator. You specify which source accounts and regions to include. You can either list individual accounts or use AWS Organizations to automatically include all current and future accounts.
Advanced Queries: The aggregator supports SQL-like queries using SelectAggregateResourceConfig. The syntax is similar to SelectResourceConfig but includes the aggregatorName parameter. Queries can filter by resource type, region, account ID, compliance status, and tags.
Compliance Dashboard: The AWS Config console in the aggregator account shows aggregated compliance data, including a summary of compliant/noncompliant resources by account and region.
Limits: Each aggregator can aggregate data from up to 1000 source accounts and 100 regions. You can create up to 3 aggregators per account per region. If you need more, request a limit increase.
Configuring AWS Config Aggregator
#### Step 1: Enable AWS Config in All Accounts and Regions
Before aggregation works, AWS Config must be enabled in every source account and region you want to aggregate. Use AWS Config rules to evaluate resources.
#### Step 2: Create an Aggregation Authorization in Each Source Account
In each source account, run the following AWS CLI command (or use the console):
aws configservice put-aggregation-authorization \
--authorized-account-id 123456789012 \
--authorized-aws-region us-east-1 \
--tags Key=Purpose,Value=CentralAggregatorThis authorizes the aggregator account (123456789012) in region us-east-1 to access Config data. The authorization expires after 24 hours by default. You can set --validity-period in hours (1-24).
#### Step 3: Create the Configuration Aggregator in the Central Account
In the aggregator account, create the aggregator:
aws configservice put-configuration-aggregator \
--configuration-aggregator-name my-org-aggregator \
--organization-aggregation-source RoleArn=arn:aws:iam::123456789012:role/aws-service-role/organizations.amazonaws.com/AWSServiceRoleForOrganizations,AwsRegions=us-east-1,us-west-2,AllAwsRegions=falseIf not using Organizations, use --account-aggregation-sources with a list of account IDs and regions.
#### Step 4: Query Aggregated Data
Use the AWS Config console or CLI to run advanced queries. For example:
aws configservice select-aggregate-resource-config \
--configuration-aggregator-name my-org-aggregator \
--expression "SELECT resourceType, resourceId, awsRegion, accountId WHERE resourceType = 'AWS::EC2::Instance' AND configuration.complianceType = 'NON_COMPLIANT'"How It Interacts with Related Technologies
AWS Organizations: If you use Organizations, you can create an aggregator that automatically includes all accounts in the organization. This simplifies management because new accounts are automatically added. The aggregator uses the Organizations service-linked role to list accounts.
AWS Config Rules: The aggregator does not evaluate rules; it only aggregates compliance results. Rules must be deployed in each source account. Use AWS Config conformance packs to deploy rules consistently across accounts.
AWS CloudTrail: All aggregator API calls (e.g., PutConfigurationAggregator, SelectAggregateResourceConfig) are logged in CloudTrail in the aggregator account. This is useful for auditing who queried what data.
AWS Config Advanced Queries: These are the primary way to retrieve aggregated data. The query engine supports SQL-like syntax with limitations: it cannot do JOINs, subqueries, or aggregate functions like COUNT without pagination. Use SELECT with LIMIT and pagination tokens.
IAM Permissions: The aggregator account needs config:SelectAggregateResourceConfig, config:GetAggregateComplianceDetailsByConfigRule, and similar permissions. Source accounts need config:PutAggregationAuthorization. If using Organizations, the aggregator account needs organizations:ListAccounts and organizations:DescribeOrganization.
Enable AWS Config in Source Accounts
Before aggregation can work, AWS Config must be enabled in every source account and region you want to include. This involves setting up an S3 bucket for configuration snapshots, an SNS topic for notifications, and optionally AWS Config rules. Ensure that the AWS Config recorder is recording all resource types you care about. Without Config enabled, the aggregator will have no data to query. In the exam, a common scenario is that a source account has Config disabled in a specific region, causing that region's data to be missing from the aggregator.
Authorize Aggregator Account in Source
In each source account, create an aggregation authorization using PutAggregationAuthorization. This grants the aggregator account (by ID) and aggregator region access to the source account's Config data. The authorization has a validity period (default 24 hours) that can be set from 1 to 24 hours. If the authorization expires, the aggregator cannot query that source account. You can check existing authorizations with ListAggregationAuthorizations. In the exam, remember that authorizations are per aggregator account-region pair and must be created in each source account.
Create Configuration Aggregator in Central Account
In the aggregator account, create a ConfigurationAggregator resource using PutConfigurationAggregator. You specify either a list of individual accounts and regions (AccountAggregationSources) or an organization source (OrganizationAggregationSource) if using AWS Organizations. The aggregator name must be unique per account per region. After creation, the aggregator begins to aggregate data from authorized source accounts. You can verify with DescribeConfigurationAggregators. Note: If using Organizations, the aggregator account must have the appropriate service-linked role for Organizations.
Query Aggregated Config Data
Use SelectAggregateResourceConfig to run SQL-like queries across all aggregated accounts and regions. The query must be scoped to the aggregator. For example, you can filter by resource type, region, account ID, or compliance status. The API returns paginated results (max 100 items per page). Use the nextToken for pagination. The query is executed in real-time against each source account, so performance depends on the number of sources. Advanced queries cannot use aggregate functions like COUNT, SUM, or GROUP BY. For compliance details by rule, use GetAggregateComplianceDetailsByConfigRule.
Monitor and Troubleshoot Aggregation
Monitor the aggregator's status using DescribeConfigurationAggregatorStatus. It shows the status of each source account and region (e.g., SUCCEEDED, FAILED, OUTDATED). Common failures include expired authorizations, missing Config enablement, or IAM permission errors. Check CloudTrail logs for API calls. If a source account is not appearing, verify that the authorization exists and has not expired. Also ensure that the aggregator account has the necessary permissions to call Config APIs in source accounts (cross-account trust).
Enterprise Scenario 1: Centralized Compliance for a Large Organization
A financial services company uses AWS Organizations with 200 accounts across 5 regions. The compliance team needs a single view of all resources that are noncompliant with PCI DSS rules. They deploy an AWS Config Aggregator in the security account (central account) using the OrganizationAggregationSource. This automatically includes all existing and new accounts. They create conformance packs to deploy the same set of rules across all accounts. The aggregator allows the team to run a query like: "SELECT accountId, resourceType, resourceId WHERE complianceType = 'NON_COMPLIANT'" and get results from all accounts. Performance is generally fast with under 500 accounts; beyond that, queries may take several seconds. They set up a CloudWatch Events rule to trigger a Lambda function that runs the query daily and sends a report to Slack. One issue they encountered: when a new account was added, it took up to 15 minutes for the aggregator to recognize it because the Organizations service-linked role needed to sync. They also learned that authorizations are not needed when using Organizations — the aggregator uses the Organizations API to list accounts.
Enterprise Scenario 2: Multi-Account Audit for a Managed Service Provider
An MSP manages AWS environments for 50 clients, each with their own account. They want to provide a compliance dashboard to each client without giving them access to other clients' data. They deploy a separate aggregator per client? No, that would be costly. Instead, they create a single aggregator in the MSP's central account that aggregates data from all client accounts. They then use IAM policies to restrict which accounts a specific client can query. For example, they create an IAM role for Client A that has a policy allowing SelectAggregateResourceConfig only with a condition that filters by account ID. However, the aggregator does not support row-level security — the query can filter by account ID, but the IAM policy cannot restrict which account IDs are returned. So they must create separate aggregators per client. Each client account authorizes the MSP's aggregator account. They set the authorization validity period to 24 hours and use a Lambda function to refresh authorizations daily to avoid expiration. They also use CloudTrail to log all queries for compliance.
Performance and Scale Considerations
When aggregating many accounts (e.g., 1000+), query latency increases. AWS recommends limiting the number of source accounts per aggregator to 1000. If you need more, create multiple aggregators. Each aggregator can handle up to 100 regions. The aggregator itself is a regional resource; if you need cross-region disaster recovery, create aggregators in multiple regions. The aggregator does not support cross-region aggregation from a single aggregator? Actually, it does: you can specify multiple source regions in the aggregator configuration. But the aggregator itself is in one region; if that region goes down, you lose access until it recovers. For high availability, create a second aggregator in another region with the same source accounts.
What SOA-C02 Tests on This Topic
The SOA-C02 exam tests your ability to configure and troubleshoot AWS Config Aggregator in multi-account environments. Specific objectives include:
Domain 4.2: Implement and manage security and compliance controls.
Sub-objectives: Configure AWS Config rules, manage compliance data, and aggregate data from multiple accounts.
Common Wrong Answers and Why Candidates Choose Them
1. Wrong: "The aggregator stores a copy of all configuration data from source accounts." Why chosen: Many assume aggregation means data replication. Reality: The aggregator does not store data; it queries source accounts in real-time.
2. Wrong: "You must create an authorization in the aggregator account for each source account." Why chosen: Confusion about direction. Reality: Authorization is created in the *source* account, granting access to the *aggregator* account.
3. Wrong: "The aggregator can evaluate AWS Config rules across all accounts." Why chosen: Misunderstanding of aggregator's role. Reality: The aggregator only aggregates compliance results; rules must be deployed in each source account.
4. Wrong: "You can use advanced queries with COUNT(*) to get the total number of noncompliant resources." Why chosen: SQL familiarity. Reality: Advanced queries do not support aggregate functions; you must paginate and count client-side.
Specific Numbers and Terms on the Exam
Authorization validity period defaults to 24 hours, range 1-24 hours.
Maximum 1000 source accounts per aggregator.
Maximum 3 aggregators per account per region.
Advanced queries return max 100 items per page.
The CLI command is put-configuration-aggregator and put-aggregation-authorization.
Edge Cases and Exceptions
If a source account is part of an organization but the aggregator uses individual account sources (not OrganizationAggregationSource), new accounts are NOT automatically added.
If an authorization expires, the aggregator will show the source account status as FAILED. You must recreate the authorization.
When using Organizations, the aggregator account needs organizations:ListAccounts permission; if the aggregator account is not the management account, it must be a delegated administrator for Config.
The aggregator cannot aggregate data from accounts that are not in the same AWS partition (e.g., gov-cloud).
How to Eliminate Wrong Answers
If the question mentions "storing data" or "copying snapshots," eliminate that answer.
If it says "authorization in aggregator account," it's wrong.
If it says "evaluate rules across accounts," it's wrong.
If it says "use COUNT or GROUP BY," it's wrong.
Look for keywords: "real-time queries," "source account authorization," "OrganizationAggregationSource," "SelectAggregateResourceConfig."
AWS Config Aggregator does not store data; it queries source accounts in real-time.
Aggregation authorization is created in the source account, not the aggregator account.
Authorization validity period defaults to 24 hours; can be set from 1 to 24 hours.
Maximum 1000 source accounts and 100 regions per aggregator.
Maximum 3 aggregators per account per region.
Advanced queries do not support aggregate functions (COUNT, SUM, GROUP BY).
When using Organizations, use OrganizationAggregationSource to automatically include all accounts.
Each source account must have AWS Config enabled in the regions you want to aggregate.
Use DescribeConfigurationAggregatorStatus to troubleshoot aggregation failures.
The aggregator account needs config:SelectAggregateResourceConfig and related permissions.
These come up on the exam all the time. Here's how to tell them apart.
Individual Account Aggregation Sources
You must specify each account ID and region explicitly.
New accounts are not automatically added; you must update the aggregator.
You need to create aggregation authorizations in each source account.
Useful when you don't use AWS Organizations or want to exclude some accounts.
Provides fine-grained control over which accounts are aggregated.
Organization Aggregation Source
Automatically includes all current and future accounts in the organization.
No need for aggregation authorizations.
Requires the aggregator account to have Organizations permissions.
Simplifies management for large organizations.
Cannot exclude specific accounts; all accounts in the organization are included.
Mistake
The aggregator stores a copy of all configuration data from source accounts.
Correct
The aggregator does not store data; it queries source accounts in real-time via API calls. This is why query performance depends on the number of sources.
Mistake
You create the aggregation authorization in the aggregator account.
Correct
The authorization is created in the source account, granting the aggregator account access. The aggregator account does not create authorizations.
Mistake
The aggregator can evaluate AWS Config rules across all accounts.
Correct
The aggregator only aggregates compliance results. Rules must be deployed in each source account individually or via conformance packs.
Mistake
Advanced queries support aggregate functions like COUNT, SUM, and GROUP BY.
Correct
Advanced queries do not support aggregate functions. You must paginate through results and count client-side.
Mistake
If you use Organizations, you still need to create aggregation authorizations for each account.
Correct
When using OrganizationAggregationSource, authorizations are not required. The aggregator uses the Organizations API to list accounts.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, it does not. The aggregator queries source accounts in real-time using API calls. It only stores metadata about the source accounts and regions. This means query performance depends on the number of sources and network latency.
In the source account, use the PutAggregationAuthorization API (or CLI command `put-aggregation-authorization`). Specify the aggregator account ID and the aggregator region. Optionally set a validity period (1-24 hours). The authorization must be created in each source account.
Yes. You can create an aggregator using OrganizationAggregationSource. This automatically includes all accounts in the organization, and you do not need to create individual authorizations. The aggregator account must have the necessary Organizations permissions.
Use the SelectAggregateResourceConfig API with a SQL-like query. For example: `SELECT resourceType, resourceId, accountId WHERE resourceType = 'AWS::EC2::Instance' AND configuration.complianceType = 'NON_COMPLIANT'`. Results are paginated (max 100 items per page).
The aggregator will not be able to query that source account. The status for that source account will show as FAILED or OUTDATED. You must recreate the authorization in the source account. You can check the status using DescribeConfigurationAggregatorStatus.
No. The aggregator only works within the same AWS partition (e.g., commercial, gov-cloud, china). You cannot aggregate across partitions.
The default limit is 3 aggregators per account per region. You can request a limit increase via AWS Support.
You've just covered AWS Config Aggregator for Multi-Account — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?