Right, so you’ve got your EC2 instances running and your containers neatly tucked into ECR. You’ve done the hard part. But how do you know they’re secure? You can’t just eyeball it for CVE-2023-4863. This is where AWS Inspector v2 comes in, like a relentlessly thorough, slightly obsessive friend who reads every cybersecurity bulletin and isn’t afraid to tell you your baby is ugly.

Think of it as a continuous automated security scanner that pokes and prods your EC2 instances and ECR repositories, comparing what it finds against a gigantic, constantly updated database of known vulnerabilities (CVEs). It’s not guessing; it’s checking software bills of materials (SBOMs) and package versions against a known-bad list. And the best part? It’s mostly hands-off.

How It Actually Works (The Magic Isn’t Magic)

Inspector doesn’t require you to install an agent on your EC2 instances anymore. Thank goodness. Instead, it leverages the exact same systems you’re (hopefully) already using for monitoring: the SSM Agent. If your instance can be managed by AWS Systems Manager, it can be scanned by Inspector. It’s a brilliant move by AWS because it removes a huge barrier to entry. For ECR, it’s even simpler: it scans your container images on push, and then continuously rescans them as new vulnerabilities are published, which is the real killer feature.

You enable it at the account level. Once it’s on, it just… starts working. It discovers your resources and begins its assessment. The first scan might take a few hours, but after that, it’s continuous.

Here’s how you enable it using the CLI. It’s one of those things you setup once and mostly forget:

# Enable Inspector for your account and all resources
aws inspector2 enable \
  --resource-types EC2 ECR \
  --status ENABLED

But wait! The default is to scan everything. That’s great for compliance, maybe, but terrible for your wallet if you have a sprawling dev environment. Be smart about it.

Taming the Beast: Resource Management

You absolutely do not need to scan every single test instance running a three-year-old Node.js version that gets torn down daily. That’s just burning money and drowning you in noise. Inspector lets you create resource groups to scope your assessments precisely.

First, create a resource group for your production resources:

# Create a resource group for production EC2 instances
aws resource-groups create-group \
  --name Production-EC2 \
  --resource-query '{"Type":"TAG_FILTERS_1_0", "Query":"{\"ResourceTypeFilters\":[\"AWS::EC2::Instance\"], \"TagFilters\":[{\"Key\":\"Environment\", \"Values\":[\"production\"]}]}"}'

Then, tell Inspector to only scan that group:

# Update your assessment configuration to target the production group
aws inspector2 update-configuration \
  --resource-types EC2 ECR \
  --ec2-configuration '{"scanMode":"EC2_SSM_AGENT_BASED", "targets":[{"accountId":"YOUR_ACCOUNT_ID", "ec2ResourceGroupArn":"arn:aws:resource-groups:us-east-1:YOUR_ACCOUNT_ID:group/Production-EC2"}]}'

This is the single most important best practice: scan what matters. Ignore the rest. Otherwise, you’ll suffer from alert fatigue and miss the actual critical vulns hiding in production.

Reading the Tea Leaves (Findings and Severity)

The findings dashboard in the AWS Console is where you’ll spend your time. Inspector rates everything from CRITICAL to INFORMATIONAL. My advice? Immediately create standards in Security Hub to send CRITICAL and HIGH findings to a Slack channel or PagerDuty. For MEDIUM and below, a daily digest is probably fine.

The findings are deliciously detailed. It doesn’t just say “this version of OpenSSL is bad.” It says “CVE-2022-3602: A buffer overrun can be triggered in X.509 certificate verification…”. It gives you the CVSS score, a link to the NVD, and often even tells you which package manager to use to update the package (yum update vs apt-get). This is the “why” that saves you hours of Googling.

The Rough Edges and Pitfalls

It’s not all rainbows. Inspector v2 is still young and has its quirks.

  1. The Cost: It’s not free. You pay per EC2 instance scan and per ECR image scan. It’s usually pennies, but it can add up if you’re careless and scan everything. Manage your resources.
  2. The Lag: While it’s “continuous,” there can be a delay of a few hours between a new CVE being published and it showing up in your findings. It’s still miles faster than any human-driven process.
  3. Deep Container Scavenging: It’s fantastic for OS-level packages in your containers, but it’s not a silver bullet. If you have a vulnerability in your own application code (a custom Python script), Inspector won’t find it. For that, you need a SAST tool like CodeGuru or a third-party scanner.
  4. The “No Agent” Lie (Kinda): Remember, it uses the SSM Agent. If you’ve foolishly decided not to install the SSM agent on an instance “for security,” congratulations, you’ve also made it invisible to Inspector. This is a self-own. Install the agent.

The bottom line? Enable it. Configure it properly to focus on your crown jewels. Integrate its findings into your alerting system. It is, without a doubt, one of the highest-value, lowest-effort security controls you can turn on in AWS today. It’s the closest thing you get to having a security engineer manually patrolling your infrastructure 24/7, and it doesn’t ask for vacation days.