Amazon CloudTrail records a history of all API calls that occur in your AWS account. Whether operations are performed using the AWS Management Console, AWS CLI, or any of the various SDKs, Amazon CloudTrail will record details about the API calls.
Recording of action data is important for the following reasons:
Amazon CloudTrail will record many details about the actions that are executed, including:
For example, if you created an EBS snapshot, “snap-12345678”, of an EBS volume using the AWS CLI:
aws cli create-snapshot –volume-id vol-12345678
then CloudTrail will record this with the following details:
By default, CloudTrail is disabled in all regions. It must be enabled in each region you want to enable it in.
Tip: You should enable CloudTrail in all regions, even regions that you are not intending to use. You cannot retroactively enable CloudTrail to diagnose past events. So enable CloudTrail before you need it.
To enable CloudTrail, navigate to the CloudTrail management console and add trails for all regions. For each trail, you can create a new S3 bucket or reuse an existing bucket. If you choose, you can store all CloudTrail data for all regions in the same bucket.
When AWS announces a new region, return to the CloudTrail management console and add a new trail for the new region.
Tip: Under “Advanced” options, CloudTrail asks you whether the log files should be encrypted (yes/no). However, even if you choose “no”, the log files will still be encrypted with S3’s Server-Side AES 256 encryption. If you say “yes”, then CloudTrail will use a KMS key to encrypt the data, which will cost you extra for using the KMS key. So the distinction is not whether to encrypt or not, but instead whether to use KMS keys or not.
You can use the AWS Management Console to view the logs. However, the AWS Management Console will only list actions that alter your AWS account, such as “Create”, “Modify”, “Delete” API calls. If you need to search or view any of the read-only calls, then you must traverse the data in Amazon S3 yourself, or use Amazon CloudWatch Logs.
The console allows you to filter results by the following fields:
For example, if you want to find all actions that occurred on an EC2 instance, then you can filter by resource name on the EC2 instance ID.
The “User name” column is a bit misleading. If you were using an IAM user (AWS Management Console or access keys), then that user’s user name will appear in this column. However, if an IAM role (third-party IAM role, EC2 instance profile, etc.) were used, then the role’s name is not shown. Instead, the Session ID used during the “sts:AssumeRole” is shown.
Tip: CloudTrail events take a little while to appear. You should allow up to 30 minutes from the time that the action was executed to the time that the events appear in the CloudTrail console.
There are also third-party tools that can examine, report on, and generate alerts for your CloudTrail trails. One such tool is CloudCheckr.
As I mentioned before, enable CloudTrail in all regions now, before you actually need it.
Skeddly includes full logs of all Skeddly actions that are executed. Using our logs, you can see all of the Amazon API actions that were executed as part of your Skeddly action.
You can also view all activity executed by Skeddly through CloudTrail as well.
If you are using an IAM role to allow Skeddly to act on your AWS account (which you should be using), then you will notice user names in CloudTrail that start with “skeddly-“. The rest of the user name is a unique sequence of characters used to group AWS actions together within the Skeddly action.
Currently, the CloudTrail console only allows exact matches when filtering by user names. We are hoping that AWS will add the ability to include partial matches of user names, which will make searching for Skeddly events easier.
For example, if you are using Skeddly to start and stop your EC2 instance, you will see “StartInstance” and “StopInstance” events in CloudTrail. For API actions associated with your Skeddly action, you will see the AWS credentials you gave to Skeddly for these events.
If you are noticing that your EC2 instance is starting or stopping outside of the desired Skeddly schedule, use CloudTrail to determine how this is happening. You can filter the CloudTrail events by resource name, using the EC2 instance ID of your EC2 instance. You’ll get a filtered list of events showing the credentials that started and/or stopped your EC2 instance. Here you should see what is operating on your EC2 instance aside from Skeddly.
CloudTrail is like insurance in that you need to plan ahead. If it’s not available when you need it, it won’t help you.
So plan ahead, enable CloudTrail now in all regions.
Skeddly is the leading scheduling service for your AWS account. Using Skeddly, you can: