.png)
AWS
Microsoft Azure
Google Cloud
Key takeaways
1
Approve access for the functions you will use: cost analysis, commitment purchasing, and infrastructure automation require different permissions.
2
Inspect the actual cloud identities, policies, assignments, and billing-data reach. A dashboard setting alone does not prove the effective scope.
3
Make purchasing authority a separate decision, then agree on action records, ongoing access reviews, and an exit procedure.
Your FinOps team wants to test savings recommendations. Security asks what the platform can read and purchase. Both need an answer before connecting a production cloud account.
Ask for the identity and effective permissions, not just a “read-only” label. Approve an assessment first if it meets your purpose; review purchase permissions and controls before enabling execution.
The Short Answer
Grant access for the function you are evaluating, at a scope your team has checked. Billing analysis may need cost exports and selected metadata; buying commitments requires additional authority; changing running resources is another action entirely.Ask for the identity and effective permissions, not just a “read-only” label. Approve an assessment first if it meets your purpose; review purchase permissions and controls before enabling execution.
What Access Does the Platform Actually Need?
An optimization platform’s permissions should follow its job. The FinOps Foundation’s tooling guidance calls for least-privilege access and warns that cost data can include sensitive account names, resource names, tags, and business context.| Function | Typical access to review | Decision it enables |
|---|---|---|
| Cost assessment | Billing exports or APIs, existing commitments, and relevant resource or usage metadata | Can the platform produce a credible recommendation? |
| Recommendation review | Assessment data plus access for your team to inspect results in the vendor platform | Who can see costs and approve a proposed action? |
| Commitment execution | Specific provider permissions to purchase or manage supported commitments | What financial obligation can the integration create? |
| Infrastructure automation | Permissions to change resources or configurations | Which workloads could the platform affect? |
These are functional categories, not a standard permission package. A commitment specialist may need purchase authority without the ability to stop a VM. Ask the vendor to map each requested write permission to an enabled feature.
Keep setup authority separate from continuing vendor access. An administrator may need elevated rights to create roles; inspect what the vendor’s identity receives afterward.
Read-only describes actions, not data sensitivity. Decide who may see detailed spending and usage patterns in the vendor dashboard too.
Keep setup authority separate from continuing vendor access. An administrator may need elevated rights to create roles; inspect what the vendor’s identity receives afterward.
Read-only describes actions, not data sensitivity. Decide who may see detailed spending and usage patterns in the vendor dashboard too.
How Access Scope Differs Across AWS, Azure, and Google Cloud
“Connect our cloud account” can produce different identities and data paths. Inspect the current setup output for the selected product.| Cloud | Inspect the integration identity | Check the effective reach | Check before enabling purchases |
|---|---|---|---|
| AWS | Cross-account role, trust policy, and attached policies | Connected accounts and the billing or metadata actions allowed | Exact purchase actions, trusted principal, and any conditions |
| Azure | Service principal, any guest identity, custom role, and assignments | Management-group or other assigned scope, plus relevant billing access | Commitment permissions and the identity that receives them |
| Google Cloud | Service account, custom role, project bindings, and BigQuery dataset grants | Organization or project inheritance and all data readable from the billing dataset | Commitment write actions and projects where they apply |
For AWS, third-party access guidance recommends an external ID when a provider accesses multiple customers. Inspect the trusted principal, that condition, and the permissions policy.
AWS identifies savingsplans:CreateSavingsPlan as a purchase action; describing plans need not permit buying them.
For Azure, distinguish installer prerequisites from vendor permissions. Microsoft’s savings plan guidance says savings plans have their own permissions and do not inherit subscription permissions after purchase. Review assignments and billing access together.
For Google Cloud, inspect the BigQuery billing dataset as well as selected projects. Google’s export documentation says standard or detailed exports can contain costs for every project under the same billing account.
A project-selection screen does not narrow dataset access. For resource-based commitments, check whether the vendor requests compute.commitments.create.
For Azure, distinguish installer prerequisites from vendor permissions. Microsoft’s savings plan guidance says savings plans have their own permissions and do not inherit subscription permissions after purchase. Review assignments and billing access together.
For Google Cloud, inspect the BigQuery billing dataset as well as selected projects. Google’s export documentation says standard or detailed exports can contain costs for every project under the same billing account.
A project-selection screen does not narrow dataset access. For resource-based commitments, check whether the vendor requests compute.commitments.create.
What Must Pass Before You Grant Access?
Set the non-negotiable requirements before the walkthrough. A strong savings projection cannot compensate for access your security team cannot approve. The Usage.ai software evaluation scorecard covers broader vendor selection; this is the narrower access decision.| Approval requirement | Evidence to request | Who should decide | Result |
|---|---|---|---|
| Justified scope | Current policy or role definition mapped to enabled features and accounts | Security and cloud owner | Pass / Open / Fail |
| Known data path | Data-flow description, billing sources, metadata, destination, and dashboard users | Security, privacy, and FinOps | Pass / Open / Fail |
| Controlled purchases | Allowed actions, affected accounts, approval mode, limits, and stop procedure | FinOps and accountable cloud owner | Pass / Open / Fail |
| Traceable results | Example recommendation, authorization, provider action, commitment, and billing record | FinOps and Finance | Pass / Open / Fail |
| Removable access | List of identities and grants, export needs, revocation steps, and remaining obligations | Security and Procurement | Pass / Open / Fail |
“Open” means evidence is missing or a configuration needs changing. Do not treat it as a pass. A requirement may be irrelevant to a genuinely read-only trial for example, purchase limits when no purchase permission is granted but record that boundary explicitly.
Ask whether the platform receives billing data, queries your dataset, or reads resource metadata too. Confirm retention and dashboard access. A SOC report cannot establish what a role in your account allows.
For commitment purchases, ask who owns the provider purchase, what happens to pending actions when automation pauses, and what obligations survive removal.
Then follow one recommendation from source data to action. Have the vendor show the forecast, who can approve it, the proposed commitment, the provider-side purchase record, and how the eventual charge and savings appear in reporting.
AWS documents CloudTrail records for Savings Plans API calls; Microsoft documents a way to identify an Azure reservation purchaser. Ask which records apply to the particular product being demonstrated.
Have your team demonstrate how to pause future actions and revoke each identified grant.
Recheck access whenever you add an account, enable automation, change a product, or alter a policy, not only at contract renewal.
Name an owner for provider commitments and reporting. Revoking vendor access does not cancel a Savings Plan, reservation, or committed use discount already purchased. Resolve previously approved or queued actions before removal.
For a complete departure, the cloud cost optimization platform exit checklist covers exports, active commitments, final billing, and access removal.
If you authorize purchases, we need the relevant cloud permissions. In CoPilot, we recommend commitments for your approval; with Autopilot, we purchase within the controls you set. We cannot start or stop production workloads.
With our Flex Insured Commitments program, teams can access 30–50% savings on average through eligible one- or three-year cloud commitments, with none of the commitment risk of paying more than equivalent On-Demand usage for covered commitments.
If an eligible Flex Commitment does cost more, we offer cashback protection to help cover the difference. However, commitments you purchased independently are not automatically covered.
Our fee is an agreed percentage of realized savings on commitments we optimize. If we don’t save, you don’t pay a savings-based fee.
Ask whether the platform receives billing data, queries your dataset, or reads resource metadata too. Confirm retention and dashboard access. A SOC report cannot establish what a role in your account allows.
For commitment purchases, ask who owns the provider purchase, what happens to pending actions when automation pauses, and what obligations survive removal.
How to Test a Vendor’s Access Claims
Walk through setup using a representative account. Before running a script, inspect its identity, policy, inherited access, and data destination. Compare read-only and purchase-enabled configurations; record what changed.Then follow one recommendation from source data to action. Have the vendor show the forecast, who can approve it, the proposed commitment, the provider-side purchase record, and how the eventual charge and savings appear in reporting.
AWS documents CloudTrail records for Savings Plans API calls; Microsoft documents a way to identify an Azure reservation purchaser. Ask which records apply to the particular product being demonstrated.
Have your team demonstrate how to pause future actions and revoke each identified grant.
Who Controls Access After Onboarding?
Give each integration a named internal owner. That person should know which products are enabled, which accounts and datasets are connected, who can authorize purchases, and when the permissions were last reviewed.Recheck access whenever you add an account, enable automation, change a product, or alter a policy, not only at contract renewal.
Name an owner for provider commitments and reporting. Revoking vendor access does not cancel a Savings Plan, reservation, or committed use discount already purchased. Resolve previously approved or queued actions before removal.
For a complete departure, the cloud cost optimization platform exit checklist covers exports, active commitments, final billing, and access removal.
How We Separate Assessment From Purchasing at Usage.ai
You can assess potential savings with our read-only Savings Test before granting us purchase permission. We analyze billing data and selected metadata, including existing commitments.If you authorize purchases, we need the relevant cloud permissions. In CoPilot, we recommend commitments for your approval; with Autopilot, we purchase within the controls you set. We cannot start or stop production workloads.
With our Flex Insured Commitments program, teams can access 30–50% savings on average through eligible one- or three-year cloud commitments, with none of the commitment risk of paying more than equivalent On-Demand usage for covered commitments.
If an eligible Flex Commitment does cost more, we offer cashback protection to help cover the difference. However, commitments you purchased independently are not automatically covered.
Our fee is an agreed percentage of realized savings on commitments we optimize. If we don’t save, you don’t pay a savings-based fee.
Final Verdict: Approve the Access You Can Verify
An access request is ready for approval when the enabled function, effective cloud permissions, data reach, accountable owners, and removal path agree. If a vendor cannot show the configuration or trace a proposed action through to the provider record, keep that requirement open.Frequently asked questions
Can we evaluate more than one platform without giving both purchasing authority?
Yes, if each vendor's assessment access and data handling meet your requirements. Review each integration independently, and avoid granting two platforms independent purchase authority over the same commitment scope without a clear owner and coordination plan.
Does selecting only some projects in a vendor dashboard restrict access to the billing dataset?
Not necessarily. The dataset's IAM grants and the billing export's contents determine what an identity can read. Check those controls and the billing-account scope separately from any project selection in the vendor interface.
Should the onboarding administrator keep elevated access for ongoing operation?
Only if a separately justified ongoing task requires it. Inspect the permissions granted to the continuing vendor identity after setup, then review your administrator's temporary access under your normal internal process.
Share
Facebook
X
LinkedIn
Reddit
