Instructor: Now let's talk about CloudTrail.
So CloudTrail is a way to get governance,
compliance and audit for your AWS Accounts.
And CloudTrail is enabled by default.
This will allow you to get a history of all the events
and API calls made within your AWS Accounts
by the Console, by the SDK, the CLI, other services on AWS,
and all these logs will be appearing in CloudTrail.
And what you can do is that,
you can also put these logs from CloudTrail
into CloudWatch Logs or Amazon S3.
And you can create the trail to be applied
to all regions or a single region,
if you want to accumulate all these history
of events accumulated across all the regions
into one specific for example, S3 Bucket.
And when we use CloudTrail for example,
well say someone went ahead
and deleted something in AWS for example,
say that's an easy two instance was being terminated,
and you wanna figure out who did it?
Well, the answer is to look into CloudTrail
because CloudTrail we have that API call in it,
and we'll be able to get to the bottom of it
and understand who did what and when.
So to summarize CloudTrail is in the middle,
and the actions of the SDK, the CLI or the Console
or even IAM Users and IAM Roles
or other services will be in the CloudTrail Console.
We can look in it to inspect and audit what happened.
And if you want to have all the events
for more than 90 days,
then we can send them into CloudWatch Logs
or we can send them into an S3 Buckets.
So let me dive a little bit deeper for CloudTrail.
So we have three kinds of events
that you can see in CloudTrail.
The first one is called the Management events
and these represents operations that are performed
on resources in your AWS accounts.
For example, whenever someone configure security
they will use the API code called IAM AttachRolePolicy
and this will appear in CloudTrail.
If you create a subnets this will appear as well,
if you set up logging this will appear by default.
Anything that modifies your resources
or your AWS Accounts will appear in CloudTrail.
And by default,
trails are configured to log management events
no matter what.
You can separate two kinds of management events,
you have the Read Events that don't modify resources
for example, someone is listing all the users in IAM,
or listing all the Institute instances in IC2
these kinds of things.
You can separate them from Write Events
that may modify resources for example,
someone deletes or tries to delete a DynamoDB table.
And obviously the Write Events
have probably a lot more importance
because they can wreck damages into your AWS infrastructure
whereas the Read Events
is just to get information which are silver important,
but maybe less destructive.
Then you have Data Event so they're separate,
and by default data events are not logged
because they're high volume operations
so what are Data Events?
Well you have Amazon S3 object-level activity
for example, GetObject, DeleteObjects, PutObjects
and as you can see this can be,
happening a lot on the S3 Buckets,
and so this is why they're not logged by default
and you have the option to separate again
Read and Write Events so a Read Events would be a GetObject,
whereas a Write Events would be a DeleteObject
or a PutObject.
Another kind of event you can have in a CloudTrail
are AWS Lambda function execution activities
so whenever someone uses the Invoke API
so you can get insights about how many times
the Lambda functions are being invoked.
And again, this could be really high volumes,
if your Lambda functions are executed a lot.
And the third kind of events in CloudTrail
are called, CloudTrail Insights Events.
And so I will talk to you about CloudTrail Insighst
into more details in the next slide.
So now let's talk about CloudTrail Insights.
So when we have so many management events
across all types of services
and so many APS happening very very quickly
in your accounts,
it can be quite difficult to understand what looks odd,
what looks unusual and what doesn't.
And so this is where CloudTrail Insights comes in.
So with CloudTrail Insights and you've to enable it
and you have to pay for it,
it will analyze your events
and try to detect unusual activity in your accounts.
For example, in accurate resource provisioning,
hitting service limits,
bursts of AWS IAM actions,
gaps in periodic maintenance activity.
So the way it works is that,
CloudTrail will analyze what's normal
management activities look like to create a baseline,
and then it will continuously analyze anything
that is a Write type of events.
So whenever something is changed
or tried to be changed,
to detect unusual patterns.
So very simply, the management events
are going to be continuously
analyzed by CloudTrail Insights,
which will generate Insights Events
in case something is detected.
And so these anomalies, so these insights events will appear
in the CloudTrail console.
They will also be sent to Amazon S3 if you want to.
And an EventBridge events,
so in CloudWatch event is going to be generated
in case you need to automate
on top of these CloudTrail Insights,
for example to send an email.
So this is the idea behind CloudTrail Insights.
Finally, let's talk about CloudTrail Event Retentions.
So events by default are stored for 90 days in CloudTrail
and then afterwards they're deleted.
But sometimes, you may want to have events for longer
in case you want to go back
to something that happened maybe a year ago
for audit purposes.
And so to keep events beyond this period
what you have to do is
that you have to log them to S3 so send them to S3
and then you would use Athena to analyze them.
So very simply,
all your management events,
your data events and your insights events are going to go
into CloudTrail for 90 days retention period.
And then you would log those into your S3 Buckets
for long-term retention.
And when you're ready to analyze them,
you would use the Athena service
which is a server-less service to query data in S3
to find the events that you're interested in about
and learn more about them.
Okay.
So that's it.
I hope you liked it and I will see you in the next lecture.