Tracking New AWS Resource Types With AWS Config

This is particularly useful when different teams manage different AWS services.

Check Your Existing Configuration Recorder

The AWS CLI makes it possible to inspect the configuration recorder without opening the AWS Management Console.

Start by listing the configuration recorders:

aws configservice describe-configuration-recorders \
  --region ap-south-1

The response includes the recorder configuration and its recording group.

Next, check whether the recorder is running:

aws configservice describe-configuration-recorder-status \
  --region ap-south-1

A recorder that is configured correctly but not running will not provide the expected recording coverage.

You should also inspect the recording strategy and resource types.

For a recorder using an inclusion strategy, review the resourceTypes list carefully. For an all-supported or exclusion strategy, inspect the corresponding recording configuration and exclusions.

Remember that the configuration recorder is regional. Repeat these checks for every Region where your organization expects AWS Config coverage.

Build a Python Script to Identify Missing Resource Types

Let's create a small Python script using Boto3.

The purpose is straightforward: compare a list of resource types that your organization expects to record against the current recorder configuration.

This example focuses on the inclusion strategy because it is the strategy where manually maintained resource lists can easily become outdated.

First, install Boto3:

pip install boto3

Create a Python file named check_config_resource_types.py.

import boto3

REGION = "ap-south-1"

EXPECTED_RESOURCE_TYPES = {
    "AWS::EC2::Instance",
    "AWS::S3::Bucket",
    "AWS::RDS::DBInstance",
    "AWS::Bedrock::KnowledgeBase",
    "AWS::SageMaker::Endpoint",
    "AWS::Organizations::Policy"
}

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

response = client.describe_configuration_recorders()

if not response["ConfigurationRecorders"]:
    print("No AWS Config recorder found.")
    raise SystemExit(1)

for recorder in response["ConfigurationRecorders"]:
    name = recorder["name"]
    group = recorder.get("recordingGroup", {})

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

    if strategy_type is None:
        strategy_type = (
            "ALL_SUPPORTED_RESOURCE_TYPES"
            if group.get("allSupported", False)
            else "INCLUSION_BY_RESOURCE_TYPES"
        )

    print(f"\nRecorder: {name}")
    print(f"Strategy: {strategy_type}")

    if strategy_type == "INCLUSION_BY_RESOURCE_TYPES":
        configured_types = set(group.get("resourceTypes", []))

        missing_types = (
            EXPECTED_RESOURCE_TYPES - configured_types
        )

        if missing_types:
            print("Resource types missing from recorder:")

            for resource_type in sorted(missing_types):
                print(f" - {resource_type}")
        else:
            print("All expected resource types are configured.")

    elif strategy_type == "ALL_SUPPORTED_RESOURCE_TYPES":
        print(
            "All supported resource types are selected, "
            "subject to exclusions and regional availability."
        )

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

        excluded_types = set(exclusions)

        missing_types = EXPECTED_RESOURCE_TYPES & excluded_types

        if missing_types:
            print("Expected resource types explicitly excluded:")

            for resource_type in sorted(missing_types):
                print(f" - {resource_type}")
        else:
            print("No expected resource types are excluded.")

The script performs the following checks:

1. Connects to AWS Config in the selected Region.

2. Retrieves the existing configuration recorders.

3. Reads the recording strategy.

4. Compares expected resource types with the inclusion list.

5. Identifies expected resource types that are explicitly excluded.

6. Reports the result for each recorder.

The example uses a manually maintained expected-resource list. It does not automatically discover every newly supported AWS Config resource type. You can update this list as part of your monthly review process.

It also does not prove that a resource type is available in the selected Region or that a particular resource instance exists. Those checks should be part of a broader coverage assessment.

Understand Regional Availability and Global Resources

One common mistake is assuming that AWS Config supports every resource type in every Region.

AWS maintains a separate resource coverage by Region reference. Check it before adding a resource type to a regional recording configuration.

Global resources also need special attention.

For example, IAM users, groups, roles, and customer-managed policies have specific recording limitations depending on the Region and when AWS Config became available there.

Some global resource types are recorded only in their designated home Region.

Aurora global clusters are a special case: AWS Config can record AWS::RDS::GlobalCluster in all supported Regions where the customer-managed configuration recorder is enabled.

Therefore, a resource type missing from one Region does not automatically mean that your recorder is misconfigured. It might be a regional or global-resource limitation.

Common Mistakes to Avoid

Assuming all new resource types are automatically recorded

This is true for the all-supported and exclusion strategies, subject to the relevant resource and Region limitations. It is not true for an inclusion strategy.

Checking only the AWS Config console

A recorder can exist but be stopped. Always verify its status in addition to its configuration.

Ignoring excluded resource types

An exclusion strategy provides broad coverage, but an explicitly excluded resource type will not be recorded by that recorder.

Treating recording support as complete compliance coverage

Recording a resource does not automatically make it compliant. You still need suitable AWS Config rules, evaluations, and remediation processes.

Ignoring recording activity and cost

Adding more resource types can increase the number of configuration items and rule evaluations. Review the impact before changing recording coverage across a large organization.

Best Practices for Tracking New Resource Types

A practical approach is to make resource-type tracking part of your regular cloud governance process.

• Review the AWS Config supported resource types page monthly.

• Subscribe to AWS announcements relevant to your infrastructure.

• Maintain an internal list of resource types that must be monitored.

• Prefer all-supported recording when broad coverage is appropriate for your organization.

• Use exclusions deliberately and document why each resource type is excluded.

• Validate recorder status across all required Regions.

• Check global-resource recording limitations.

• Review AWS Config rules separately from recording coverage.

• Monitor recording costs and configuration activity after expanding coverage.

• Test recording changes in a non-production account before rolling them out widely.

For organizations using AWS Organizations, centralizing visibility through AWS Config aggregators can make it easier to review configuration data across multiple accounts and Regions. However, an aggregator does not replace the need to configure recording in the source accounts and Regions.

Summary

AWS Config support for resource types continues to expand, so a recording configuration that was sufficient when it was created might not meet your current monitoring requirements. The most important step is understanding your recording strategy. All-supported and exclusion-based strategies can automatically include newly supported resource types, while inclusion-based recording requires manual maintenance. Combine monthly documentation reviews, AWS announcements, recorder-status checks, regional availability checks, and automated validation to maintain reliable AWS Config coverage. This helps security, compliance, and operations teams maintain better visibility as their AWS environments evolve.