The category claim
From recommendation to verified action
GetFinOps runs approved fixes in your AWS account, checks the result, rolls reversible changes back automatically if the check fails, and re-checks every saving before it counts.
It does not make changes in GCP or Azure.
The problem
Recommendations pile up and nobody acts on them. Engineers don’t trust a dashboard that can’t prove a change is safe or reversible, so waste keeps compounding while the "potential savings" number grows meaningless.
How it works
Find
A rule flags waste and proposes one of the supported actions, with an estimated saving where it can be priced.
Approve
An owner or admin approves in the app or in Slack. Only a reversible action type you have allowed to run on its own skips this step.
Run, check, count
The change runs in your AWS account, the post-check compares the result with the intent, and the saving is re-checked seven days later before it counts.
5 kinds
of change that findings propose today
7 days
until a booked saving is looked up again, before it counts as realized
Verified
only when the post-check had something to compare
Approval
required for every deletion, because deletions cannot be undone
Capabilities
Run the fix in AWS, check the result, and roll reversible changes back automatically.
Real changes, not tickets
Stop idle EC2 instances, delete unattached EBS volumes and stale snapshots, add missing tags and turn on S3 Block Public Access — in your AWS account, through the cross-account role you deploy.
A post-check on the result
After a change runs, the state AWS reports back is compared with what the action intended. When there is nothing to compare, the run is marked unverified rather than verified.
Automatic rollback for reversible actions
If the post-check fails, a stop, a tag change or an S3 setting is reverted automatically in the same account. Deletions cannot be undone, so they never run without a person approving them.
You decide what needs a person
Every action type starts at “approve each” for every account. An admin can let a reversible action type run on its own, and Settings → Autonomy suggests it once the type has a clean record. Nothing runs on its own until the workspace turns on automatic execution, and guardrails apply at every level.
In depth
What it can change in your AWS account
Findings propose five kinds of change today. Each one runs through the AWS API with the permissions you grant, and any action outside the supported list is refused before a call is made.
- Stop an idle EC2 instance. Reversible: the instance is started again if the check fails.
- Delete an unattached EBS volume or a stale EBS snapshot. Not reversible, so a person always approves it.
- Add missing tags to EC2 instances, volumes, snapshots, security groups, RDS instances and S3 buckets. Reversible: the added keys are removed again.
- Turn on all four S3 Block Public Access settings for a bucket. Reversible: rolling back turns the four settings off again.
- Stopping an RDS instance is supported as well, though no finding proposes it yet.
How a change is checked
After an action runs, GetFinOps compares the state AWS returned for that call with what the action intended: an instance stopping or stopped, the tag keys present, all four Block Public Access settings on, the deletion confirmed.
The check reads what the AWS call reported; it does not look the resource up again. When there is nothing to compare, the run is marked unverified rather than verified, so an action type’s track record is built only from checks that actually passed.
If the check fails, a reversible action is rolled back automatically in the same account. An irreversible one is marked failed and flagged for manual follow-up.
When a person has to approve
Every action type starts at “approve each” for every account. Owners and admins approve in the app or in Slack, where the approver’s linked account and role are checked before anything runs. Wherever it was approved, a change in an account labelled production, or with no environment label, is blocked by default unless the account’s policy allows production or an owner or admin uses a single-use override.
An owner or admin can let a reversible action type run on its own for one account, up to the level set for the workspace. Settings → Autonomy offers Graduate once it has a clean record, by default ten verified successes in 30 days, and the level can also be set directly. It drops back to “approve each” automatically after a failed check, a reverted saving or a used override. A change of that type runs without a person only when a scan marks it safe and the workspace is on a paid plan or active trial, has turned on automatic execution and has saved a guardrail configuration.
Deletions never run on their own. Stopping an EC2 instance and deleting a snapshot also wait for a person today, because two checks they depend on — a recent CPU spike, and an AMI that still uses the snapshot — are not measured yet, and an unmeasured check sends the action to approval instead of passing it.
Guardrails that always apply
Guardrails run before any change is made, at every autonomy level.
- Terminating instances and deleting databases or buckets are blocked permanently; no setting unblocks them.
- Accounts labelled production, and accounts with no environment label, are blocked by default. An admin can grant a single-use override that lifts that block for one run.
- A workspace kill switch, cool-downs and a daily execution limit can be turned on in settings.
Permissions you grant
Remediation needs write permissions that are off by default. Turning on EnableRemediation in the cross-account role template adds a short list: stopping and starting EC2 and RDS instances, deleting EBS volumes and snapshots, adding and removing tags, and managing S3 bucket tagging and Block Public Access.
These permissions apply across the account rather than to named resources, so which resources are touched is decided by approvals, guardrails and your autonomy settings.
How savings are counted
Stopping an instance or deleting a volume or snapshot books an estimated saving at AWS list price, marked as pending. Seven days later the resource is looked up again in its own account: if it is still stopped or gone, the saving counts as realized; if it was started again or the change was rolled back, it counts as zero. Stopped instances are re-checked every 30 days after that.
These are list-price estimates for changes that held, not figures reconciled against your AWS invoice.
What it does not do
- It does not make changes in GCP or Azure.
- It doesn’t run a change without approval unless the workspace has turned on automatic execution and set that action type to run on its own.
- It does not rightsize instances or databases.
- It does not stop resources on a schedule.
- When it rolls back, it does not restore tag values it overwrote or the S3 settings a bucket had before.
FAQ
Questions
Will it change anything without approval?
Only if you allow it. Every action type starts at “approve each”. An owner or admin can let a reversible action type run on its own for a specific account, and Settings → Autonomy suggests it once the type has a clean record. It then runs without approval only after a scan marks it safe, and only once the workspace has turned on automatic execution and saved a guardrail configuration. Deletions always need a person, and guardrails apply either way.
What if a change breaks something?
If the post-check fails, a reversible action is rolled back automatically in the same account. Deletions have no undo, which is why they always wait for approval.
Does it make changes in GCP?
No. GetFinOps collects and analyses GCP cost and usage, but it only makes changes in AWS today.
What access does it need?
Read-only access for analysis. Remediation is opt-in: turning on EnableRemediation in the cross-account role template adds the short list of write permissions described on this page.
Try free — no credit card
Create a workspace and connect an AWS or GCP account, or book a demo first.