---
title: AWS Incident Response Runbooks (2026): What Changes Now That Security Incident Response Is Metered and GuardDuty Correlates Attack Sequences
description: 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.
url: https://www.factualminds.com/blog/aws-security-incident-response-runbooks-2026/
datePublished: 2026-06-09T00:00:00.000Z
dateModified: 2026-06-10T00:00:00.000Z
author: Palaniappan P
category: Security & Compliance
tags: aws-security, incident-response, guardduty, security, aws
---

# AWS Incident Response Runbooks (2026): What Changes Now That Security Incident Response Is Metered and GuardDuty Correlates Attack Sequences

> 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.

**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](https://bitbucket.org/baymail/factualminds-astro/src/main/examples/architecture-blog-2026/incident-response/triage-decision-tree.md), an [EC2 containment runbook](https://bitbucket.org/baymail/factualminds-astro/src/main/examples/architecture-blog-2026/incident-response/containment-runbook-ec2-credential-compromise.md), an [EventBridge rule that routes only critical attack sequences to your pager](https://bitbucket.org/baymail/factualminds-astro/src/main/examples/architecture-blog-2026/incident-response/route-critical-findings-eventbridge.json), and a [SIR finding cost model CSV](https://bitbucket.org/baymail/factualminds-astro/src/main/examples/architecture-blog-2026/incident-response/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 `critical` correlated sequences — AWS documents the service filters over 99% of alerts. Modeled in the [cost CSV](https://bitbucket.org/baymail/factualminds-astro/src/main/examples/architecture-blog-2026/incident-response/sir-finding-cost-model.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/CompromisedInstanceGroup`
- `AttackSequence: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](https://bitbucket.org/baymail/factualminds-astro/src/main/examples/architecture-blog-2026/incident-response/triage-decision-tree.md) 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](https://bitbucket.org/baymail/factualminds-astro/src/main/examples/architecture-blog-2026/incident-response/route-critical-findings-eventbridge.json) 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 `high` GuardDuty 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](/blog/aws-macie-detective-data-security-investigation/) 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](https://bitbucket.org/baymail/factualminds-astro/src/main/examples/architecture-blog-2026/incident-response/containment-runbook-ec2-credential-compromise.md) is phase-gated, and the gates exist to stop two specific mistakes:

1. **Phase 1 — Confirm & scope** (~10 min): read the finding's summary + ATT&CK mapping, list affected instances and their IAM roles, decide SEV.
2. **Phase 2 — Preserve evidence** (do not skip): termination protection on, EBS snapshots tagged `do-not-delete`, CloudTrail exported to a WORM bucket.
3. **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.
4. **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.
5. **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

1. 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.
2. Delete any "page on every `high` finding" rule. Deploy the [critical-only EventBridge route](https://bitbucket.org/baymail/factualminds-astro/src/main/examples/architecture-blog-2026/incident-response/route-critical-findings-eventbridge.json) instead.
3. 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](https://bitbucket.org/baymail/factualminds-astro/src/main/examples/architecture-blog-2026/incident-response/sir-finding-cost-model.csv).
4. Drop the [EC2 containment runbook](https://bitbucket.org/baymail/factualminds-astro/src/main/examples/architecture-blog-2026/incident-response/containment-runbook-ec2-credential-compromise.md) into your wiki and dry-run it in a non-prod account against a synthetic finding.
5. 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](/blog/aws-guardduty-threat-detection-production-guide/).
- **Security Hub configuration and CSPM scoring** — see [setting up Security Hub](/blog/how-to-set-up-aws-security-hub-compliance-monitoring/) and [CSPM native vs third-party](/blog/aws-cspm-native-vs-third-party-decision-guide/).
- **Automated remediation pipelines** for low-severity drift — see [automating AWS security remediation](/blog/from-reactive-to-proactive-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](/blog/aws-guardduty-threat-detection-production-guide/) · [Automating security remediation](/blog/from-reactive-to-proactive-automating-aws-security-remediation/) · [CloudTrail production setup](/blog/aws-cloudtrail-production-setup-multi-region-validation-lake/) · [IAM least-privilege](/blog/aws-iam-best-practices-least-privilege-access-control/) · [AWS cloud security services](/services/aws-cloud-security/)

**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 KMS Encryption Architecture (2026): The Per-Tenant CMK Trap, the 10,000 req/s Shared Quota, and When AWS-Owned Keys Win](/blog/aws-kms-encryption-architecture-cmk-strategy-2026/)
- [AWS Resource Hardening Quick Wins: DMS, OpenSearch, SageMaker, and Lambda Runtimes](/blog/aws-resource-hardening-quick-wins-dms-opensearch-sagemaker-lambda/)
- [How to Protect AWS Infrastructure from Cost-Based Attacks](/blog/protect-aws-infrastructure-cost-based-attacks/)

## FAQ

### What changed with AWS Security Incident Response pricing in late 2025?
On November 21, 2025, AWS Security Incident Response moved to a metered, consumption-based pricing model. The first 10,000 security findings ingested per month are free; beyond that you pay $0.000676 per finding, with tiered discounts at higher volumes and no upfront commitment or minimum fee. You can monitor your monthly finding volume in Amazon CloudWatch at no additional cost. This replaced the prior membership-style model and means small estates can adopt the service at $0 and large estates can predict cost from their finding volume. Always confirm the current rate and tier breaks on the AWS Security Incident Response pricing page, because the numbers here are the model as of mid-2026.

### How is GuardDuty Extended Threat Detection different from regular GuardDuty findings?
Regular GuardDuty findings are individual signals — an SSH brute force here, a crypto-mining process there. Extended Threat Detection uses AI/ML to correlate multiple signals across resources and time into a single attack-sequence finding with a new critical severity level, a natural-language incident summary, an event timeline, MITRE ATT&CK mapping, and remediation guidance. It covers IAM, S3, EKS, and — since the EC2/ECS expansion in December 2025 — also EC2 instances (AttackSequence:EC2/CompromisedInstanceGroup) and ECS clusters (AttackSequence:ECS/CompromisedCluster). It is enabled by default at no additional cost when GuardDuty is on, though coverage depth depends on which protection plans and Runtime Monitoring you have enabled. Operationally it means you should page on the correlated critical, not on every high finding.

### When should we NOT page a human for a GuardDuty finding?
Do not page on medium/low findings (recon, port probes) or on high single findings that have a plausible false-positive explanation — route those to auto-triage and same-day or next-business-day review. Do not page on Security Hub control failures at all; those are configuration drift for your hardening backlog, not incidents. Reserve paging for the critical attack-sequence findings that represent correlated intent. The failure mode of paging on every high finding is alert fatigue: the on-call learns to swipe the pager away, and the one real critical gets the same dismissive treatment as the noise. Let GuardDuty Extended Threat Detection and Security Incident Response suppression/auto-triage filter the volume — AWS documents that the service filters over 99% of alerts to surface critical events.

### Should we buy AWS Security Incident Response or build our own triage pipeline?
Build-your-own (EventBridge routing + a Lambda that opens tickets + a SOAR runbook library) is justified when you have a dedicated security operations team, want full control of the workflow, and can staff 24/7 on-call. AWS Security Incident Response is the better default when you lack 24/7 security coverage, want adaptive auto-triage that learns your environment, and value 24/7 access to AWS Security Incident Response engineers plus agentic AI-powered investigation that automates evidence gathering. Most mid-size teams should start with the managed service (now $0 under the free tier for low finding volumes) and layer their own EventBridge automation on top for the criticals — that is the pattern this post recommends, not an either/or.

### What is the single most important rule when containing a compromised EC2 instance?
Isolate, do not terminate — and preserve evidence before you do anything else. The instinct under pressure is to terminate the instance to "stop the bleeding," but that destroys the forensic evidence and the root-cause trail, and you lose the ability to learn how the attacker got in. The correct sequence is: enable termination protection, snapshot the EBS volumes (tagged do-not-delete), export the relevant CloudTrail events to a WORM/Object-Lock bucket, then move the instance to a quarantine security group with no egress and detach or deny its IAM role. Only after evidence is captured and the blast radius is contained do you replace the host from a known-good AMI. Never clean-and-return a compromised host — you cannot prove it is clean.

### Does AWS Security Incident Response guarantee our data can be recovered?
No. AWS explicitly states there is no guarantee that impacted resources can be recovered, which is why the service guidance — and this runbook — insists on maintaining tested backups for anything that matters to your business. The service helps you triage, escalate, investigate, and coordinate response with access to AWS security engineers, and it shortens mean-time-to-resolve, but recovery still depends on your having clean, pre-compromise backups to restore from. Treat backups and restore drills as a precondition for incident response, not an afterthought. If your restore path is untested, your IR plan has a hole no managed service fills.

---

*Source: https://www.factualminds.com/blog/aws-security-incident-response-runbooks-2026/*