Amazon GuardDuty, AWS Security Hub CSPM, AWS Security Hub, and Amazon Detective can operate together, but they solve distinct detection, posture, correlation, and investigation problems.

• GuardDuty detects suspicious activity.
• Security Hub CSPM evaluates controls and consolidates findings; Security Hub correlates exposures and helps teams prioritize and respond.
• Detective helps analysts investigate what happened around a finding.

The current AWS SCS-C03 exam places detection, incident response, and investigation across several domains, so understanding how these services hand work to one another is more useful than memorizing three product descriptions.

GuardDuty is the threat-detection layer

GuardDuty continuously analyzes supported AWS telemetry and generates findings when it detects activity that matches threat intelligence, behavioral models, anomaly detection, or known attack techniques.

Depending on the protection features enabled, GuardDuty can analyze signals associated with services and workloads such as:

• AWS account and IAM activity
• Amazon EC2
• Amazon S3
• Amazon EKS
• AWS Lambda
• Amazon RDS
• malware-protection workflows

A GuardDuty finding answers a question such as:

“What suspicious behavior has AWS detected?”

It does not replace every raw log or every security-control assessment.

It produces a security detection that an analyst can triage.

A finding includes context such as:

• finding type
• severity
• affected AWS resource
• account and Region
• related IP addresses
• API or network activity
• timestamps
• additional threat context

The finding type is designed to describe the suspicious behavior.

That lets a SOC prioritize a GuardDuty finding without building every detection from raw CloudTrail or VPC Flow Logs.

Centralized SIEM workflows correlate security events across many sources. GuardDuty is narrower: it is an AWS-managed threat-detection source that can feed that larger security-operations workflow.

Security Hub CSPM evaluates posture; Security Hub connects exposures

AWS Security Hub CSPM receives findings from several AWS security services and supported partner products.

GuardDuty findings can flow automatically into Security Hub CSPM when both services are enabled in the same account and Region.

Security Hub CSPM normalizes findings into the AWS Security Finding Format, or ASFF.

AWS Security Hub and Security Hub CSPM are distinct complementary services. CSPM evaluates security standards and consolidates posture and integrated findings. Security Hub correlates findings from CSPM and other enabled sources into exposures so teams can prioritize critical risks and route remediation. Enablement and coverage must be designed for each service; one is not simply a different name for the other.

That gives a security team one place to:

• review findings
• filter by account, Region, service, severity, or resource
• aggregate findings across Regions
• track workflow status
• manage integrations
• evaluate security standards and controls
• review security coverage

The CSPM posture and finding-ingestion role is different from GuardDuty threat detection, while AWS Security Hub adds cross-service exposure correlation and response workflows.

GuardDuty detects threats.

Security Hub CSPM centralizes security findings and evaluates configuration/posture controls.

This distinction matters.

A Security Hub CSPM control can report that:

• a security service is disabled
• a resource configuration violates a standard
• an S3 bucket setting is noncompliant
• required protection is missing

Those are posture or configuration findings.

A GuardDuty finding represents suspicious or potentially malicious activity.

Both matter, but they have different urgency and response paths.

A noncompliant configuration may create risk without showing that an attacker is active.

A GuardDuty detection may require immediate investigation.

Detective is the investigation layer

Amazon Detective collects and analyzes security-relevant data to build a behavior graph.

AWS currently uses sources such as:

• CloudTrail activity
• VPC Flow Logs
• GuardDuty findings
• supported Security Hub CSPM findings and other data sources

Detective then creates profiles and visualizations around entities such as:

• IAM principals
• AWS accounts
• EC2 instances
• IP addresses
• storage resources

The investigation question becomes:

“What was this entity doing before, during, and after the finding?”

That is a different job from generating the original detection.

AWS supports investigation pivots from GuardDuty and Security Hub CSPM into Detective.

An analyst can open a finding and move into a related entity or finding profile.

That reduces the amount of manual correlation required.

Instead of separately searching several logs for one EC2 instance, Detective can show activity associated with that entity over time.

Useful questions include:

• Is this API call unusual for the role?
• Did the instance suddenly contact a new IP range?
• Which other findings involve the same user?
• Is the network-traffic spike normal for this instance?
• Did several suspicious events form one larger activity?

This is where Detective adds investigative context.

Detective finding groups connect related activity

Attackers rarely perform only one action.

A compromised identity can generate:

• suspicious API activity
• credential-use findings
• resource changes
• new network behavior

Detective can group related findings and entities to help analysts see a broader activity pattern.

A finding group is therefore useful when one isolated alert does not explain the entire attack.

This can help the SOC identify scope and root cause faster.

GuardDuty is also adding investigation features

AWS now provides GuardDuty Investigation in preview.

It can analyze GuardDuty findings, related activity, threat intelligence, and historical context to produce a risk assessment and investigation recommendations.

That does not make Detective irrelevant.

The products still have different scopes and operating models.

GuardDuty Investigation is centered around GuardDuty’s detections.

Detective remains a dedicated investigation service with behavior-graph context, entity profiles, and broader finding analysis.

For production architecture, follow current AWS service capabilities rather than assuming the boundaries will never evolve.

A typical security workflow

A practical flow can look like this:

1. GuardDuty detects suspicious behavior.
2. The finding is sent to Security Hub CSPM.
3. Security Hub CSPM centralizes the finding with other AWS security findings.
4. When AWS Security Hub is enabled, its correlation and exposure capabilities help the SOC prioritize work with asset and business context; analysts should still review the original finding.
5. The analyst pivots into Detective.
6. Detective shows related activity and affected entities.
7. The analyst determines scope and likely root cause.
8. Incident-response automation or human responders contain the affected resources.
9. The finding workflow is updated in Security Hub CSPM.

This is not the only possible architecture.

It is a useful mental model for understanding the roles.

Choose the service by the question

Use GuardDuty when the question is:

“What suspicious activity is AWS detecting?”

Use Security Hub CSPM when the question is:

“What security findings and posture issues exist across my accounts and Regions?”

Use AWS Security Hub when the question is:

“Which correlated exposures need priority action across services?”

Use Detective when the question is:

“What happened around this finding, user, instance, or IP address?”

How the services divide a real investigation

The easiest way to understand these products is to follow one suspicious resource through the workflow. Suppose an EC2 instance begins communicating with an IP address associated with command-and-control infrastructure. GuardDuty is the service most likely to raise the behavioral finding because it continuously analyzes supported AWS telemetry and threat intelligence for suspicious activity. The finding should tell the analyst what resource is affected, what behavior triggered the alert, the severity, and enough context to begin scoping the event.

Security Hub CSPM changes the problem from one finding to an estate-wide view. Its job is not to reproduce every GuardDuty analytic. It aggregates and normalizes findings from AWS security services and supported integrations, and it also surfaces posture findings from security controls. That matters in a multi-account environment because the analyst may need to determine whether the compromised instance is an isolated problem or part of a larger pattern involving identity, network, or configuration weaknesses. Normalization also gives automation a consistent record format instead of forcing every downstream workflow to understand each provider’s native schema.

Detective becomes most useful after the question changes from what was detected? to what else happened around it? Its investigation model lets an analyst pivot through related entities and historical activity, such as identities, IP addresses, and compute resources. That context can expose whether the suspicious communication began recently, whether the instance assumed an unusual role, or whether related activity appears on other resources. The value is correlation over time, not another independent alert stream.

This division of responsibility also explains why a finding can legitimately appear in more than one console without the services being redundant. One service detected the behavior, another centralized the security record, and another gives the analyst a richer investigation surface. Treating all three as interchangeable usually leads to the wrong architecture decision.

Blind spots come from coverage and workflow gaps

A mature deployment still needs deliberate coverage design. GuardDuty protection plans vary by resource type, so enabling the service is not the same as enabling every available protection capability. Security Hub and Security Hub CSPM each reflect only enabled sources and applicable coverage; CSPM controls cannot assess resources that are not recorded or supported. Detective can only investigate from the telemetry and entities available to its behavior graph. If account enrollment, Region coverage, log sources, or delegated administration are incomplete, analysts can get a polished dashboard that still represents only part of the environment.

Operationally, the strongest design is to decide which service owns each stage: detection, aggregation, triage, investigation, and response. Automations should key off stable finding attributes, not console-specific wording. Severity should influence prioritization but should not replace asset criticality or business context. An unusual API call on a production identity may deserve faster escalation than a technically higher-severity event on an isolated lab resource.

The final test is whether an analyst can move from a GuardDuty finding to the wider account context and then to the evidence required for containment without manually rebuilding the story from scratch. When that path works, GuardDuty, Security Hub CSPM, Security Hub, and Detective form a connected security-operations workflow, with distinct responsibilities rather than interchangeable dashboards.
A final operational detail is delegated administration. Large AWS organizations should decide which account owns security administration and how member accounts and Regions are enrolled. Centralization simplifies triage, but only if coverage is consistent. A newly created account or Region that is not enrolled can become an observability gap. Periodic coverage reviews therefore belong in the same operating model as finding triage, especially after organizational restructuring or rapid account growth.