Who Changed That AWS Resource? A Practical Guide to AWS CloudTrail
Learn how to investigate an unexpected AWS configuration change, interpret CloudTrail events, and build a lasting audit record.
An application stops responding after a deployment. A security group contains an unfamiliar rule. Someone asks who deleted a resource, and nobody remembers doing it.
These situations call for evidence. AWS CloudTrail records supported account activity and helps you investigate the identity, action, and context behind a request. This guide uses a hypothetical security group change to show how to start an investigation and where the default history reaches its limits.
Start with the question you need to answer
Suppose you discover an unexpected inbound rule in an EC2 security group. First record the account, Region, security group ID, rule, and approximate time you noticed it. Then investigate how it was introduced.
Avoid assuming that the last person who used the console caused the change. A deployment pipeline, assumed role, or AWS service may have made the request.
Use Event history for recent management activity
CloudTrail Event history is available automatically and provides the past 90 days of management events for an account in the selected Region. You do not need to create a trail to begin using it.
In the CloudTrail console:
- Select the Region containing the security group.
- Open Event history and choose an appropriate time range.
- Filter by Event name and enter
AuthorizeSecurityGroupIngress. - Open matching events and inspect the security group and rule details.
This action is a starting point for newly authorized inbound rules. If you find no match, investigate other operations, including rule modifications, and confirm the account, Region, and time window.
Event history supports one attribute filter plus a time range. It does not provide a combined search across all accounts and Regions, so keep the investigation scope explicit.
Read the event as evidence
The JSON record contains more context than the event name alone:
| Field | What to examine |
|---|---|
| eventTime | Request time in UTC |
| eventName | Requested action |
| eventSource | AWS service receiving the request |
| userIdentity | Identity and role context |
| requestParameters | Requested resource and changes, when recorded |
| sourceIPAddress | Recorded request origin |
| errorCode and errorMessage | Failure information, when applicable |
| eventID | Identifier for referencing the event |
Distinguish an attempted action from a completed change. Inspect error information and response details, then compare the event with the current resource configuration.
An assumed-role identity is not automatically a named person. Correlate the session context with your identity provider or deployment records. An IP address is also a clue rather than conclusive attribution: requests can originate through shared networks or AWS services.
Repeat the lookup with the AWS CLI
If you prefer a terminal, this read-only command searches recent management events in a specified Region:
1
2
3
4
5
6
aws cloudtrail lookup-events \
--region us-east-1 \
--lookup-attributes \
AttributeKey=EventName,AttributeValue=AuthorizeSecurityGroupIngress \
--max-items 20 \
--output jsonReplace the Region with the one you are investigating. The command limits the output to 20 items; check pagination when expanding your search. Each result includes a
CloudTrailEvent value containing the event JSON as a string, which you can parse for deeper inspection.Document the event ID, time, resource, identity context, and related deployment evidence. That makes your conclusion easier for someone else to verify.
Understand what Event history does not contain
A management event describes a control-plane operation, such as changing resource configuration. A data event describes supported activity involving the data itself, such as accessing an S3 object.
Event history does not show data events. Trails do not log them by default either: you must explicitly configure the relevant supported resources or event types. If you need to answer who downloaded an attachment from S3, decide on that logging requirement before the incident. Enabling logging later cannot recreate an event that was never recorded.
Create a trail for a lasting record
For retention beyond the default history, create a CloudTrail trail that delivers events to Amazon S3. A multi-Region trail covers the Regions enabled in your account and consolidates delivery to the configured bucket.
Define who can read the audit bucket, who can change the trail, and who can delete its logs. Choose retention based on investigation and organizational requirements. Validate delivery after setup instead of relying only on the existence of the trail.
Enable log file integrity validation when you need to check whether delivered files were altered or deleted. It creates integrity evidence; it does not itself prevent deletion. Run the validation workflow when verifying that evidence.
Make the record useful during an incident
You can deliver trail events to CloudWatch Logs and create metric filters and alarms for selected activity, such as security group changes. An alarm should lead to a useful review: which resource changed, whether the operation succeeded, and whether the change matches an approved deployment.
Not every change is suspicious. Review the alert against expected automation and maintenance so that your team can focus on unexplained activity.
CloudTrail supports investigation of AWS activity. Application logs and service metrics remain necessary to understand how a change affected users.
Review costs and test the workflow
Event history is available without CloudTrail charges. For trails, the first copy of management events in each Region is delivered without a CloudTrail event delivery charge, while S3 costs still apply. Additional copies, data events, and optional integrations can add costs. Review current pricing before widening collection.
Practice in a sandbox with a harmless configuration change. Find its event, identify the recorded role, and confirm that the trail delivered logs. Keep production audit coverage in place when cleaning up a learning exercise.
The goal is a repeatable investigation: define the scope, find the event, interpret its context, and connect it to evidence from your application and deployment process.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article