Skip to content

SKU & pricing modernization

Clouds keep shipping cheaper ways to run the same workload: a newer instance generation, an ARM/Graviton processor, a newer disk type, a serverless or consumption pricing model, a managed-service tier that fits better. Modernizing the SKU or the pricing model keeps the workload identical while lowering the rate.

  • Newer generation / architecture: an older instance family or disk type (e.g. gp2→gp3) with a cheaper, equivalent successor; ARM/Graviton eligibility.
  • Better pricing model: provisioned capacity that fits serverless or consumption better, an on-demand mode that should be switched, a batch or spot-eligible workload.
  • Legacy tiers: classic/v1 services with a cheaper modern equivalent (e.g. Front Door classic → Standard, App Gateway v1 → v2).

Each candidate names the concrete target and confirms feature-compatibility in the pre-check, so a “cheaper” move never silently drops something you depend on.

Every dollar comes from a price lookup on both ends of the move (what your current SKU lists at, and what the target lists at, in your own region), applied to your own billed spend. There is no flat percentage anywhere: two SKUs one generation apart can be 6% or 24% apart depending on the region and the size, so a single “expect ~X%” figure would be wrong in both directions.

Where the two ends cannot both be priced, we say so instead of estimating. Some moves change the pricing model rather than the SKU (Front Door Classic → Standard, App Gateway v1 → v2, API Gateway REST → HTTP all reprice onto capacity units, base fees or per-rule charges), and no fraction of the old bill is the answer. Those findings still surface, because the legacy tier is a real fact worth acting on, but they carry no savings number: instead they show the resource’s measured monthly spend as your exposure, and say why the figure is withheld. A finding whose target cannot be verified against vendor documentation at all does not appear.

Modernization ranges from an online flag change to a planned migration; one-way moves (e.g. a Hyperscale promotion) lead with an export step and a longer lead time. leancosts drafts the migration steps, the validation, and the rollback. Follow Act on a cost finding.