Le mie fatture Cloud sono troppo elevate: ciò che vedo ora

Ciao a tutti, Jules Martin qui, di nuovo su agntmax.com!

Oggi voglio parlare di qualcosa che mi preoccupa, e probabilmente preoccupa molti di voi, da circa un anno: l’aumento costante dei costi dell’infrastruttura cloud, in particolare per quanto riguarda le funzioni senza server. Siamo stati tutti attratti dal sogno del “paga per ciò che utilizzi”, e per molto tempo, sembrava essere una realtà. Ma ultimamente, ho visto le fatture salire, a volte in modo incomprensibile, anche quando i modelli di traffico sembravano stabili. È come se fossimo stati erosi dalla stessa flessibilità che abbiamo adottato. Quindi, esploriamo qualcosa di molto specifico e attuale: Dominare il Mostro Senza Server: Scoprire e Ridurre i Costi Nascosti di AWS Lambda.

Il mio percorso in questo campo è iniziato circa sei mesi fa. Abbiamo un microservizio centrale che gestisce l’autenticazione degli utenti e la gestione delle sessioni. È quasi interamente costruito su AWS Lambda, API Gateway, DynamoDB e Cognito. Per lungo tempo, i costi erano perfettamente prevedibili. Poi, l’estate scorsa, la nostra fattura AWS per questo servizio specifico è aumentata di circa il 15%. Nessuna nuova funzionalità, nessun picco di traffico significativo. All’inizio ho attribuito questo a una fluttuazione stagionale o a un piccolo bug che non avevo ancora scoperto. Ma quando la fattura del mese successivo è arrivata ancora più alta, ho capito che dovevo indagare. Non era solo un incidente isolato; era una tendenza, e ci costava davvero dei soldi.

L’Illusione dei Livelli “Gratuiti” e la Realtà delle Invocazioni “Minime”

Uno dei principali punti di vendita delle soluzioni senza server, soprattutto per le startup o i piccoli team, è il generoso livello gratuito. Ed è generoso! Un milione di invocazioni gratuite al mese per Lambda, oltre a una quantità significativa di tempo di calcolo. Il problema è che, man mano che la tua applicazione cresce, queste invocazioni “gratuite” scompaiono più velocemente di una fetta di pizza a un meetup tech. Ciò che spesso viene trascurato sono il volume considerevole di invocazioni minime, apparentemente insignificanti, che si accumulano. Pensa ai compiti cron, ai controlli di salute interni o persino ai meccanismi di ripetizione di altri servizi. Ognuna di queste invocazioni conta.

La mia indagine sul nostro servizio di autenticazione ha rivelato esattamente ciò. Avevamo una funzione Lambda, chiamiamola auth-token-refresher, progettata per aggiornare periodicamente i token di servizio interni. Era programmata per essere eseguita ogni cinque minuti. Sembra innocua, vero? 288 invocazioni al giorno. Moltiplica per 30 giorni e ottieni 8.640 invocazioni al mese. Aggiungi i nostri ambienti di sviluppo, staging e produzione, e all’improvviso diventano più di 25.000 invocazioni solo per un piccolo compito di manutenzione. Avevamo una dozzina di tali funzioni. All’improvviso, le nostre invocazioni “minime” non erano più così minime.

Trovare i Colpevoli: Le Metriche CloudWatch sono i Vostri Migliori Amici

Il primo passo per domare questa bestia è sapere dove va il tuo denaro. AWS CloudWatch è essenziale qui. Non limitarti a guardare il dashboard di fatturazione a un livello alto; esplora le metriche specifiche per le tue funzioni Lambda.

Ecco su cosa mi sono concentrato:

1. Invocazioni: Questa è la metrica più semplice. Contatori di invocazioni elevati per funzioni che non gestiscono traffico utente diretto sono segnali di allerta immediati.
2. Durata: Quanto tempo impiega ogni invocazione? Durate più lunghe significano costi di calcolo più elevati.
3. Utilizzo della Memoria: Hai sovraprovisionato memoria per le tue funzioni? Paghi per ciò che allochi, non per ciò che utilizzi.
4. Tasso di Errore: Tassi di errore elevati possono portare a ripetizioni, il che significa più invocazioni e cicli di calcolo sprecati.

Per il nostro auth-token-refresher, ho esaminato la sua metrica `Invocazioni`. In effetti, funzionava come un orologio, ogni cinque minuti. La durata era minima, solo circa 50 ms. Ma il volume considerevole contribuiva al nostro costo totale di invocazione.

Esempio Pratico 1: Consolidare e Pianificare in Modo più Intelligente

La soluzione per auth-token-refresher e diverse altre funzioni di manutenzione simili era sorprendentemente semplice: la consolidazione. Invece di avere funzioni Lambda individuali attivate da eventi CloudWatch (o EventBridge al giorno d’oggi) a orari separati, ho creato un’unica funzione Lambda chiamata “Maintenance Runner”.

Questo “Maintenance Runner” è attivato da una sola regola di evento CloudWatch, diciamo, una volta all’ora. All’interno di questo runner, ho un semplice dispatch che verifica l’ora corrente ed esegue i compiti necessari. Per esempio:

import os
import datetime

def lambda_handler(event, context):
 current_hour = datetime.datetime.now().hour
 current_minute = datetime.datetime.now().minute

 # Compito 1: Aggiornare il token di autenticazione (eseguito ogni 5 minuti)
 if current_minute % 10 == 0: # Eseguire ora ogni 10 minuti
 print("Esecuzione dell'aggiornamento del token di autenticazione...")
 # Chiamare la logica reale per aggiornare il token o un'altra funzione interna
 refresh_auth_token()

 # Compito 2: Pulire i vecchi log (eseguito ogni ora)
 if current_hour % 1 == 0 and current_minute == 0: # Eseguire all'inizio dell'ora
 print("Esecuzione della pulizia dei log...")
 cleanup_old_logs()

 # Compito 3: Verificare lo stato del servizio esterno (eseguito ogni 30 minuti)
 if current_minute == 0 or current_minute == 30:
 print("Verifica dello stato del servizio esterno...")
 check_external_service()

 return {
 'statusCode': 200,
 'body': 'Compiti di manutenzione eseguiti.'
 }

def refresh_auth_token():
 # ... logica reale per l'aggiornamento del token ...
 pass

def cleanup_old_logs():
 # ... logica reale per la pulizia dei log ...
 pass

def check_external_service():
 # ... logica reale per la verifica del servizio esterno ...
 pass

Questo semplice cambiamento ha immediatamente ridotto il numero di invocazioni per questi compiti di manutenzione da centinaia di migliaia al mese a qualche migliaio. I risparmi erano tangibili, non solo in termini di invocazioni Lambda, ma anche riguardo all’ingestione dei log CloudWatch e alle chiamate a API Gateway (se una di queste chiamate era esposta tramite API Gateway).

Il Trucco della Sovrapprovisionamento della Memoria

Questo rappresenta un altro fattore di costo sottile che viene spesso trascurato. Quando crei una funzione Lambda, allochi una certa quantità di memoria (ad esempio, 128MB, 256MB, 512MB). Paghi per questa memoria allocata, indipendentemente da quanto la tua funzione utilizzi realmente. Inoltre, la potenza della CPU aumenta proporzionalmente all’allocazione di memoria. Quindi, se allochi 1GB di memoria per un semplice script Python che ha bisogno solo di 128MB, non stai solo pagando troppo per la memoria; stai anche pagando troppo per i cicli di CPU di cui non ha bisogno.

Ho imparato questa lezione a mie spese con una funzione Lambda di elaborazione dei dati che era inizialmente configurata con 1GB di memoria “giusto per sicurezza”. Quando ho controllato le sue metriche CloudWatch per l’utilizzo della memoria, rimaneva costantemente al di sotto di 200MB, anche durante i picchi di carico. Fondamentalmente stavamo pagando per 800MB di RAM inutilizzata e l’aumento corrispondente della CPU.

Esempio Pratico 2: Ottimizzare l’Allocazione della Memoria con Lambda Power Tuning

Determinare manualmente l’impostazione di memoria ottimale può essere noioso. Devi distribuire, testare, monitorare, modificare e ripetere. Fortunatamente, esiste un ottimo strumento open source chiamato AWS Lambda Power Tuning (sviluppato da Alex Casalboni presso AWS) che facilita questo processo.

Si tratta di un’applicazione senza server che ti aiuta a visualizzare e identificare l’impostazione di memoria ottimale per le tue funzioni Lambda in base ai costi e alle prestazioni. La distribuisci sul tuo account AWS e poi puoi usarla per testare le tue funzioni.

Ecco come funziona generalmente:

1. Distribuisci lo strumento Power Tuning tramite il Serverless Application Repository o SAM.
2. Invoca una macchina a stati (creata dallo strumento) con l’ARN della tua funzione Lambda e un payload.
3. La macchina a stati invoca la tua Lambda più volte con diverse configurazioni di memoria (ad esempio, 128MB, 256MB, 512MB, 1024MB, ecc.).
4. Analizza quindi i log di esecuzione e fornisce una visualizzazione che mostra i compromessi tra costi e velocità per ciascuna impostazione di memoria.

Per la mia funzione Lambda di elaborazione dei dati, il test con il Power Tuner ha mostrato che 256 MB era un compromesso ideale per il costo, con una degradazione delle prestazioni trascurabile rispetto a 1 GB. Abbiamo subito ridotto l’allocazione di memoria a 256 MB, il che ha portato a una riduzione del 75% dei costi di calcolo per questa funzione specifica. Non è stata una soluzione una tantum; da allora ho assicurato che diventasse una prassi standard far passare nuove funzioni o quelle rivalutate tramite questo strumento.

Per utilizzarlo, dopo il deployment, normalmente avviereste la macchina a stati con qualcosa di simile (regolando l’ARN e il payload):

aws stepfunctions start-execution \
 --state-machine-arn "arn:aws:states:REGION:ACCOUNT_ID:stateMachine:powerTuningStateMachine" \
 --input '{ "lambdaARN": "arn:aws:lambda:REGION:ACCOUNT_ID:function:YOUR_FUNCTION_NAME", "num": 100, "payload": {}, "parallel": 5 }'

L’output fornisce un grafico chiaro, mostrando esattamente dove i vostri costi e la vostra velocità si intersecano per prestazioni ottimali. È un cambiamento significativo per l’ottimizzazione dei costi.

La Verbosità dei Log e i Démarrages a Froid

Due ulteriori aree che spesso sorprendono sono la verbosità dei log e i démarrages a froid. I log di CloudWatch non sono gratuiti. Ogni riga stampata dalla vostra funzione Lambda viene registrata e archiviata, e voi pagate per questo. Anche se un buon log è cruciale per il debug, una registrazione eccessivamente verbosa (ad esempio, stampare oggetti interi o ripetere inutilmente messaggi di stato) può rapidamente gonfiare la vostra fattura per i log di CloudWatch.

Ho trovato alcune funzioni che registravano il corpo completo della richiesta HTTP ad ogni invocazione. Sebbene ciò fosse utile per lo sviluppo iniziale, in produzione si rivelava solo rumore e costo. Un rapido aggiustamento per registrare solo i metadati essenziali (ID della richiesta, codice di stato, endpoint) ha ridotto notevolmente la nostra registrazione dei log.

I démarrages a froid, anche se non sono un “costo” diretto allo stesso modo, impattano l’esperienza utente e possono indirettamente portare a più tentativi o a lunghezze di fatturazione più elevate se la vostra funzione deve attendere risorse. Sebbene AWS abbia fatto progressi significativi nel ridurre i tempi di démarrage a froid, ottimizzare la dimensione del pacchetto della vostra funzione e evitare una logica di inizializzazione complessa al di fuori del gestore può ancora fare la differenza. Per le funzioni critiche sensibili alla latenza, la concorrenza provisionata è un’opzione, ma sappiate che pagate per questa concorrenza assegnata anche quando è inattiva.

Esempio Pratico 3: Registrazione Intelligente e Variabili d’Ambiente

Per la registrazione, la soluzione più semplice è spesso la migliore. Utilizzate variabili d’ambiente per controllare i livelli di registrazione. In Python, ad esempio, potete fare così:

import os
import logging

LOG_LEVEL = os.environ.get('LOG_LEVEL', 'INFO').upper()
logging.basicConfig(level=LOG_LEVEL)
logger = logging.getLogger()

def lambda_handler(event, context):
 logger.debug("Questo è un messaggio di debug, visibile solo se LOG_LEVEL è DEBUG")
 logger.info("Elaborazione dell'evento: %s", event.get('request_id'))
 try:
 # ... logica della funzione ...
 logger.debug("Finiti di elaborare per request_id: %s", event.get('request_id'))
 return {
 'statusCode': 200,
 'body': 'Successo'
 }
 except Exception as e:
 logger.error("Errore durante l'elaborazione di request_id %s: %s", event.get('request_id'), str(e), exc_info=True)
 return {
 'statusCode': 500,
 'body': 'Errore'
 }

Impostando LOG_LEVEL su INFO in produzione e DEBUG in sviluppo/staging, potete ridurre notevolmente la vostra fattura per i log di CloudWatch senza sacrificare l’osservabilità quando ne avete bisogno.

Un altro consiglio è prestare attenzione a ciò che viene inizializzato al di fuori del gestore. Qualsiasi codice direttamente nello scope globale della vostra funzione Lambda verrà eseguito durante il démarrage a froid. Se avete operazioni costose come il pooling di connessioni al database o import di grandi librerie, considerate di differirle fino a quando non sono realmente necessarie nel gestore, o assicuratevi che siano messe in cache in modo efficiente per le invocazioni calde successive.

Azioni Concreti per la Vostra Crociata di Costi Serverless

Va bene, abbiamo coperto molte cose. Ecco un riepilogo delle azioni pratiche che potete intraprendere subito per iniziare a ridurre questi insidiosi costi Lambda:

• Monitora senza sosta: Non limitatevi a dare un’occhiata alla vostra fattura AWS globale. Esplorate le metriche di CloudWatch per le Invocazioni, la Durata e l’Utilizzo della Memoria per ogni funzione Lambda. Configurate allarmi per picchi inattesi.
• Consolida i lavori cron: Se avete molte piccole funzioni Lambda programmate, considerate di raggrupparle in un unico “Mantenitore” che distribuisce i compiti su un orario meno frequente. Questo riduce notevolmente il numero di invocazioni.
• Ottimizza l’allocazione di memoria: Utilizzate strumenti come AWS Lambda Power Tuning per trovare l’impostazione di memoria ottimale per le vostre funzioni. Non limitatevi a indovinare e sovraprovvedere. Ricordate che più memoria significa più CPU, e pagate per entrambe.
• Controlla la verbosità dei log: Implementate livelli di registrazione guidati da variabili d’ambiente (ad esempio, INFO per la produzione, DEBUG per lo sviluppo). Evitate di registrare l’intero corpo delle richieste o uno stato interno eccessivo in produzione. La vostra fattura per i log di CloudWatch ve ne sarà grata.
• Esaminare le funzioni inutilizzate: Audit periodicamentente le vostre funzioni Lambda. Ci sono vecchie funzioni, sperimentali o obsolete, attive che generano costi? Rimuovetele!
• Monitora la dimensione dei pacchetti: Pacchetti di deployment più piccoli significano démarrages a froid più veloci e meno costi di archiviazione. Includete solo le dipendenze necessarie.
• Comprendere il vostro modello di pricing: Leggete di nuovo la pagina di pricing di Lambda. Comprendete come vengono addebitate le invocazioni, i GB-secondo e il trasferimento dati. La conoscenza è potere, soprattutto quando si tratta del vostro portafoglio.

Dominare il mostro serverless non significa evitare il serverless; si tratta di essere intelligenti e intenzionali nel nostro utilizzo. La flessibilità e la scalabilità sono inestimabili, ma senza la giusta vigilanza, questi “piccoli” costi possono accumularsi e rappresentare una parte significativa del vostro budget. Andate, monitorate, ottimizzate e risparmiate!

È tutto da parte mia per oggi. Fatemi sapere nei commenti se avete altri consigli o trucchi per l’ottimizzazione dei costi Lambda!

🕒 Published: April 4, 2026