Cloud Cost Management Tools: What Access Do They Actually Want?

Cloud cost management tools all onboard the same way. You paste an account id into the vendor's console, launch the CloudFormation stack it hands back, and ninety seconds later there is a dashboard with your bill on it. Nobody reads the template. We have watched engineers who would argue for an hour about one security group approve a cross-account role by accident.

The tools are mostly good. The templates are not, for a dull reason: the fastest way to make a cost platform work in every customer's account is to attach ReadOnlyAccess and stop thinking. That policy does more than its name suggests.

So, the position. A cost tool should get the billing export and the describe calls, and nothing that can read an object or change a resource. If the template asks for more, ask for a smaller one.

Why do cloud cost management tools need more than the bill?

Because the bill on its own cannot tell you anything worth paying for. To say an instance is oversized the tool needs CloudWatch metrics; to say a volume is unattached, ec2:DescribeVolumes; to draw your account hierarchy, organizations:ListAccounts. Fair enough. The trouble is that listing the describe calls for every service AWS sells, and keeping that current, is real and unglamorous work. One managed policy is a line and never needs updating.

Does read-only mean the tool cannot read your data?

No, and AWS says so in a box on its own documentation page. The job function policies reference carries an Important note under ReadOnlyAccess: "This user will also have access to read data in storage services like Amazon S3 buckets and Amazon DynamoDB tables."

Hold that against what sits in a fintech's accounts. KYC documents. Settlement files. The bucket holding the 180 days of logs CERT-In asks for. None of it is cost data; all of it is inside the reach of a policy somebody attached to make a dashboard light up.

The answer is in the next sentence of the same page: "If you need a similar policy that does not grant access to read data in storage services, see View-only user job function." With ViewOnlyAccess, AWS says, "the user cannot read resource content or metadata that goes beyond the quota and list information for resources". For something whose job is counting instances, that is the right shape.

What is the external ID doing, and why is it not a secret?

AWS documents this with an example that is, word for word, the thing you are buying. From the page on access for third parties: "let's say that you decide to hire a third-party company called Example Corp to monitor your AWS account and help optimize costs."

The mechanism matters. "The primary function of the external ID is to address and prevent the confused deputy problem." Without that condition your role trusts the vendor's entire AWS account, so anybody who can persuade their platform to assume an arbitrary role ARN reaches into yours. Nobody has to be malicious; somebody only has to type your role ARN into the vendor's onboarding form.

It is not a password, which is the part most often misread: "AWS does not treat the external ID as a secret." What matters is its origin. AWS recommends "using one external ID per AWS account", and that "this ID should be a random string generated by the third party". If the value in your trust policy is the vendor's product name, the condition is decoration.

AWS even wrote the review question on the vendors' behalf: "if you can assume the role without the correct external ID, don't store the customer's role ARN in your system." Ask yours whether your ID is unique to you, and whether they test that.

Where does the billing export land, and who owns that bucket?

This is the part a security review misses, because it does not look like access. It is a copy, and a copy is permanent. When you create a standard data export, the console asks whether to deliver it to the S3 bucket of "This account" or "Another account". Choose the second and your billing data lands in the vendor's account daily. Cancelling later does not take it back.

Billing data is not neutral in a regulated account. The CUR 2.0 options include a tick box for resource ids, and AWS notes that "including resource IDs creates individual line items for each of your resources". Resource ids are names: the bucket called settlement-files-prod, the cluster, the KMS key alias. A daily feed of those is a legible map of your architecture, held by a third party. Which number belongs in that report at all is a separate argument.

Deliver to your own bucket, in your own account and Region, and let the tool read one prefix. One warning: aim an export at a bucket you already own and AWS says "you need to acknowledge that Data Exports will overwrite your existing S3 bucket policy". Not the one holding your log copy, then.

Which permissions should a cost tool never get?

Anything that changes a resource. The feature that earns the upgrade in every demo is one-click rightsizing, and the role behind it is not a reader: ec2:ModifyInstanceAttribute, ec2:StopInstances, ec2:DeleteVolume, rds:ModifyDBInstance. Grant it and a vendor's scheduler can stop a production database at 2am on a recommendation computed from a fortnight of CPU, which is the wrong basis for that call, as our post on which recommendations to ignore argues at length.

AWS shows the scoped version. Its own policies give CostOptimizationHubReadOnlyAccess five list and get actions, while CostOptimizationHubAdminAccess adds UpdateEnrollmentStatus, organizations:EnableAWSServiceAccess and permission to create a service-linked role. A tool that reads your recommendations needs the first; plenty of templates ask for the second because it switches the Hub on for you.

Our rule: the tool recommends, your pipeline applies. A change that arrives as a pull request has a reviewer, a diff and a timestamp, which is the cheapest audit evidence you will ever generate. What that pipeline looks like is a post of its own.

What does the RBI expect of a vendor holding a role?

Two short paragraphs, and both land on the role rather than on the tool. The Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026 say at paragraph 113 that "access to information assets shall be allowed only where a valid business need exists", and at paragraph 114 that the NBFC "shall closely supervise personnel with elevated system access entitlements with all their system activities logged and periodically reviewed".

A vendor's cross-account role is an access entitlement, and its activity is already in CloudTrail. The missing half is the review: the role was created for a trial in March, the trial became a contract, and nobody has read the policy since.

One detail decides whether the log is worth reading. CloudTrail records the role session name the caller chose, so if the vendor assumes your role as the same generic string every time, you learn that the vendor did something and never which of their engineers. Ask them to pass an identifying session name. The longer version of that argument is in how a provider should get into your account.

What can you run on Monday?

Twenty minutes, and you need nobody's cooperation. List every role that another AWS account may assume, with the external ID condition beside it.

aws iam list-roles --output json --query \
  'Roles[?AssumeRolePolicyDocument.Statement[?Principal.AWS]].{
     role: RoleName,
     trustedBy: AssumeRolePolicyDocument.Statement[?Principal.AWS].Principal.AWS,
     externalId: AssumeRolePolicyDocument.Statement[?Principal.AWS].Condition.StringEquals."sts:ExternalId"}'

Service roles and OIDC federation drop out, so what prints is every outside party with a door into the account. Any row whose externalId comes back as [] trusts a whole AWS account with no condition at all. Fix those this week, cost tool or not.

Then read what each one can do:

aws iam list-attached-role-policies --role-name <role> \
  --query 'AttachedPolicies[].PolicyName' --output text

If ReadOnlyAccess comes back, you have a real answer to "can our cost vendor read the KYC bucket", and it is yes. For the wider question AWS points at IAM Access Analyzer, to learn "whether principals in accounts outside of your zone of trust (trusted organization or account) have access to assume your roles".

When is a cloud cost management tool worth the access?

More often than this post makes it sound. Past a few dozen accounts, with chargeback to teams who argue about their own numbers, nobody is going to build the allocation engine in-house and keep it running for three years. The platforms are good at that, and we have recommended them.

We told readers of our post on accounts or tags not to buy a cost tool on Monday, and the order has not changed: fix the account layout and the tag coverage first, because a platform inherits whatever allocation you already have. After that it is a decision rather than a way to avoid a boring job.

Some vendors deserve credit here. A few ship a read-only template with no write actions, a per-customer external ID, and an export that lands in your bucket rather than theirs. That is a shorter security review and a fair reason to prefer them on a tie.

The short version

Open the vendor's CloudFormation template before you launch it and find the policy. If it says ReadOnlyAccess, hand back ViewOnlyAccess plus the handful of ce: and cost-optimization-hub: actions they actually call, and ask them to confirm the list in writing.

Check the external ID is a value their system generated for you alone, and that your trust policy requires it. Point the export at your own bucket in your own Region and let them read one prefix.

Refuse every write action, and route rightsizing through the pipeline that already has reviewers. Then put the role on the access review list with a date against it, because paragraph 114 asks for that and the role everyone forgets is reliably the one with the widest policy.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.