Recording AWS Resources with AWS Config - AWS Config
ConsiderationsRegional and global ResourcesAWS Config Rules and global resource typesRecording frequencyNon-recorded resources

Recording AWS Resources with AWS Config

AWS Config continuously detects when supported resource types are created, changed, or deleted. AWS Config records these events as configuration items (CIs).

You can customize AWS Config to record configuration changes for all supported resource types, or for only the supported resource types that are relevant to you. For a list of supported resource types that AWS Config can record, see Supported Resource Types for AWS Config.

Topics

Considerations

High Number of AWS Config Evaluations

You might notice increased activity in your account during your initial month recording with AWS Config when compared to subsequent months. During the initial bootstrapping process, AWS Config runs evaluations on all the resources in your account that you have selected for AWS Config to record.

If you are running ephemeral workloads, you may see increased activity from AWS Config as it records configuration changes associated with creating and deleting these temporary resources. An ephemeral workload is a temporary use of computing resources that are loaded and run when needed. Examples include Amazon Elastic Compute Cloud (Amazon EC2) Spot Instances, Amazon EMR jobs, and AWS Auto Scaling.

If you want to avoid the increased activity from running ephemeral workloads, you can set up the customer managed configuration recorder to exclude these resource types from being recorded, or run these types of workloads in a separate account with AWS Config turned off to avoid increased configuration recording and rule evaluations.

Region availability

Before specifying a resource type for AWS Config to track, check Resource Coverage by Region availability to see if the resource type is supported in the AWS Region where you set up AWS Config.

If a resource type is supported by AWS Config in at least one Region, you can enable the recording of that resource type in all Regions supported by AWS Config, even if the specified resource type is not supported in the AWS Region where you set up AWS Config.

What are the differences between Regional and global resources?

Regional resources

Regional resources are tied to a Region and can be used only in that Region. You create them in a specified AWS Region, and then they exist in that Region. To see or interact with those resources, you must direct your operations to that Region. For example, to create an Amazon EC2 instance with the AWS Management Console, you choose the AWS Region that you want to create the instance in. If you use the AWS Command Line Interface (AWS CLI) to create the instance, then you include the --region parameter. The AWS SDKs each have their own equivalent mechanism to specify the Region that the operation uses.

There are several reasons for using Regional resources. One reason is to ensure that the resources, and the service endpoints that you use to access them, are as close to the customer as possible. This improves performance by minimizing latency. Another reason is to provide an isolation boundary. This lets you create independent copies of resources in multiple Regions to distribute the load and improve scalability. At the same time, it isolates the resources from each other to improve availability.

If you specify a different AWS Region in the console or in an AWS CLI command, then you can no longer see or interact with the resources you could see in the previous Region.

When you look at the Amazon Resource Name (ARN) for a Regional resource, the Region that contains the resource is specified as the fourth field in the ARN. For example, an Amazon EC2 instance is a Regional resource. The following is an example of an ARN for a Amazon EC2 instance that exists in the us-east-1 Region.

arn:aws:ec2:us-east-1:123456789012:instance/i-0a6f30921424d3eee
Global resources

Some AWS services resources are global resources, meaning that you can use the resource from anywhere. You don't specify an AWS Region in a global service's console. To access a global resource, you don't specify a --region parameter when using the service's AWS CLI and AWS SDK operations.

Global resources support cases where it is critical that only one instance of a particular resource can exist at a time. In these scenarios, replication or synchronization between copies in different Regions is not adequate. Having to access a single global endpoint, with the possible increase in latency, is considered acceptable to ensure that any changes are instantaneously visible to consumers of the resource.

For example, Amazon Aurora global clusters (AWS::RDS::GlobalCluster) are global resources, and therefore not tied to a Region. This means that you can create a global cluster without relying on a regional endpoint. The benefit is that, while the Amazon Relational Database Service (Amazon RDS) itself is organized by Regions, the specific Region where a global cluster originates doesn't impact the global cluster. It appears as a single, continuous global cluster across all Regions.

The Amazon Resource Name (ARN) for a global resource doesn't include a Region. The fourth field is empty, such as in the following example of an ARN for a global cluster.

arn:aws:rds::123456789012:global-cluster:test-global-cluster
Important

Global resource types onboarded to AWS Config after February 2022 will only be recorded in the service's home Region for the commercial partition and AWS GovCloud (US-West) for the GovCloud partition. You can view the configuration items (CIs) for these new global resource types only in their home Region and AWS GovCloud (US-West).

Global resource types onboarded before February 2022 (AWS::IAM::Group, AWS::IAM::Policy, AWS::IAM::Role, and AWS::IAM::User) remain unchanged. You can enable the recording of these global IAM resources in all Regions where AWS Config was supported before February 2022. These global IAM resources cannot be recorded in Regions supported by AWS Config after February 2022.

Global resource types | IAM resources

The following IAM resource types are global resources: IAM users, groups, roles, and customer managed policies. These resource types can be recorded by AWS Config in Regions where AWS Config was available before February 2022. This list where you cannot record the global IAM resource types includes the following Regions: Asia Pacific (Hyderabad), Asia Pacific (Malaysia), Asia Pacific (Melbourne), Canada West (Calgary), Europe (Spain), Europe (Zurich), Israel (Tel Aviv), and Middle East (UAE).

To prevent duplicate configuration items (CIs), you should consider only recording the global IAM resource types one time in one of the supported Regions. This can also help you avoid unneccessary evaluations and API throttling.

Global resource types | Home Region Only

Global resources for the following services are only recorded by AWS Config in the home Region of the global resource type: Amazon Elastic Container Registry Public, AWS Global Accelerator, Amazon Route 53, Amazon CloudFront, and AWS WAF. For these global resources, the same instance of the resource type can be used in multiple AWS Regions, but the configuration items (CIs) are only recorded in the home Region for the commercial partition or AWS GovCloud (US-West) for the AWS GovCloud (US) partition.

Home Regions for Global Resource Types
AWS Service Resource Type Value Home Region
Amazon Elastic Container Registry Public AWS::ECR::PublicRepository US East (N. Virginia) Region
AWS Global Accelerator AWS::GlobalAccelerator::Listener US West (Oregon) Region
AWS::GlobalAccelerator::EndpointGroup US West (Oregon) Region
AWS::GlobalAccelerator::Accelerator US West (Oregon) Region
Amazon Route 53 AWS::Route53::HostedZone US East (N. Virginia) Region
AWS::Route53::HealthCheck US East (N. Virginia) Region
Amazon CloudFront AWS::CloudFront::Distribution US East (N. Virginia) Region
AWS WAF AWS::WAFv2::WebACL US East (N. Virginia) Region
Global resource types | Aurora global clusters

AWS::RDS::GlobalCluster is a global resource that is recorded in all supported AWS Config Regions where the customer managed configuration recorder is enabled. This global resource type is unique in that if you enable the recording of this resource in one Region, AWS Config will record configuration items (CIs) for this resource type in all your enabled Regions.

If you do not want to record AWS::RDS::GlobalCluster in all enabled Regions, use one of the following recording strategies for the AWS Config console:

  • Record all resource types with customizable overrides, choose "AWS RDS GlobalCluster", and choose the override "Exclude from recording"

  • Record specific resource types.

If you do not want to record AWS::RDS::GlobalCluster in all enabled Regions, use one of the following recording strategies for the API/CLI:

  • Record all current and future resource types with exclusions (EXCLUSION_BY_RESOURCE_TYPES)

  • Record specific resource types (INCLUSION_BY_RESOURCE_TYPES).

AWS Config Rules and global resource types

The global IAM resource types onboarded before February 2022 (AWS::IAM::Group, AWS::IAM::Policy, AWS::IAM::Role, and AWS::IAM::User) can only be recorded by AWS Config in Regions where AWS Config was available before February 2022. These global IAM resource types cannot be recorded in Regions supported by AWS Config after February 2022. For a list of those Regions, see Recording AWS Resources | Global Resources.

If you record a global IAM resource type in at least one Region, periodic rules that report compliance on the global IAM resource type will run evaluations in all Regions where the periodic rule is added, even if you have not enabled the recording of the global IAM resource type in the Region where the periodic rule was added.

Best Practices for reporting compliance on global resources onboarded before February 2022

To avoid unnecessary evaluations, you should only deploy AWS Config rules and conformance packs that have these global resources in scope to one of the supported Regions. For a list of which managed rules are supported in which Regions, see List of AWS Config Managed Rules by Region Availability. This applies to AWS Config rules, organizational AWS Config rules, and also rules created by other AWS services, such as AWS Security Hub and AWS Control Tower.

If you are not recording global resource types onboarded before February 2022, it is recommended that you do not enable the following periodic rules to avoid unnecessary evaluations:

Best Practices for reporting compliance on global resources onboarded after February 2022

Global resource types onboarded to AWS Config recording after February 2022 will be recorded only in the service's home Region for the commercial partition and AWS GovCloud (US-West) for the AWS GovCloud (US) partition. You should deploy AWS Config rules and conformance packs that have these global resources in scope only to the resource type's home Region. For more information, see Home Regions for Global Resource Types.

Recording frequency for AWS Config

AWS Config supports Continuous recording and Daily recording. Continuous recording allows you to record configuration changes continuously whenever a change occurs. Daily recording allows you to receive a configuration item (CI) representing the most recent state of your resources over the last 24-hour period, only if it’s different from the previous CI recorded. For steps on how to change the recording frequency, see Changing Recording Frequency.

Continuous recording

Some benefits of continuous recording include:

  • Real-time Monitoring: Continuous recording can provide immediate detection for unauthorized changes or unexpected alterations, which can enhance your security and compliance efforts.

  • Detailed Analysis: Continuous recording can allow you to perfom in-depth analysis of configuration changes to your resources as they occur, which can allow you to identify patterns and trends in the moment.

Daily recording

Some benefits of daily recording include:

  • Minimal Disruption: Daily recording can provide you with a more mangeable flow of information, which can reduce the frequency of notifications and alert fatigue.

  • Cost Efficiency: Daily recording can provide you with the flexibility to record changes to your resources at at a lower frequency, which can reduce costs related to the number of configuration changes recorded.

Note

AWS Firewall Manager depends on continuous recording to monitor your resources. If you are using Firewall Manager, it is recommended that you set the recording frequency to Continuous.

Non-recorded resources

If a resource is not recorded, AWS Config captures only the creation and deletion of that resource, and no other details, at no cost to you. When a non-recorded resource is created or deleted, AWS Config sends a notification, and it displays the event on the resource details page. The details page for a non-recorded resource provides null values for most configuration details, and it does not provide information about relationships and configuration changes.

Note

The AWS::IAM::User, AWS::IAM::Policy, AWS::IAM::Group, AWS::IAM::Role resource types will only capture the creation (ResourceNotRecorded) and deletion (ResourceDeletedNotRecorded) states if the resource is, or previously was, selected as a resource to record in the customer managed configuration recorder .

Note

The configuration items (CIs) for ResourceNotRecorded and ResourceDeletedNotRecorded do not follow the typical recording time for resource types. These resource types are only recorded during the periodic baselining process for the customer managed configuration recorder , which is at a less frequent cadance than that for the other resource types.

Note

For service-linked configuration recorders, the recording scope determines if you receive configuration items (CIs) in the delivery channel. The recording scope is set by the service that is linked to the configuration recorder. If the recording scope is internal, you will not receive CIs in the delivery channel.

The relationship information that AWS Config provides for recorded resources is not limited because of missing data for non-recorded resources. If a recorded resource is related to a non-recorded resource, that relationship is provided in the details page of the recorded resource.