AWS Security Hub vs GuardDuty vs Inspector: Honest Take

Every AWS security review eventually runs into the same conversation: which of these three services should we be paying for, and do we still need a third-party platform on top? The AWS console makes them look like a coherent product line. They are not. Security Hub, GuardDuty, and Inspector were built by different teams, ship findings in different shapes, and solve genuinely different problems — even though their marketing pages overlap enough to leave most engineers confused. After years of standing up these services as part of AWS security hardening engagements, the honest take is that the right combination depends on what you’re actually defending and how much manual triage your team can absorb. This is the field-level comparison: what each service detects, where they quietly overlap, the cost shape that surprises everyone in month two, and where they collectively leave you blind.

The three-service confusion — what people get wrong from day one

The most common misconception, repeated across blog posts and even some AWS documentation, is that the three services are tiers of the same product. They are not.

What people assume

The mental model engineers build on day one usually looks like: GuardDuty does network detection, Inspector does host scanning, Security Hub combines them, so turning on Security Hub gets you both. This is wrong on every count.

What’s actually true

Security Hub does not enable GuardDuty or Inspector for you. It does not generate detection findings of its own — it ingests findings from other services and applies a layer of standards-mapping (CIS, NIST, PCI DSS, AWS Foundational Security Best Practices) on top. If GuardDuty and Inspector aren’t enabled, Security Hub will dutifully report on its own standards checks (which are static config assessments, not behavioural detection) and stay quiet on threats and vulnerabilities — leaving teams convinced they have visibility they don’t.

The three services are best understood as three independent products that happen to use the same finding format (AWS Security Finding Format, ASFF) and feed into a common aggregation point. Each has its own bill, its own enablement decision, and its own failure modes.

What each service is actually designed for

GuardDuty: continuous threat detection from log streams

GuardDuty is a managed intrusion detection service. It consumes CloudTrail management events, CloudTrail data events (optional), VPC Flow Logs, DNS query logs, EKS audit logs, RDS login activity, Lambda invocation telemetry, and S3 data plane events — then applies a mix of signature-based, anomaly-based, and threat-intel-correlated detection rules to surface suspicious activity.

The output is a finding: “EC2 instance i-0abc1234 is communicating with a known cryptocurrency mining domain,” “IAM principal X is using a session token from an unusual geographic region,” “a role assumption pattern matches credential-stuffing behaviour.” These are behavioural detections — they tell you something is happening, not that something is misconfigured.

Inspector: agentless vulnerability scanning for compute

Inspector v2 (the current generation, launched 2021 and significantly evolved since) is a vulnerability management service. It continuously scans EC2 instances, container images in Elastic Container Registry, and Lambda functions for known CVEs against the OS packages and application dependencies it finds. EC2 scanning is via the SSM agent (so SSM must be configured); ECR scanning is at push and rescan-on-CVE-disclosure; Lambda scanning is on deploy and rescan as the vulnerability database updates.

The output is a finding: “CVE-2025-12345 affects libxml2 on this instance,” “this container image has 14 high-severity packages,” “this Lambda runtime version is past EOL.” These are configuration-state findings — they tell you something is vulnerable, not that anyone is exploiting it.

Security Hub: aggregator with compliance overlay

Security Hub is two services in one trench coat. The first half is a finding aggregator — it ingests ASFF findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, Health, Detective, and 60+ third-party tools, deduplicates them, applies severity normalization, and gives you a single dashboard. The second half is a compliance checker — it runs continuous static config checks against your environment mapped to standards like AWS FSBP, CIS Benchmarks v1.4 and v3.0, NIST 800-53, and PCI DSS, generating its own findings that look just like ingested ones.

The output of the compliance checker is a finding: “S3 bucket public-uploads has block public access disabled,” “EBS volume vol-abc is not encrypted,” “this IAM user has not rotated their access key in 90 days.” These look like Inspector-style findings but they’re config drift checks, not CVE scans.

Pricing in 2026 — the bill that surprises everyone

Each service prices on different dimensions, and the interactions matter.

The compounding shape catches teams off guard. Enabling all three across a multi-account org with hundreds of resources, a busy CloudTrail, and active EKS clusters can move the monthly bill from “barely noticeable” to “needs a budget conversation” inside one billing cycle. Test in one account, observe the bill shape, then expand.

The other failure mode: teams disable a sub-feature (say, GuardDuty S3 Protection) to control cost, then later get breached via the channel they turned off. The cost-versus-coverage trade-offs should be documented decisions, not silent omissions.

Detection coverage — head to head on the categories that matter

The pattern is consistent: GuardDuty owns runtime/behavioural; Inspector owns vulnerability state; Security Hub owns config compliance plus aggregation. The categories none of them cover well — insider abuse using legitimate creds, business-logic abuse, application-layer attacks against your code — need separate investment.

Where GuardDuty’s signal actually comes from

Understanding GuardDuty’s signal sources is the difference between a useful deployment and a noisy one.

CloudTrail management events

The single most important input. GuardDuty consumes all CloudTrail management events from the regions it’s enabled in (you do not pay for CloudTrail twice). The detections this powers: anomalous API call patterns, unusual geographic location for IAM activity, root account usage, detection of compromised access keys via known leaked-credential databases, suspicious AssumeRole patterns, IAM enumeration.

VPC Flow Logs

GuardDuty does not require you to enable VPC Flow Logs separately — it analyses them at the hypervisor level. Detections from this stream: communication with known malicious IPs and domains, port scanning behaviour from EC2, cryptocurrency mining traffic, EC2 acting as botnet C2 client, unusual outbound traffic patterns.

DNS query logs

DNS queries from EC2 instances using the default VPC resolver are inspected. Detections: DNS tunneling for data exfiltration, queries to known malware/C2 domains, DGA (domain generation algorithm) patterns, fast-flux detection. The blind spot: instances using third-party DNS resolvers bypass this entirely.

EKS audit logs

If EKS Protection is enabled, the Kubernetes API audit logs are streamed into GuardDuty. Detections: anonymous API access, exec-into-pod activity, privileged container creation, suspicious service account behaviour, kubectl from outside the cluster’s normal client set.

Malware Protection

GuardDuty Malware Protection for EC2 takes a snapshot of EBS volumes attached to instances flagged by other GuardDuty findings, then runs a file-based malware scan against the snapshot. This is your only signature-based malware scanning option natively in AWS — Inspector does not do this. The trade-off: scans run only on demand, are billed per GB, and add latency to investigation.

A common operational pattern is to enable everything except Lambda and S3 Protection, watch the bill for a billing cycle, then turn those on selectively per account based on cost-benefit.

Inspector — vulnerabilities, not detections

Inspector v2 is often misunderstood because Inspector v1 (the deprecated classic version) was a host-agent-based scanner that worked very differently. The current Inspector is agentless from the user’s perspective.

EC2 scanning and the SSM agent dependency

EC2 vulnerability scanning works by Inspector calling the SSM Run Command API against your instances to inventory installed packages, then matching them against the National Vulnerability Database. This requires the SSM agent installed, registered, and reachable — meaning your instances need either the SSM endpoint reachable via the public internet or VPC endpoints for SSM/EC2 Messages.

The single biggest reason Inspector reports zero findings on an account that absolutely has CVEs: SSM agent not registered. Always verify SSM Fleet Manager shows your instances before trusting Inspector’s “no findings” state.

ECR image scanning

ECR images are scanned at push, then re-scanned automatically when new CVEs are disclosed against packages already in the image. The enhanced scanning mode (paid) covers OS packages plus application dependencies (npm, Python, Java, Go, Ruby, Rust). The basic mode (free) only covers OS packages and only at push time.

For container-heavy environments, the enhanced mode is generally worth it — but be aware that long-running images that haven’t been pulled in 90 days drop out of scanning unless you’ve configured Inspector to scan them on-demand.

Lambda function scanning

Lambda scanning has two tiers. Standard scanning ($0.30/function/month) covers third-party dependencies and runtime versions. Deep scanning ($1.25/function/month) adds application code scanning for vulnerabilities and embedded secrets. Deep scanning is generally only justified for production functions handling sensitive workloads — applying it to every dev/test function makes the bill spike.

Security Hub — what it actually does for you

The Security Hub value proposition is less about detection (it generates its own only for config drift) and more about workflow.

Standards compliance checks

The compliance checker continuously evaluates your account against the standards you’ve enabled. AWS FSBP is enabled by default; the others (CIS v1.4, CIS v3.0, NIST 800-53, PCI DSS) are opt-in. Each standard is a set of controls, and each control maps to one or more compliance checks — most automated via AWS Config rules running behind the scenes.

The catch: enabling more standards means more checks, which means more billing (per-check pricing), and more findings noise — controls overlap significantly between FSBP, CIS, and NIST. Picking one primary standard and treating the others as secondary is usually the right call.

Finding aggregation and dedup

Security Hub ingests ASFF-formatted findings from native services (GuardDuty, Inspector, Macie, etc.), cross-account via the Security Hub aggregator, and from third-party tools (Wiz, Lacework, Crowdstrike, Sentinel One, Snyk, others). It then groups identical findings, applies a normalized severity, and gives you one searchable surface.

The deduplication is good but not perfect — the same vulnerability reported by Inspector and a third-party agent will often appear twice unless you write a suppression rule. For teams with overlapping tools, the cleanup work is real.

Automation actions and EventBridge

The single most valuable feature, underused in practice, is the EventBridge integration. Every finding state change becomes an event you can route to Lambda, SNS, SQS, Step Functions, or any EventBridge target. This is how findings become tickets, Slack alerts, auto-remediation actions, and SIEM ingestion.

A common automation pattern, using CloudFormation:

Resources:
  HighSeverityFindingRule:
    Type: AWS::Events::Rule
    Properties:
      Name: securityhub-high-severity-to-slack
      EventPattern:
        source: ["aws.securityhub"]
        detail-type: ["Security Hub Findings - Imported"]
        detail:
          findings:
            Severity:
              Label: ["HIGH", "CRITICAL"]
            Workflow:
              Status: ["NEW"]
            RecordState: ["ACTIVE"]
      Targets:
        - Id: SlackNotifier
          Arn: !GetAtt SlackNotifierFunction.Arn

This pattern is the backbone of most production SIEM-light deployments. Done well, it cuts finding triage burden by an order of magnitude.

Multi-account at scale — where everything quietly breaks

Single-account deployments are simple. Multi-account organizations — which is the recommended landing zone shape — introduce failure modes that are easy to miss.

GuardDuty Organization-wide enablement

GuardDuty supports a delegated administrator account per organization. Member accounts are enrolled automatically, with findings centralised. The pitfall: regions. GuardDuty must be enabled per region per account, even with org delegation — there is no “enable in all regions” toggle by default. New regions added by AWS don’t auto-enable. Teams expanding into new regions for the first time often discover GuardDuty was silently absent for months.

Security Hub aggregation regions

Security Hub findings can be aggregated to a single “home” region, but the aggregation is one-way and cross-region replication of state changes (ticketing, suppression) is asymmetric. A finding suppressed in the aggregator does not propagate suppression back to the source region’s Security Hub instance — you’ll see the same finding back on the next sync if you only suppress in the aggregator.

Inspector cross-account scanning

Inspector supports delegated administration. The most common breakage is when accounts are added to the organization after Inspector was enabled — the new account is not auto-enrolled unless AutoEnable is set on the org-wide Inspector configuration. Always verify Inspector status after every org account addition.

Real-world false positive rates

Numbers from production deployments across mid-market and enterprise accounts:

The implication: every service needs a tuning pass before its findings stream becomes operationally usable. Untuned, Inspector ECR findings will swamp Slack within a day for any team with active CI. Tuned (severity threshold, finding suppression rules, dev-vs-prod tagging), it becomes one of the higher signal-to-noise feeds in your stack.

Integration with non-AWS tooling

ASFF is the lingua franca. Most enterprise security platforms — Wiz, Lacework, Orca, Crowdstrike Falcon Cloud, Palo Alto Prisma Cloud, Snyk, Mend, Sentinel One — both consume from Security Hub via ASFF and publish back to it. This lets Security Hub serve as a hub even if your primary triage tool is third-party.

The reverse path matters more for SIEM integration. Findings can be routed via EventBridge → Kinesis Firehose → Splunk/Sentinel/Elastic/Sumo Logic. This is the recommended path; trying to bring Security Hub findings into a SIEM via its REST API will hit pagination and rate-limit issues at scale.

For organizations layering a CNAPP (Wiz, Orca, Lacework) on top, the question is whether the native AWS services still earn their keep. Usually yes for GuardDuty (the behavioural detections are genuinely complementary to CNAPP’s posture/runtime split), and arguably no for Inspector (CNAPPs do CVE scanning at least as well and often with better runtime context). Security Hub stays valuable as the aggregator regardless.

When you don’t need any of them

There are scenarios where the AWS-native services are not the right answer:

• Single-account dev environments with no production traffic: enabling all three creates noise without proportional risk reduction. Wait until production-readiness.
• Multi-cloud organizations where AWS is one of several clouds: a CNAPP that spans AWS, Azure, GCP, and Kubernetes will produce a more coherent operational story than running three different cloud-native stacks.
• Mature security teams already running Wiz or Orca for full CNAPP coverage: GuardDuty for behavioural detection is the only one of the three that consistently earns its bill in this scenario.
• Cost-constrained startups in pre-revenue: enable GuardDuty foundational and Security Hub with AWS FSBP only. Skip Inspector and the GuardDuty add-ons until the engineering team grows past 10.

For a deeper dive into the broader landscape, see our cloud penetration testing methodology across AWS, Azure, and GCP and AWS security hardening critical configurations guides. The cloud security assessment service walks through the tooling-versus-architecture trade-offs in real engagements.

The honest recommendation — which to enable in what order

For a team standing up AWS security from zero:

1. Week 1: Security Hub with AWS FSBP standard enabled across all accounts and regions, delegated admin in a security tooling account. This establishes the aggregation backbone and gives you a config-drift baseline immediately.
2. Week 2: GuardDuty foundational across all accounts and regions, delegated admin in the same tooling account, findings auto-routed to EventBridge. This catches active threats fast.
3. Week 3: Inspector EC2 + ECR scanning in production accounts only. Tune severity threshold, suppress dev/test noise via finding filters.
4. Week 4: EventBridge automation — findings to Slack/PagerDuty/ticketing. This is what turns a service deployment into a working detection program.
5. Month 2: Evaluate GuardDuty add-ons (S3, EKS, RDS, Lambda Protection) per workload — enable selectively based on actual data flow, not blanket coverage.
6. Quarter 2: If CNAPP budget exists, layer Wiz/Orca/Lacework for the gaps these three don’t cover — primarily lateral movement reconstruction, identity attack paths, and cross-cloud posture.

None of these services replace continuous vulnerability management, application-layer pen testing, or managed SOC monitoring. They cover specific layers of the cloud stack well. Treating them as a complete security program is the most common mistake teams make after enablement.

The three services aren’t competing — they’re complementary. The argument was never which one to pick. It’s which combination, at what cost, with what tuning, leaves your team confident they’d see an attack in time to do something about it.