Seçilmiş VM seriyaları üçün RI satınalma və yenilənmələri 1 İyul 2026-dan sonra dayanır; mövcud rezervasiyalar isə term bitənədək endirim verməyə davam edir.
Bu dəyişiklik sırf “VM işləməyəcək” tipli klassik retirement deyil; əsas risk kommersiya qatındadır. 1 İyul 2026-dan sonra birillik RI-lar Av2, Amv2, Bv1, D, Ds, Dv2, Dsv2, F, Fs, Fsv2, G, Gs, Ls və Lsv2 seriyaları üçün, həmçinin birillik və üçillik RI-lar Dv3, Dsv3, Ev3 və Esv3 üçün yeni alım və renewal səviyyəsində dayandırılır. Nəticə odur ki, compute runtime işləməyə davam etsə belə, rezervasiya termi bitəndə xərclər avtomatik olaraq pay-as-you-go qiymət modelinə düşə bilər və bu, FinOps baxımından “gizli cost cliff” yaradır. Microsoft-un öz keçid bələdçisi də məhz cost predictability-nin qorunmasını əsas məqsəd kimi vurğulayır.
FinOps tərəfində üç fərqli ssenari yaranır. Birinci ssenaridə workload sabitdir və siz eyni ölçü qrupu daxilində qalmaq istəyirsiniz; bu halda instance size flexibility hələ də faydalıdır, amma yalnız eyni flexibility group daxilində. İkinci ssenaridə workload dinamiktir və region, service və ya VM ailəsi üzrə elastiklik lazımdır; burada Microsoft savings plan-ı əsas tövsiyə kimi önə çəkir. Üçüncü ssenaridə isə siz köhnə ailədən yeni ailəyə keçirsiniz; bu zaman təkcə ölçü deyil, storage temp disk davranışı, CPU generation, premium storage uyğunluğu, ephemeral OS disk dəstəyi və availability zonası mövcudluğu da yenidən yoxlanmalıdır. Üstəlik, reservation exchange siyasətində ailə və region üzrə gələcək məhdudlaşma trendi olduğuna görə, uzunmüddətli strateji seçim kimi savings plan daha elastik ola bilər.
Arxitektura baxımından bunu üçqat model kimi düşünmək daha düzgündür: workload runtime (real işləyən VM SKU), commercial coverage (RI / savings plan / PAYG) və hardware generation lifecycle (ailənin faktiki retirement statusu). Bu qatları qarışdırmaq ən tipik səhvdir. Məsələn, Dv3/Dsv3/Ev3/Esv3 ailələri üçün Microsoft-un migration guide sənədi açıq şəkildə bildirir ki, bu ailələr “further notice” verilənədək runtime retirement mərhələsində deyil, amma onların RI endirimləri üçün yeni purchase/renewal imkanları 1 İyul 2026-dan sonra dayandırılır. Yəni workload-unuz işləyə bilər, amma commitment economics dəyişir.
Arxitektura və Dəyişikliyin Mahiyyəti.
Ən mühüm texniki detal odur ki, Reserved VM Instance coverage yalnız uyğun SKU və uyğun flexibility group çərçivəsində avtomatik tətbiq olunur. Microsoft-un instance size flexibility sənədlərində göstərildiyi kimi, məsələn Standard_DS4_v2 rezervasiyası eyni DSv2 flexibility group daxilində daha kiçik və ya nisbətə görə başqa SKU-ları da qismən və ya tam əhatə edə bilir, amma ailə dəyişdikdə bu avtomatizm itir. Bu səbəbdən “Dsv2-dən Dsv5-ə resize etdik, rezervasiya yenə işləyər” fərziyyəsi təhlükəlidir; kommersiya coverage ayrı planlanmalıdır. Bundan əlavə, Microsoft 9 May 2026-dan etibarən instance size flexibility CSV faylının yenilənməyəcəyini, 30 Avqust 2026-da isə tam çıxarılacağını və API/PowerShell yoluna keçidi tövsiyə etdiyini qeyd edir. DevOps pipeline-larında hələ CSV-yə bağlı məntiq varsa, bu özü ayrıca technical debt-dir.
Yeni nəsil ailəyə keçid zamanı yalnız “closest successor” deyil, workload sinfi üzrə seçim etmək lazımdır. Dv3/Dsv3 üçün tövsiyə olunan ailələr Dsv5, Ddsv5, Dasv5, Dadsv5, Dsv6, Ddsv6, Dasv6 və Dadsv6 kimi verilir; Ev3/Esv3 üçün isə Esv5, Edsv5, Easv5, Eadsv5, Esv6, Edsv6, Easv6 və Eadsv6 ailələri tövsiyə olunur. Bu mapping sadəcə CPU upgrade deyil; local storage, AMD/Intel seçimi, memory-per-vCPU nisbəti, temp disk davranışı və perf-per-dollar profilini də dəyişir. Ona görə migration matrisi “legacy SKU → target SKU → reservation strategy → validation status” formatında saxlanmalıdır.
Adım-adım Tətbiq və Konfiqurasiya.
İlk mərhələ inventardır: hansı VM-lərin impacted ailələrdə işlədiyini və hansı subscription-larda RI expiry yaxınlaşdığını çıxarmaq lazımdır. Aşağıdakı Azure Resource Graph sorğusu runtime footprint-i tapmaq üçün praktik başlanğıcdır. İkinci mərhələ isə commercial coverage planıdır: eyni ailə daxilində qalacaqsınızsa RI, yeni ailəyə keçirsinizsə savings plan və ya yeni reservation kombinasiyası seçilməlidir. Microsoft-un reservation exchange və refund prosesi portal üzərindən idarə olunur; trade-in və ya exchange qərarı term və yeni hədəf məhsulun məbləğinə görə qurulur.
# Impacted VM families inventory via Azure Resource Graph
az graph query -q "
resources
| where type =~ 'microsoft.compute/virtualmachines'
| extend vmSize = tostring(properties.hardwareProfile.vmSize)
| where vmSize matches regex @'^(Standard_)?(A.*v2|B.*v1|D.*_v2|DS.*_v2|F.*|FS.*|Fsv2.*|G.*|GS.*|L.*s.*|Lsv2.*|D.*v3|DS.*v3|E.*v3|ES.*v3)'
| project subscriptionId, resourceGroup, name, location, vmSize
" -o tableAiləmiqyaslı resize üçün dəyişiklik pəncərəsi belə planlana bilər: əvvəl VM-ni deallocate edin, sonra hədəf SKU-ya resize edin, daha sonra yenidən start verin. Bu davranış klassik IaaS resize modelinə uyğundur və xüsusən availability/capacity səhvlərini ayırd etmək üçün vacibdir. Əgər siz yeni ailəyə migration edirsinizsə, IaC-də SKU parametrləşdirilməsi də eyni anda dəyişdirilməlidir ki, drift yaranmasın. Microsoft-un guidance-i Dv3/Dsv3 və Ev3/Esv3 üçün konkret successor ailələri göstərir; aşağıdakı Bicep pattern-i həmin idarəetmə yanaşmasını əks etdirir.
# Resize workflow
az vm deallocate -g rg-prod -n appvm01
az vm resize -g rg-prod -n appvm01 --size Standard_D4ds_v5
az vm start -g rg-prod -n appvm01
@description('Target VM size after legacy family exit strategy')
param vmSize string = 'Standard_D4ds_v5'
resource vm 'Microsoft.Compute/virtualMachines@2024-11-01' = {
name: 'appvm01'
location: resourceGroup().location
properties: {
hardwareProfile: {
vmSize: vmSize
}
// other properties omitted for brevity
}
}Mümkün Problemlər və Troubleshooting Ssenariləri.
Ən çox rast gəlinən edge case odur ki, reservation termi bitir, VM isə işləməyə davam edir və komanda bunu “service healthy” kimi qəbul edir. Əslində problem cost anomaly-dir. Bu ssenaridə ilk yoxlama reservation utilization və expiration tarixidir; ikinci yoxlama actual runtime SKU-nun reservation coverage-ə düşüb-düşməməsidir; üçüncü yoxlama isə resize edilmiş SKU-nun əvvəlki flexibility group-dan çıxıb-çıxmadığıdır. Əgər VM fərqli ailəyə keçibsə, köhnə RI coverage tətbiq olunmur.
İkinci tip problem resize failure-dir. Regionda target SKU capacity çatışmazlığı, zonal uyğunsuzluq, local-temp-disk fərqləri və bəzi köhnə şəkillərin yeni ailədə dəstəklənməməsi buna səbəb ola bilər. Dv3/Ev3 sahəsindəki migration guide göstərir ki, successor ailələrə keçid yalnız commercial decision deyil; support matrix məsələsidir. Əgər runtime retirement olmuş ailəyə ilişmisinizsə və deadline-i qaçırmısınızsa, Microsoft-un sənədi bildirir ki, belə VM-lər deallocated vəziyyətə düşə, SLA və dəstək itirilə, amma managed disk data-sı qoruna bilər; bu halda supported size-a resize və restart bərpa yolu olur.
Üçüncü tip problem reservation automation mənbəyindədir. Əgər sizin daxili FinOps pipeline-larınız hələ instance size flexibility CSV faylına paralel dependensiyadadırsa, həmin CSV 9 May 2026-dan sonra yenilənmir və 30 Avqust 2026-da silinir. Bu halda ratio və flexibility mapping-ləri API və ya PowerShell-lə dinamik çəkməyən hər hansı avtomatlaşdırma yanlış qərar verə bilər. Burada remediation çox aydındır: static CSV-ləri pipeline-dan çıxarın, canlı metadata source-a keçin, commit coverage hesablama məntiqini test edin.
Ən Yaxşı Təcrübələr.
Ən sağlam yanaşma budur: legacy ailələr üçün ayrıca “RI exit register” yaradın; hər entry-də reservation expiration tarixi, successor SKU, test nəticəsi, savings plan uyğunluğu və rollback planı olsun. Sabit workload-lar üçün reservation, dəyişən workload-lar üçün isə savings plan xətti qurun. Resize-dan əvvəl perf baseline, disk IO baseline və boot diagnostics snapshot götürün. Və ən vacibi, runtime migration qərarını reservation qərarı ilə qarışdırmayın; bunlar eyni cədvəldə izlənməlidir, amma eyni problem deyillər.