First 48 hours after an AWS security alert

The alert is rarely the whole story. The first two days decide whether you contain a real issue — or burn the week chasing noise while the actual exposure sits untouched.

This is the triage sequence we use with product and IT teams when GuardDuty, Security Hub, IAM Access Analyzer, or a vendor scanner lights up.

Hour 0–2: Confirm it is real and owned

1. Capture the finding as-is.
Screenshot or export the alert ID, account, region, resource ARN, severity, and first/last seen times. Do not “fix” anything yet.

2. Name an incident owner.
One person drives triage. Everyone else supports. Slack threads without an owner become archaeology.

3. Check blast radius, not drama.
Ask: What identity or resource is implicated? What data or network path could that touch? Public exposure and credential risk beat “interesting” malware findings on a throwaway sandbox.

4. Decide severity for your business.
Vendor “High” is a hint. Production customer data, long-lived keys, and public admin paths escalate. Dev accounts with no secrets usually do not.

Hour 2–8: Contain without making it worse

Situation	Prefer	Avoid
Compromised IAM key	Disable/rotate the key; review CloudTrail for use	Deleting the user before you know what it accessed
Suspicious EC2 / instance role	Isolate security group / NACL; snapshot if forensics needed	Immediate terminate if you still need evidence
Public S3 / open admin port	Block public access / close the port; confirm no second path	Rewriting the whole account VPC “while we are here”
GuardDuty crypto / C2 finding	Quarantine host; preserve logs	Reimaging before exporting memory/disk if legal needs evidence

Containment goal: stop ongoing access while preserving enough logs to answer “what happened.”

Day 1: Prove what the identity did

Pull CloudTrail (and VPC Flow Logs if relevant) for the implicated principal:

• First anomalous API call vs last
• Regions and services touched
• Whether data APIs (GetObject, SelectObjectContent, DB exports) fired
• Whether new users, keys, roles, or trust policies were created

Write a one-page timeline: detection → containment → known actions → unknown gaps. That page is what leadership and customers actually need.

Day 2: Close the door and schedule the boring fixes

1. Rotate everything the finding touched — keys, session tokens, passwords for related humans, and any secrets that lived on the host.

2. Fix the enabling misconfiguration — the public bucket policy, missing MFA, over-broad role, or disabled logging that made this easy. See common AWS security mistakes for the patterns that show up repeatedly.

3. Turn on the signals you wished you had — CloudTrail in all regions, GuardDuty, Security Hub (or equivalent), budget/anomaly alerts, and a ticket path that is not “whoever saw Slack.”

4. Decide residual risk in writing — accepted, mitigated, or transferred. Silent “we’ll get to it” is how the same alert returns in 90 days.

What good looks like after 48 hours

• The suspicious principal cannot still act
• You know whether customer or proprietary data was accessed (or you have a clear “unknown” with next steps)
• Logging gaps that hid the blast radius are on a dated fix list
• One owner is assigned to the permanent control change

You do not need a perfect forensics lab on day one. You need calm containment, a timeline, and a shorter path to the next alert being quieter.

For how responsibility splits between you and AWS, see the Shared Responsibility Model for busy leaders.

---

If you want a baseline review before the next alert — identity, logging, and priority fixes — book a free architecture review or talk about managed security.