Accounts where the AWS Config recorder is switched off
What does ZopNight detect here?
ZopNight emits one config-recorder finding per AWS account, firing only when the discoverer confirms the recorder is disabled. Coverage is currently probed in us-east-1 alone, so multi-region accounts are judged from that 1 region: a deliberate, documented limit rather than a silent assumption about the other regions.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1520 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | config_recorder.go |
Where it applies
What you lose without the recorder
AWS Config is the service that remembers what your infrastructure looked like yesterday. With the recorder off there is no configuration timeline: when an incident review asks “when did this security group open port 22, and what else changed that day”, the honest answer becomes “we don’t know”. Config Rules, conformance packs, and drift detection all sit on top of the recorder. None of them function in an account where it never ran.
How the signal is produced
The discoverer emits a single synthetic config-recorder resource per account and stamps a
boolean config_recorder_enabled on it. The rule fires only when that flag is present and
false. If the flag is missing or unreadable (a failed probe, a permissions gap), the rule
abstains instead of declaring an unknown account non-compliant. An earlier version read a tag
that no producer ever wrote and therefore never fired at all; the current gate reads the field
the producer actually populates.
The single-region caveat, stated plainly
The probe currently runs against us-east-1 only, and one resource represents the whole account. CIS AWS Foundations treats Config as an all-regions control, so an account with the recorder on in us-east-1 but off everywhere else will pass this rule today. That accuracy bound lives in the producer, not the rule. The fail-closed gate is correct for whatever scope the probe reports, and widening coverage means aggregating recorder state across regions upstream, not loosening the check.
Verify from your terminal
aws configservice describe-configuration-recorder-status --region us-east-1 \ --query 'ConfigurationRecordersStatus[].[name,recording,lastStatus]' --output tableAn empty result means no recorder exists; recording: false means one exists but is stopped.
Turning it on without a billing surprise
Config bills per configuration item recorded, so the pragmatic setup is to record all resource types but check the estimate for high-churn accounts first. An account cycling hundreds of spot instances daily records a lot of items. Enable it once through the console or IaC, point snapshots at a versioned S3 bucket, and the finding clears at the next discovery pass. The recommendation itself carries no savings figure; the value is forensic, not financial.