AWS Config Not Aggregating All Regions: Closing Your Cross-Region Blind Spots

AWS Config records the configuration state of your resources and tracks how they change over time. On its own, Config is a per-region service. Each region keeps its own recorder, its own rules, and its own history. That regional isolation is fine until you need a single view of your compliance posture, and that is exactly what a Config aggregator gives you.

This Lensix check, account_configaggregator, verifies that your account has a configuration aggregator set up to pull data from every region, not just the one or two you actively work in.

---

What this check detects

The check inspects your AWS account for a Config aggregator and confirms it is configured to cover all regions. It fails when one of these is true:

• No configuration aggregator exists at all.
• An aggregator exists but only lists specific regions instead of using the "all regions" setting.
• An aggregator exists but new regions are not automatically included as AWS adds them.

An aggregator is a Config resource that consolidates configuration and compliance data from multiple source accounts and regions into a single account and region. With one in place, you can query the compliance state of every resource everywhere from one location instead of jumping between region dropdowns in the console.

---

Why it matters

Attackers love regions you forget about. A common pattern in real incidents looks like this: an attacker gains access to credentials, then spins up resources in a region your team never touches, say ap-south-1 or sa-east-1. Crypto mining instances, exfiltration buckets, or backdoor IAM roles get created somewhere your dashboards never look.

If your Config rules and compliance views only cover us-east-1 and eu-west-1, that activity never shows up in your security reporting. The resources are technically being recorded by Config in that region, but nobody is aggregating the data into a place a human or an alerting pipeline will actually see.

Beyond active attacks, there are everyday business consequences:

• Audit gaps. Frameworks like SOC 2, PCI DSS, and HIPAA expect continuous monitoring across your environment. "We only checked the regions we use" rarely satisfies an auditor.
• Drift you cannot see. A misconfigured security group or a public S3 bucket in an unwatched region drifts indefinitely with no remediation trigger.
• Multi-account sprawl. In an Organizations setup, each member account multiplies the number of region blind spots. An aggregator scoped to the whole org collapses that into one view.

---

How to fix it

There are two pieces to a complete fix. First, make sure Config recording is actually on in the regions you care about. Second, create an aggregator that pulls all of it together.

Step 1: Confirm Config is recording where you need it

Check the recorder status in a given region:

aws configservice describe-configuration-recorder-status \
  --region us-east-1

If recording is false or no recorder exists, set one up before the aggregator will return useful data. For new regions, the simplest path is the Config console "Set up AWS Config" wizard, or use AWS Config conformance packs deployed through Organizations.

Step 2: Create the aggregator (single account, all regions)

For a standalone account, create an aggregator that includes the current account and enables all regions:

aws configservice put-configuration-aggregator \
  --configuration-aggregator-name org-wide-aggregator \
  --account-aggregation-sources '[
    {
      "AccountIds": ["123456789012"],
      "AllAwsRegions": true
    }
  ]'

The key field is "AllAwsRegions": true. This tells the aggregator to include every current region and to automatically add new ones as AWS launches them, which is what closes the gap this check is looking for.

Step 2 (alternative): Organization-wide aggregator

If you run AWS Organizations, an org aggregator is far better than listing account IDs manually. It covers every current and future member account.

aws configservice put-configuration-aggregator \
  --configuration-aggregator-name org-wide-aggregator \
  --organization-aggregation-source '{
    "RoleArn": "arn:aws:iam::123456789012:role/service-role/AWSConfigRoleForOrganizations",
    "AllAwsRegions": true
  }'

Step 3: Verify

Confirm the aggregator is in place and covers all regions:

aws configservice describe-configuration-aggregators \
  --configuration-aggregator-names org-wide-aggregator

Look for "AllAwsRegions": true in the output. Then test that data is flowing by querying aggregated compliance:

aws configservice describe-aggregate-compliance-by-config-rules \
  --configuration-aggregator-name org-wide-aggregator

---

Doing it with Infrastructure as Code

Click-ops aggregators tend to rot. Define the aggregator in code so it is version controlled and reproducible.

Terraform

resource "aws_config_configuration_aggregator" "org" {
  name = "org-wide-aggregator"

  organization_aggregation_source {
    all_regions = true
    role_arn    = aws_iam_role.config_aggregator.arn
  }
}

For a single account instead of an org:

resource "aws_config_configuration_aggregator" "account" {
  name = "account-aggregator"

  account_aggregation_source {
    account_ids = [data.aws_caller_identity.current.account_id]
    all_regions = true
  }
}

CloudFormation

{
  "Resources": {
    "OrgAggregator": {
      "Type": "AWS::Config::ConfigurationAggregator",
      "Properties": {
        "ConfigurationAggregatorName": "org-wide-aggregator",
        "OrganizationAggregationSource": {
          "AllAwsRegions": true,
          "RoleArn": "arn:aws:iam::123456789012:role/AWSConfigRoleForOrganizations"
        }
      }
    }
  }
}

---

How to prevent it from coming back

An aggregator created by hand can be deleted by hand, and a region added next year will quietly slip out of scope if someone listed regions explicitly instead of using "all regions". A few guardrails keep this fixed:

• Manage it in Terraform or CloudFormation as shown above, and require all_regions = true. Reviewers can catch a pull request that lists regions one by one.
• Add a policy-as-code check. With OPA or Checkov against your IaC, fail any aggregator definition that does not set all regions.
• Use a delegated administrator account. Centralize Config and the aggregator in a dedicated audit account so individual teams cannot accidentally break the org-wide setup.
• Run continuous checks. Let Lensix re-run account_configaggregator on a schedule so a regression surfaces within hours rather than at audit time.

A simple Checkov custom policy snippet to gate the Terraform:

from checkov.terraform.checks.resource.base_resource_check import BaseResourceCheck
from checkov.common.models.enums import CheckResult

class ConfigAggregatorAllRegions(BaseResourceCheck):
    def __init__(self):
        super().__init__(
            name="Config aggregator must cover all regions",
            id="CKV_CUSTOM_1",
            categories=["LOGGING"],
            supported_resources=["aws_config_configuration_aggregator"],
        )

    def scan_resource_conf(self, conf):
        for source in conf.get("organization_aggregation_source", []) + \
                      conf.get("account_aggregation_source", []):
            if source.get("all_regions") == [True]:
                return CheckResult.PASSED
        return CheckResult.FAILED

check = ConfigAggregatorAllRegions()

---

Best practices

• Always prefer "all regions" over a region list. Explicit region lists are the single most common reason this check fails after someone thought they had it covered.
• Aggregate at the organization level when you use AWS Organizations. It scales to new accounts with zero extra work.
• Keep the aggregator and recorders in a dedicated audit account with restricted access, separate from workload accounts.
• Do not confuse aggregation with recording. An aggregator over a region where Config is off shows you nothing. Enable recording everywhere you expect resources to live.
• Wire aggregated compliance into alerting. Query the aggregator from EventBridge or a scheduled Lambda and route non-compliant findings to Slack or your SIEM so the data is acted on, not just collected.

Getting this right turns AWS Config from a per-region curiosity into a genuine, account-wide compliance backbone. That single pane of glass is what lets you answer "is anything misconfigured anywhere in our environment right now?" without trusting that nobody ever launched something in a region you forgot about.