What Is Amazon Inspector? The Inspector Who Checks the Locks

Amazon Inspector is the vulnerability scanner for your AWS account — a managed service that reads the list of software installed on your EC2 servers, your container images, and your Lambda functions, compares every package against more than fifty feeds of known security holes (CVEs), checks which of your servers are reachable from the internet, and hands you a ranked list of what to patch first. No scan to schedule, no scanner to install by hand, and when you fix something it notices and closes the finding on its own. It is the natural next stop after GuardDuty: the guard watches for someone trying the doors; the inspector walks the building first and tells you which locks are already known to be broken. And here is the finding most readers will see on their very first scan, because of a date that passed two months ago: Amazon Linux 2 — the default AWS Linux for the better part of six years — reached end of support on June 30, 2026, and Inspector now files a CRITICAL finding against every server still running it, whether or not a single package on it is vulnerable. The operating system itself is the finding. This post explains what Inspector is and is not (it is not GuardDuty, not an antivirus, and it blocks nothing), what its three kinds of findings mean, why the score it gives a vulnerability can be lower than the one on the internet, what the 15-day trial covers and what the bill looks like after it, and it keeps the promise the GuardDuty post made: a $0 alarm that emails you the moment a Critical finding appears.

This is the twentieth stop in the Learn AWS for Free series, and it is the post the GuardDuty post promised. That one gave you a guard who reads the logs and shouts when someone is trying a door. This one answers the question the guard cannot: which of your doors were already broken before anyone tried them? A server with a two-year-old OpenSSL, a container built on an Alpine image nobody has rebuilt since spring, a Lambda function importing a library with a known injection bug — none of those show up in a log, because nothing has happened yet. Inspector is the service AWS built to look before something happens, and like GuardDuty it is one of the few security services a solo builder can switch on and genuinely trust to run itself.

What is Amazon Inspector used for? The inspector who checks the locks

My friend Ethan, who has now explained four AWS security services to me using the same imaginary office building, finished the picture over a coffee. The building has a smoke detector (CloudWatch), a key-card log (CloudTrail), and a guard who reads that log all night (GuardDuty). "Now," he said, "think about who visits the building once a year with a clipboard. The fire inspector. She does not care who has been through the doors. She walks every floor with a list of every lock, hinge, and extinguisher model that has ever been recalled, and she checks whether you have any of them. Then she leaves you a report, ranked by how bad each one is, and comes back to see whether you fixed it."

That is Amazon Inspector, with one improvement on the human version: it does not come once a year. It walks your building continuously, every time you install something, and every time a new recall notice is published anywhere in the world. Its list of recalls is the CVE system — Common Vulnerabilities and Exposures, the public registry every vendor security advisory ends up in — and Inspector pulls from more than fifty of those feeds, updating at least daily. Its "building" is three kinds of resource: EC2 instances, container images stored in Amazon ECR, and Lambda functions. And its report is a list of findings, each one a specific vulnerable package on a specific resource, with the fixed version named and, where AWS knows it, the exact command to run.

"So GuardDuty is about behavior and Inspector is about condition," I said. Ethan nodded. "The guard would never notice a rusted lock. The inspector would never notice a burglar. You want both, and they cost about the same as a sandwich."

How does Amazon Inspector work? Inventory, advisories, and three ways to read a disk

Every Inspector scan is the same two-step trick. Step one: get the list of installed software and versions off the resource — the inventory. Step two: compare that inventory against the advisory feeds and write a finding for every package that has a known fix or a pending one. The interesting engineering is all in step one, because getting an inventory off a running server without slowing it down is harder than it sounds, and AWS gives you three ways to do it.

Agent-based scanning uses the Systems Manager agent (SSM), which is already installed on most Amazon-provided images. Inspector creates a few SSM "associations" in your account — you will see resources with names like InspectorInventoryCollection-do-not-delete appear, and the name is good advice — and uses them to collect the package list every 30 minutes and to re-scan whenever you install something or a new relevant CVE lands. This is the continuous option, and the only one that can do deep inspection: looking inside application language packages (Python, Java, JavaScript) rather than only the operating system’s own package manager. Since 2025 there is also an upgraded path AWS calls Enhanced EC2 Scanning, which installs a dedicated Inspector VM Scanner through those same associations and gives more consistent results, especially on Windows; it is opt-in under Settings → Scan settings and AWS recommends it.

Agentless scanning is for the servers that are not managed by SSM — the agent is missing, stopped, or has no permission. Inspector takes an EBS snapshot of the instance’s volumes (in your account, tagged InspectorScan), reads the package list straight off the snapshot using the EBS direct APIs, and deletes the snapshot when it is done. It runs every 24 hours, needs an ext3/ext4/xfs filesystem, and works only on instances with fewer than 8 volumes totaling 1,200 GB or less. It costs more per instance than the agent, but it finds servers the agent cannot see, and on Linux it scans every path for language packages rather than only the default ones, which is why the same server can produce slightly different findings under the two methods.

Hybrid scanning is simply both: agent where the agent works, snapshot where it does not. It is what a new account gets by default, and it is the right setting for almost everyone. The one caveat is cost — the agentless rate is about 40 percent higher — so if your fleet is entirely SSM-managed there is a small saving in switching the scan mode to agent-only.

Network reachability is a separate, simpler scan that runs every 12 hours regardless of method: Inspector reads your VPC configuration — security groups, network ACLs, route tables, internet gateways, load balancers, peering connections — and works out, on paper, which TCP and UDP ports on which instances can be reached from the edge of your network. It needs nothing installed anywhere, because it is reading the map, not knocking on doors.

Is Inspector an antivirus? A firewall? GuardDuty? Three questions, three straight answers

Is Amazon Inspector an antivirus? No. An antivirus looks for malicious files that are present. Inspector looks for legitimate software that has a published weakness. A server can be spotless by one measure and full of holes by the other. If you want the malware angle on AWS, that is GuardDuty’s Malware Protection plan, not Inspector.

Does Inspector block or fix anything? No, and this is the one to internalize. Inspector is a reporting service. It tells you the package, the fixed version, and often the exact apt or yum line; it never runs that line for you. Nothing you switch on in Inspector can take a server offline or change a security group. The only automation it offers is the EventBridge event, which you can wire to whatever you like — including, if you are brave and careful, a Systems Manager patch run. We will wire it to an email.

Is Inspector the same as GuardDuty? No, and the AWS naming does not help. GuardDuty reads logs for signs of an attack in progress. Inspector reads your software list for weaknesses an attack could use. GuardDuty needs no agent because it reads logs AWS already has; Inspector needs a way onto the disk, which is the whole agent-versus-snapshot story above. They are priced separately, enabled separately, and complement each other exactly. If you can afford only one and you are a solo builder with a public server, I would honestly pick Inspector first — a known unpatched hole on a public port is the way most small accounts actually get compromised, and it is the one you can fix before it matters.

What does Inspector detect? The three finding types in plain English

Where GuardDuty has roughly two hundred finding types, Inspector has three, and every finding you will ever see is one of them. The names are on the finding itself under Type, and the machine-readable versions (PACKAGE_VULNERABILITY, CODE_VULNERABILITY, NETWORK_REACHABILITY) are what you filter on in EventBridge later.

Two details worth knowing before you open the console. First, on Windows servers the package findings are keyed by Microsoft KB numbers rather than individual CVEs — one finding named KB5023697 can stand for a dozen CVEs that update fixes, and it carries the worst score among them. If you are here from the Windows side of this blog, that will feel familiar. Second, code vulnerability findings capture a snippet of your source to show you the problem, and that snippet can contain the very secret it is warning you about; it is encrypted at rest with an AWS-owned key by default, and you can supply your own KMS key if that matters to you.

The Inspector score: why a "Critical" CVE can arrive as Medium

Here is the second thing that surprises people, and it is a pleasant one. You will read on a news site that some CVE is "rated 9.8, Critical." Inspector finds it on your server and lists it as Medium. That is not a bug; it is the whole point of the Inspector score.

The number on the news site is the CVSS base score from the National Vulnerability Database — a rating of the vulnerability in the abstract, assuming the worst case: reachable over the network, no privileges needed, and so on. Inspector starts from that base score and then adjusts it for your environment. If the vulnerability is exploitable over the network but Inspector’s reachability scan shows the instance has no open path from the internet, it lowers the Attack Vector metric and the score drops. If exploit code is known to be circulating, it says so. The finding’s Inspector score and vulnerability intelligence tab shows both numbers side by side, metric by metric — Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope, Confidentiality, Integrity, Availability — with a sentence explaining every difference. Below that sits the intelligence: the MITRE ATT&CK techniques the CVE maps to, whether CISA has put it on the Known Exploited Vulnerabilities list and the date it wants systems patched by, any known malware kits that use it, and the last date a public exploit was seen.

That tab is the single most useful screen in the service, because it turns "I have 212 findings" into "I have four that are reachable, have a public exploit, and are on CISA’s list — those four are today." Two limits, stated plainly: the score exists only for package findings on EC2 (containers and Lambda show the vendor score), and it is not available for Ubuntu, because Canonical uses its own severity system rather than CVSS.

Jake’s first scan: 212 findings, and the one that was the whole server

Jake — the phone-shop owner whose AWS account has been the test bed for this whole series — switched Inspector on the evening after the GuardDuty post went up, on the theory that the guard had earned his keep and the inspector might too. He had one EC2 instance, the little t3.micro that runs his stock-lookup page, three Lambda functions from the link-shortener project, and a handful of container images from an experiment he had abandoned in spring. Twenty minutes after enabling, the dashboard said 212 findings. He sent me a screenshot with no text at all, which for Jake is the equivalent of a scream.

Two hundred and twelve sounds like a catastrophe and is a Tuesday. Most of them were Medium and Low package findings on the server — the ordinary sediment of a Linux box that had not been rebooted since March: a kernel, OpenSSL, curl, a Python library, each with a fix already sitting in the repository. One sudo apt update && sudo apt upgrade and a reboot closed 180 of them by the following morning, because Inspector re-reads the inventory after you install things and closes findings on its own when the fixed version shows up. Nobody clicked "resolve." The inspector simply came back, saw the new lock, and crossed it off.

The finding that mattered was the one at the top, and it was not a package. CRITICAL — Amazon Linux 2 reached end of standard support on June 30, 2026. The abandoned container images had been built on an AL2 base, and one of Jake’s earlier servers, since terminated, had run it too. Inspector’s position on discontinued operating systems is blunt and, I think, correct: a vendor that has stopped publishing advisories has stopped telling you about holes, so the absence of findings means nothing, so the OS itself is the finding. The fix is not a patch; it is a rebuild on Amazon Linux 2023, and Inspector will keep generating that Critical for twelve months after the discontinue date and then go quiet — not because the server got safer, but because the feeds dried up. Jake deleted the images, which closed the findings three days later, and made a note to check the base image on anything he builds again.

The last one was small and taught him the most. A single network reachability finding: port 22 on the stock-lookup server reachable from an Internet Gateway. He had opened SSH to the world in 2024 "for a minute" to fix something from a café. The minute was twenty months long. He changed the rule to his home IP, and twelve hours later, on the next reachability pass, the finding closed itself. Total spend on the exercise: one evening, one reboot, and about eleven cents of Inspector time.

How to enable Amazon Inspector, step by step (and what appears in your account)

Inspector is regional, like GuardDuty: you enable it in each region where you have resources, and findings live in the region of the resource. The enable itself is about ninety seconds; the choices inside it are where I will slow down.

1. Sign in with an IAM identity that has administrator rights, open the Amazon Inspector console, and confirm the region selector at the top right shows the region your servers live in. If you use two regions, you will do this twice.
2. Click Get started. The page shows the scan types that will switch on: Amazon EC2 scanning, Amazon ECR container image scanning, and AWS Lambda standard scanning. Lambda code scanning is a separate checkbox; leave it off for the trial unless you write Lambda code by hand — it is the one option that reads your source.
3. Click Activate Inspector. The 15-day free trial starts now, for every scan type, and the Usage page will show a projected monthly bill from day one, which is the honest way to decide what to keep.
4. Within a few minutes, look at Account management → Instances. Every EC2 instance shows a status: Managed (SSM agent working, agent-based scan), Unmanaged EC2 instance (no working agent — hybrid mode will snapshot it within an hour), or Unsupported OS. If an instance you expected to be managed says unmanaged, the usual cause is a missing instance profile; attach the AmazonSSMManagedInstanceCore policy to the instance’s role and the status flips on the next inventory pass.
5. Look at Systems Manager → State Manager if you are curious. You will find the associations Inspector created — InspectorInventoryCollection-do-not-delete, InspectorDistributor-do-not-delete, and a few more. They are the mechanism. If one is deleted by accident, Inspector recreates it at the next interval; deleting them on purpose does not turn Inspector off, it just makes it blind.
6. Under Settings → Scan settings, optionally click Start upgrade for Enhanced EC2 Scanning. On Windows servers in particular this is worth doing on day one.
7. Give it twenty minutes, then open Findings, sort by severity, and read the first five. The intelligence tab on each is where the real triage happens.

Excluding a resource is a tag, not a setting: put the tag key InspectorEc2Exclusion on an instance (any value, case-insensitive) and Inspector stops scanning it and stops billing for it. The same tag on a KMS key excludes every encrypted volume that key protects from agentless scanning. Lambda functions have an equivalent exclusion tag, and functions not invoked or updated in 90 days drop out of scanning on their own.

Is Amazon Inspector free? The 15-day trial and the honest price list

There is no permanent free tier for Inspector, and I would rather tell you that in the H2 than in the last paragraph. What there is: a 15-day free trial for any account new to the service, covering every eligible instance, image, and function, with a live projected bill on the Usage page the whole time. After that, you pay per resource, prorated — an instance that exists for ten days of the month is billed for ten days. These are the US East (N. Virginia) rates on the AWS pricing page as of August 2026; the pricing page’s own examples use the same region.

Notice what is not on the list: there is no charge for findings, no charge for the reachability scan, no charge for events, and no charge for excluded instances. The price is a function of how much you own, not how insecure it is.

How much does Inspector cost for a small account? A worked example

Take Jake’s account after the cleanup: one t3.micro that is SSM-managed, three Lambda functions that run daily, and five container images he now keeps. In a 30-day month:

• 1 instance × $1.258 = $1.26
• 3 functions × $0.30 = $0.90
• 5 images: he rebuilt them once this month (5 × $0.09 = $0.45) and two were re-scanned for new CVEs (2 × $0.01 = $0.02) = $0.47
• Network reachability, findings, EventBridge, email: $0.00

Total: about $2.63 a month. Add GuardDuty’s few dollars from the last post and the whole security-monitoring layer on a one-server business costs less than the coffee Ethan drinks while explaining it. If Jake had left the SSH port open and been quietly mined for a weekend, the EC2 bill alone would have exceeded a year of Inspector. That comparison — the watcher must never cost more than the watched, and here it costs a rounding error — is the entire argument.

Containers: enhanced scanning, and the 14-day window that quietly stops re-scanning your images

Amazon ECR, the container registry, has two scanning modes and the names are the only confusing part. Basic scanning is ECR’s own: operating-system packages only, on push or on demand, billed by ECR. Enhanced scanning hands the job to Inspector: operating-system and language packages, exploitability data, findings that flow to EventBridge and Security Hub, and continuous re-scanning when new CVEs appear. Activating Inspector’s ECR scanning sets enhanced as the registry’s preferred scanner; whether a given repository is "scan on push" or "continuous" is still set on the ECR side, and Inspector will show you the setting but cannot change it.

Now the detail that catches container people, and it is a change from May 2025. With continuous scanning on, Inspector only keeps re-scanning an image while it is inside a window: pushed within the last 14 days, or pulled/in use within the last 14 days, or inside whatever re-scan duration you configure (the options run from 14 days up to the image’s lifetime). Outside that window, the image is not deleted and its existing findings are not deleted — but no new CVE will ever be matched against it again until it is pushed or pulled. An image you built in March and have run untouched since is, from Inspector’s point of view, exactly as safe as it was in March. Accounts created before May 16, 2025 kept the older 90-day default; new accounts get 14. If you keep long-lived images, go to Settings → ECR re-scan duration and set it to something honest, understanding that each re-scan is a penny.

Two more container facts that save an afternoon. Archived images (ECR’s ARCHIVED status) are never scanned, and their findings close and disappear three days after archiving. And Inspector can map images to the containers actually running on ECS and EKS, including Fargate — the finding detail shows this image is running in 3 tasks right now, which is a far better priority signal than the CVSS number. That data takes up to 36 hours to appear for a new image and refreshes daily.

Lambda: standard scanning, code scanning, and the 90-day rule

Lambda standard scanning looks at the dependencies you bundle with a function — the requests or lodash in your deployment package and its layers — and reports package vulnerabilities exactly as it does for a server. It covers Python, Node.js, Java, .NET, Go, and Ruby runtimes, plus the Amazon Linux custom runtimes. It scans a function when it first discovers it, whenever you deploy an update, and whenever a new relevant CVE lands. Only the $LATEST version is scanned, and only functions invoked or updated in the last 90 days; the rest are automatically excluded and pick up again the moment they run.

Lambda code scanning is the add-on that reads your actual handler code. It uses automated reasoning and the detector library AWS built with Amazon Q to look for injection flaws, data leaks, missing encryption, weak cryptography, and hardcoded credentials, and each finding comes with a snippet, a location, and a suggested replacement block you can paste in. AWS is careful to say the suggestions may not work as intended and that you are responsible for reviewing them, which is the right disclaimer for any machine-written patch. Two constraints: it requires standard scanning to be on first, and neither scan type can read a function encrypted with a customer-managed KMS key.

One quiet side effect worth knowing: activating Lambda scanning creates CloudTrail service-linked channels in your account, which Inspector uses to hear about function deployments. They are harmless and show up in the CloudTrail console; AWS still recommends you keep your own trail, for the reasons the CloudTrail post gave.

CIS scans: checking a server against the hardening checklist for three cents

Everything above is about vulnerable software. CIS scans are about misconfigured settings: the Center for Internet Security publishes a benchmark for each operating system — hundreds of checks like "password expiry is set," "the audit daemon is running," "root login over SSH is disabled" — and Inspector can run that checklist against an SSM-managed instance and give you a pass/fail/skipped per check. You pick Level 1 (basic settings that will not break anything) or Level 2 (the stricter set for regulated environments; it includes Level 1), target instances by tag, and run once or on a daily, weekly, or monthly schedule. It supports AL2023, RHEL, Rocky, SLES, Ubuntu 20.04 through 24.04, and Windows Server 2016 through 2025, needs the AmazonInspector2ManagedCisPolicy on the instance role in addition to the SSM one, and costs three cents per instance per assessment. For a solo builder, a monthly Level 1 scan on the one public server is three cents well spent; the results read like a to-do list written by someone more careful than you.

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

Inspector publishes every new finding, and every change to a finding’s state, to EventBridge in the region where it happened, with source aws.inspector2 and detail-type Inspector2 Finding. An EventBridge rule that matches on severity and hands the event to an SNS topic with your email on it is the same seven-step pattern the CloudWatch, CloudTrail, and GuardDuty posts used, and it costs nothing: EventBridge’s default bus is free for AWS-service events, and SNS email is free at any volume you will ever reach. If you built the GuardDuty alarm, you already have the SNS topic; skip to step 4.

1. Open Amazon SNS → Topics → Create topic. Type Standard, name it security-alerts, create it.
2. On the topic, Create subscription: protocol Email, endpoint your address. Create it.
3. Open the confirmation email SNS sends and click Confirm subscription. Until you do, the topic silently drops everything — this is the step people miss.
4. Open Amazon EventBridge → Rules → Create rule. Name it inspector-critical-email, event bus default, rule type Rule with an event pattern. Next.
5. Under Event pattern, choose Custom pattern (JSON editor) and paste:

   {
     "source": ["aws.inspector2"],
     "detail-type": ["Inspector2 Finding"],
     "detail": {
       "severity": ["CRITICAL"],
       "status": ["ACTIVE"]
     }
   }

   Add "HIGH" to the severity list if the account is public-facing and you want the weekly-fix tier by email too. The status line matters: without it you would also be emailed every time a finding closes. Next.
6. Target: AWS service → SNS topic → security-alerts. Next, Next, Create rule.
7. Test it honestly. There is no "generate sample findings" button in Inspector as there is in GuardDuty, so the cleanest test is to temporarily change the pattern’s severity to ["MEDIUM"], install and then remove a deliberately old package on a test instance, or simply push a container image built from an old base — FROM alpine:3.16 will do it, since Alpine 3.16 is discontinued — wait for the email, then set the pattern back to Critical and delete the image.

The rule is regional. If you enabled Inspector in two regions, build the rule in both; the SNS topic can be shared across them by ARN. And if you are the delegated administrator for several accounts, this one rule in the admin account receives every member account’s findings, with the originating awsAccountId in the event.

Suppression rules: hiding the noise without hiding the risk

A suppression rule is a saved filter with the action hide. Findings that match it get the status Suppressed, drop out of the default view, stop being sent to EventBridge and Security Hub — and keep existing, keep being tracked, and close normally when fixed. A rule cannot close or remediate anything, which is the right design: you are choosing not to look, and the service is refusing to pretend the problem is gone. Rules can take up to 24 hours to apply, and in an organization only the delegated administrator can create them.

Jake’s first rule, and the one I would suggest to any solo builder: Severity is Low, and Resource tag env=dev. Low findings on a throwaway box are information, not work. His second was more surgical: Vulnerability ID is CVE-xxxx, and Fix available is NO — a kernel issue Canonical had marked as needing no action, which Inspector kept listing because no fixed version existed to compare against. To build one: Suppression rules → Create rule, add criteria from the filter bar (severity, resource type, tag, vulnerability ID, fix available, and a dozen more), name it, save. The rule page shows what it is hiding, so you can audit your own blind spots.

What happens to a finding: auto-close, the three-day deletion, and the seven-day reopen

Findings have three states — Active, Suppressed, Closed — and you never set any of them by hand. Inspector closes a finding when it sees the fix; if the same vulnerability comes back within seven days of closing (you rolled back a deploy, say), it reopens the same finding rather than making a new one. When a resource is terminated, deleted, or stops being eligible, its findings close and are deleted three days later. Findings closed for any other reason are deleted after 30 days. Disable Inspector entirely and everything is gone in 24 hours. And one detail that trips people: a stopped instance is not a terminated one — its findings stay Active, because the vulnerable software is still on the disk waiting for the next start.

If you need findings to outlive those windows — for an audit, or because you want a year of history — export them. Findings → Export findings writes a CSV or JSON report to an S3 bucket with a KMS key you choose; do it monthly and the history is yours. Security Hub keeps its own copy for 90 days if you have it enabled, which is the subject of the next post.

Inspector vs GuardDuty vs Security Hub vs Macie vs Trusted Advisor vs Inspector Classic

The Classic row is worth a sentence because the search results still lead to it. If a tutorial tells you to create an "assessment template" or install the "Amazon Inspector agent," it is describing the old service, which AWS closed to new accounts some time ago and switched off for everyone on May 20, 2026. The current service has no templates and no dedicated agent to install; it rides on SSM or snapshots, as described above.

What Amazon Inspector does not do

• It does not patch. Every finding names the fix; you or your automation applies it. Systems Manager Patch Manager is the AWS tool for the applying.
• It does not scan software outside the package manager. Linux detection covers the default rpm/dpkg repositories and, with deep inspection, Python/Java/JavaScript packages. A binary you compiled and copied to /opt is invisible to it. It also does not scan toolchain vulnerabilities — a bug in the Go or Rust compiler version that built your app.
• It does not see inside a running container. It scans the image in ECR and maps it to running tasks; it does not inspect what a process did after start.
• It does not scan your laptop, your on-premises servers, or another cloud — with the recent exception of Azure VMs, Azure Container Registry, and Azure Functions, which it can now cover through an integration at similar per-resource rates.
• It does not give an Inspector score on Ubuntu, or on container and Lambda findings; those show the vendor severity.
• It does not run forever on old operating systems. Twelve months after a vendor discontinues an OS, Inspector stops generating findings for it. Silence on a dead OS is not safety.

More than one account: the delegated administrator

If you use AWS Organizations, nominate one account as the Inspector delegated administrator from the management account, and from then on that account can activate Inspector across every member with one click, auto-enable it for accounts that join later, see every member’s findings in one list, set the EC2 scan mode for everyone, and own the suppression rules. Member accounts still see their own findings. The one asymmetry AWS calls out: the administrator cannot view the code snippets attached to a member’s code vulnerability findings — those stay with the account that owns the code. Same shape as GuardDuty, and if you already set that up, the Inspector version takes two minutes.

If you’re here for the certification

The exams love to put GuardDuty, Inspector, Macie, and Security Hub in one question and ask which one does what. The tell-words: vulnerabilities, CVEs, unintended network exposure, EC2/ECR/Lambda → Inspector. Threat detection, malicious activity, compromised credentials, logs → GuardDuty. Sensitive data, PII, S3 buckets → Macie. Aggregate findings, compliance standards, single pane → Security Hub. Second-order facts that appear: Inspector needs the SSM agent for agent-based scanning (or agentless via snapshots in hybrid mode); it integrates with EventBridge and Security Hub; it is regional; it has a delegated administrator model; and the Inspector score adjusts CVSS for network reachability. If a question mentions "assessment templates," it is a Classic question and the answer is usually "migrate."

FAQ — Amazon Inspector, answered straight

What is Amazon Inspector in one sentence?

A managed vulnerability scanner that continuously inventories the software on your EC2 instances, ECR container images, and Lambda functions, matches it against known CVEs and your network exposure, and produces severity-ranked findings with the fix named — without patching or blocking anything.

What does Amazon Inspector do?

Three things: finds vulnerable packages (package vulnerability findings), finds servers reachable from outside your VPC (network reachability findings), and, for Lambda with code scanning on, finds flaws in your own code (code vulnerability findings). It also runs optional CIS benchmark checks against server configuration.

What is Amazon Inspector primarily used for?

Vulnerability management: knowing which of your workloads have known, fixable security holes, ranked by how exposed they actually are in your account, so you patch the right things first.

Is Amazon Inspector free?

No permanent free tier. New accounts get a 15-day free trial across all scan types; after that it is per resource — about $1.26 per EC2 instance-month, $0.09 per container image, $0.30 per Lambda function-month in US East as of August 2026. Excluded resources and findings themselves cost nothing.

How much does Amazon Inspector cost for a small account?

One SSM-managed instance, three Lambda functions, and five container images rebuilt monthly comes to roughly $2.63 a month. Agentless scanning raises the instance line to $1.75; Lambda code scanning adds $0.60 per function.

Amazon GuardDuty vs Amazon Inspector — what is the difference?

GuardDuty reads logs to detect attacks and misuse happening now; Inspector reads software inventories to find weaknesses an attack could use later. GuardDuty needs no agent; Inspector needs SSM or a snapshot to read the disk. They are separate services, separately priced, and meant to run together.

Does Amazon Inspector require an agent?

Not necessarily. Agent-based scanning uses the Systems Manager agent already on most AWS images; agentless scanning reads an EBS snapshot instead and needs nothing installed. A new account runs in hybrid mode and uses whichever works for each instance. There is no separate "Inspector agent" to install anymore — that was Inspector Classic.

Why is my EC2 instance showing as "Unmanaged" in Inspector?

The SSM agent is not running or has no permission. Attach an instance profile with the AmazonSSMManagedInstanceCore policy (or turn on SSM Default Host Management Configuration), confirm the agent is started, and the status changes on the next inventory pass. Until then, hybrid mode scans it agentlessly once a day.

What is the Amazon Inspector score and why is it different from the CVSS score?

The Inspector score starts from the NVD or vendor CVSS base score and adjusts it for your environment — most often lowering it when the instance has no network path from the internet. The finding shows both scores and explains each metric that changed. It applies to EC2 package findings only and is not available on Ubuntu.

What does "fix available" mean in an Inspector finding?

Whether the vendor has published a fixed package version (YES), has not yet (NO), or has fixed only some of the affected packages (PARTIAL). Findings with no fix available are candidates for a suppression rule until the vendor ships one.

Does Amazon Inspector patch vulnerabilities automatically?

No. It reports and names the fix. Patching is Systems Manager Patch Manager or your own deployment process. Inspector does detect when the fix is applied and closes the finding on its own.

Does Amazon Inspector scan containers?

Yes — images in Amazon ECR, through ECR’s enhanced scanning mode: OS and language packages, continuous re-scanning while an image is within the re-scan window (14 days pushed or pulled by default for new accounts), and mapping to the ECS/EKS tasks currently running each image.

Does Amazon Inspector scan Lambda functions?

Yes. Standard scanning checks the packaged dependencies of any function invoked or updated in the last 90 days; the optional code scanning add-on checks your own handler code for injection, leaks, weak crypto, and hardcoded secrets.

Why does Inspector show a Critical finding for Amazon Linux 2?

Because Amazon Linux 2 reached end of standard support on June 30, 2026, and Inspector raises a Critical finding for any resource on a discontinued operating system. The fix is migrating to Amazon Linux 2023 (or rebuilding images on a supported base), not a package update.

Is Amazon Inspector always on?

Once activated in a region, yes: it rescans EC2 on install and on new CVEs (agent) or daily (agentless), images on push and on new CVEs within the window, Lambda on deploy and on new CVEs, and network reachability every 12 hours. There is nothing to schedule except CIS scans.

Can I get an SBOM from Amazon Inspector?

Yes. Inspector can export a software bill of materials for scanned resources in CycloneDX or SPDX format to an S3 bucket, and its ScanSbom API can scan an SBOM you already have. Exports are free; the API scans are priced separately.

What happened to Amazon Inspector Classic?

It was retired. Support ended May 20, 2026, and the console and resources are no longer accessible. Everything described here is the current service, sometimes called Inspector v2, which has no assessment templates and no dedicated agent.

How do I get an email when Inspector finds something Critical?

An EventBridge rule matching source aws.inspector2, detail-type Inspector2 Finding, severity CRITICAL, and status ACTIVE, with an SNS email topic as the target. Seven steps, $0, above.

Does Inspector send findings to Security Hub?

Automatically, if Security Hub is enabled in the same region. Suppressed findings are not sent. Security Hub is the next post in this series.

Where to go next

Revision note. I wrote this on August 30, 2026. The prices are from the Inspector pricing page that morning, and the list of supported and discontinued operating systems is from the user guide the same day. Those two things are what AWS changes most, so if a number here looks off when you read it, it probably moved — drop me a line through the contact page and I will fix it.. The next post is Security Hub, the page where CloudWatch, CloudTrail, GuardDuty, and Inspector finally all land in one place. And if you opened Inspector and got a number like Jake’s 212: sort by severity, read the top one, check whether it is reachable, and reboot. Most of the list goes away. The few that stay are the actual job, and it is a smaller job than the number suggests.