Amazon Inspector

Amazon Inspector is an automated vulnerability scanner. It continuously looks at your EC2 instances (the virtual servers you rent from AWS), your container images, and your Lambda functions (small bits of code AWS runs for you), and tells you which ones contain known software flaws. It matches the software you run against public lists of security bugs called CVEs (Common Vulnerabilities and Exposures — each is a uniquely numbered, publicly known security flaw, like CVE-2024-3094). This matters because most breaches happen through old, unpatched software, and finding those weak spots by hand across hundreds of servers is impossible.

What Inspector actually does

Inspector runs in the background. Once you turn it on for an account, it keeps watching your resources and re-scans them automatically whenever new vulnerability data is published or your software changes. There is no scan button to press on a schedule; it is continuous.

It covers three resource types:

Resource type	What it scans for	How it scans
EC2 instances	Operating system packages and application libraries with known CVEs; risky network paths reachable from the internet	Uses the SSM agent to read your installed packages (no separate agent to install)
ECR container images	OS and language-package CVEs inside the image layers	Scans on push and re-scans existing images when new CVEs appear
Lambda functions	Vulnerable dependencies in your function code and layers	Scans the deployed code package automatically

For each finding, Inspector calculates an Inspector score that blends the CVE severity with real context — for example, whether the vulnerable instance is actually reachable from the internet. This risk-based prioritization means you fix the genuinely dangerous issues first instead of drowning in a flat list of thousands of CVEs.

Important gotcha: Inspector finds vulnerabilities — it does not fix them. There is no auto-patch. You still need a patching process (for example AWS Systems Manager Patch Manager) to actually remediate what Inspector reports.

When to use this (and when not to)

Use Inspector when you run your own EC2 instances, build container images, or ship Lambda functions and you need ongoing assurance that they are free of known CVEs. It is the right tool for software vulnerability management.

Do not reach for Inspector to detect active attacks, suspicious API calls, or compromised credentials — that is what GuardDuty is for. And it does not classify sensitive data in S3; that is Amazon Macie. Inspector answers one question: “what known software flaws exist in my compute, and how risky are they?”

The SSM coverage gotcha for EC2

This is the trap that catches most teams. To scan an EC2 instance, Inspector needs that instance to be managed by AWS Systems Manager (SSM) — a service that lets AWS securely run commands and read configuration inside your servers. Inspector uses the SSM agent already present on most modern Amazon Machine Images (AMIs) to read the list of installed packages.

If an instance is not registered with SSM, Inspector silently skips it. It does not error. It does not warn you on the main dashboard. The instance simply never appears in your findings — which looks identical to an instance that was scanned and found clean.

For an instance to be SSM-managed it needs three things:

1. The SSM agent installed and running (default on current Amazon Linux, Ubuntu, and Windows AMIs).
2. An IAM instance profile attached that grants the AmazonSSMManagedInstanceCore policy.
3. Network reach to the SSM endpoints (via an internet/NAT gateway or VPC endpoints).

Verify coverage before you trust the results. A “clean” Inspector report with poor SSM coverage gives a false sense of security. Always confirm how many instances are actually being scanned versus how many you run.

Check SSM-managed instances from the CLI:

aws ssm describe-instance-information \
  --query "InstanceInformationList[].{Id:InstanceId,Ping:PingStatus}" \
  --output table

Output:

-------------------------------------
|     DescribeInstanceInformation   |
+----------------------+------------+
|         Id           |   Ping     |
+----------------------+------------+
|  i-0a1b2c3d4e5f      |  Online    |
|  i-0f9e8d7c6b5a      |  Online    |
+----------------------+------------+

Compare that count against your running instances. Any instance missing from this list is invisible to Inspector.

You can also check Inspector’s own coverage view directly:

aws inspector2 list-coverage \
  --filter-criteria '{"resourceType":[{"comparison":"EQUALS","value":"AWS_EC2_INSTANCE"}]}' \
  --query "coveredResources[].{Id:resourceId,Status:scanStatus.statusCode}" \
  --output table

Output:

----------------------------------------
|             ListCoverage             |
+-------------------+------------------+
|        Id         |     Status       |
+-------------------+------------------+
|  i-0a1b2c3d4e5f   |  ACTIVE          |
|  i-0f9e8d7c6b5a   |  INACTIVE        |
+----------------------------------------

An INACTIVE status usually means the instance is not reachable through SSM.

Enabling Inspector

Console steps

1. Sign in to the AWS Management Console and open the Amazon Inspector console.
2. Choose Get started (first time) or open Account management in the left menu.
3. Select which scan types to turn on: EC2 scanning, ECR scanning, and Lambda scanning.
4. Choose Activate Inspector. Scans begin automatically within minutes for eligible resources.
5. Open Findings > All findings to review results, sorted by Inspector score.

CLI equivalent

Enable all three scan types for the current account:

aws inspector2 enable \
  --resource-types EC2 ECR LAMBDA

Output:

{
    "accounts": [
        {
            "accountId": "123456789012",
            "resourceStatus": {
                "ec2": "ENABLED",
                "ecr": "ENABLED",
                "lambda": "ENABLED"
            },
            "status": "ENABLED"
        }
    ],
    "failedAccounts": []
}

List your highest-risk findings:

aws inspector2 list-findings \
  --filter-criteria '{"severity":[{"comparison":"EQUALS","value":"CRITICAL"}]}' \
  --query "findings[].{Title:title,Score:inspectorScore,Resource:resources[0].id}" \
  --output table

Output:

-----------------------------------------------------------------------------
|                                ListFindings                               |
+--------------------------------------+--------+---------------------------+
|                Title                 | Score  |        Resource           |
+--------------------------------------+--------+---------------------------+
|  CVE-2024-3094 - xz-utils            |  9.8   |  i-0a1b2c3d4e5f            |
|  CVE-2023-44487 - HTTP/2 Rapid Reset |  7.5   |  arn:aws:lambda:...:api    |
+--------------------------------------+--------+---------------------------+

Cost

Inspector is priced per resource scanned, not per scan. As a 2026 guide: EC2 instances are roughly $1.258 per instance per month, ECR image scans are about $0.09 per image on initial scan (with re-scans bundled), and Lambda function scanning is about $0.30 per function per month. There is a 15-day free trial when you first activate it. Because it bills per resource, turning on scanning across many idle or short-lived instances can add up — disable scan types you do not need.

Best practices

• Activate Inspector account-wide using AWS Organizations and a delegated administrator account, so new accounts are covered automatically.
• Always verify SSM coverage against your running instance count; treat an empty findings list with suspicion, not relief.
• Bake the SSM agent and the AmazonSSMManagedInstanceCore instance profile into your base AMIs and launch templates so every new instance is scannable from boot.
• Route Inspector findings into AWS Security Hub or Amazon EventBridge to drive automated tickets and remediation workflows.
• Prioritize remediation by Inspector score, not raw CVE severity — fix internet-reachable critical findings first.
• Remember Inspector only reports; pair it with Systems Manager Patch Manager to actually patch what it finds.
• Suppress accepted-risk findings with suppression rules so your dashboard stays focused on what genuinely needs action.

Related Topics

• Security overview
• Amazon GuardDuty
• AWS Security Hub
• Amazon Macie
• Security best practices