AWS GuardDuty, Security Hub CSPM and Security Hub Compared

Start with the required outcome and the current service names

Choose the next capability from a specific question, the accounts and Regions in scope, the evidence you need and the people who will act. Team size alone does not establish that GuardDuty should precede posture checks. Detection, posture and response can have parallel requirements.

Distinguish the services · Check billing scope · Compare the questions · Copy a bounded verification plan

Define the scope, authority and operating owner

Record the account structure, workloads, data sensitivity, service administrators and permitted changes. This guide does not authorize changes in an AWS account. Before a rollout or test, identify the person who approves it, reviews costs and owns downstream responses.

Write the required outcome in concrete terms: investigate suspicious activity, evaluate a particular configuration condition, correlate supported findings or verify delivery to an existing response process. A service being enabled is not the same as the outcome being verified.

GuardDuty: ask which activity and protection capability matter

Amazon GuardDuty is a threat-detection service that analyzes supported AWS data sources. Available protection capabilities and their coverage differ; review the exact account, Region, resource types and enabled settings rather than treating the service name as complete coverage.

The current guide describes defaults that vary between first-time enablement and plans introduced for existing customers. Record what is actually enabled and what the relevant capability requires. A quiet findings list does not establish that activity was collected, analyzed or safe.

If threat detection is the immediate gap, investigate the relevant GuardDuty capabilities and the response path. That is a task-specific reason to prioritize work, not a universal rule for every small team.

Security Hub CSPM: ask which control and population need checking

Security Hub CSPM evaluates supported configuration controls and consolidates supported security findings. Most control checks require appropriate AWS Config recording. Review the chosen controls, covered resources and prerequisites; an enabled standard does not establish that all checks completed or all resources were assessed.

A posture gap can justify CSPM work immediately, alongside detection work or before a separate expansion. Record the actual condition and owner. A passed control, score or collection of findings is not by itself a complete compliance assessment.

Security Hub, Security Hub CSPM and GuardDuty are distinct names

The current AWS service distinction describes Security Hub CSPM as posture evaluation and Security Hub as a unified experience for prioritizing and responding to security issues. Security Hub can correlate CSPM findings with other sources to generate exposures. Do not read an older use of “Security Hub” as automatically describing the current unified plan.

For a proposal, name the exact service, plan and capabilities. Separate the originating detection or control finding from the system that receives, correlates or routes it. These roles can complement each other; neither a dashboard nor a service label establishes the whole response workflow.

Review what the team already operates

Inventory existing detection, posture, logging, investigation and response arrangements before proposing another service. Include managed providers and organization-level settings. A small team may already have centrally managed coverage; a larger team may still have an unowned gap.

Record administrators, member accounts, intended Regions, covered resource types and known exclusions. Compare the desired state with evidence from the actual environment. Do not infer a need for a new service solely from the number of engineers or AWS accounts.

Compare the actual billing model and included capabilities

The current Security Hub pricing page distinguishes unified plans from individual service pricing. It states that services such as GuardDuty and Security Hub CSPM remain available separately when Security Hub is not enabled. Capabilities outside a selected plan can retain separate charges. Do not add two nominal prices without checking what is already included.

The Security Hub trial does not cover every add-on or plan. Individual-service trial eligibility and related charges can differ. Confirm current terms and use the provider’s estimate for the actual account and Region scope; this article gives no live quote.

Record currency, pricing date, billable resource or usage dimensions, plan inclusions, exclusions, trial end, related services and growth assumptions. Keep the estimate separate from observed charges and the internal work needed to triage, investigate and maintain the workflow. Mark missing values unknown rather than zero.

Define who interprets and acts on a finding

Record the receiving queue, named owner or rotation, escalation conditions and authority to make changes. A notification reaching a shared channel does not establish acknowledgment, investigation or remediation.

Keep severity distinct from operational priority. Describe the affected asset, identity, environment and evidence rather than applying a blanket rule that every finding from one service outranks every finding from another. If a finding is suppressed or closed, keep the reason, evidence, owner and review condition.

Automated responses need their own scope, permissions, review and recovery plan. Do not attach disruptive actions to unreviewed sample events or placeholder resource values.

Use phases with evidence-based exit conditions

  1. Document the need: define the question, population, existing coverage, cost assumptions and accountable owner.
  2. Review configuration: check the selected capability, prerequisites and intended boundary against current documentation.
  3. Verify the relevant behavior: distinguish configuration review, sample delivery, a completed posture check and a separately authorized detection exercise.
  4. Review the result: record what was established, what failed or remained unknown, and what must be checked before expanding.

The phases have no mandatory thirty-day schedule or service order. Choose review dates from the task and operational constraints. Do not report an incomplete phase as passed merely because its planned date arrived.

Trace the handoff from source finding to response

Document each required link: source service, account and Region, receiving service or event route, relevant filter, notification or ticket, acknowledgment and handling decision. Check the current GuardDuty–CSPM integration documentation for the intended handoff.

Test the actual required path. A finding visible in its source console does not establish arrival in another account, Region, dashboard or queue. Duplicated deliveries do not establish two independent detections. Preserve identifiers and timestamps so a reviewer can trace what happened without guessing.

Compare the question and the evidence needed

This is a question map, not a ranking or an enablement instruction. Scroll horizontally for all columns; focus the region to use arrow keys.

Different outcomes require different verification
QuestionCapability to investigateEvidence to record
Is suspicious activity detected for this workload?Relevant GuardDuty protection capabilityCoverage, prerequisites, authorized test boundary and observed result
Does a supported configuration control fail?Relevant CSPM controlActual check result, resource population, recorder state and exceptions
How are supported risks correlated and prioritized?Current Security Hub plan and inputsSources present, expected correlation and limits of the resulting view
Does the owner receive and acknowledge a finding?Configured delivery and response pathSource identifier, destination, timestamps, acknowledgment and failure points
What will this change cost?Actual plan and related-service estimateIncluded capabilities, billable units, trial limits, exclusions and observed usage

Avoid conclusions the check did not establish

  • Do not call a sample notification proof that an attack was detected.
  • Do not call an enabled service proof of complete account, Region or resource coverage.
  • Do not call a posture score an audit opinion or a guarantee of security.
  • Do not count included capabilities again as independent charges without reviewing the plan.
  • Do not infer that an automatic response was safe because its rule matched.
  • Do not use team size as a substitute for the required outcome and operating evidence.

Questions about the comparison

Must every small team enable GuardDuty first?

No. Identify the immediate detection, posture and response gaps, current coverage, cost and owners. A documented need can justify parallel work or a different sequence.

Does Security Hub CSPM mean the current Security Hub plan?

No. Name the exact service and plan. Use the current service distinction and pricing documents rather than assuming older descriptions are equivalent.

Does generating a sample prove detection coverage?

No. It can support a delivery-path exercise. A completed detection or posture verification is a different claim with different evidence.

No. Check included capabilities, separate-service eligibility and related charges for the actual scope.

Copy a bounded verification plan

Choose the task and obtain the appropriate approval before changing services or exercising a workflow. No fixed fifteen-minute window establishes success.

Required outcome: [ ]
Service, plan and enabled capability: [ ]
Accounts, Regions and resource population: [ ]
Prerequisites and configuration evidence: [ ]
Approver, operating owner and cost owner: [ ]
Verification type: [document review / sample delivery / posture check / authorized exercise]
Expected observable result and limits: [ ]
Downstream automation reviewed: [ ]
Actual result, identifier and timestamps: [not performed / record]
Acknowledgment and handling decision: [ ]
What this did not establish: [ ]
Next check and expansion condition: [ ]

Use the sample-finding precautions and task record below. Preserve the distinction between a proposed configuration, an observed result and a planned next step.

A sample finding tests routing, not threat detection

GuardDuty sample findings contain placeholder values and are marked [SAMPLE], with sample: true in additional information. Use them to check EventBridge matching, notifications, tickets, and acknowledgment. Successful delivery does not demonstrate that a real attack was detected or that all accounts and protection plans are covered.

Review downstream automation before generating samples. Route the test into an approved exercise workflow so placeholder resource details do not trigger an unintended production response. Record the account, Region, sample type, recipient, acknowledgment, and result. Exercise-based detection testing belongs in a separately authorized, isolated account. A proposed rollout schedule is only a planning aid; an urgent posture gap can justify prioritizing CSPM alongside detection.

Editorial review: 16 October 2026. Examples are illustrative; this review does not represent an audit or live control test.

AWS security-service outcome record

Use this when: you are a small team selecting detection or posture capabilities against a defined need. Copy the fields into your own notes. Record what is known, what remains uncertain and who will perform the next check.

Suggested working record — complete with your own evidence
FieldWhat to recordYour evidence / next check
Required outcomeDescribe the security question rather than starting with a service name.To complete
Coverage boundaryRecord accounts, Regions, resources and enabled capabilities.To complete
Operational ownershipAssign triage, investigation, remediation and escalation responsibilities.To complete
Validation boundaryDistinguish a routing sample from an actual detection or posture check.To complete

Next action: Choose the first capability whose findings your team can interpret and act on. Keep the supporting observation and its conditions beside the decision so that a later reader can distinguish an established result from a working explanation.

This is an editorial working aid. Complete it with your own scope, evidence and accountable reviewers; the table alone does not establish security, coverage or acceptance.

Related task: For CloudTrail evidence coverage and retrieval, use AWS CloudTrail Checklist: Coverage and Evidence. Keep that task distinct from the specific record above.

Worksheet change record — October 20, 2026

Added this aws security-service outcome record, four task-specific fields, a next action and a link to a distinct related task. Existing source notes keep their own review dates. This addition is not a new verification of every statement or a newly executed lab test.

Review notes, sources and limits

Document review: October 23, 2026. Replaced the universal GuardDuty-first sequence, team-size assumptions, staged product tiers and fixed-time rollout with outcome-specific checks. Current AWS service, pricing and sample-finding documentation informed the distinctions. No AWS account was accessed, service enabled, finding generated, cloud bill estimated or detection exercised for this review.

Sources: GuardDuty overview · CSPM overview · Security Hub service distinction · Current pricing scope · Sample findings and their limits

Stay Updated with Kioptrix

Get practical guides, useful resources, and new articles delivered to your inbox.

No spam. Unsubscribe anytime. Read our Privacy Policy.