Hello and welcome to this lecture where I will explain the basic fundamentals of AWS CloudTrail giving you an overview of the service.

So what is CloudTrail and what does it do? AWS CloudTrail is a service that has a primary function to record and track events, such as AWS Application Programming Interface (API) requests made within your AWS account, in addition to non-API requests made.  These events can be programmatic requests initiated from a user using an SDK, the AWS command line interface, from within the AWS management console, or even from a request made by another AWS service.  For example, when EC2 auto-scaling is triggered to create a new EC2 instance, an API request is made by the service to launch the instance. These API requests are all recorded and tracked by CloudTrail.

As Events are a key part of CloudTrail, it’s worth explaining what Events are in a little more detail.  There are 3 types of events that CloudTrail categorizes and tracks, these being:

• Management Events

• Data Events

• CloudTrail Insight Events

The main type of events, which are recorded by default when working with CloudTrail are the Management Events (also known as control plane operations), which track information about management operations taken against your AWS resources running within your account.  For example, if you were to run the Amazon RDS CreateDBInstance API or the AWS IAM CreateUser API.  

Although the majority of the events captured are captured through API calls, some events are also captured that are classed as non-API events.  An example of this would be when an automatic key rotation of a KMS key is performed, or when a user has a successful sign into the AWS Management Console, or indeed an unsuccessful one.

Data Events (also known as data plane operations) are events that show information about resource operations that have been performed either on or in a resource.  For example Amazon S3 object-level API activity, including GetObject, DeleteObject, and PutObject API operations, or AWS EBS Snapshot operations, such as PutSnapshotBlock, GetSnapshotBlock, and ListChangedBlocks API operations.

Insight events allow you to capture events that are triggered by unusual activity within your account.  These events are stored in a different folder in S3 to the Management and Data events and contain information about the time of the event in question, in addition to error codes, associated APIs, and additional statistics to help you identify potential issues within your environment.

By default for all new AWS accounts, AWS CloudTrail is enabled to record events, all of which can be viewed using the Event History within the dashboard of the service of the AWS Management Console.  The Event History provides a quick and easy way to both search and download the previous 90 days of activity that has been recorded by CloudTrail.  You can also filter for events within the Event History, allowing you to quickly identify specific events more efficiently.

However, you also have the ability to store, review and then analyze these captured events, beyond what is capable of the Event History viewer by configuring a component called a CloudTrail Trail.  These trails also allow you to respond to specific events that have been captured, enabling you to create an event-driven architecture.  The data captured by these Trails are recorded and stored within Amazon S3, but they can also be sent to Amazon CloudWatch Logs. For more information on Amazon S3, and Amazon CloudWatch, please see our existing content here:  

Before we move on from Trails, I want to highlight that there are 3 different types of Trail that you can create:

• All Region Trail

• Single Region Trail

• AWS Organization Trail

An all-region trail is a trail that does exactly what it says on the tin, it’s a trail that will apply to all regions within your AWS account.  AWS CloudTrail will record the events that it has been configured for in each region that you are operating, and then deliver these events via log files to your specified S3 bucket.

An all-region trail is the recommended and suggested option by AWS when using CloudTrail, it enables you to capture and record data across your entire account which ultimately enhances how you can track events across your infrastructure.  Generally, having more information and data being captured about your environment, the more opportunities you have to optimize and secure your infrastructure through greater visibility. 

Unlike the All region trail, you can only create a single-region trail using the AWS command line interface, the CLI.  As expected, these trails only capture data from a single region only, this allows you to customize which regions you are interested in to record data for.  The event log files are then delivered to your chosen destination, such as an Amazon S3 bucket acting as a single repository, or and if required, you can have each single-region trail deliver logs to a separate bucket.

If you are using AWS Organizations within your AWS workloads, then you can implement an AWS Organization Trail.  More information on AWS Organizations can be found in our course here

When an organization trail is created, it will capture all events from all accounts that belong to the AWS Organization.  Interestingly, these organization trails can either be configured to capture events from just a single region, or all regions.  So as a ‘catch all’ approach, you could configure AWS CloudTrail with your AWS organization, and configure it across all regions.

The Management account must be used to create the trail, and this trail will then be associated and applied to all of your member accounts.  As a means of control, the member accounts will only have access to view the trail and the log files that it generates, and so they will not be able to modify the trails configuration in any way, this can only be done from the Management account. 

Another interesting component of AWS CloudTrail is something called a CloudTrail Lake. CloudTrail lakes allow you to collectively store, review and then query different events within your AWS account that have been generated by your resources, and then accumulate them into what’s known as event data stores, keeping them for up to 7 years.  These event data stores enable you to filter which events you want to be a part of that store, presenting only the relevant events that you would like to analyze using advanced event selectors, helping you to troubleshoot incidents and security threats and breaches.  Using SQL query language you can then extract specific data from the event data stores allowing you to take relevant actions depending on your use case.

In addition to being able to collect events from your own resources in your AWS account using CloudTrail events, CloudTrail lakes also provide you with the ability to capture log events from AWS Config configuration items, plus external sources, including those from within your own data center.  

AWS also works with a range of Partners who integrate their systems into AWS CloudTrail Lakes, such as CrowdStrike, CyberArk, GitHub, Nordcloud, and many others allowing you to seamlessly capture this data into a new CloudTrail Lake through the use of CloudTrail channels.  These channels enable you to link to your external source and your destination CloudTrail Lake together.