Quanto commitment sui Savings Plans AWS è quello giusto? Il problema del dimensionamento e come smettere di tirare a indovinare

La risposta breve

Se da questo post vi portate via una sola cosa, che sia questa: fate commitment sulla vostra baseline stabile — il compute che è davvero acceso 24 ore su 24 — non sulla settimana media, e nemmeno sul picco. Trasformatela in una policy di copertura difendibile (quanta parte della spesa volete sotto commitment, più un tetto da non superare), poi aggiungete commitment a piccoli passi verso quell'obiettivo invece che con un unico grande acquisto.

Tutto quello che segue spiega perché questa è la risposta giusta, perché il processo abituale la rende difficile e come applicarla in modo continuo senza dover sorvegliare un foglio di calcolo.

Perché il "quanto" è davvero difficile

Partiamo dalle due parole che tutti usano come sinonimi e che sinonimi non sono: copertura e utilizzo.

• La copertura indica quanta parte della vostra spesa on-demand idonea è sotto commitment. Se spendete circa 80 $/ora in compute idoneo ai Savings Plans e 60 $/ora sono coperti, siete al 75% di copertura.
• L'utilizzo indica quanta parte del commitment acquistato viene effettivamente usata. Se vi impegnate per 70 $/ora e si presentano solo 60 $/ora di utilizzo corrispondente, siete a circa l'86% di utilizzo — e state comunque pagando la tariffa impegnata per il 14% rimasto inattivo.

Ed ecco la parte scomoda: queste due metriche si muovono in direzioni opposte quando provate a spingerle. Inseguite una copertura più alta e comprerete più commitment, rendendo più facile che l'utilizzo scivoli se la spesa cala. Proteggete l'utilizzo comprando con prudenza e la copertura — e con lei i risparmi — resterà bassa. Dimensionare un commitment significa scegliere dove posizionarsi su questa altalena. La maggior parte dei team non fa mai questa scelta in modo esplicito: si limita a reagire.

Poi ci sono le leve, ognuna delle quali cambia i conti:

Scelta	Opzioni	Il compromesso
Durata	1 anno vs. 3 anni	Il triennale aumenta lo sconto ma triplica il lock-in su cui state scommettendo.
Pagamento	No / Partial / All Upfront	Pagare di più in anticipo garantisce una tariffa leggermente migliore, ma immobilizza liquidità e alza la posta in caso di errore.
Tipo di piano	Compute SP vs. EC2 Instance SP	Il Compute SP (fino a ~66% di sconto) è flessibile su famiglia di istanze, dimensione, regione, OS, tenancy e perfino Fargate/Lambda. L'EC2 Instance SP (fino a ~72% di sconto) sconta un po' di più ma vi vincola a una famiglia di istanze in una regione. Di nuovo: flessibilità contro sconto.

Per capire quanto valgono queste scelte, guardate che effetto hanno sul prezzo di una singola istanza — la stessa c6a.8xlarge, una sola regione, prezzata sulle diverse durate e opzioni di pagamento del Compute Savings Plan (più l'on-demand):

Il divario è enorme: la stessa macchina passa da circa 1,22 $/ora on-demand a ~0,54 $/ora con un Compute Savings Plan triennale — un'oscillazione del ~56% decisa interamente da come comprate. E i delta non sono distribuiti in modo uniforme: passare da 1 a 3 anni quasi dimezza la tariffa, mentre la scelta dell'anticipo (No / Partial / All) la sposta solo di un paio di punti percentuali. La leva che sembra un dettaglio scritto in piccolo — la durata — è quella che sposta davvero i soldi.

Ognuna di queste scelte presuppone che sappiate come sarà il vostro workload per l'intera durata. Con un piano EC2 Instance triennale all-upfront non state dimensionando un commitment: state facendo una previsione sulla vostra architettura nel 2028. È questa la vera difficoltà. Il numero non è difficile da calcolare. È il futuro da cui dipende a essere difficile da conoscere.

Le cinque forze che continuano a spostare il bersaglio

Se il vostro utilizzo fosse una linea piatta, sarebbe un esercizio da foglio di calcolo. Non lo è mai. Cinque forze continuano a trascinare altrove il numero "giusto" dopo che vi siete impegnati.

1. L'utilizzo non è piatto. La spesa reale di compute oscilla di settimana in settimana: job batch, lanci, traffico stagionale, l'onboarding di un grande cliente. Un commitment dimensionato su una buona settimana diventa un commitment eccessivo in una settimana tranquilla. Dimensionate su una settimana intensa a 70 $/ora quando la vostra baseline stabile è in realtà di 60 $/ora, e appena le cose si calmano quei 10 $/ora in più sono commitment inattivo: circa 87.600 $ l'anno pagati per capacità che non state usando. Lo sconto che inseguivate è più piccolo dello spreco che avete creato.

2. Right-sizing e migrazioni riducono la baseline. È la forza che, in silenzio, immobilizza più denaro di tutte. Vi impegnate sull'utilizzo di oggi, poi il vostro team fa il suo lavoro: applica il right-sizing alle istanze sovradimensionate, sposta un servizio su Graviton, fa il refactoring di un monolite. Il vostro utilizzo scende, il vostro commitment no. Vi impegnate sulla baseline di 60 $/ora, poi il team migra a Graviton e la baseline si assesta a 50 $/ora. Da un giorno all'altro, quei ~10 $/ora di commitment restano senza utilizzo su cui atterrare — con circa due anni rimanenti su un piano triennale, all'incirca 175.000 $ immobilizzati. Avete fatto la cosa giusta dal punto di vista ingegneristico e siete stati puniti per questo. La mossa corretta è l'ordine inverso: prima il right-sizing, poi il commitment sullo stato stabile più snello. Non lo fa quasi nessuno, perché commitment e right-sizing vivono nei backlog di team diversi.

3. I commitments scadono, e le scadenze arrivano a grappoli. Un Savings Plan comprato un anno fa termina in un giorno preciso. Se ne avete comprati diversi tutti insieme, scadranno tutti insieme, e la vostra copertura crollerà da un giorno all'altro. Rinnovare significa rifare da capo tutto l'esercizio di dimensionamento, esattamente nel momento in cui è meno probabile che stiate guardando. Se ve lo perdete, tornate alle piene tariffe on-demand per la fetta scaduta.

4. Un target di copertura non è un risultato di utilizzo. Potete puntare all'80% di copertura e ritrovarvi comunque con un utilizzo scarso se la spesa cala dopo l'acquisto. I target si fissano sulla storia; l'utilizzo si realizza nel futuro. Il divario tra i due è puro spreco, e non lo vedete finché non arriva la fattura.

5. Il tempo stesso. Ogni giorno che aspettate per avere "abbastanza certezza" prima di impegnarvi è un giorno a tariffe on-demand. I team rimandano i commitments per mesi inseguendo una fiducia che non arriva mai, e lo sconto rimandato è perso per sempre. Come scriviamo nel post sugli errori nei commitment: anche durante migrazioni e periodi di incertezza, impegnare una parte batte non impegnare nulla.

Notate che nessuna di queste è una falla di pianificazione. È semplicemente la realtà. La vostra infrastruttura deve cambiare, è il suo mestiere. Il problema non è che il bersaglio si muove: è che la maggior parte dei processi di commitment è costruita come se non lo facesse.

Perché l'approccio manuale non regge

Ecco come avviene di solito il dimensionamento nella pratica.

Una volta al trimestre, qualcuno apre la raccomandazione di acquisto dei Savings Plans di AWS. AWS guarda indietro su una finestra — potete scegliere 7, 30 o fino a 60 giorni — e vi consegna un unico commitment orario suggerito, ottimizzato per il risparmio massimo. Qualcuno gli dà un'occhiata, magari lo riduce "per stare tranquilli", ottiene un'approvazione e compra.

In questo flusso ci sono tre problemi strutturali.

Primo: è un singolo numero ricavato da un singolo periodo di lookback. Le raccomandazioni a risparmio massimo assumono che il passato recente sia il vostro futuro e spingono in alto la copertura. Ottimo quando l'utilizzo è stabile; costoso nel momento in cui non lo è.

Secondo: è un acquisto big-bang. Prendete l'intera decisione di commitment del trimestre e la eseguite in un'unica transazione, in un solo giorno. Se quel giorno capita in cima a un picco di utilizzo, avete appena ancorato un anno di commitment a un picco.

Terzo: è già obsoleto. Quando la raccomandazione viene rivista, approvata e acquistata, sono passati giorni o settimane e l'utilizzo si è mosso. Non vi state impegnando sulla vostra realtà attuale: vi state impegnando su un'istantanea di una realtà che non c'è più.

Il problema più profondo è la cadenza. L'utilizzo cambia in continuazione; il processo manuale scatta ogni trimestre. State campionando un segnale in movimento quattro volte l'anno e agendo su ogni campione con settimane di ritardo. Nessun rigore da foglio di calcolo può risolvere un problema di frequenza di campionamento.

Un modello mentale migliore: dimensionare sulla baseline, poi arrivarci a scalini

La soluzione consiste in realtà in due lavori distinti, e dare loro un nome aiuta: il dimensionamento (scegliere il numero giusto) e il laddering (arrivarci in sicurezza). Due cambiamenti nel modo di pensare a ciascuno.

Primo cambiamento — dimensionamento: ancoratevi alla baseline stabile. Questo è il lavoro di scegliere il numero. Invece di chiedervi "qual è l'importo giusto in dollari", decidete quanta parte della spesa idonea volete coprire — ancorandovi alla baseline stabile, la parte che gira 24 ore su 24 — e lasciate che l'importo in dollari ne discenda. Trasforma una stima senza confini in una policy su cui potete ragionare:

• Conservativa (~65% di copertura). Proteggete l'utilizzo e mantenete flessibilità. Rinunciate deliberatamente a una parte del risparmio. Adatta a utilizzi volatili o in rapido cambiamento.
• Bilanciata (~80% di copertura). Il default per la maggior parte dei workloads di produzione stabili: risparmi significativi con un buffer comodo contro i cali.
• Aggressiva (~90% di copertura). Massimo risparmio, buffer minimo. Appropriata solo quando la baseline è davvero stabile e prevedibile.

Perché non scegliere sempre l'aggressiva? Perché la copertura ha rendimenti decrescenti, e l'ultima fetta è quella pericolosa. La base del vostro utilizzo — la parte accesa 24/7/365 — è la più sicura da coprire, e lì lo sconto è praticamente denaro regalato. Man mano che spingete la copertura più in alto, iniziate a impegnarvi sulla parte variabile in cima al vostro utilizzo: le ore che esistono solo durante i picchi. Quella spesa marginale è esattamente la spesa che ha più probabilità di sparire, il che significa che la copertura aggiunta oltre l'~80% porta con sé la maggior parte del rischio di commitment eccessivo aggiungendo i risparmi meno affidabili. L'approccio giusto non è "coprire tutto". È "coprire in modo aggressivo la base stabile e con cautela la parte alta e volatile".

Secondo cambiamento — laddering: arrivateci a piccoli passi. Questo è un lavoro diverso: non quanto impegnare, ma come arrivarci. Invece di un unico grande acquisto, spezzate la distanza dal vostro target in una serie di piccoli commitments scaglionati nel tempo. Il laddering risolve in un colpo solo diverse delle cinque forze:

• Passi piccoli e frequenti significano che nessun singolo acquisto si ancora a un picco. State mediando l'ingresso nel vostro commitment come fareste con un piano di accumulo su una posizione.
• Date di inizio scaglionate significano scadenze scaglionate: nessun crollo al rinnovo, perché i piani arrivano a scadenza pochi alla volta invece che tutti insieme.
• Impegnarsi gradualmente significa poter fermarsi o rallentare nel momento in cui la spesa cala, invece di scoprire il commitment eccessivo un anno dopo, dentro un contratto bloccato.

Ma tenete i due lavori separati. Il laddering gestisce il timing — la concentrazione degli acquisti e i crolli alle scadenze — non il dimensionamento. Non può salvare un target troppo aggressivo: fate laddering lentamente verso il numero sbagliato e finirete comunque sovraesposti, solo qualche settimana più tardi. Prima azzeccate la baseline; poi fate laddering verso di essa.

Il punto critico: dimensionare su una baseline in movimento, ricontrollare la copertura ogni settimana, correggere per le scadenze e mettere in pausa nei cali è un lavoro genuinamente continuo. Fatto a mano, è un ruolo part-time che nessuno ha. È esattamente il vuoto che l'automazione è nata per colmare.