GuardDuty & Security Hub Together

Threat detection findings feeding a centralized security-posture dashboard.

A common first question when picking up AWS's security-detection tools is why there are two of them. GuardDuty and Security Hub are not competitors and not redundant - they sit at different layers of the same pipeline. GuardDuty watches your account's activity and tells you when something looks wrong. Security Hub collects everything anyone is telling you (GuardDuty included) and turns it into one dashboard with one compliance score. Understanding that division early saves you from either duplicating effort or missing half the picture.

Summary

• GuardDuty is a detective control: it continuously analyzes logs and telemetry and emits findings when it spots suspicious behavior.
• Insight: GuardDuty never takes action on its own - it surfaces findings, and any response (isolating a host, revoking a credential) is something you build separately.
• Key Concepts: detection vs aggregation, the Amazon Security Finding Format (ASFF), automatic finding ingestion, compliance standards and scores.
• When to Use: enable GuardDuty for threat detection in every account/region; enable Security Hub on top when you need one aggregated view and a compliance posture score across multiple sources or accounts.
• Limitations/Trade-offs: Security Hub does not replace GuardDuty's detection logic - it has no findings of its own to show if nothing feeds it. Both charge separately and both need to be enabled per region.

Foundations

GuardDuty is a managed threat-detection service. Once you enable it in a region (CreateDetector), it starts analyzing VPC Flow Logs, DNS query logs, and CloudTrail management/S3 data events automatically - no log shipping or agent install required. Optional data sources add deeper coverage: EKS audit logs for Kubernetes-specific threats, S3 data events for bucket-level anomalies, and Malware Protection for EBS-volume scanning triggered by suspicious findings. The output is a stream of findings - structured records like UnauthorizedAccess:EC2/SSHBruteForce - each with a type, a severity score from 0 to 10, and the resource involved.

Security Hub is a findings aggregator and compliance scorer. It does not watch your infrastructure directly. Instead, once enabled (EnableSecurityHub), it receives findings pushed to it in the AWS Security Finding Format (ASFF) - a common schema that GuardDuty, Inspector, Macie, IAM Access Analyzer, and third-party partner tools all speak. Security Hub also runs standards - CIS AWS Foundations Benchmark, AWS Foundational Security Best Practices - that check your account configuration against a rule set and roll the results into a compliance score.

# --- Python (boto3) ---
import boto3
 
guardduty = boto3.client("guardduty", region_name="us-east-1")
securityhub = boto3.client("securityhub", region_name="us-east-1")
 
# Enable GuardDuty in this region
detector = guardduty.create_detector(Enable=True)
detector_id = detector["DetectorId"]
 
# Enable Security Hub in the same region
securityhub.enable_security_hub(EnableDefaultStandards=True)

// --- TypeScript (AWS SDK v3) ---
import { GuardDutyClient, CreateDetectorCommand } from "@aws-sdk/client-guardduty";
import { SecurityHubClient, EnableSecurityHubCommand } from "@aws-sdk/client-securityhub";
 
const guardduty = new GuardDutyClient({ region: "us-east-1" });
const securityhub = new SecurityHubClient({ region: "us-east-1" });
 
// Enable GuardDuty in this region
const detector = await guardduty.send(new CreateDetectorCommand({ Enable: true }));
const detectorId = detector.DetectorId;
 
// Enable Security Hub in the same region
await securityhub.send(new EnableSecurityHubCommand({ EnableDefaultStandards: true }));

Once both are enabled, no wiring code is needed for findings to flow - Security Hub automatically ingests GuardDuty findings for accounts where it is enabled in the same region.

Mechanics & Interactions

Who does what. Think of GuardDuty as a sensor and Security Hub as a control room. GuardDuty's job ends when it produces a finding. Security Hub's job starts when a finding (from GuardDuty or elsewhere) arrives - it normalizes it into ASFF, applies workflow state (NEW, NOTIFIED, RESOLVED), and shows it next to findings from every other integrated service.

Automatic ingestion, not push code. You do not call an API to send a GuardDuty finding into Security Hub. As long as GuardDuty and Security Hub are both enabled in the same account and region, the integration happens behind the scenes. Third-party or custom findings that are not natively integrated use BatchImportFindings to submit ASFF records directly - GuardDuty does not need this path.

One score, many inputs. Security Hub's compliance score comes from standards subscriptions, evaluated independently of whatever findings GuardDuty produces. A clean GuardDuty feed (no active threats) does not mean a high compliance score - the score reflects configuration checks (encryption settings, public access blocks, IAM policies), which is a different question from "is someone attacking us right now."

Regional scope. Both services are regional. Enabling GuardDuty in us-east-1 does not detect anything in eu-west-1, and Security Hub in one region only aggregates findings pushed to it in that same region. Multi-region coverage means enabling both, per region, or using the Organizations-based delegated-administrator pattern to do it centrally.

Advanced Considerations & Applications

Where this leads. Once findings land in Security Hub, two natural next steps open up: reacting automatically to individual GuardDuty findings via EventBridge and Lambda, and rolling multiple accounts' findings up to one place via AWS Organizations. Both build directly on the detector and Security Hub subscription created here.

Cost shape. GuardDuty bills by volume of analyzed data (events, flow log volume); Security Hub bills per finding ingested and per compliance check run. Running both is the standard production posture, but at scale, it is worth watching both services' cost dashboards rather than assuming a fixed line item.

Independent lifecycles. You can run GuardDuty without Security Hub (you just lose the unified view and compliance scoring) or, less commonly, Security Hub without GuardDuty (you would only see findings from whatever other sources you connect - much thinner coverage). In practice nearly every account runs both.

Common Misconceptions

• "Security Hub detects threats." - No. It aggregates and scores findings from services that detect threats, GuardDuty chief among them. It has no detection logic of its own.
• "GuardDuty findings need to be exported to Security Hub." - No. Ingestion is automatic once both are enabled in the same account/region - there is no export or push step to write.
• "A high Security Hub score means no active threats." - No. The compliance score comes from standards checks (configuration), which is separate from whether GuardDuty is currently reporting active findings.
• "Enabling one enables the other." - No. Each has its own enable call (CreateDetector for GuardDuty, EnableSecurityHub for Security Hub) and its own per-region activation.
• "GuardDuty will fix what it finds." - No. GuardDuty only reports. Any remediation - isolating an instance, revoking credentials - is something you build via EventBridge and Lambda.

FAQs

Related

• Threat Detection Basics - enable GuardDuty and list findings end to end.
• GuardDuty Detectors & Finding Types - data sources and severity in depth.
• Security Hub Standards & Compliance Scores - how the compliance score is computed.
• Automated Response to GuardDuty Findings - wiring findings to remediation.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).