Finding AWS Resources That Your Config Rules Still Do Not Cover

{
  "totalDiscoveredResources": 125,
  "resourceCounts": [
    {
      "resourceType": "AWS::EC2::Instance",
      "count": 40
    },
    {
      "resourceType": "AWS::EC2::SecurityGroup",
      "count": 25
    },
    {
      "resourceType": "AWS::S3::Bucket",
      "count": 60
    }
  ]
}

The values are illustrative.

You can use this information to understand which resource types are currently represented in the Config inventory.

However, discovered-resource counts alone are not sufficient to prove that all resources are covered.

You must also compare the inventory with:

• Resource types actually deployed in the account.

• Resource types supported in the selected Region.

• Recorder inclusion and exclusion settings.

• Rule evaluation scope.

• Recording status and permissions.

A resource type that does not appear in the Config inventory may be unsupported, excluded, unavailable in the Region, or simply not present in the account.

Do not automatically classify every missing resource type as a configuration error.

Check Whether Existing Config Rules Cover the Resource Types

After reviewing recording settings, inspect the rules themselves.

An AWS Config rule has a scope that determines which resources trigger evaluation.

The scope can include:

• One or more resource types.

• A specific resource type and resource ID.

• A tag key and value.

• All recorded resources, depending on the rule configuration.

For example, a rule may be configured to evaluate only Amazon EC2 instances.

Even if AWS Config records S3 buckets, the EC2-specific rule will not evaluate those buckets.

You can inspect existing rules using:

aws configservice describe-config-rules \
    --region ap-south-1

The response includes information about each rule, including its scope and evaluation configuration.

To inspect compliance results, run:

aws configservice describe-compliance-by-config-rule \
    --region ap-south-1

This provides compliance information for the configured rules.

Remember that a rule showing COMPLIANT does not prove that every resource in the account is covered.

It only means that the resources evaluated by that rule currently satisfy its requirements.

A complete coverage assessment must compare the resource inventory against the intended security and compliance policies.

Build a Simple Coverage Audit

Now let's bring the information together.

A practical coverage audit should maintain a list of resource types that the organization expects to monitor.

For example:

{
  "requiredResourceTypes": [
    "AWS::EC2::Instance",
    "AWS::EC2::SecurityGroup",
    "AWS::S3::Bucket",
    "AWS::RDS::DBInstance",
    "AWS::Lambda::Function",
    "AWS::Bedrock::Guardrail"
  ]
}

This list is an organizational requirement, not a complete list of AWS-supported resource types.

The audit process should compare the required resource types with the recorder configuration and regional support information.

A simple classification can be:

This classification is more useful than simply reporting that a resource type is missing.

For example, an organization might intentionally exclude temporary development resources from recording. That should be documented as an approved exception rather than treated as an unexpected failure.

Use a Python Script to Inspect Recorder Settings

For organizations managing multiple AWS accounts and Regions, manually checking recorder configurations becomes difficult.

A small Python script using boto3 can retrieve the recorder configuration and identify whether a resource type is included.

Install boto3:

pip install boto3

Create a file named config_coverage.py:

import boto3

region = "ap-south-1"

required_resource_types = {
    "AWS::EC2::Instance",
    "AWS::EC2::SecurityGroup",
    "AWS::S3::Bucket",
    "AWS::RDS::DBInstance",
    "AWS::Lambda::Function",
    "AWS::Bedrock::Guardrail"
}

client = boto3.client(
    "config",
    region_name=region
)

response = client.describe_configuration_recorders()

if not response.get("ConfigurationRecorders"):
    print("No configuration recorder found.")
    raise SystemExit(1)

recorder = response["ConfigurationRecorders"][0]

group = recorder.get("recordingGroup", {})

strategy = group.get("recordingStrategy", {})

strategy_type = strategy.get("useOnly")

if strategy_type == "ALL_SUPPORTED_RESOURCE_TYPES":
    recorded_types = None

elif strategy_type == "EXCLUSION_BY_RESOURCE_TYPES":
    exclusions = set(
        group.get("exclusionByResourceTypes", {})
        .get("resourceTypes", [])
    )

    recorded_types = None

else:
    recorded_types = set(
        group.get("resourceTypes", [])
    )

    exclusions = set()

for resource_type in sorted(required_resource_types):

    if recorded_types is None:
        is_recorded = resource_type not in exclusions
    else:
        is_recorded = resource_type in recorded_types

    status = "RECORDED" if is_recorded else "NOT RECORDED"

    print(f"{resource_type}: {status}")

This script provides a basic comparison between required resource types and the recorder configuration.

It does not establish whether a resource type is actually supported in the selected Region, whether resources of that type exist, or whether a suitable Config rule evaluates them.

Those checks should be added as separate stages in a production coverage audit.

Also, when using a service-managed recorder or more advanced recording configurations, inspect the corresponding recorder scope and settings rather than assuming that the customer-managed recorder configuration represents every recording workflow.

Review the Latest AWS Config Resource Type Additions

AWS regularly expands Config coverage as new services and resource types become available.

Two recent announcements demonstrate why this review matters.

In September 2026, AWS announced support for 60 additional resource types across services including Amazon Bedrock, Amazon EC2, Amazon SageMaker, and AWS Organizations.

In October 2026, AWS announced another 77 resource types, including resources from Amazon S3 Files and Amazon Q Business.

Organizations using an inclusion-based recording strategy should review these additions to determine whether they need to update their recorder configuration.

Organizations recording all supported resource types can automatically receive coverage for newly supported resource types in eligible Regions, subject to their exclusions and recording configuration.

This is one reason why an all-supported strategy can reduce ongoing administrative work.

However, automatically recording a new resource type does not automatically create a security rule for it.

The organization must still determine what security and compliance requirements apply to the newly supported resource.

Use AWS Config Aggregators for Multi-Account Visibility

Large organizations rarely operate in one AWS account or Region.

They may have separate accounts for development, testing, production, security, and shared infrastructure.

An AWS Config aggregator provides a centralized view of configuration and compliance information from multiple accounts and Regions.

A typical architecture looks like this:

AWS Account A
  |
  v
AWS Config Recorder
  |
  v
AWS Config Rules
  |
  +------------------+
                     |
AWS Account B        |
  |                  |
  v                  |
AWS Config Recorder  |
  |                  |
  v                  |
AWS Config Rules     |
  |                  |
  +------------------+
                     |
                     v
              AWS Config
                Aggregator
                     |
                     v
             Centralized View
                     |
                     v
             Coverage Analysis

An aggregator helps security and compliance teams understand which accounts and Regions are contributing configuration data.

However, an aggregator does not automatically fix missing recording configurations.

If a resource type is not recorded in a source account, the aggregator cannot provide complete configuration details for that resource.

Therefore, central aggregation should be combined with account-level recorder audits.

Establish a Continuous Coverage Review Process

Resource coverage should not be checked only when AWS Config is initially enabled.

New AWS services, resource types, Regions, and compliance requirements continue to evolve.

A practical governance process should include:

• Reviewing AWS Config resource type announcements.

• Checking the supported resource types reference.

• Comparing recorder settings with organizational requirements.

• Reviewing excluded resource types.

• Verifying rule scopes.

• Checking recorder health and permissions.

• Reviewing coverage across accounts and Regions.

• Documenting unsupported resource types and approved exceptions.

You can automate parts of this process using scheduled Lambda functions, EventBridge, and centralized reporting.

For example, a scheduled audit can collect recorder configurations from every account and Region, compare them with an approved resource inventory, and publish a report containing missing resource types.

This provides security teams with an actionable view of monitoring gaps instead of requiring administrators to inspect every account manually.

Summary

Having AWS Config rules enabled does not guarantee complete infrastructure coverage.

The configuration recorder determines which resource types are recorded, while Config rules determine which recorded resources are evaluated. Both must be configured correctly to provide meaningful compliance visibility.

Start by reviewing supported resource types and regional availability. Inspect the configuration recorder, identify inclusion and exclusion settings, check discovered resources, and verify the scope of existing rules.

For organizations operating multiple AWS accounts, AWS Config aggregators provide centralized visibility, while automated audits can identify missing recording and evaluation coverage.

The most important lesson is that compliance coverage is not measured by the number of Config rules deployed. It is measured by whether the resources that matter to your organization are actually recorded, evaluated, and monitored.