I miei costi di infrastruttura nascosti hanno distrutto il mio budget

Ciao a tutti, Jules Martin qui, di nuovo su agntmax.com. Spero che stiate tutti bene. Oggi voglio parlare di qualcosa che mi preoccupa ultimamente, qualcosa che ho visto emergere in più conversazioni e post-mortem di progetti di quanto voglia ammettere: il prelievo invisibile dei costi di infrastruttura non ottimizzati. Sappiamo tutti che dobbiamo costruire velocemente, scalare in fretta e consegnare funzionalità ieri. Ma spesso, in questa corsa, lasciamo dietro di noi una scia di risorse dimenticate, istanze sovradimensionate e servizi che funzionano in modalità automatica, accumulando fatture che a malapena daremo un’occhiata prima che la revisione trimestrale del budget cada come un tonnellata di mattoni.

Quindi, per questo articolo, mi immergo a capofitto nellottimizzazione dei costi, ma con un’angolazione molto specifica e tempestiva: come smettere di perdere denaro su risorse « sempre accese » che dovrebbero essere « on demand » o « attivate da eventi ». Siamo nel 2026, gente. I giorni della fornitura di server alla carta sono finiti. Se la vostra fattura del cloud sembra ancora un elenco telefonico, è tempo di intervenire.

Il Killer Silenzioso: Sempre Acceso Quando Dovrebbe Essere On Demand

Siamo realisti. Quando siamo sotto pressione per lanciare un nuovo strumento per gli agenti o un miglioramento del servizio clienti, il costo di solito passa in secondo piano rispetto alla funzionalità e alla velocità. Provisioniamo un’istanza EC2 che è « abbastanza grande », forse persino « un po’ più grande giusto per sicurezza ». Lanciamo un database con IOPS provisionati che potrebbero gestire l’intero Internet, solo per trovarlo principalmente inutilizzato durante le ore di picco. Dimentichiamo di configurare le politiche di scalabilità appropriate, oppure lasciamo semplicemente che le cose funzionino 24/7 perché, beh, è più facile non preoccuparsene.

Ho visto tutto questo con i miei occhi alcuni mesi fa con il nuovo cruscotto di analisi interna di un cliente. Il team, che Dio li benedica, aveva costruito un sistema fantastico che forniva agli agenti visibilità in tempo reale delle interazioni con i clienti. È stata una grande vittoria per le performance. Ma quando è arrivata la prima fattura del cloud, il direttore finanziario è quasi svenuto. Avevano provisionato un cluster EKS robusto, alcune istanze RDS di alto livello e una moltitudine di funzioni Lambda con allocazioni di memoria generose, tutte funzionanti senza sosta. Il colpo di grazia? Il cruscotto veniva utilizzato principalmente dagli agenti durante l’orario d’ufficio, dalle 9 alle 17, dal lunedì al venerdì. Al di fuori di questo, era una città fantasma.

Stavano pagando per una capacità di livello aziendale per un sistema che era effettivamente inattivo il 70% della settimana. È come comprare un’auto di Formula 1 per andare al supermercato una volta alla settimana.

Identifica i Colpevoli: Dove Va Davvero il Tuo Denaro

Prima di poter riparare qualsiasi cosa, devi sapere cosa è rotto. La maggior parte dei fornitori di cloud offre strumenti per aiutarti a visualizzare le tue spese, e devi assolutamente usarli. AWS Cost Explorer, Azure Cost Management, Google Cloud Billing reports – non sono solo per le finanze. Sono la tua prima linea di difesa.

I Soliti Sospetti

• Istanza di Calcolo (EC2, VMs): Sono spesso i colpevoli principali. Sono sovradimensionate? Funzionano quando non dovrebbero? Stai usando la giusta famiglia di istanze per il tuo carico di lavoro?
• Database (RDS, Azure SQL, Cloud SQL): Come per il calcolo, i database possono essere sovra-provisionati per le IOPS, la CPU o la memoria. Molti offrono ora opzioni senza server che si riducono a zero o a un costo quasi nullo quando sono inattivi.
• Storage (volumi EBS, dischi non collegati): Hai mai avviato un’istanza, l’hai terminata, ma hai lasciato il volume di storage associato a vagare? Questo accade più spesso di quanto pensi.
• Networking (Trasferimento di dati, NAT Gateways): I costi di trasferimento dei dati possono sorprenderti, specialmente tra le regioni. Le NAT Gateways hanno anche un costo orario, anche se non fanno nulla.
• Servizi Sottoutilizzati: Stai pagando per un cache Redis dedicato che ha solo alcune accessi al giorno? Un cluster Kafka gestito per una rete di messaggi?

Il mio cliente del racconto del cruscotto di analisi ha iniziato guardando il suo AWS Cost Explorer. Le voci più significative erano, prevedibilmente, EC2 e RDS. Hanno anche trovato alcuni volumi EBS collegati a istanze terminate e una NAT Gateway in una VPC che non era più utilizzata per il traffico di produzione. Piccole cose, ma si accumulano.

Strategie per Trasformare Sempre Acceso in On Demand (o Fuori Picco)

Ok, hai identificato le aree in cui stai spendendo troppo. Passiamo alla parte divertente: riparare questo. L’obiettivo non è solo risparmiare denaro, ma costruire un sistema più resilienti ed efficiente che consuma risorse solo quando ne ha realmente bisogno.

1. Pianifica l’Avvio/Arresto delle Istanze

È probabilmente il frutto più facile per molte applicazioni. Se i tuoi strumenti interni o i tuoi ambienti di staging vengono utilizzati solo durante l’orario d’ufficio, non c’è motivo che funzionino 24/7. La maggior parte dei fornitori di cloud offre modi nativi per pianificare i cicli di alimentazione delle istanze, oppure puoi creare la tua soluzione con funzioni senza server.

Esempio Pratico: Pianificatore EC2 AWS con Lambda

Puoi creare una semplice funzione Lambda attivata da eventi CloudWatch (espressioni CRON) per arrestare e avviare istanze EC2 in base ai tag. Ecco una versione semplificata del codice della funzione Lambda (Python):

import boto3

def lambda_handler(event, context):
 ec2 = boto3.client('ec2')
 
 # Definisci dei tag per identificare le istanze da arrestare/avviare
 # Per esempio, 'Schedule': 'business-hours'
 
 # Recupera tutte le istanze in esecuzione con il tag 'Schedule' impostato su 'business-hours'
 running_instances = ec2.describe_instances(
 Filters=[
 {'Name': 'instance-state-name', 'Values': ['running']},
 {'Name': 'tag:Schedule', 'Values': ['business-hours']}
 ]
 )
 
 stop_instance_ids = []
 for reservation in running_instances['Reservations']:
 for instance in reservation['Instances']:
 stop_instance_ids.append(instance['InstanceId'])
 
 if stop_instance_ids:
 print(f"Arresto delle istanze: {stop_instance_ids}")
 ec2.stop_instances(InstanceIds=stop_instance_ids)
 else:
 print("Nessuna istanza da arrestare.")
 
 # --- Logica simile per avviare istanze in un altro momento ---
 # Avresti un'altra Lambda/Event di CloudWatch per avviare,
 # oppure combinare la logica con un tag 'start'.
 
 return {
 'statusCode': 200,
 'body': 'Pianificazione delle istanze EC2 completata.'
 }

Dovresti configurare due regole di eventi CloudWatch: una per attivare questa Lambda, diciamo, alle 18:00 UTC per arrestare le istanze, e un’altra alle 7:00 UTC per avviarle. Questo può da solo ridurre i costi di calcolo di oltre il 70% per queste risorse specifiche.

2. Adotta il Senza Server e l’Orchestrazione di Contenitori

Se il tuo carico di lavoro è veramente sporadico o attivato da eventi, il senza server è il tuo migliore alleato. AWS Lambda, Azure Functions, Google Cloud Functions – si riducono a zero quando non vengono utilizzate, il che significa che paghi solo per il calcolo quando il tuo codice si esegue realmente. È un enorme cambiamento rispetto al paradigma « sempre accesso ».

Per applicazioni più complesse che richiedono comunque servizi persistenti ma hanno una domanda fluttuante, le piattaforme di orchestrazione di contenitori come Kubernetes (EKS, AKS, GKE) combinate con uno scaling intelligente sono potenti. Gli Horizontal Pod Autoscalers (HPA) possono variare la dimensione dei tuoi pod di applicazione in base all’utilizzo della CPU o a metriche personalizzate. Gli Cluster Autoscalers possono persino aggiungere o rimuovere nodi dal tuo cluster man mano che la domanda cambia.

Il mio cliente ha rifattorizzato parti del suo cruscotto di analisi per utilizzare Lambda per generare alcuni rapporti che venivano richiesti solo alcune volte al giorno. Invece di un’istanza EC2 dedicata che esegue un job cron, una funzione Lambda veniva attivata da un evento S3 (nuovi file caricati) o da una richiesta API Gateway. I risparmi erano immediati e significativi.

3. Dimensiona Correttamente i Tuoi Database con il Senza Server o l’Auto-Scalabilità

I database sono spesso problematici poiché la persistenza dei dati è critica. Tuttavia, molti database moderni offrono opzioni senza server o di auto-scalabilità che non erano ampiamente disponibili qualche anno fa.

• AWS Aurora Serverless v2 : È un cambiamento significativo. Regola la capacità in base all’utilizzo reale, da frazioni di un ACU (Unità di Capacità Aurora) fino a centinaia, e si paga solo per ciò che si utilizza. Non è più necessario prevedere una capacità di picco quando per la maggior parte del tempo si opera con un carico normale.
• Azure SQL Database Serverless : Simile ad Aurora Serverless, si adatta automaticamente alla capacità di calcolo e si mette in pausa quando è inattivo, realizzando risparmi significativi per carichi di lavoro intermittenti.
• DynamoDB On-Demand : Per i carichi di lavoro NoSQL, la modalità di capacità on-demand di DynamoDB significa che paghi per ogni richiesta, senza la necessità di prevedere unità di capacità di lettura/scrittura. Perfetto per modelli di traffico imprevedibili.

Il pannello di analisi utilizzava inizialmente un’istanza RDS PostgreSQL grande con IOPS provisionati. Dopo la migrazione a Aurora Serverless v2, i loro costi per il database sono diminuiti di quasi il 60%, semplicemente perché non funzionava più a pieno regime durante le ore di bassa attività.

4. Pulisci gli Storage Non Attaccati e gli Snapshots

Questo può sembrare basilare, ma è una fonte costante di spreco di denaro. Quando si termina un’istanza EC2, il suo volume EBS associato non viene sempre eliminato di default, specialmente se si trattava di un volume non root. Lo stesso vale per gli snapshots – si accumulano rapidamente e possono diventare costosi.

Esempio Pratico: Trovare e Rimuovere Volumi EBS Non Attaccati (AWS CLI)

Puoi usare l’AWS CLI per trovare i volumi non attaccati e rimuoverli. È un’attività di pulizia comune.

# Elenca tutti i volumi non attaccati
aws ec2 describe-volumes --filters Name=status,Values=available --query 'Volumes[*].[VolumeId,Size,CreateTime]' --output table

# Per eliminare un volume specifico (FAI ATTENZIONE, È IRREVERSIBILE)
# Sostituisci 'vol-xxxxxxxxxxxxxxxxx' con l'ID reale del volume
# aws ec2 delete-volume --volume-id vol-xxxxxxxxxxxxxxxxx

Automatizza questo con una funzione Lambda programmata se crei e elimini spesso ambienti. Il cliente ha scoperto diversi terabyte di vecchi volumi EBS non attaccati e centinaia di snapshots obsoleti. Rimuoverli ha permesso di risparmiare alcune centinaia di dollari sulla loro fattura mensile – non è enorme, ma ogni piccolo gesto conta.

5. Ottimizza i Costi di Rete

Le NAT Gateways sono fantastiche per consentire alle istanze nei sotto-reti privati di accedere a Internet, ma comportano costi orari e spese per il trattamento dei dati. Se hai più NAT Gateways in diverse zone di disponibilità, ma solo una viene utilizzata attivamente, stai pagando per le ridondanze.

• Consolida le NAT Gateways : Se la tua architettura lo consente, consolida verso meno NAT Gateways.
• Endpoints VPC : Per accedere ai servizi AWS come S3 o DynamoDB dal tuo VPC, usa gli Endpoints VPC. Il traffico circola in modo privato all’interno della rete AWS, evitando i costi delle NAT Gateways e offrendo una maggiore sicurezza.

Abbiamo riscontrato che il cliente aveva una NAT Gateway in ogni AZ, anche se la sua applicazione principale funzionava solo in due. Sono riusciti a consolidare e risparmiare così, e successivamente hanno implementato degli Endpoints VPC per l’accesso a S3, il che ha ridotto i costi per il trattamento dei dati tramite la NAT Gateway.

Azioni da Intrattenere per il Prossimo Sprint

Non si tratta solo di ridurre i costi; si tratta di costruire sistemi più intelligenti ed efficienti, intrinsecamente consapevoli dei costi. Ecco cosa puoi iniziare a fare da subito:

1. Audit Regolari della Tua Fattura Cloud : Rendila un’abitudine. Utilizza gli strumenti di gestione dei costi forniti dal tuo provider cloud. Non lasciarlo solo alle finanze. Comprendi dove va ogni dollaro.
2. Etichetta Tutto : Questo è non negoziabile. Etichetta le risorse per progetto, proprietario, ambiente (dev, staging, prod) e se possono essere programmate per lo spegnimento. Questo rende molto più facile l’identificazione e l’automazione.
3. Prioritizza la Programmazione per gli Ambienti Non Produttivi : Gli ambienti di staging, dev, QA sono candidati ideali per spegnimenti programmati al di fuori dell’orario di lavoro. Questo è generalmente il guadagno più facile e rapido.
4. Valuta il Serverless per Nuove Carichi di Lavoro : Se stai costruendo qualcosa di nuovo, in particolare microservizi basati su eventi o attività di backend, considera sempre prima il serverless.
5. Rivaluta le Tue Scelte di Database : Se hai database in funzione 24/7 con carichi molto variabili, esamina le opzioni serverless o di auto-scaling per la tua tecnologia di database specifica.
6. Automatizza la Pulizia : Implementa script automatizzati o funzioni serverless per identificare e rimuovere volumi di storage non attaccati, vecchi snapshots e altre risorse orfane.
7. Educate la Tua Squadra : Promuovi una cultura della consapevolezza dei costi. Assicurati che i programmatori comprendano le implicazioni finanziarie delle loro scelte di provisioning. Non è più solo un problema di operazioni.

Fermare le perdite legate alle risorse “sempre attive” non è una soluzione una tantum; è una disciplina continua. Ma apportando questi cambiamenti, risparmierai non solo una somma significativa di denaro per la tua azienda, ma costruirai anche un’infrastruttura più agile, resiliente e pronta per il futuro. E francamente, questo ti rende un attore migliore nel campo tecnologico.

È tutto per me questa volta. Continua a costruire in modo intelligente, e ci vediamo alla prossima!

🕒 Published: April 4, 2026