Cloud security engineering, proven on real infrastructure.
Three hands on AWS security labs. An automated GuardDuty to quarantine incident response pipeline, a real finding investigation, and a CloudTrail forensic timeline. Every screenshot below is a real console, a real API call, and a result I verified independently rather than took on faith.
- 3
- labs, real AWS account
- 2
- real bugs found and fixed
- 18
- redacted evidence screenshots
- 0
- simulated results
Build it, break it, prove it.
Each lab is a real workflow against a live AWS account. Not a walkthrough I followed, but infrastructure I configured, tested, and independently verified against the console, CloudWatch, and CloudTrail.
Automated EC2 Quarantine
GuardDuty → EventBridge → Lambda → EC2A high severity GuardDuty finding automatically strips an EC2 instance's network access. No human in the loop. Found and fixed two real bugs that would have broken it in production.
GuardDuty Investigation
Real finding, real reasoningInvestigated a genuinely recurring root credential finding from the account's own telemetry, 1,918 occurrences and counting, and determined it was console noise, not compromise.
CloudTrail Investigation
90 day timeline reconstructionReconstructed the full 90 day CloudTrail history of the Lab 1 instance. 26 events triaged into 24 routine credential rotations and the 2 that actually mattered.
Every result here was checked in at least two places before I called it done.
I don’t trust a Lambda’s own success message, and neither should you. Every claim on this site, the quarantine actually happening, the finding actually being a false positive, the timeline actually being clean, is backed by a redacted screenshot from the AWS console, cross referenced against CloudWatch Logs and CloudTrail. Account IDs, access keys, and source IPs are redacted throughout; resource IDs and security group names are left visible because they aren’t sensitive and the evidence is more useful with them intact.