Amazon GuardDuty and Amazon Inspector

At 03:00 an EC2 instance in your production account opens a connection to an IP address in a country where you run nothing. Nobody deployed anything. Separately, that same instance has been running a version of a system library with a published CVE for 5 weeks.

Two facts about one instance, and 2 different questions. The first is "is something bad happening right now?" The second is "what could an attacker use if they got in?" AWS answers them with 2 different services, and the exam spends most of its detection questions on which service answers which question. Skill 4.2.5 asks you to configure reports and remediate findings from AWS Security Hub, Amazon GuardDuty, AWS Config, Amazon Inspector, and AWS Security Agent. This lesson takes the first 2 detectors in that list.

Behavior versus state

The cleanest way to hold these apart is that GuardDuty reads activity and Inspector reads inventory.

That last row is the practical difference. A GuardDuty finding is a report about the past that never fixes itself; an Inspector finding is a description of the present that disappears when you patch. Keep that in mind when a question describes a finding "that closed on its own" or one "that stayed open after the instance was terminated".

GuardDuty reads logs you never had to turn on

Enable GuardDuty in a Region and it immediately starts consuming 3 foundational data sources:

• AWS CloudTrail management events, the control plane calls such as AttachRolePolicy, CreateSubnet, and CreateTrail.
• VPC Flow Logs from the EC2 instances in the account.
• Route 53 Resolver DNS query logs, the name lookups your instances perform.

Here is where a predictable misconception starts. It is tempting to assume you must create a CloudTrail trail and enable VPC flow logs first, the way you would for most log-consuming services. You do not. GuardDuty consumes each of these through an independent, duplicated stream. Your CloudTrail configuration does not affect what GuardDuty sees, and GuardDuty does not affect your CloudTrail configuration. Disabling flow logs on a VPC does not blind GuardDuty. There is also no extra charge for the log access itself; you pay GuardDuty's own pricing after the 30-day free trial.

The DNS source carries the one real dependency, and it is a favorite exam detail. GuardDuty reads DNS queries through the internal AWS DNS resolvers. If your instances use the AWS-provided resolver, which is the default, GuardDuty sees the queries. If you point them at OpenDNS, Google DNS, or a resolver you run yourself, GuardDuty cannot access that data at all, and every DNS-based finding type goes quiet. Enabling Route 53 Resolver query logging does not fix it, because GuardDuty uses a separate stream rather than that feature.

One more behavior worth knowing before you decide which Regions to enable. Global service events, from IAM, AWS STS, S3, CloudFront, and Route 53, are recorded by CloudTrail in one Region but matter everywhere. GuardDuty replicates those events and processes them in every Region where you have it enabled, which is how it keeps a user and role profile per Region. That is the argument for turning GuardDuty on even in Regions where you deploy nothing: an attacker who creates resources in an unused Region is exactly the case those profiles catch.

Protection plans widen the surface

The 3 foundational sources are the baseline. Everything else GuardDuty can watch comes from an optional protection plan, which the API calls a feature. Each one adds a log or event source:

Two details about how these switch on. When you enable GuardDuty for the first time, all protection plans except Runtime Monitoring are enabled automatically and included in the 30-day free trial. If you were already a GuardDuty customer when a plan launched, that plan is not enabled automatically and you have to opt in, which is why long-lived accounts often have coverage gaps that new accounts do not.

Malware Protection for S3 is the one exception to the whole model: you can use it on its own without enabling the GuardDuty service at all. Every other protection plan requires GuardDuty.

Malware Protection for EC2 comes in 2 flavors that scenario questions like to separate. A GuardDuty-initiated malware scan fires automatically when a finding suggests malware on an instance, runs at most once every 24 hours per resource, and has its own 30-day free trial. An on-demand malware scan is one you start yourself with an instance ARN, requires no feature-level configuration beyond GuardDuty being enabled, can be repeated on the same resource 1 hour after the previous scan started, and has no free trial. Both honor the global GuardDutyExcluded tag. Snapshots of the scanned volumes are retained only when malware is found, and only if you configured retention.

Sitting above all of this is Extended Threat Detection. It correlates events across data sources, resource types, and time inside one account to spot multi-stage attacks, then writes an attack sequence finding. It costs nothing extra, needs no protection plan, and is enabled automatically with GuardDuty. It is also the reason attack sequence findings land in the Critical band while individual signals sit lower: each event alone looked survivable, and the sequence did not.

Reading a finding type without opening the finding

GuardDuty names every finding type with the same grammar:

ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.DetectionMechanism!Artifact

Walk one real type through it. CryptoCurrency:EC2/BitcoinTool.B!DNS says: the adversary's purpose is cryptocurrency activity, the affected resource type is an EC2 instance, the family of activity is a known Bitcoin tool, .B is the detected variant, and !DNS names the artifact, meaning the instance was talking to a known Bitcoin-related domain.

Two values in the DetectionMechanism position carry extra meaning:

• .Custom means the match came from a threat list you uploaded, not from AWS threat intelligence.
• .Reputation means a domain reputation score model produced the match.

The ThreatPurpose values are worth skimming once because several map directly onto MITRE ATT&CK tactics: Backdoor, Behavior, CredentialAccess, Cryptocurrency, DefenseEvasion, Discovery, Execution, Exfiltration, Impact, InitialAccess, Pentest, Persistence, Policy, PrivilegeEscalation, Recon, Stealth, Trojan, and UnauthorizedAccess. You do not need to memorize the list, but you should recognize that Policy means a best-practice violation rather than an attack, and that Pentest means the activity looks like known penetration testing tools, which GuardDuty cannot tell apart from an actual adversary using the same freely available tools.

Severity is a number from 1.0 to 10.0, split into 4 bands:

Scenario questions usually hand you the number, not the label, so the boundary values are the part to hold.

Aggregation, archiving, and the delay that surprises people

GuardDuty does not create a new finding for every packet. When it detects new activity tied to the same security issue, it updates the original finding and increments the Count, replacing the details with the most recent occurrence. Repeated SSH brute force attempts against one instance stay a single finding; the same attack against a second instance creates a second finding with its own ID, because that is a distinct security issue with a distinct resource.

That aggregation has a delivery consequence. New active findings reach EventBridge within about 5 minutes. Updates to existing findings follow a separate setting, Frequency for updated findings, which defaults to every 6 hours and can be set to 15 minutes or 1 hour. So an ongoing attack, which arrives as updates rather than new findings, can sit for hours before your remediation Lambda hears about it. If a question describes automation that "fired late" on a continuing incident, this setting is the answer.

Suppression rules are how you cut noise. A rule is filter criteria plus a value, and new findings matching it are automatically archived. Three properties matter:

1. Suppressed findings are not sent to Security Hub CSPM, Amazon S3, Amazon Detective, or EventBridge, and they do not trigger Malware Protection for EC2 scans. This is the point: it silences the SIEM, not just the console.
2. The findings are still generated and stored in GuardDuty for 90 days, viewable by filtering on Archived.
3. In a multi-account setup, only the GuardDuty administrator can create suppression rules.

There is a cost to suppressing broadly that is easy to miss. Archived findings are not used as signals when Extended Threat Detection correlates events into attack sequences. Suppress every EKS cluster finding and you have also removed GuardDuty's ability to notice a chain where an attacker exploits a container, grabs a privileged token, and reaches sensitive resources. AWS's own guidance is to build suppression rules reactively, for specific behaviors you have repeatedly confirmed as false positives, never as a blanket filter.

Inspector scans what you deployed

Amazon Inspector discovers workloads on its own and scans them continuously. There is no assessment to schedule and no scan window to plan. When a resource changes, when you install a package, or when a new CVE relevant to that resource is published, Inspector rescans. When you fix the problem, it detects the remediation and closes the finding for you.

It produces 3 finding types:

Network reachability is the one that catches people out on 2 counts: it is EC2 only, and it runs on a 12-hour cycle rather than continuously.

Severity deserves a note because Inspector does something Config and GuardDuty do not. It takes the National Vulnerability Database CVSS base score and adjusts it for your environment, producing the Amazon Inspector score. A network-exploitable vulnerability on an instance with no open path to the internet scores lower than the same CVE on an internet-facing instance. Two accounts can hold the same CVE at different severities and both be correct.

Retention rules follow the state model. Findings for deleted, terminated, or no-longer-eligible resources are closed automatically and deleted after 3 days. Findings closed for any other reason are deleted after 30 days. A remediated finding that reappears within 7 days is reopened rather than recreated. Findings on stopped instances stay active, because a stopped instance still has the vulnerable package on disk.

Agent-based, agentless, and how Inspector picks

Package vulnerability scanning on EC2 uses one of 2 collection methods, and the choice per instance is not arbitrary.

Agent-based scanning collects the software inventory through the SSM Agent. The instance must be a managed instance in Systems Manager in the same account, which in practice means the SSM Agent installed and running plus an instance profile granting SSM permission (the AmazonSSMManagedInstanceCore managed policy covers everything Inspector needs). Inspector creates its own SSM associations, with names ending in -do-not-delete, to install collection plugins and pull inventory. This method scans continuously: at launch, when new software is installed on Linux and Mac, and when a newly published CVE affects the instance. It is also the method that supports Inspector deep inspection for application programming language packages on Linux.

Agentless scanning needs nothing on the instance. Inspector snapshots every attached EBS volume, tags the snapshot with InspectorScan, reads it through the EBS direct APIs, generates findings, then deletes the snapshot. An instance is eligible when it has a supported OS, has a status of Unmanaged EC2 instance, Stale inventory, or No inventory, is EBS backed with an ext3, ext4, or xfs file system, has fewer than 8 attached volumes totaling 1200 GB or less, and is not excluded by tag.

Hybrid scanning mode combines the 2 and is what activating EC2 scanning enrolls you in: SSM managed instances go the agent-based route, and eligible unmanaged instances get agentless coverage. Agentless scans run every 24 hours, and Inspector looks for newly eligible instances every hour. A standalone account or the Inspector delegated administrator can change the scan mode, and when the delegated administrator sets it, the mode applies to every member account in the organization.

One consequence to expect rather than debug: the same instance can produce different findings depending on which method scanned it. On Linux, agentless scanning inspects all available paths for language packages, while agent-based scanning covers the default paths plus any extra paths you configured for deep inspection.

To take an instance out of scanning entirely, tag it with the key InspectorEc2Exclusion. The tag key is case-insensitive and the value is optional. Excluded instances are not charged.

Beyond package scanning, Inspector also runs CIS scans against EC2 operating systems. These target instances by tag, need the instance to be SSM managed with the AmazonInspector2ManagedCisPolicy permissions attached, and run once on demand or on a daily, weekly, or monthly schedule. You pick CIS Benchmark Level 1 for baseline settings that should not disrupt service, or Level 2 for high-security environments, where Level 2 includes everything in Level 1.

Suppression means 2 different things

This is the boundary most worth carrying out of the lesson, because both services use the same word for genuinely different behavior.

Delete an Inspector suppression rule and the matching findings return to Active and are published to Security Hub CSPM and EventBridge again. Delete a GuardDuty suppression rule and future matches simply stop being archived; the ones already archived stay archived until you unarchive them.

Running both across an organization

Both services integrate with AWS Organizations through a delegated administrator, and both are Regional, but the details differ enough to be tested.

For GuardDuty, the Organizations management account designates the delegated administrator, and enabling it there activates GuardDuty in that Region only. The rule that trips people is a pair: the designation is per Region, and it must be the same account in every Region. Designate account 111122223333 in Ireland and you cannot designate 555555555555 in Canada. Auto-enable preferences let the administrator cover NEW member accounts only or ALL accounts including existing ones, and the NEW setting has an ordering trap in opt-in Regions: the member must opt into the Region before joining the organization, or it is no longer new. One administrator manages a maximum of 50,000 member accounts. Removing the delegated administrator removes the member associations but leaves GuardDuty enabled in those accounts.

For Inspector, the delegated administrator can activate the service for the whole organization in one step and set automatic activation for accounts that join later. It can view aggregated findings for all members, activate or deactivate scans for them, set the EC2 scan mode for the entire organization, and own CIS scan configurations at the organization level. There is one privacy boundary: the delegated administrator cannot view code snippets belonging to member accounts, because code vulnerability findings include captured source.

Exam tips

• "Is someone attacking?" points at GuardDuty. "What is vulnerable or exposed?" points at Inspector. A question mentioning CVEs, patch levels, or container images is Inspector even when it uses security language.
• Nothing needs to be enabled before GuardDuty. If an option says "first enable VPC flow logs" or "first create a CloudTrail trail", it is wrong.
• The exception is DNS. A non-AWS resolver means no DNS findings, and no setting anywhere fixes it.
• Malware Protection for S3 works without GuardDuty enabled. Every other protection plan requires it.
• Runtime Monitoring is the one protection plan not enabled automatically on first activation.
• Severity boundaries: Low 1.0-3.9, Medium 4.0-6.9, High 7.0-8.9, Critical 9.0-10.0. Critical implies an attack sequence from Extended Threat Detection.
• New findings hit EventBridge in about 5 minutes; updates follow the export frequency, default 6 hours. Late automation on an ongoing attack is almost always this setting.
• GuardDuty suppression stops downstream delivery. Inspector suppression does not. Do not let the shared word merge them.
• Inspector network reachability is EC2 only, every 12 hours. Agentless package scanning is every 24 hours. Different numbers, different mechanisms.
• Hybrid mode: SSM managed goes agent-based, unmanaged and EBS backed goes agentless. Exclude with the InspectorEc2Exclusion tag.
• GuardDuty delegated administrator: per Region, same account everywhere, 50,000 member ceiling, designated only by the Organizations management account.

The thing to carry forward is the split in the first table: GuardDuty tells you something happened, Inspector tells you something is possible. Neither one ranks the two against each other, deduplicates them, or does anything about them. A GuardDuty High on an instance that Inspector already flagged with a remotely exploitable CVE is a different situation from either finding alone, and no single detector can say so. That correlation, and the automation that acts on it, is what the next lesson builds with Security Hub.