What is Service Screener?

Service Screener is an open-source Python tool maintained by AWS Samples. It uses your existing AWS CLI credentials to make read-only describe/list/get API calls across your account, evaluates the results against a library of best-practice checks (security, cost, reliability, performance, operations), and generates an HTML report plus raw data you can post-process.

Think of it as a point-in-time audit rather than continuous monitoring. It answers one question fast: "If I look at my account right now, where am I drifting from best practices?"

Where it fits vs. the managed stack:

Service Screener isn't a replacement for GuardDuty-style threat detection. I found it useful as a first step: get a baseline, fix the obvious gaps, then decide whether the managed stack is worth it.

Getting started

Prerequisites: AWS CLI v2 with a read-capable profile (the SecurityAudit or ViewOnlyAccess AWS-managed policy is a good fit), Python 3.9+. Read-only is enough — Service Screener never modifies resources.

git clone https://github.com/aws-samples/service-screener-v2.git
cd service-screener-v2
pip install -r requirements.txt

python3 main.py

python3 main.py --regions ap-northeast-1,us-east-1 \
                --services iam,s3,cloudtrail,kms \
                --profile my-audit-profile

Reading the output

After a run, Service Screener drops an output folder containing an index.html report (open in a browser — findings grouped by service, each with severity and a "why it matters" note) plus raw JSON/CSV per service you can parse for your own tooling. That raw data is what makes triage-at-scale possible.

Each finding carries a category mapping roughly to the AWS Well-Architected pillars:

A typical high-value finding: "IAM user has an access key not rotated in 90+ days" (Security), or "CloudTrail trail does not have S3 bucket logging enabled" (Reliability/Security).

How to triage the report (the part most people skip)

The tool gives you findings. It does not tell you which ones are real risks in your context — that judgment is yours. A practical triage loop:

1. Sort by severity, then by blast radius. A wildcard IAM policy on a production deploy role outranks a missing tag.
2. Separate "true gaps" from "accepted risk." Some findings are intentional. Document why, don't just silence them.
3. Cross-check before acting. Service Screener flags patterns, not intent. A snapshot flagged "orphaned" might still back a live AMI. Verify before you delete.
4. Track state over time. Re-run after fixes and diff against the previous scan to prove findings actually closed.

That last point — treating the scan as a baseline you drive down over time — is what turns a one-off report into a security program.

The workflow that ties it together

Reading the HTML report is only step one. What worked for me was building a repeatable loop around the raw output, so a scan turns into a plan and the plan into trackable progress. This is roughly the workflow I've settled on:

The scope-and-verify step is the one that mattered most — it's what turns a flat list of findings into a prioritized, verifiable work plan. The real engagement below shows the loop in practice.

Context

• Environment: a single AWS account hosting multiple projects (production + staging), primarily in one region, with global IAM.
• Starting point: no managed security stack, no periodic audit, security posture unknown — the classic "we've been shipping fast, we're not sure what's exposed" situation.
• Goal: get a full picture of the security gaps for free, prioritize them, and drive them down with proof — without disrupting running production systems.

The team didn't have budget approval for the managed stack, and standing that up would have taken weeks before producing a single actionable finding. Service Screener produced a full, prioritized report on day one, for free — so we started fixing instead of procuring.

Case anonymized — client identifiers and specific resource names are hidden.

The findings: 860+ issues, grouped into 8 workstreams

Running the workflow above on this account, the scope-and-verify step was where most of the work went. The raw scan surfaced thousands of findings across all severities (as the report overview above shows). Instead of trying to fix everything at once, we focused on the 860+ High-severity items and grouped them into eight remediation workstreams. The lower-severity findings were logged for later, not acted on first.

The breakdown, organized by remediation scope:

Two buckets stood out, both typical of a team that has been shipping quickly:

• Backup protection (576 findings) — the largest by volume. Root volumes without backup plans, RDS without deletion protection. High count, but mostly mechanical to fix once a backup policy is defined.
• Wildcard IAM policies (145 findings) — the largest by risk. Roles and groups carrying iam:*, ec2:*, s3:* and AWS-managed FullAccess policies. This is where least-privilege work concentrated.

What I learned: the tool flags patterns, not intent

The thing that stuck with me from this engagement wasn't a vulnerability — it was a false positive I could easily have acted on, which would have caused an outage.

• IAM roles flagged "too permissive": Service Screener flagged dozens of EC2 instance roles carrying AmazonSSMManagedInstanceCore and similar as "Managed Policy Full Access." Some did need narrowing — but many were correctly attached to running services. Stripping them would have broken SSM access to production instances.
• Wildcard on deploy pipelines: the code-pipeline-role-* roles carried broad wildcards (ec2:*, s3:*, cloudformation:*...). Real risk — but these drive active CI/CD. Narrowing them required mapping every action the pipeline actually uses before touching the policy, or deployments would silently fail.

Proving the fixes landed: baseline diff

A scan is a snapshot. To prove remediation actually worked, I ran a second scan months later and diffed it against the baseline. Findings that disappeared were marked "PASS after fix" and tied back to the specific date-stamped comparison — for example, 11 of 19 stale IAM key/user findings and 54 of 145 wildcard findings were confirmed closed by the re-scan, not just assumed fixed.

Having that before/after comparison is what made the difference between running a scan once and being able to show the fixes actually held.

Results

What Service Screener is good at — and where it stops

Great at: zero-cost, fast, broad best-practice coverage; read-only and safe on production; raw output you can post-process for triage at scale; a perfect first step before deciding on a paid security stack.

Not a fit for: continuous/real-time threat detection (that's GuardDuty); runtime vulnerability scanning (that's Inspector); findings correlation and long-term case management (that's Security Hub + Detective); anything that needs intent — it flags patterns, you supply judgment.

Lessons learned

1. Free tooling gets you a baseline fast — worth doing while the paid stack waits for budget.
2. Raw output > the HTML report — parsing findings into workstreams turns 860+ rows into a plan.
3. The scanner proposes, the human decides — verifying against live evidence prevented an outage.
4. A scan is just a snapshot — re-scanning and comparing is what shows the fixes held.
5. Know where the free tool stops — it's the first step, not the whole security posture.