AWS GuardDuty vs Security Hub: The Actual Difference and When You Need Each

GuardDuty is a managed threat detection service. It continuously analyzes three data sources that AWS makes available to it:

1. AWS CloudTrail management events: Every API call made in your AWS account: RunInstances, CreateUser, DescribeSecurityGroups, GetSecretValue. GuardDuty looks for patterns indicating credential compromise (API calls from an unusual geography for that IAM user, calls to services the user has never used, API calls at 3 AM), account reconnaissance (extensive DescribeX calls to enumerate resources), and persistence establishment.

2. VPC Flow Logs: Network traffic metadata for your EC2 instances and VPCs. GuardDuty looks for communications with known malicious IP addresses, cryptocurrency mining pool connections, and unusual traffic patterns indicating C2 communication.

3. Route 53 DNS query logs: DNS queries from your EC2 instances. GuardDuty looks for queries to domain generation algorithm (DGA) domains, known C2 infrastructure, and coin mining pools.

GuardDuty does not require you to enable or forward these logs yourself: it accesses them directly through the AWS service API. This is one of its primary advantages: zero configuration overhead for the log sources.

What GuardDuty produces: Findings categorized by threat type (Backdoor, CryptoCurrency, DefenseEvasion, Discovery, Exfiltration, Impact, InitialAccess, Persistence, PrivilegeEscalation, Recon, Stealth, Trojan, UnauthorizedAccess) and severity (1-10). Each finding includes the affected resource, the specific behavior detected, and remediation recommendations.

What GuardDuty does not do: It does not check whether your S3 buckets are public, whether your IAM roles are over-permissioned, or whether your Security Groups allow unnecessary inbound traffic. Those are configuration issues, not active threats: they are Security Hub's domain.

Security Hub is an aggregation and posture management service. It has two main functions:

Function 1: Findings aggregation. Security Hub collects findings from multiple AWS security services into a single unified view:

• GuardDuty (threat detections)
• Amazon Inspector (vulnerability assessment for EC2 and container images)
• Amazon Macie (sensitive data in S3: PII, credentials, financial data)
• IAM Access Analyzer (external resource access and permission analysis)
• AWS Firewall Manager (WAF policy compliance)
• Third-party integrations (CrowdStrike, Palo Alto, Splunk, etc.)

Without Security Hub, each of these services has its own console, its own alert mechanism, and its own data format. Security Hub normalizes all findings to the AWS Security Finding Format (ASFF) and presents them in a single dashboard with filtering, sorting, and workflow management.

Function 2: Security standards and compliance checks. Security Hub continuously evaluates your AWS account configuration against security benchmark standards:

• CIS AWS Foundations Benchmark (Level 1 and Level 2)
• AWS Foundational Security Best Practices
• PCI DSS
• NIST SP 800-53
• SOC 2 (through AWS Audit Manager integration)

These checks evaluate things like: Is MFA enabled on the root account? Are CloudTrail logs encrypted? Are S3 buckets blocking public access? Are security group rules following least-privilege principles? Does your account have IAM password policies enforced?

Each check produces a pass/fail result with a remediation recommendation. Your aggregate Security Hub score reflects the percentage of passing controls.

GuardDuty produces active threat findings. Security Hub aggregates them alongside configuration findings and vulnerability findings into a unified view.

The integration is two-click to enable: in Security Hub, go to Integrations > AWS > Amazon GuardDuty > Accept findings. GuardDuty findings then appear in Security Hub alongside Inspector vulnerability findings and Macie data classification findings.

Why the combination matters:

A GuardDuty finding tells you: 'EC2 instance i-1234567890abcdef0 is communicating with a known cryptocurrency mining IP.'

The Security Hub context for that same instance might show: 'This EC2 instance has an Inspector finding for CVE-2024-1234 (CVSS 9.8) that was not patched, a public Security Group rule allowing SSH from 0.0.0.0/0, and is in a subnet with no VPC Flow Log monitoring.'

The combination reveals that the compromised instance had multiple configuration weaknesses that likely enabled the compromise. Without Security Hub, you are triaging the active threat without the configuration context. Without GuardDuty, you have configuration findings but no real-time threat detection.

The EventBridge integration for automated response:

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "severity": [{"numeric": [">", 7]}]
  }
}

This EventBridge rule triggers on high-severity GuardDuty findings and can invoke Lambda functions to automatically isolate affected EC2 instances, revoke IAM credentials, or notify your SOC via SNS.

Both services offer 30-day free trials. Evaluate them in trial mode before committing to production costs.

GuardDuty pricing (approximate):

• CloudTrail analysis: $3.50 per 1 million management events
• VPC Flow Log analysis: $1.00 per GB analyzed
• DNS log analysis: $1.00 per 1 million DNS queries

For a small AWS environment (< 10 EC2 instances, moderate API activity), GuardDuty typically costs $10-30/month. For large environments with high API activity and traffic volumes, costs scale accordingly: use the 30-day trial to establish your baseline cost.

Security Hub pricing:

• $0.0010 per finding ingested per month (first 10,000 findings free)
• $0.001 per security check per account per month

Security Hub costs are typically lower than GuardDuty for most environments: roughly $5-20/month for standard deployments.

When to enable GuardDuty: Enable it in every AWS account, immediately. The threat detection value is high and the cost is low. There is no valid reason to operate an AWS account without GuardDuty enabled: the 30-day trial is enough to evaluate it, and the cost to continue is low enough that disabling it after trial is a poor security tradeoff.

When to enable Security Hub: Enable it when you are ready to act on configuration findings. Security Hub's value is in the compliance checks: if you enable it and ignore the findings, it provides no security benefit. Enable it when you have at least part-time capacity to review and remediate configuration findings.