Cloud / AWS Security Hub Interview questions

AWS Security Hub is a cloud security posture management (CSPM) service that gives you a single, aggregated view of security findings across your AWS accounts and Regions. Instead of checking GuardDuty, Inspector, Macie, and AWS Config separately, you get one dashboard.

It normalizes every finding, whether generated by an AWS service or a partner product, into the AWS Security Finding Format (ASFF) so severity, resource, and compliance data look the same regardless of source. It also runs automated checks against standards like the AWS Foundational Security Best Practices and produces a security score.

Because it sits above the individual detection services, teams typically enable Security Hub last, after GuardDuty, Inspector, and Macie are already running, so it has data to consolidate.

A finding is the basic unit of data in Security Hub: a structured JSON record describing one potential security issue tied to a specific AWS resource. It includes fields such as severity, the affected resource ARN, the generator that produced it, and a compliance status if it came from a control.

Every finding also carries a workflow status (NEW, NOTIFIED, RESOLVED, or SUPPRESSED) so teams can track triage progress without leaving Security Hub. Findings can originate from AWS services like GuardDuty and Inspector, from Security Hub's own control checks, or from integrated partner tools.

Because all findings share the ASFF schema, you can filter, group into insights, or route them through automation rules using the same fields no matter which service generated them.

Security Hub evaluates your environment against named standards, each bundling a curated set of controls aligned to a specific framework. The core standards include the AWS Foundational Security Best Practices (FSBP), the CIS AWS Foundations Benchmark, PCI DSS, and NIST 800-53.

In 2026, AWS added the AI Security Best Practices standard, which checks resources like Amazon Bedrock and SageMaker against controls purpose-built for AI/ML workloads.

You enable only the standards relevant to your compliance obligations; each one adds its own controls and therefore its own billed security checks.

Security Hub CSPM is the name AWS now uses for the original posture-management engine of Security Hub: the component that runs automated best-practice checks against your resource configurations and produces the compliance-standard findings described earlier.

The rename happened because Security Hub itself broadened into a unified umbrella that also folds in Amazon Inspector for vulnerability management, GuardDuty for threat detection, and Macie for sensitive-data discovery, all correlated together. CSPM is now one core capability inside that larger picture rather than a synonym for the whole product.

Existing checks, standards, and integrations you relied on under the old "Security Hub" name keep working unchanged under the CSPM label.

ASFF is the standardized JSON schema every finding in Security Hub is stored in, regardless of whether GuardDuty, Inspector, a CSPM control, or a partner product generated it. It defines required fields like SchemaVersion, Id, ProductArn, GeneratorId, Severity, and Resources.

Because every producer maps its native output into these same fields, you can write one automation rule, one insight filter, or one EventBridge pattern that works across all finding sources instead of building separate logic per integration.

ASFF also defines optional fields for compliance status, workflow status, and note, which is what lets Security Hub track triage state consistently across such a wide variety of upstream sources.

A control is a single automated check, such as verifying that S3 buckets block public access, mapped to one or more security standards. Each control has a unique ID like S3.8 and evaluates a specific resource configuration against a pass/fail rule.

Controls are the actual work being billed as "security checks": every time Security Hub evaluates a resource against a control, that's one check. A control can belong to multiple standards at once, for example the same S3 control appearing in both FSBP and CIS.

Consolidated control findings let Security Hub show one finding per control even when it's shared across several enabled standards, instead of duplicating the same failure per standard.

Insights are saved queries that group existing findings by a shared attribute, like resource type, account, or severity, so you can spot patterns instead of scrolling through individual findings one at a time. Security Hub ships several managed insights out of the box, such as grouping S3 buckets with public write access.

You can also build custom insights with your own filters and group-by field, for example grouping open critical findings by resource tag to see which team owns the most risk.

Insights update continuously as new findings match their criteria, and the result counts can be used to trigger a custom action for further automation.

Enabling Security Hub is a per-Region action, so you turn it on in each Region you actually use.

1. Open the Security Hub console or run aws securityhub enable-security-hub in the target Region.
2. Subscribe to the standards you need, such as FSBP or CIS.
3. Confirm AWS Config is recording resources, since many checks rely on Config's recorded configuration items.
4. For an AWS Organization, designate a delegated administrator account so member accounts can be enabled centrally instead of one at a time.

Findings and the security score typically populate within the first hour as controls run their initial evaluation.

Security Hub consolidates findings from several native AWS services plus dozens of AWS Partner Network integrations.

• Amazon GuardDuty - intrusion and threat detection findings
• Amazon Inspector - software vulnerability and network reachability findings
• Amazon Macie - sensitive data discovery in S3
• IAM Access Analyzer - public and cross-account resource access, plus unused access findings
• AWS Firewall Manager - resources lacking required WAF coverage
• AWS Config - configuration data that powers Security Hub CSPM's own controls

On top of these, Security Hub CSPM itself generates findings from its control checks, and partner tools can push findings in using the same ASFF schema through the "enabled products" mechanism.

Automation rules let Security Hub automatically modify findings that match a set of criteria, without you touching each one by hand. A rule can update severity, workflow status, a note, or add a custom string when a finding matches its filter.

A common use is auto-suppressing findings you've already accepted as risk, or auto-escalating anything critical that touches a production account tag, so analysts only spend time on what actually needs a decision.

Rules run continuously against both new and existing findings, and each rule evaluation is a billed unit, so overly broad criteria can add up in cost as your finding volume grows.

Custom actions are user-defined buttons you can attach to one or more selected findings or insight results in the console, which then publish an event to Amazon EventBridge's default bus.

They exist to bridge Security Hub's triage view with actual downstream automation: an EventBridge rule matching that custom action's event can invoke a Lambda function, start an SSM Automation document, or kick off a Step Functions workflow, for example to isolate a compromised instance.

Unlike automation rules, which run automatically against matching criteria, custom actions are triggered manually by an analyst who selects findings and clicks the action.

Workflow status tracks where a finding stands in an analyst's triage process, separate from its severity or compliance status.

You can set this manually, through an automation rule, or via the BatchUpdateFindings API, and it's one of the most useful fields for building dashboards that separate "still needs action" from "already handled."

Cross-Region aggregation lets you pick one aggregation Region and have findings, insights, and control compliance data from all your other linked Regions replicated into it, so you can review everything from a single console view instead of switching Regions manually.

Aggregation is read-only in the linked Regions' direction; you still take actions like updating workflow status from the aggregation Region and those changes sync back. It doesn't reduce billing, since checks still run per Region, it only centralizes visibility.

This is especially useful for organizations running workloads across many Regions who want one operational view without building their own cross-Region reporting pipeline.

Released in mid-2026, this is a Security Hub standard purpose-built for AI and machine learning workloads rather than general infrastructure. It ships with controls that check whether resources like Amazon Bedrock and SageMaker are configured according to AI-specific security guidance.

Example controls include checks such as Bedrock.1, and several SageMaker controls covering things like model endpoint exposure and encryption of training artifacts. It exists because generic controls for storage or IAM didn't capture the specific misconfigurations unique to how AI resources get deployed and accessed.

Enabling it adds these controls to your compliance score just like any other standard, so teams running AI workloads get the same continuous drift detection they already have for core infrastructure.

AI inventory, added in July 2026, gives you a unified list of managed and self-hosted AI and machine learning resources across your AWS environment, things like Bedrock models and SageMaker endpoints, in one place inside Security Hub.

Before this, knowing what AI resources even existed across many accounts and Regions was a manual discovery exercise. AI inventory solves the visibility half of the problem, while the AI Security Best Practices standard solves the compliance half, and the two are designed to work together.

It's particularly useful for security teams who need to answer "what AI is running in our environment" before they can even begin assessing whether it's configured safely.

Exposure findings are a finding type that represents a combined risk picture rather than a single isolated issue, for example a publicly reachable resource that also has a critical vulnerability and access to sensitive data. They come out of Security Hub's correlation engine, which cross-references CSPM, Inspector, GuardDuty, and Macie data together.

An added Impact trait type gives these findings extra context about the potential consequence of the exposure, helping you prioritize the handful of combined risks that matter most instead of triaging hundreds of unrelated low-level findings individually.

Exposure findings are what let Security Hub answer "what could actually be exploited" rather than just "what failed a check."

You subscribe your account to a standard, either through the console's Security standards page or via the API using the standard's ARN with the BatchEnableStandards call.

Once subscribed, Security Hub automatically enables the relevant controls for that standard and begins evaluating your resources against them; you don't need to configure each control individually unless you want to disable a specific one that doesn't apply to your environment.

Because each enabled standard adds its own set of billed checks, teams usually start with FSBP as a broad baseline, then layer on CIS, PCI DSS, or NIST only where a specific compliance requirement calls for it.

Security Hub offers a 30-day free trial for each AWS account in each Region, covering the full feature set so teams can evaluate real findings and the security score before committing to ongoing charges.

Note that this trial doesn't cover AWS Config, which Security Hub CSPM depends on for many of its checks and which is billed separately based on configuration items recorded and rule evaluations.

After the trial window, normal consumption-based pricing kicks in automatically, calculated from security checks run, finding ingestion events, and automation rule evaluations for that account and Region.

Security Hub retains a finding for 90 days after its last update date, not 90 days from when it was first created. Any change to the finding, such as a workflow status update or a re-evaluation that confirms it's still failing, resets that 90-day clock.

This means actively failing, unresolved findings stay visible indefinitely as long as they keep getting re-evaluated, while findings that stop being updated, typically because the underlying resource or check no longer applies, eventually age out and are archived.

Teams that need longer-term historical records typically export findings to S3 via EventBridge or a Firehose pipeline rather than relying on Security Hub itself as an archive.

A connector is a newer integration mechanism that lets Security Hub manage third-party security tool configuration recorders and pull in their data more deeply than a simple finding-import integration. It's backed by an updated managed policy, AWSSecurityHubV2ServiceRolePolicy, that grants permissions for creating and managing connectors and retrieving their health metrics.

Connectors are part of the broader push to correlate signals across a wider ecosystem, including identity protection and endpoint security tools, not just AWS-native services.

Compared to older partner integrations that only pushed findings in, connectors support bidirectional management and health monitoring, so you can see whether a third-party integration itself is functioning correctly.

Security teams historically had to check GuardDuty for threats, Inspector for vulnerabilities, Macie for data exposure, and Config for drift, each in its own console, and mentally stitch the picture together themselves. Security Hub exists specifically to remove that stitching work.

It's central because it normalizes every source into ASFF, runs its own posture checks through CSPM, and now correlates across all of them so a single exposure finding can represent "vulnerable, public, and touching sensitive data" as one prioritized item instead of three separate alerts in three separate tools.

That correlation is the real value: individual services still do their specialized detection, but Security Hub is where the combined risk story gets assembled and acted on.

The two are deeply linked rather than competing: many Security Hub CSPM controls are powered by configuration items that AWS Config records, and Security Hub does not duplicate that recording, it consumes it.

In short, Config answers "what changed and when," while Security Hub answers "which of these things is actually a security problem, and how bad is it."

A useful way to remember it: GuardDuty is a detector, Security Hub is the place that detector's output ends up alongside everything else, so you triage from one screen instead of jumping between services.

You still need GuardDuty enabled for that specific class of threat detection; Security Hub can't generate those findings on its own.

A standard is a named framework, like FSBP or CIS AWS Foundations Benchmark, that bundles together a set of individual checks relevant to that framework's requirements. A control is one of those individual checks, such as verifying encryption is enabled on an EBS volume.

The relationship is many-to-many: enabling a standard turns on many controls, and a single control, like an S3 public-access check, can be shared across several standards at once since the underlying best practice is the same regardless of which framework asks for it.

When you look at your security score, it's calculated from control pass/fail results, but you subscribe and unsubscribe at the standard level, not per control, except for individually disabling ones that don't apply.

Before this feature, if the same control, say an S3 public-access check, belonged to three enabled standards, a failure produced three nearly identical findings, one per standard, cluttering the console and inflating counts without adding real information.

Consolidated control findings merge those into a single finding per control, regardless of how many standards reference it, while still tracking which standards it's associated with in the background for compliance reporting purposes.

This makes triage faster since analysts see one actionable item per actual misconfiguration, and it makes the security score more meaningful since it isn't inflated by duplicate counting of the same underlying issue.

Within AWS Organizations, you designate one member account as the Security Hub delegated administrator. That account can then centrally enable Security Hub, subscribe standards, and view findings across every member account in the organization without needing to log into each one individually.

Member accounts can be auto-enabled going forward, so new accounts joining the organization automatically get Security Hub turned on with the administrator's chosen standards, rather than requiring manual setup each time.

Combine this with cross-Region aggregation and a security team can review findings across every account and every Region from one console, which is the typical setup for any organization beyond a handful of accounts.

As soon as you're operating more than a small handful of accounts under AWS Organizations, since manually enabling and configuring Security Hub account-by-account doesn't scale and quickly leads to inconsistent standards between accounts.

It's especially worth doing before onboarding new accounts at any regular cadence, since the delegated administrator setup is what enables auto-enablement for future accounts, saving repeated manual work later.

It also matters operationally: centralizing to one administrator account means your security team has a single place to build dashboards, automation rules, and insights that apply organization-wide, rather than maintaining separate copies of the same logic in every account.

The security score for a standard is the ratio of passed controls to total applicable controls, weighted by each control's severity rather than counted as simple pass/fail, so a failing critical control drags the score down more than a failing low-severity one.

Controls that don't apply to your environment, for example a check for a resource type you don't use, are excluded from the denominator entirely rather than counted as automatic failures, so the score reflects only what's actually relevant to your account.

Because the score is calculated per standard, an account subscribed to FSBP, CIS, and PCI DSS will show three separate scores, and there's no single account-wide blended number unless you build one yourself from the underlying control results.

Setting workflow status to SUPPRESSED tells Security Hub you've reviewed the finding and either accepted it as a known risk or identified it as a false positive. Suppressed findings are excluded from active-finding views and from the security score's active count, so they stop cluttering day-to-day triage.

Suppression doesn't delete the finding or remove it from the audit trail; it remains queryable via the API and console filters, and if the underlying condition changes, a re-evaluated version of the finding can still surface again as NEW.

Teams commonly automate this through an automation rule for well-understood, recurring low-risk patterns rather than suppressing findings by hand one at a time.

Since pricing scales with security checks, finding ingestion events, and automation rule evaluations per account per Region, the biggest lever is only enabling standards and Regions you actually need instead of turning everything on everywhere by default.

• Disable standards that overlap heavily with one another if you don't have a specific compliance requirement for each
• Turn off Security Hub in Regions with no active workloads
• Scope automation rules narrowly, since broad rule criteria multiply evaluations across every matching finding
• Use cross-Region and cross-account aggregation for visibility instead of duplicating tooling per account

Finding ingestion tied to Security Hub's own security checks isn't separately charged, so the checks themselves, not the resulting findings, are usually where cost actually accumulates as resource count grows.

1. Confirm the upstream service, like GuardDuty or Inspector, is actually enabled and generating findings in that same account and Region.
2. Check that the producing service is listed as an "enabled product" in Security Hub for that account.
3. Verify AWS Config is recording the relevant resource type, since many CSPM controls can't evaluate resources Config isn't tracking.
4. Check IAM permissions on the Security Hub service role and, for member accounts, confirm the account is actually associated with the delegated administrator.
5. Look for an automation rule that might be auto-suppressing or otherwise modifying the finding right after ingestion.

Region mismatches are the single most common cause: a resource in one Region won't show up if Security Hub or the relevant detection service is only enabled in a different Region.

A finding moves through detection, triage, and eventual closure, with its workflow status reflecting where it sits at each point.

flowchart LR
    A["Source service detects issue"] --> B["Finding ingested as ASFF, status NEW"]
    B --> C{Automation rule matches?}
    C -- yes --> D["Fields auto-updated, e.g. suppressed or escalated"]
    C -- no --> E["Analyst reviews, status NOTIFIED"]
    D --> F["Status: RESOLVED or SUPPRESSED"]
    E --> F
    F --> G["No further updates for 90 days"]
    G --> H["Finding archived / no longer shown"]

Any re-evaluation that confirms the issue still exists resets the 90-day retention clock and can flip status back toward NEW-like review if the underlying resource changed materially, keeping genuinely unresolved risk visible instead of letting it silently age out.

sequenceDiagram
    participant Src as Finding Source
    participant SH as Security Hub
    participant Rule as Automation Rule
    participant EB as EventBridge

    Src->>SH: New or updated finding (ASFF)
    SH->>Rule: Evaluate finding against rule criteria
    alt criteria match
        Rule->>SH: Apply actions (update severity, workflow, note)
        SH-->>EB: Optionally emit event if configured
    else no match
        Rule-->>SH: No change made
    end

Rules are evaluated in a defined order when multiple rules could match the same finding, and each one can either stop further rule processing or let subsequent rules also apply, depending on how it's configured.

Because rules run against both newly ingested findings and updates to existing ones, a single rule can keep re-applying its logic every time a matching finding changes state, not just at creation.

Security Hub's correlation engine ingests findings from Inspector (vulnerabilities), GuardDuty (active threats), Macie (sensitive data locations), and CSPM (misconfigurations), then looks for overlaps on the same resource rather than treating each finding as independent.

When it finds overlapping signals, for example a resource with both a critical Inspector vulnerability and a CSPM finding showing it's publicly reachable, it generates a combined exposure finding with an Impact trait describing the compounded risk, rather than leaving analysts to notice the connection themselves across four separate finding lists.

This matters because a resource with several individually medium-severity findings can represent a genuinely critical exposure once you see them together, something no single detection service, looking only at its own narrow signal, could surface on its own.

Security Hub is intentionally a detection and aggregation layer, not an enforcement engine, because automatically changing production resources based on an automated check carries real risk of outages or unintended side effects if the remediation logic is wrong or the finding is a false positive.

Instead, remediation is opt-in: teams wire up automation rules or EventBridge custom actions to specific, reviewed remediation logic, often using the separate Automated Security Response (ASR) solution's prepackaged playbooks, so that what gets auto-remediated is a deliberate choice per finding type, not a blanket default.

This separation also keeps audit and compliance simpler, since it's always clear that a human or a specifically approved automation, not Security Hub itself, made the change to a resource.

Security Hub publishes events to EventBridge's default event bus whenever findings are created or updated, and also when an analyst triggers a custom action on selected findings.

You write EventBridge rules matching a pattern, such as severity CRITICAL findings from a specific product, and target that rule at a Lambda function, an SSM Automation document, a Step Functions state machine, or an SNS topic for notification.

This is the mechanism underneath both automation-adjacent workflows and manual custom actions, since Security Hub itself doesn't call your remediation code directly, it always goes through EventBridge as the decoupling layer between detection and response.

The most common path is an EventBridge rule matching the findings you want forwarded, targeting either a Lambda function that reformats and pushes to the SIEM's ingestion API, or a Kinesis Data Firehose stream that lands data in S3 for the SIEM to pull from.

Many popular SIEM and observability platforms, such as Splunk and Datadog, also offer a direct listed integration in Security Hub's partner catalog, which handles the API call and field mapping for you instead of requiring a custom Lambda.

Whichever path you choose, it's worth filtering at the EventBridge rule level so you're forwarding meaningful findings, not every low-severity informational one, to avoid overwhelming the SIEM's ingestion volume and cost.

Not every finding represents something worth acting on again and again. A known, accepted risk, or a check that's a false positive for your specific architecture, will otherwise keep showing up as an active finding every time it re-evaluates, drowning out genuinely new issues.

Suppression lets you mark those as reviewed without deleting them, so the active-finding view and the security score reflect only what still needs a decision, while the full history stays available for audits or compliance reviews that ask what was found and how it was handled.

Used well, suppression is what keeps a mature Security Hub setup usable at scale instead of turning into an ever-growing pile of findings nobody trusts enough to act on.

When the specific grouping you need to monitor isn't covered by one of Security Hub's managed insights, for example grouping open critical findings by a resource tag representing team ownership, so each team sees only its own open risk.

Custom insights are also useful for tracking a narrow, org-specific pattern, like all findings tied to a particular application's resources across accounts, which a generic managed insight has no way of knowing about.

Because insight results can feed a custom action, a custom insight is often the first step toward automating a very specific workflow, like triggering a notification only when a particular team's open-critical count crosses a threshold.

In practice, FSBP is usually the broader default baseline most teams enable first, while CIS is layered on specifically because auditors, customers, or internal policy explicitly reference the CIS benchmark by name as a recognized industry standard.

The two overlap on many foundational controls, which is exactly why consolidated control findings matter: a shared control failing shows up once, not twice, even though it's counted toward both standards' scores.

Each finding carries a GeneratorId and an Id that together let Security Hub recognize when an incoming record is an update to something already tracked rather than a brand-new issue, so re-running the same check on the same resource updates one finding instead of creating a fresh copy every time.

On top of that per-source dedup, consolidated control findings handle a second layer: when the same control is shared across multiple enabled standards, Security Hub merges what would otherwise be near-identical findings from each standard into a single finding, while still tracking standard associations behind the scenes.

The result is that a genuinely recurring issue shows one finding whose fields update over time, rather than a growing list of duplicates that all say the same thing.

sequenceDiagram
    participant GD as GuardDuty
    participant SH as Security Hub
    participant Corr as Correlation Engine
    participant UI as Console / Insights

    GD->>GD: Analyze logs, detect threat activity
    GD->>SH: Publish finding (native integration)
    SH->>SH: Map finding into ASFF schema
    SH->>Corr: Check for overlap with CSPM, Inspector, Macie findings
    Corr-->>SH: Return correlated exposure context if matched
    SH->>UI: Display finding, or combined exposure finding

Because the GuardDuty integration is native rather than a generic partner import, the mapping into ASFF happens automatically with no configuration required beyond having both services enabled in the same account and Region.

If the same resource GuardDuty flagged also has a public-access CSPM finding, the correlation step is what turns two separate alerts into one prioritized exposure finding instead of leaving analysts to connect the dots manually.

Per-Region review means an analyst has to switch consoles or CLI profiles for every Region in use, and it's easy to simply forget a Region exists, especially one used for a single legacy resource, leading to blind spots that have nothing to do with actual risk and everything to do with operational oversight.

Aggregation solves the visibility problem without changing where the underlying evaluation happens: controls still run per Region against that Region's resources, aggregation just replicates the results into your chosen aggregation Region so nothing requires a console switch to review.

It's a workflow and coverage-assurance improvement, not a detection improvement, since the actual security checks and their accuracy are identical whether or not aggregation is turned on.

• Use automation rules to auto-suppress specific low-severity control failures your team has already reviewed and accepted as acceptable risk
• Build a custom insight filtered to medium-and-above severity so daily triage dashboards skip the long tail
• Disable individual controls that consistently fire on resource types outside your actual risk model, rather than leaving every control from a standard active by default
• Adjust which standards are enabled if a lower-priority framework is contributing a disproportionate share of low-value findings

The goal isn't to hide risk, it's to make sure the findings analysts see day-to-day are the ones that actually warrant a human decision, while the full record still exists for anyone who needs the complete picture.

Disabling a standard stops its associated controls from running new evaluations, so no new findings tied to that standard's checks will be generated going forward, and the standard's security score disappears since there's nothing left to score.

Existing findings that were already generated under that standard aren't automatically deleted; they remain in Security Hub until they age out naturally after 90 days without an update, or until someone manually suppresses or archives them.

If a control is shared with another standard you still have enabled, thanks to consolidated control findings, that control keeps running and generating findings under the remaining standard, it's only fully stopped once every standard referencing it is disabled.

flowchart TD
    A["Define filter criteria and group-by attribute"] --> B["Insight created and saved"]
    B --> C["Security Hub continuously matches findings against filter"]
    C --> D["Matching findings grouped by chosen attribute"]
    D --> E["Result counts shown per group in console"]
    E --> F{Threshold or pattern of interest?}
    F -- yes --> G["Trigger custom action for further automation"]
    F -- no --> C

Unlike a one-time report, an insight isn't run on demand and forgotten, it's a persistent, continuously evaluated query that stays live until you delete it, updating its grouped counts as new findings match or existing ones change state.

This is what makes insights useful for ongoing monitoring dashboards rather than point-in-time snapshots, since the same insight will reflect this week's numbers and next month's without anyone re-running anything manually.

Notably, finding ingestion events tied to Security Hub's own security checks aren't separately charged, so most of a typical bill comes from the checks themselves plus whatever volume of external findings, from GuardDuty, Inspector, or partners, gets ingested each month.

AWS Config is billed entirely separately based on configuration items recorded and rule evaluations, and isn't included in Security Hub's own pricing dimensions even though CSPM checks depend on it.

Security Hub tells you what's wrong; the Automated Security Response (ASR) solution is AWS's prepackaged answer for actually doing something about it, shipping ready-made EventBridge rules paired with Lambda or SSM Automation remediation playbooks for common FSBP and CIS control failures.

Deploying it via CloudFormation means you're not writing custom remediation code from scratch for well-understood issues, like an open security group port or an unencrypted EBS volume, since AWS has already built, tested, and packaged that logic as reusable playbooks.

You still choose which playbooks to enable per control, keeping the deliberate, opt-in remediation model Security Hub is designed around, but with far less custom engineering work than building every response pipeline in-house.

Standalone Security Hub covers native AWS services, GuardDuty, Inspector, Macie, and CSPM, correlated together under one bill tied to the usual security-check and ingestion pricing dimensions.

The Extended plan builds on top of that by adding pay-as-you-go access to 14-plus curated third-party partner integrations, identity protection, endpoint security, and other specialized tools, all consolidated under one bill instead of requiring separate contracts and separate billing relationships with each partner vendor.

It's aimed at organizations that already value Security Hub's AWS-native correlation but have a real footprint of non-AWS or specialized security tooling they want folded into the same console and the same correlated exposure findings, rather than left in a separate silo.

When your organization is primarily AWS-centric but has a meaningful, ongoing footprint of other clouds or partner security tools, and the priority is getting a unified, correlated risk view without standing up and learning an entirely separate multicloud platform.

Security Hub's correlation across CSPM, Inspector, GuardDuty, and Macie now extends attack-path visibility into that wider ecosystem, linking misconfigurations, vulnerabilities, and identity risk across tools into one exposure story, which is valuable specifically because it reuses a console and workflow your AWS teams already know.

A dedicated third-party CSPM or multicloud platform still makes more sense when non-AWS coverage is the primary requirement, since a platform built cloud-agnostic from the ground up will generally go deeper on non-AWS-native detection than an AWS-rooted service extending outward.