Config.1 failing with CONFIG_RECORDER_CUSTOM_ROLE even though recorder uses AWSServiceRoleForConfig

Question

I set up Security Hub and AWS Config across my AWS Organization a few years ago using the AWS-provided StackSets. Everything has been running fine with no
changes on my end. Recently, Config.1 started failing in some accounts and regions (not all) with the following:

"Description": "The AWS Config recorder is using a custom IAM role instead of the AWS Config service-linked role."
"ReasonCode": "CONFIG_RECORDER_CUSTOM_ROLE"

Related requirements: CIS AWS Foundations Benchmark v1.2.0/2.5, CIS AWS Foundations Benchmark v1.4.0/3.5

When I check some of the failing accounts, the recorder appears to be using AWSServiceRoleForConfig with the AWSConfigServiceRolePolicy managed policy.

1. Did the Config.1 control evaluation criteria change recently to include the includeConfigServiceLinkedRoleCheck parameter?
2. Is it possible that the StackSets originally created a custom role with an identical name or similar permissions that is not actually the service-linked
role?
3. What is the recommended remediation path for an Organization with 50+ accounts — updating the recorder role via StackSets, or setting
includeConfigServiceLinkedRoleCheck to false?

Any clarity on when this check was introduced would be helpful, as my configuration has not changed.

Oscar D · Accepted Answer

Short answer: The Config.1 control got stricter. It now checks that your recorder uses the actual service-linked role (SLR), and this check didn't exist when
you set things up. Your config didn't change — the benchmark did.

What's likely happening with the role:

There's a subtle but important distinction. The real service-linked role has this ARN path:

arn:aws:iam:::role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig

The StackSets from a few years ago often created a custom IAM role via CloudFormation that looks identical (same name, same policies), but lives at a
different ARN path — something like:

arn:aws:iam:::role/AWSServiceRoleForConfig

Notice the missing /aws-service-role/config.amazonaws.com/ path. That's what the control is flagging. They look the same in the console, which is why you
think you're using the SLR — but technically you're not.

To confirm, run this in one of the failing accounts:

bash
aws configservice describe-configuration-recorders --region  --query 'ConfigurationRecorders[].roleARN'

If /aws-service-role/config.amazonaws.com/ is missing from the path, that's your answer.

Why only some accounts/regions? The StackSet may have deployed slightly differently across your org, or some accounts may have had the SLR created
separately later (e.g., if you ever used the Config console in that account, it would have created the real SLR).

Fixing it at scale (50+ accounts):

The cleanest fix is to update your StackSet to point the recorder at the real SLR. First ensure it exists in each account:

bash
aws iam create-service-linked-role --aws-service-name config.amazonaws.com

Then update the recorder:
bash
aws configservice put-configuration-recorder \
  --configuration-recorder name=default,roleARN=arn:aws:iam:::role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig

If you need a quick fix right now, set the Config.1 parameter includeConfigServiceLinkedRoleCheck to false in Security Hub. The control will still validate
that Config is enabled and recording — it just won't care about the role. That's perfectly reasonable if your current role has the right permissions.

Hope this clears things up. You did everything right when you set it up — AWS just moved the goalposts.

Config.1 failing with CONFIG_RECORDER_CUSTOM_ROLE even though recorder uses AWSServiceRoleForConfig

Add your answer

Relevant content