How to Find, Validate and Remove those Unnecessary CloudTrails

Since we last spoke you may have had a look at your AWS bill and seen that you do, in fact, have some extra Cloud Trails in your accounts and they are costing you money. But fear not, we will find them together and check if you actually need them.

Firstly, I do highly recommend that you have a CloudTrail in all your accounts. It is great for audits, logging and keeping track of what’s going on and when the first CloudTrail is given free, you might as well. If you have an Organisation setup for your accounts you can create an Organisation level CloudTrail instead of having an individual one in each account. This enables you to log all data across all accounts to one centralised location, simplifying any security monitoring. See here for how to do this.

Now with that covered let’s see what else you have going on. With this script, using the CloudTrail option, you can loop through the accounts in your organisation and see what non-organisational trails you have (aka ones costing you money). The script provides the account, name of trail, logging bucket, and if it is an event trail or not. Event trails provide insights into the resource (“data plane”) operations performed on, or within, the resource itself. Data events are often high-volume activities and include operations such as Amazon S3 object level APIs and AWS Lambda functions invoke APIs. These always cost money even if it is the only one in the account but – be careful- they may be needed for a specific reason.

So, run the script and let’s see what you find!

Removal

If you are like me and you found a number of additional trails then here are some steps to validate them before you delete.

Checklist before removal:

1. Is the trail your Organisation one? It will appear similar to below

2. Is the trail an events trail? It is NOT if there is an option to configure it, see below. 

3. If it is an event trail, do you need it? Validate with whatever it is pointing at and make an assessment (this is upon your own assessment)

4. If it is a simple management trail do any Cloud Watch Alarms look to this Trail? Check by seeing if a Log Group is configured, if as shown below no alarms use it and you can skip to the deleting section

5. If it is configured it will look similar to below and we will need to point them to the single trail you do want to keep in this account

Validate the cloud watch group and if it is uses alerting from the below section

Validate the Alerting:

1. Go to CloudTrails and find the log group, seen in Point 5

2. Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.

3. In the navigation pane, choose the log.

4. In the list of log groups, select the log group that you created for CloudTrail log events.

5. Choose Create Metric Filter.

6. Evaluate if this is pointing at an alarm or something that is required

(This validation is something that is personal to your account. If the alerting is needed I would move the metric to a group that looks at your main trail).

If you can delete the trail do the following:

1. Make Note of the S3 bucket it places logs to, if you don’t do this and delete the trail you won’t be able to check the bucket name to remove it.

2. Check if the trail is part of a deployment of infrastructure a code. If so delete it in your code so it doesn’t come back otherwise delete manually.

And that’s about it.

This is just a rough guidance for finding and evaluating your trails and is personal to your accounts.

However, I hope that you find this useful and even if it saves you a couple of dollars a month, at least you can treat yourself to a guilty-free coffee.