The stated purpose of the AWS Config is that it “enables you to assess, audit, and evaluate the configurations of your AWS resources.” Let’s get right to it, in my opinion, AWS Config is not a service you should bother using. In theory, it’s supposed to act like a database to keep track of the historical metadata for the resources in an account, but it rarely lives up to peoples’ assumptions.
Lack of coverage
My biggest complaint with AWS Config is the lack of coverage it has over AWS services. In almost every AWS account there will be resources that it does not keep track of. You can see this table I use to track support for security things on AWS, and see that common services like API Gateway, Route53, and more are not supported by AWS Config. Even AWS’s oldest service, SQS, is not recorded. This isn’t full support for the services, but just any support whatsoever, which works out to about 19% of services.
The list of resources that AWS Config supports is here. There is no exhaustive list of all the types of resources that exist on AWS, but CloudFormation does support many resources on AWS, and so we can use that to help estimate what percentage of AWS resources AWS Config actually records. By comparing the resources that AWS Config supports (extracted as a list here) and the resources CloudFormation supports (extracted as a list here) we can see AWS Config only supports 20% (67/334) of the resources CloudFormation supports. These numbers are a little awkward to compare because AWS Config sometimes combines the resources CloudFormation uses into a single resource type, but CloudFormation also supports even more resources than I was able to count, as pointed out by Ian Mckay to me.
If you expected to have some sort of historical record about your account by using AWS Config, you will be sorely dissapointed the day you need to do Disaster Recovery work on your account to rebuild it. Ideally, you should be using Infrastructure as Code (IaC) for this purpose (ex. Terraform or CloudFormation), but even companies that use IaC heavily often have a few resources they setup once long ago and haven’t gotten around to adding to their IaC solution.
Other problems
AWS Config costs money, although not a lot at $0.003/resource/month. Where it does get expensive is if you start using AWS Config Rules. Those rules will cost you $2/rule/month/region with some bulk discounts. There are 82 managed AWS Config Rules (so not including ones you create yourself). If you turn all these on, it will cost you $112/month/region, or I believe $1,792/mo to monitor all regions for a single account.
Another problem with AWS Config is it is regional, like other services on AWS that shouldn’t be (looking at you GuardDuty!). This means you need to remember to turn it on in every region you work in.
Due at least in part to these problems, I don’t know of any tools that work with AWS Config to do anything useful with the data it has.
Update 2019.03.05: It was pointed out to me that AWS Config is also delayed by 15 minutes, so you can’t detect or respond to issues in real-time. You also will potentially miss situations where someone violates a rule and then fixes it before AWS Config detects it.
What should you use instead?
CloudTrail has much more coverage than AWS Config (although still doesn’t support some services or new API’s added to existing services). This also keeps a record of who made what changes and is generally much more useful for any type of incident response. CloudTrail logs are difficult to use though to piece together what the configuration of a resource was at a point in time.
There is not a solution I know of to record a complete snapshot of the metadata in an account. Many groups have attempted to create solutions for this due to the rate-limiting AWS enforces on you when you try to query the metadata of an account. CloudMapper’s collect provides a good starting point though for someone to add this functionality. See this post on CloudMapper to learn how to easily add new services to collect information about. CloudMapper already makes over 90 types of requests for information in an account across over 30 services (more than AWS Config), but again, it is hard to compare these types of requests to the resources AWS Config supports.
For the things that AWS Config Rules detect, you’d be better off using CloudWatch Events and streaming those to a solution such as StreamAlert or Cloud Custodian to detect things from them.
As mentioned earlier, ideally you should use Infrastructure as Code. If you were using IaC, a regular snaphsot with something like CloudMapper for the resources not in IaC, and monitoring on CloudWatch Events, I can’t think of a use case someone with have for AWS Config.
Most groups will quickly run into the limitations of AWS Config and have to tack on additional collection and monitoring to make up for it. If you go down that path, you then have to maintain expertise and tooling for these two separate systems (AWS Config plus something else), so in my opinion it’s better to just avoid AWS Config entirely and focus on something else. If AWS Config dramatically improved their coverage and dropped the price of AWS Config Rules, it could be a reasonable option, but as it exists now, it won’t fulfil most people’s assumptions about the service.