Di Dima Kramskoy — Senior Cloud Architect, DoiT International
La domanda che tutti pongono nel modo sbagliato
Quando gestivo i ticket di ottimizzazione cloud, questa era la domanda numero uno dei clienti: "Meglio i Savings Plans o le Reserved Instances?". Me la sentivo ripetere tre, quattro volte a settimana da clienti diversi.
È la domanda sbagliata.
Quella giusta è: che aspetto avranno i suoi workloads tra 12 mesi?
Ecco perché questo cambio di prospettiva è decisivo: un'organizzazione che pianifica una migrazione a Graviton butterà via soldi in Standard RI che non potranno seguire i workloads verso nuove instance family. Un team con un cluster RDS solidissimo, con configurazione invariata da due anni, lascia soldi sul tavolo scegliendo i Compute Savings Plans quando una Standard RI offrirebbe 6–9 punti percentuali di sconto in più.
La scelta tra SP e RI non è una questione di prodotti. È una questione di direzione architetturale. La strategia di commitment deve rispecchiare la roadmap dell'infrastruttura, non il contrario.
E c'è una verità scomoda: la maggior parte dei clienti con cui lavoro non sa che aspetto avranno i propri workloads tra 12 mesi. Non sa se migrerà a Graviton il prossimo trimestre, se passerà ai container o se raddoppierà il compute. Non è un fallimento della pianificazione: è la realtà. Se non sa dove sono diretti i suoi workloads, questa È già la risposta. Incertezza = flessibilità. Scelga almeno i Compute Savings Plans, oppure, ancora meglio, lasci che sia uno strumento a farsi carico del rischio di commitment al posto suo (ne parliamo alla fine).
Le illustro il framework che uso con i clienti enterprise, aggiornato con tutte le novità del 2025–2026.
Risposta rapida: diagramma decisionale
Prima di entrare nel dettaglio, ecco la via più rapida:
START: qual è il suo workload di compute principale?│├─ Solo EC2, una sola instance family, stabile da 12+ mesi│ └─ → EC2 Instance Savings Plan o Standard RI│ ├─ Serve capacity reservation? → Zonal Standard RI│ └─ Vuole una gestione più semplice? → EC2 Instance SP│├─ EC2 su più instance family│ └─ → Compute Savings Plan│├─ Migrazione a Graviton in programma (x86 → arm64)│ └─ → Compute Savings Plan (si applica automaticamente alla nuova family)│├─ Fargate, Lambda o serverless-first│ └─ → Compute Savings Plan (è l'unico tipo che li copre)│├─ RDS / Aurora / livello database│ └─ Config stabile, sconto massimo? → Standard RI (fino al 69%)│ └─ Multi-engine, Gen 7+, flessibilità? → Database SP (fino al 35%)│└─ Ri-architettura in corso o migrazione fuori da AWS └─ → Non si impegni. Usi On-Demand/Spot finché la situazione non si stabilizza.Tabella comparativa rapida
| Tipo | Sconto massimo | Flessibilità | Ideale per |
|---|---|---|---|
| Compute SP | Fino al 66% | Qualsiasi region, family, OS, servizio | Organizzazioni in modernizzazione, serverless, multi-region |
| EC2 Instance SP | Fino al 72% | Qualsiasi size/OS dentro a family + region fissi | EC2 family stabile, gestione semplice |
| Standard RI | Fino al 72–75% | Tipo + region fissi (flessibilità di size con la Regional RI) | Workloads ultra-stabili, capacity reservation |
| Convertible RI | Fino al 54–58% | Family/OS scambiabili (stessa region) | Esigenze legacy di flessibilità — ormai superate dagli SP |
| Database SP | Fino al 35% | Qualsiasi DB engine idoneo (solo Gen 7+) | Parchi database multi-engine, Aurora Serverless |
Cosa è cambiato nel 2025–2026
Quattro novità di rilievo dalla mia ultima revisione sull'ottimizzazione dei costi:
1. Lancio dei Database Savings Plans (dicembre 2025)
L'annuncio FinOps più importante del re:Invent 2025. I Database Savings Plans coprono 10 servizi: Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream, DMS e OpenSearch.
La fregatura: solo termini da 1 anno (niente 3 anni), solo No Upfront, e richiedono istanze Gen 7+ (db.r7g, db.m7g). Lo sconto massimo è di circa il 35%, ben al di sotto del 69% raggiungibile con le Standard RDS RI. Non sostituiscono quindi le DB RI: sono una leva di flessibilità per organizzazioni con parchi database eterogenei e in evoluzione.
2. Restrizioni sulla condivisione di RI/SP (giugno 2025)
AWS ha vietato a MSP e rivenditori di condividere gli sconti RI/SP tra più clienti finali. Se acquista tramite un partner, i commitments sono ora vincolati al solo utilizzo della sua azienda. Acquirenti enterprise diretti: in larga parte non interessati dalla novità.
3. Funzionalità Group Sharing — GA (novembre 2025)
È passata un po' in sordina, ma risolve un vero punto dolente. Ora può controllare con precisione quali account della sua Organization beneficiano dei commitments condivisi, scegliendo tra due modalità:
- Prioritized Group Sharing: il commitment si applica prima al gruppo designato e poi si estende al resto dell'organizzazione
- Restricted Group Sharing: isolamento totale — ne beneficia solo il gruppo designato
Mette fine al problema del "team sbagliato che beneficia della nostra RI" che ha afflitto il consolidated billing per anni. I gruppi si definiscono tramite Cost Categories. Se gestisce un'organizzazione multi-BU con modelli di chargeback, le cambia le regole del gioco.
4. Le RI NON sono deprecate
Nonostante le speculazioni ricorrenti, le Reserved Instances restano pienamente supportate. Le pagine di pricing AWS sono aggiornate attivamente (ultimo aggiornamento maggio 2026), Cost Explorer continua a generare raccomandazioni RI e l'RI Marketplace è operativo. AWS predilige chiaramente i Savings Plans nello sviluppo di nuove funzionalità e nella documentazione, ma le RI non sono in via di estinzione.
Un'ultima cosa: i Savings Plans con commitments superiori a 100 $/ora non sono restituibili. Sotto i 100 $/ora ha una finestra di 7 giorni all'interno dello stesso mese di calendario, con un massimo di 10 restituzioni all'anno. A scala enterprise, questi commit sono di fatto permanenti. Pianifichi di conseguenza.
Approfondimento: Compute SP vs EC2 SP vs Standard RI vs Convertible RI
Ecco il confronto completo che avrei voluto avere io quando prendevo queste decisioni:
| Dimensione | Compute SP | EC2 Instance SP | Standard RI | Convertible RI |
|---|---|---|---|---|
| Sconto massimo | 66% | 72% | 72–75% | 54–58% |
| Base del commitment | $/ora (qualsiasi compute) | $/ora (family + region) | Instance type + region + OS + tenancy | Instance family + region |
| Instance family | Qualsiasi — applicazione automatica | Fissa per piano | Fissa | Scambiabile |
| Instance size | Qualsiasi — applicazione automatica | Qualsiasi — applicazione automatica | Flessibile (Regional RI) | Flessibile |
| Flessibilità OS | Qualsiasi | Qualsiasi | Fissa | Scambiabile |
| Region | Cross-region ✅ | Region fissa | Region fissa | Region fissa |
| Lambda/Fargate | ✅ | ❌ | ❌ | ❌ |
| Capacity reservation | ❌ | ❌ | ✅ (Zonal RI) | ❌ |
| Rivendibile | ❌ | ❌ | ✅ (RI Marketplace*) | ❌ |
| Cancellabile | Limitato (≤100 $/h, 7 giorni) | Limitato | ❌ | ❌ |
| Overhead di gestione | Basso | Basso | Alto | Medio |
*I clienti EDP non possono vendere sull'RI Marketplace.
Ordine di applicazione in fattura (un dettaglio che conta)
AWS applica gli sconti seguendo questa priorità:
- Le Reserved Instances si applicano per prime (sull'utilizzo corrispondente)
- Gli EC2 Instance Savings Plans si applicano per secondi
- I Compute Savings Plans si applicano per ultimi (la rete più ampia)
All'interno di ciascun livello, viene coperto per primo l'utilizzo con la percentuale di risparmio più alta. Significa che può combinare tranquillamente tutti e tre i tipi senza conflitti: AWS ottimizza l'applicazione in automatico.
Portabilità dei workloads: quando la flessibilità batte lo sconto
Il gap di sconto tra Compute SP (66%) ed EC2 Instance SP (72%) è di circa 6 punti percentuali. A condizioni enterprise tipiche (1 anno, no-upfront), si riduce a 2–4 punti. Vediamo insieme quando pagare quel "premio di flessibilità" è palesemente la scelta giusta.
Migrazione a Graviton
Passaggio da x86 (m5, c5, r5) a Graviton (m7g, c7g, r7g):
- Compute SP: senza intoppi. Lo sconto si applica automaticamente alle istanze Graviton nel momento stesso in cui le avvia.
- EC2 Instance SP: si rompe. m5 ≠ m7g — sono instance family diverse.
- Standard RI: del tutto inutilizzabile per le nuove istanze. Commitment incagliato.
- Convertible RI: richiede uno scambio manuale, di valore pari o superiore, e resta vincolata alla region.
Se è sul percorso di migrazione a Graviton (e dovrebbe esserlo: il rapporto prezzo/prestazioni migliora del 20–40%), i Compute SP sono strutturalmente superiori.
Containerizzazione / transizione al serverless
Passaggio da EC2 a ECS/Fargate o Lambda:
- Compute SP: copre Fargate e Lambda in automatico. Lo sconto la segue.
- Tutto il resto: zero copertura su compute container o serverless.
Espansione cross-region
Apertura di una nuova region o consolidamento da 4 region a 2:
- Compute SP: lo sconto si applica globalmente su tutte le region.
- Tutti gli altri: vincolati alla region. Il consolidamento le incaglia i commitments.
I numeri
Su una spesa annua di compute di 5 milioni di dollari, un gap di 6 punti percentuali costa circa 300.000 $ in 3 anni. Sembra una cifra importante — finché non si rende conto che una migrazione a Graviton fallita (perché non può permettersi di abbandonare RI bloccate) le costa il miglioramento di prestazioni del 20–40% sull'intera flotta. Il premio di flessibilità è un'assicurazione, e per giunta a buon mercato.
Gli anti-pattern (cosa succede quando si sbaglia)
In oltre 10 anni di ottimizzazione dei costi cloud ho visto questi errori costare milioni alle aziende. Ecco i cinque più costosi:
Anti-pattern 1: impegnarsi sul picco invece che sul baseline
L'errore: acquistare commitments basandosi sull'utilizzo massimo osservato.
Cosa succede: si impegna per 50 $/ora perché è il picco del lunedì mattina. Il baseline sostenuto è invece di 35 $/ora. Sta sfruttando il commitment al 70%: il restante 30% è puro spreco.
Il costo: su un commit da 50 $/ora, il 30% di spreco equivale a 131.000 $/anno bruciati.
La soluzione: si impegni sul 70–80% del suo floor sostenuto (su 60–90 giorni di dati). Copra i picchi con Spot e On-Demand.
Anti-pattern 2: Standard RI su workloads prossimi alla migrazione
L'errore: acquistare Standard RI a 3 anni per una flotta m5 con una migrazione a Graviton in roadmap.
Cosa succede: dopo sei mesi è pronto a passare a m7g. Le sue Standard RI non possono seguirla. Non sono convertibili. Se è un cliente EDP, non può nemmeno venderle sul Marketplace. Sta pagando istanze che non gira più.
Il costo: una RI a 3 anni incagliata su r5.4xlarge: commitment di circa 278 $/mese che produce zero benefici per i 30 mesi residui = 8.340 $ sprecati per istanza. Lo moltiplichi per una flotta intera.
La soluzione: se è prevista una qualsiasi variazione architetturale nella finestra del commitment, usi i Compute SP.
Anti-pattern 3: lasciare scadere i commitments in silenzio
L'errore: nessun monitoraggio delle scadenze, nessuna coda di rinnovi.
Cosa succede: un blocco di RI scade un martedì. Nessuno se ne accorge finché non arriva la fattura di fine mese. La tariffa effettiva passa da 278 $/mese a 736 $/mese per r5.4xlarge: oltre il 62% di aumento da un giorno all'altro.
Il costo: una flotta di 20 istanze che torna On-Demand anche solo per un mese: circa 9.160 $ di spesa inattesa.
La soluzione: alert di scadenza tramite AWS Budgets + acquisti di Savings Plan in coda prima della data di scadenza.
Anti-pattern 4: ignorare il compute non-EC2
L'errore: impegnarsi solo su EC2 mentre oltre il 40% della spesa di compute è in Lambda, Fargate o EKS.
Cosa succede: una quota significativa di spesa serverless/container resta a tariffa piena On-Demand. Le aziende che ottimizzano solo i commitments EC2 pensano di aver "chiuso la partita" e intanto lasciano sul tavolo il 20–30% di risparmi sui workloads in più rapida crescita.
Il costo: 200.000 $/anno in Lambda + Fargate On-Demand quando un Compute SP farebbe risparmiare dal 20% al 66% = 40.000–132.000 $/anno di risparmi mancati.
La soluzione: faccia un audit di TUTTI i servizi idonei. Un singolo Compute SP copre contemporaneamente EC2, Lambda e Fargate.
Anti-pattern 5: impegnarsi durante una ri-architettura attiva
L'errore: acquistare commitments mentre si sta facendo right-sizing, re-platforming o migrazione.
Cosa succede: oggi si impegna per 80 $/ora. Nei 6 mesi successivi l'ottimizzazione riduce il baseline a 55 $/ora. Resta bloccato su 25 $/ora di spreco per tutto il termine residuo.
Il costo: 25 $/ora × 8.760 ore residue su un termine annuale = 219.000 $ di commitment incagliato.
La soluzione: prima stabilizzi, poi si impegni. Usi commitments scaglionati in base al livello di confidenza: commit piccoli durante la migrazione, commit più consistenti una volta che i pattern di utilizzo si sono consolidati.
Framework decisionale
Questa è la tabella da salvare con uno screenshot:
| Se il suo workload assomiglia a… | Scelga | Perché |
|---|---|---|
| Flotta EC2 stabile, singola family, nessun cambiamento previsto per 12+ mesi | EC2 Instance SP o Standard RI | Sconto massimo (72–75%) con basso rischio di incagliarsi |
| Flotta EC2 con migrazione a Graviton entro 12 mesi | Compute SP | Si applica automaticamente alla nuova instance family senza interventi |
| Architettura multi-region o espansione di region pianificata | Compute SP | L'unico tipo di commitment che funziona cross-region |
| Spesa Lambda/Fargate in crescita (>20% del compute) | Compute SP | L'unico tipo che copre compute serverless + container |
| Cluster RDS/Aurora, stessa configurazione da 18+ mesi | Standard RI | Lo sconto DB più profondo (fino al 69%) per database a stabilità comprovata |
| Più engine database, istanze Gen 7+, parco database in evoluzione | Database SP | Flessibilità su 10 servizi, copre Aurora Serverless |
| Serve capacità garantita per compliance/SLA | Zonal Standard RI | L'unico tipo di commitment che offre capacity reservation |
| Ri-architettura attiva, migrazione in corso | Non si impegni | Aspetti che l'utilizzo si stabilizzi; usi On-Demand/Spot |
La strategia a livelli (quella che consiglio alla maggior parte delle aziende)
Non scelga un solo tipo. Li sovrapponga:
- Livello 1 — Compute SP (60–80% del baseline): coprono il floor minimo di compute con la massima flessibilità
- Livello 2 — EC2 Instance SP: da aggiungere sopra per le family su cui ha confidenza (recuperano 6 pp di sconto extra)
- Livello 3 — Standard RI: da riservare ai workloads ultra-stabili del data-tier e alle esigenze di capacità
- Livello 4 — On-Demand/Spot: da usare senza commitment per workloads variabili e incerti
Parta con termini annuali per validare i pattern. Dopo 12 mesi di dati di utilizzo stabili, aggiunga termini triennali sul baseline consolidato (15–22 punti percentuali di sconto in più).
Come DoiT automatizza tutto questo
Ricorda quello che ho detto sull'incertezza? La maggior parte dei clienti non sa che aspetto avranno i propri workloads tra 12 mesi. È esattamente lo scenario per cui è stato costruito FlexSave for Compute.
Il pitch in una frase: ottiene tariffe di sconto pari a un Savings Plan annuale senza alcun commitment a suo carico. È DoiT a prendersi il rischio.
Ecco cosa fa:
- Monitora l'utilizzo on-demand: analizza cosa gira, cosa è stabile, cosa sta cambiando
- Applica automaticamente i meccanismi di sconto ottimali: copre i workloads idonei non già coperti dalle sue RI/SP
- Si adatta in continuo: migrazione a Graviton? Scaling down? Passaggio a Fargate? FlexSave si adegua senza che lei debba toccare un foglio di calcolo
- Nessun commitment da parte sua: è DoiT a farsi carico del rischio. Lei ottiene lo sconto. E può uscire quando vuole.
- Copre l'intero stack di compute: EC2, ECS, EKS, Fargate, Lambda, SageMaker (non solo EC2)
Per i database: i nuovi Database Savings Plans di AWS (dicembre 2025) sono la scelta migliore per RDS e Aurora. FlexSave si concentra sul compute, dove l'incertezza e le esigenze di flessibilità sono più elevate.
Per avere visibilità su tutto ciò che accade nel suo portafoglio di commitments, DoiT Cloud Analytics le offre metriche di utilizzo, copertura e sprechi in un unico posto: così sa sempre se la sua strategia sta funzionando.
La combinazione risolve entrambi i problemi: FlexSave gestisce l'esecuzione nei casi "non so cosa succederà dopo", Cloud Analytics garantisce la supervisione. L'incertezza smette di essere un problema quando i suoi strumenti si adattano insieme a lei.
TL;DR
I Compute SP sono la scelta di default per la maggior parte delle aziende — il premio di flessibilità (2–4 pp a condizioni tipiche) vale quasi sempre la pena per i team che hanno una qualsiasi variazione architetturale in roadmap.
Le Standard RI restano vincenti sui workloads ultra-stabili — data-tier, capacity reservation imposte dalla compliance e workloads con oltre 18 mesi di stabilità comprovata.
I Database Savings Plans (nuovi a dicembre 2025) sono una leva di flessibilità, non di sconto — 35% contro il 69% delle Standard RI. Li scelga per parchi database multi-engine, Gen 7+.
Sovrapponga i commitments — Compute SP come base, EC2 Instance SP per le family su cui ha fiducia, Standard RI per i database stabili, On-Demand per tutto il resto.
Non si impegni mai durante una migrazione attiva — prima stabilizzi, poi si impegni. Il costo dei commitments incagliati supera sempre il costo dell'attesa.
La strategia di commitment giusta non punta a massimizzare lo sconto: punta ad allineare il commitment alla direzione architetturale dell'azienda.
Vuole smettere di gestire tutto questo a mano? Prenoti una demo per scoprire come FlexSave ottimizza in automatico i suoi commitments AWS.
Dima Kramskoy è Senior Cloud Architect in DoiT International, con oltre 20 anni di esperienza in software engineering, 10 certificazioni AWS e il riconoscimento di AWS Community Builder (2026). È specializzato in FinOps e ottimizzazione dei costi cloud per organizzazioni enterprise.