GuardDuty vs Security Hub: When to Use Each AWS Security Service

Freshness Check (July 2026)

Use this page as a decision framework, then validate the latest pricing, quotas, and region-level feature parity in AWS documentation before final sign-off.

This page was refreshed against official AWS announcements and service documentation published in the last 12 months, including Security Hub AI inventory (14 July 2026). Confirm region support, quotas, and pricing before final architecture sign-off.

• AWS What’s New

GuardDuty and Security Hub are not competing services — they answer different questions. Confusing them leads to one of two wrong calls: turning on Security Hub and assuming behavioral threats are covered (they are not), or running GuardDuty without Security Hub and ending up with a stream of findings nobody can normalize across CIS, PCI DSS, NIST 800-53, or HIPAA. The same complementarity applies to AI: GuardDuty DNS feeds external-model discovery; Security Hub catalogs the estate and correlates findings.

This comparison is written for security architects deploying AWS-native detection on regulated workloads.

The Core Distinction

Security Hub is the aggregation and posture layer. Security Hub CSPM (continuous controls) evaluates your environment against security standards — AWS Foundational Security Best Practices, CIS AWS Foundations, PCI DSS 4.0, NIST 800-53 r5, HIPAA, and more — and emits normalized findings. The broader Security Hub service also correlates those posture findings with signals from other AWS services (GuardDuty, Inspector, Macie, and others) so teams can prioritize risk. Since July 2026 it also hosts AI inventory — org-wide discovery of managed, self-hosted, and external AI assets — using Config, Inspector SBOM, and GuardDuty DNS as inputs. It is not a substitute for GuardDuty’s standalone behavioral threat-detection models.

GuardDuty is the behavioral threat-detection layer. It analyzes CloudTrail management events, CloudTrail S3 data events, VPC Flow Logs, DNS query logs, EKS audit logs, RDS login events, and Lambda invocations — looking for cryptocurrency mining, credential exfiltration, anomalous API patterns, malware on EBS volumes, and EKS runtime compromises. It feeds findings into Security Hub.

The right way to think about it: GuardDuty is a finding source; Security Hub is a finding destination + standards evaluator.

What Each Service Detects

GuardDuty Foundation (CloudTrail-based):

• Anomalous IAM API patterns (suddenly listing all S3 buckets at 2 a.m. from a new IP)
• Credential compromise (CloudTrail events from regions you do not operate in)
• Cryptocurrency mining (Bitcoin protocol DNS queries)
• C2 communication (DNS queries to known threat-intel-listed domains)
• Recon activity (port scanning, IMDSv1 abuse)

GuardDuty Protection Plans (add-ons):

• S3 Protection — anomalous S3 data event patterns (mass GETs, unusual download volumes)
• EKS Protection — Kubernetes audit log analysis + runtime monitoring (kernel-level threat detection inside containers)
• RDS Protection — anomalous RDS login patterns (brute force, credential stuffing, unusual user behavior)
• Lambda Protection — anomalous Lambda invocation patterns
• EC2 Runtime Monitoring — kernel-level threat detection inside running EC2 instances (file access, process execution)
• Malware Protection — agentless EBS-snapshot malware scanning on triggered Lambda functions and EC2 instances

Security Hub:

• Finding aggregation across all AWS services + partner integrations
• Continuous standards checks (FSBP, CIS 1.4 + 2.0, PCI DSS 4.0, NIST 800-53 r5, HIPAA)
• Cross-account and cross-region centralization (delegated administrator pattern)
• Automation rules (auto-remediation, finding routing, custom severity overrides)
• Insight queries (custom dashboards over normalized findings)

Cost Comparison (2026)

GuardDuty Foundation is priced per CloudTrail management event and per GB of VPC Flow Logs / DNS analyzed. For a typical mid-market workload with 50M CloudTrail events/month, expect $200/month base. Protection plans:

• S3 Protection: $0.80 per million S3 data events, tiering down to $0.40 and $0.20 with volume
• EKS Audit Log: $1.60 per million events (first 100M), then $0.80
• EKS Runtime: $1.50 per vCPU-month (first 500 vCPUs), then $0.75
• RDS Protection: $1.00 per protected vCPU-month
• Lambda Protection: per GB of Lambda network activity, on the VPC Flow Log tiers
• EC2 Runtime: ~$1.50 per vCPU per month (hourly metered)
• Malware Protection for S3: $0.09 per GB scanned plus $0.215 per 1,000 objects; EBS malware scans $0.03 per GB

Mid-market regulated workloads typically land at $300–$2,000/month for GuardDuty.

Security Hub Essentials (2025 reprice) bills per protected resource per month — $0.0010 per AWS resource per month for security checks, plus per-finding ingestion charges from external sources. Mid-market regulated workloads land at $300–$1,500/month. Unlimited control checks and findings within scope; cross-region aggregation included.

Combined typical mid-market spend: $600–$3,500/month for the GuardDuty + Security Hub pair on a regulated workload.

Decision Framework

Turn on Security Hub if you have any of:

• More than two AWS accounts (cross-account aggregation is the headline value)
• A compliance framework that asks for continuous controls evaluation (SOC 2 CC7, PCI DSS Req 10–11, HIPAA §164.308, ISO 27001 A.8.16)
• Partner security tools (CrowdStrike, Wiz, etc.) you want to centralize
• A SIEM or GRC tool that needs a single AWS-side feed

Turn on GuardDuty if you have any of:

• Production workloads (the answer is “always” for production)
• Internet-exposed resources (EC2, ALB, API Gateway, S3 with public read)
• IAM principals beyond a small core team (insider-threat coverage)
• Containers or Lambda in production
• RDS or Aurora handling regulated data

In practice: enable both on every regulated production workload from day one. The combined cost is a fraction of one breach, and the deployment is a single Terraform module.

Deployment Pattern We Use

For multi-account AWS Organizations:

1. Designate the Security account as Security Hub delegated administrator — all findings aggregate there
2. Enable GuardDuty Organization-wide with auto-enrollment on new accounts
3. Enable Security Hub Organization-wide with the AWS Foundational Security Best Practices and any framework-specific standards (PCI DSS, NIST 800-53)
4. Enable Macie selectively on accounts that hold sensitive data (full-account is overkill)
5. Enable Inspector v2 on every account with EC2 / ECR / Lambda
6. Wire EventBridge rules in the Security account to fan critical findings to PagerDuty and Slack
7. Connect Security Hub to your GRC tool (Vanta, Drata, Secureframe) via the read-only integration

The full pattern is documented in our GuardDuty production guide, Security Hub setup guide, and Security & Compliance hub.

When You Outgrow Native AWS

Native AWS detection works for AWS-only estates. You start to need a third-party tool when:

• You span multi-cloud (AWS + Azure or GCP) and need a single posture view
• You need attack-path graphs (Wiz, Orca, Lacework) beyond per-finding severity
• Your SOC lives in Splunk, Sumo Logic, Microsoft Sentinel, or Google Chronicle and the integration cost of “Security Hub → SIEM” outweighs the duplication of a CSPM that lives in the SIEM directly

For most regulated SaaS, healthtech, and fintech in AWS-only estates, the native pair (GuardDuty + Security Hub + Inspector v2 + Macie) is the right call. We size up to a third-party CSPM only when one of the conditions above triggers it.

Related Reading

• AWS Cloud Security service — assessment, hardening, monitoring
• Managed SOC & MDR — 24/7 detection and response
• Threat Detection subtopic hub — full curated guide set
• Security & Compliance hub — frameworks, services, and tools