What Is AWS Security Hub? The Front Desk Where It All Lands

AWS Security Hub is the service where all of your other security services finally report to one place — the page where GuardDuty’s threats, Inspector’s vulnerabilities, and a few hundred configuration checks of its own land in a single ranked list, with a score on top telling you how your account measures against AWS’s own definition of "set up properly." That is the easy half of the answer. The other half is the reason this post exists, because it invalidates almost every tutorial you will find: in late 2025, AWS renamed the product. The Security Hub in every course, blog post, and exam dump written before December 2025 is now called Security Hub CSPM — and the name "Security Hub" now belongs to a new, different product that costs roughly ten times as much for a small account. Same console, same word, two services, two bills. One of them costs a small account about a quarter per month; the other starts at $3.75 per server. If you clicked "enable" on the wrong one this morning, nothing is broken — but you should know which one you turned on, and this post will make sure you do. It covers what each product actually does, the score and the controls, what the new exposure findings are genuinely good at, the honest bill for both (including the AWS Config charge that quietly runs behind the free trial), and the $0 alarm that emails you when something Critical lands — the same promise every post in this series keeps.

This is the twenty-first stop in the Learn AWS for Free series, and it is the post the Inspector post promised. Over the last four stops this series has switched on a smoke detector (CloudWatch), a key-card log (CloudTrail), a guard who reads that log all night (GuardDuty), and an inspector who checks every lock against the recall list (Inspector). If you followed along, you now have four consoles, four kinds of findings, and no single place that answers the only question that matters at 9 a.m.: what should I look at first? Security Hub is that place. And if you did not follow along — if you are here because a compliance form or a job posting said "Security Hub" and you wanted to know what it is — you picked a genuinely confusing month to ask, and the next section untangles it before anything else.

What is AWS Security Hub used for? The front desk where every report lands

My friend Ethan, who has now walked me through five AWS security services using one imaginary office building, did not even need prompting for this one. "Think about where all those reports physically go," he said. "The smoke detector logs to a panel. The key-card system prints a ledger. The guard files an incident report. The fire inspector leaves a clipboard sheet. In a badly run building, those live in four different drawers, and the manager reads none of them. In a well-run building there is a front desk, and every report lands on it — sorted, with the scary ones on top, and a note on the wall saying how the building did on this month’s checklist."

That front desk is Security Hub. It does two jobs, and keeping them separate makes everything else in this post easier. Job one: collection. Every finding GuardDuty, Inspector, or Macie produces is forwarded automatically — nothing to wire up — and lands in one list you can filter, sort, and search, in one format. Job two: checking. Security Hub also generates findings of its own, by continuously comparing your account’s configuration against published checklists of good practice — is root MFA on, are your S3 buckets blocked from going public, is CloudTrail on in every region — and scoring the result as a percentage. The first job saves you from four consoles. The second tells you about problems no scanner will ever find, because a missing MFA is not a vulnerability in any package; it is a door you simply forgot to lock.

Notice what is not in either job: watching traffic, scanning files, or fixing anything. Security Hub produces and organizes findings. Every action it triggers happens through other services, and we will get to exactly where its edges are — because knowing what a security service does not do is half of using it well.

Security Hub vs Security Hub CSPM: the rename nobody told your tutorial about

Here is the timeline, because it explains every confusing search result you have seen. From 2018 to 2025, "AWS Security Hub" meant one product: the collector-and-checker described above. At re:Inforce in June 2025, AWS previewed a new product doing something genuinely different — correlating findings across services into combined risks — and on December 2, 2025 that new product went GA. AWS gave the new product the old name, and renamed the original Security Hub CSPM (Cloud Security Posture Management). Both exist today. Both are in the console. Both are called Security Hub in casual conversation. They are different services with different findings, different formats, and very different bills.

If that feels like a lot to hold in your head, the practical version is short: small account learning AWS → you want CSPM first. It is the one this series’ earlier posts feed into, it is the one certification exams still describe, and it is the one that costs a quarter. The new Security Hub is real and good at what it does — we will give its exposure findings a fair section below — but it is priced for accounts with fleets, not for a builder with one server and three Lambda functions. Enabling one does not require the other, with one direction of exception: enabling the new Security Hub switches CSPM on automatically, because it needs CSPM’s checks as raw material.

How Security Hub CSPM works: standards, controls, and checks in plain English

Three words carry the whole mechanism, and they nest like folders. A standard is a published checklist — a definition of what a well-configured account looks like. CSPM ships several: AWS Foundational Security Best Practices (FSBP, AWS’s own list, the one to start with), CIS AWS Foundations Benchmark (the industry list auditors ask about), PCI DSS (card payments), and NIST (US government flavor). A control is one line on a checklist — "S3 general purpose buckets should block public access," "hardware or virtual MFA should be enabled for the root user." Each has an ID like S3.8 or IAM.9, a severity, and a documented fix. A check is one evaluation of one control against one resource, and checks re-run continuously as your configuration changes — which is why the count of checks, not controls, is what the bill meters.

Every check produces a finding with a status: PASSED or FAILED (plus a small tail of "warning" and "not available" cases). The failures are your to-do list, already sorted by severity, each one linking to a remediation page that tells you which console switch or CLI command fixes it. And the passes are not wasted either — they feed the security score, the percentage at the top of the console that condenses the whole exercise into one number. That number deserves its own section, because the first time you see yours, it will not be a nice number, and what you do in the next ten minutes depends on understanding it.

Jake’s 43%: what a first security score actually means

My colleague Jake — whose staging server you met in the CloudTrail post and whose 212 Inspector findings you met in the last one — turned on CSPM the evening that post went up. The message arrived at 9:40 p.m.: "Security score 43%. Sixty-one failed controls. I thought I’d been doing everything right. This feels worse than the 212."

It is not worse, and if your first score lands anywhere in the 40s or 50s, you are exactly where nearly everyone starts — the checklist is strict on purpose, and it is grading years of AWS defaults, not your judgment. Here is what we found when we actually read Jake’s list, and it is what you will find too: failed controls cluster around a handful of root causes. Jake’s sixty-one failures were mostly four decisions he had never been asked to make: account-level S3 public access block was off (a dozen findings, one for the account and one per bucket), CloudTrail was single-region (several more), root had no MFA (a Critical, and genuinely the one to fix first), and a batch of default security groups allowed more than they should. Four fixes. About an evening of work, most of it reading. By Friday his score was 71%, and — this is the part I want you to hear before any caveat — the fixes were real. The score is a proxy, but MFA on root and buckets that cannot go public are not proxies; they are the actual difference between the account that survives a leaked key and the one in the horror story.

Two honest notes about the number itself. First, 100% is not the goal — some controls will not apply to how you build, and the right response to those is a documented suppression (there is a section on that below), not contortions. Second, the score moves slowly — checks re-run on their own schedule, so a fix can take hours to turn a FAILED green. Fix, note what you fixed, and check back tomorrow. Refreshing the page every four minutes helps exactly as much as it did with your exam results.

Is AWS Security Hub a SIEM? An antivirus? A scanner? Three straight answers

Is it a SIEM? No — and this is the most common expensive misunderstanding. A SIEM (Splunk, Sentinel, Elastic) ingests raw logs by the terabyte, stores them, and lets you search and write detection rules over them. Security Hub never sees your logs; it sees findings — the conclusions other services drew from logs. You cannot ask it "show me every API call from this IP," because that data was never there; that question goes to CloudTrail. What it can do is feed a SIEM: the new Security Hub speaks OCSF, the schema SIEM vendors have standardized on, and pushing findings to Splunk or Datadog is a supported integration rather than a parsing project. The Threat Analytics add-on nudges the new product a step in the SIEM direction — it analyzes CloudTrail events directly — but you would not replace a SIEM with it.

Is it an antivirus? No. It never opens a file, and it blocks nothing. Nothing in this AWS security family blocks — detectors detect, and acting is your job (or your automation’s: the alarm and automation sections below are exactly that).

Is it a scanner? Also no, and this one matters for the bill. Inspector reads the software installed on your machines and matches it against CVEs; that is scanning. CSPM reads your account’s settings — it can tell you a bucket is public, never that a package on your server is vulnerable. The two are complements, not rivals, which is why the new Security Hub’s bundle includes both, and why enabling CSPM alone does not give you vulnerability findings: those arrive only if Inspector is on and forwarding.

What are AWS Security Hub findings, and where do they come from?

A finding is one structured statement: this resource has this problem, this severe, observed at this time, fix it this way. In CSPM every finding — whether born from its own checks or forwarded from GuardDuty, Inspector, Macie, IAM Access Analyzer, or one of dozens of third-party tools — is normalized into ASFF, a JSON format where the same fields always mean the same thing. That normalization is quietly the whole value of the collection job: severity from Inspector and severity from a Palo Alto appliance land in the same field, so one filter ("severity CRITICAL, status NEW") covers your entire security estate. Each finding also carries a workflow status you control — NEW, NOTIFIED, SUPPRESSED, RESOLVED — which turns the list from a feed into a queue you can actually work.

Three mechanics worth knowing before they surprise you. Findings are not retroactive: CSPM starts collecting the day you enable it, and nothing that happened before appears — a reason to enable it early, not a reason to feel late. Findings are regional: each region’s Security Hub holds that region’s findings, though you can (and should) designate one aggregation region that mirrors the rest — more in the regions FAQ. And findings expire: CSPM keeps a finding for 90 days after its last update, then deletes it. Ninety days is generous for a queue and useless for an archive, so if an auditor will ever ask "show me Q1," schedule an export — the FAQ covers how.

How to enable Security Hub CSPM, step by step (the small-account lane)

Ten minutes, most of it reading a consent screen. The one real prerequisite: CSPM’s checks run on AWS Config, the service that records every configuration change in your account (the next section explains that relationship and its cost, so you sign nothing blind).

1. Sign in as your admin IAM user — not root; if the words "IAM user" are new, the IAM post is the place to start — and open Security Hub CSPM from the console search. Make sure the region in the top-right is the one your resources actually live in.
2. Choose Go to Security Hub CSPM. The setup screen asks which standards to enable: keep AWS Foundational Security Best Practices checked, and my honest advice for a first account is to enable only that one — every additional standard multiplies checks (and after the trial, cost) while mostly re-asking the same questions in different words. CIS can wait until something requires it.
3. If the screen offers to enable AWS Config recording for you, accept — that is the engine starting, and it is expected.
4. Choose Enable. The 30-day trial starts now.
5. Come back in a few hours. Checks need time to run their first lap; a dashboard read twenty minutes in will just show you an empty room. When you return: your score, the failed controls ranked by severity, and — if GuardDuty and Inspector are on from the earlier posts — their findings already in the list, no wiring required.

That is genuinely all of it. The urge at this point is to fix the score tonight; the better move is Jake’s — group the failures by root cause, fix root MFA first, and let the rest be this week’s list instead of tonight’s panic.

AWS Config: the engine under Security Hub, and the bill behind the free trial

In Ethan’s building, there is one employee we have not introduced: the clerk who writes down every physical change — this lock replaced Tuesday, that door added in March. The fire inspector does not measure the building herself; she reads the clerk’s ledger. AWS Config is that clerk. It records every configuration change to your resources as a configuration item, and CSPM’s checks are, mechanically, rules evaluated against that ledger. No ledger, no checks — which is why enabling CSPM enables Config recording.

Now the part the console will not stop you from missing, and the reason this section sits before the pricing one: the Security Hub CSPM free trial does not cover AWS Config. The trial waives CSPM’s own charges — and to be fair, AWS also does not charge for the Config rules its standards activate — but the recording itself bills normally from day one: $0.003 per configuration item recorded (US East, August 2026). On a quiet account that is cents — a configuration item happens when something changes, not per resource per day. But an account where infrastructure is created and destroyed all day — a CI pipeline standing up test stacks, an autoscaling group breathing — writes a lot of ledger, and people in exactly that situation have opened their first "free trial" bill to find the Config line larger than everything else on it. Check yours after 48 hours: Billing → Bills → Config. On Jake’s account it settled at about sixty cents a month, and yours will likely land near that too. Config deserves — and will get — its own post; it does far more than serve Security Hub, and its recorder settings are where that bill gets tuned.

How to enable the new Security Hub — and the checkbox that costs money

If your account is past the hobby stage — real workloads, real users, a security bill you already accept — the new Security Hub earns a look, and enabling it on a standalone account is short. From the console, open Security Hub (the entry without "CSPM" in the name) and choose Get started. Then comes the screen to slow down on: Security capabilities, with two options. "Enable all capabilities" turns on the Essentials plan plus the add-ons — including Threat Analytics, which bills separately per CloudTrail event analyzed and is not covered by the 30-day trial. "Customize capabilities" lets you take Essentials alone, which is what the trial actually covers and what a first month should be. The big friendly button is the expensive one; it is not a dark pattern exactly, but it is a default that assumes an enterprise budget. Choose your regions (all, or the short list you really use), skip tags unless you have a tagging habit, and choose Enable Security Hub.

Three things appear in your account the moment you do, and none of them are cause for alarm when you know to expect them: a service-linked role (AWSServiceRoleForSecurityHubV2), service-linked Config recorders, and a service-linked IAM Access Analyzer — that last one powers the unused-access analysis in the next section. CSPM is switched on automatically if it was not already, since its checks are one of the signal streams the correlation engine eats.

Exposure findings: the analyst who reads all four reports together

Here is the problem the new product exists to solve, and it is one Jake hit within a week of having everything on. One untagged EC2 instance generated three findings in three services: Inspector flagged an old OpenSSL on it, CSPM flagged its security group open to the world on port 22, and GuardDuty logged a probe rattling exactly that port. Three medium-to-high findings, three list entries, easy to triage separately on three different days — and together they describe one situation that is much worse than any line item: a reachable, vulnerable, actively-probed server. In Ethan’s building: the clipboard says the lock is recalled, the ledger says that door faces the street, and the guard’s report says someone tried the handle last night. A front desk files those in three trays. An analyst reads them together and interrupts your morning.

An exposure finding is that analyst’s memo. The new Security Hub continuously correlates signals from CSPM, Inspector, GuardDuty, and Macie with what it knows about network reachability and IAM relationships, and when the combination on one resource crosses the line, it writes a single finding: the risk in plain terms, the contributing traits (each source signal, itemized), a severity graded on how easy the thing is to find and exploit and how bad success would be, and — the genuinely useful part — an attack path graph: an interactive diagram of how an attacker gets from the internet to the resource and what they can reach after it, drawn from your real security groups and roles. Each resource is the subject of at most one exposure finding, so the list stays short by construction — it is a list of situations, not symptoms.

The same engine watches for a quieter risk: unused access. Through that service-linked Access Analyzer, it flags IAM roles, users, keys, and permissions untouched for 90 days, and can draft a scoped-down replacement policy for a role that has permissions it never uses. This shows up inside exposure findings as context, and it is the detail that changes priorities: a vulnerable server whose role can touch 5 services it never calls is a much bigger blast radius than the same server with least privilege. If you read the IAM post’s advice to start narrow and grant as needed — this is the tool that audits whether you kept to it, with a one-year Trends view to prove the direction of travel.

Is AWS Security Hub free? The two trials and the honest price list

Not free, but CSPM is close to it at small scale, and both products give you 30 days to measure your real usage before a dollar is charged — the same honest pattern as GuardDuty and Inspector: enable it, do nothing, and read the Usage page in week three. All prices US East, from the pricing pages on August 31, 2026.

Security Hub CSPM meters three things:

AWS’s own worked example for a small account — 250 checks and 5,000 ingested findings in a month — comes to $0.25. Plus the Config engine underneath: figure cents-to-a-dollar on a quiet account, as covered above.

The new Security Hub threw the per-check meter out and prices by what you protect. One resource unit is $3.75/month, and your unit count is: each EC2 instance = 1; Lambda functions, 12 to the unit; ECR container images, 18 to the unit; IAM users and roles, 125 to the unit (Azure equivalents count too). That price bundles what used to be separate bills — unlimited CSPM checks and ingestion, Inspector-class vulnerability scanning, GuardDuty’s EC2 malware scanning, and the exposure analytics — so it replaces the Inspector line, not stacks on it. Outside the bundle: the Threat Analytics add-on ($4.00 per million CloudTrail events plus $0.55/GB of security data), Lambda code scanning, and the Extended tier — a curated marketplace of about two dozen partner products (endpoint agents, and more) billed at each partner’s own rates through the same console. None of those three are in the trial; Essentials is.

What does Security Hub cost a small account? Jake’s numbers, both ways

Jake’s account, which this series has been building since the first-project post: one EC2 instance, three Lambda functions, five container images, four IAM identities. Here is the same protection priced both ways, using the current pricing pages and the Inspector numbers from the last post:

So at Jake’s size the old way costs about $3.50 and the new way about $5.85 — and the honest reading is that at this scale the à la carte way wins on price and loses on nothing you will miss: the extra $2.35 buys exposure correlation and malware scanning that matter most when there are more than three findings a week to correlate. The crossover is real, though. The new pricing is kind to Lambda-heavy and container-heavy accounts (12 and 18 to a unit) and it caps what Inspector-style scanning can cost per instance — a busy account with many instances, agentless scanning, and standards piled up can absolutely come out ahead, and AWS put a cost estimator in the Security Hub console for exactly that math. My advice stands as it has all series: enable the trial, read the Usage page in week three, and let your own numbers decide — just decide which product you are trialing on purpose this time.

The $0 "email me when it’s Critical" alarm, step by step — promise kept

Every post in this arc ends its tour with the same practical gift: a free alarm so the service can reach you when it matters, instead of waiting for you to remember a dashboard. Security Hub’s version is the best one yet, because CSPM is the collection point — one rule here covers GuardDuty, Inspector, Macie, and CSPM’s own checks at once. If you built the alarms from the last two posts, this one can even replace them: same alert, one rule instead of three. Every CSPM finding is also emitted to EventBridge as an event, so the recipe is the familiar seven steps:

1. Open SNS → Topics → Create topic: Standard, name it security-critical-alerts (or reuse the topic from the earlier posts and skip to step 4).
2. Create subscription → Protocol: Email → your address.
3. Click the link in the confirmation email SNS sends you. Unconfirmed topics deliver nothing, and this is the step everyone skips.
4. Open EventBridge → Rules → Create rule, name it securityhub-critical-email, event bus default, rule with an event pattern.
5. Choose Custom pattern and paste:

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": { "Label": ["CRITICAL"] },
      "RecordState": ["ACTIVE"],
      "Workflow": { "Status": ["NEW"] }
    }
  }
}

6. Target: SNS topic → security-critical-alerts.
7. Create. Done: the next Critical finding from any integrated service emails you within about five minutes of landing. The Workflow NEW line is there so a finding only fires on arrival — not again every time a check re-observes it, which, for a Critical you have scheduled for the weekend, is the difference between an alarm and a nag. Add "HIGH" next to CRITICAL if you want the wider net; on a small account that is a handful of emails a month, not a flood. Cost: EventBridge rules on service events are free, SNS email is free for the first thousand a month — $0, tested on Jake’s account against a deliberately public test bucket. The email arrived before the console refreshed.

Automation rules and suppression: taming the list without hiding the risk

Once findings flow, the practical enemy is volume, and CSPM gives you a native tool for it: automation rules, which act on findings as they arrive when they match criteria you define. The two honest uses: raising what matters to you (any finding touching your production bucket → severity CRITICAL — which then trips the alarm above; the two features compound nicely) and suppressing what you have consciously accepted (that dev-account control failure you re-triage every Monday → workflow SUPPRESSED, with the reason written in the rule’s note field where your future self can find it). The same discipline from the Inspector post applies: suppression is choosing not to look, and it is honest exactly as long as the reason is written down. Suppressed findings still exist and still close when fixed — they just stop shouting.

Past that, custom actions let you push a selected finding to EventBridge by hand — the standard trick for a "send to ticket" button — and the new Security Hub builds the rest of that road: native Jira and ServiceNow integrations that open tickets from findings without the EventBridge carpentry. Full auto-remediation (finding → Lambda → fix applied, untouched by humans) is real and well-documented, and my advice for a first account is the same as it was for Inspector’s: not yet. Read your findings by hand for a month first; automation is wonderful at scaling up judgment and terrifying at scaling up a misunderstanding.

Security Hub vs GuardDuty vs Inspector vs Config vs Macie

The whole family on one card — and in Ethan’s building, because that is how it will stay in your head:

The pairing logic bears repeating one last time, because exam questions and real decisions both turn on it: GuardDuty and Inspector are not alternatives — one watches events, the other watches state — and Security Hub is not an alternative to either: with nothing feeding it, the front desk is just an empty desk with a checklist. It is the reason this post comes after theirs in the series.

More than one account, more than one cloud

Like GuardDuty and Inspector before it, Security Hub follows the delegated administrator pattern for AWS Organizations: the management account designates one member account (use the same one across all your security services — future-you will be grateful) and that account sees and manages findings, standards, and rules for the whole organization, with central configuration policies deciding what is enabled where. If you run one account, file the term for the exam and move on.

The genuinely new development is the second half of this heading: Security Hub now reads beyond AWS. CSPM can run its checks against Microsoft Azure subscriptions (Azure checks bill at $0.0012 each), and the new Security Hub counts Azure VMs, Functions, container images, and identities as resource units like their AWS twins. It is early — AWS-side coverage is far deeper — but if your world is split across both clouds, one score covering both is no longer a third-party-only feature.

What AWS Security Hub does not do

The honest edges, so nothing on this page oversells: Security Hub stores no logs and searches no logs — it is not a SIEM, and "show me that IP’s history" remains a CloudTrail/Athena job. It detects nothing by itself beyond configuration checks — no GuardDuty means no threat findings, no Inspector means no CVEs, and the score can read 90% while an unpatched server sits wide open, if nothing that checks patches is enabled. It fixes nothing unless you explicitly build remediation on top. It is not retroactive — enabling it tells you nothing about last month. Its findings expire at 90 days — it is a queue, not an archive. And a checklist pass is not a guarantee: CIS compliance is a floor. The score going up means the doors you knew about are locked; it has never once meant there is nothing left to find.

If you’re here for the certification

A heads-up that is genuinely useful in 2026: most exam questions were written against the old naming, so when a question says "Security Hub," it almost always means what is now CSPM — answer for the front desk: aggregation ("single pane of glass"), CIS/FSBP checks, ASFF, automation via EventBridge. The tell-words table above settles the which-service questions, and the classic trap remains: Security Hub does not detect threats (GuardDuty), scan for CVEs (Inspector), or record configuration history (Config) — it consumes all three. Second-order facts that appear: it is regional with cross-region aggregation; it requires Config recording for checks; delegated administrator for Organizations; findings from a member account appear in the administrator’s view; and custom actions send findings to EventBridge. If a question mentions exposure findings or attack paths, it is new enough to mean the December 2025 product — and those questions are only beginning to appear.

FAQ — AWS Security Hub, answered straight

What is AWS Security Hub in one sentence?

The collection point of AWS security: Security Hub CSPM gathers findings from your other security services into one ranked list and scores your account’s configuration against best-practice standards, while the new Security Hub (December 2025) additionally correlates those findings into combined "exposure" risks with attack-path diagrams.

What is AWS Security Hub CSPM?

The product that was simply called "AWS Security Hub" from 2018 until December 2025, renamed when the new Security Hub launched. CSPM stands for Cloud Security Posture Management: continuous configuration checks against standards like FSBP and CIS, a security score, finding aggregation in ASFF format, and automation rules.

Is AWS Security Hub free?

No, but both products start with a 30-day free trial, and CSPM stays near-free at small scale — AWS’s own small-account example is $0.25/month, plus the AWS Config recording underneath (typically cents on a quiet account). The new Security Hub is $3.75 per resource unit per month after its trial.

Does AWS Security Hub cost money during the free trial?

The trial waives Security Hub’s own charges, but AWS Config — which its checks run on — bills normally from day one at $0.003 per recorded configuration item. Quiet accounts: cents. Accounts with churning infrastructure: check Billing after 48 hours.

Is AWS Security Hub a SIEM?

No. A SIEM ingests, stores, and searches raw logs; Security Hub only handles findings — conclusions other services drew from logs. It feeds SIEMs well (OCSF-format integrations with Splunk, Datadog, and others), and the Threat Analytics add-on analyzes CloudTrail events directly, but it does not replace one.

What is the difference between Security Hub and GuardDuty?

GuardDuty detects threats by analyzing activity logs; Security Hub collects and organizes findings, including GuardDuty’s, and runs configuration checks of its own. GuardDuty is a producer, Security Hub is the collector — you want both, and they bill separately.

How do I enable AWS Security Hub?

For CSPM: open Security Hub CSPM in the console, keep the FSBP standard selected, accept the AWS Config prompt, and choose Enable — about ten minutes, findings within hours. For the new Security Hub: open Security Hub, choose Get started, pick "Customize capabilities" (not "Enable all," which adds paid add-ons the trial excludes), choose regions, and Enable.

How do I disable AWS Security Hub?

Settings → General → Disable in each product’s console (per region), or aws securityhub disable-security-hub from the CLI. In an organization, the delegated administrator must release member accounts first. Disabling CSPM stops checks and, after 90 days, its stored findings are gone — export first if you need history.

Is AWS Security Hub a regional service or a global service?

Regional — each region runs and stores its own checks and findings. Both products support designating one aggregation region that mirrors findings from the others, which is the practical fix; and full CIS compliance expects CSPM enabled in every region you can use.

Can AWS Security Hub monitor multi cloud environments?

Azure, yes — since the 2025 relaunch, CSPM can check Azure subscriptions ($0.0012/check) and the new Security Hub counts Azure VMs, Functions, images, and identities as resource units. Coverage is deepest on AWS; other clouds and on-prem still arrive via third-party integrations.

What is AWS Security Hub Extended?

The new Security Hub’s partner tier: a curated set of roughly two dozen third-party security products (endpoint protection and more) you can buy, deploy, and read findings from through the Security Hub console, each billed at the partner’s own per-unit rates. Not covered by the free trial.

How do I export AWS Security Hub findings?

Quick and manual: the console’s findings page has a download for the current view. Repeatable: the GetFindings API/CLI with filters, or the EventBridge stream (every finding is an event) landing in S3 via Firehose. If an auditor will ever ask for history, set up the export before the 90-day retention makes the question academic.

What are exposure findings?

The new Security Hub’s signature output: one finding that correlates signals from CSPM, Inspector, GuardDuty, and Macie on the same resource — a vulnerability, on a reachable server, with an over-broad role — graded by exploitability and impact, with an attack-path diagram. One resource appears as the subject of at most one exposure finding, so the list stays short.

Does Security Hub fix anything automatically?

Not by default. Automation rules can modify or suppress findings and route them onward, and you can build full auto-remediation with EventBridge and Lambda (or use the new product’s Jira/ServiceNow ticketing) — but out of the box it reports, ranks, and alerts. The fixing is deliberately left to you.

Does enabling Security Hub also enable GuardDuty and Inspector?

No — each detector is enabled (and billed) on its own, though the new Security Hub’s Essentials price includes Inspector-class scanning and GuardDuty’s EC2 malware scanning once those are on. The one automatic coupling: enabling the new Security Hub switches on Security Hub CSPM, which it needs for raw material.

How long does Security Hub keep findings?

CSPM keeps a finding for 90 days after its last update, then deletes it. Active problems keep getting re-observed and effectively never expire; it is the history of resolved and stale findings that evaporates — export to S3 if you need an archive.

Where to go next

Revision note. I wrote this on August 31, 2026. The prices are from the Security Hub, Security Hub CSPM, and AWS Config pricing pages that morning, and the two-product split is from the AWS documentation and the December 2, 2025 GA announcement the same day. This page has the shortest shelf life in the series so far — AWS is actively reshaping both products — so if a number or a name looks off when you read it, it probably moved; drop me a line through the contact page and I will fix it. The alarm near the end is real: I tested the rule against a deliberately misconfigured test bucket, and the email beat the console refresh. The next post is AWS Config — the clerk this whole page quietly runs on, the one service billing you through everyone else’s free trial, and a recorder with settings worth ten minutes of your attention. And if you just enabled CSPM and got a number like Jake’s 43%: group the failures by root cause before you touch anything. It is four decisions, not sixty-one problems, and one of them — MFA on root — is tonight’s. The rest will keep until the weekend, and the score will follow.