Amazon Inspector
Does ZopNight manage Amazon Inspector?
Amazon Inspector bills per resource scanned per month: each EC2 instance under assessment, each container image scanned in ECR, and each Lambda function evaluated adds to the meter. ZopNight discovers the scanning configuration on its 6-hour cycle and trends Inspector cost from Cost Explorer or CUR 2.0 as the estate grows.
Rules that fire on Amazon Inspector
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and cost tracking only. |
Amazon Inspector continuously scans EC2 instances, container images, and Lambda functions for vulnerabilities, billed per resource scanned per month. Cost tracks the size of the scanned estate, growing automatically as resources are added.
A meter that grows with the estate
Inspector prices by what it watches: an average monthly charge per EC2 instance under continuous assessment, a charge per container image scanned into ECR (with rescans metered as well), and a charge per Lambda function under code and vulnerability scanning. Nobody provisions Inspector capacity. Enabling it at the organization level subscribes the whole resource population, present and future. Every autoscaling burst, every new microservice, and every image pushed to ECR nudges the meter, which makes Inspector one of the few line items that grows without anyone deploying anything named Inspector.
Trend analysis over scanning spend
A dedicated provider picks up the Inspector configuration on the 6-hour cycle, and scanning cost flows in from Cost Explorer or CUR 2.0 with trend analysis across time. The question ZopNight helps answer is proportionality: whether scanning spend is tracking estate growth (expected), or diverging from it (worth a look, often an image-heavy CI pipeline generating rescans, or a fleet of short-lived instances churning through assessment hours). As with other security tooling, there is nothing to stop or schedule; the discipline is knowing what is enabled where and what each slice costs.
Scanning configurations that overspend
Three patterns worth catching: ECR registries where CI pushes dozens of throwaway images per day, each scanned on push while most never deploy; Inspector enabled across all member accounts including sandboxes whose vulnerability findings nobody triages; and rescan-on-update behaviour amplifying cost in repositories with high image churn. In each case the fix is scoping: exclusion rules, retention policies upstream in ECR, or disabling a resource type in accounts where findings have no audience.
Inspecting Inspector itself
The Inspector console’s account management and usage views show which resource types are enabled per account and the estimated monthly cost per type. Comparing that against which teams actually consume the findings tells you whether the coverage is protection or just spend.