Amazon Inspector Pricing Guide: Sizing Vulnerability Scanning Spend

Amazon Inspector v2 launched as a managed vulnerability scanner for EC2, ECR container images, and Lambda functions. It works well. It is also priced on a per-asset basis that compounds across multi-account organisations. The original Inspector was nearly free for many customers; Inspector v2 commonly bills $30K to $300K per year before any discount. This guide walks the pricing model and the scoping decisions that decide whether the bill is at the lower or upper end of that range.

Pricing dimensions

Notice the EC2 number is the heavyweight. For a fleet of 5,000 instances, EC2 scanning alone is ~$75K/year. ECR and Lambda are typically smaller, but the function counts in mature serverless shops climb quickly.

Where the bill lands in real environments

• EC2-heavy enterprises: 80 percent of Inspector spend lands on EC2 continuous scanning. Right-sizing the fleet (which is the right move regardless) is the biggest lever.
• Container-heavy enterprises: ECR scanning is small per image but ECR re-scans on every CVE publication compound. Image hygiene matters here.
• Serverless-heavy enterprises: Lambda function counts in mature shops easily exceed 5,000; that is $1,500 to $2,250 per month just on function inventory.

The four cost-driving anti-patterns

1. Inspector enabled organisation-wide before scoping. The default behaviour is to scan everything. In environments with thousands of EC2 instances in dev and test, the first-month bill triples.
2. Long-lived images in ECR. An ECR repository with hundreds of historical images that nobody is using still bills re-scan charges when CVEs publish.
3. Lambda function count without lifecycle. Forgotten Lambda functions from past projects still count for scanning even though they have not been invoked in months.
4. Agentless and agent scanning both enabled. Some teams enable agent-based and agentless EC2 scanning simultaneously, doubling the bill without doubling the value.

Scoping strategy that actually works

1. Production-first. Enable Inspector on production accounts and selected staging accounts. Exclude developer sandboxes; dev vulnerabilities do not have production blast radius.
2. Tag-based exclusion. Use Inspector exclusion rules driven by tags. Build a scan: false tag policy with documented review intervals.
3. Agentless for ephemeral fleets. Auto-scaling groups with short-lived instances are better scanned via the agentless snapshot path than via continuous agent.
4. ECR repository pruning. Implement a lifecycle policy that deletes images older than 90 days. Reduces re-scan volume by 60 to 80 percent.
5. Lambda inventory rationalisation. Run a Lambda function-age audit and decommission anything not invoked in 90 days. Common saving: $5K to $20K annualised.

Inspector versus alternatives

Scoped Inspector is the cheapest AWS-native option and is almost always the right starting point unless multi-cloud posture management is the primary requirement.

Findings noise reduction

The biggest hidden Inspector cost is not the service bill - it is the security team time spent triaging findings. Reduce noise:

• Suppress findings on EOL OS images that have a known remediation date.
• Route findings to ticketing only at severity High and above by default.
• Use findingFilters to suppress findings on packages your runtime never invokes.
• Integrate with AWS Security Hub for de-duplication across services.

Negotiation hooks

Inspector v2 is a relatively new line on most enterprise bills and sales teams are actively pushing adoption. Levers worth asking for:

• First-year ramp credit for the EC2 scan line, sometimes 50 to 100 percent for the first 60 to 90 days.
• Bundle discount with GuardDuty and Macie inside an EDP renewal.
• Lambda scan free-tier expansion for customers above a Lambda spend threshold.
• Findings dashboard delivery as a managed deliverable inside the deal, sometimes worth more than the dollar discount.

Implementation checklist

1. Audit current Inspector scope per account; tag exclusions.
2. Limit to production and selected staging.
3. Switch ephemeral fleets to agentless scanning.
4. Apply ECR lifecycle policy for image pruning.
5. Decommission dormant Lambda functions.
6. Negotiate ramp credit in the next EDP cycle.
7. Contact us for an Inspector scoping engagement benchmarked against 500+ engagements.

For the broader view see our AWS security cost strategy pillar, the GuardDuty pricing optimization piece for the next-most-correlated security service, and the Macie data discovery costs piece for the data-classification flank.

Container scanning at scale

ECR image scanning is per-image and per-rescan. Mature container shops with thousands of images per repository face two cost drivers:

• Image proliferation. Build pipelines that push every commit produce thousands of images per month. Use tag-based lifecycle policies to keep only release tags and the last N development tags.
• CVE-driven rescans. Every published CVE triggers rescans of all matching images. Combined with thousands of historical images, this compounds quickly. The fix is ECR lifecycle and image hygiene.

Practical pattern: keep release-* tags indefinitely, keep last 30 days of dev-* tags, delete the rest. Reduces rescan volume by 70 to 90 percent.

Lambda scanning trade-offs

Lambda standard scanning is $0.30 per function per month; code scanning is $0.45. Code scanning analyses your application code, not just the runtime. The decision rule:

• Code scanning makes sense for security-critical functions handling regulated data.
• Standard scanning is sufficient for general-purpose functions whose runtime CVEs are the primary risk.
• Dormant functions should be decommissioned, not scanned.

Finding workflow integration

Inspector findings flow into Security Hub by default. The integration choices that matter for cost-conscious teams:

1. Filter findings by severity at the EventBridge layer rather than at the SIEM layer; reduces downstream ingestion cost.
2. De-duplicate findings against compensating controls (e.g., WAF blocking exploitable paths) before alerting.
3. Track mean-time-to-remediate as a Macie / Inspector KPI; the team that closes findings fastest is the team you can grant the broadest Inspector scope to.

Inspector and asset inventory

Inspector requires SSM Agent on EC2 instances for the deepest scan. The dependency:

• Confirm SSM Agent installation across the fleet before enabling Inspector.
• Inventory instances without SSM Agent; they show up as un-scanned in findings but still bill if Inspector is enabled.
• For container hosts, configure Inspector to scan the container images, not the host instance, where possible.

Multi-account administration

Inspector v2 supports an organisation-level delegated administrator account, which is the right structural choice for any multi-account estate. With the administrator delegation in place, scoping and exclusion policies are managed centrally and inherited by member accounts. The operational benefit is consistency; the cost benefit is that scope changes propagate immediately rather than being applied account by account.

Operational pattern that holds across mature shops:

• Designate a dedicated security tooling account as Inspector delegated administrator.
• Define exclusion tag standards centrally; publish them in an internal cloud governance handbook.
• Run weekly reports showing newly-enrolled accounts, their resource counts, and projected Inspector cost.
• Block direct Inspector enablement in member accounts via SCP; require central enablement only.

Compliance versus cost trade-off

Some compliance regimes (PCI, FedRAMP, HIPAA) require continuous vulnerability scanning on specific resource sets. Inspector v2 satisfies that requirement, but only if the scoped resources are actually covered. The cost trade-off:

• Compliance-mandated scope cannot be reduced. Document it explicitly.
• Optional scope - dev accounts, non-regulated workloads, ephemeral fleets - can be scoped down without compliance impact.
• Re-scan frequency settings affect both compliance posture and bill; the default settings are usually appropriate for compliance and not unduly expensive.