AWS Config tracks configuration changes across your AWS resources and AWS Organizations. AWS Config uses the configuration recorder to detect changes and records them as configuration items (CIs). As your infrastructure grows and becomes more complex, choosing the appropriate recording frequency becomes critical for maintaining operational visibility, meeting compliance requirements, and supporting your security posture.

Since the launch of the periodic recording feature in 2023, you now have two recording options. The first option is continuous recording that captures every configuration change as it occurs, providing real-time visibility into your environment. The second option is periodic recording that captures a resource’s most recent state every 24 hours, but only if it differs from the last recorded state. Periodic recording can reduce the total amount of CIs in busy environments. Each approach serves different operational needs and choosing the optimal recording frequency helps you maintain the right level of visibility for your specific use-cases.

This post helps you to understand how to evaluate your environment and choose recording frequencies that best align with your operational, security, and compliance objectives. We explore decision frameworks and common scenarios when implementing AWS Config. We then introduce best practices that can help you optimize resource inventory along with compliance reporting and costs. Additionally, with these best practices, you can apply proactive controls to achieve governance at scale and achieve operational agility.

Understanding Your AWS Config Requirements

AWS Config helps you track changes in your environment to serve four main purposes, each with different recording frequency requirements.

• Resource inventory management
• Compliance-as-code for compliance evaluation
• Streamline operational and security investigations
• Continuous audit

Your recording frequency decision should align with how you use AWS Config across these purposes. Different workloads may have varying requirements. Real-time compliance monitoring and security incident response typically require continuous recording. Resource inventory and operational troubleshooting may function effectively with periodic recording, depending on your change patterns and response time requirements. When you use AWS Config, you track changes in your environment that matter the most for your use-case. You can then act on these changes by creating remediation rules, alerts, and analyses to prepare for future changes. Understanding these distinctions helps you implement granular recording strategies that match your operational needs.

Environment Characteristics

Your AWS environment’s characteristics significantly influence the optimal recording frequency. Dynamic environments contain ephemeral resources that automatically scale using services like AWS Lambda, Amazon EKS and Amazon EMR. These resources frequently change state based on workloads, schedules, or development and deployment patterns. Static environments contain more permanent resources using services like Amazon RDS and Amazon VPC. These resources are expected to stay and remain consistent over time due to network or data needs. Long-running resources that change infrequently may generate similar CI counts under both recording modes, making continuous recording preferable for complete visibility.

Consider these examples as we explore decision framework for recording frequency:

• Scenario A: In a development environment, your team deploys and terminates short tasks using Amazon EMR and Amazon EC2 Spot Instances. Each task runs for less than an hour before termination. You release your spot instance and terminate the EMR cluster after each job, and you make several modifications.
• Scenario B: In a production environment, your cluster and tasks run for at least 24 hours before terminating and you make few modifications to the cluster or task settings.

Successful recording frequency selection requires evaluating three key factors alongside your primary use-case:

• Resource staticity
• Relationships
• Baseline change frequency

Resource staticity

Resource staticity analysis involves understanding when and how your resource change state. Comparing CI counts between recording modes allows you to quantify data generation differences and optimize resource tracking. In environments with short-lived resources like scenario A, continuous recording captures start, termination, and related changes for complete operational visibility. Periodic recording doesn’t capture transient state changes for resources that start and stop within 24 hours, potentially creating gaps in your operational understanding. For a static environment with resources running longer than 24 hours like scenario B, continuous recording still provides complete operational visibility. And periodic recording captures state transitions across 2 days. AWS Config will capture start and termination for resources that stay for more than 24 hours in either recording.

Relationships

Consider Amazon EMR environment and components listed in DescribeCluster API action. When you create an EMR cluster, many interactions take place. As some examples:

• Amazon EC2 instances are attached
• On an Amazon VPC
• Leverages an IAM Profile
• Attaches EBS Volume
• Attached to AWS Systems Manager to patch EC2 instance
• Triggering AWS Config rules

This means one change can create multiple CIs in related resources. If you use indirect relationship, a change to EC2 Instance can result in 4 CIs:

• Security Group
• Subnet
• VPC
• EC2 instance

In the case of Systems Manager managed instance, periodic recording still records at least 2 CIs, start and stop, unlike unmanaged instances, producing additional CIs. And this is before AWS Config Rules for compliance checks, which is another relationship.

Understanding these relationships between AWS services that you may have in your environments are important to define the right recording frequency for the right resources.

Baseline Change Frequency

When you stop or override recording settings, you change recording frequency per resource type. And because AWS Config pricing for the recorder is per CI delivered per AWS account per AWS Region, you need to understand the frequency of change for each resource type to determine whether changing the frequency makes sense.

Consider Amazon EMR or Amazon EKS. Creating a cluster is 1 CI, and terminating a cluster is 1 CI. At the time of publishing, the cost of continuous recording is $0.003 per CI delivered, and periodic recording is $0.012 per CI delivered. With scenario B, an ephemeral EC2 instance runs for more than 24 hours, like the cluster. For periodic recording to be more cost-effective, you need 3 other CIs every two days when an instance starts and stops, if those days do not align with when the cluster starts and stops. Changes like instance type modifications or tag updates usually don’t happen often enough to reduce your overall CI count.

Analysis

To understand the differences between periodic and continuous recording, you start with continuous recording and observe the CI count over time. Next, you switch to periodic recording for specific resources and compare CI counts. Review How do I retrieve the number of configuration items that AWS Config records each month? for examples on how to query for your CIs.

Following table summarizes the daily CIs for all resources comparing continuous and periodic recording, simulating scenario A

Table 1: the daily CIs for all resources comparing continuous and periodic recording, simulating scenario A

Following table summarizes the daily CIs for all resources using continuous recording and difference with periodic recording for EC2 types, simulating scenario B

Table 2: the daily CIs for all resources using continuous recording and difference with periodic recording for EC2 types, simulating scenario B

The goal of the analysis is to find resource types with more than 4 daily CIs in continuous recording and greater than 75% reduction in total CIs generated in periodic recording. In Table 1, EC2 instances show 90% fewer CIs with periodic recording, but NetworkInterface only saved 34% and Volume saved 30%. In Table 2, EC2::SubnetRouteTableAssociation, KMS::Key, EC2::NatGateway, KMS::Alias, Events::Rule, and ECS::Cluster didn’t have more than 4 CIs and resulted in zero CIs with periodic recording.

As a result, incorporating the three key factors we discussed earlier, we can determine that Table 1 resulted in an overall AWS Config cost increase due to NetworkInterface and Volume, while Table 2 resulted in overall AWS Config cost savings.

We will now discuss the four common use cases of the AWS Config recording feature.

Use Case 1: Resource inventory management

Maintaining an accurate inventory of AWS resources requires selecting the appropriate configuration tracking approach in AWS Config. You can optimize your resource management strategy by understanding how periodic and continuous recording modes impact cost, efficiency, security, and operational visibility. You also need to understand how AWS is already taking an inventory on your behalf using relationships. With AWS Config, you are taking an inventory of all relationships in a centralized area, and thus, it’s important to understand which relationships you value tracking and identify where there may be duplicative inventories.

Based on the analysis of the EMR task flow example, you may be inclined to turn on periodic recording for one resource type to start, say EC2 Instance. However, as discussed in the Relationship section above, you need to analyze other resources. In the case of scenario A, AWS Config will still record at least start and stop events associated with Systems Manager (unlike EC2 Instance type), and EBS Volume associated with instances. To continue recording software inventory changes on EC2 Instance, you need to record ManagedInstanceInventory. The following graph demonstrates the CI increases and decreases across many services for starting EMR clusters.

Best Practice: Evaluate whether you need tracking from multiple services (EC2, Systems Manager) based on your environment’s requirements.

Use Case 2: Compliance-as-code for compliance evaluation

Organizations subject to regulations like HIPAA (Health Insurance Portability and Accountability Act), GDPR (General Data Protection Regulation), or PCI DSS (Payment Card Industry Data Security Standard) commonly implement compliance-as-code frameworks using AWS Config. This approach automates compliance monitoring by defining rules as code, enabling consistent, scalable compliance checks across AWS environments. For production, you may implement continuous recording to maintain detailed audit trails and real-time visibility into configuration changes affecting PHI-processing resources.

Based on the analysis of the EMR task flow example, you may notice AWS::Config::ResourceCompliance is having the largest CIs. It’s important to note that for accurate reporting on compliance status and to use AWS Config configuration timeline, you must record this resource type. Furthermore, as we discussed above, many AWS Config rules are triggered on changes and creates CI for ResourceCompliance. When working with AWS Config rules for compliance, align your strategy for rule trigger and recording frequency to maximize the benefit. You need to also evaluate the required resource types for the related AWS Config or AWS Security Hub controls.

Best Practice: Match your AWS Config rules and recording frequency to optimize both compliance reporting and costs.

Use Case 3: Streamline operational and security investigations

Maintaining an accurate representation of the resource state can streamline development practices by providing confident knowledge about your resources. You can also remediate issues and confirm their state faster. AWS Config rules help to act fast based on changes so you can be notified of unexpected events. The level of visibility and near real-time updates for changes are dependent on the environment and workflow. In lower development environments, you may only want to track resource changes that are available over 24 hours. In staging environments, you may want to track dependencies and relationships with other workloads but do not need to implement immediate remediation actions.

Based on the analysis above, the comparison of recording frequencies for long-running resources (Table 2) reveals daily anomalies in a lower, frequently changing environment. When creating Amazon EMR clusters, services like KMS, DynamoDB, and Events may emerge as critical dependencies in your infrastructure. Instead of choosing the resource type with the highest CIs, you need to evaluate the role for each environment, such as anomalies for lower, frequently changing environments, and relationship-based services for pre-production environments. The following graph demonstrates the CI increases and decreases, but more sporadically unlike Figure 2, to have more targeted effort in monitoring services based on operational needs.

Best Practice: Use multiple accounts to separate environment and workloads and adjust AWS Config recording strategy more granularly.

Use Case 4: Continuous audit and near real-Time detection

Many organizations are subject to internal processes and controls for standardization to operationalize teams. While compliance frameworks provide structured requirements, organizations can also implement additional or optional controls based on their specific security needs and risk tolerance. When you use AWS Config to continuously audit your controls, it’s important to categorize the impact and consider your deployment strategy. If you have development and deployment controls for runtime versions in your IDE or CI/CD pipeline, we recommend using those existing controls rather than duplicating efforts with AWS Config runtime evaluations. Similarly, if you have an event-based architecture to take action in near real-time, we recommend using continuous recording instead of periodic recording to ensure immediate detection and response to critical changes.

Based on the analysis above, the comparison of recording frequencies for long-running resources (Table 2) demonstrates the impact of ephemerality with AWS Lambda functions. If you create and destroy AWS Lambda functions on an ad-hoc basis, and you have controls in your IDE or CI/CD, continuous recording for internal audit purposes may create developer noise. You need to evaluate the impact for each of your internal controls and align your rules with the recording frequency so you’re not triggering rules every 8 hours when your recording is set for periodic every 24 hours.

Best Practice: Categorize environments by impact level, consider controls closer to the developer, and consider AWS Config to close the gaps.

Conclusion

The guidance and best practices outlined in this post help you make informed decisions about AWS Config recording frequencies that serve your specific operational needs. By understanding the three key factors alongside your primary use case, and applying them to your unique environment characteristics, you can optimize operational effectiveness while maintaining the configuration visibility your organization requires for successful cloud operations.

In this post, we explored how resource staticity, service relationships, baseline change frequency, and primary use case influence CI generation. We outlined the decision framework and best practices to help you evaluate these factors systematically through practical examples and analysis.

Corrections made:

The best practices that can help you make a decision for your organization include:

• Analyze your current CI patterns
• Identify and compare your resource relationships strategy to the existing relationship
• Match recording frequency to your needs
• Align rule evaluations with recording frequency
• Implement environment-specific requirements
• Consider account and environment separation

If you are interested in learning more about the steps to enable periodic recording, refer to How to record resource configuration changes periodically with AWS Config.