AWS Config Pricing: The Bill That Surprises People, and Why

AWS Config charges for three things: configuration items recorded, rule evaluations, and conformance pack evaluations. The first one is where surprise bills come from, because it scales with how often your resources change rather than how many you have.

The reason this service generates confused threads is that its cost driver is not intuitive. Most AWS pricing scales with something you can picture - instance hours, gigabytes stored, requests served. Config scales with change events, and nobody has a mental model of how often their resources change.

Table of contents

• The three charges
• Where the volume comes from
• Finding out what you are actually paying for
• Reducing the bill without losing the point
• Whether you need it at all
• How this fits the rest of the stack
• FAQ

The three charges

Configuration items. A configuration item is a recorded snapshot of a resource’s state at a point in time. One is written every time a recorded resource is created, modified, or deleted. Continuous recording is charged at a low per-item rate, and periodic recording at a higher per-item rate - the periodic mode costs more per item because it records far fewer of them.

Rule evaluations. Each time a Config rule evaluates a resource, that is a billable evaluation. Rules can be triggered by configuration change or on a schedule, and the trigger type determines the volume.

Conformance pack evaluations. A conformance pack bundles many rules, and evaluations within it are charged per evaluation.

Individually the rates are small - fractions of a cent per item. The bill is a volume story, not a rate story, which is exactly why it surprises people. Nobody looks at a rate of a third of a cent and budgets for it.

# The arithmetic that catches people
# 1,000 configuration items x $0.003 = $3.00
# 1,000,000 configuration items x $0.003 = $3,000.00

Where the volume comes from

Four patterns generate configuration items at rates well above what people expect.

Auto-scaling. Every scale-out and scale-in event creates and destroys instances, network interfaces, and volumes, each producing configuration items. An account that scales aggressively through the day generates them continuously.

Ephemeral compute. Container tasks and serverless-adjacent resources that come and go produce items on every lifecycle transition. A batch workload spinning up hundreds of short-lived tasks can generate more items in an hour than a static fleet does in a week.

Automated tagging and remediation. Anything that modifies resources on a schedule creates a configuration item per modification. A nightly tagging job across a large account is a large, recurring, entirely self-inflicted charge.

Recording everything, everywhere. Config is enabled per region, and the default is to record all supported resource types. An organisation-wide enablement across every region, including ones with almost nothing in them, records relationship changes for resources nobody is monitoring.

That last one is the most common cause of a genuinely baffling bill: a region you forgot was enabled, quietly recording.

Finding out what you are actually paying for

Before changing anything, look at the data. Cost Explorer will break the charge down by usage type, which distinguishes configuration items from rule evaluations.

# Which regions have a recorder at all
for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  n=$(aws configservice describe-configuration-recorders --region $r \
      --query 'length(ConfigurationRecorders)' --output text 2>/dev/null)
  [ "$n" != "0" ] && [ -n "$n" ] && echo "$r: recorder present"
done

# What a given region is recording
aws configservice describe-configuration-recorders --region us-east-1

# Is it actually running
aws configservice describe-configuration-recorder-status --region us-east-1

# How many rules are in play
aws configservice describe-config-rules --region us-east-1 \
  --query 'length(ConfigRules)'

The region sweep is the highest-value thing here. Running it usually finds at least one region nobody knew was enabled, and turning that off is a pure saving with no downside.

On the rules side, look at which are change-triggered against resource types that change constantly. A rule evaluating a resource type that mutates hundreds of times a day is generating evaluations at that rate.

Reducing the bill without losing the point

The goal is not to disable Config - it exists because knowing your resource configuration history is genuinely valuable during an incident or an audit. The goal is to record what you need.

• Turn off recording in unused regions. The easiest saving, with essentially no trade-off.
• Record specific resource types rather than everything. If your compliance requirement covers storage, compute, and identity, record those rather than every supported type.
• Consider periodic recording for slow-changing resources. It costs more per item and produces far fewer items, which is a net saving for resources that rarely change. Continuous recording remains right where you need every change captured.
• Exclude high-churn resource types where the history is not useful to you. Network interfaces attached to auto-scaling instances are a common candidate.
• Review conformance packs. They are convenient and bundle a lot of rules, some of which you may not need. Individual rules cost less than a pack you use a fraction of.
• Reduce self-inflicted churn. If an automated job modifies resources nightly, each modification is billable. Sometimes the job is more expensive than the problem it solves.

Set a budget alert on the service specifically. Config bills grow gradually as an account grows, so the first sign is usually a month where the total looks wrong rather than a single obvious spike.

Whether you need it at all

Config answers questions like what did this resource look like last Tuesday, what changed just before the incident, and which resources currently violate a policy. Those are valuable questions in a large organisation with compliance obligations and many people making changes.

They are less valuable in a small account where three people know everything that runs and infrastructure is defined in code. If your entire infrastructure is in a repository and every change goes through a pull request, you already have a change history with better attribution than Config provides, and it is free.

The honest position: if a compliance framework requires it, you need it, and the exercise is scoping it sensibly. If nobody is requiring it and you enabled it because it seemed prudent, check whether anyone has ever looked at the data. Frequently nobody has, and it has been billing for two years.

The wider version of this question is worth asking about any cloud governance tooling. Managed platform services shift a lot of this concern: when the deployment platform holds the deploy history, the runtime logs, and the environment configuration, the questions Config answers about your application layer are already answered somewhere simpler. On RunxBuild, every deploy keeps its build log and runtime logs, environment variables live in the dashboard, and rolling back to the previous deploy is a button - which covers the practical version of what changed and when for the application, without a per-item charge.

How this fits the rest of the stack

Governance tooling is worth its cost when the environment is complex enough to need it, and worth re-examining when it is not. The RunxBuild hosting calculator shows the alternative shape plainly - a service, a managed database, storage, and bandwidth as fixed line items on plans you pick - so the comparison is between two known numbers rather than between a known number and a usage-based unknown.

Useful related references:

• GCP vs AWS: Pricing, Network, and When to Pick Each
• AWS vs GCP: Pricing, Network, and When to Pick Each
• Google Cloud vs AWS: Pricing, Networking, and When to Pick Each
• Services on RunxBuild

FAQ

How is AWS Config priced?

Three charges: per configuration item recorded, per rule evaluation, and per conformance pack evaluation. Continuous recording carries a low per-item rate; periodic recording costs more per item but produces far fewer of them. The rates are small, so the bill is driven by volume rather than price.

Why is my AWS Config bill so high?

Almost always configuration item volume. Auto-scaling, ephemeral container tasks, automated tagging jobs, and recording all resource types across every region each generate items continuously. A forgotten region with recording enabled is a common and easily fixed cause.

What is a configuration item in AWS Config?

A recorded snapshot of a resource’s state at a point in time. One is written whenever a recorded resource is created, modified, or deleted. Cost therefore scales with how often your resources change, not with how many resources you have.

How do I reduce AWS Config costs?

Disable recording in regions you do not use, record specific resource types rather than everything, use periodic recording for slow-changing resources, exclude high-churn types such as network interfaces on auto-scaling instances, and review whether conformance packs are pulling in rules you do not need.

Do I need AWS Config?

If a compliance framework requires it, yes, and the work is scoping it sensibly. If you enabled it because it seemed prudent, check whether anyone has ever looked at the data. In a small account with infrastructure defined in code, your repository already provides a change history with better attribution and no per-item charge.