AWS Config Not Recording Global Resources: Why IAM Changes Slip Through

AWS Config is the service most teams lean on for tracking how their cloud resources change over time. It records configuration snapshots, builds a timeline of every modification, and lets you evaluate resources against compliance rules. But there is a subtle gap that trips up a lot of accounts: by default, a Config recorder only captures resources in the region where it runs. Global resources like IAM are a separate setting, and if you do not explicitly turn that on, the most security-sensitive changes in your account never make it into Config at all.

This check, account_configglobal, looks at your AWS Config recorder and verifies that it is set to record global resource types. If it is not, you have a blind spot in exactly the area you can least afford one.

---

What this check detects

AWS Config recorders have a setting called includeGlobalResourceTypes. When this is set to false (or left at its default in older setups), the recorder ignores resource types that are not tied to a specific region. The main category here is IAM: users, groups, roles, and managed policies.

The check fails when it finds a Config recorder in your account that has global resource recording disabled. The practical consequence is that creating an IAM user, attaching an admin policy to a role, or modifying a trust relationship produces no Config entry. You lose both the historical record and the ability to run Config rules against those resources.

---

Why it matters

IAM is the control plane for your entire AWS account. The difference between a contained incident and a full account takeover usually comes down to identity changes: a new access key here, a permissive policy there, a role trust extended to an external account. When those changes are not recorded, you are flying blind during the moments that matter most.

Consider a realistic scenario. An attacker compromises a developer's access key and uses it to create a new IAM user with AdministratorAccess, then quietly removes their original foothold. If your Config recorder is not capturing global resources, there is no Config timeline showing when that user appeared, what policies were attached, or who created it. You can sometimes reconstruct pieces from CloudTrail, but CloudTrail tells you about API calls, not the resulting configuration state over time. Config is what answers "what did this role's permissions look like last Tuesday?"

There are compliance angles too. Frameworks like CIS AWS Foundations, PCI DSS, and SOC 2 expect continuous configuration monitoring of IAM resources. Auditors regularly ask for evidence that identity changes are tracked. A Config recorder that excludes global resources will not satisfy those requirements, and it can turn an otherwise clean audit into a finding.

---

How to fix it

The fix is to update your Config recorder so it records all resource types including global ones. You can do this through the console, the CLI, or infrastructure as code.

Option 1: AWS CLI

First, find the name of your existing recorder:

aws configservice describe-configuration-recorders \
  --region us-east-1

This returns the recorder name and its current recordingGroup. To enable global resource recording while keeping everything else, update the recorder:

aws configservice put-configuration-recorder \
  --region us-east-1 \
  --configuration-recorder '{
    "name": "default",
    "roleARN": "arn:aws:iam::111122223333:role/aws-config-role",
    "recordingGroup": {
      "allSupported": true,
      "includeGlobalResourceTypes": true
    }
  }'

Replace the name, roleARN, and account ID with your own values. Setting allSupported to true records every supported resource type, and includeGlobalResourceTypes: true brings IAM into scope.

Confirm the recorder is also delivering to your S3 bucket and that it is running:

aws configservice start-configuration-recorder \
  --region us-east-1 \
  --configuration-recorder-name default

Option 2: AWS Console

1. Open the AWS Config console and switch to your primary region.
2. Go to Settings in the left navigation.
3. Under Recording method, choose Edit.
4. Select Record all resource types supported in this region.
5. Check Include global resources (e.g. AWS IAM resources).
6. Save your changes.

Option 3: Terraform

If you manage Config as code, set the recording group explicitly:

resource "aws_config_configuration_recorder" "main" {
  name     = "default"
  role_arn = aws_iam_role.config.arn

  recording_group {
    all_supported                 = true
    include_global_resource_types = true
  }
}

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

---

How to prevent it from happening again

Fixing one recorder is easy. Keeping the setting correct across every account and region as your organization grows is the real challenge. A few approaches that hold up over time:

Deploy Config through the organization, not per account

Use AWS Organizations with a delegated administrator for Config, or roll out recorders via CloudFormation StackSets. When the recording group is defined in one place and pushed to every account, there is no opportunity for an individual account to be set up without global resources.

Gate it in CI/CD with policy-as-code

If your Config recorders live in Terraform, add a check in your pipeline that fails the plan when include_global_resource_types is not enabled in your designated region. A small OPA/Conftest policy works well:

package config_recorder

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_config_configuration_recorder"
  rg := resource.change.after.recording_group[_]
  rg.all_supported == true
  rg.include_global_resource_types == false
  msg := "Config recorder must record global resources in the primary region"
}

Continuously monitor with Lensix

Drift happens. Someone edits a recorder by hand during an incident, a new account joins without the right baseline, or a Terraform import overwrites the setting. Lensix runs the account_configglobal check on a schedule across all your accounts, so a recorder that quietly loses global recording surfaces as a finding instead of waiting to be discovered during an audit or a breach.

---

Best practices

• Enable global recording in exactly one region. Pick your primary region and keep the flag off everywhere else to avoid duplicate configuration items and the cost that comes with them.
• Record all supported resource types. Unless you have a specific reason to scope down, allSupported: true gives you the broadest coverage and the fewest surprises.
• Pair Config with CloudTrail. Config tells you what the configuration looked like over time, CloudTrail tells you who made the call. You want both for IAM investigations.
• Set up Config rules for IAM. Once global resources are recorded, layer on rules like iam-user-no-policies-check and iam-password-policy so you catch risky identity configurations automatically.
• Aggregate findings. Use a Config aggregator or a central security account so identity changes across the whole organization land in one place your security team actually watches.

Recording global resources is a one-line change, but it closes a gap that sits directly over your account's most sensitive surface. Turn it on, enforce it in your pipeline, and let continuous monitoring catch any drift before someone else does.