Insights & Resources
Cloud & AWS

How to Track and Investigate Activity in Your AWS Account

Here is how to track and investigate activity in your AWS account using AWS CloudTrail, as it logs account activity related to users, roles, and AWS services.

Priyanka ShawPublished : 30 Sept 2026
Cloud & AWS

Hey readers! An AWS account can contain dozens or even thousands of resources, multiple users, applications, IAM roles, automated workloads, and services operating at the same time. In the event of something unexpected, just checking the AWS Management Console may not be enough to figure out what happened. You might see a new EC2 instance, an unfamiliar login, a changed security group, an unexpected IAM policy, or an unusual spike in activity. The important question is not only what changed, but also who made the change, when it happened, where the request originated, and which credentials or role were involved. AWS has several tools to investigate this kind of activity. One of the most important is AWS CloudTrail because it logs account activity related to users, roles, AWS services, the AWS Management Console, command-line tools, SDKs and APIs.

Why is AWS Account Activity Important?

Cloud environments are dynamic. Analyzing this data can help cloud administrators troubleshoot incidents, detect unauthorized activity, audit changes, and improve security controls. Resources can be created, changed, accessed or deleted in seconds. Some actions are performed by people; others are triggered automatically by applications, CI/CD pipelines, scheduled jobs or AWS services. This is why attribution is important.

Suppose an administrator discovers that an IAM policy was modified overnight. Looking only at the current policy tells you its present state. It does not necessarily explain who changed it or what happened immediately before the modification.

You have a history of activity logs. They can help you answer questions such as: who created the account access, what IAM user or role performed an action, what AWS API operation was called, when the activity happened, and to which AWS Region the request was made.

What resource was affected?

Was the request successful?

What source IP address or user-agent information was associated with the request?

These details can turn an unexplained configuration change into an event that can be investigated.

AWS CloudTrail: The Starting Point for Investigation

For many AWS account investigations, CloudTrail is the natural starting point.

CloudTrail logs activity in the form of events. Events can include actions taken using the AWS Management Console, AWS CLI, AWS SDKs, and APIs, and other AWS services. AWS positions CloudTrail as a service for operational and risk auditing, governance, and compliance. CloudTrail events may include data on the identity that initiated a request, the service concerned, the operation executed, the event time, and other request specifics. A key feature is Event history.

AWS provides you with CloudTrail Event history automatically, allowing you to view the last 90 days of management events for an AWS Region. You can search and download the event history, and you can view individual event records from the console. Event history is especially useful when investigating a recent change.

How to Start an AWS Activity Investigation 

Understanding the Identity Behind an Event

One of the most important parts of a CloudTrail record is the identity information.

An event can be associated with an IAM user, an assumed role, temporary credentials, the root user, or an AWS service, depending on how the action was performed.

This distinction matters because seeing a role name does not necessarily tell you which person initiated the original activity.

For assumed-role activity, CloudTrail records information about the role session and the identity associated with the credentials. AWS specifically notes that the assumed-role session name is used when filtering Event history for activity associated with a role session.

For example, a record might display an operation performed under an assumed role, rather than directly by an IAM user. This makes investigation a matter of understanding how that role was assumed. 

Look at the Event Name and Event Source 

The event name tells you what operation occurred. An event could be, for example, an API call to IAM, EC2, S3, CloudTrail, or another AWS service. The event source tells you which AWS service handled the request. Together, these fields give you a useful description of what happened.

In case you see an unexpected change to an IAM policy, for example, you can search for the corresponding IAM event and check the surrounding information. AWS defines management events as control-plane operations that involve management of AWS resources. Examples include security configuration, resource creation, networking configuration, and logging configuration changes. These events can be very useful when investigating changes to cloud infrastructure.

Check When and Where the Request Happened 

Timing can have a very dramatic impact on the meaning of an event. An action that looks suspicious at 3 AM could be all good if you typically automate a deploy at that time. An IP address you don’t recognize doesn’t automatically mean an account’s been compromised. Source addresses can be impacted by remote employees, VPNs, proxies, corporate networks, and cloud infrastructure.

For this reason, activity should be compared with known operational patterns. Look at the event timestamp, source IP information, Region, user agent, and surrounding events where available.

AWS notes that CloudTrail Event history records events in the AWS Region where the event occurred. The Event history view is therefore Region-specific, which is important when investigating accounts that operate workloads across multiple Regions.

Investigating Login Activity

Authentication events deserve particular attention during an account investigation.

A successful console sign-in can help to confirm someone signed in to the AWS Management Console and the associated identity and request information can provide additional context.

The ConsoleLogin event is one example of a CloudTrail event that can be searched in Event history.

However, authentication activity should not be examined in isolation. The sequence of events is often more helpful than a single event. Investigating IAM Activity IAM deserves special attention because identity and permissions determine what users and applications can do inside AWS. When you investigate an account, look for anomalous changes in users, groups, roles, policies, access keys, and permissions.

For example, an investigation may begin with an unexpected administrative permission. You can then use CloudTrail to determine when the relevant IAM configuration changed and which identity performed the operation.

IAM also provides last accessed information, which can help administrators understand which AWS services and actions an IAM identity has actually attempted to use. AWS states that this information can be viewed for IAM users, groups, roles, and policies.

This is especially useful when reviewing excessive permissions.

Going Beyond the 90-Day Event History

The built-in Event history is useful for recent investigations, but it has an important limitation: it covers the previous 90 days of management events for the relevant Region.

Organizations that need longer-term investigation capabilities should establish an appropriate CloudTrail trail or event data store.

A trail can deliver CloudTrail log files to Amazon S3, allowing organizations to retain activity records according to their operational, security, and compliance requirements. AWS recommends multi-Region trails when the goal is to capture activity across Regions.

This becomes particularly important for incident response.

Imagine discovering suspicious activity six months after it occurred. The Event history view may no longer contain the relevant events. Long-term log storage gives you the historical evidence needed to piece together what happened.

Understand Management Events and Data Events 

Another Important Concept in Investigations is the Difference Between Management Events and Data Events. Management events are control plane activity, such as creation, modification or deletion of AWS resources. Data events provide visibility into resource-level data operations for supported services and resources.

The CloudTrail Event history interface focuses on management events and does not show data events. AWS recommends using a trail or event data store when you need to investigate data events.

This distinction can prevent a common investigation mistake: assuming that because an action is absent from Event history, the action never happened.

The correct question is whether the relevant event type was being recorded.

Using CloudWatch for Deeper Log Analysis

For organizations that send CloudTrail logs to CloudWatch Logs, CloudWatch can provide another layer of investigation and analysis.

Instead of opening each event manually, security teams can use CloudWatch capabilities to search and analyze log data.

For example, an administrator could investigate activity associated with a particular IAM identity or look for a particular API operation.

AWS documents the use of CloudWatch log groups to search CloudTrail API history beyond the basic Event history workflow when a suitable CloudTrail configuration is in place.

Using the AWS CLI for Investigation

Security and cloud teams do not always need to work through the console.

The AWS CLI provides the aws cloudtrail lookup-events command for querying CloudTrail management events from the previous 90 days in the current Region. AWS documents filters including event name, event source, access key, event ID, and read-only status.

This can be useful for programmatic investigation of incidents or for inclusion of AWS activity checks in operational workflows. Instead of manually searching the console, an administrator can export the relevant events and review the results with scripts or other analysis tools. Automation is particularly useful in larger environments where repetitive investigation tasks need to be standardized. 

Look for the Story, Not Just Individual Events 

One of the most common mistakes in AWS activity investigation is to look at just one event. A security incident or configuration problem could involve several actions. Consider a hypothetical sequence: A new login happens.

A security group is changed.

An EC2 instance is launched.

Looking at only the final EC2 event would provide an incomplete picture.

Instead, investigators should build a timeline.

Trace the sequence of events beginning with the first anomalous activity. Determine the actor, the impacted resources, timestamps, locations, and relationships between activities. This method helps translate raw logs into a cohesive story.

Using CloudTrail Insights for Anomalous Activity 

CloudTrail Insights can also help identify anomalous patterns in API activity when enabled. Insights can catch anomalous activity such as changes in API call rates or API error rates, depending on how the event is set up, AWS said. Insights events can only be viewed after you enable them on a suitable trail. This is useful when an investigation is initiated by an unexpected spike in API activity, instead of a single suspicious operation. For example, if an application or identity spikes API calls, it is worth investigating even if the individual requests look legitimate.

AWS Activity Investigations Best Practices 

Effective investigation starts well before an incident occurs. Organizations must configure CloudTrail logging and retention to meet their security and compliance requirements. Logs must be protected from unauthorized modification and access and critical activity must be continuously monitored, not just after an incident has occurred. Identity management is equally important. Strong authentication, least-privileged permissions, controlled role assumption, and regular access reviews can reduce the probability and impact of unauthorized activity. It may also be useful to document normal behavior while in operation. If a deployment system regularly creates infrastructure at a certain time, security teams are less likely to mistake that activity for an intrusion.

Finally, investigations should be repeatable. Define procedures for examining authentication events, IAM changes, infrastructure modifications, access keys, and other high-impact activity so that responders do not have to develop an investigation process from scratch during an incident.

Final Thoughts

Investigating AWS account activity does not have to mean searching through endless technical logs without context. The process becomes much clearer when you start with a specific question and gradually reconstruct the sequence of events.

The process involves using AWS CloudTrail, which logs account activity and allows you to search the past 90 days of management events in Event history. Investigators can then look at identities , API operations , times , Regions , affected resources , and context of events . IAM last accessed information can assist with permission reviews, and extended CloudTrail configurations can offer historical visibility beyond the default Event history window.

Next Step

Need help turning this into a working system?

Let's Talk