A read-only FinOps tool for engineering and finance teams cutting AWS and Google Cloud costs safely

A cost tool needs to see every account you run, which makes its access one of the widest grants you’ll ever give a vendor. A read-only FinOps tool keeps that grant safe: it reads your bill, inventory and metrics on AWS and Google Cloud, works out what to cut, and leaves every change to your engineers. This post is for the engineering and finance teams choosing one. It covers why a cloud cost analyzer should only read, what read-only access looks like on each cloud, what to check in a vendor’s policy, and how non-destructive cloud optimization still gets savings shipped.

Why a cloud cost analyzer should only read

Finding waste takes cost data, an inventory and utilization metrics. None of that needs permission to change anything. Write access only matters if the tool acts on what it finds, and that’s where the risk lives.

• Blast radius. A cost tool is usually connected to every account, including production. With write access, a bug in its automation, a compromised vendor, or a recommendation applied at the wrong moment can stop or delete something that matters. With read access, the worst case is someone reading your inventory.
• Security review. A role that can only describe resources and read cost is quick to review. A role that can stop instances or buy commitments deserves the same scrutiny as your deploy pipeline, and should get it.
• Change management. Production changes go through your process: a pull request, a change ticket, a maintenance window. A tool that acts on its own schedule bypasses all of it.
• Ownership. The team that runs a service knows what a cost tool can’t see: that an idle-looking instance is a disaster recovery standby, or that a database is mid-migration. They should make the call.

What read-only access looks like on AWS

On AWS, a third-party tool should reach your account through an IAM role you create, never through an IAM user’s access keys. The role’s trust policy names the vendor’s AWS account and requires an External ID; the vendor calls STS to assume the role and gets temporary credentials (AWS docs).

The External ID solves the confused deputy problem. A vendor serving many customers could be tricked into using its access on the wrong account: another customer hands it your role’s ARN, which isn’t a secret, and the vendor assumes your role on their behalf. Requiring a unique External ID that the vendor generates for each customer, and sends on every AssumeRole call, makes that impossible (AWS docs). AWS doesn’t treat the External ID as a secret. What matters is that the vendor generates it, not you.

The permissions should be a short list of describe, get and list actions. Here is the whole permission policy of the role Omni FinOps asks for, from its CloudFormation template:

- Sid: Cost
  Action: [ce:GetCostAndUsage, ce:GetDimensionValues]
- Sid: Inventory
  Action: [ec2:DescribeInstances, ec2:DescribeVolumes, ec2:DescribeSnapshots,
           ec2:DescribeAddresses, ec2:DescribeNatGateways, ec2:DescribeImages,
           ec2:DescribeLaunchTemplateVersions, ec2:DescribeRegions,
           rds:DescribeDBInstances]
- Sid: Metrics
  Action: [cloudwatch:GetMetricData, cloudwatch:ListMetrics]

Read-only isn’t always as narrow as it sounds. AWS’s own ReadOnlyAccess managed policy can read data in storage services like S3 buckets and DynamoDB tables; ViewOnlyAccess is the managed policy that lists resources without reading their content (AWS docs). A cost tool needs neither. It needs cost, inventory and metrics, and nothing that reads your data.

What read-only access looks like on Google Cloud

On Google Cloud, the cleanest pattern is a Google sign-in with read-only OAuth scopes. There’s no service account to create and no key to paste, and Google’s consent screen lists each scope in plain words before you allow it. The scopes tell you what a tool can do (Google):

A cost tool should ask only for scopes from the top of that table. It also sees no more than the Google account that signs in can see, so sign in with the account that manages billing, not a project owner’s. To revoke access, remove the app from your Google Account’s third-party connections (Google Account Help).

What to check in any vendor’s IAM policy

Before you deploy a vendor’s role, read the policy. A safe cloud cost analyzer passes every check below.

• Only read actions. Look for Describe*, Get* and List*, plus the cost APIs. Anything with Create, Delete, Modify, Put, Start, Stop, Terminate or Purchase in its name is a write.
• No reads of your data. Some get actions read content, not metadata: s3:GetObject, secretsmanager:GetSecretValue, ssm:GetParameter, dynamodb:GetItem. A cost tool has no reason to hold them.
• No wildcards on services that change things. ec2:* or "Action": "*" grants every write the service has, today and in the future.
• No iam:PassRole. It lets the holder hand a more powerful role to a service.
• A trust policy with an External ID. It should name one vendor account and require sts:ExternalId.
• A one-step way out. Deleting one stack or one app connection should end access.

You can check all of this from the CLI without changing anything:

# Who can assume the role, for how long, and when it was last used
aws iam get-role --role-name OmniFinOpsReaders \
  --query 'Role.[AssumeRolePolicyDocument, MaxSessionDuration, RoleLastUsed]'

# Every policy on the role
aws iam list-role-policies --role-name OmniFinOpsReaders
aws iam list-attached-role-policies --role-name OmniFinOpsReaders

# Prove that writes and data reads are denied
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:role/omni-finops/OmniFinOpsReaders \
  --action-names ec2:StopInstances ec2:TerminateInstances s3:GetObject \
  --query 'EvaluationResults[].[EvalActionName, EvalDecision]' \
  --output table

Every action in the last command should come back as implicitDeny.

The trade-off: tools that change things for you

Some tools are built to act. Commitment management services buy and exchange Savings Plans or Reserved Instances for you, which takes purchase permissions like savingsplans:CreateSavingsPlan. Schedulers and automated rightsizing need ec2:StopInstances or ec2:ModifyInstanceAttribute. AWS has a native version too: a budget action can apply an IAM policy or a service control policy, or stop specific EC2 or RDS instances, automatically or after someone approves it (AWS docs).

Automation can be worth it for a narrow, well-understood job, like a large commitment portfolio or dev environments that should sleep at night. If you grant it, grant it on purpose: a separate role for that one job, only the actions it needs, scoped to tagged resources where the service allows it, with an approval step where one exists. Write access should be a deliberate grant for one task, never the price of seeing your bill.

How non-destructive cloud optimization still ships savings

Non-destructive cloud optimization splits the work. The tool does the analysis: it reads the data, finds the waste and works out the fix. Your team does the change, with its own credentials and through its own process. That only works if the handoff is complete, so each lead should carry:

• The resource, the evidence and the monthly saving.
• The exact command to run, and whether it restarts anything or can be rolled back.
• An owner, a status and a note on why it was done, delayed or skipped.

A lead’s command is ready to paste. These two change your account, so they run with your credentials, not the tool’s:

# Release an Elastic IP attached to nothing
aws ec2 release-address --allocation-id eipalloc-0c19b4e2

# Move a gp2 volume to gp3, online, with no restart
aws ec2 modify-volume --volume-id vol-0b9e4c6a12 --volume-type gp3

Order matters as much as the commands. Start with deletions and releases that restart nothing, like unused public IPs and unattached volumes. Then rightsize and schedule in maintenance windows, then re-platform, and buy commitments last, sized to the footprint you have after the cleanup.

Omni FinOps is built this way. On AWS, one CloudFormation stack creates the OmniFinOpsReaders role shown above, trusting only your company’s External ID; Omni FinOps assumes it for an hour at a time and can’t read S3 files, database rows or secrets. On Google Cloud, you sign in with Google and allow read-only scopes for Cloud Billing, Compute Engine, Cloud Monitoring and your projects. Every lead carries the AWS CLI or gcloud command, and the Planner sorts leads into four waves (clean up, rightsize and schedule, re-platform, commit) with owners and due dates, then exports the runbook. To revoke access, delete the stack or remove the Google connection. For how read-only tools compare with the rest of the market, see the best cloud cost optimization tools of 2026.