‫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.
‫Now, what you can do is that you can also put these logs
‫from CloudTrail into CloudWatch Logs or Amazon S3.
‫And you can create a trail to be applied
‫to all regions or a single region,
‫if you wanted to accumulate all these history
‫of events accumulated across all regions
‫into one specific, for example, S3 buckets.
‫And when we use CloudTrail, for example,
‫we'll say someone went ahead and deleted something in AWS.
‫For example, say that an EC2 instance
‫was being terminated
‫and you wanna figure out who did it?
‫Well, the answer is to look into CloudTrail
‫because CloudTrail will have that API Call
‫in it and will 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 configures security,
‫they will use the API Call called IAM AttachRolePolicy.
‫And this will appear in CloudTrail.
‫If you create a subnet, this will appear as well.
‫If you set up logging, this will appear by default.
‫Anything that modifies your resources
‫or your iOS accounts will appear in CloudTrail.
‫And by default,
‫trails are configured to log Management Events
‫no matter what.
‫You can separate two kind 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 EC2 instances in EC2,
‫these kind 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 still very important, but maybe less destructive.
‫Then you have Data Events.
‫So they're separate and by default Data Events
‫as 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, DeleteObject, PutObject.
‫And as you can see,
‫these can be happening a lot on an S3 bucket.
‫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 Event will be a GetObject
‫whereas a Right Event 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 your Lambda functions are being evoked.
‫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 Insights
‫in a bit 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 APIs happening 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 have 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, burst of AWS IAM actions,
‫gaps in periodic maintenance activity.
‫So the way it works is that CloudTrail will analyze
‫what normal management
‫activities look like to create the baseline
‫and then it will continuously analyze anything
‫that is the right type of event.
‫So whenever something is changed
‫or try 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 Event
‫in case something is detected.
‫And so these anomalies, so these Insight Events will appear
‫in the CloudTrail console.
‫They will also be sent to Amazon industry if you want to,
‫and an EventBridge Event.
‫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 Retention.
‫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 audited 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 serverless
‫service to query data in S3 to find the events
‫that you're interested in about and learn more about them.
‫Okay, very important CloudTrail integration
‫need to know about is the one
‫with Amazon EventBridge to intercept any API Calls.
‫So let's say you wanted to receive an SNS notification,
‫anytime a user would delete a table in DynamoDB
‫by using the DeleteTable API Call.
‫So what happens that whenever we do an API Call in AWS,
‫as you know,
‫the API Call itself is going to be logged in CloudTrail,
‫that's for any API Call
‫but then all these API Calls will end
‫up as events as well in Amazon EventBridge.
‫And so we can look
‫for that very specific DeleteTable API Call
‫and create a rule out of it.
‫And this rule will have a destination,
‫the destination being Amazon SNS
‫and therefore we can create alerts.
‫So that's it very simple
‫but you can do it for any API Calls
‫and that will close all the topics for CloudTrail.
‫I hope you like this lecture
‫and I will see you in the next lecture.