AWS CloudTrail is a crucial governance and auditing tool for any company operating in the cloud. At its core, this service records all activity in your AWS environments in the form of CloudTrail Events, which are specific API requests that can originate from:
- Individual users, moving around the AWS Management Console and reviewing or changing things.
- Other AWS services, as varied as EC2 instance creation due to an automatic EC2 Auto Scaling event, scheduled Fargate tasks running in an ECS cluster, or a new log stream being created in CloudWatch due to a recent Lambda function execution.
- Programmatic access using CLI and SDKs from any location in the world.
Tracking these events has countless benefits:
- Easily audit your account activity since it provides a centralized collection of logs you can view, search, analyze, and use for incident response.
- Satisfy regulatory compliance requirements by allowing you to store account activity for many years.
- Optimize your security and access management controls by applying permission restrictions based on usage evidence.
- Improve your operational excellence by allowing you to track account changes and their impact on your business workloads.
For all these reasons, it is fundamental to understand and know how to leverage this service. And that is why we will cover its main characteristics and explore some relevant use cases in this article.
A plethora of integrations
What kind of activity does it record? That is a fair question to ask. AWS CloudTrail is capable of recording API calls to several AWS services. So many of them that it is easier to list unsupported services:
- AWS Import/Export.
- Amazon VPC endpoint policy-specific events.
This means that CloudTrail will include requests made to API endpoints from Amazon EC2, API Gateway, CloudWatch, S3, and Secrets Manager, among many others. You can get a detailed list of all the services supported in the AWS CloudTrail user guide.
Besides being able to log events from all those services, plenty of AWS services use CloudTrail records under the hood to provide you with several useful features. Here are some of these benefits, only to name a few:
- Trigger Amazon EventBridge events whenever specific API calls occur.
- Organize multi-account activity records using AWS Organizations.
- Understand resource modifications by linking CloudTrail events from the AWS Config dashboard.
- Investigate security incidents through the Amazon Detective integration.
But how does CloudTrail work? And how can I use it for my governance and auditing purposes? We will now learn about the workflow and concepts that make up this essential tool.
Of events, trails, and lakes
Let’s start by taking a look at the service dashboard in the AWS Console. If you go there, you will immediately encounter a list of events already recorded by the service.
CloudTrail dashboard in the AWS Console
Events: Types and Anatomy
We already covered the definition of an Event as the record of a specific AWS API call received by your account, stored in JSON format. There are three types of events: management, data, and insights.
| Management Events | Data Events | Insights Events |
|---|---|---|
| These are API calls performed on the resources in your Account. These are the ones you see by default in your CloudTrail dashboard. You will need to monitor these events if your aim is auditing specific actions executed in your account. | These are data plane operations performed on or within AWS resources. Examples: uploads to an S3 bucket, item updates inside a DynamoDB table, and activity on Cognito Identity Pools, among many others. These are high-volume events, so recording them might increase your costs, as we will see later in this article. | These are events generated by CloudTrail whenever unusual activity is detected in your account, like an increase in the volume of specific API calls or a sudden peak in error rates within your account’s management events. These can help you identify and respond to potential incidents that require your attention. |
For example, a CreateLogStream management event would look like this:
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AssumedRole",
"principalId": "somePrincipalId",
"arn": "arn:aws:sts::123456789012:assumed-role/someAssumedRole",
"accountId": "123456789012",
"accessKeyId": "someAccessKeyId",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "somePrincipalId",
"arn": "arn:aws:iam::123456789012:role/someRole",
"accountId": "123456789012",
"userName": "someUserName"
},
"webIdFederationData": {},
"attributes": {
"creationDate": "2023-06-28T20:35:16Z",
"mfaAuthenticated": "false"
}
}
},
"eventTime": "2023-06-28T20:35:23Z",
"eventSource": "logs.amazonaws.com",
"eventName": "CreateLogStream",
"awsRegion": "us-east-1",
"sourceIPAddress": "34.228.254.90",
"userAgent": "awslambda-worker/1.0 rusoto/0.48.0 rust/1.69.0 linux",
"requestParameters": {
"logGroupName": "/some/LogGroup/Name",
"logStreamName": "/some/LogStream/Name"
},
"responseElements": null,
"requestID": "12345678-ffff-aaaa-0000-111122223333",
"eventID": "12345678-ffff-aaaa-0000-111122223333",
"readOnly": false,
"eventType": "AwsApiCall",
"apiVersion": "20140328",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.2",
"cipherSuite": "ECDHE-RSA-AES128-GCM-SHA256",
"clientProvidedHostHeader": "logs.us-east-1.amazonaws.com"
}
}
Besides showing you which API call was actually executed (the Event Name), it gives you all sorts of details regarding who **is executing the API call (the userIdentity field), the parameters of the call (requestParameters field), the response (responseElements, in this case empty), and many otspecific values about the overall context and conditions of the request. Notice also tthe eventCategory** field specifies the type of event.
Here’s another example, this time for an Insights event:
{
"version": "0",
"id": "01234567-0123-0123-0123-012345678901",
"detail-type": "AWS Insight via CloudTrail",
"source": "aws.cloudtrail",
"account": "123456789012",
"time": "2019-11-15T20:16:00Z",
"region": "us-east-1",
"resources": [],
"detail": {
"eventVersion": "1.07",
"eventTime": "2019-11-15T20:16:00Z",
"awsRegion": "us-east-1",
"eventID": "01234567-89ab-cdef-1234-0123456789ab",
"eventType": "AwsCloudTrailInsight",
"recipientAccountId": "123456789012",
"sharedEventID": "12345678-ffff-aaaa-0000-111122223333",
"insightDetails": {
"state": "End",
"eventSource": "logs.amazonaws.com",
"eventName": "CreateLogStream",
"insightType": "ApiCallRateInsight",
"insightContext": {
"statistics": {
"baseline": {
"average": 0
},
"insight": {
"average": 2
},
"insightDuration": 1
}
}
},
"eventCategory": "Insight"
}
}
In this case, the insightDetails field contains the nature of the unusual activity (insightType, in this case ApiCallRateInsight), and the difference between the baseline and the measured value in the insightContext. Additional contextual information is also provided in other fields.
Trails
A collection of events that are captured together and delivered to a common destination (S3 bucket, CloudWatch Logs or Amazon Eventbridge) is called a Trail. By default, AWS provides you with an initial trail storing up to 90 days of management events. And yes, the events from the Dashboard home belong to this initial trail.
But you can also create your own trails from the Trails section in the CloudTrail dashboard, or using the AWS CLI. Upon creation, you can specify the following trail attributes:
- S3 bucket that will hold the event files
- Optional encryption configuration using a KMS key
- Whether to enable log digest files to validate the integrity of the files
- SNS notification for every log file creation
- CloudWatch Logs integration
- Tags for the trail resource
- And most importantly, the type of events to collect in the trail.
Trails can also be multi-Regional, single-Regional or organizational. AWS recommends always using multi-Regional trails for a comprehensive audit of your account, as well as organizational trails for multi-account workloads by integrating with the AWS Organizations offering.
Lakes
Since trail events can be delivered to S3 and CloudWatch Logs, you can leverage offerings like Amazon Athena or CloudWatch Logs metric filters to inspect and inspect your account’s activity. But you can also use CloudTrail Lake, a service that allows you to aggregate CloudTrail events into event data stores, and analyze them using SQL-based queries. This keeps you from implementing external data processing pipelines, as you can now process all audit information within one service. You can even add events from sources outside AWS, like Github, Okta, Snyk, or even your own on-premises applications.
Some Real World Applications
Monitor console login activity with CloudWatch Alarms
A classical example for CloudTrail usage is to monitor for login activity inside your AWS account. Imagine a user logs into the AWS Console. This will generate a Cloudtrail management event named ConsoleLogin. This event will contain useful contextual information about the incident, such as the user name, user agent, IP address, and even if MFA authentication was in place for the login.
In order to monitor this type of activity, you can create a trail that captures management events, sends them to an S3 bucket as well as CloudWatch Logs, and use CloudWatch Logs metric filters to look for events containing the ConsoleLogin name and create a custom metric. Using this metric, you can trigger a CloudWatch alarm with an SNS target to notify you whenever someone accesses the console.
Monitor suspicious account activity with Amazon Eventbridge
You can also use Amazon Eventbridge to automate responses to specific events captured by CloudTrail. Say for example that you have created a trail recording CloudTrail Insights events, and you wish to receive a Slack message whenever unusual activity is detected.
All you need to do is create an Eventbridge Rule having an AWS Cloudtrail event as source, and search for AWS Insight events. This would be the rule’s event pattern:
{
"source": ["aws.cloudtrail"],
"detail-type": ["AWS Insight via CloudTrail"]
}
Once a target action is configured and this rule is enabled, you will be able to automate your response.
CloudTrail Pricing
Now you know the benefits of using AWS CloudTrail in your accounts, but how much will it cost you? Like with most AWS services, you pay only for what you use.
You get your automatic first trail for free, recording 90 days of management events across your account. Should you create additional trails, there might be fees per event delivered to Amazon S3. Your first copy of management events are delivered for free, additional deliveries are charged USD$2.00 per 100,000 events. In the case of data events, there’s no free tier available, and you always pay USD$0.10 per 100,000 events.
If you enable CloudTrail Insights, you will be charged USD$0.35 per 100,000 events analyzed.
Essentially, your CloudTrail costs will depend on the amount of activity your account has, and on whether you’d like to measure it or not. You could get away monitoring management activity for free, but would have to increase your payments if you desire to create additional copies of the events, or start tracking data events.
Finally, for CloudTrail Lake, there’s a free trial period, valid until 30 days have passed or a 5 GB limit of ingested or scanned data is reached. After that, you have ingest and storage fee tiers ranging between USD$2.5 and USD$0.5 per GB depending on the amount of TB stored, and an additional scanning fee of $0.005 per GB of data analyzed.
You can find the latest information regarding CloudTrail pricing, as well as some useful examples, in the AWS CloudTrail Pricing page.
CloudTrail Best practices
Here are some useful recommendations when to help you secure your CloudTrail assets.
- Deliver all CloudTrail logs to a central S3 bucket with strong access control. Ideally in another AWS account, using a restrictive S3 resource policy.
- Prevent accidental loss of CloudTrail data by enabling versioning and MFA-delete on the S3 bucket.
- Encrypt your CloudTrail files enabling SSE-KMS encryption in your bucket.
- Always enable log file validation for your files, in order to prevent tampering.
Key Takeaways
AWS CloudTrail is a governance and auditing tool that records all activity in your AWS accounts, in the form of CloudTrail Events. By leveraging its integrations with AWS services like Eventbridge, CloudWatch, among many others, this service allows you to easily audit account activity, satisfy regulatory compliance requirements, automate security and access management controls, and improve your operational excellence.You can decide to record management events to keep track of your account activity as a whole, specific data events for monitoring changes to your data plane, or insights events for responding to unusual activity in your account.The costs of using this service will depend on the number of events recorded and analyzed. Finally, it is a security best practice to restrict access to your CloudTrail logs bucket, as well as protecting the availability and integrity of your event records.
