Certified Security - Specialty

Sign Up Free or Log In to participate!

Be careful, AWS Config can be an *expensive* service

AWS Config is an excellent service, but can be expensive. I was doing some work with the service in a personal account and wasn’t watching the billing and ended up with a bill that was several hundred dollars. If you’re working with Config be aware of the billing and make sure you have the appropriate CloudWatch billing alarms set …. just sayin’. 😉


thanks for the heads up.

Andre Hiotis

You are definitely correct. I was playing around with Amazon Macie and that can be very expensive and the results were not very impressive.

7 Answers

Andy, how could you end up with several hundreds of USD for AWS config itself??

It’s charged on per rule basis ($2/month/rule) + $0.003 per configuration item recorder.



So to have i.e. $200 bill, you would need to have i.e. 10 rules ($20) + 60000 config items recorder (changes)… in a month.

I’m not saying it’s not possible, I’m just saying it’s quite a lot for a private account 🙂


I believe if you look at the way the service is billed, it’s $2 every time you activate a rule. If you’re doing custom rule development with Lambda, and you need to add/modify and then redeploy your code a number of times per day (and repeat the process on many days per month) it becomes very expensive very quickly, trust me. 🙂

I agree with Mariusz — this is confusing.   Is the AWS Config pricing page wrong / misleading?   The way it reads is that it should not charge you every time you activate a rule, but should charge you $2 per active rule per month, not $2 per evaluation.  See this:

With Config Rules, you are charged based on the number of active rules in your account. Each time an AWS resource is compared with a rule, the result is recorded as an evaluation result. You can choose to evaluate rules when AWS resources change or at periodic intervals like hourly or daily. A rule is active if it has one or more evaluations in a month.

Config Rules costs: $2 per active rule per month

Are you sure you didn’t have something wrong in Lambda that caused it to create many unique rules instead of re-evaluating existing rules?   I’m not saying I don’t believe what you are saying — I just want to understand it better.   Can you post your account’s billing from Config?


The key in the Config billing information is the following: ‘Config Rules costs: $2 per active rule per month’. Let’s say you’re developing a custom Config rule (i.e., a Lambda function): when you deploy the custom Lambda function/Config rule, it becomes an active Config rule and that’s a $2 charge. If you then undeploy the rule, update the code, and then redeploy it, I believe it’s another $2 charge because it then becomes (again) an active Config rule. I could be wrong, but I believe that every upload/deployment cycle of the custom Config rule is going to cost you $2. Do that several times a day for most of the month and it adds up. Unfortunately I was doing this work last year and I don’t have the billing records, but an inquiry to AWS would probably confirm it. All I’m saying to those who are doing similar kinds of work is be aware of the billing and set the alarms early. 🙂

Jay Owen

Oh, so this happened to you during development of the Lambda. Yeah, I can believe that scenario. Thanks for explaining that in detail.


Yes … and it was quite the shock, trust me. 🙂 That said, it’s not the typical Config user’s scenario to be sure.

For example, here’s current Config billing for my company account:

Config  $19.06

AWS Config ActiveConfigRules $18.00

    $2.00 per Active Config Rule in US East (N.Virginia) region   

           9 ActiveConfigRules   $18.00

AWS Config ConfigurationItemRecorded $1.06

    $0.003 per Configuration Item recorded in US East (N.Virginia) region   

           353 ConfigurationItemRecorded$1.06


If you’ve got a static Config deployment as you’re demonstrating I would expect it not to cost you much money; however if you’re doing custom Config rules that fire on every Config event (and there are thousands of events in a typical account’s startup/shutdown cycle) it adds up fast.


The points you and Mariusz have raised are well taken; I changed the title of the thread from is to can be. The context I used the service is was probably unique and wouldn’t be what most folks would encounter. I would simply be aware that, if you’re in the business of writing your own custom rules for Config, it can be expensive (or at least that was my experience).

Hi Andy, looking at the FAQ -> https://aws.amazon.com/config/faq/

It says

"If you are using AWS Config Rules, you will be charged based on active Config Rules in that month. When a rule is compared with an AWS resource, the result is recorded as an evaluation. An rule is active if it has one or more evaluations in a month."

I assume that when you create config rule, you have an asset to check against it, so this would trigger evaluation and record CI. So yes, now your example makes more sense to me. Probably it’s better to test lambdas outside of config rule service 😉

Thanks, that’s helpful for sure


Mariusz, I think the FAQ should more accurately read: "If you are using AWS Config Rules, you will be charged based on Config Rules that are active during any point within that month. …" To me that describes how the billing works more accurately than the way they currently have it stated. Yes, it’s probably better to test Lambdas outside of Config in general if you can, however if you’re specifically developing Config rules that makes that somewhat difficult depending on what you want your rules to do. 🙂

Sam T

Yes, so likely any change seemingly counts as new another $2

Hi, I see a charge to 9 config rules.. are there any disadvantages to me deleting these 9 rules? Are they absolutely needed during learning process.. (monthly bill of $18 for 9 rules :-))

Kumarvijay Walikar

You can delete, But expect first month bill of $18.. Once you create its counted as active Rule and will be billed. Config ‘s billing is not pro rata as other services.


TLDR; use Athena to query the Config data objects being stored in S3 to get true cost insights. This AWS blog post is a great starting point: https://aws.amazon.com/premiumsupport/knowledge-center/retrieve-aws-config-items-per-month/

This is a super important area to know if you’re working in an environment that deploys code multiple times per day/hour. I can’t stress enough how important it is to know this. Don’t just think about this topic in terms of passing AWS certification exams, think of it in terms of keeping the job you land. If you enable AWS Config on your first day without understanding the cost implications, your last day might be the end of the month when your organization gets the next bill.

One of the most important element of the AWS Config pricing model is the fact that configuration items are recorded/created whenever a resource undergoes a configuration change or a relationship change. This means every time you make a change to a resource you’re going to pay at least $0.003 (as of today’s pricing). For example, if you create a security group and attach it to multiple EC2 instances, you’re not just paying for the cost of creating the security group ($0.003) but also the cost of attaching it to the instances themselves (at $0.003 per attachment). The act of attaching the security group to the instance counts as a relationship change. Relationship changes are an often misunderstood AWS Config ‘sneaky’ cost that continues to accumulate behind the scenes because users are unaware that they’re being billed for every single change they make, even without creating new resources. See the AWS Config documentation for a list of supported resources their relationships: https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html

An application hosted in AWS doesn’t have to be large to rack up Config costs quickly; especially if you are working with autoscaling, automation, orchestration and/or CI/CD build processes in your AWS account. In these environments, the change relationships between VPC, subnet, security group, and autoscaling resources can easily accumulate thousands of Config changes for a single resource. We’re talking thousands of dollars a month in AWS Config costs alone. These costs can get large enough to make some smaller companies close their doors, and make larger companies seriously consider whether or not they want you managing resources in their cloud accounts.


Well stated and spot-on! 🙂


Thanks for pointing that out. I just enabled Config in 15 regions / 10 accounts, all recording global resources, because otherwise SecurityHub complains config isn’t properly enabled. That would mean every config change to a global resource costs $0.50 to record! I’ll have to reconfigure so only one account / region records the global changes, and you can disable security hub rules. AWS lists the rules you can disable https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-pcidss-to-disable.html


I still remember the first time I encountered this exact scenario. Getting Security Hub and Config to a point where they were both enabled and working well with each other transitioned from a simple ticket to a cost mitigation saga spanning a few weeks. We weren’t willing to sacrifice Security Hub insights or Config recording data so the solution required a combination of thinking outside the box and documentation deep dives. Below is an outline of the general workaround process. We used Athena to query historic Config items (see my link above) to determine which resource types were costing us the most. In our case, 2-3 resource types accounted for over 50% of the total number of changes, which had a synergistic effect that also inflated the number of AWS::Config::ResourceCompliance resource type changes. To work around this, it’s possible to enable Config recording for "All resources" (all supported resources + global resources) on the Config settings page via the console but revoke “describe” permissions from the Config IAM role itself by adding an explicit DENY for those resource types (e.g. ec2:DescribeXYZ) in an attached IAM policy. See https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html for the list of supported resource types. Before rolling this out, make sure you weigh the security risk of disabling recording for a specific resource type and determine if the value gained from keeping the recording data is justified by the associate Config cost. For example, Security Group recording can often be expensive due to change counts but disabling recording for these resources has a high impact on risk and Security Hub assessments, whereas disabling recording for something like AutoScaling Groups can often reduce costs by a significant amount without affecting Security Hub assessments because very few rules require AutoScaling Group visibility and their associated severities are often categorized as Low (which may not be worth spending thousands of dollars a month to keep). For a subset of resource types, there are very few associated Security Hub rules so disabling them can sometimes be a straightforward decision. Hope this helps.

I’ve had the AWS "free tier" for a while, but in the last week I’ve actually started developing a back end for an app (using just DynamoDB and API Gateway with Lambda functions) and storing it in CodeCommit;

I haven’t explicitly done anything with the "Config" service.

Yet my config costs jumped from 0 to about $10 a day during the last week when I’ve been coding the back end.  There are no users of the app beyond myself.  Since I haven’t used the Config service, what about my activities have caused this jump?

Does calling API Gateway somehow introduce "config" costs?  Do Git CodeCommit’s cause "config" costs?

If it costs $10 a day for this app to run when there are no users beyond myself, this will never scale.  Something doesn’t make sense here.

Sign In
Welcome Back!

Psst…this one if you’ve been moved to ACG!

Get Started
Who’s going to be learning?