.png)
AWS
Microsoft Azure
Google Cloud
A useful POC should produce more than a savings estimate. By the end, you should have a recommendation comparison, downside model, permissions plan, net-economics view, and clear go or no-go decision.
Start the POC With Read-Only Access
The first phase is for evaluation, not purchasing.Microsoft provides separate Savings Plan RBAC roles, including reader, purchaser, contributor, and administrator. A Savings Plan reader can inspect Savings Plans without purchase authority, but access to the billing and usage data needed for a POC must be reviewed separately. The purchaser role is specifically for purchasing.
Review Microsoft’s Savings Plan permission model.
You can review the opportunity first, then decide whether to grant us purchasing permissions.
| POC phase | Access objective | What happens |
|---|---|---|
| Read-only evaluation | Review authorized cost, usage, commitment, and metadata | Build recommendations |
| Recommendation review | Validate assumptions and economics | No purchase required |
| Purchase approval | Review additional permissions | Enable approved access |
| Active management | Execute approved commitment actions | Apply your chosen controls |
Define the POC Scope, Inputs, and Outputs
Define the test boundaries before connecting Usage.ai.Scope
Choose the subscriptions, management groups, billing scopes, services, and commitment types to include in the evaluation.Inputs
A useful POC should include:historical billing and usage data
existing Reservations and Savings Plans
current benefit scope and utilization
known rightsizing opportunities
planned migrations or architecture changes
expected growth or reductions
applicable Usage.ai fees
Outputs
The final package should include:current spend and commitment coverage
uncovered eligible usage
our recommendation compared with Azure's native recommendation
lower-usage scenarios
modeled net savings, including applicable fees
required permissions
identified assumptions and risks
stakeholder sign-off
an explicit go or no-go decision
Establish the Azure Baseline First
Do not start by buying more discounts.Microsoft recommends rightsizing and shutdown actions first, then reviewing underutilized Reservations and possible trade-ins before adding new Reservations or Savings Plans.
Microsoft explains the broader commitment decision in its Savings Plan vs Reservation guidance.
A stronger sequence is:
Compare Our Recommendation With Azure
Our recommendation does not need to match Azure exactly.It should, however, explain the difference.
Microsoft’s Savings Plan recommendations analyze eligible hourly pay-as-you-go usage and simulate commitment levels. Microsoft documents the process in its Savings Plan recommendation methodology.
When comparing our recommendation with Azure, normalize the inputs first:
Scope: Use the same subscriptions or billing scope.
Lookback period: Compare the same historical period.
Commitment term: Compare equivalent terms.
Existing commitments: Treat current Reservations and Savings Plans consistently.
Expected changes: Include the same migrations, rightsizing, and growth assumptions.
which usage we consider eligible
which workloads we exclude
how we handled existing commitments
why our baseline differs from Azure's
which assumptions could reduce the opportunity
Use a Proof-of-Value Scorecard
| Area | Evidence to require | Review owner |
|---|---|---|
| Access | Read-only evaluation with controlled permissions | Security |
| Baseline | Existing commitments and uncovered usage identified | FinOps |
| Workload changes | Rightsizing, migrations, and growth included | Engineering |
| Recommendation | Product, amount, scope, term, and assumptions | FinOps |
| Economics | Incremental savings and applicable Usage.ai fees included | Finance |
| Commercial terms | Fees, responsibilities, and approval process | Procurement |
| Downside | Lower-usage scenarios tested | FinOps + Finance |
| Auditability | Recommendation can be reproduced and reviewed | All stakeholders |
Test What Happens When Usage Drops
Do not test only the expected case.Rerun the economics with scenarios such as:
10% or 20% lower eligible usage
VM rightsizing
planned migrations
architecture changes
movement between Azure services or regions
existing commitments absorbing more usage than expected
Azure Savings Plans use a fixed dollar-per-hour commitment. Savings Plan for Compute is available in one- or three-year terms, while Savings Plan for Databases is available in a one-year term. Unused commitment for an hour expires and does not roll over.
See Microsoft’s Azure Savings Plan overview and discount application guidance.
Compare Savings Plans With Reservations
A strong POC should not assume a Savings Plan is automatically the right choice.Microsoft positions Reservations for more stable workloads where relevant resource characteristics are expected to remain consistent. Savings Plans provide more flexibility across eligible usage.
Use Microsoft’s Savings Plan and Reservation comparison when validating the recommendation.
The POC should answer two questions:
How much usage is safe to commit?
Which Azure commitment model best fits that usage?
Separate Modeled Savings From Realized Savings
A read-only POC can validate a modeled savings opportunity.It cannot prove future realized savings because new commitments have not been purchased and future usage has not occurred.
Modeled savings use historical usage, current rates, eligibility, existing commitments, and assumptions.
Realized savings are what you retain after the commitment is purchased, future utilization is known, workloads change, and applicable fees are included.
Microsoft’s Azure Advisor savings methodology also treats savings estimates as dependent on future usage and pricing.
Define a Clear POC Pass Condition
A POC should end with a documented decision.FinOps signs off on
Baseline, commitment coverage, recommendation methodology, and modeled utilization.Engineering signs off on
Expected workload stability, migrations, rightsizing, and architecture changes.Security signs off on
Current access and any permissions requested for execution.Procurement and Finance sign off on
Commercial terms, applicable Usage.ai fees, net economics, and downside exposure.The final decision should be explicit:
GO: The recommendation is technically and financially supported.
NO-GO: The evidence does not justify additional commitment or purchasing access.
REVIEW: More usage history or revised assumptions are required.
Azure Cost Optimization POC Checklist
Before making the final decision, confirm:Existing Reservations and Savings Plans were included.
Rightsizing and underutilized commitments were reviewed first.
Eligible usage is separated from total Azure spend.
Our recommendation and Azure's native recommendation use comparable inputs.
Planned infrastructure changes are reflected.
Lower-usage scenarios were modeled.
Hourly underutilization risk is understood.
Applicable Usage.ai fees are included in net economics.
Finance, Engineering, Security, and Procurement reviewed the result.
How We Run a Read-Only Savings Test at Usage.ai
At Usage.ai, our read-only Azure Savings Test lets you evaluate the savings opportunity before giving us permission to purchase commitments.Our Azure integration uses a dedicated service principal with read-only permissions for the evaluation. The administrator setting up the integration needs sufficient Azure authority to assign the required role, but our service principal does not automatically receive that administrator role.
See our Azure permissions guidance and Savings Test workflow.
During the test, we evaluate relevant billing, usage, existing commitments, and workload information to understand existing coverage, where eligible usage remains uncovered, and which additional opportunities may be worth considering.
The goal is simple: prove the opportunity first, then decide whether purchasing access makes sense.
Disclosure
We are Usage.ai, a cloud cost optimization and commitment-management company.Azure Advisor, Azure Reservations, Azure Savings Plans, Azure Cost Management, and Azure RBAC are Microsoft products and services. Microsoft controls their pricing, permissions, eligibility, recommendations, and billing mechanics.
Our Savings Test and Flex Insured Commitments are separate Usage.ai services.
Run the POC Before Granting Purchase Access
Microsoft states that Azure Savings Plan for Compute can provide up to 65% savings on pay-as-you-go prices for select compute services, with actual savings depending on factors such as region, instance type, and usage. Microsoft’s published 65% example is tied to a three-year Savings Plan for Compute. See Azure Savings Plan pricing and conditions.With our read-only Azure Savings Test, you can assess whether eligible workloads support the up to 65% savings associated with a three-year Azure Savings Plan for Compute before granting us purchasing access.
If you later choose to activate an eligible Flex Commitment with us and it costs more than equivalent On-Demand usage, we provide cashback protection to help cover the difference, subject to current program eligibility and terms. Learn more about our Flex Commitment Program and cashback protection.
Frequently asked questions
What is an Azure cost optimization proof of concept?
An Azure cost optimization POC is a limited evaluation that tests our savings methodology, permissions model, recommendations, downside assumptions, and projected economics against your actual Azure environment.
Does Usage.ai need purchasing access during the POC?
Not during our read-only Savings Test. The POC still requires separately authorized access to the billing, usage, and commitment data needed for the analysis, but purchasing authority remains with your team until you decide to proceed.
What data should an Azure cost optimization POC include?
Include historical cost and usage data, existing Reservations and Savings Plans, commitment utilization, planned workload changes, rightsizing opportunities, and relevant commercial assumptions.
What happens if an Azure Savings Plan is underused for an hour?
Unused hourly commitment expires and does not roll over. That is why Savings Plan sizing should be evaluated against hourly usage rather than monthly averages alone.
When should we grant purchasing authority?
Treat purchasing as a separate approval stage. Enable it after FinOps, Engineering, Security, Procurement, and Finance have reviewed the recommendation and the expected value justifies the additional access.
