Every finding in your Parsivex report has a severity level and an estimated monthly savings figure. This article explains what those numbers mean and how they are calculated.
Severity levels
Parsivex assigns one of three severity levels to each finding:
| Severity | What it means | How it appears |
|---|---|---|
| High | Significant waste or clear idle resources with meaningful cost impact — for example, an idle EC2 instance, an orphaned volume costing more than $20/month, or NAT Gateway spend over $200/month | Red badge and left border on finding cards |
| Medium | Real waste with moderate impact — smaller orphaned volumes, idle load balancers, or cost-based findings below high-tier thresholds | Primary-colored badge |
| Low | Minor but still worth reviewing — for example, an unused Elastic IP (~$3.60/month when unattached) | Muted badge |
Severity is assigned automatically based on estimated monthly cost and resource type. It helps you prioritize which findings to fix first. Sort your report by savings to tackle the highest-impact items regardless of severity badge.
Cost anomaly alerts (paid plans) use separate warning and critical severity levels based on spend spikes. Finding severity only applies to waste detected during scans.
How severity is assigned
Parsivex uses named cost thresholds — not arbitrary labels. Examples:
- Idle EC2 — always high severity when flagged
- Orphaned EBS volumes — high if monthly cost exceeds $20, otherwise medium
- NAT Gateway overuse — high if NAT spend exceeds $200/month, otherwise medium
- Reserved Instance opportunities — high if potential savings exceed $200/month, otherwise medium
- Unused Elastic IP — low severity
The exact thresholds may be adjusted over time. The principle is consistent: higher estimated waste maps to higher severity.
How monthly savings estimates are calculated
Parsivex computes estimated monthly savings and current monthly cost using standard AWS list prices rather than your negotiated rates or live price lookups. This keeps scans fast and consistent.
Pricing approach by resource type
| Resource type | How cost is estimated |
|---|---|
| EC2 | Lookup table of common instance types (t3, m5, c5, r5 families) with fixed USD/month rates |
| EBS / snapshots | Storage size × per-GB-month rate for the volume type |
| RDS | Instance class lookup table |
| Lambda | Memory allocation × per-GB-second rate based on invocation metrics |
| Elastic IPs | Fixed monthly charge for unattached addresses |
| Load balancers | Hourly rate × hours per month (ALB/NLB vs Classic LB) |
| S3 | Standard storage rate per GB-month |
| DynamoDB | Provisioned RCU/WCU hourly rates |
| NAT Gateway / RI opportunities | Actual spend from Cost Explorer where available |
When Cost Explorer data is missing (partial scan), cost-based findings are skipped entirely rather than guessed.
"Approximately" wording
Some figures are based on sampled data from large accounts rather than checking every single resource. When that happens, findings use explicit approximate language:
- Titles and descriptions prefix with "Approximately"
- The finding card shows an approximate indicator
- Example: S3 incomplete multipart upload findings sampled from a capped number of uploads per bucket
Always treat approximate findings as directional — verify the numbers in the AWS console before acting.
Savings are estimates, not guarantees
Parsivex savings figures are estimates intended to help you prioritize. They are not invoices, commitments, or audited financial projections.
Important caveats:
| Factor | Impact on estimates |
|---|---|
| Static pricing | Real AWS prices vary by region, reservation coverage, Savings Plans, and enterprise discounts |
| Utilization assumptions | Idle detection uses CloudWatch averages; bursty workloads may look idle over a short window |
| Right-sizing suggestions | Downsizing recommendations assume current metrics represent typical load |
| Shared resources | NAT Gateway and load balancer costs may be split across many workloads |
| Your architecture | A flagged resource may be intentional (staging environment, DR standby) |
Before deleting or resizing any resource, validate in your own environment. Parsivex surfaces opportunities; you make the final call.
Total monthly waste on your report
The report total estimated monthly waste is the sum of estimated savings across all open findings in that scan. It represents potential savings if you addressed every finding — not your current AWS bill and not guaranteed realized savings.
On paid plans with recurring scans, realized savings tracks findings that actually disappeared after you fixed them. That is separate from scan estimates. See Realized savings and Finding lifecycle.
Using severity and savings together
A practical workflow:
- Sort by savings — Fix the biggest dollar items first
- Use severity as a tiebreaker — Among similar savings amounts, start with high-severity findings
- Dismiss intentional resources — So they do not inflate future totals
- Re-scan after fixes — Confirm waste dropped and, on paid plans, see realized savings credited
Related articles
- How scans work — What data feeds savings calculations
- Partial scan warnings — When cost data is missing
- Finding lifecycle — Dismiss, snooze, and resolve findings
- Realized savings — Verified savings after you fix waste
- Your first scan — Walkthrough from scan to report