Sette segnali poco evidenti nella bolletta cloud che possono nascondere un anti-pattern o spese eccessive, e come intervenire per correggerli.
Quando si parla di ottimizzare i costi del cloud, a volte occorre saper leggere tra le righe della bolletta.
Spesso ci si concentra sui picchi di spesa più evidenti, ma cosa dire dei segnali più sottili e meno appariscenti che si nascondono dietro ai numeri?
In una recente puntata del podcast Cloud Masters, abbiamo riunito tre Technical Account Manager (TAM) di DoiT per scoprire sette campanelli d'allarme poco evidenti che hanno individuato presso i loro clienti, discutendo come intervenire al loro posto.
Non parliamo dei classici picchi di spesa "sotto gli occhi di tutti"; sono piuttosto indizi sottili che qualcosa potrebbe non funzionare come dovrebbe, segnalando potenziali sprechi o pratiche poco efficienti.
Guardi l'episodio completo qui sotto, oppure prosegua nella lettura mentre analizziamo questi segnali e le offriamo consigli pratici per ciascuno.
Campanello d'allarme #1: sta pagando per AWS CloudTrail
Se si trova a pagare per CloudTrail in qualsiasi misura, ha un'opportunità per risparmiare sulla bolletta cloud. Il primo trail di CloudTrail in una regione è gratuito, e l'unico trail dovrebbe essere a livello di AWS Organization, perché i trail di Organization vengono creati automaticamente in tutti gli account membri.
Tenga presente che il nuovo trail viene creato in aggiunta a qualsiasi trail già esistente negli account membri. Pertanto, se in passato ha creato trail separati negli account membri, ha l'opportunità di risparmiare rimuovendoli.
Creare il trail di CloudTrail a livello di Organization la aiuterà ad applicare in modo uniforme la sua strategia di event logging su tutti gli account dell'organizzazione, perché la configurazione del trail di Organization si propaga a tutti gli account. Di conseguenza, dovrebbe verificare che la configurazione del trail di Organization rispecchi il modo in cui desidera siano configurati i trail di tutti gli account che ne fanno parte.
Campanello d'allarme #2: i costi di storage crescono costantemente per la mancanza di policy di lifecycle dei dati
Se nota che i costi di cloud storage aumentano costantemente nel tempo, potrebbe essere il segnale che non ha applicato le opportune policy di lifecycle degli oggetti.
Le policy di lifecycle degli oggetti automatizzano il passaggio dei dati a classi di storage diverse, oppure ne gestiscono l'eliminazione in base a regole predefinite, allineando il costo dello storage al valore e all'accessibilità dei dati. In questo modo si evita di pagare più del dovuto per archiviare dati che non richiedono accesso immediato o ormai obsoleti.
Senza policy di lifecycle, finirà per accumulare dati, log in continua crescita e/o snapshot in eccesso. Di conseguenza, i costi di storage tenderanno a salire, soprattutto se i dati più vecchi o consultati di rado restano in classi di storage costose.
Nella maggior parte dei casi è sufficiente trasferire o far scadere gli oggetti dopo 30-90 giorni. Ma il segnale rivelatore che vale la pena guardare lo storage più da vicino è proprio una curva dei costi in salita.
Campanello d'allarme #3: i costi delle API GetMetricData di CloudWatch sono elevati
Servizi di terze parti come New Relic e Datadog effettuano scansioni regolari dei suoi account cloud — tipicamente delle metriche di CloudWatch — per ottenere informazioni aggiornate sull'utilizzo.
Tuttavia, in molti non si rendono conto che si pagano anche le richieste API che questi servizi effettuano. Tali richieste vengono registrate in CloudWatch nello SKU API " GetMetricData". Senza la dovuta attenzione, finirà per pagare cifre considerevoli per CloudWatch a causa di queste chiamate GetMetricData provenienti dal software di terze parti.
Di conseguenza, occorre prestare attenzione a:
- la frequenza di queste chiamate API;
- quali metriche e quali dati vengono scansionati.
Per esempio, potrebbe avere un account di sviluppo con molte risorse su cui sta spendendo cifre importanti in CloudWatch perché le chiamate API vengono effettuate ogni minuto. In casi come questo, dovrebbe chiedersi se la frequenza — e magari la granularità dei dati — sia davvero necessaria.
Per ridurre i costi di CloudWatch generati da queste chiamate API, in molti casi è sufficiente chiedere ai servizi di terze parti di rivedere la frequenza e le metriche raccolte per specifici account/progetti.
Campanello d'allarme #4: i costi di logging superano il 20% della bolletta cloud
Sebbene il logging sia essenziale per il monitoraggio e il troubleshooting, un logging eccessivo può far lievitare la bolletta cloud.
Come per il consiglio dato sulle chiamate API nel campanello precedente, dovrebbe chiedersi se la frequenza e le metriche raccolte dal logging siano adatte al caso d'uso. Per esempio, se sta alimentando una dashboard con dati provenienti dai log, non servono per forza aggiornamenti al secondo: un aggiornamento ogni cinque minuti può bastare.
Come regola generale, non dovrebbe spendere più del 20% della bolletta cloud in logging. Se supera questa soglia, è il segnale che dovrebbe esaminare più da vicino la composizione di questi costi. Chieda ai vari team che utilizzano i log a cosa servono: potrà così individuare dove ridurre la frequenza o quali metriche di logging tagliare.
Inoltre, presti particolare attenzione al logging negli ambienti non di produzione, che non sono necessariamente quelli che generano ricavi. Difficilmente avrà bisogno della stessa frequenza o delle stesse metriche degli account di produzione. Se qualcosa si rompe in un ambiente non di produzione, può semplicemente attivare e disattivare i log al volo, a differenza della produzione, dove servono più informazioni per capire cosa sia andato storto.
Campanello d'allarme #5: non sta facendo cross-check delle decisioni
Sebbene questo campanello d'allarme non sia una voce specifica che può individuare in bolletta o in un cost and usage report, la mancata verifica incrociata delle decisioni tecnologiche e di design può tradursi a cascata in problemi di bolletta cloud e di performance lungo la strada.
Un esempio molto comune è quando un team acquista uno sconto su commitment (es. Savings Plan) in modo isolato, senza tenere conto della strategia organizzativa più ampia o delle esigenze degli altri team. Il dipartimento tecnico potrebbe voler passare al serverless nei prossimi due anni, ma all'improvviso qualcuno acquista un Savings Plan triennale, vincolando tutti all'uso delle VM.
Non esiste una decisione "oggettivamente giusta" quando si costruisce nel cloud. Prendere decisioni cloud in modo isolato può portare a inefficienze e costi maggiori. Si chieda come stia verificando internamente con i colleghi e/o con altri team la solidità delle sue scelte. In termini più concreti, ciò può significare convalidare le decisioni di infrastruttura cloud rispetto alla strategia e alla visione di engineering, oppure rispetto ai relativi documenti RFC/ ADR.
Campanello d'allarme #6: non sta limitando regioni e tipologie di istanze con le organizational policy
Le organizational policy (vedi documentazione di Google Cloud; AWS) le consentono di definire come gli utenti del cloud possono accedere, utilizzare e gestire le risorse cloud aziendali.
In ottica di ottimizzazione dei costi (e di sicurezza), sono particolarmente utili per assicurarsi che nessuno avvii servizi dove non dovrebbe.
Nello specifico, senza organizational policy che limitino tipi di istanze e regioni, esporrà la sua infrastruttura cloud a vulnerabilità di sicurezza e a rischi di overspending. Soggetti malintenzionati possono sfruttare questa mancanza di controllo per avviare istanze in regioni inutilizzate, sfuggendo ai controlli e portando avanti le proprie attività malevole.
Limiti i tipi di istanze e le regioni a quelli che effettivamente utilizza, in modo che nessuno — per dolo o per errore — possa avviare, ad esempio, un'istanza x1 al posto di una t4 in Sud America quando tutte le sue risorse si trovano in Europa.
Implementando le org policy potrà proteggere efficacemente l'ambiente cloud e ottimizzare l'utilizzo delle risorse.
Campanello d'allarme #7: chiamate API in eccesso verso gli storage bucket
Chiamate API frequenti e non necessarie agli storage bucket possono far lievitare i costi di storage e incidere sulle performance. Questo segnale si manifesta in molte situazioni diverse.
Le sue applicazioni potrebbero effettuare chiamate API frequenti ai bucket di cloud storage. Ciò può rivelarsi particolarmente problematico per applicazioni che generano grandi volumi di dati o che effettuano trasferimenti frequenti. Oppure potrebbe trattarsi di un processo schedulato che interagisce con i bucket, accumulando nel tempo un numero rilevante di chiamate API.
Oltre alle ragioni di costo, consideri che chiamate API frequenti incidono anche sulle performance applicative, causando rallentamenti, timeout e persino interruzioni di servizio.
Senza un monitoraggio adeguato, è facile spendere troppo senza che scatti alcun allarme, fino all'arrivo della bolletta o al raggiungimento del limite di una service quota.
Per questo dovrebbe rivedere e ottimizzare il codice applicativo per ridurre al minimo il numero di chiamate API necessarie per ciascuna operazione. Implementi inoltre meccanismi di caching per tenere in memoria i dati consultati di frequente e ridurre la necessità di chiamate API ripetute agli storage bucket.
Porre le domande giuste alla bolletta cloud
Per quanto possiamo fornirle un elenco di campanelli d'allarme da osservare, gli aspetti a cui prestare attenzione sono potenzialmente infiniti. Per questo, nel lungo periodo, è fondamentale coltivare la curiosità rispetto alla propria spesa cloud. Non si limiti ad accettare l'importo della bolletta. Si chieda il perché, e poi se lo chieda di nuovo.
Per esempio, se i costi di S3 stanno aumentando, individui quali bucket stiano trainando la crescita. Poi verifichi quali SKU siano responsabili dell'incremento dei costi in quei bucket. E quando scopre che si tratta di costi di trasferimento dati, si chieda — e chieda al suo team — se quell'aumento per quei bucket fosse atteso o meno. Forse i costi sono saliti per un buon motivo, ma non lo saprà finché non se lo chiederà.
Nel tempo, tutto questo contribuisce a costruire una cultura dell'ottimizzazione dei costi in tutta l'azienda, in cui ognuno è consapevole del proprio contributo alla bolletta cloud e si sente legittimato ad agire.
Ognuno di questi campanelli d'allarme sottolinea l'importanza della responsabilità condivisa e della curiosità verso la propria bolletta cloud. Ricordi: individuare queste opportunità di ottimizzazione non dovrebbe ricadere solo sulle spalle dell'Head of Infrastructure o del FinOps Lead. È un percorso che funziona grazie al lavoro di squadra.