AWS Config Not Enabled: Detection and Fix Guide

TL;DR

This check flags AWS regions where AWS Config is either disabled or not actively recording resource changes. Without it, you lose the audit trail that incident responders and compliance auditors rely on. Turn on a Config recorder with an S3 delivery channel in every region you use.

AWS Config is one of those services that does nothing visible day to day, then becomes the single most important tool you have the moment something goes wrong. It records the configuration of your AWS resources over time, tracks how they change, and lets you ask questions like "what did this security group look like three weeks ago?" or "who modified this IAM role and when?"

When this Lensix check fires, it means at least one region in your account has no active AWS Config recorder, or the recorder exists but is not recording. That gap is invisible until an auditor or an incident response team comes looking for history that simply was never captured.

What this check detects

The account_configrules check inspects each AWS region in your account and verifies two things:

A configuration recorder exists in the region.
That recorder is in the recording state and has a working delivery channel pointing at an S3 bucket.

If either condition fails, the region is flagged. A recorder that was created but later stopped counts as a failure, because a paused recorder captures nothing while it sits idle.

Note: AWS Config is a regional service. Enabling it in us-east-1 does nothing for eu-west-1. Each region needs its own recorder, which is why many accounts have partial coverage without realizing it.

Why it matters

Config is your configuration history. Lose it and you lose the ability to reconstruct what happened during an incident or prove compliance during an audit. A few concrete scenarios make the risk obvious.

Incident response goes blind

Say an attacker compromises a set of credentials, opens a security group to 0.0.0.0/0 on port 22, exfiltrates data, then reverts the change to cover their tracks. Without Config recording, the security group looks normal when your team investigates. With Config, you have a timestamped record of the open rule and exactly when it appeared and disappeared.

Compliance frameworks require it

Config recording is a baseline expectation in CIS AWS Foundations Benchmark, PCI DSS, SOC 2, HIPAA, and most internal security policies. The CIS benchmark specifically calls for Config to be enabled in all regions. An auditor who finds it disabled in even one region will write you up for it.

Config rules and conformance packs stop working

Many automated guardrails depend on Config under the hood. AWS Config Rules, Security Hub controls, and conformance packs all evaluate against the configuration data Config records. If recording is off, those rules either fail to evaluate or report misleading results, which means your other detective controls quietly degrade.

Warning: AWS Config bills per configuration item recorded and per active Config rule evaluation. In a busy region with frequent changes, costs can add up. This is real, but it is small relative to the cost of a breach you cannot investigate. Use recording exclusions for noisy, low-value resource types if you need to control spend.

How to fix it

You need three things in each region: an IAM role Config can assume, an S3 bucket for delivery, and the recorder itself. Here is the full setup using the AWS CLI.

1. Create the S3 bucket for Config snapshots

REGION="us-east-1"
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
BUCKET="config-bucket-${ACCOUNT_ID}-${REGION}"

aws s3api create-bucket \
  --bucket "$BUCKET" \
  --region "$REGION"

Apply a bucket policy that lets the Config service write to it:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AWSConfigBucketPermissionsCheck",
      "Effect": "Allow",
      "Principal": { "Service": "config.amazonaws.com" },
      "Action": "s3:GetBucketAcl",
      "Resource": "arn:aws:s3:::config-bucket-ACCOUNT_ID-REGION"
    },
    {
      "Sid": "AWSConfigBucketDelivery",
      "Effect": "Allow",
      "Principal": { "Service": "config.amazonaws.com" },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::config-bucket-ACCOUNT_ID-REGION/AWSLogs/ACCOUNT_ID/Config/*",
      "Condition": {
        "StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control" }
      }
    }
  ]
}

2. Set up the IAM service-linked role

AWS provides a managed policy for this. The simplest path is the service-linked role:

aws iam create-service-linked-role \
  --aws-service-name config.amazonaws.com 2>/dev/null || true

3. Create and start the recorder

# Create the configuration recorder
aws configservice put-configuration-recorder \
  --configuration-recorder \
    name=default,roleARN=arn:aws:iam::${ACCOUNT_ID}:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig \
  --recording-group allSupported=true,includeGlobalResourceTypes=true \
  --region "$REGION"

# Point it at the S3 bucket
aws configservice put-delivery-channel \
  --delivery-channel \
    name=default,s3BucketName=${BUCKET} \
  --region "$REGION"

# Turn recording on
aws configservice start-configuration-recorder \
  --configuration-recorder-name default \
  --region "$REGION"

Note: Set includeGlobalResourceTypes=true in only one region. Global resources like IAM users and roles are recorded once, and enabling it everywhere duplicates those configuration items and inflates your bill.

Verify it is recording

aws configservice describe-configuration-recorder-status \
  --region "$REGION" \
  --query 'ConfigurationRecordersStatus[0].recording'

A return value of true means you are good.

How to prevent it from coming back

Manually clicking through every region is how you end up with gaps in the first place. Bake Config enforcement into your provisioning and your guardrails.

Use Terraform for repeatable setup

resource "aws_config_configuration_recorder" "this" {
  name     = "default"
  role_arn = aws_iam_service_linked_role.config.arn

  recording_group {
    all_supported                 = true
    include_global_resource_types = true
  }
}

resource "aws_config_delivery_channel" "this" {
  name           = "default"
  s3_bucket_name = aws_s3_bucket.config.id
  depends_on     = [aws_config_configuration_recorder.this]
}

resource "aws_config_configuration_recorder_status" "this" {
  name       = aws_config_configuration_recorder.this.name
  is_enabled = true
  depends_on = [aws_config_delivery_channel.this]
}

Enforce it org-wide with AWS Organizations

If you run multiple accounts, do not configure Config one account at a time. Use an organization aggregator and deploy recorders through AWS Control Tower or an organization conformance pack so every new account inherits the setup automatically.

Tip: AWS Organizations supports a delegated administrator for Config. Designate a security account, deploy an organization-wide conformance pack, and you get a single pane of glass for recording status across every account and region without touching each one.

Gate it in CI/CD

Add a policy-as-code check to your pipeline that fails the build if a Terraform plan removes or disables a Config recorder. Tools like OPA, Checkov, or tfsec can catch this before merge. And let Lensix run continuous scans so a recorder that gets stopped after deployment surfaces within minutes rather than at audit time.

Danger: Never run stop-configuration-recorder or delete a Config recorder in production to save money without a replacement plan. Any window where recording is off is a permanent hole in your history that cannot be backfilled. You will not get that data back.

Best practices

Enable Config in every region you use, plus a few you do not. Recording in unused regions is cheap and catches resources an attacker might spin up where you are not looking.
Centralize delivery. Aggregate all regional and account data into a single security account using a Config aggregator for unified querying.
Lock down the S3 bucket. Enable versioning, block public access, and apply a lifecycle policy to move old snapshots to cheaper storage. Encrypt the bucket with KMS.
Layer on Config Rules. Recording alone is passive. Add managed rules like restricted-ssh and s3-bucket-public-read-prohibited to turn the data into active alerts.
Set retention deliberately. Config retains configuration items for seven years by default. Align retention with your compliance requirements rather than leaving it on the default.
Monitor the recorder itself. A recorder can fail silently if its IAM role or bucket policy breaks. Alert on the recording status, not just on whether the recorder exists.

Config is quiet infrastructure that earns its keep the day you need to answer a hard question under pressure. Turn it on everywhere, keep it running, and let automation make sure it stays that way.

AWS Config Not Enabled: Why It Matters and How to Fix It