Amazon Web Services has put a price tag on something most security teams used to handle with overtime pay and panic. On October 8, 2026, AWS updated the pricing page for Security Incident Response, a managed service that pairs automated triage with human investigators who work security findings around the clock. The pitch is simple: GuardDuty and Security Hub already tell you something is wrong, and now AWS will help you figure out what to do about it, billed by the finding instead of by the headcount.
The timing matters. AWS rolled out the pricing update the same month it expanded Security Hub’s threat analytics and added GuardDuty RDS Protection for Aurora PostgreSQL and Amazon RDS for PostgreSQL, part of a steady security buildout that has run through most of 2026. Security Incident Response slots into that stack as the layer that actually does something with the alerts instead of just generating more of them. For cloud teams drowning in findings they don’t have staff to chase, that’s the whole sales pitch.
What AWS Security Incident Response Actually Does
Security Incident Response is not a detection tool. AWS already sells several of those. It’s a response layer that sits on top of detection, built to help customers prepare for, respond to, and recover from security events once something has already been flagged. The service combines automated monitoring and triage of incoming findings with AI-assisted investigation, then backs that up with direct access to AWS security engineers 24 hours a day, seven days a week.
That combination is the point. Automated systems are fast at sorting signal from noise, but they still stumble on judgment calls: is this failed login attempt a misconfigured script or an attacker pivoting through a compromised account? AWS’s model routes the findings worth a second look to human engineers who can open a case, coordinate containment steps, and walk a customer through recovery. It’s the kind of work that used to require a retained incident-response firm on speed dial, now offered as a line item on the AWS bill.
Crucially, the service doesn’t replace the detection tools feeding it. Findings arrive from Amazon GuardDuty, AWS’s managed threat-detection service, and from supported third-party tools that route through AWS Security Hub. Security Incident Response is the triage and response desk sitting downstream of all that telemetry, not a new sensor network.
The Pricing Breakdown: How the Per-Finding Model Works
According to AWS’s published pricing page, Security Incident Response bills on a simple principle: the more findings you send through it, the cheaper each one gets. The first 10,000 security findings ingested each month cost nothing. After that, AWS splits usage into three marginal tiers, with the price per finding dropping at each threshold rather than resetting.
| Tier | Monthly Findings Ingested | Price Per Finding |
|---|---|---|
| Free tier | First 10,000 | $0 (free) |
| Tier 1 | Next 100,000 (10,001 to 110,000) | $0.000676 |
| Tier 2 | Next 500,000 (110,001 to 610,000) | $0.000538 |
| Tier 3 | Above 610,000 | $0.000430 |
Run the math on a busy month and the numbers stay modest. AWS’s own example puts a 2 million-finding month at roughly $934.30 in service charges, a figure that excludes whatever GuardDuty and Security Hub themselves cost to run, since those are billed separately. For a company with a sprawling multi-account AWS estate throwing off hundreds of thousands of findings, that’s a rounding error next to the cost of a single breach that goes unnoticed for weeks.
There’s a carve-out that changes the calculus for AWS’s biggest spenders. Customers on Enterprise Support or Unified Operations plans get Security Incident Response bundled into their existing support contract at no additional per-finding cost, including findings above the 10,000 free tier. For large enterprises already paying for AWS’s top support tiers, this is effectively a free add-on. For everyone else, it’s a true pay-as-you-go service with a free entry point low enough that a small team can trial it without budget approval.
How GuardDuty and Security Hub Feed the Pipeline
To understand why AWS can price this so cheaply, it helps to see what’s happening upstream. GuardDuty analyzes signals like CloudTrail activity, VPC flow logs, DNS queries, and workload-specific telemetry to flag suspicious behavior automatically, no agents required. Those findings then flow into Security Hub, which normalizes them alongside results from other AWS security services and supported partner products, applying workflows and automation rules before anything reaches a human.
Security Incident Response is the fourth link in that chain. Per AWS’s own security services best-practices documentation, existing GuardDuty suppression rules and Security Hub automation can filter out known-benign activity before it ever triggers an investigation, which keeps the finding count (and the bill) from ballooning on noise alone. The practical effect is that a well-tuned Security Hub configuration, with sane suppression rules, directly lowers what a company pays for incident response. Sloppy tuning does the opposite.
That dependency is also the service’s biggest limitation. Security Incident Response only investigates what GuardDuty and Security Hub can see. A company running minimal AWS-native detection, or one that hasn’t enabled GuardDuty across every account and region, gets a thinner slice of coverage no matter how good the human engineers on the other end are. The AWS Builder Center’s GuardDuty walkthrough makes the same point from the detection side: coverage depends on which protection plans and data sources are actually turned on, and GuardDuty pricing itself scales with that usage.
Part of a Bigger 2026 Security Push
Security Incident Response isn’t landing in isolation. AWS has spent 2026 steadily widening its native security portfolio, and the October pricing update arrived alongside two other changes worth tracking. Security Hub now exports findings to Amazon S3 in either CSV or OCSF JSON format, giving security teams an easier path to pull AWS findings into whatever external SIEM or data lake they already run. And GuardDuty RDS Protection expanded to cover data exfiltration and destruction detection on Aurora PostgreSQL and Amazon RDS for PostgreSQL, closing a gap for teams running managed Postgres at scale.
Security Hub itself has also been restructured this year around what AWS calls Essentials capabilities: vulnerability management through Amazon Inspector scanning, cloud security posture checks, GuardDuty EC2 malware scanning, and risk prioritization, all bundled under resource-based pricing with a 30-day free trial. Threat Analytics, powered by GuardDuty, and Lambda code scanning, powered by Amazon Inspector, sit as optional add-ons on top of that base. Seen together, the pattern is consistent: AWS keeps turning free-standing security signals into paid, increasingly automated response products, and Security Incident Response is the newest rung on that ladder.
Coverage of the launch from theCUBE’s AWS news desk framed it plainly as AWS expanding its cybersecurity portfolio to make it easier for customers to detect and remediate breaches without standing up a dedicated response team from scratch. That framing lines up with how AWS has pitched nearly every security release this year: less “buy more tools,” more “let AWS operate the tools you already pay for.”
AWS vs. Microsoft Sentinel and Defender for Cloud
Microsoft’s answer to cloud-native security operations is split across two products that don’t map cleanly onto AWS’s single service. Microsoft Sentinel is a cloud-native SIEM and SOAR platform: customers bring their own data, build their own detection rules and playbooks, and pay primarily for data ingestion and retention volume, with cost shifting based on commitment tiers and connected data sources. Microsoft Defender for Cloud, by contrast, focuses on cloud security posture management, workload protection, and attack-path analysis, typically priced per protected resource or workload plan rather than per investigation.
Neither one is a direct substitute for what AWS just shipped. Sentinel expects the customer to operate the platform and write their own response logic. Defender for Cloud detects and scores risk but doesn’t hand a customer 24/7 human investigators by default. A Microsoft-centric security team chasing the same outcome as AWS Security Incident Response would likely need Sentinel or Defender XDR for detection, plus a separate managed SOC contract or incident-response retainer layered on top, since Microsoft doesn’t currently bundle a comparable per-finding managed response tier into either product’s public pricing.
AWS vs. Google Security Operations
Google’s equivalent lives under the Google Security Operations banner, the rebranded home of what used to be Chronicle. It combines SIEM, detection, investigation, and SOAR functionality in one platform, with a historical strength in retaining and searching huge volumes of telemetry cheaply. Pricing there tends to run on ingestion volume or committed data capacity rather than a small per-alert fee, which makes it a better fit for organizations that want one giant security data lake spanning multiple clouds, not just AWS.
That breadth versus depth trade-off is the throughline across all three hyperscalers. Google Security Operations is built for teams that want a central hunting ground across everything they run. AWS Security Incident Response is narrower by design: it’s cheap, fast to turn on, and tightly scoped to findings AWS’s own detection stack already produces. A team that lives almost entirely inside AWS gets more value per dollar from the native option. A team running meaningfully across AWS, Azure, and on-prem infrastructure will likely still need a cross-platform SIEM regardless of which hyperscaler’s response tooling they also buy.
AWS vs. Managed SOC Providers: CrowdStrike and Arctic Wolf
The more interesting comparison isn’t against another hyperscaler at all, it’s against the managed detection and response (MDR) vendors that have built entire businesses around exactly the staffing gap AWS is now addressing natively. CrowdStrike’s Falcon Complete and Arctic Wolf both offer full outsourced security operations: 24/7 analyst monitoring, but across endpoints, identity systems, email, network traffic, and cloud, not just AWS findings. Their scope typically extends to deploying and tuning the detection technology itself, not just triaging what a customer already has running.
Public list pricing for Falcon Complete or Arctic Wolf isn’t consistently published the way AWS’s per-finding rate is. Both vendors generally quote based on endpoint count, telemetry volume, contract length, and how much remediation authority the customer hands over, which makes a direct dollar-for-dollar comparison against AWS’s transparent tiered pricing difficult without a live quote. The comparison that matters more than price is scope, summarized below.
| Provider | Model | Pricing Structure | Coverage Scope | Best Fit |
|---|---|---|---|---|
| AWS Security Incident Response | Managed triage + investigation | Per finding, tiered, published publicly | AWS-native (GuardDuty/Security Hub findings) | AWS-heavy teams wanting low-cost, fast-start response |
| Microsoft Sentinel | Customer-operated SIEM/SOAR | Data ingestion and retention volume | Any connected source, customer-built rules | Teams wanting full control over detection logic |
| Microsoft Defender for Cloud | Posture management + workload protection | Per protected resource/workload plan | Cloud security posture, attack-path analysis | Teams prioritizing prevention over response |
| Google Security Operations | SIEM, detection, SOAR | Ingestion/committed data volume | Cross-cloud telemetry and threat hunting | Multi-cloud teams needing one data lake |
| CrowdStrike Falcon Complete | Full managed SOC | Quote-based (endpoints, scope, term) | Endpoint, identity, cloud, email, network | Organizations wanting a full outsourced SOC |
| Arctic Wolf | Full managed SOC | Quote-based (endpoints, scope, term) | Endpoint, identity, cloud, network | Organizations without any internal SOC function |
That table is really a map of trade-offs, not a ranking. AWS’s service is cheap and fast to switch on precisely because it does less: it won’t contain a compromised laptop, roll back an identity provider, or hunt through email headers. It triages and investigates what AWS’s own stack already flagged, then helps a human on the customer’s side decide what to do next. Falcon Complete and Arctic Wolf cost more, and you find out exactly how much more only after a sales call, because they’re selling the whole operation, not just the response desk sitting at the end of it.
Who This Actually Helps: The Mid-Market Gap
The customers with the most to gain aren’t the giants already paying for Enterprise Support, who get this for free, or the smallest startups generating too few findings to need it. It’s the stretch in between: companies running serious AWS workloads, generating tens of thousands of GuardDuty findings a month, but too small to justify a dedicated SOC team or a six-figure MDR contract. For that segment, a $0.000676 per-finding rate with a 10,000-finding free tier is a low-friction way to get expert eyes on alerts that would otherwise sit in a Security Hub dashboard nobody has time to read.
That’s also where the service’s narrowness becomes less of a weakness. A mid-market company that is genuinely AWS-first, with little legacy on-prem infrastructure and no sprawling multi-cloud footprint, doesn’t need Google’s cross-cloud data lake or a full CrowdStrike deployment across every endpoint in the building. It needs someone to look at the findings AWS already generates and tell it what to do before 2 a.m. turns into a public breach disclosure. AWS built a product for exactly that gap, and priced it to be an easy yes.
Modeling the Real Cost at Scale
It’s worth walking through AWS’s own worked example because it shows how the marginal pricing actually behaves once a company scales past the free tier. At 1.39 million findings in a month, the 10,000 free findings are gone immediately. The next 100,000 land in Tier 1 at $0.000676 each, costing about $67.60. The next 500,000 land in Tier 2 at $0.000538 each, costing about $269. The remaining roughly 780,000 findings fall into Tier 3 at $0.000430 each, costing about $335.40. Add it up and the total comes to $672.00 for the month, not the $597.70 AWS cites — that $597.70 figure is actually just the Tier 3 charge in AWS’s own 2 million-finding example, which totals $934.30.
That number only covers the Security Incident Response service itself. GuardDuty and Security Hub run on their own separate pricing, scaled by data sources, protection plans, and usage, and those bills can run considerably higher than the response layer sitting on top of them, especially for an organization with a large multi-account footprint running every GuardDuty protection plan at once. Anyone budgeting for this needs to model the whole detection-to-response pipeline, not just the headline per-finding rate AWS leads with on its pricing page.
A Quick Way to Check Your Own Exposure
Before enabling Security Incident Response, most teams will want a rough sense of how many findings they’re already generating, since that number drives the entire cost model above. GuardDuty’s own console and CLI expose finding counts per account, which is the fastest way to estimate where a workload lands on AWS’s pricing tiers before committing to anything.
aws guardduty list-findings \
--detector-id <your-detector-id> \
--finding-criteria '{"Criterion":{"severity":{"Gte":4}}}' \
--max-results 50Running that query across every active account and region, then multiplying by 30, gives a rough monthly estimate that maps directly onto the tier table above. Teams that come back with a number comfortably under 10,000 have an easy decision to make: there’s effectively no cost to trying the service. Teams well past that threshold should budget for Tier 1 and Tier 2 pricing before flipping the switch across an entire organization.
Market Impact: Pressure on the MDR Middle Tier
The segment of the security market most exposed to this launch isn’t the top-tier MDR vendors selling full cross-platform SOC contracts to large enterprises. It’s the smaller, AWS-focused managed security providers that have spent the last few years reselling GuardDuty and Security Hub monitoring as a service, essentially acting as the human triage layer AWS just decided to build itself. Those resellers now have to justify their margin against a native AWS option that starts free and scales to a few hundred dollars a month for mid-sized workloads.
That pressure doesn’t eliminate the market for those providers outright. Plenty of customers will still want a vendor relationship that spans more than AWS, or one willing to take on remediation authority AWS’s service doesn’t offer. But the pure “we watch your GuardDuty dashboard for you” business model just got a lot harder to sell at a premium, because the hyperscaler that produces the findings now also sells the response to them, at a price smaller resellers will struggle to beat.
Historical Context: From Alerts to Automated Response
GuardDuty launched years ago as a detection-only service: it flagged suspicious activity and left the customer to figure out what to do next. Security Hub came later to aggregate those findings across accounts and services into one dashboard. What’s shifted through 2026 is the next logical step in that chain: AWS moving from “here’s what we found” to “here’s what we’ll do about what we found,” first with automated remediation playbooks, and now with a managed, human-backed response tier that closes the loop entirely.
That progression mirrors what happened in enterprise security more broadly over the past decade. Detection tooling matured faster than the staffing needed to act on it, and vendors raced to fill the gap, first with better dashboards, then with automation, and now with bundled human expertise sold as a metered product. AWS arriving at that endpoint with a transparent, low per-unit price is less a surprising pivot than the predictable conclusion of a trend that’s been building since GuardDuty’s earliest days.
Risks and Limitations Worth Knowing Before You Enable It
A few caveats deserve attention before any team treats this as a full security-operations replacement. First, the service is only as good as the detection feeding it. A misconfigured GuardDuty rollout, with protection plans disabled in half the regions a company actually runs workloads in, leaves blind spots that no amount of downstream investigation talent can fix. Second, the pricing excludes GuardDuty and Security Hub costs entirely, so the headline per-finding rate understates the true cost of the full pipeline for anyone who hasn’t already budgeted for the upstream services.
Third, and most important for anyone comparing this to a full MDR contract, is scope. AWS Security Incident Response is scoped to AWS. It won’t investigate a phishing email that lands in a Google Workspace inbox, won’t contain a compromised laptop sitting on an office network, and won’t correlate an AWS finding with suspicious activity on an Azure tenant. Companies running meaningfully across multiple clouds, or with substantial on-prem infrastructure, still need a broader detection and response strategy that this service was never built to cover on its own.
Five Predictions for Where This Goes Next
- Microsoft and Google respond with comparable bundles. Expect Microsoft to tie a response tier more tightly into Defender’s existing per-workload pricing, and Google to package a similar triage layer around Security Operations, rather than leave AWS as the only hyperscaler selling metered human response.
- Smaller MDR resellers consolidate or pivot. Providers whose entire business was reselling GuardDuty monitoring face margin pressure and will likely either merge with larger MDR players or shift toward multi-cloud and on-prem coverage AWS doesn’t touch.
- Enterprise Support becomes a bigger upsell lever. Because Security Incident Response is free under Enterprise Support and Unified Operations, expect AWS account teams to lean on this bundling harder when pitching support-tier upgrades to mid-size customers sitting on Business Support.
- Finding volume becomes a cost-optimization target. Just as FinOps teams tune EC2 and S3 spend today, expect a parallel discipline to emerge around tuning GuardDuty suppression and Security Hub automation specifically to control Security Incident Response bills, not just alert fatigue.
- Cross-cloud correlation remains the unsolved problem. None of AWS’s, Microsoft’s, or Google’s native response offerings currently correlate findings across each other’s clouds, leaving multi-cloud shops dependent on third-party SIEMs for the foreseeable future, regardless of how cheap each hyperscaler’s own response tier gets.
How to Decide If You Need This
The decision tree is shorter than it looks. Companies already on Enterprise Support or Unified Operations have almost no reason not to enable it, since there’s no additional per-finding charge. Companies on lower support tiers with a heavy AWS footprint and a thin security staff should check their current GuardDuty finding volume using the CLI query above, then weigh the resulting monthly estimate against what they’re currently paying, in staff time or a third-party reseller fee, to triage those same findings manually.
Companies running substantial infrastructure outside AWS, or those that need remediation authority beyond investigation and guidance, should treat this as a complement to a broader MDR or SIEM strategy rather than a replacement for one. An independent breakdown of AWS’s native security tooling from Upwind makes a similar point: AWS’s security stack is genuinely strong for AWS-native workloads, but it was never designed to be the single security platform for an organization that lives across multiple environments.
Frequently Asked Questions
What is AWS Security Incident Response?
It’s a managed service from AWS that provides automated triage and AI-assisted investigation of security findings from GuardDuty and Security Hub, backed by 24/7 access to AWS security engineers for case handling and response guidance.
How much does AWS Security Incident Response cost?
The first 10,000 findings per month are free. After that, pricing is tiered: $0.000676 per finding for the next 100,000, $0.000538 per finding for the next 500,000, and $0.000430 per finding beyond 610,000 findings a month.
Is the service free for any customers?
Yes. Customers on AWS Enterprise Support or Unified Operations support plans get Security Incident Response included in their existing contract with no additional per-finding billing.
Does the price include GuardDuty and Security Hub?
No. AWS explicitly states that Security Incident Response charges don’t include GuardDuty or Security Hub usage costs, which are billed separately based on data sources, protection plans, and usage.
How is this different from Microsoft Sentinel or Google Security Operations?
Sentinel and Google Security Operations are broader SIEM and SOAR platforms the customer largely operates themselves, priced mainly by data ingestion and retention. AWS Security Incident Response is narrower: a managed, AWS-native triage and response layer priced per finding rather than per gigabyte ingested.
Can Security Incident Response replace a managed SOC provider like CrowdStrike or Arctic Wolf?
Not fully. Those providers cover endpoints, identity, email, and network telemetry across environments beyond AWS, and typically take on remediation authority AWS’s service doesn’t offer. Security Incident Response is best understood as a focused AWS-native complement, not a full SOC replacement.
How do I estimate my monthly cost before enabling it?
Use the AWS CLI to pull your current GuardDuty finding counts across all active accounts and regions, multiply by roughly 30 days, and map that estimate against AWS’s published pricing tiers to get a realistic monthly figure before turning the service on organization-wide.