Lo sconto che non stavamo incassando: perché Spot e Graviton costano meno

La fattura AWS ha superato il budget per due mesi di fila. Lo sforamento rispetto al tetto fissato era di una percentuale a una sola cifra: non enorme in termini assoluti, ma la direzione era quella sbagliata. Ho passato in rassegna le risorse una per una, cercando cosa tagliare, e la conclusione è stata inaspettata: c'era ben poco da ridurre. La vera leva non stava in "quanto" si usa, ma in "come" lo si compra. Quello che ho imparato lungo il percorso è che ogni cifra della fattura ha una ragione, e solo capendo quella ragione si può decidere cosa spegnere e cosa lasciare.

Le risorse erano già ottimizzate

Ho iniziato guardando i volumi di utilizzo. Ma qui il lavoro era già stato fatto: niente NAT gateway, architettura basata su subnet pubbliche, log conservati solo 7 giorni, tracing campionato all'1%, dashboard di osservabilità compressa dentro i limiti gratuiti. Il DB e Redis giravano già su istanze ARM più economiche, S3 aveva il tiering automatico, e il bastion veniva acceso solo all'occorrenza. A livello di risorse, c'era ormai poco altro da spremere.

Scomponendo la fattura di giugno per voce: la parte più grande era il DB (RDS), da solo circa il 40% del totale; seguiva il compute (ECS Fargate) con circa il 17%; load balancer e WAF pesavano ciascuno circa il 10%; IP pubblico, cache (ElastiCache) e S3 chiudevano con percentuali singole a coda. Ridurre ulteriormente le istanze qui sarebbe stato un passo indietro: il DB aveva già una storia di upgrade per carenza di memoria, e il WAF era lì di proposito per validare le regole prima dei deploy in produzione. La leva rimasta non era la risorsa, ma il modo di pagarla: usare le stesse risorse, ma comprarle a un prezzo più basso.

Perché Spot costa meno

La prima cosa che ho notato è stata che il compute veniva acquistato solo al prezzo pieno on-demand. AWS però ha un canale che vende lo stesso server molto più a buon mercato: Fargate Spot, circa il 70% più economico rispetto all'on-demand.

Questo prezzo basso ha una ragione precisa. AWS costruisce i propri data center dimensionati sul picco di domanda. Nei momenti normali, quindi, restano server inutilizzati. Lasciare quella capacità in eccesso a fare nulla significa zero ricavi, quindi AWS la vende a prezzo stracciato con una condizione: "se arriva un cliente a prezzo pieno, liberi il posto entro 2 minuti". È lo stesso principio delle compagnie aeree che svendono i posti vuoti poco prima della partenza: se l'aereo parte comunque con quei posti vuoti il ricavo è zero, quindi conviene venderli anche a condizioni svantaggiose pur di incassare qualcosa.

Il punto è se si può sostenere quella condizione: "se ti viene chiesto di liberare il posto, lo liberi". In produzione è un problema: se ci sono utenti collegati e il task viene revocato dopo 2 minuti, il servizio vacilla anche solo per un istante. Ma staging è diverso: non ci sono utenti reali, e qualche minuto di down disturba al massimo un tester QA per poco. Per questo ho spostato le API di staging su Spot. Le prestazioni sono identiche all'on-demand, perché vCPU e memoria girano sullo stesso hardware. L'unica cosa che cambia è la condizione di disponibilità - "può essere revocato" - ed è una condizione che staging è ben felice di accettare. Dopo l'attivazione, i task di staging hanno iniziato a girare regolarmente su Spot.

Perché Graviton costa meno

Il secondo punto riguardava il chip del compute. DB e Redis usavano già istanze ARM, ma proprio il Fargate che fa girare l'applicazione era rimasto su x86. Passando a Graviton, il chip ARM progettato internamente da AWS, si ottengono le stesse prestazioni a circa il 20% in meno.

La ragione di questo prezzo più basso è diversa da quella di Spot. Le istanze normali usano CPU che AWS acquista da Intel o AMD, quindi nel prezzo che paghiamo è incorporato il margine del produttore del chip. Graviton, invece, è un chip progettato direttamente da AWS: quel margine intermedio non esiste. In più, l'architettura ARM consuma meno energia e genera meno calore a parità di calcolo, quindi anche i costi di elettricità e raffreddamento del data center sono inferiori. Per AWS il costo di base è più basso, quindi vendere a -20% resta comunque redditizio, ed è anche una strategia per attirare i clienti nel proprio ecosistema di chip vendendo a prezzo scontato.

Qui c'è una differenza importante. Lo sconto di Spot porta con sé la condizione "accetta di poter essere revocato", mentre lo sconto di Graviton non ha alcuna condizione: è semplicemente un chip più economico. Per questo Spot si può usare solo in staging, mentre Graviton si applica tale e quale fino alla produzione. Anche sulle prestazioni non c'è molto di cui preoccuparsi: Node.js su Graviton ha prestazioni per vCPU pari o addirittura migliori rispetto a x86. L'unico punto da osservare è il cold start: all'avvio dell'app conta la velocità del singolo core, e qui Graviton può essere leggermente più lento dei più recenti x86, allungando l'avvio di qualche secondo. Ho quindi misurato prima i tempi di avvio in staging e solo dopo promosso in produzione. L'unico controllo preliminare necessario è verificare che i moduli nativi siano compilati per arm64.

Riassumendo la natura dei due sconti: quello di Spot è uno sconto ricevuto in cambio di accettare un disagio, quindi porta una condizione (da qui staging); quello di Graviton è uno sconto che condivide il vantaggio di costo del chip proprietario di AWS, quindi non ha condizioni (da qui fino alla produzione). Con prestazioni identiche, non c'era motivo di restare al prezzo pieno del più costoso x86. In realtà, più che aver risparmiato qualcosa di nuovo, questa ottimizzazione è stata soprattutto iniziare finalmente a incassare uno sconto che non stavamo prendendo.

Ci sono anche costi che non vanno spenti

Scorrendo la fattura, però, si trova anche la trappola opposta: voci che sembrano sprechi ma sono in realtà un'assicurazione.

È il caso di RDS Proxy. Aveva un costo mensile fisso, e all'inizio sembrava un candidato per il taglio: una delle sue funzioni è gestire senza interruzioni la rotazione automatica dei secret, ma quella rotazione era spenta. Mi sono chiesto perché tenere il Proxy se la rotazione non veniva usata.

Era una lettura sbagliata. Lo scopo primario del Proxy non è la rotazione, ma prevenire i picchi di connessione. Quando un deploy o uno scale-out fa salire di colpo il numero di task, le connessioni verso il DB aumentano bruscamente, ma il DB ha un tetto massimo di connessioni simultanee. Il Proxy sta davanti a tutto questo, raggruppando e moltiplexando le connessioni per non superare quel tetto. E guarda caso proprio questo DB era un'istanza già scalata una volta per carenza di memoria, dove ogni singola connessione consuma memoria. In altre parole, quel costo fisso non era uno spreco, ma il premio assicurativo che impedisce al DB di crollare per un'ondata di connessioni a ogni deploy. Spegnerlo non avrebbe fatto risparmiare nulla: avrebbe solo tolto la protezione.

La causa dell'equivoco era un commento nel codice. Il commento che descriveva quel Proxy era scritto quasi solo dal punto di vista della rotazione, ed era facile fraintendere: "la rotazione è spenta, quindi anche il Proxy è superfluo". Così, invece di togliere il Proxy dal piano di riduzione, ho aggiunto una riga al commento: "lo scopo principale è contenere i picchi di connessione, la rotazione è una funzione secondaria". Perché la prossima persona che guarda la fattura non commetta lo stesso errore di valutazione.

Ogni cifra della fattura ha una ragione

Quando ci viene chiesto di ridurre i costi cloud, la mano corre subito a "cosa spegnere": rimpicciolire le istanze, disattivare funzionalità, cancellare risorse. Ma questa volta ho imparato il contrario: prima di ridurre, la domanda da porsi è "perché questa cifra è qui".

Certe cifre sono uno sconto non incassato: come Spot e Graviton, esiste un canale per comprare la stessa risorsa a un prezzo più basso, ma la si stava semplicemente pagando a prezzo pieno. Ogni sconto di questo tipo ha una ragione precisa per cui costa meno, e conoscerla (se è in cambio di accettare una revoca, o se è un vantaggio di costo senza condizioni) permette di stabilire dove applicarlo in sicurezza. Altre cifre, al contrario, sono un'assicurazione che non va spenta. Anche se sembra uno spreco, se sta prevenendo un incidente, quella voce non è una spesa: è una difesa.

Alla fine, leggere una fattura non significa rendere le cifre più piccole, ma capire la ragione di ciascuna. Capita la ragione, si incassano gli sconti la cui condizione si può sostenere, e si lasciano intatti i costi che prevengono incidenti. Tutto quello che abbiamo fatto è stato proprio questo: non risparmiare qualcosa di nuovo, ma distinguere lo sconto da incassare dall'assicurazione da mantenere.