Amazon Inspector is the default vulnerability scanner for most AWS-only shops, largely because it ships built into the console and turns on with a single toggle per account. The question that actually matters for a security engineer evaluating it is narrower than is it good: what does it actually cover, how fresh are its findings, and at what point do its blind spots start costing more than a second tool would. This article works through Inspector’s real coverage boundaries, its refresh cadence, its cost curve, and the point where teams typically add something else next to it.
Inspector’s actual coverage: EC2, ECR images, Lambda functions
Inspector v2, the current generation that replaced Inspector Classic, scans three asset types: EC2 instances, container images in Amazon ECR, and Lambda functions and their layers. Coverage differs meaningfully by type.
For EC2, Inspector requires the SSM Agent to be installed and running, and the instance must be managed by Systems Manager. If SSM Agent is missing, out of date, or the instance role lacks the AmazonSSMManagedInstanceCore policy, the instance simply does not appear in findings, silently, with no error banner telling you it was skipped. On EC2, Inspector performs both package vulnerability scanning, matching installed packages against the CVE database, and, if enabled, network reachability analysis that flags instances exposed to the internet through security groups and route tables.
For ECR, Inspector scans images on push when continuous scanning is enabled for the repository, and re-scans existing images as new CVEs are published. It covers OS packages and, since the language package scanning expansion, a subset of application dependency manifests, including Java, Python, Node.js, Go.NET, Ruby, and Rust, inside the image layers.
For Lambda, Inspector scans function code and its dependency layers for known vulnerable packages, but only for supported runtimes, and only for functions that enter the scan queue after being updated or invoked. Container-image-based Lambda functions are scanned the same way ECR images are.
What is conspicuously absent from all three: on-premises servers, other clouds, SaaS configurations, network appliances, and anything not running the SSM Agent or not stored in ECR. Inspector is an AWS-workload scanner, not a general-purpose vulnerability management platform, and its own documentation does not claim otherwise.
How findings are generated and how often they refresh
Inspector does not run on a fixed daily or weekly schedule the way a traditional scanner does. It operates on an event-driven model: a new finding can appear when a new CVE is published in the National Vulnerability Database, when a monitored resource changes such as a new package install, a new image push, or a modified security group rule, or on periodic re-evaluation of already-scanned resources. In practice EC2 package findings usually surface within a few hours of a CVE’s publication, not after the next scheduled scan window.
The tradeoff is that continuous does not mean instant everywhere. Network reachability findings, which depend on VPC route table and security group evaluation, re-run less frequently than package findings and can lag actual configuration changes by several hours. ECR re-scanning of existing images, as opposed to on-push scanning, happens on Amazon’s schedule, not yours, and there is no button to force an immediate re-evaluation of an entire repository on demand.
Findings carry a severity score derived from CVSS plus an Inspector-specific adjustment that factors in exploitability data and, for EC2, network exposure. This adjusted score is useful for prioritization inside Inspector itself, but it is calculated independently of anything happening outside AWS, so it cannot account for compensating controls, WAF rules, or business context that live elsewhere.
Gaps: non-AWS assets, container runtime behavior, application layer, exceptions
Four gaps come up repeatedly in teams that have run Inspector for more than a quarter.
Non-AWS assets are the most obvious: on-prem file servers, colocated hardware, SaaS misconfigurations, and workloads in other clouds get zero coverage. Any organization running a hybrid estate needs a second source of truth for everything outside AWS, and reconciling two separate finding lists by hand does not scale past a handful of assets.
Container runtime behavior is a second gap. Inspector scans the image, not the running container. It will not tell you that a container is running as root when it does not need to, that a pod has an unnecessarily broad set of Linux capabilities, or that a process inside a container opened a listening socket it should not have. That is runtime security territory, the domain of tools like Falco or a CNAPP’s runtime sensor, and Inspector’s static image scan does not substitute for it.
Application layer coverage is the third and probably the most consequential gap for anyone running a web-facing product. Inspector has no SAST, no DAST, and no dependency scanning for application source code outside the specific package-manager manifests it supports inside container images and Lambda packages. It will not find a SQL injection, an IDOR, a broken authorization check, or a business-logic flaw. Teams that rely on Inspector alone for vulnerability management typically carry a large application security blind spot they have not measured yet.
Exceptions and suppression are the fourth gap. Inspector supports suppression rules, but they are matched by filter criteria such as resource tags, finding type, or package name, rather than by a documented risk-acceptance workflow with expiry dates, approver identity, and an audit trail. For a SOC 2 or ISO 27001 audit, a suppression rule is a weaker artifact than a ticket where a named approver accepted a risk for 90 days with a documented compensating control.
Cost behavior at scale and what triggers surprise billing
Inspector’s pricing is per-resource, per-month, with separate rates for EC2 instances, ECR images, and Lambda functions, and it bills based on the number of resources actively scanned, not a flat account fee. A few mechanics catch teams off guard.
- ECR image cost is driven by the number of unique images scanned, and CI pipelines that push a fresh image tag on every commit multiply the scanned-image count fast. A repository with hourly builds can accumulate thousands of billable image scans a month even if only a handful of tags are ever deployed.
- Lambda function cost scales with the number of functions, not the number of invocations, so an account with a sprawl of small, rarely used functions left over from old experiments pays for scanning coverage nobody uses.
- EC2 cost is per instance-month, so autoscaling groups that churn instances frequently do not reduce cost proportionally, since Inspector still evaluates each instance while it exists.
- Enabling Inspector organization-wide across many linked accounts without first tagging or excluding sandbox and test accounts is the single most common cause of a bill that lands three to five times higher than the security team expected in month one.
The fix is not to avoid Inspector, it is to scope activation deliberately: exclude ephemeral CI or CD image repositories from continuous scanning where a manual pre-deploy scan is enough, prune unused Lambda functions before enabling Lambda scanning, and review the per-account cost breakdown monthly instead of assuming a flat rate.
When Inspector is enough and when teams add a second layer
Inspector is genuinely sufficient for a team whose entire estate is AWS-native, whose applications are already covered by a separate AppSec program with SAST and DAST in the CI pipeline, and whose compliance obligations do not require a documented exception workflow beyond what Inspector’s suppression rules provide. For a single-cloud shop running standard EC2 and container workloads, adding a second infrastructure scanner purely for redundancy usually is not worth the licensing cost or the alert fatigue of two systems disagreeing on severity for the same CVE.
The calculus changes once any of the following becomes true: the estate includes non-AWS assets, or the compliance framework in play, such as PCI DSS, SOC 2, ISO 27001, GDPR, KVKK, or BDDK for regulated Turkish entities, needs findings mapped to specific controls rather than a flat severity list. That is a capability platforms such as SITEY build in as compliance mapping rather than a manual spreadsheet exercise. The same is true once the security team needs a single dashboard that correlates infrastructure findings with application findings and manual pentest results instead of stitching together exports from three consoles by hand. At that point, teams typically keep Inspector running as their AWS data source and add a second layer above it for aggregation, deduplication, and workflow, rather than replacing it.
Feeding Inspector output into a unified remediation workflow
Inspector exposes findings through the console, through EventBridge events, and through the Inspector2 API, which makes it straightforward to pull findings into a downstream system rather than triaging them inside the AWS console indefinitely. The practical pattern is: Inspector stays the collector for AWS-native resources, and its findings get normalized alongside output from other integrated scanners, network scanners, SAST and DAST tools, and cloud posture scanners for non-AWS accounts, into one pipeline that deduplicates overlapping findings, scores them with business context Inspector does not have, and tracks remediation to closure.
Deduplication matters more than it sounds like in this specific pairing: the same underlying package vulnerability on an EC2 instance and inside a container image it also affects can show up as two separate Inspector findings with two separate ARNs, and again as a third finding if a network scanner also flags the exposed port. Platforms that automate this phase, such as SITEY, ingest raw findings from Inspector alongside the rest of a scanning stack, collapse duplicates that describe the same underlying weakness, and run AI validation to strip out findings that are technically present but not actually exploitable in context, before anything reaches a human’s queue.
Retest is the other piece Inspector does not close on its own. Inspector marks a finding resolved once its own next scan no longer detects the vulnerable package version, but it does not verify that a patch was applied correctly rather than simply that the package manifest changed, and it has no concept of a ticket-based approval gate before a fix reaches production. A workflow that re-tests the specific finding after a patch, instead of trusting that a new scan cycle happened to come back clean, closes that gap and gives an auditor a defensible trail from detection to verified fix.
For teams building this out, the practical next steps are: confirm SSM Agent coverage across every EC2 fleet before assuming Inspector sees everything, budget for ECR scan volume based on unique tags rather than deployment count, decide up front which compliance framework’s exception process needs to be satisfied since Inspector’s native suppression will not fully cover it, and pick one place where AWS findings and everything else converge instead of triaging Inspector, a SAST tool, and a network scanner as three unrelated backlogs.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.