Oliver Berger | Tue, 19 Aug 2019
A lot of AWS users and DevOps engineers ask us:
What’s the difference between AWS Config and AWS CloudTrail? Why should I choose one over the other?
A good way to think of it is that Config will tell you what your resource state is now or what it was at a specific point in the past whereas CloudTrail will tell you when specific events in the form of API calls have taken place.
AWS CloudTrail is a service that records every event inside your AWS environment via the console, SDKs, CLIs & other means and then stores them in an S3 bucket for inspection later.
There are a number of other ways that CloudTrail events can be leveraged. For example, you can inspect them via the CloudTrail Console or you can use a product like GorillaStack’s Real Time Events to get alerted and trigger remediation by triggering a Lambda from that CloudTrail event.
If you’re working with a particularly large dataset and want to take a look back over a significant period of time, you may wish to consider using AWS Athena to query your CloudTrail events.
AWS Config Rules allow organizations to determine a number of standards for which they would like their configurations to comply. Those rules can be set as Managed Rules which come out of the box as best practice presets or as Custom Rules which you can make yourself but require a lot of tinkering.
The rules, which in the case of Custom Rules operate as Lambda functions, can be run periodically and/or every time a relevant resource changes. If a compliance status changes, a notification will be sent to your SNS topic.
At the time of writing there are a handful of configurations you can check with Managed Config Rules including essentials such as IAM Policy configuration, S3 Bucket configuration, EC2 compliance and more. This should stand you in good stead to monitor the fundamentals of your infrastructure but is fairly limited for more complex environments. If you’d like to monitor anything deeper than the essentials, you’ll need to set up Custom Config Rules.
If the services that you want to stay abreast of are not covered by Managed Rules, you can always write and deploy your own Custom Rules for AWS config. These require you to write you own Lambda functions and the code can be fairly involved if you want to write a number of these at scale. There are AWS Config examples out there though which you can deploy or further customize for your own needs.
Sorry to be boring but the answer is that you ought to use both. Config Rules will trigger on a change in the status of your environment, but that may not happen immediately and will often only give you an update on the state itself (if for example a number of events have lead to that state change). They’re extremely important for telling you when your organization was in compliance and when it fell out of compliance so you can identify gaps in time that were at risk.
On the other hand, CloudTrail is a log of every event so it can tell you the kinds of things that took place and help identify all the causes that may have lead to a security event in the first place. What’s more, if you’re monitoring them carefully, using GorillaStack’s Real Time Events for example, you can know about and remediate the most important CloudTrail security events in real time.