GuardDuty, Inspector, Macie and Security Hub

By the end of this lesson you will be able to

• Explain why detection is needed on top of prevention, and which question each service answers: is someone attacking (GuardDuty), what could be attacked (Inspector), where is the sensitive data (Macie), what is the overall picture (Security Hub), how did it happen (Detective).
• Describe what Amazon GuardDuty reads, what its protection plans add, where it needs an agent, and how a finding becomes an automatic response through EventBridge.
• Describe how Amazon Inspector scans EC2 instances (with the SSM Agent or from EBS snapshots), ECR images and Lambda functions for CVEs and network exposure, and how it scores and rescans.
• Use Amazon Macie to find personal data and risky bucket settings in S3, with managed and custom data identifiers and allow lists.
• Explain what AWS Security Hub collects, why its security standards need AWS Config, and what changed in 2025 when the old service became Security Hub CSPM.
• Pick the right service from a scenario’s keywords and reject the look-alikes, including WAF, Shield, Config and CloudTrail.

#Why detection, not only prevention

#Locks are not enough

The earlier lessons of this chapter were about prevention: encrypt the data (21.1–21.5), filter the requests and absorb floods (21.6). Prevention fails in quiet ways. A developer pushes an access key to a public repository. A library that was safe last month gets a new CVE today. Someone exports a customer list to a bucket “just for one report” and forgets it. None of these trips a lock; all of them are visible if something is watching.

AWS splits that watching into separate managed services, each answering one question:

#Amazon GuardDuty: threat detection

#What GuardDuty watches

Amazon GuardDuty is an intelligent threat detection service. It continuously analyses activity in your account and raises findings when something looks malicious or unauthorised. It combines three techniques:

• Threat intelligence: lists of known malicious IP addresses and domains (mining pools, command-and-control servers, anonymising proxies), from AWS and partners.
• Machine learning and anomaly detection: it learns what is normal for each user, role and instance, and flags what is not (an API never called before, from a new country, at 3 AM).
• Known attack patterns: rules for behaviour such as port probing, credential use from outside AWS, or data hidden inside DNS queries.

When you enable it, GuardDuty immediately reads three foundational data sources:

• CloudTrail management events: every control-plane API call, such as RunInstances, CreateTrail or PutBucketPolicy. Unusual API calls and unauthorised deployments show up here.
• VPC flow logs for EC2 instances: unusual traffic, connections to known bad IPs.
• DNS logs from the Amazon-provided resolver: a compromised instance looking up a mining pool, or hiding stolen data inside DNS queries.

GuardDuty reads these from its own independent feed. You do not have to create a CloudTrail trail, turn on VPC Flow Logs or enable Route 53 Resolver query logging, and doing so changes nothing for GuardDuty; those are for your own use (lessons 19.6 and 22.3). Nothing is installed on your instances for this foundational detection, so it has no performance impact. Enabling it is one click; new accounts get a 30-day free trial, after which you pay by the volume of events analysed.

GuardDuty is Regional: a detector watches one Region. Enable it in every Region, including those you do not use, because those are where an attacker with a stolen key likes to launch instances.

#Protection plans

Beyond the foundational sources, GuardDuty offers optional protection plans, each watching another source. When you enable GuardDuty for the first time, all of them except Runtime Monitoring are turned on and included in the trial; you can turn any of them off.

#Findings and automated response

A finding is GuardDuty’s report of one potential problem. Its type name tells you what it is, in the form ThreatPurpose:ResourceType/ThreatFamily.Variant!Artifact, for example:

• CryptoCurrency:EC2/BitcoinTool.B!DNS: an instance is querying a domain linked to crypto-currency mining. GuardDuty has dedicated findings for crypto-mining, which is the most common result of a compromised instance.
• UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS: credentials of an instance’s role are being used from outside AWS.
• Trojan:EC2/DNSDataExfiltration: an instance is hiding data in DNS queries.

Each finding has a severity: Low (1.0–3.9), Medium (4.0–6.9), High (7.0–8.9) and Critical (9.0–10.0, used for attack sequences). Some practical tools:

• Sample findings generate one of each type, so you can test your alerting without being attacked.
• Suppression rules archive expected findings automatically (a security scanner you run on purpose).
• Trusted IP lists and threat lists add your own known-good and known-bad addresses.

GuardDuty finds; it does not block or fix. The response is something you build with Amazon EventBridge (lesson 19.5): every new finding is sent to the default event bus, usually within about five minutes (updates to an existing finding are sent every 6 hours by default; you can set 15 minutes or 1 hour). An EventBridge rule matches source: aws.guardduty and a severity, and targets SNS (email or chat for people) or Lambda (automatic action: isolate the instance with a quarantine security group, snapshot it for forensics, deactivate a leaked access key, block an IP in a NACL or WAF). For multi-step responses, the target can be a Step Functions workflow or a Systems Manager Automation runbook.

#Many accounts, every Region

In an organization, choose one account (usually a security tooling account, not the management account) as the GuardDuty delegated administrator through AWS Organizations (lesson 20.1). From there you enable GuardDuty for all member accounts, auto-enable it for accounts created later, choose the protection plans centrally and see every account’s findings in one place. Repeat per Region (or use the console’s multi-Region setup), because detectors are Regional. Members cannot turn off what the administrator manages.

#Amazon Inspector: vulnerability management

#What Inspector scans

Amazon Inspector is an automated vulnerability management service. It discovers your workloads by itself and keeps scanning them for software vulnerabilities and unintended network exposure. It covers exactly three kinds of resources:

• EC2 instances: operating system packages (and, on Linux, application language packages such as Python, Java and Node.js libraries) compared against known CVEs, plus network reachability.
• Container images in Amazon ECR: scanned when pushed and then continuously. This is ECR enhanced scanning, which is Inspector; ECR basic scanning is a one-time, OS-only scan (lesson 14.1).
• Lambda functions: standard scanning checks the function’s package dependencies when it is deployed or updated; code scanning also reads your own code for problems such as hard-coded secrets, injection flaws and weak cryptography.

It finds nothing outside these: not RDS engines, not S3 objects, not on-premises servers (that would be Systems Manager Patch Manager’s job for patching, lesson 25.3).

#How Inspector scans EC2: agent or snapshot

For EC2, Inspector needs the list of installed software. There are two ways to get it:

• Agent-based: through the SSM Agent (Systems Manager). The instance must be a managed instance: the agent running, plus an instance profile with AmazonSSMManagedInstanceCore (or Default Host Management Configuration). Inspector creates SSM associations that collect the inventory. This gives continuous scans: a new instance, a newly installed package or a new relevant CVE triggers a rescan.
• Agentless: for instances that are not managed by SSM, in hybrid scan mode Inspector takes EBS snapshots of the instance’s volumes, reads them through the EBS direct APIs, scans the packages and deletes the snapshots, about once every 24 hours.

An instance with no SSM Agent in an account set to agent-based mode shows as Unmanaged EC2 instance: no findings, and no warning unless someone opens the coverage page. Instances in private subnets need VPC endpoints (or a NAT gateway) to reach Systems Manager.

#Continuous scanning, risk score and findings

Inspector is continuous: you do not schedule assessments (the old Inspector Classic did, and its “assessment runs” are what the slides’ diagram still shows). It rescans a resource when a package is installed or removed, when an image is pushed, when a function is updated, and when a new CVE that affects it is published. When you fix the issue, the next scan sees it and closes the finding by itself. For ECR images this covers only images still inside the re-scan window: pushed or last in use (running on ECS/EKS) within the re-scan duration, 7 days by default for accounts that turn on ECR scanning from October 2026 (14 or 90 days on older accounts, configurable). Older idle images stop being monitored. Network reachability is analysed about every 12 hours from the security groups, NACLs, route tables and gateways (no packets are sent).

Every finding gets an Inspector score: Inspector starts from the CVE’s CVSS base score in the vulnerability database and adjusts it for your environment. A network-exploitable CVE on an instance with an open path from the internet keeps a high score; the same CVE on an instance with no network path in scores lower. This is what “a risk score is associated with all vulnerabilities for prioritisation” means.

Findings appear in the Inspector console and are sent to EventBridge (to open tickets, block a deployment, page someone) and to Security Hub. With AWS Organizations, a delegated administrator activates Inspector for every account.

#GuardDuty or Inspector?

The notes put it in one line: GuardDuty watches for live attacks and suspicious behaviour (threats); Inspector looks for software bugs and loopholes (vulnerabilities).

A vulnerability is an open window; a threat is someone climbing through it. Fixing Inspector’s findings is how you get fewer GuardDuty findings.

#Amazon Macie: sensitive data in S3

#What Macie finds

Amazon Macie is a fully managed data security and data privacy service. It uses machine learning and pattern matching to discover sensitive data in Amazon S3, such as personally identifiable information (PII): names, addresses, phone numbers, email addresses, credit card numbers, bank account numbers, passport numbers, national ID numbers, plus credentials such as private keys and AWS secret keys.

It works only on S3. Data in RDS, DynamoDB or EBS is out of its reach (export it to S3 first if you need it classified).

Macie decides what is sensitive with:

• Managed data identifiers: AWS’s built-in detectors for a long list of data types across many countries (credit card numbers, US social security numbers, passport numbers, several countries’ national IDs and tax numbers, AWS secret access keys…). Check the list for your country before relying on it.
• Custom data identifiers: your own detectors: a regular expression, optionally with keywords that must appear nearby and a maximum distance. Use them for formats the managed list does not cover: a Bangladeshi NID number, an internal customer ID, a loan account format.
• Allow lists: text or patterns Macie must ignore, such as your own public hotline number or test data, so real findings are not buried in noise.

It looks in two ways:

• Automated sensitive data discovery: Macie continually picks representative sample objects from all your buckets and inspects them, building a map of where sensitive data probably is, at low cost. Good for broad visibility across hundreds of buckets.
• Sensitive data discovery jobs: you choose buckets, a sampling depth and filters, and run a job once or on a schedule (daily, weekly, monthly). Good for a deep, targeted audit of specific buckets.

#Bucket inventory and policy findings

As soon as it is enabled, Macie also keeps an inventory of your S3 general purpose buckets and monitors each one’s security and access control: which buckets are public, which are not encrypted by default, which are shared with other accounts, and whether Block Public Access is on. When a bucket’s posture gets worse (Block Public Access turned off, the bucket becomes public, default encryption removed) Macie raises a policy finding. When it finds sensitive data in an object it raises a sensitive data finding, such as SensitiveData:S3Object/Personal or SensitiveData:S3Object/Financial.

To read objects encrypted with SSE-KMS under a customer managed key, Macie’s service-linked role must be allowed to use the key in the key policy (lesson 21.2); otherwise the objects are skipped. Objects encrypted with SSE-C can never be analysed, because AWS does not keep that key (lesson 10.8).

Findings go to EventBridge (as events, for alerts and automation) and, if you choose, to Security Hub. Macie reports; it does not delete, move or lock anything. With AWS Organizations, a delegated Macie administrator enables Macie and runs jobs for all member accounts. New accounts get a 30-day free trial for bucket monitoring and automated discovery; discovery jobs are always charged by the amount of data inspected.

#AWS Security Hub: one place for findings

#What Security Hub does

With five security services in 20 accounts and several Regions, nobody can open every console. AWS Security Hub gives one view:

• Aggregates findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, Systems Manager and many partner products, normalised into one format: the AWS Security Finding Format (ASFF).
• Runs security standards (cloud security posture management, CSPM): automated checks against AWS Foundational Security Best Practices, the CIS AWS Foundations Benchmark, PCI and NIST standards. Each control (“S3 buckets should block public access”, “security groups should not allow port 22 from anywhere”) produces a passed or failed finding and feeds a security score. Most controls run as service-linked AWS Config rules, so AWS Config must be enabled and recording in every account and Region you check (lesson 19.7).
• Cross-Region aggregation: link Regions to one home Region and see all findings there.
• Multi-account: a delegated administrator in AWS Organizations enables it centrally, with central configuration policies for which standards run where.
• Automation rules: change findings as they arrive (raise severity for production accounts, suppress a known false positive, add a note).
• EventBridge integration: every finding is sent to EventBridge; rules trigger Lambda, Step Functions, SSM Automation or a ticketing system. Custom actions let an analyst send a chosen finding to a workflow with one click.

Security Hub only shows findings created after it was enabled, only in the Regions where it is enabled. It has a 30-day free trial; after that you pay per check and per finding ingested.

#Security Hub and Security Hub CSPM (2025)

#Detective and the other security services

#Amazon Detective

Amazon Detective investigates. It automatically collects CloudTrail management events, VPC flow logs, GuardDuty findings (and, optionally, EKS audit logs and Security Hub findings) and builds a behaviour graph with machine learning, statistics and graph theory. From a finding, you pivot to an entity (an IAM role, an IP address, an instance) and see its activity over time: when it first appeared, what it called, which resources it touched, what is normal for it. Finding groups put related findings together. Detective does not create alerts and does not fix anything: GuardDuty detects, Detective explains the root cause.

#One line each for the rest

• AWS CloudTrail records who called which API, when and from where: the audit trail behind everything here (lesson 19.6).
• AWS Config records each resource’s configuration over time and evaluates it against rules (“is this volume encrypted?”); Security Hub’s standards run on it (lesson 19.7).
• IAM Access Analyzer finds resources shared outside your account or organization (external access), unused roles, keys and permissions, and validates policies (lesson 2.4, lesson 10.2).
• AWS Artifact is the self-service portal for AWS’s own compliance reports (SOC, ISO certifications, PCI) and agreements such as the BAA: “download AWS’s compliance reports for the auditor” → Artifact.
• AWS Audit Manager continuously collects evidence from your accounts and maps it to a framework (for example CIS or GDPR) to prepare your audit.
• AWS Trusted Advisor includes security checks (open ports, root MFA, exposed access keys, public snapshots) among its best-practice checks (lesson 26.1).
• WAF, Shield and Firewall Manager block and absorb attacks at the edge (lesson 21.6); they prevent, not detect compromise inside the account.

#One incident, seen by every tool

The services are most useful together. In the animation below, the same attack on an online shop is seen by each of them in turn. In the first version the warning is ignored; in the second it is acted on.

#Which service? Practise

#What goes wrong

#Threat detection in system design

#A baseline for every account

In a multi-account landing zone, threat detection is not a project per application; it is a baseline applied by the organization:

1. A dedicated security tooling account is the delegated administrator for GuardDuty, Inspector, Macie, Detective and Security Hub.
2. Each service is auto-enabled for every existing and new member account, in every Region.
3. Security Hub aggregates into one home Region; AWS Config records in every account and Region.
4. EventBridge rules in the security account send Critical and High findings to the on-call channel and to well-tested remediation functions.
5. SCPs (lesson 20.1) stop member accounts from disabling GuardDuty, Security Hub or Config.

#Automate carefully

Automatic responses are powerful and dangerous. Good candidates are reversible and well understood: quarantine an instance (keep it for forensics), deactivate an access key, turn Block Public Access back on, block an IP. Bad candidates are destructive: terminating instances (evidence lost), deleting data. Start with notification, then automate the responses you have seen many times. Use suppression rules and allow lists so that every alert that reaches a person is worth reading; alert fatigue is how real findings get ignored.

#Cost

All five services charge by usage (events analysed, resources scanned, data inspected, findings ingested), and all except Detective’s per-GB model start with a free trial. Look at the trial’s usage estimate before turning everything on everywhere: Macie discovery jobs on petabytes of logs, or S3 data event monitoring on a very busy bucket, can be the expensive parts. Automated discovery in Macie samples, which is why it is the cheaper default.

#Try it yourself

These commands are for a test account. They enable the services, generate sample findings and wire up a response.

# 1. GuardDuty: enable, create sample findings, list them
aws guardduty create-detector --enable --region ap-south-1
# { "DetectorId": "12abc34d567e8fa901bc2d34e56789f0" }
DET=12abc34d567e8fa901bc2d34e56789f0
aws guardduty create-sample-findings --detector-id $DET \
  --finding-types "CryptoCurrency:EC2/BitcoinTool.B!DNS"
aws guardduty list-findings --detector-id $DET \
  --finding-criteria '{"Criterion":{"severity":{"Gte":7}}}'
# { "FindingIds": [ "a2b4c6d8e0f1a3b5c7d9e1f3a5b7c9d1" ] }
aws guardduty get-findings --detector-id $DET \
  --finding-ids a2b4c6d8e0f1a3b5c7d9e1f3a5b7c9d1 \
  --query 'Findings[].[Type,Severity,Resource.InstanceDetails.InstanceId]'
# [ [ "CryptoCurrency:EC2/BitcoinTool.B!DNS", 8, "i-99999999" ] ]   (sample findings use placeholder IDs)

# 2. Route High findings to email through EventBridge and SNS
aws events put-rule --name guardduty-high \
  --event-pattern '{"source":["aws.guardduty"],"detail-type":["GuardDuty Finding"],"detail":{"severity":[{"numeric":[">=",7]}]}}'
aws events put-targets --rule guardduty-high \
  --targets Id=sec-email,Arn=arn:aws:sns:ap-south-1:111122223333:security-alerts
# (the SNS topic's access policy must allow events.amazonaws.com to publish)

# 3. Inspector: activate EC2, ECR and Lambda scanning, then read critical findings
aws inspector2 enable --resource-types EC2 ECR LAMBDA LAMBDA_CODE
# { "accounts": [ { "accountId": "111122223333", "status": "ENABLING", ... } ] }
aws inspector2 list-coverage \
  --filter-criteria '{"resourceType":[{"comparison":"EQUALS","value":"AWS_EC2_INSTANCE"}]}' \
  --query 'coveredResources[].[resourceId,scanStatus.reason]'
# [ [ "i-0abc1234def567890", "SUCCESSFUL" ], [ "i-0fed9876cba543210", "UNMANAGED_EC2_INSTANCE" ] ]
aws inspector2 list-findings \
  --filter-criteria '{"severity":[{"comparison":"EQUALS","value":"CRITICAL"}]}' \
  --query 'findings[].[title,inspectorScore,resources[0].id]'
# [ [ "CVE-2021-44228 - org.apache.logging.log4j:log4j-core", 10.0,
#     "arn:aws:ecr:ap-south-1:111122223333:repository/shop-api/sha256:4f2e..." ] ]

# 4. Macie: enable, add a custom data identifier for NID numbers, run a one-time job
aws macie2 enable-macie
aws macie2 create-custom-data-identifier --name bd-nid \
  --regex '\b(\d{10}|\d{13}|\d{17})\b' --keywords NID "National ID" \
  --maximum-match-distance 30
# { "customDataIdentifierId": "3a1b2c3d-4e5f-6a7b-8c9d-0e1f2a3b4c5d" }
aws macie2 create-classification-job --job-type ONE_TIME --name exports-audit \
  --custom-data-identifier-ids 3a1b2c3d-4e5f-6a7b-8c9d-0e1f2a3b4c5d \
  --s3-job-definition '{"bucketDefinitions":[{"accountId":"111122223333","buckets":["exports-example"]}]}'
# { "jobArn": "arn:aws:macie2:ap-south-1:111122223333:classification-job/...", "jobId": "..." }
aws macie2 list-findings --finding-criteria '{"criterion":{"category":{"eq":["CLASSIFICATION"]}}}'

# 5. Security Hub CSPM: enable with default standards, then read failed controls
aws securityhub enable-security-hub --enable-default-standards
aws securityhub get-findings --max-items 3 \
  --filters '{"ComplianceStatus":[{"Value":"FAILED","Comparison":"EQUALS"}],"SeverityLabel":[{"Value":"HIGH","Comparison":"EQUALS"}]}' \
  --query 'Findings[].[Title,Resources[0].Id]'
# [ [ "Security groups should not allow ingress from 0.0.0.0/0 to port 22",
#     "arn:aws:ec2:ap-south-1:111122223333:security-group/sg-0123456789abcdef0" ] ]

# 6. Clean up the test account
aws guardduty delete-detector --detector-id $DET
aws inspector2 disable --resource-types EC2 ECR LAMBDA LAMBDA_CODE
aws macie2 disable-macie
aws securityhub disable-security-hub

In the console, open GuardDuty’s Findings page after step 1 and read one sample finding fully: the resource, the actor, the action, the severity. Then open Security Hub’s Controls page and find the controls that show “No data”: those are the ones waiting for AWS Config.

#Summary

Key takeaways

• Detection complements prevention. Each service answers one question: GuardDuty (attacked now?), Inspector (what could be attacked?), Macie (where is sensitive data?), Security Hub (overall picture), Detective (how did it happen?).
• GuardDuty: ML + threat intelligence + anomaly detection over CloudTrail management events, VPC flow logs and DNS logs, read from its own feed (you enable nothing else). Protection plans add S3 data events, EKS audit logs, Runtime Monitoring (agent), Malware Protection (EC2 volumes, S3 uploads), RDS logins, Lambda network activity. Regional, one click, 30-day trial, dedicated crypto-mining findings. It detects only: route findings with EventBridge to SNS or Lambda.
• Inspector: continuous vulnerability management for EC2, ECR images and Lambda only. CVEs in packages, network reachability for EC2, code scanning for Lambda. EC2 via the SSM Agent or agentless EBS snapshots (hybrid mode). Rescans on new CVEs, scores findings from CVSS adjusted to your environment, sends to EventBridge and Security Hub.
• Macie: ML + pattern matching for PII in S3 only; managed and custom data identifiers, allow lists, automated discovery (sampling) vs discovery jobs; bucket inventory with policy findings for public, unencrypted or shared buckets. It is Amazon Macie; it reports, it does not block.
• Security Hub: aggregates findings (ASFF) from many services and accounts, runs standards (AWS Foundational Security Best Practices, CIS…) that need AWS Config, automation rules, cross-Region aggregation, EventBridge. Since 2025 that service is called Security Hub CSPM, and the new Security Hub correlates exposures on top of it.
• Detective investigates root cause with a behaviour graph. Config = settings, CloudTrail = API calls, Access Analyzer = external and unused access, Artifact = AWS’s reports, Audit Manager = your evidence, WAF/Shield = blocking.

Self-check: threat detection and security services30 questions