<p>There are multiple AWS services that can help with this, and it depends really on your exact needs as to which would suit you best. Different features (and costs) apply to each.</p>

<p>CloudTrail has been mentioned, but the the first option that comes to mind for me given your question (and it's mentioned in a <a href="https://devops.stackexchange.com/questions/1160/how-to-track-changes-to-aws-settings#comment1969_1161">comment on @Evgeny's answer</a>) is the <a href="https://aws.amazon.com/config/" rel="noreferrer"><strong>AWS Config Service</strong></a>. It stores 'snapshots' of your AWS configuration at points in time (in an S3 bucket), but helpfully also sends any changes to an SNS topic. You can then deal with these however you like. For example, on a low traffic account I have these going straight into Slack; on a high traffic account I am tracking the <code>NumberOfMessagesPublished</code> metric on that SNS topic to notice if a larger number of changes are made than usual.</p>

<p>AWS Config also offers a 'rules' service; these are a bit more pricey than I would expect them to be but depending on your needs they could be useful. Just don't activate them all at once like I did when I was playing around... the month's charge for each rule applies right away. ;) (But you can use Config without using the rules - that is what I am doing at the moment).</p>

<p>There's also <a href="https://aws.amazon.com/premiumsupport/trustedadvisor/" rel="noreferrer"><strong>Trusted Advisor</strong></a>, which doesn't do what you asked for exactly but might be handy to perform certain checks against how engineers configure your infrastructure, such as whether anyone's left S3 buckets open. It's most useful with a Business level Support plan or above, as many of its checks are blocked otherwise.</p>

<p>Then there's third party tools like <a href="https://cloudcheckr.com/" rel="noreferrer"><strong>CloudCheckr</strong></a>, which combine aspects of AWS Cost Explorer, Trusted Advisor, Config, CloudTrail, CloudWatch, Inspector and GuardDuty. Useful if you want to get in really deep but save time configuring everything yourself.</p>

<p>Alternatively, you could manage your infrastructure using a tool such as <a href="https://www.terraform.io/" rel="noreferrer">Terraform</a> or <a href="https://aws.amazon.com/cloudformation/" rel="noreferrer">CloudFormation</a>, and mandate that all changes must be made through those. You can then commit your config files/templates to source control, and even test them against the live infrastructure in CI and fail the build if someone's made non-tracked changes. That way, your commit history becomes your audit log - but it does require your engineers to be disciplined!</p>

CC BY-SA 4.0
2018-06-17T03:22:42.343Z
2018-06-17T03:22:42.343Z
Tim Malone
<p>AWS has the CloudTrail service that tracks most of the API calls done in your account. Then stores these in files in your specified S3 bucket. </p>

<p><a href="https://aws.amazon.com/cloudtrail/" rel="noreferrer">https://aws.amazon.com/cloudtrail/</a></p>

<p>Using CloudTrail you can see who, or which service, called which change - in many cases also including which arguments were used.</p>

<p>Unfortunately it doesn't support ALL services at the moment.</p>

CC BY-SA 3.0
2017-05-14T17:22:22.940Z
This answer should probably also mention [AWS Config](https://aws.amazon.com/config/).
Michael - sqlbot
CC BY-SA 3.0
2017-05-15T09:31:52.077Z
@Michael-sqlbot You are right.  Pl add it as an answer yourself. :)
Dawny33
CC BY-SA 3.0
2017-05-15T09:48:20.443Z
AWS Config is not an audit log. It is a system that enables to react to events as they happen. So it's more like a firewall than a firewall audit log. And it's actually very pricey compared to the almost free CloudTrail.
Evgeny Zislis
CC BY-SA 3.0
2017-05-14T14:47:33.233Z
2017-05-14T14:47:33.233Z
Evgeny Zislis
<p>Is there a way to track changes we make to the AWS system?</p>

<p>For example, changes to a subnet setting, from using <em>nat</em> to <em>iwg</em> - these display a message, and then disappear.</p>

<p>Is there a way to get AWS to create a log so that one can track which changes were made to what and when? </p>

<p>The closest thing we have now is the ElasticBeanstalk events - but even that only tells you what AWS did, not which settings were changed to cause the events.</p>

<amazon-web-services>
How to track changes to AWS settings?
Danny Schoemann
# How to track changes to AWS settings?

(Asked by: username_0 on 2017-05-14)

Is there a way to track changes we make to the AWS system?

For example, changes to a subnet setting, from using *nat* to *iwg* - these display a message, and then disappear.

Is there a way to get AWS to create a log so that one can track which changes were made to what and when?

The closest thing we have now is the ElasticBeanstalk events - but even that only tells you what AWS did, not which settings were changed to cause the events.

**Tags:** amazon-web-services


---

## 2 answers

### Answer by username_2 on 2017-05-14. Score: 12

AWS has the CloudTrail service that tracks most of the API calls done in your account. Then stores these in files in your specified S3 bucket.

<https://aws.amazon.com/cloudtrail/>

Using CloudTrail you can see who, or which service, called which change - in many cases also including which arguments were used.

Unfortunately it doesn't support ALL services at the moment.

> **Comments:**
> **username_3**: This answer should probably also mention [AWS Config](https://aws.amazon.com/config/).  
> **username_4**: @Michael-sqlbot You are right.  Pl add it as an answer yourself. :)  
> **username_2**: AWS Config is not an audit log. It is a system that enables to react to events as they happen. So it's more like a firewall than a firewall audit log. And it's actually very pricey compared to the almost free CloudTrail.  

---

### Answer by username_1 on 2018-06-17. Score: 6

There are multiple AWS services that can help with this, and it depends really on your exact needs as to which would suit you best. Different features (and costs) apply to each.

CloudTrail has been mentioned, but the the first option that comes to mind for me given your question (and it's mentioned in a [comment on @Evgeny's answer](https://devops.stackexchange.com/questions/1160/how-to-track-changes-to-aws-settings#comment1969_1161)) is the [**AWS Config Service**](https://aws.amazon.com/config/). It stores 'snapshots' of your AWS configuration at points in time (in an S3 bucket), but helpfully also sends any changes to an SNS topic. You can then deal with these however you like. For example, on a low traffic account I have these going straight into Slack; on a high traffic account I am tracking the `NumberOfMessagesPublished` metric on that SNS topic to notice if a larger number of changes are made than usual.

AWS Config also offers a 'rules' service; these are a bit more pricey than I would expect them to be but depending on your needs they could be useful. Just don't activate them all at once like I did when I was playing around... the month's charge for each rule applies right away. ;) (But you can use Config without using the rules - that is what I am doing at the moment).

There's also [**Trusted Advisor**](https://aws.amazon.com/premiumsupport/trustedadvisor/), which doesn't do what you asked for exactly but might be handy to perform certain checks against how engineers configure your infrastructure, such as whether anyone's left S3 buckets open. It's most useful with a Business level Support plan or above, as many of its checks are blocked otherwise.

Then there's third party tools like [**CloudCheckr**](https://cloudcheckr.com/), which combine aspects of AWS Cost Explorer, Trusted Advisor, Config, CloudTrail, CloudWatch, Inspector and GuardDuty. Useful if you want to get in really deep but save time configuring everything yourself.

Alternatively, you could manage your infrastructure using a tool such as [Terraform](https://www.terraform.io/) or [CloudFormation](https://aws.amazon.com/cloudformation/), and mandate that all changes must be made through those. You can then commit your config files/templates to source control, and even test them against the live infrastructure in CI and fail the build if someone's made non-tracked changes. That way, your commit history becomes your audit log - but it does require your engineers to be disciplined!


---

