AWS Events and Changes To Track For Your AWS Account Security
AWS CloudTrail service captures and publishes every action taken or change performed across any other AWS services.
These changes could come as a result of
- Console use by a user
- An application running its code
- A SaaS partner using assume role running/ accessing some API in your account
- An event trigger another component (e.g File got uploaded on S3 which trigger a Lambda function)
As you can see everything gets pushed into CloudTrail. Identity-related events like these gain meaning only when correlated with the surrounding posture, which is the lesson behind correlating identity with misconfigurations so contextual severity reflects the real IAM graph.
The example below shows that the IAM user Alice used the AWS CLI to call the CreateUser action to create a new user named Bob.
{
"Records": [
{
"eventVersion": "1.0",
"userIdentity": {
"type": "IAMUser",
"principalId": "EX_PRINCIPAL_ID",
"arn": "arn:aws:iam::123456789012:user/Alice",
"accountId": "123456789012",
"accessKeyId": "EXAMPLE_KEY_ID",
"userName": "Alice"
},
"eventTime": "2014-03-24T21:11:59Z",
"eventSource": "iam.amazonaws.com",
"eventName": "CreateUser",
"awsRegion": "us-east-2",
"sourceIPAddress": "127.0.0.1",
"userAgent": "aws-cli/1.3.2 Python/2.7.5 Windows/7",
"requestParameters": { "userName": "Bob" },
"responseElements": {
"user": {
"createDate": "Mar 24, 2014 9:11:59 PM",
"userName": "Bob",
"arn": "arn:aws:iam::123456789012:user/Bob",
"path": "/",
"userId": "EXAMPLEUSERID"
}
}
}
]
}So much data?
Data -> information -> insights becomes challenging and overwhelming if the amount is large and needs to be consumed in real-time. Real-time monitoring paired with contextual severity is what keeps this manageable, scoring each event by actual risk instead of drowning your team in noise. So, below is the list of metrics that we recommend you keep an eye on. This doesn’t mean that other events are not important but the objective of this blog is to ensure that the signal-to-noise ratio for your team is minimum and you do not lose sight of critical updates.
ConsoleLogin
- What? This event is raised when anyone logs into the account using the AWS console.
- Why? Generally, if you have CI/ CD setup and your team uses command-line tools to interact with cloud API, then console login is a rare act. It makes it important to stay alert if there is a console login.
- Risk: Medium
- What to do next? If you have a console login, especially for someone with a root or administrator role, then checking with them offline (over Slack or other messenger-based tools) is recommended.
StopLogging
- What? When AuditTrail logs are disabled. Yes, it raises this event and logs this action too 🙂
- Why? There will be little to no reason that anyone without a planned notice and communication has disabled AuditTrail logs themselves. So, this event itself is a good enough reason to jump on it.
- Risk: High
- What to do next? Jump on a call with team members (if required), login into your console, and assess who did it? If it was a mistake, then reenable the logging again. Also, put controls and education in a place where this mistake doesn’t happen again in the future. Events like this are exactly why a continuous cloud audit trail matters, and why teams invest in closing the audit-trail gap from missing logs to complete access auditing.
CreateRoute, CreateNetworkAclEntry, CreateSecurityGroup
- What? These deal with VPC security – one of the building blocks in which your compute and other resources and data resides.
- Why? This activity should be planned, documented, and approved activity.
- Risk: High
- What to do next? Alert your team about this and fix the issue/ process which has caused this.
AuthorizeDBSecurityGroupIngress, CreateDBSecurityGroup, DeleteDBSecurityGroup, RevokeDBSecurityGroupIngress
- What? These events deal with database security groups, which control network access to your databases.
- Why? Your database should be one of the most protected resources. Not only shouldn’t it have a public IP assigned, but it also should be in a private subnet. Listening for these events ensures that any changes to DB security groups don’t go unnoticed.
- Risk: High
- What to do next? Alert your team about this and verify that the change was planned and approved.
References
People Also Read
- AWS Real-Time Security Events
- Cloudanix Query Builder: Write Queries On Your Data
- All You Need To Know About AWS CloudTrail
- Best Practices For AWS CloudTrail
- CloudTrail, CloudWatch, Splunk, Custom logs solution
- A Practical Step by Step Guide To Prevent Security Breach Of Your AWS Account
- A Big List Of Mistakes AWS Cloud Users Have Done And Spent Millions
- How to setup Multi Factor Authentication (MFA) devices in AWS?
- The Different Types of Protection your Application Needs If Hosted in AWS
- Top 18 Challenges of Cloud Security in 2026
