AWS non si gestisce da solo: quando Terraform moltiplica costi e rischi

La fattura AWS arriva puntuale. Il dubbio, invece, spesso arriva tardi: stiamo pagando per ciò che l’applicazione usa davvero o per un’infrastruttura lasciata crescere senza una regia?

È facile associare il cloud all’idea che tutto si adatti automaticamente. Si definiscono le risorse con Terraform, si attivano alcuni servizi gestiti e l’infrastruttura sembra risolta. Ma AWS gestisce i data center e il funzionamento dei suoi servizi; non decide al posto dell’azienda quanto dimensionare un database, quali porte esporre, che cosa sottoporre a backup o quante zone di disponibilità usare. Il modello di responsabilità condivisa di AWS è molto chiaro: configurazioni, dati, identità e controlli restano in larga parte responsabilità del cliente.

Terraform aggiunge automazione, non giudizio. Se la scelta è corretta, la rende ripetibile. Se è sbagliata, rende ripetibile anche lo spreco o il rischio.

Il cloud non è un rubinetto da lasciare sempre aperto

Con un server tradizionale si acquista capacità in anticipo e la si tiene disponibile. Nel cloud la promessa è diversa: usare le risorse quando servono e adattarle alla domanda. Se però si trasferisce lo stesso modello mentale su AWS, il risultato può essere una grande istanza EC2 sempre accesa, un database sovradimensionato, ambienti di sviluppo attivi anche di notte e storage che continua ad accumularsi.

In quel momento il cloud ha tutta la flessibilità di un rubinetto, ma viene usato come se non avesse una manopola. Il problema non è il prezzo del singolo servizio. È l’assenza di qualcuno che colleghi la fattura al carico reale, ai requisiti dell’applicazione e al valore prodotto.

Anche AWS, nel suo Well-Architected Framework, invita a smettere di indovinare la capacità necessaria e a fornire risorse in modo dinamico. La possibilità tecnica esiste; bisogna però progettarla, misurarla e mantenerla nel tempo.

Un caso reale: costi fissi per un carico che fisso non era

Mi è capitato di intervenire su una piattaforma SaaS ospitata su AWS. L’applicazione funzionava, ma l’infrastruttura raccontava una storia diversa da quella del prodotto: una grande istanza EC2 restava sempre attiva, RDS era dimensionato oltre il carico effettivo e i deploy richiedevano operazioni manuali.

Ridurre la taglia della macchina avrebbe abbassato la fattura nell’immediato, ma non avrebbe risolto il problema. L’applicazione sarebbe rimasta dipendente da un singolo punto di capacità, senza la possibilità di reagire automaticamente ai picchi e con rilasci ancora legati all’intervento umano.

Prima di cambiare servizi abbiamo ricostruito la baseline: fatture comparabili, utilizzo di CPU e memoria, comportamento del database, distribuzione del traffico e modalità di rilascio. Solo dopo è diventato possibile distinguere la capacità realmente necessaria da quella pagata per abitudine o prudenza.

Non un taglio, ma un’architettura proporzionata

L’applicazione è stata containerizzata e spostata su ECS Fargate. I task vengono distribuiti tra più Availability Zone dietro un Application Load Balancer, con health check e sostituzione delle unità non sane. Le policy di autoscaling aumentano o riducono la capacità usando metriche di CPU e memoria, mentre RDS è stato ridimensionato in base all’utilizzo osservato.

I file statici sono passati su S3 e CloudFront, lasciando al compute applicativo soltanto il lavoro che gli compete. Una pipeline GitHub Actions costruisce l’immagine e aggiorna il servizio ECS, eliminando i deploy manuali sulla macchina di produzione.

Il confronto tra fatture AWS comparabili ha mostrato una riduzione del 20% della spesa mensile. Ma il risultato più interessante non è stato soltanto economico: l’applicazione non dipende più da una singola istanza, può adattare la capacità alla domanda e dispone di un processo di rilascio ripetibile. Risparmio, scalabilità e affidabilità sono arrivati dalla stessa analisi, non da tre iniziative separate.

Terraform non è un architetto

Descrivere VPC, subnet, security group e servizi in codice è una buona pratica. Permette revisione, versionamento e ricostruzione degli ambienti. Non garantisce, però, che ciò che viene descritto sia adatto al prodotto.

Un security group con una regola troppo ampia rimane pericoloso anche se creato da una pipeline impeccabile. Un database sovradimensionato rimane costoso anche se il suo modulo Terraform è elegante. Un servizio distribuito in una sola Availability Zone rimane un punto debole anche se ogni modifica passa da una pull request.

Esiste poi il tema del drift: modifiche manuali o esterne possono far divergere l’infrastruttura reale dalla configurazione e dallo stato conosciuto da Terraform. HashiCorp avverte che il successivo riallineamento può arrivare a ricreare o distruggere risorse in modo non intenzionale. Infrastructure as Code richiede quindi ownership, revisione e controllo continuo; non è un pilota automatico da lasciare senza supervisione.

Quattro rischi che una fattura non mostra

1. Sicurezza lasciata alle impostazioni iniziali

Aprire temporaneamente SSH, RDP o una porta di database verso 0.0.0.0/0 è una scorciatoia che può diventare permanente. AWS Security Hub classifica come critici diversi casi di accesso indiscriminato a porte ad alto rischio. La VPC isola solo ciò che viene configurato per essere isolato: servono regole con privilegi minimi, percorsi di amministrazione controllati e verifiche periodiche.

2. Backup che esistono soltanto sulla carta

Una retention configurata non equivale a un piano di continuità. Bisogna sapere quali dati sono protetti, quanti se ne possono perdere e quanto tempo richiede il ripristino. AWS raccomanda test periodici di recovery: un backup è affidabile quando viene restaurato e i dati risultano integri e utilizzabili entro gli obiettivi stabiliti.

3. Ridondanza nominale

Usare AWS non rende automaticamente un’applicazione altamente disponibile. Un workload concentrato in una sola Availability Zone o dipendente da una sola istanza conserva un singolo punto di guasto. La raccomandazione AWS per i workload di produzione è distribuire risorse e dati almeno su due zone, quando il requisito di continuità lo richiede.

4. Costi senza un proprietario

Cost Explorer, Budgets e Cost Anomaly Detection rendono visibile la spesa, ma una dashboard non spegne da sola una risorsa inutile e non sa se un picco produce valore. AWS considera ad alto rischio la mancanza di una responsabilità esplicita sull’ottimizzazione. Anche lo State of FinOps 2026 indica workload optimization e riduzione degli sprechi come la principale priorità attuale dei team FinOps.

Che cosa fa davvero un esperto di costi cloud

Ottimizzare non significa cercare il servizio più economico o ridurre ogni istanza finché l’applicazione rallenta. Significa capire quale parte del cloud viene sfruttata e quale viene semplicemente pagata.

• Attribuisce la spesa: collega account, servizi e risorse a un workload e a un responsabile.
• Legge l’utilizzo: confronta capacità, metriche, picchi e stagionalità invece di basarsi sulla taglia nominale.
• Definisce il rischio: traduce disponibilità, perdita dati accettabile e tempi di ripristino in requisiti verificabili.
• Sceglie la leva corretta: rightsizing, scheduling, autoscaling, servizi serverless o impegni di spesa risolvono problemi diversi.
• Introduce guardrail: budget, alert sulle anomalie, tagging, controlli di sicurezza e revisioni impediscono al problema di ricrearsi.
• Misura dopo il cambiamento: verifica fattura, prestazioni, affidabilità e carico operativo su dati confrontabili.

Comprare Savings Plans per una risorsa inutile rende soltanto più conveniente continuare a sprecarla. Spegnere una replica necessaria riduce il costo finché non arriva un guasto. Il valore dell’esperienza sta proprio nel distinguere questi casi.

Il cloud va governato, non soltanto configurato

AWS offre leve potenti per scalare, automatizzare e rendere più affidabile un prodotto. Proprio perché le risorse si creano in pochi minuti, anche costi e rischi possono crescere con la stessa velocità. L’infrastruttura va osservata come parte viva dell’applicazione: cambia il traffico, cambiano i servizi, cambiano i prezzi e cambiano le priorità aziendali.

La domanda utile non è “quanto costa AWS?”, ma “quale risultato sta producendo ogni euro speso su AWS?”. Nel caso raccontato, rispondere con dati reali ha ridotto la spesa del 20% e reso l’applicazione scalabile. È questo il punto: dosare il cloud non significa limitarlo, significa usarne davvero le caratteristiche.

Se vuoi capire dove il tuo ambiente sta pagando capacità inutilizzata o accumulando rischi, il Cloud Rescue Audit AWS analizza costi, sicurezza, backup e affidabilità. Nel caso studio della migrazione a ECS Fargate trovi anche l’architettura e gli interventi applicati.