Reserved instances, savings plans, and hybrid benefit compose the structural cost layer of the Azure estate. Done well, they cut Azure compute economics by 30 to 65 percent without changing the workload. Done poorly, they lock the customer into commitments that absorb spend on resources that do not match what is actually running. The reserved instance strategy is the engagement that builds the structural cost layer against the workload, not against the seller proposed pattern.
A reserved instance is a one or three year commitment to consume specified Azure compute capacity in exchange for a materially discounted rate against the pay as you go price. The mechanic is simple. The execution is not. The reservation has to match the workload that is actually running, in the region the workload is running in, on the VM family that matches, in the quantity that the consumption pattern justifies. Mismatch any one of those and the reservation absorbs against the wrong consumption or sits underutilized while the workload bills at the on demand rate.
RI portfolios fail in three predictable ways. The first failure is over reservation against a workload that downsizes or migrates, leaving the commitment to absorb against deprecated capacity for the remainder of the term. The second failure is under reservation that leaves productive capacity billing at the on demand rate, often discovered too late to recover. The third failure is wrong family reservation, where the customer reserved D series and the workload runs on E series, leaving both the reservation and the consumption mispriced.
Each failure mode has a corresponding posture in the strategy work. The portfolio design accounts for workload trajectory, planned migrations, and seasonal capacity patterns. The reservation mix is sized to the consumption envelope rather than to the consumption peak. The instance family selection is matched against the deployed workload by region and by SKU, not against an aggregate compute number. The work produces a portfolio that absorbs as designed across the term rather than carrying drift from year one.
The Microsoft account team has visibility into your Azure consumption but does not have visibility into your workload roadmap, your planned migrations, your seasonal patterns, or your business case for the workloads that drive consumption. The seller produced reservation recommendation is statistical against your current consumption. The buyer side strategy is contextual against your workload future. Those two views produce different reservation portfolios and the customer outcome differs accordingly.
Savings plans operate alongside reserved instances and absorb differently. The plan commits to a dollar hourly spend rather than to specific compute capacity, which produces flexibility at a slightly higher rate than the equivalent RI. The mix of RI and savings plan against the workload determines the structural rate and the operational flexibility.
The strategy engagement designs the mix per workload class. Stable, well understood, regionally fixed workload absorbs to RI. Variable, migrating, or growing workload absorbs to savings plan. The aggregate Azure rate compresses without locking the estate into commitments that mismatch the workload trajectory.
The engagement runs in four phases over eight weeks. The first two phases produce the analysis. The third phase produces the executed portfolio. The fourth phase produces the operating model that maintains it across the term.
Azure consumption telemetry across all subscriptions, regions, and SKU families. Trailing twelve month profile. Workload classification. The starting baseline.
Workload roadmap from infrastructure and application teams. Planned migrations, planned decommissions, seasonal capacity, geographic shifts. The forward twelve month picture.
The RI and savings plan mix per workload class. Hybrid benefit posture. Region allocation. Family selection. The portfolio that absorbs as designed.
Portfolio purchase. Subscription tagging cleanup. The quarterly review cadence. The operating model that keeps the portfolio matched to the workload across the term.
Azure Hybrid Benefit is the customer right to apply existing Windows Server and SQL Server licenses with Software Assurance against equivalent Azure compute, removing the operating system or database license layer from the Azure compute rate. The benefit can reduce Azure VM cost by 40 to 55 percent on Windows compute and even more on SQL workloads. Many estates either do not apply hybrid benefit at all or apply it inconsistently across subscriptions.
The hybrid benefit posture engagement tests each Azure VM for hybrid benefit eligibility, identifies the VMs that should be applying it and are not, and identifies the VMs that are applying it but should not be. The second category is rare but material when it occurs because Microsoft can recoup the benefit if the underlying license entitlement is found insufficient at audit. The audit risk is symmetric.
The application of hybrid benefit at scale requires the Windows Server and SQL Server entitlement record. The work coordinates with the broader effective license position posture so that the hybrid benefit application is defensible and the contract memory is durable.
SQL Server licensing in Azure is governed by both the SQL core license entitlement and the Azure compute hybrid benefit posture. The two interact in ways that the Azure portal does not surface. The posture analysis identifies the SQL workloads where the customer is paying both the SQL license and the Azure premium rate, where the customer is paying the SQL license but not applying it to Azure, and where the customer is at the right posture and should hold.
SQL hybrid benefit is consistently one of the largest single recoveries the engagement produces on Azure heavy estates. Six to seven figure annual recovery is typical when the SQL posture has been unmanaged for more than 12 months.
An RI and savings plan portfolio designed correctly at engagement close drifts within nine to fifteen months absent a maintaining discipline. Workloads migrate. Regions shift. Family preferences evolve. The portfolio that was right last quarter is no longer right this quarter, and the absorption rate degrades as the mismatch grows.
The operating model is a quarterly review cadence. Each quarter, the consumption picture is rebaselined, the workload roadmap is updated, and the portfolio is rebalanced through reservation exchange, sale back, or new purchase. The review is not heavy. Most quarters produce small adjustments. The discipline catches the larger drift events early enough to correct without major rework.
The quarterly review is the input to the annual MACC structuring conversation, the input to the renewal posture work, and the input to the audit posture posture testing. It is the operating layer that converts the strategy engagement output into a portfolio that holds through the term.
The engagement includes the first four quarterly reviews as part of the package. After the first year, the customer chooses whether to internalize the discipline, to extend the engagement, or to absorb the work into the broader vendor negotiation retainer if one is in place. Most customers extend or absorb. The discipline pays for itself materially every quarter.
The brief is short. The portfolio picture, the recommended adjustment, the executive decision required. The work is operational by design, not advisory, because the value sits in the execution rather than in the analysis.
The Azure rate the customer pays at the end of the term is not the rate Microsoft set. It is the rate the customer designed through the reservation portfolio, the hybrid benefit application, and the savings plan posture. The customer who designs it pays the structural rate. The customer who does not pays the seller proposed rate.Managing analyst · Azure cost practice
The same four questions surface at the discovery stage of every engagement in this service line. The short answers are below. The full conversation happens against the customer specifics on the first analyst call.
A reseller earns margin on what you buy from Microsoft. Our economics are inverted. We are paid by the customer to reduce or restructure what the customer commits to Microsoft. No SKU we recommend produces revenue for the firm. No customer outcome we deliver compromises a reseller relationship the firm does not hold. The advice is buyer side without qualification, and the engagement structure is built around that posture.
This is the reason most reseller produced analyses recommend keeping the SKUs the reseller earns the most on. Our analyses do not have that incentive. The recommendations follow the customer interest, full stop.
The engagement is buyer side and confidential. Analyst access to customer data runs against a signed NDA with the engagement entity, not against any Microsoft visible data sharing arrangement. The artifacts produced for the customer are not shared with Microsoft unless the customer chooses to share them in negotiation. The methodology footnotes are designed to be defensible if surfaced and silent if not.
The engagement does not surface to the customer Microsoft account team. The seller will see the customer producing better counter analysis than the seller proposed pricing accounts for. The seller will not see the source of the counter analysis unless the customer chooses to disclose it.
Most engagements run as a fixed scope, fixed fee, fixed timeline structure. The fee is set on day one against the scope agreed in the engagement letter. Success based or contingent fee structures are available for specific engagement types where the outcome is cleanly attributable, but they are the exception rather than the default. Buyer side advisory works best when the analyst incentive is to do the right thing rather than to maximize a contingent number.
The first two analyst calls are scoped at no fee and produce the engagement letter only if the fit is right. We do not propose engagements we cannot deliver the outcome on.
The customer provides access to the contract record, the procurement file, the relevant administrative telemetry, and a single point of contact who can authorize the data access and the stakeholder interviews. The engagement does not require dedicated customer resourcing beyond the point of contact. The analyst team runs the work and surfaces findings into the customer cadence.
The data access is scoped tightly. Read only telemetry is sufficient for most workstreams. Where elevated access is required, the engagement scopes the access against a specific runbook with the customer security team in the loop.
Two analyst calls. No pitch. We tell you what we would do, what the leverage actually is, and whether we are the right firm for this engagement.