.png)
Key takeaways
1
A read-only Usage.ai Savings Test lets you evaluate savings opportunities without giving us permission to purchase commitments.
2
Usage.ai reads billing, usage, existing commitment, and selected cloud metadata needed to build the recommendation. Read-only evaluation does not include starting or stopping workloads.
3
Purchasing is a separate step. Your team must authorize the recommendation and enable the permissions required for the product before Usage.ai can execute a commitment purchase.
You want to find out what Usage.ai could save. Your security team wants to know what connecting your cloud environment would allow us to do.
A read-only Usage.ai Savings Test lets you review the opportunity without giving us purchasing authority. We analyze billing, usage, existing commitments, and relevant cloud metadata. Your team can review the recommendation before deciding whether to enable commitment purchasing.
Purchasing requires additional permissions for the products you choose.
The benefit of separating those stages is practical. Your security team can review the evaluation scope before anyone has to decide whether Usage.ai should be allowed to act on a recommendation.
That makes the first review about what we can read, not about approving a financial action at the same time.
For example, if Savings Plans already cover some of your AWS usage, we need to account for that before recommending more coverage.
The same principle applies when you already hold Azure or Google Cloud commitments. Existing coverage changes how much additional commitment opportunity is actually available.
We do not start or stop workloads as part of this read-only evaluation.
You can review the current access description in our Security and Compliance documentation.
A read-only Usage.ai Savings Test lets you review the opportunity without giving us purchasing authority. We analyze billing, usage, existing commitments, and relevant cloud metadata. Your team can review the recommendation before deciding whether to enable commitment purchasing.
Purchasing requires additional permissions for the products you choose.
The benefit of separating those stages is practical. Your security team can review the evaluation scope before anyone has to decide whether Usage.ai should be allowed to act on a recommendation.
That makes the first review about what we can read, not about approving a financial action at the same time.
What we need to read
We read billing and usage data, existing commitments, and selected cloud metadata. That can include instance type, region, start and stop times, and CPU utilization.For example, if Savings Plans already cover some of your AWS usage, we need to account for that before recommending more coverage.
The same principle applies when you already hold Azure or Google Cloud commitments. Existing coverage changes how much additional commitment opportunity is actually available.
We do not start or stop workloads as part of this read-only evaluation.
You can review the current access description in our Security and Compliance documentation.
One important distinction
A read-only connection lets us evaluate the opportunity. It does not give us permission to purchase commitments.
If you later want us to act on an approved recommendation, the permissions required for that product must be enabled separately.
A read-only connection lets us evaluate the opportunity. It does not give us permission to purchase commitments.
If you later want us to act on an approved recommendation, the permissions required for that product must be enabled separately.
Access differs by cloud
AWS, Azure, and Google Cloud expose billing and usage information differently, so the identity and permission model you review will not look identical across clouds.| Cloud | Read-only evaluation | What changes for purchasing |
|---|---|---|
| AWS | IAM role and attached policy | Review the product permissions generated for what you enable |
| Azure | Dedicated service principal with read-only Savings Test access | Review the product permissions assigned for what you enable |
| Google Cloud | Dedicated service account with required BigQuery billing access | Insured Commitments adds read and write permissions for supported commitment products |
The table is a summary. Your security team should review the current policy, role, service principal, or permission configuration for the products you actually select.
The trust policy controls who can assume that role. The attached permissions control what the role can do.
That gives your team a concrete review point. Instead of approving a broad “Usage.ai access” request, you can inspect the role and policy for the accounts and products you plan to connect.
Keep the read-only evaluation scope separate from permissions that allow commitment purchasing.
Our AWS Integration Guide contains the implementation details, including individual account connections, CloudFormation and Terraform options, IAM role and policy setup, and the conditional hourly Cost Explorer requirement for Fargate recommendations.
AWS also documents how IAM trust and permissions policies work for cross-account access.
Our Azure Integration Guide lists User Access Administrator as a setup prerequisite. That does not mean Usage.ai receives that role.
The administrator performing the setup needs enough authority to create the required role assignments.
The dedicated Usage.ai service principal has its own permissions for the Savings Test. Those ongoing permissions, along with the management-group scope where they apply, are what your team should review before connecting.
Microsoft also documents how Azure RBAC role assignments can be removed when access is no longer required.
That billing access is separate from commitment-management permissions.
In the current GCP integration flow, selecting Insured Commitments grants additional read and write permissions for GCP reservations and savings plans.
That gives your team two different things to review: the access needed for billing analysis and the additional permissions associated with commitment management.
Our GCP Integration Guide contains the current custom-role, billing-export, dataset, and project-onboarding steps.
Google Cloud also documents how IAM access can be changed or revoked.
Under the documented Flex Commitment Program, we first analyze your cloud usage and provide a recommendation.
Once you approve a recommendation and the required permissions are enabled, we call the applicable AWS, Azure, or Google Cloud API to purchase the commitment. The resulting commitment is then managed as a Flex Commitment.
Our pricing model is tied to realized savings, and eligible commitments can include cashback protection under the applicable program terms.
The recommendation, your authorization, and the technical permissions are separate parts of that decision.
That distinction matters because your security team can decide what the integration is technically allowed to do, while your organization decides whether the recommended purchase should be authorized.
Simply connecting your cloud environment for evaluation does not grant us purchasing authority.
Your administrator can remove Usage.ai access through your cloud provider’s identity controls.
For AWS, that means removing the relevant IAM role or permissions.
For Azure, it means removing the applicable RBAC role assignment.
For Google Cloud, it means removing the relevant IAM role binding for the Usage.ai service account.
Any commitments already purchased remain subject to the applicable cloud provider’s terms.
Treat removing access and reviewing your remaining commitment obligations as separate steps.
Disconnecting Usage.ai should not be interpreted as canceling, refunding, or otherwise removing a provider-side commitment.
How AWS access works
AWS uses an IAM role.The trust policy controls who can assume that role. The attached permissions control what the role can do.
That gives your team a concrete review point. Instead of approving a broad “Usage.ai access” request, you can inspect the role and policy for the accounts and products you plan to connect.
Keep the read-only evaluation scope separate from permissions that allow commitment purchasing.
Our AWS Integration Guide contains the implementation details, including individual account connections, CloudFormation and Terraform options, IAM role and policy setup, and the conditional hourly Cost Explorer requirement for Fargate recommendations.
AWS also documents how IAM trust and permissions policies work for cross-account access.
How Azure access works
For an Azure Savings Test, we use a dedicated service principal with read-only permissions.Our Azure Integration Guide lists User Access Administrator as a setup prerequisite. That does not mean Usage.ai receives that role.
The administrator performing the setup needs enough authority to create the required role assignments.
The dedicated Usage.ai service principal has its own permissions for the Savings Test. Those ongoing permissions, along with the management-group scope where they apply, are what your team should review before connecting.
Microsoft also documents how Azure RBAC role assignments can be removed when access is no longer required.
How Google Cloud access works
For evaluation, a dedicated service account reads the required BigQuery billing datasets.That billing access is separate from commitment-management permissions.
In the current GCP integration flow, selecting Insured Commitments grants additional read and write permissions for GCP reservations and savings plans.
That gives your team two different things to review: the access needed for billing analysis and the additional permissions associated with commitment management.
Our GCP Integration Guide contains the current custom-role, billing-export, dataset, and project-onboarding steps.
Google Cloud also documents how IAM access can be changed or revoked.
What changes before purchasing
Connecting your environment for a read-only Savings Test does not start purchasing.Under the documented Flex Commitment Program, we first analyze your cloud usage and provide a recommendation.
Once you approve a recommendation and the required permissions are enabled, we call the applicable AWS, Azure, or Google Cloud API to purchase the commitment. The resulting commitment is then managed as a Flex Commitment.
Our pricing model is tied to realized savings, and eligible commitments can include cashback protection under the applicable program terms.
The recommendation, your authorization, and the technical permissions are separate parts of that decision.
That distinction matters because your security team can decide what the integration is technically allowed to do, while your organization decides whether the recommended purchase should be authorized.
Simply connecting your cloud environment for evaluation does not grant us purchasing authority.
How access can be removed
Removing access does not cancel existing commitments.Your administrator can remove Usage.ai access through your cloud provider’s identity controls.
For AWS, that means removing the relevant IAM role or permissions.
For Azure, it means removing the applicable RBAC role assignment.
For Google Cloud, it means removing the relevant IAM role binding for the Usage.ai service account.
Any commitments already purchased remain subject to the applicable cloud provider’s terms.
Treat removing access and reviewing your remaining commitment obligations as separate steps.
Disconnecting Usage.ai should not be interpreted as canceling, refunding, or otherwise removing a provider-side commitment.
Before connecting Usage.ai
Before connecting, confirm:Which AWS accounts, Azure scopes, or Google Cloud projects are in scope.
Whether you are enabling read-only evaluation or purchasing permissions as well.
Which Usage.ai products you plan to enable.
The actual policy, role, service principal, or service-account permissions requested for those products.
Who on your team can approve commitment purchases.
Who owns ongoing access reviews and removal.
This gives security, engineering, and FinOps teams a clear basis for reviewing the integration without mixing evaluation access with purchasing authority.
Review permissions before you connect
Check the integration guide for your cloud to review the evaluation setup and the permissions required for the products you plan to enable. Review the exact permissions for your selected products before enabling purchasing.Frequently asked questions
Should permissions be reviewed when we enable another Usage.ai product?
Yes. Permissions can vary by cloud and product, so review the current configuration when you change what you enable.
How can our security team verify the exact permissions?
Review the role, policy, service principal, or service account created during setup together with the relevant Usage.ai integration guide.
Can we control which cloud environments are connected?
Yes. The setup lets you choose the relevant AWS accounts, Azure scope, or GCP projects you want to connect.
What should we review during an access check?
Confirm the connected scope, enabled Usage.ai products, and the permissions currently assigned to the integration.
Does Usage.ai need access to core infrastructure?
No. Our security documentation says we access the billing layer and specific metadata needed for optimization, not core infrastructure resources.
Share
Facebook
X
LinkedIn
Reddit
