New – AWS API Activity Lookup in CloudTrail

My colleague Sivakanth Mundru sent another guest post my way! This one shows you how to look up AWS API activity using CloudTrail.

— Jeff;

As you know, AWS CloudTrail captures API activity that is made on your AWS account and delivers log files containing API activity to an Amazon Simple Storage Service (Amazon S3) bucket and a CloudWatch Logs log group that you specify. Today, we are announcing support for looking up API activity using the CloudTrail Console, AWS SDKs, and AWS Command Line Interface (AWS CLI). You can now more easily troubleshoot operational issues or analyze potential security incidents. You will continue to receive the log files in your S3 bucket so that you can use them as a part of demonstrating compliance with internal or external policies.

This feature is available immediately in the US East (N. Virginia), US West (Oregon), US West (N. California), Europe (Ireland), Asia Pacific (Sydney), Asia Pacific (Singapore),  Europe (Frankfurt), Asia Pacific (Tokyo), and South America (São Paulo) regions. You can look up API activity that was made to create, delete, or update AWS resources in your AWS account. You can look up API activity that was captured for your account in last 7 days for 28 AWS services including Amazon Elastic Compute Cloud (Amazon EC2), Amazon Relational Database Service (Amazon RDS), Amazon Elastic Block Store (Amazon EBS), Amazon Virtual Private Cloud (Amazon VPC), and AWS Identity and Access Management (IAM) (check out the CloudTrail Supported Services for more information).

If you have already turned on CloudTrail for your account, you do not need to take any other action. Simply go to the CloudTrail Console and the API activity related to creating, deleting, and updating AWS resources will be automatically available to you. If you haven’t turned on CloudTrail for your AWS account, turn it on now from the CloudTrail Console to take advantage of this new cool feature. Once you login to the CloudTrail Console, you will see the API activity history page where you can see the history of API activity for last 7 days. The API activity history is arranged in the reverse chronological order with the most recent events listed at the top.  CloudTrail will retrieve older events for you as you scroll down.

You can view the API activity and you can also filter it. This can help you to troubleshoot operational issues or security incidents. The 5 filters supported are: Range, Event name, User name, Resource type and Resource name:

Troubleshooting Operational Issues
As I mentioned, you can use this feature to troubleshoot operational issues in your AWS account. For example, I saw that one of my EC2 instances in my web server fleet was not responding, so I navigated to the CloudTrail console and filtered the API activity by resource type EC2 Instance. I found that one of my team members (John) stopped the instance and was able to establish the root cause:

I checked with John, and he told me that he had stopped the instance in order to test the fault tolerance of our web server fleet. He was satisfied with the outcome of the test and agreed that we could start the instance. During my investigation I used the View Event button to take a closer look at the actual API call:

Reviewing Potential Security Incidents
Another type of event that many of you care about is the ConsoleLogin failures to the AWS console.

In my previous blog post, I showed you how to create CloudWatch alarms using this CloudFormation template and receive email notifications for certain network and security related API calls, including ConsoleLogin failures. You can follow the steps here to create an alarm that sends you a notification when three or more ConsoleLogin failures have occurred in the last 5 minutes.

Here is as an example of the email notification that I will receive when this happens:

I can then navigate to the CloudTrail console and see what those events are and which IP addresses they are coming from. I can view the entire event to validate that the ConsoleLogin requests came from known IP addresses or perform a deeper security analysis, if I do not recognize the IP addresses.

These are just two examples of how you can use this feature to troubleshoot operational or security incidents.

— Sivakanth Mundru, Senior Product Manager