Findings worth acting on

Rules run over the data each scan collects, and a rule fires only where that data exists. Today they cover:

• AWS compute and storage: idle EC2 instances, unattached EBS volumes, old EBS snapshots, storage still billed on stopped instances, and RDS instances in a few r5 and t3 classes whose CPU stays low.
• AWS security: S3 buckets with public access risk, and security groups open to the internet on risky ports such as SSH and RDP.
• Tags: AWS and GCP resources missing the tags or labels your workspace policy requires.
• Commitments: Savings Plans used below 70%, plus AWS’s own Savings Plan, Reserved Instance and rightsizing recommendations.
• GCP: idle VMs and disks, large Cloud SQL tiers, public Cloud Storage buckets and committed use suggestions.
• AI and more: Bedrock and Vertex AI spend spikes, idle provisioned inference capacity, under-used SaaS seats, and over-requested pods in active Kubernetes clusters.

Each finding carries a severity (high, medium, low or info), a category, the resource and region, the evidence behind it, a recommendation, and a monthly savings estimate with its method, such as a price table, a Cost Explorer or BigQuery figure, or AWS’s own number. When a saving can’t be priced, the figure is left empty and marked unpriced.

Confidence runs from 0 to 100. For an idle EC2 instance it weighs the lookback window, how low CPU stayed and how many hourly CloudWatch datapoints arrived, so a thin series scores lower. For an idle GCP VM it reflects agreement: 95 when Google’s Recommender and Cloud Monitoring agree, 50 when they conflict, with both views in the evidence.

Several rules hold back findings that would look right and aren’t:

• An EC2 instance counts as idle only while it’s running, with p95 CPU under 5% and combined network traffic under 500 KB over the lookback, seven days by default.
• ECS container hosts aren’t flagged as idle, because low CPU is normal for them. An instance in an Auto Scaling group gets a note to lower the group’s desired capacity instead.
• AWS resources reported as terminated or being deleted are removed before rules run. GCP isn’t filtered this way, because a stopped GCE instance still bills for its disks.
• Two accounts can use the same resource name. Findings are kept per account, so neither is lost.

Every finding has a status: open, pending approval, reviewed, approved, resolved or dismissed. You can search and filter by severity, category, status, confidence and date, select findings in bulk to mark them reviewed or request remediation, and export a selection as JSON.

Pending approval is set when you request remediation. If that approval expires, is denied or cancelled, or its execution fails or rolls back, the finding shows as open again with the reason. A successful remediation marks it resolved.

Each finding says whether it can be remediated. Four AWS finding types map to changes GetFinOps can run: stopping an idle instance, deleting an unattached volume or old snapshot, adding missing tags and turning on S3 Block Public Access. They run only in AWS accounts connected with the cross-account role, in the resource’s own region. Choosing Remediate requests approval, and the change then passes guardrails, a post-check and, for reversible actions, automatic rollback.

The remediation plan explains the rest. Buying or changing a commitment and removing a SaaS seat are decisions for a person. GCP fixes, open security groups, database resizing and Kubernetes changes aren’t automated yet.

You can start a scan at any time from the dashboard or through the MCP server. Where scheduled scans are turned on, each workspace also gets a daily scan at an hour and quarter-hour you pick in Settings → Schedule, in your local time. Self-hosted installs launch with scheduled scans off.

The account overview shows when the last scan finished, so an empty list isn’t mistaken for a clean estate. You can also list findings through the MCP server.

• It doesn’t change anything in GCP. GCP findings are for review only.
• It doesn’t resize RDS instances, and it flags oversized ones only in a few r5 and t3 classes.
• It doesn’t flag under-used Reserved Instances or GCP committed use discounts yet.
• It doesn’t judge whether an ECS container host is idle.
• Its price-table estimates use approximate AWS on-demand rates, so they don’t reflect your discounts.
• It doesn’t return AWS purchase or rightsizing recommendations for member accounts in an AWS Organization; AWS gives those to the payer account.