Docs navigation

Remediation Effort per Resource Type

Every finding has an effort value (low / medium / high) that feeds the “Top quick wins” ranking in the PDF report — sorted by a cost/effort score, not by monthly cost alone — so the first items the reader sees are the cheap-to-fix ones, not simply the most expensive.

Criteria

  • low — pure deletion or detachment of a resource referenced by nothing, zero dependents, reversible or near-zero risk.
  • medium — requires verification before acting (the scan’s classification might be wrong), or it’s a no-downtime config change with some side effects.
  • high — requires downtime, data migration, or coordination with another team/service.

Full table

Kind Effort Why
ebs-volume low Volume already detached, zero dependents
elastic-ip low IP already unassociated
rds-instance high Database: data loss risk, requires snapshot and coordination
load-balancer medium Verify no client still points to the DNS name
ec2-instance medium Verify before terminating; reversible via AMI
ebs-snapshot low Old or redundant snapshot
nat-gateway medium If misclassified, impacts an entire subnet’s network path
ebs-gp2-upgrade low In-place volume type change, zero downtime
ebs-idle low Same reasoning as ebs-volume
ec2-underutilized medium Rightsizing requires a stop/start, brief downtime
rds-underutilized high RDS rightsizing usually requires a maintenance window
log-group low No production impact
eni-orphaned low Network interface already detached
s3-no-lifecycle low Adding a lifecycle rule is config-only
lambda-underutilized low Memory change is config-only, zero downtime
efs-unused medium Verify intermittent mounts before deleting
dynamodb-overprovisioned low Online throughput change, zero downtime
elasticache-idle medium Caches are often silently shared by other apps
redshift-idle-cluster high Data warehouse — verify dependent BI tools
opensearch-idle-domain medium Verify dependent apps; reversible via snapshot
msk-idle-cluster high Messaging infra often has hidden consumers
fsx-idle-filesystem medium Verify mounts before deleting
documentdb-idle-instance high Database, same reasoning as rds-instance
neptune-idle-instance high Graph database, same reasoning
mq-idle-broker medium Verify queue-dependent apps
workspaces-idle low Low per-user impact, easily re-provisioned
vpn-connection-idle medium Network connectivity, needs network team input
transit-gateway-idle-attachment medium Network routing, requires verification
kinesis-provisioned-idle-stream medium Verify producers and consumers
sqs-dlq-abandoned low Zero-cost queue, pure cleanup
lambda-loggroup-orphaned low No production impact
aurora-serverless-overprovisioned medium Min ACU change is online but affects scaling floor
sagemaker-notebook-idle low Isolated dev notebook, single-user
sagemaker-endpoint-idle high Serving endpoint — if misclassified, breaks production ML
sagemaker-training-orphaned low Model with no active endpoint, zero risk
environment-ghost medium Multiple resources together, but already inactive by definition
eks-node-overprovisioned high Affects scheduling capacity of the entire cluster
eks-orphan-pvc low No pod references it by construction
ami-unused low Unused AMI, zero dependents
ecr-image-untagged low No deployment references untagged digests
s3-multipart-upload-abandoned low Pure cleanup, zero risk
rds-manual-snapshot-old low Old snapshot, same reasoning as ebs-snapshot
secretsmanager-unused medium A secret may have indirect dependents hard to verify
codepipeline-pipeline-stale low No production impact, recreatable from source

How it’s used

The PDF report orders “Top recommendations” by a combined economic impact / remediation effort score. This means a $40/month EBS volume (effort: low) appears before a $200/month Redshift cluster (effort: high), because the former is a one-click fix while the latter requires coordination.

In JSON format, every finding carries the effort field so you can filter or sort as you prefer:

cloudrift analyze --format json | jq '.findings[] | select(.effort=="low")'