AWS Incident Response Runbooks (2026): What Changes Now That Security Incident Response Is Metered and GuardDuty Correlates Attack Sequences
Quick summary: Two 2025 shifts rewrite the IR playbook: GuardDuty Extended Threat Detection now emits a single critical attack-sequence finding instead of a pile of high findings, and AWS Security Incident Response moved to metered pricing (free first 10,000 findings/month, then $0.000676 each) on November 21, 2025. The lesson is to page humans on the <1% of correlated criticals, isolate instead of terminate, and let auto-triage absorb the rest. Here are the runbooks.
Key Takeaways
- 000676 each) on November 21, 2025
- The lesson is to page humans on the <1% of correlated criticals, isolate instead of terminate, and let auto-triage absorb the rest
- Two changes in late 2025 quietly rewrote how AWS incident response should work, and most runbooks haven't caught up
- First, on November 21, 2025, AWS Security Incident Response (SIR) moved to metered pricing — the first 10,000 findings ingested per month are free, then $0
- 000676 per finding — so the service is now $0 to adopt for a small estate
Table of Contents
Two changes in late 2025 quietly rewrote how AWS incident response should work, and most runbooks haven’t caught up. First, on November 21, 2025, AWS Security Incident Response (SIR) moved to metered pricing — the first 10,000 findings ingested per month are free, then $0.000676 per finding — so the service is now $0 to adopt for a small estate. Second, GuardDuty Extended Threat Detection expanded to EC2 and ECS in December 2025, and it now correlates multi-step attacks into a single critical attack-sequence finding with a MITRE ATT&CK mapping, instead of leaving you to stitch together a pile of high findings yourself. Put together, these change the core IR question from “how do we triage thousands of alerts?” to “how do we respond to the handful of correlated criticals — and let automation absorb the rest?”
This is for security engineers, platform leads, and CTOs who already have GuardDuty on and want an end-to-end response process, not another detection-setup walkthrough. We ship a triage decision tree, an EC2 containment runbook, an EventBridge rule that routes only critical attack sequences to your pager, and a SIR finding cost model CSV.
Benchmark pattern (not a cited client) — A composite mid-size multi-account SaaS estate: ~30 accounts, GuardDuty + Runtime Monitoring enabled, ~500,000 GuardDuty findings/month at baseline. Of those, GuardDuty Extended Threat Detection + SIR auto-triage surface well under 1% as
criticalcorrelated sequences — AWS documents the service filters over 99% of alerts. Modeled in the cost CSV: 500k findings/month is ~490k billable after the free tier, an upper-bound ~$331/mo before tiered discounts — while the human on-call only investigates the survivors, not all 500k. The leverage is in what you page on, not in how fast you can read findings.
The detection layer changed: stop correlating by hand
For years the IR bottleneck was correlation. GuardDuty would fire UnauthorizedAccess:EC2/SSHBruteForce, then later CryptoCurrency:EC2/BitcoinTool.B, then a CloudTrail anomaly — three findings, three timestamps, and a tired analyst trying to decide if they were the same incident.
GuardDuty Extended Threat Detection removes that work. It correlates runtime activity, malware detections, VPC Flow Logs, DNS queries, and CloudTrail events using AI/ML and emits one critical-severity attack sequence finding with an incident summary, an event timeline, MITRE ATT&CK mapping, and remediation guidance. It already covered IAM, S3, and EKS; the December 2025 expansion added two findings for compute:
AttackSequence:EC2/CompromisedInstanceGroupAttackSequence:ECS/CompromisedCluster
Opinionated take: the critical attack-sequence finding is the only GuardDuty output that should page a human at 03:00. It is enabled by default at no additional cost, but its depth depends on enabling the relevant protection plans and Runtime Monitoring — so turn those on, or the correlation runs half-blind.
The triage layer: page on intent, batch the rest
The triage decision tree encodes one rule: route by what kind of signal it is, not by raw severity count.
| Source | Default route |
|---|---|
| GuardDuty critical attack sequence | Page on-call → open SEV-2 (SEV-1 if data in scope) |
GuardDuty single high finding | Auto-triage → enrich → human review within SLA |
GuardDuty medium/low | Aggregate; business-hours review |
| Security Hub control failure | Hardening backlog — not an incident |
The EventBridge route matches severity >= 9.0 and type prefix AttackSequence:, then targets SNS (pager), a ticketing Lambda, or Slack. Everything below that bar is absorbed by SIR’s adaptive auto-triage and suppression rules, or routed to a low-urgency queue.
What broke — On a prior estate, the on-call paged on every
highGuardDuty finding “to be safe.” Within three weeks the team was getting 20–40 pages a day, almost all benign recon. The predictable outcome: when a genuine credential-compromise sequence fired, the engineer reflexively acknowledged-and-ignored it like the other 39, and containment slipped by hours. The fix was not a better pager — it was deleting the high-finding page rule entirely and paging only on critical attack sequences, letting auto-triage handle the rest. Alert volume to humans dropped by more than 90% and the next real critical got a 12-minute response instead of a 4-hour one.
Build vs buy: it’s “both,” not “either”
AWS Security Incident Response triages findings from GuardDuty and third-party tools via Security Hub, escalates events, and gives you 24/7 access to AWS Security Incident Response engineers plus agentic AI-powered investigation that automates evidence gathering. With the November 2025 metered model it is $0 under 10,000 findings/month.
- Lean toward SIR when you lack 24/7 in-house security coverage, want auto-triage that learns your environment, or want AWS engineers on call.
- Layer your own EventBridge automation on top for the criticals — routing to your ticketing system, kicking off the containment runbook, posting to the incident channel.
Named substitutes: GuardDuty Extended Threat Detection replaces manual signal correlation; SIR replaces a DIY 24/7 triage rota; Amazon Detective replaces hand-rolled CloudTrail spelunking for investigation. You don’t pick one — you compose them.
The containment layer: isolate, don’t terminate
When a critical sequence is confirmed, the EC2 containment runbook is phase-gated, and the gates exist to stop two specific mistakes:
- Phase 1 — Confirm & scope (~10 min): read the finding’s summary + ATT&CK mapping, list affected instances and their IAM roles, decide SEV.
- Phase 2 — Preserve evidence (do not skip): termination protection on, EBS snapshots tagged
do-not-delete, CloudTrail exported to a WORM bucket. - Phase 3 — Contain: move instances to a quarantine SG (no egress), detach/deny the IAM role, deactivate implicated keys, revoke sessions, deregister from the ALB/ASG.
- Phase 4 — Eradicate & recover: close the entry vector in the launch template, replace from a known-good AMI, restore data from a pre-compromise backup.
- Phase 5 — Close & learn: confirm no recurrence for 72h, write the retro, convert one lesson into automation.
Opinionated take: the two cardinal sins are terminate-first (destroys evidence) and clean-and-return (you cannot prove a compromised host is clean). The runbook gates both out.
Recovery depends on you, not the service
AWS is explicit: there is no guarantee impacted resources can be recovered. SIR shortens mean-time-to-resolve and gives you expert hands, but restoration still depends on your having clean, pre-compromise backups. If your restore path is untested, that is the hole in your IR plan no managed service fills. Run a restore drill before you need one.
What to do this week
- Confirm GuardDuty Extended Threat Detection coverage: turn on the protection plans and Runtime Monitoring for EC2/ECS/EKS so attack-sequence correlation runs at full depth.
- Delete any “page on every
highfinding” rule. Deploy the critical-only EventBridge route instead. - Onboard AWS Security Incident Response (it’s $0 under 10k findings/month) and watch your finding volume in CloudWatch for a week to size your cost model.
- Drop the EC2 containment runbook into your wiki and dry-run it in a non-prod account against a synthetic finding.
- Run one restore drill from backup. Time it. That number is your real recovery SLA.
What this post doesn’t cover
- GuardDuty initial setup and protection-plan selection — see GuardDuty threat detection production guide.
- Security Hub configuration and CSPM scoring — see setting up Security Hub and CSPM native vs third-party.
- Automated remediation pipelines for low-severity drift — see automating AWS security remediation.
- Forensic deep-dives (memory capture tooling, disk imaging) beyond the evidence-preservation gate.
- Exact current SIR pricing and tier breaks — confirm on the AWS Security Incident Response pricing page; figures here are the mid-2026 model.
Related: GuardDuty threat detection · Automating security remediation · CloudTrail production setup · IAM least-privilege · AWS cloud security services
If you only do one thing: Delete your “page on every high finding” rule and page only on GuardDuty critical attack sequences. That single change is what turns an alert-fatigued on-call into one that actually responds when the real incident fires.
Related reading
AWS Cloud Architect & AI Expert
AWS-certified cloud architect and AI expert with deep expertise in cloud migrations, cost optimization, and generative AI on AWS.
