Context
AWS Config records supported resource configuration changes so teams can inspect history and evaluate rules. A resource missing from that history does not immediately prove the recorder stopped. Account scope, Region, resource support, recording strategy and delivery each influence what evidence appears. Trace these boundaries before recreating the recorder.
Define the expected configuration evidence
Record the resource ARN and type, owning account, Region, recorder identity and the approximate change time. Identify whether the resource is Regional or global. Obtain the current recording configuration and status along with delivery-channel status through read-only console or API access.
Keep a known supported test resource available for a harmless configuration change in a nonproduction environment. This provides fresh evidence without modifying a security control merely to generate an event.
1. Check recorder status and resource scope
Read describe-configuration-recorders and describe-configuration-recorder-status for the intended account and Region. A recorder existing is different from recording being true. Inspect the latest status and error information as well as the boolean.
Review whether the strategy records all supported types, includes selected types or excludes selected types. Compare the exact AWS resource type string with the relevant list. A resource created after an inclusion list was written may be outside scope by design.
2. Resolve global-resource placement explicitly
AWS Config has different recording rules for global resource families. Older global IAM types have particular Region support, newer global types may have a home Region, and Aurora global clusters have another documented behavior. Do not treat the global-service console view as proof that history will appear in whichever Region is currently selected.
Review the includeGlobalResourceTypes setting in the context of the selected strategy. AWS documents that exclusion-based recording needs explicit exclusions for global IAM types; the flag does not act as a universal off switch in that mode. Confirm the actual recorded scope before claiming a coverage or cost result.
3. Separate recording from delivery
| Evidence | Interpretation to test | Next check |
|---|---|---|
| Recorder exists but recording is false | Collection is stopped | Status reason and approved operating state |
| Only one resource family is absent | Scope or support limitation | Type and strategy |
| Global resource visible in another Region | Home-Region behavior | Current global-resource documentation |
| Resource history exists but bucket files do not | Delivery boundary | Delivery-channel status and permissions |
An explicitly illustrative scenario: an audit team expects Route 53 history in its application Region and finds no configuration items. The recorder is healthy. The owner checks the resource type's documented home Region and locates the expected evidence there, then updates the audit collection procedure. Restarting the application Region's recorder would not move that global-resource history.
Correct, verify and maintain coverage
Apply the smallest approved scope, status or delivery correction. Generate a controlled change on an in-scope test resource and verify a fresh configuration item with the expected timestamp. Check delivery independently if downstream evidence depends on S3 or SNS.
The SOP should map required resource families to accounts, Regions, recording strategies and evidence destinations. Monitor recorder and delivery status together, and review coverage when new resource types or accounts are introduced. Assign an owner to exceptions so “not recorded” remains an explicit decision rather than an unexplained gap in an audit report.
Explore Clouvenix cloud security for implementation and operational handover.
Technical reference
Recording-group semantics, global-resource placement, recorder verification, and delivery status explain the evidence path.