Amazon Inspector: Continuous Vulnerability Scanning for AWS Workloads

Security teams need to know which workloads contain vulnerable packages before attackers exploit them. Amazon Inspector is an automated vulnerability management service that discovers eligible AWS workloads, scans them continuously, and creates findings for software vulnerabilities and unintended network exposure.

This is Part 60 of the AWS Cloud Practitioner Study Notes. The simplest mental model is:

Amazon Inspector
→ Is this workload vulnerable or unintentionally exposed?

Amazon GuardDuty
→ Is there suspicious activity or a possible compromise?

AWS Shield
→ Is a DDoS attack overwhelming the perimeter?

Inspector finds weaknesses. It does not automatically patch every workload or act as a real-time malware detector.

What Amazon Inspector scans

The core Inspector scan types cover three AWS resource groups:

Resource	What Inspector looks for
Amazon EC2	Operating-system and programming-language package vulnerabilities, CVEs, and network reachability issues
Amazon ECR	Vulnerabilities in packages inside container images
AWS Lambda	Vulnerabilities in application dependencies and layers; optional code scanning provides an additional code-focused scan

Amazon Inspector automatically discovers eligible resources after the relevant scan type is activated. It continues monitoring them throughout their eligible lifetime and rescans when changes or newly published vulnerability intelligence may affect the result.

EC2 vulnerability scanning

An EC2 instance can contain operating-system packages, libraries, runtimes, and application dependencies. When a vulnerability such as a critical OpenSSL CVE is published, the security team needs to identify affected instances quickly.

EC2 instance
      ↓
Package and network inventory
      ↓
Amazon Inspector
      ↓ compares with
Vulnerability intelligence and security advisories
      ↓
Finding with severity and remediation information

For agent-based EC2 scanning, Inspector uses AWS Systems Manager to collect software inventory. The instance must be a Systems Manager managed instance with the SSM Agent running and the required permissions. Inspector also supports agentless scanning for eligible EBS-backed instances in hybrid scan mode, so the exact coverage depends on the selected scan mode and instance configuration.

Inspector can identify package vulnerabilities and network reachability issues. For example, an instance with an outdated web library is concerning; an outdated library that is also reachable from the internet may deserve a higher remediation priority.

Network reachability findings are not the same as a live intrusion alert. They describe whether network paths or exposure make a resource reachable in a way that increases risk.

ECR container image scanning

Container images can include vulnerable operating-system packages or application dependencies even when the application source code looks correct:

Dockerfile
    ↓ build
Container image
    ↓ push
Amazon ECR
    ↓ enhanced scanning
Amazon Inspector
    ↓
Package vulnerability findings

Inspector’s enhanced ECR scanning can scan operating-system and programming-language packages in private ECR repositories. Configure the repository and scan scope according to the required behaviour, such as scanning on push or continuously monitoring eligible images.

A useful CI/CD gate is:

Build image
      ↓
Push to ECR
      ↓
Scan image
      ↓
Critical finding?
  ├── Yes → stop or review deployment
  └── No  → continue to ECS, EKS, or another runtime

Scanning is evidence for a deployment decision, not a guarantee that the image is safe. Teams still need to define severity thresholds, exceptions, patch timelines, and how to rebuild images when a base image becomes vulnerable.

Lambda dependency scanning

Lambda functions can include vulnerable libraries in their uploaded package or layers. Inspector Lambda standard scanning identifies package vulnerabilities in application dependencies:

Lambda function or layer
      ↓
Uploaded dependencies
      ↓
Amazon Inspector
      ↓
Package vulnerability finding

Inspector rescans functions when they are deployed or updated and when relevant vulnerability information is added. The standard scan focuses on dependencies supplied with the function or inherited from a layer; it does not scan the AWS SDK dependency that the Lambda runtime provides by default. Eligibility also depends on supported runtimes and the function’s activity.

Lambda code scanning is an additional capability for code vulnerabilities. For Cloud Practitioner questions, remember the core distinction: Inspector can identify vulnerable Lambda packages and dependencies; it does not automatically rewrite or patch the function.

Continuous scanning

Inspector differs from a one-time manual assessment because it responds to changes in the workload and its vulnerability knowledge:

Day 1: instance has no known finding
        ↓
Day 5: new CVE is published
        ↓
Inspector rescans affected resources
        ↓
Finding appears with remediation guidance

Inspector can rescan when a package is installed, a patch changes the software inventory, a new function or image is deployed, or a newly added CVE applies to the resource. The timing and cadence vary by resource type and scan method, so “continuous” means managed ongoing assessment rather than every resource being scanned on every second.

When an issue is appropriately remediated, Inspector can detect the change and close the finding. Findings contain the affected resource, vulnerability details, severity or risk information, and recommended remediation guidance.

Findings and severity

An Inspector finding is a report about a vulnerability or network issue affecting a resource. It may include:

• Affected resource and package
• CVE or vendor advisory details
• Severity and vulnerability intelligence
• Exploitability or network reachability context
• Recommended remediation
• Finding status and timestamps

Inspector can provide a risk score that adds environment context to vulnerability severity. For example, a vulnerability with network exploitability may receive different prioritisation when the affected instance has no open network path to the relevant source.

Do not treat a CVSS score as a complete business risk decision. Consider whether the asset is production, the data sensitivity, exposure, exploit availability, compensating controls, and the time required to apply a safe fix.

Inspector integrations

Systems Manager

Systems Manager helps Inspector collect EC2 inventory, and Patch Manager can help remediate missing patches:

Inspector finds vulnerable package
          ↓
Systems Manager Patch Manager
          ↓
Install approved update
          ↓
Inspector rescans and closes finding

Inspector reports the weakness; Patch Manager or another deployment process applies the change. Keeping these responsibilities separate makes the workflow easier to audit.

Security Hub

Security Hub can aggregate Inspector findings with findings from GuardDuty, Macie, IAM Access Analyzer, and other security services. This provides a central view, but aggregation does not itself remediate the vulnerability.

EventBridge

Inspector publishes findings and other events to EventBridge. You can route a high-severity finding to SNS, Lambda, a ticketing workflow, or an automated review process:

Inspector finding
      ↓
EventBridge rule
      ├── SNS notification
      ├── Security Hub aggregation
      ├── Ticket or incident workflow
      └── Lambda automation

Be careful with automatic remediation. A patch or image rebuild should be tested and approved according to the workload’s deployment and change-management process.

AWS Organizations

Inspector supports delegated administration across AWS Organizations. A security account can manage activation and findings for member accounts, which is useful when an organisation has many AWS accounts. The organisation still needs to define account coverage, Regions, exclusions, and remediation ownership.

Inspector versus related services

Service	Main question	Example
Amazon Inspector	Is a workload vulnerable or exposed?	EC2 has a package with a critical CVE
Amazon GuardDuty	Is there suspicious activity or a compromise?	Instance communicates with a known malicious host
AWS Shield	Is a DDoS attack targeting the perimeter?	TCP SYN flood overwhelms an internet-facing resource
AWS WAF	Should this HTTP or HTTPS request be blocked?	SQL injection or rate-based web rule
AWS Config	Does the resource meet a configuration rule?	S3 bucket is publicly accessible
Systems Manager	How do we operate or patch the resource?	Install an approved security update

The services can work together. Inspector may find an outdated package, Systems Manager may patch it, Security Hub may aggregate the finding, and EventBridge may notify the security team.

What Inspector does not do

Inspector is not:

• A replacement for patch management
• A DDoS mitigation service
• A general-purpose firewall
• A real-time network intrusion detector
• A guarantee that an application contains no security defects
• An automatic approval system for production deployments

It scans supported resources and reports actionable vulnerabilities and exposure. Your team decides how to prioritise, patch, rebuild, isolate, accept, or otherwise remediate the finding.

Common exam questions

Which service scans EC2 packages for CVEs?

Amazon Inspector.

Which service scans container images in Amazon ECR?

Amazon Inspector with ECR scanning.

Which service scans Lambda dependencies for vulnerabilities?

Amazon Inspector Lambda scanning.

Which service detects suspicious activity or malware communication?

Amazon GuardDuty.

Which service protects against DDoS attacks?

AWS Shield.

Which service checks whether a resource configuration is compliant?

AWS Config.

Does Inspector patch the vulnerability automatically?

No. Inspector creates findings and recommendations; Systems Manager, a CI/CD pipeline, or another operational process performs remediation.

How can a critical Inspector finding trigger an alert?

Use Inspector’s EventBridge integration to route matching findings to SNS, Lambda, Security Hub, or an incident workflow.

Final memory map

Amazon Inspector
├── EC2 → packages, CVEs, network reachability
├── ECR → container-image packages
├── Lambda → function and layer dependencies
├── Findings → severity, context, remediation guidance
├── Systems Manager → inventory and patch remediation
├── Security Hub → central findings view
└── EventBridge → notifications and automation

The one-sentence takeaway is: Amazon Inspector continuously scans eligible EC2, ECR, and Lambda workloads for software vulnerabilities and unintended exposure, then reports findings that other services and teams can remediate.

Sources

• What is Amazon Inspector?
• Automated scan types
• Scanning EC2 instances
• Scanning ECR container images
• Scanning Lambda functions
• Understanding Inspector findings
• Inspector EventBridge integration