The Microsoft Azure Consumption Commitment is a multi-year cloud-spend commitment carrying discount bands, an eligible-service catalogue, Marketplace pull-through and a remediation framework. The Admodum read on quantum, tenor, ramp shape and expiry posture.
The Microsoft Azure Consumption Commitment (the MACC, in current naming; the SCE-Azure construct in legacy naming) is a multi-year commitment to spend a defined dollar (or pound, or euro) quantum on Azure across the term. In exchange for the commitment, the publisher offers discount bands tiered against the annual quantum and access to the Marketplace pull-through (Marketplace ISV purchases against the commit).
The commit is paid in arrears against consumption: the buyer is billed for actual Azure consumption against the commit each month; at term-end any unspent commit is forfeit.
The wider EA framework sits at the Enterprise Agreement overview; the MCA-E framework in which the MACC persists sits at MCA-E versus EA; the wider editorial sits in the Microsoft pillar.
The quantum is the annual dollar (or pound, or euro) commitment. The decision is read against three artefacts: the current Azure run-rate (the trailing twelve months of consumption against the eligible-service catalogue), the forecast Azure growth (the validated workload-by-workload growth plan), and the discount-band thresholds (the level above which the next band's discount kicks in).
The discipline is to size the quantum just inside the next band if the growth case supports it (the next band's discount on the whole commit exceeds the at-risk gap), and just below the next band if the growth case does not (the at-risk gap on the discount is not justified by the additional commit).
The wider OCI-comparator context sits at the OCI construct spoke; the wider hyperscaler comparator sits at the AWS and Google Cloud knowledge hubs.
The tenor (one, three or five years; three-year is the standard) interacts with the discount band: a longer tenor at a higher quantum carries a deeper discount; a shorter tenor at a lower quantum carries a shallower discount but materially less at-risk forfeiture.
The ramp shape (flat, front-loaded, back-loaded) is the per-year breakdown of the total commit. A flat ramp matches a steady-state migration; a front-loaded ramp suits a re-platforming workload that lands in year one; a back-loaded ramp suits a multi-year migration where the validated workload-by-workload growth lands across years two and three.
The eligible-service catalogue defines which Azure consumption counts against the commit. First-party Azure services count (compute, storage, networking, databases, AI, identity, monitoring); certain Marketplace ISV transactions pull through under the Marketplace pull-through rule (the ISV transacts on Marketplace, the consumption counts as Azure consumption against the commit).
The pull-through rule is the principal mechanic by which an enterprise can fund Marketplace-purchased third-party software (security, observability, data platforms) against the Azure commit; the buyer-side discipline is to route eligible third-party purchases through Marketplace rather than direct, where the catalogue supports the pull-through.
The wider Marketplace context sits at the Azure Marketplace burn spoke (forthcoming); the Azure Hybrid Benefit context sits at the Azure Hybrid Benefit spoke (forthcoming); the OpenAI economics sit at the Azure OpenAI economics spoke (forthcoming).
Unused commit at expiry is forfeit. There is no roll-forward. The expiry posture is therefore a design variable: the commit must size against a credible burn plan, and the burn plan must be monitored against actual consumption month by month across the tenor.
The remediation framework, where a buyer is trending under-consumption mid-term, includes: re-platform pull-through (additional workloads brought onto Azure to burn the commit); Marketplace pull-through (eligible third-party purchases routed through Marketplace); reserve-instance purchases (one and three year reserved instances counted as commit-eligible spend); commit reduction at the renewal moment (the next-term commit reset to the actual burn). Each option carries trade-offs that the buyer must read against.
The wider Reserved Instance context sits at the Azure reserved instances spoke (forthcoming); the renewal cadence sits at the EA renewal cycle.
The buyer-side artefacts to hold against the MACC are: the consumption baseline (the trailing twelve months of Azure consumption by eligible-service catalogue), the burn-rate forecast (consumption against commit, month by month, across the tenor), the eligible-service catalogue read (which resources are eligible; which Marketplace pull-throughs are eligible), the discount-band read (current band; next-band threshold; discount delta at the next band), the expiry-posture forecast (the at-risk under-burn) and the renewal-time disposition (the next-term commit read).
The renewal-time conversation is then a negotiation against artefacts. The publisher's renewal proposal carries a new quantum, a new tenor, a new ramp; the buyer reads each variable against the artefacts and against the BATNA (the AWS or Google Cloud commitment construct as the BATNA architecture).
The wider engagement sits in the Microsoft practice; the aggregated reading list sits in the Microsoft knowledge hub; active renewal moments route to the Renewal Programme; the wider hyperscaler comparators sit at the AWS practice and the Google Cloud practice.
The eighteen-month cadence in which the MACC is renegotiated.
A senior Admodum Microsoft advisor will read your Azure consumption baseline, the burn-rate forecast and the discount-band thresholds against your commit position on a private call. Active renewal moments route to the Renewal Programme.