What AWS Config actually costs (2026)

AWS Config bills per configuration item recorded, and a configuration item is not a resource. It is a change. Which means the bill scales with how much your environment moves, not how big it is, and an autoscaling group can generate more billable items than a data centre.

What does AWS Config charge for?

Three meters. Per the AWS Config pricing page, "you are charged based on the number of configuration items recorded, the number of active AWS Config rule evaluations, and the number of conformance pack evaluations in your account."

Note there is no per-resource, per-account or per-Region charge, and no hourly charge. A completely static account with Config enabled costs almost nothing. A busy one costs in proportion to its churn.

What counts as a configuration item?

More than you would guess, and this is the sentence that explains most unexpected Config bills. AWS defines a configuration item as "a record of the configuration state of a resource in your AWS account", then adds:

As a result, even when no new resources are created (such as when a security group is attached to an Amazon Elastic Compute Cloud [EC2] instance), a configuration item can be recorded.

Attaching a security group creates no resource and records a configuration item. So does detaching one, changing a tag, modifying an instance attribute, or any relationship change between two recorded resources. A single deployment that touches fifty instances can record several hundred items.

The pattern that produces the largest numbers in practice is anything that cycles instances. Autoscaling, spot replacement, managed node group upgrades, and rolling deploys all create and destroy resources continuously, and every step records items for the resource and for everything related to it. A cluster that replaces nodes hourly is a Config cost centre, and nothing about the cluster looks expensive.

How do you reduce it without turning Config off?

Four levers, in the order we would apply them.

1. Narrow what the recorder records. AWS lets you "record configuration changes for all supported resource types, or for only the supported resource types that are relevant to you", and the all-types setting is the one to check first. Excluding high-churn types you do not audit is the single largest reduction available, and it is a one-line change.
2. Stop recording global resources in every Region. IAM and other global resource types can be recorded once rather than in every enabled Region, a setting covered under setting up AWS Config with the console. One resource type ignores that choice: AWS notes AWS::RDS::GlobalCluster "is unique in that if you enable the recording of this resource in one Region, AWS Config will record configuration items (CIs) for this resource type in all your enabled Regions." Recording them everywhere multiplies identical items by your Region count.
3. Audit conformance packs by size. Each pack is billed per rule evaluation per resource, so a pack with 60 rules across 5,000 resources is 300,000 evaluations per evaluation cycle. Packs are easy to enable and easy to forget.
4. Check periodic versus change-triggered rules. A rule that evaluates on every change to a high-churn resource type costs far more than the same check on a 24-hour schedule, and for most compliance questions the schedule is sufficient.

The recorder's options are documented in selecting which resources AWS Config records, and the rule evaluation modes in evaluating resources with AWS Config rules. Conformance packs are covered in the conformance packs documentation.

What the recorder is currently set to, which is the first thing to look at:

aws configservice describe-configuration-recorders \
  --query 'ConfigurationRecorders[].recordingGroup'

aws configservice describe-config-rules \
  --query 'ConfigRules[].[ConfigRuleName,Source.Owner,Scope.ComplianceResourceTypes[0]]' \
  --output table

If allSupported is true and includeGlobalResourceTypes is true in more than one Region, both of the first two levers are available immediately.

Is Config worth it anyway?

Usually yes, and it is worth saying so plainly rather than treating this as pure waste. Config is the only AWS service that answers "what did this resource look like before the change", which it does through the configuration history it keeps, and it is the question every incident review opens with. It also underpins conformance packs, which is how most organisations demonstrate a control is continuously enforced rather than checked once.

The argument is not whether to run it. It is that the default configuration records everything everywhere, and the cost of that default is invisible until it is a line item. Config produces no rightsizing recommendation, appears in no optimisation console, and is absent from Cost Optimization Hub's supported resource list, so nothing will ever suggest you narrow the recorder.

Which Config meter is driving your bill?

Under its own service name, split by usage type so the three meters separate, and grouped by Region because the global-resource duplication shows up there:

aws ce get-cost-and-usage \
  --time-period Start=2026-07-01,End=2026-08-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost UsageQuantity \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --group-by Type=DIMENSION,Key=REGION \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["AWS Config"]}}'

Two readings to act on. If configuration items dominate, the recorder is too broad or something is cycling resources. If rule and conformance pack evaluations dominate, you have more rules than you are reading findings from.

The same Region-by-Region duplication applies to the other always-on governance services, and they compound: a Region enabled "just in case" carries Config, CloudTrail and GuardDuty at once. None of them appear large individually and none of them are covered by any recommendation engine. Auditing the set of enabled Regions is one decision that moves three bills.