If you've ever investigated an unexpected change in AWS, you probably know how much time can go into understanding a single event.
Take a security group rule allowing inbound SSH traffic from 0.0.0.0/0.
CloudTrail can show you the AuthorizeSecurityGroupIngress event, when it happened, and which IAM identity made the API call.
That's a starting point, but there's still quite a bit to investigate.
Was the change made manually or through automation? Which resources are associated with that security group? Are any of them actually reachable from the internet? What did the configuration look like before the change?
You might find yourself checking CloudTrail, EC2, AWS Config, and your deployment history just to piece together what happened.
And not every risky-looking configuration has the same impact. An overly permissive rule attached to a resource in a private subnet is a different situation from one exposing a production instance with a public IP.
That context matters when deciding what needs immediate attention.
I've been working on Kultarr, a product focused on making these kinds of AWS investigations easier.
The idea is to bring together the change, the identity behind it, the affected resources, and the relevant security context so engineers can understand what's happening without manually jumping between services.
Kultarr is still in development, and I'm currently refining how these investigations should work.
I'm interested in hearing how other engineers approach this.
When you need to investigate an unexpected IAM or security group change, what's your usual workflow? Do you use CloudTrail and AWS Config directly, or have you found a better way to connect the information?
More about what I'm building: https://kultarr.io
Top comments (0)