I miei costi di infrastruttura nascosti hanno fatto fuori 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 tiraggio invisibile dei costi di infrastruttura non ottimizzati. Sappiamo tutti che dobbiamo costruire rapidamente, scalare velocemente e consegnare funzionalità ieri. Ma spesso, in questa fretta, lasciamo dietro di noi una scia di risorse dimenticate, istanze sovradimensionate e servizi che funzionano in modalità automatica, accumulando bollette che a malapena diamo un’occhiata prima che la revisione budgetaria trimestrale ci colpisca come un tonnellata di mattoni.

Quindi, per questo articolo, affronterò a testa alta l’ottimizzazione dei costi, ma con un angolo molto specifico e opportuno: come smettere di perdere denaro su risorse “sempre attive” che dovrebbero essere “on-demand” o “attivate da eventi”. Siamo nel 2026, ragazzi. I giorni della fornitura di server a la carte sono finiti. Se la vostra bolletta cloud somiglia ancora a un elenco telefonico, è ora di intervenire.

Il Killer Silenzioso: Sempre Attivo Quando Dovrebbe Essere On-Demand

Essere realistici. 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 rapidità. Provisioniamo 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, solo perché rimanga principalmente inutilizzato durante le ore non di punta. Dimentichiamo di configurare adeguate politiche di scaling, oppure semplicemente lasciamo che le cose funzionino 24/7 perché, beh, è più facile che preoccuparsi.

Ho visto questo con i miei occhi qualche mese 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 prestazioni. Ma quando è arrivata la prima bolletta cloud completa, il direttore finanziario ha rischiato di avere un attacco di cuore. 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 interruzione. Il colpo di scena? Il cruscotto era utilizzato principalmente dagli agenti durante l’orario lavorativo, dalle 9 alle 17, dal lunedì al venerdì. Al di fuori di ciò, 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 un’auto di Formula 1 per andare al supermercato una volta alla settimana.

Identifica i Colpevoli: Dove Vanno Davvero i Tuoi Soldi

Prima di poter riparare qualcosa, devi sapere che 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 Sospettati

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

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

Strategie per Trasformare Sempre Attivo in On-Demand (o Fuori-Peak)

D’accordo, hai identificato i settori in cui spendi troppo. Passiamo alla parte divertente: sistemare ciò. L’obiettivo non è solo risparmiare denaro, ma costruire un sistema più resiliente ed efficace che consuma risorse solo quando ne ha realmente bisogno.

1. Pianifica l’Avvio/Fine 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 lavorativo, non c’è motivo che funzionino 24/7. La maggior parte dei fornitori di cloud offre modi nativi per pianificare cicli di alimentazione delle istanze, oppure puoi creare la tua soluzione con funzioni serverless.

Esempio Pratico: Pianificatore EC2 AWS con Lambda

Puoi creare una semplice funzione Lambda attivata da eventi CloudWatch (espressioni CRON) per interrompere 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 arrestare/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 arrestare.")
 
 # --- Logica simile per avviare le istanze in un altro momento ---
 # Avresti un'altra Lambda/Event CloudWatch per avviare,
 # o 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 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. Adotta il Serverless e l’Orchestrazione dei Container

Se il tuo carico di lavoro è veramente sporadico o attivato da eventi, il serverless è il tuo migliore alleato. AWS Lambda, Azure Functions, Google Cloud Functions – si riducono a zero quando non utilizzate, il che significa che paghi solo per il calcolo quando il tuo codice viene eseguito realmente. È un enorme cambiamento rispetto al paradigma “sempre attivo”.

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

Il mio cliente ha rifattorizzato parti del suo cruscotto analitico per utilizzare Lambda per generare alcuni report che venivano richiesti solo pochi 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. Dimensiona Correttamente i Tuoi Database con il Serverless o l’Auto-Scalabilità

I database sono spesso problematici poiché la persistenza dei dati è critica. Tuttavia, molti database moderni offrono opzioni serverless 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 pianificare una capacità di picco mentre la maggior parte del tempo operi 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, generando risparmi significativi 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 pianificare unità di capacità di lettura/scrittura. Perfetto per modelli di traffico imprevedibili.

Il cruscotto analitico utilizzava originariamente un’istanza RDS PostgreSQL grande con IOPS pianificate. 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 punta.

4. Pulisci gli Archivi Non Collegati e gli Snapshot

Questo può sembrare banale, ma è una fonte costante di spreco di denaro. Quando interrompi 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 Eliminare i Volumi EBS Non Collegati (AWS CLI)

Puoi utilizzare l’AWS CLI per trovare volumi non collegati e eliminarli. È un compito di pulizia comune.

# Elencare tutti i volumi non collegati
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 del volume reale
# 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 collegati e centinaia di snapshot obsoleti. Eliminandoli, hanno risparmiato alcune centinaia di dollari sulla loro bolletta mensile – non è enorme, ma ogni piccolo gesto conta.

5. Ottimizzare i Costi di Rete

Le NAT Gateway sono fantastiche per consentire alle istanze nei sottoreti private di accedere a Internet, ma comportano costi orari e costi di elaborazione dei dati. Se hai più NAT Gateway in diverse zone di disponibilità, ma solo una è utilizzata attivamente, stai pagando per delle ridondanti.

• Consolida le NAT Gateway : Se la tua architettura lo permette, consolida verso meno NAT Gateway.
• Endpoints VPC : Per accedere ai servizi AWS come S3 o DynamoDB dalla tua VPC, utilizza gli Endpoints VPC. Il traffico circola 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 un NAT Gateway in ogni AZ, anche se la sua applicazione principale funzionava solo in due. Hanno potuto consolidare e realizzare risparmi da lì, e successivamente hanno implementato gli Endpoints VPC per l’accesso a S3, il che ha ridotto i costi di elaborazione dei dati tramite la NAT Gateway.

Azioni da Intraprendere 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 oggi:

1. Audita Regolarmente la Tua Fattura Cloud: Rendilo un’abitudine. Utilizza gli strumenti di gestione dei costi del tuo fornitore cloud. Non lasciarlo solo alle finanze. Comprendi dove va ogni dollaro.
2. Tagga Tutto: Questo non è negoziabile. Tagga le risorse per progetto, proprietario, ambiente (dev, staging, prod) e se possono essere programmate per l’arresto. Questo facilita enormemente l’identificazione e l’automazione.
3. Prioritizza la Programmazione per Ambienti Non Produttivi: Gli ambienti di staging, dev, QA sono candidati ideali per arresti programmati al di fuori dell’orario lavorativo. È generalmente il guadagno più facile e veloce.
4. Valuta il Serverless per Nuove Carichi di Lavoro: Se stai costruendo qualcosa di nuovo, in particolare 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 che funzionano 24/7 con carichi molto variabili, valuta le opzioni serverless o di auto-scaling per la tua specifica tecnologia di database.
6. Automatizza la Pulizia: Implementa script automatizzati o funzioni serverless per identificare ed eliminare volumi di archiviazione non collegati, vecchi snapshot e altre risorse orfane.
7. Educa il Tuo Team: Promuovi una cultura della consapevolezza dei costi. Assicurati che gli sviluppatori comprendano le implicazioni finanziarie delle loro scelte di approvvigionamento. Non è più solo una questione operativa.

Fermare le perdite legate alle risorse “sempre attive” non è una soluzione temporanea; è 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, ciò ti rende un attore migliore nel campo tecnologico.

È tutto da parte mia questa volta. Continua a costruire in modo intelligente, e ci vediamo alla prossima!

🕒 Published: April 4, 2026