April 4, 2026 · Tim Fraser, Cloud Operations Lead
What to Do After an AWS Security Incident
You just dealt with a security incident in your AWS account. Maybe compromised credentials, maybe an exposed S3 bucket, maybe an EC2 instance running a crypto miner. The immediate fire is out. Now comes the harder part: making sure it doesn't happen again.
Most teams handle containment reasonably well. What they struggle with is the aftermath — the investigation, the root cause analysis, and most critically, the sustained monitoring that prevents recurrence.
Phase 1: Containment (the first hour)
If you haven't done this already, these are the immediate actions:
Disable compromised credentials. Go to IAM, find the access key or user, and deactivate it. Don't delete it yet — you need it for investigation. Just deactivate. Isolate affected resources. For EC2 instances, change the security group to one that blocks all traffic. Don't terminate — you'll want the disk for forensics. For Lambda functions, set concurrency to zero. Revoke active sessions. For compromised IAM roles, add an inline policy denying all actions for sessions issued before now. This invalidates temporary credentials already in use without destroying the role. Check for persistence. Attackers typically create additional access paths: new IAM users, new access keys, modified trust policies, Lambda functions on a schedule. Check all of these before assuming containment.Phase 2: Investigation (the first day)
Once you've contained the blast radius, figure out what actually happened.
CloudTrail is your primary evidence. Filter Event History by the compromised principal. Look at every API call — especially calls that create resources (RunInstances, CreateUser, CreateAccessKey), exfiltrate data (GetObject), or cover tracks (DeleteTrail, StopLogging).If you have CloudTrail logging to S3, search the full history with Athena. If you only have the 90-day Event History, export it now before it rolls off.
VPC Flow Logs show network traffic. Check for unusual outbound connections — data going to unfamiliar IP addresses, especially on non-standard ports. If Flow Logs weren't enabled, enable them now for future incidents. Build a timeline. Write down every action chronologically: initial access, lateral movement, what was accessed, what was modified. This timeline determines actual impact and reporting obligations.Phase 3: Root cause and remediation
Knowing what the attacker did matters less than knowing how they got in. Common root causes:
Credentials in code. Access keys in a Git repo, hardcoded in config, or in a .env file. Fix: rotate to IAM roles wherever possible. For external services, use Secrets Manager. Overly permissive IAM policies. A role with: that was meant to be temporary. Fix: review CloudTrail for what the role actually used, and write a policy covering exactly that.
Exposed services. Security groups allowing 0.0.0.0/0 on port 22 or 3389. Public S3 buckets. Public RDS instances. Fix: audit every security group and resource for public exposure.
Missing MFA. Console users without MFA, especially admins. Fix: enforce MFA for all IAM users with console access.
Phase 4: Ongoing monitoring (the part most teams skip)
After every incident, teams make the same promise: "We'll monitor more closely from now on." They set up a few CloudWatch alarms, maybe review security groups weekly, check IAM users monthly.
It lasts about three weeks. Then a product deadline hits, priorities shift, and monitoring becomes something that gets done when someone remembers. The next incident arrives and the conversation starts with "we were meant to be checking that."
The post-incident response doesn't break down in containment or investigation. It breaks down in the sustained attention that security requires after the urgency fades.
Effective post-incident monitoring covers: new IAM users and access keys, security group changes, public S3 buckets, CloudTrail being disabled, root account usage, and resources in unexpected regions. It needs to run every week whether anyone remembers or not.
How plainfra helps with the ongoing part
plainfra connects to your AWS account with read-only access and delivers weekly health reports that cover the security checks most teams intend to do manually but don't sustain. New IAM users, open security groups, disabled logging, root account activity, public resources — flagged automatically, every week.
You can also ask direct questions after an incident: "Show me all IAM users created in the last 30 days," or "Which security groups allow inbound SSH from anywhere?" The answers come from live API calls, not a stale database.
The investigation and remediation after an incident require human judgement. The ongoing vigilance that prevents the next incident requires consistency — and that's what automation is built for.
Try plainfra free → 50K tokens, 7 days, no charge. Or see the interactive demo →.