New Savings Proposals: approve, test and roll back cost changesLearn more Sign in|Talk to a cloud engineer
Product tourGet a demo

Apply savings changes with approvals and rollback

Bundle recommendations into one proposal. An approver decides per resource, a dry run checks the change against the real account, and CloudLens applies only what was approved. Every step is recorded, and there is a way back.

Get a demoSee recommendations
What you're watching
  1. 1
    Add five recommendations to the cart

    From stopping analytics-sandbox-01 to deleting edge-nat-staging, each with its monthly saving.

  2. 2
    Create PR-1042 for Priya

    The proposal is named Q3 compute cleanup. Priya is emailed and the status is Pending Approval.

  3. 3
    Priya decides per resource

    Three are approved, orders-db-replica-2 goes On Hold and edge-nat-staging is rejected with a reason, so the proposal becomes Partially Approved.

  4. 4
    Dry run, then apply

    The dry run checks pass, the status moves to Ready to Apply, and Apply via Tool changes the four approved resources.

Who does thisFinOps lead as requester, platform lead as approverWhat you getFour approved changes applied, the held replica untouched, and before and after specs saved.
Applied without approval0resources: only approved ones can apply
Lifecycle11statuses, from Pending Approval to Rolled Back
Export formats3CloudFormation, Terraform and Python
RollbackPreviewof what can and can’t revert

Describes how the product works. Figures in scenes are fictional sample data.

A saving only counts if nothing breaks

Rightsizing stalls when nobody owns the risk. A proposal gives every change an owner, a test and a way back.

Delivery

Nobody wants to press delete

What usually happens: Everyone agrees the replica is unused, but nobody wants to be the one who removes it in production, so it runs for another year.

How CloudLens resolves it: PR-1042 bundles five changes worth $3,542/mo. The platform lead approves each one and the change runs in a planned window.

Resolved
Risk

Changes that fail halfway

What usually happens: The script runs, the third resource hits a missing permission, and the environment is left half-changed on a Friday night.

How CloudLens resolves it: The dry run assumes the target role and simulates the IAM actions first, and permissions are checked again right before apply.

Resolved
Audit

Nobody can say who changed what

What usually happens: Three months later nobody can say who deleted a volume or what size an instance used to be.

How CloudLens resolves it: Before and after specs, the approver and whoever applied it are stored on the proposal, and the rollback preview shows what can be reversed.

Resolved

How PR-1042 went from a cart to applied

Five changes, two people, one change window, and a record security could read afterwards.

ARAna RuizFinOps lead, Lumora Retail

Lumora Retail is a fictional company. The people, names and numbers are sample data.

    1
    Tue 11:00

    Ana adds five recommendations to a cart

    Stop analytics-sandbox-01, resize checkout-worker-03, delete an unattached volume and an idle NAT gateway in staging, and remove an unused orders-db replica.
    2
    Tue 11:05Pending Approval

    Creates PR-1042 for Priya

    The proposal totals $3,542/mo. Priya gets an email and the proposal shows Pending Approval.
    3
    Wed 09:30Partially Approved

    Priya decides per resource

    Three are approved. orders-db-replica-2 goes On Hold until month-end reporting finishes, and edge-nat-staging is rejected because staging still routes through it. The proposal becomes Partially Approved.
    4
    Wed 09:45Dry Run Passed

    Runs the dry run

    It assumes the role in prod-core, confirms each approved resource is in the expected state and simulates the IAM actions. Nothing is flagged.
    5
    Sat 02:10

    Applied in the change window

    Only the four approved resources are changed. The held replica is untouched, and before and after specs are saved for each change.
    6
    Mon 09:00

    Security asks who removed the NAT gateway

    Execution History shows the requester, the approver, the dry run result, who applied it and when. The question is answered with a link.
Have recommendations nobody will apply?

Walk through a proposal with our team

Get a demo

One proposal, seven recorded steps

Click any step. Every transition records who did it and when.

Pending Approval

Pick recommendations from the list and add them to a proposal cart. Name it, choose an approver and confirm.

Step 1 / 7

Approve, test, then apply what was approved

Approve each resource, not the whole list

Approvers see each resource, its change and its saving. Approve what is safe, put a replica On Hold until month end, reject a change with a reason. The requester is emailed the outcome and the proposal becomes Partially Approved.
  • Approve, hold or reject each resource
  • Reason required to reject
  • Partially Approved
  • Email notifications
What you're watching
  1. 1
    Approve three, hold one

    Priya approves analytics-sandbox-01, checkout-worker-03 and batch-legacy-vol-2, and puts orders-db-replica-2 On Hold.

  2. 2
    Reject with a reason

    edge-nat-staging is rejected because it is still used by the staging deploy pipeline. The reason is required.

  3. 3
    The requester hears back

    Ana is emailed: 3 approved, 1 on hold, 1 rejected. The proposal shows Partially Approved.

Who does thisPlatform lead as approverWhat you getSafe changes move ahead, and the others wait or stop with a reason on record.

Check the change before anything runs

The Dry Run Test assumes the target role in the real account, runs describe calls against each approved resource and simulates the IAM actions the change needs. Missing permissions and moved resources show up before anything is touched.
  • Assumes target role
  • Describe calls
  • IAM permission simulation
  • Nothing is modified
What you're watching
  1. 1
    Run the dry run on PR-1042

    CloudLens assumes the target role in prod-core, the real account the change will run in.

  2. 2
    Watch the checks pass

    Describe calls find 4 of 4 approved resources. ec2:StopInstances, ec2:DeleteVolume and the other needed actions come back allowed.

  3. 3
    See what is skipped

    rds:DeleteDBInstance is skipped because the replica is On Hold. Before specs are captured and nothing is changed.

Who does thisPlatform lead, before the change windowWhat you getProof the change has the permissions it needs, before any resource is touched.

See what can be reversed before rolling back

Execution History shows every create, decision, dry run and apply. When you need to revert, the rollback preview separates Resources Ready to Rollback from those that Cannot Rollback, such as a deleted volume, before you confirm.
  • Execution History
  • Rollback preview
  • Rolled Back status
  • Before and after specs
What you're watching
  1. 1
    Open Execution History

    Ana created the proposal. Priya's decision, dry run and apply follow, each with a time and resource count.

  2. 2
    Preview the rollback

    checkout-worker-03 can return to m6i.2xlarge and analytics-sandbox-01 can start again. The deleted volume and NAT gateway cannot come back.

  3. 3
    Roll back two resources

    The proposal shows Rolled Back, and a new history row records who did it and when.

Who does thisPlatform lead, with security reading the history laterWhat you getA partial undo where one is possible, and a plain list of what cannot be reversed.

Guardrails enforced by the workflow

None of these depend on someone remembering a checklist.

Only approved resources can be applied

Held and rejected resources are excluded when the change runs, not just hidden in the UI.

Dry run assumes the target role and previews every change

The dry run uses the real target account and its role, so a missing permission or a moved resource shows up before the change.

IAM permission simulation before apply

IAM actions are simulated during the dry run and permissions are checked again right before apply.

Before/after resource specs stored for audit

Every applied resource keeps its before and after spec, who applied it and when.

One-click rollback with a preview of what can revert

Before anything is rolled back, you see which resources can revert and which can’t.

Or export as CloudFormation, Terraform or Python

If your changes go through a pipeline, export the approved changes as CloudFormation, Terraform or Python instead.

Always clear where a proposal stands

Pending ApprovalOn HoldApprovedPartially ApprovedRejectedReady to ApplyAppliedPartially AppliedApplication FailedRolled BackResolved Manually

A proposal marked Resolved Manually is locked, so no one can apply it twice.

Execution history

Created, decided, dry-run, applied and rolled back, each step with who and when.

Email at every hand-off

Approvers hear when a proposal is created. Requesters hear when it is decided and when it is applied.

Starts from recommendations

Proposals are built from priced recommendations, so the saving on the proposal is the saving that was approved.

See proposals on your accountTrack the work in Jira

Where proposals fit

01 · Find

Recommendations

Priced per resource, owned and tracked.

02 · Fix fast

Quick Wins

Safe fixes with the command ready.

You are here

Savings Proposals

Approve, dry-run, apply, roll back.

04 · Automate

Scheduler

Stop non-prod when nobody's using it.

Savings Proposals questions

Only if you use Apply via Tool, and only through a role you choose to grant in the target account. The rest of CloudLens, including exporting proposals as code, works read-only.

It assumes the target role, runs describe calls to confirm each approved resource exists in the expected state, and simulates the IAM actions the change needs. It never modifies anything.

Yes. Approvers decide per resource. Held and rejected resources stay out of the apply, and the proposal shows as Partially Approved.

No. A deleted volume can’t come back. The rollback preview shows which resources can revert and which can’t before you confirm.

Yes. Export the approved changes as CloudFormation, Terraform or Python and run them through your own review and deployment.

Apply the savings you already agreed on

Connect a read-only AWS role or Azure service principal. We'll walk you through your bill, your security graph and the first things worth fixing.