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

<div class="quick-answer">

**Quick Answer:** Security Hub is the aggregation and standards-evaluation layer. GuardDuty is the behavioral threat-detection feed that flows into it. You need both — Security Hub alone has no anomaly detection; GuardDuty alone has no continuous standards checks or normalized severity.

</div>

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.

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. 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.10–$1.00 per million S3 data events (scales with traffic)
- EKS Audit Log: $1.00 per million events
- EKS Runtime: $4.50 per vCPU per hour for monitored workloads
- RDS Protection: $0.20 per RDS login event
- Lambda Protection: per invocation, varies
- EC2 Runtime: ~$1.50 per vCPU per month (hourly metered)
- Malware Protection: $0.05 per GB scanned

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](/blog/aws-guardduty-threat-detection-production-guide/), [Security Hub setup guide](/blog/how-to-set-up-aws-security-hub-compliance-monitoring/), and [Security & Compliance hub](/security-compliance/).

## 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](/services/aws-cloud-security/) — assessment, hardening, monitoring
- [Managed SOC & MDR](/services/aws-managed-soc-mdr/) — 24/7 detection and response
- [Threat Detection subtopic hub](/security-compliance/threat-detection/) — full curated guide set
- [Security & Compliance hub](/security-compliance/) — frameworks, services, and tools