I miei costi di infrastruttura nascosti hanno ucciso 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 progetto di quanto voglia ammettere: il prelievo invisibile dei costi di infrastruttura non ottimizzati. Sappiamo tutti che bisogna costruire rapidamente, scalare velocemente e consegnare funzionalità ieri. Ma spesso, in questa frenesia, lasciamo una scia di risorse dimenticate, istanze sovradimensionate e servizi che funzionano in modalità automatica, accumulando fatture su cui diamo a malapena un’occhiata prima che la revisione del bilancio trimestrale arrivi come un masso.

Quindi, per questo articolo, mi immergo a capofitto nell’ottimizzazione dei costi, ma con un angolo molto specifico e opportuno: come smettere di perdere denaro su risorse “sempre accese” che dovrebbero essere “on demand” o “attivate da evento”. Siamo nel 2026, gente. I giorni dell’approvvigionamento di server su richiesta sono finiti. Se la vostra fattura cloud assomiglia ancora a un elenco telefonico, è ora 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 passa generalmente in secondo piano rispetto alla funzionalità e alla velocità. Provisionsiamo un’istanza EC2 che è “abbastanza grande”, forse anche “un po’ più grande giusto per sicurezza.” Lanciamo un database con IOPS provisionati che potrebbero gestire l’intero Internet, soltanto perché rimanga per lo più inattivo durante le ore di punta. Dimentichiamo di configurare politiche di scaling adeguate, o semplicemente lasciamo che le cose funzionino 24 ore su 24, 7 giorni su 7, perché, beh, è più facile non pensarci.

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 panoramiche in tempo reale delle interazioni con i clienti. Era una grande vittoria per le performance. Ma quando è arrivata la prima fattura completa del cloud, il direttore finanziario ha rischiato di avere un attacco. Avevano provisionato un cluster EKS solido, alcune istanze RDS di alta gamma e una miriade di funzioni Lambda con allocazioni di memoria generose, tutte funzionanti senza interruzione. Il colpo di scena? Il cruscotto era 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.

Pagavano per una capacità di livello enterprise per un sistema che era effettivamente inattivo per il 70% della settimana. È come comprare una macchina di Formula 1 per andare al supermercato una volta alla settimana.

Identifica i Colpevoli: Dove Va Davvero il Vostro Denaro

Prima di poter riparare qualcosa, è necessario sapere cosa è rotto. La maggior parte dei fornitori di cloud offre strumenti per aiutarvi a visualizzare le vostre spese, e dovete assolutamente utilizzarli. AWS Cost Explorer, Azure Cost Management, Google Cloud Billing reports – non servono solo per le finanze. Sono la vostra prima linea di difesa.

I Soliti Sospetti

• Istanze di Calcolo (EC2, VMs): Spesso sono i più grandi colpevoli. Sono sovradimensionate? Funzionano quando non dovrebbero? Utilizzate la famiglia di istanze giusta per il vostro 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 ora offrono opzioni senza server che si riducono a zero o a un costo quasi zero quando sono inattivi.
• Storage (volumi EBS, dischi non attaccati): Avete mai lanciato un’istanza, la avete terminata, ma lasciato il volume di storage associato vagare? Succede più spesso di quanto pensiate.
• Networking (Trasferimento dati, NAT Gateways): I costi di trasferimento dati possono sorprendervi, specialmente tra regioni. Le NAT Gateways hanno anche un costo orario, anche se non fanno nulla.
• Servizi Sottoutilizzati: Pagate per un cache Redis dedicato che ha solo pochi accessi al giorno? Un cluster Kafka gestito per un flusso di messaggi?

Il mio cliente della storia del cruscotto di analisi ha iniziato guardando il suo AWS Cost Explorer. I maggiori articoli di spesa erano, prevedibilmente, EC2 e RDS. Hanno anche trovato alcuni volumi EBS attaccati 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)

Va bene, avete identificato le aree in cui spendete troppo. Passiamo alla parte divertente: risolverlo. L’obiettivo non è solo risparmiare denaro, ma costruire un sistema più resiliente ed efficiente che consuma risorse solo quando ne ha veramente bisogno.

1. Pianificate l’Avvio/Arresto delle Istanze

Probabilmente è il frutto più semplice per molte applicazioni. Se i vostri strumenti interni o i vostri ambienti di staging vengono utilizzati solo durante l’orario d’ufficio, non c’è motivo che funzionino 24 ore su 24, 7 giorni su 7. La maggior parte dei fornitori di cloud offre modi nativi per pianificare cicli di alimentazione delle istanze, o potete creare la vostra soluzione con funzioni senza server.

Esempio Pratico: Pianificatore EC2 AWS con Lambda

Potete creare una semplice funzione Lambda attivata da eventi CloudWatch (espressioni CRON) per fermare 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')
 
 # Definire tag per identificare le istanze da fermare/avviare
 # Ad esempio, 'Schedule': 'business-hours'
 
 # Recuperare 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 fermare.")
 
 # --- Logica simile per avviare le istanze in un altro momento ---
 # Avreste un'altra Lambda/Event CloudWatch per avviare,
 # o combinare la logica con un tag 'start'.
 
 return {
 'statusCode': 200,
 'body': 'Pianificazione delle istanze EC2 completata.'
 }

Dovreste configurare due regole di eventi CloudWatch: una per attivare questa Lambda, diciamo, alle 18:00 UTC per fermare 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. Adottate il Senza Server e l’Orchestrazione di Contenitori

Se il vostro carico di lavoro è davvero sporadico o attivato da eventi, il senza server è il vostro miglior alleato. AWS Lambda, Azure Functions, Google Cloud Functions – si riducono a zero quando non sono utilizzate, il che significa che pagate solo per il calcolo quando il vostro codice viene realmente eseguito. È un enorme cambiamento rispetto al paradigma “sempre acceso”.

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 vostri pod applicativi in base all’utilizzo della CPU o a metriche personalizzate. Gli Cluster Autoscalers possono persino aggiungere o rimuovere nodi dal vostro cluster man mano che la domanda cambia.

Il mio cliente ha rifattorizzato parti del suo cruscotto di analisi per usare Lambda per generare alcuni report richiesti solo poche volte al giorno. Invece di un’istanza EC2 dedicata che eseguiva un cron job, 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. Dimensionate Correttamente i Vostri Database con il Senza Server o l’Auto-Scalabilità

Questi sono spesso problematici poiché la persistenza dei dati è critica. Tuttavia, molti database moderni offrono opzioni senza server o di auto-scaling che non erano ampiamente disponibili alcuni anni 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 paghi solo per ciò che utilizzi. Non è più necessario provisionare per una capacità di picco quando la maggior parte del tempo si opera a carico ridotto.
• Azure SQL Database Serverless : Simile ad Aurora Serverless, si adatta automaticamente alla capacità di calcolo e si mette in pausa quando è inattivo, realizzando significativi risparmi per i 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 dover provisionare unità di capacità di lettura/scrittura. Perfetto per modelli di traffico imprevedibili.

Il cruscotto analitico utilizzava inizialmente un’istanza RDS PostgreSQL di grandi dimensioni con IOPS provisionate. Dopo la migrazione a Aurora Serverless v2, i loro costi di 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 Snapshot

Può sembrare basilare, ma è una fonte costante di spreco di denaro. Quando chiudi un’istanza EC2, il suo volume EBS associato non viene sempre eliminato per impostazione predefinita, soprattutto se si trattava di un volume non radice. Lo stesso vale per gli snapshot – si accumulano rapidamente e possono diventare costosi.

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

Puoi utilizzare l’AWS CLI per trovare volumi non attaccati e rimuoverli. È un compito 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 effettivo del volume
# aws ec2 delete-volume --volume-id vol-xxxxxxxxxxxxxxxxx

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

5. Ottimizza i Costi di Rete

Le NAT Gateway sono fantastiche per consentire alle istanze nei sottoreti privati di accedere a Internet, ma comportano costi orari e spese di trattamento dei dati. Se hai più NAT Gateway in diverse zone di disponibilità, ma solo una viene utilizzata attivamente, stai pagando per la ridondanza.

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

Abbiamo constatato 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 a risparmiare in questo modo, poi hanno implementato gli Endpoints VPC per l’accesso a S3, il che ha ridotto i costi di trattamento dei dati tramite la NAT Gateway.

Azioni da Intrattenere per il Prossimo Sprint

Non si tratta solo di riduzione dei costi; si tratta di costruire sistemi più intelligenti ed efficienti, intrinsecamente consapevoli dei costi. Ecco cosa puoi iniziare a fare già da oggi:

1. Audita Regolarmente la Tua Bolletta Cloud : Rendila un’abitudine. Utilizza gli strumenti di gestione dei costi del tuo fornitore cloud. Non rimandarlo solo ai finanziatori. Comprendi dove va ogni dollaro.
2. Contrassegna Tutto : Questo è non negoziabile. Contrassegna 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 le interruzioni programmate al di fuori dell’orario lavorativo. Questo è generalmente il guadagno più facile e veloce.
4. Valuta il Serverless per Nuovi Carichi di Lavoro : Se stai costruendo qualcosa di nuovo, specialmente microservizi basati su eventi o attività in background, considera sempre il serverless come prima opzione.
5. Rivaluta le Tue Scelte di Database : Se hai database attivi 24/7 con carichi molto variabili, esamina le opzioni serverless o di auto-scaling per la tecnologia del database specifico.
6. Automatizza la Pulizia : Implementa script automatizzati o funzioni serverless per identificare e rimuovere i volumi di storage non attaccati, i vecchi snapshot e altre risorse orfane.
7. Educa il Tuo Team : Favorisci una cultura della consapevolezza dei costi. Assicurati che gli sviluppatori comprendano le implicazioni finanziarie delle loro scelte di provisioning. Non è più solo un problema delle operazioni.

Fermare le perdite legate alle risorse “sempre attive” non è una soluzione una tantum; è una disciplina continua. Ma apportando questi cambiamenti, non solo risparmierai 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 intelligentemente e ci vediamo alla prossima!

🕒 Published: April 4, 2026