GuardDuty vs. Security Hub vs. Detective vs. Inspector vs. Macie: the role division and technology selection of AWS security services

"I introduced GuardDuty, so the thinking is that with this I need neither Security Hub, Inspector, nor Macie — is that right?" — it's one of the most repeatedly heard questions in the place of being consulted on AWS security design.

The answer is "No, you need all of them (precisely, all of them do a different job)." This misunderstanding is very natural. The console's "security" category lines up similarly-named services, and they all seem to "emit findings (detection results)." But line up their substance in one line each and you immediately see they don't compete — GuardDuty "detects" threats, Security Hub "aggregates and prioritizes" the results, Detective "investigates the root cause," Inspector "scans vulnerabilities," and Macie "classifies sensitive data." Even the same "security," the data they look at, what they do, and their lifecycle position all differ.

This article is a guide to verbalize the role division of these 5 (+ the adjacent AWS Config) to a level where the person you consult (or a client) never confuses them again. It fixes each service's "one-line job / data handled / lifecycle position," untangles the easily-confused pairs (GuardDuty ≠ Inspector, GuardDuty ≠ Macie, Security Hub ≠ GuardDuty), and runs through a decision frame of "if you need X, use Y" and how to bundle them with EventBridge + Security Hub into one defense system.

The standalone production design of GuardDuty (protection-plan selection, organization-wide enabling, EventBridge automated response) is handled in the main of a separate article. This article is one level above — concentrating on how to draw "the map of AWS security services" and where to place what. As material, I also weave in my experience cross-implementing IAM, observability, and DR on a multi-account AWS serverless payment platform — because it handles actual money, carbon credits, and local currency, I needed to solidify the layers of detection, investigation, vulnerability, and data protection with separate tools.

Rules for this article: each service's definition, target data, and lifecycle role are based on the AWS official documentation (as of June 2026). Supported resources, finding types, integration destinations, and pricing are revised, so always confirm the latest official information before production rollout. And this article's consistent claim — these are not substitutes competing for "which is strongest" but complementary layers of defense-in-depth. A design aiming for "one for everything" will always leave a hole somewhere. I bind myself to not exaggerating each service's scope by one millimeter from the official descriptions.

0. Mental model: the 5 differ in "verb"

Before design, fix the 5 (+1) in one matrix. What to memorize is not the names but the "verb."

This table is the whole of this article. The following chapters merely back up each line with the official words, untangle confusion, and connect them. Three conclusions up front.

1. Things with different verbs don't compete. "Detection (GuardDuty)" and "vulnerability assessment (Inspector)" work on the same threat from different angles. One never substitutes for the other.
2. Only Security Hub is different in nature. Security Hub doesn't "detect" new threats. It's an aggregation layer that gathers the findings the other 4 (+ partners) emit, and additionally a posture checker that checks against AWS standards. Lining it up with "detection engines" to discuss superiority is the very source of the misunderstanding.
3. The 5 connect through findings. The findings each service emits are aggregated in Security Hub, flow to automated response in EventBridge, and GuardDuty's findings can be dug into with Detective. Design them not as scattered tools but as one pipeline (chapter 7).

0.1 The "detect / aggregate / investigate / assess / classify" matrix

Let's raise the resolution one more notch. Cut the horizontal axis as the action of security operation and the vertical axis as lifecycle, and you see that the 5 (+ Config) don't overlap at all and divide territory. This is why the question "which is strongest" doesn't hold.

How to read:

• Read one column vertically and you see "what to use in that phase." Example: mid-breach is detect with GuardDuty → aggregate with Security Hub. Post-breach is investigate with Detective.
• Read one row horizontally and you see "which service that action is exclusive to." Detection is GuardDuty only, investigation is Detective only, classification is Macie only — roles are unique.
• Only Security Hub lies across all phases. This is the diagram of "Security Hub is different in nature from the others (an aggregation layer)."

1. GuardDuty: detect "behavioral threats" from logs

In a word: GuardDuty is a threat detection service. An agentless detection engine that continuously analyzes AWS logs (CloudTrail management events, VPC Flow Logs, DNS logs) and detects "malicious / anomalous behavior" with threat intelligence and ML, emitting findings.

The official defines GuardDuty as "a threat detection service that continuously monitors, analyzes, and processes AWS data sources and logs." Representative detectable scenarios are abuse of leaked AWS credentials, data exfiltration, unauthorized cryptomining, malware, and suspicious OS/network/file events on EKS/ECS/EC2, etc.

What's decisive here is the point of "looking at log behavior." GuardDuty doesn't examine "whether the software has a known vulnerability" (that's Inspector). It doesn't examine "whether there's PII in S3" either (that's Macie). What GuardDuty answers is the runtime behavior question of "is a malicious actor moving right now?"

• Data handled: consumes the foundational data sources (CloudTrail management events, VPC Flow Logs, DNS logs) as independent duplicate streams. Add protection plans (S3 data events, EKS audit logs, RDS login, Runtime Monitoring, Lambda network, etc.) and the monitored scope widens.
• Lifecycle position: mid-breach. Detection, not prevention. Stopping the attack is the job of WAF and IAM.
• Notable: Extended Threat Detection auto-turns-on at zero extra charge, correlates weak signals, and bundles a multi-stage attack into one "attack sequence (always Critical)" finding. For details, head to the attack-sequence finding article.

With GuardDuty as the entrance, the remaining 4 fill "before, after, and beside detection." The organization-wide enabling, protection-plan selection, and EventBridge automated-response implementation of GuardDuty itself is run through with real Terraform/Python code in the main guide.

2. Security Hub CSPM: aggregate findings and check against standards (doesn't detect)

In a word: Security Hub CSPM is "the comprehensive view of security state." It normalizes the findings of GuardDuty/Inspector/Macie/partner products into ASFF (AWS Security Finding Format), aggregates and prioritizes them, and additionally checks the environment against AWS standards/best practices. It's not a detection engine.

This is the single most confused point. Treat Security Hub as "another detection service" and you'll misdesign. The official definition is "provides you with a comprehensive view of your security state in AWS and helps you assess your AWS environment against security industry standards and best practices." What it does is broadly two things:

1. Aggregate: "receives findings from other AWS services—such as Amazon GuardDuty, Amazon Inspector, and Amazon Macie—and supported third-party products." It normalizes scattered-format findings into the single format ASFF, and correlates and prioritizes across providers to create a "single pane of glass."
2. Assess against standards: against standards like FSBP (AWS Foundational Security Best Practices), CIS, PCI DSS, NIST, it emits the pass/fail of each control (best practice) as a control finding and computes a security score.

And an easily-overlooked premise — most standard checks depend on AWS Config. The official explicitly states "Security Hub CSPM uses service-linked rules from AWS Config to run security checks for most controls. ... You must enable AWS Config and record resources in AWS Config for Security Hub CSPM to generate most control findings." That is, to run Security Hub's posture check, enabling AWS Config is effectively a premise (this is why this article says "Config is an adjacent service").

• Data handled: other services'/partners' findings (ASFF) + AWS Config's configuration records.
• Lifecycle position: a cross-cutting layer. Not "before/after" detection, but the place that gathers and lines up the results of all layers.
• Automation: automation rules can update/suppress findings, and EventBridge integration can trigger automated response.

The implication for design: GuardDuty and Security Hub are not "either/or" but both. If GuardDuty is "the hand of detection," Security Hub is "the desk that holds all detection results." Inspector and Macie's findings, too, ultimately gather on this desk (Security Hub), so it's worth setting up first as the operational central hub.

3. Detective: after detection, investigate the root cause as a graph

In a word: Detective is the service that "analyzes, investigates, and quickly identifies the root cause." It automatically collects AWS logs and, with ML, statistical analysis, and graph theory, creates a visualization of the behavior graph to speed up investigation. Not detection but investigation.

If GuardDuty ends at "emitting a red alert," what answers the next "so, how far did they get? what was the trigger?" is Detective. The official defines it as "helps you analyze, investigate, and quickly identify the root cause of security findings or suspicious activities" and continues "uses machine learning, statistical analysis, and graph theory to generate visualizations."

• Data handled: automatically extracts CloudTrail, VPC Flow Logs, EKS audit logs, and takes in GuardDuty findings to build a behavior graph. It can access up to 1 year of history and trace changes in activity volume in time series.
• Lifecycle position: after detection (incident response). Not a device to find new threats but a device to solve the context, scope, and cause of a found threat.
• Integration: via integration with GuardDuty and Security Hub CSPM, you can pivot directly from a finding to the Detective console. High-severity GuardDuty findings can have their root cause analyzed with "finding groups."

Don't confuse this — GuardDuty "detection" and Detective "investigation" are a before/after relationship, not competition. Not "GuardDuty exists so Detective is unnecessary" but "GuardDuty plots the points, Detective draws the line." In an environment like a payment foundation where you need to "detect an anomaly, then confirm and report the impact scope within time," the presence of Detective directly sways the time required for incident response.

Cost view: Detective is metered against the analyzed event volume, with a 30-day free trial on new enabling. Rather than running it always at full power company-wide, positioning it as "a tool to dig in when a high-severity GuardDuty finding appears" tends to win on cost-effectiveness.

4. Inspector: before the breach, scan software vulnerabilities

In a word: Inspector is a vulnerability management service. It automatically discovers EC2, ECR container images, Lambda and continuously scans for software vulnerabilities (CVE) and unintended network exposure. Not behavioral detection but vulnerability assessment.

This is the pair most confused with GuardDuty. Both "emit findings of a security problem," so they look the same, but the questions are opposite.

• GuardDuty's question: "Is something bad happening now?" (behavior on logs)
• Inspector's question: "If attacked, is there a hole to exploit?" (software composition)

The official defines Inspector as "a vulnerability management service that automatically discovers workloads and continually scans them for software vulnerabilities and unintended network exposure." It auto-rescans in response to changes such as installing a new package, applying a patch, and the publication of a new CVE, and assigns a risk score adjusted from NVD/CVSS to the environment. It auto-closes a finding once fixed.

• Data handled: the workload's software composition (installed packages / the contents of container images) and network reachability paths. It doesn't look at log behavior.
• Lifecycle position: before the breach (preventive assessment). Discovery to plug holes before being attacked.
• Integration: publishes findings to EventBridge. If Security Hub CSPM is enabled, Inspector's findings are also aggregated in Security Hub.

The core of confusion: GuardDuty ≠ Inspector. "Threat detection on logs" vs. "software vulnerability scanning." The former looks at the attacker's behavior, the latter the weakness you might hand the attacker. When a CVE like Log4Shell comes out, what answers "which of our images/instances applies" is not GuardDuty but Inspector.

5. Macie: the data layer, classify the "contents" of S3

In a word: Macie is a data security service. With ML and pattern matching, it discovers and classifies sensitive data (PII, financial info, credentials, etc.) from the contents of S3 objects, and additionally evaluates S3 buckets' public/encryption settings. Not threat detection but data classification.

Only Macie looks at a decisively different place from the others. Whereas GuardDuty/Inspector/Detective look at "logs, configuration, behavior," Macie looks at "the contents of S3 objects themselves." The official definition is "a data security service that discovers sensitive data by using machine learning and pattern matching, provides visibility into data security risks, and enables automated protection against those risks."

• Data handled: the contents of S3 objects (detecting PII, financial info, credentials, etc. with managed data identifiers / custom identifiers) + S3 buckets' public/encryption/access-control settings.
• Lifecycle position: the data layer. Visualize "where sensitive data is and whether it's in a dangerous state (a public bucket, etc.)."
• 2 kinds of findings: a sensitive-data finding (sensitive data found in an object) and a policy finding (a configuration problem like a public bucket).
• Integration: publishes findings to EventBridge and Security Hub CSPM.

The core of confusion: GuardDuty ≠ Macie. "Behavioral threat detection" vs. "data classification." GuardDuty looks at the behavior of "someone is trying mass exfiltration from S3." Macie looks at the contents of "that S3 in the first place has credit-card numbers in plaintext." Without knowing "where the data you'd be in trouble if exfiltrated is," you can't even judge the severity of GuardDuty's S3 alert — the two are complementary.

6. Adjacent: AWS Config is "the source of truth of configuration"

Outside the 5 protagonists, place AWS Config in one line. Config is not a detection/investigation service that emits findings but "the source of truth of configuration" that continuously records AWS resource settings and change history. What's important in this article is just one point — most of Security Hub CSPM's standard checks (controls) depend on Config (chapter 2).

That is, in actual operation, when "I enabled Security Hub but almost no control findings appear," the true cause is often Config not enabled. If you use Security Hub as a posture checker, design on the premise of enabling Config and recording resources. Config is a "track" category separate from the 5 protagonists' "verbs (detect/aggregate/investigate/assess/classify)," so it's treated as an adjacent context.

7. How to connect: finding → Security Hub / EventBridge → automated response

Once you understand the role division, next is the wiring to "turn the scattered 5 into one defense pipeline." The keys are two — Security Hub (the aggregation hub) and EventBridge (the bus of automated response). Each service emits findings independently, but only by gathering them in one place and turning them into action does it go into operation.

7.1 Architecture (text diagram)

                          ┌──────────────────────────────────────────────┐
   [ pre-breach ]         │       detect / assess / classify layer         │
                          │                                              │
   Inspector ──CVE/expos──┤                                              │
   (EC2/ECR/Lambda)       │                                              │
                          │                                              │
   [ data layer ]         │                                              │
   Macie ────sensitive────┤   each service generates findings             │
   (S3 contents)          │            │                                 │
                          │            ▼                                 │
   [ during breach ]      │   ┌─────────────────────┐                    │
   GuardDuty ─threat det──┼──▶│  EventBridge (bus)   │──▶ Lambda auto-resp │
   (log behavior)         │   └─────────────────────┘  (isolate/notify/ticket)│
        │                 │            │                                 │
        │ finding         │            ▼                                 │
        │                 │   ┌─────────────────────┐                    │
        └─────────────────┼──▶│ Security Hub CSPM    │  ← Inspector       │
                          │   │ (aggregate, ASFF     │  ← Macie           │
   [ config source ]      │   │  normalize, standard/│  ← partner products│
   AWS Config ──config────┼──▶│  best-practice check,│                    │
                          │   │  prioritize)         │                    │
                          │   └──────────┬──────────┘                    │
                          └──────────────┼───────────────────────────────┘
                                         │ pivot high-severity findings
                                         ▼
   [ post-breach ]               ┌─────────────────┐
   Detective ◀───────────────────│  root-cause      │ (behavior graph, up to 1yr)
   (investigate)                 │  investigation   │
                                 └─────────────────┘

Three points:

1. Security Hub is "the desk": the findings of GuardDuty, Inspector, Macie, and partners all gather here, normalized and lined up in ASFF. AWS Config supplies the foundation of standard checks.
2. EventBridge is "the action": it receives finding occurrences in near-real-time and flows them to automated responses like notification, isolation, and ticketing. GuardDuty, Inspector, and Macie can all publish findings to EventBridge.
3. Detective is "the deep dive": pivot from high-severity GuardDuty/Security Hub findings to trace the root cause as a graph.

7.2 Integration organization table

The crux of design: making the trigger of automated response "per service" separately increases wiring and breaks. Routing by source (aws.guardduty / aws.inspector2 / aws.macie …) and severity in EventBridge's event pattern is the standard. Limit destructive containment to "type allowlist × high severity," and start from idempotent, reversible operations — this automated-response implementation pattern is run through with Terraform/Python in the automated remediation / incident response article.

8. The decision frame: "if you need X, use Y"

Fold the role division so far into a "what you want to do"-origin quick reference. This form is most effective in a consultation.

A one-line judgment when in doubt:

• "Am I being attacked now?" → GuardDuty (detect)
• "Where do I see all the warnings?" → Security Hub (aggregate)
• "How and how far was I breached?" → Detective (investigate)
• "Where are the holes to be attacked?" → Inspector (vulnerability)
• "Where is the dangerous data?" → Macie (classify)

9. Recommended stack: startup vs. enterprise

"Put in everything" is not the right answer (it breaks down in both cost and operation). Stacking to fit assets and operational phase is the iron rule.

9.1 Startup (small team, PMF-validation phase)

Start from 2 foundations:

1. GuardDuty (foundational detection + free Extended Threat Detection) — enabling = on immediately, correlating up to attack sequences at no extra charge.
2. Security Hub CSPM (+ AWS Config) — the aggregation hub of findings and detection of "configuration gaps" via the FSBP standard. Becomes the first posture map.

Add as assets grow:

• If you put sensitive data (PII, card numbers, etc.) in S3 → Macie.
• If CVE management of containers/servers becomes necessary → Inspector (nearly mandatory the moment you put images in ECR).
• If the frequency of incident investigation rises → Detective.

A small team, precisely, wins on cost-effectiveness by first solidifying the 2 points of "detect (GuardDuty) → aggregate (Security Hub)" and connecting up to Slack notification with EventBridge. Detective and Inspector are enough to add "the moment you need them."

9.2 Enterprise (multi-account, regulated)

All layers org-wide:

• GuardDuty: govern all accounts, all regions with a delegated administrator + auto-enable (see the main guide). Introduce protection plans (S3/EKS/RDS/Runtime/Lambda) in stages per assets.
• Security Hub CSPM: set an aggregation region and enable standards corresponding to regulation like PCI DSS/NIST. Enable AWS Config company-wide.
• Inspector: continuously manage EC2/ECR/Lambda CVEs with organization-wide enabling.
• Macie: enable on accounts handling sensitive data and visualize data location (directly tied to regulatory compliance / data-protection requirements).
• Detective: keep it standing as the standard tool for root-cause investigation of high-severity findings.

In an environment like a payment foundation where accounts are separated for production/staging/audit, governing all 5 "centrally from the organization's delegated administrator" is the design that minimizes operational burden. You can structurally erase the room for "forgetting to enable on each account addition."

10. GuardDuty alone isn't enough — re-confirming defense-in-depth

Finally, back to the first mental model. This article's 5 protagonists are all "detect, aggregate, investigate, assess, classify" and none of them "stop the attack (prevention)." Introduce GuardDuty, aggregate with Security Hub, and that alone can't prevent an attack. The layers of detection, assessment, and classification become defense-in-depth only combined with the layer of prevention.

What's always needed in addition to GuardDuty (and its 4 companions):

• Entrance defense → WAF (L7 filtering, OWASP measures). Block, not detect.
• Least-privilege IAM → narrow the exploitable scope of leaked credentials from the start. Fine-grained access control.
• An operation to plug vulnerabilities → a process to actually patch the CVE Inspector found (discovery and fixing are different things).
• Data-layer protection → encryption, VPC endpoints, fine-grained access control. Macie only tells you "where the sensitive is"; it doesn't encrypt or block.

Re-confirming roles: the 5 security services, within defense-in-depth, take on the layer of "finding fast, bundling correctly, investigating deeply, plugging in advance, and classifying accurately the problems that slipped through / could slip through the prevention layer." Prevention (WAF/IAM/encryption) and the detection family (these 5) are not either/or but both.

Conclusion: an AWS security-service role-division cheat sheet

A quick reference for when you're lost.

• The 5 don't compete; the verbs differ: GuardDuty = detect / Security Hub = aggregate, standard check / Detective = investigate / Inspector = vulnerability assess / Macie = data classify. + AWS Config = config track (adjacent).
• GuardDuty: detect the behavior of logs (CloudTrail/VPC Flow/DNS) with ML + threat intel. Not prevention. Extended Threat Detection correlates attack sequences for free.
• Security Hub CSPM: not a detection engine. Normalize the findings of GuardDuty/Inspector/Macie/partners into ASFF, aggregate and prioritize + CIS/PCI DSS/NIST/FSBP standard checks. Standard checks assume AWS Config.
• Detective: after detection. Investigate the root cause and impact scope with ML/statistics/graph theory (up to 1 year). Pivot from GuardDuty findings.
• Inspector: before the breach. Continuously scan EC2/ECR/Lambda software vulnerabilities (CVE) and exposure. GuardDuty ≠ Inspector (behavior vs. weakness).
• Macie: the data layer. Classify PII, etc., from S3 object contents. GuardDuty ≠ Macie (behavior vs. contents).
• How to connect: each finding → aggregate in Security Hub + automated response with EventBridge, GuardDuty findings are dug into with Detective. Route by source + severity.
• How to stack: startups from GuardDuty + Security Hub. Add S3 sensitive data → Macie, CVE management → Inspector, more investigation → Detective to fit assets.
• Don't overtrust: the 5 are all the detection family. Prevention is separate — it becomes defense-in-depth only combined with WAF, least-privilege IAM, encryption, and actual patch operation.

AWS security is not a game of "choosing the strongest one" but a design of "correctly layering role-different layers to fit your assets and phase." The true identity of confusion is "they all emit findings so they look the same" — but split by verb (detect/aggregate/investigate/assess/classify) and they don't overlap at all.

On a multi-account serverless payment platform, I cross-implemented the IAM, observability, and DR of a foundation handling actual money, carbon credits, and local currency, guaranteeing "correctness" not by operational carefulness but by the structure and mechanism of code. The design of a security stack is the same philosophy — ① decide from assets which verb (detect/aggregate/investigate/assess/classify) you need, ② structurally erase gaps with organization-wide enabling, and ③ bundle findings into one response pipeline with Security Hub and EventBridge. Don't stop at "GuardDuty for now"; I build it through to the role map and the integration plumbing.

"Which security services to put into my AWS, in what order, integrated how" — from organizing the role division to Security Hub/EventBridge integration design, organization-wide governance, and cost optimization, I can accompany you fast and safely with one person × generative AI (Claude Code). Even from the stage of "I've introduced GuardDuty but don't know what's beyond it," feel free to reach out.

References (official documentation)

• What is Amazon GuardDuty? — the threat-detection-service definition, foundational data sources, Extended Threat Detection, Security Hub/Detective/EventBridge integration
• What is AWS Security Hub CSPM? — finding aggregation (ASFF), standard checks (FSBP/CIS/PCI DSS/NIST), AWS Config dependency, GuardDuty/Inspector/Macie integration
• What is Amazon Detective? — root-cause investigation, ML/statistics/graph theory, behavior graph, up to 1 year of history, GuardDuty finding intake
• What is Amazon Inspector? — vulnerability management service, EC2/ECR/Lambda CVE and exposure, CVSS risk score, EventBridge/Security Hub publishing
• What is Amazon Macie? — data security service, classify S3 sensitive data with ML + pattern matching, policy findings, EventBridge/Security Hub publishing