Part of #63. Design: docs/features/parallel-region-scans.md §1.
Problem
A full scan fans out ~153 region jobs (9 regional services × ~17 enabled regions), and in most accounts the large majority find nothing.
SCAN_PRUNE_REGIONS_WITH_TAGGING (app/config/scan.php:24) already exists to cut this via one tag:GetResources call per region, but is off by default for a well-reasoned documented cause: the Tagging API reports only tagged-or-previously-tagged resources, so in an inconsistently tagged account a service can hold resources and still be absent from the index. Skipping it would mark that region clean without looking at it.
Change
Revisit whether a safer signal exists that could make pruning default-on.
Dependencies
Only worth doing if PERF-6 and PERF-7 fall short. Cutting the job count matters much less once the jobs run in parallel.
Open questions
- Is there a signal safer than the Tagging API — and is default-on ever acceptable for a security scanner?
Priority: P3
Part of #63. Design:
docs/features/parallel-region-scans.md§1.Problem
A full scan fans out ~153 region jobs (9 regional services × ~17 enabled regions), and in most accounts the large majority find nothing.
SCAN_PRUNE_REGIONS_WITH_TAGGING(app/config/scan.php:24) already exists to cut this via onetag:GetResourcescall per region, but is off by default for a well-reasoned documented cause: the Tagging API reports only tagged-or-previously-tagged resources, so in an inconsistently tagged account a service can hold resources and still be absent from the index. Skipping it would mark that region clean without looking at it.Change
Revisit whether a safer signal exists that could make pruning default-on.
Dependencies
Only worth doing if PERF-6 and PERF-7 fall short. Cutting the job count matters much less once the jobs run in parallel.
Open questions
Priority: P3