Costi cloud sotto controllo: Tagging, processi FinOps e misure rigorose contro gli shadow workloads

Chi vuole tenere i costi cloud sotto controllo deve discutere meno del «cloud è costoso» e più di attribuzione, responsabilità e possibilità di disattivazione. In molte aziende i costi aggiuntivi non derivano da singoli grandi sistemi, ma da migliaia di voci piccole: ambienti di test dimenticati, database sovradimensionati, worker batch in esecuzione continua, logging con retention troppo lunga o copie di storage senza regole di lifecycle. Particolarmente critici sono Schatten-Workloads: risorse cloud utilizzate operativamente ma senza un Owner chiaro, senza budget e spesso anche senza una corretta integrazione per sicurezza e operation.

Questo contributo descrive un percorso pratico: primo, un modello di tagging e di costi che funzioni davvero; secondo, processi FinOps che escano affidabili su base mensile; e terzo, misure „forti“ con le quali contenere i Schatten-Workloads sia tecnicamente che organizzativamente. Il focus non è sulla magia degli strumenti, ma sulla realtà operativa: identità, autorizzazioni, interfacce, persistenza dei dati, questioni di rollout e ciò che conta in caso di incident o di audit.

Perché i costi cloud sfuggono al controllo: schemi tipici dall’operatività

I problemi di costo emergono spesso solo quando il budget «improvvisamente» cede. Operativamente questo accade in modo subdolo. Alcuni schemi ricorrenti:

• Attribuzione poco chiara: le voci di fatturazione non possono essere assegnate in modo univoco a un software di business, a un team o a un prodotto. Senza allocazione dei costi ogni discussione diventa politica anziché tecnica.
• Drift degli ambienti: Dev/Test/Staging crescono in modo incontrollato perché nessuno impone finestre di spegnimento. «Solo per un breve test» diventa funzionamento continuativo.
• Crescita dei dati senza paletti: object storage, backup, snapshot, log e metriche aumentano perché la retention non è limitata o non viene mai verificata.
• Provisioning senza dismissione: le risorse vengono create rapidamente ma non deprovisionate in modo pulito. La dismissione raramente fa parte della Definition of Done.
• Schatten-Workloads: singoli dipartimenti o team di progetto usano account/subscription/progetto propri o aggirano le direttive centrali. I rischi non sono solo finanziari ma anche rilevanti per la sicurezza (endpoint esposti, mancanza di cifratura, assenza di audit log).

È importante la constatazione: il controllo dei costi non è un progetto di ottimizzazione una tantum. È un processo operativo ricorrente – paragonabile al patch e release management. Senza ritmo, ruoli e blocchi tecnici chiari ogni risparmio resterà temporaneo.

Tagging come fondamento: assegnare i costi prima di ottimizzare

„Tagging“ indica metadati associati a risorse cloud (p.es. Tags/Labels), con i quali costi, responsabilità e scopo possono essere analizzati in modo leggibile da macchina. Ciò che conta non è il numero dei tag, ma uno schema coerente e applicabile. Nella pratica il tagging fallisce in tre ambiti: troppi campi, convenzioni di scrittura incoerenti, assenza di conseguenze in caso di violazioni.

Uno schema di tagging che si può mantenere nella pratica

Per la maggior parte degli ambienti sono sufficienti 6–9 campi obbligatori. Devono essere scelti in modo da supportare sia l’operatività IT sia il controllo di gestione:

• Owner (team o ruolo responsabile): non un nome di persona, ma un gruppo/unità di responsabilità che esiste in modo duraturo.
• CostCenter (centro di costo/portatore del costo): deve essere compatibile con il modello finanziario interno.
• Application (software di business/prodotto): nome del sistema che fornisce il valore.
• Environment (Prod/Test/Dev): per regole di spegnimento, SLOs e misure di protezione.
• DataClass (livello di protezione): p.es. «pubblico», «interno», «riservato». Da questo si possono derivare requisiti per logging, crittografia ed export.
• Lifecycle (temporaneo/permanente + data di fine se temporaneo): obbliga a decidere se qualcosa può essere rimosso.

Opzionale, ma utile: Project (per iniziative a termine), Compliance (p.es. «rilevante per audit»), ServiceTier (critico/standard) per la prioritizzazione operativa.

Il tagging senza applicazione è solo decorazione

Perché il tagging sia efficace, serve applicazione su più livelli:

• „Tag on create“: le risorse possono essere create automaticamente solo con i tag obbligatori. Questo può essere realizzato tramite Infrastructure as Code (IaC, ossia provisioning dichiarativo) o policy.
• Defaulting statt Freitext: dove possibile scegliere valori da un catalogo (p.es. lista di CostCenter). Il testo libero genera caos nelle analisi.
• Drift-Detection: i tag possono mancare o essere sovrascritti successivamente. Un controllo periodico con ticket ai Owner è obbligatorio.
• Konsequenz: per Dev/Test privi di tag o senza data di fine: spegnimento automatico o quarantena (p.es. nessuna regola di egress verso Internet, nessun accesso ai dati di produzione).

Un’obiezione comune è: „Tagging kostet Zeit.“ Sì – ma questo è il prezzo della rendicontabilità. Senza tag rimane solo risparmio generico (p.es. dimensionare più piccolo ovunque), il che in esercizio porta a problemi di performance e stabilità.

FinOps-Prozesse, die funktionieren: Rollen, Rhythmus, Entscheidungspfade

FinOps non è uno strumento, ma un modello di collaborazione tra IT, operations, controllo di gestione e le linee di business, per rendere le spese cloud visibili, controllabili e pianificabili. Tipico è un ritmo mensile con artefatti definiti: report di costo, analisi delle deviazioni, backlog di azioni e un ciclo decisionale che influisce concretamente su budget e architettura.

Modello di ruoli: chi decide, chi fornisce, chi assume il rischio?

Nella pratica si dimostra efficace una chiara separazione:

• FinOps Lead (spesso il controllo di gestione IT o il team piattaforma): definisce standard, modera le review, consolida le azioni.
• Service Owner (per software di business): è responsabile dei costi e delle prestazioni (p.es. disponibilità, tempi di risposta) congiuntamente – non separatamente.
• Plattform/Cloud-Admin-Team: implementa policy, budget, quote, requisiti di rete e di identità.

Importante: „Owner“ non deve significare „IT paga“. Per Ownership si intende che qualcuno sia in grado di spiegare i costi e sostenere le misure.

Showback e Chargeback: due livelli, un obiettivo

Showback significa: i costi vengono assegnati in modo trasparente, ma non addebitati internamente. Chargeback significa: esiste un addebito interno (i costi vengono imputati all’area). Molte aziende iniziano sensatamente con Showback, perché Chargeback senza dati maturi (Tagging, cataloghi, chiara separazione dei tenant) genera più conflitti che controllo.

Operativamente è decisivo: in entrambi i casi i report devono essere plausibili fino al livello Workload (p. es. „API-Cluster X“, „ETL-Job Y“, „Archivio documenti Z“). Solo così emergono misure concrete invece di indicazioni di risparmio generiche.

Il ritmo mensile: tre riunioni utili

• Controllo settimanale delle anomalie (15–30 minuti): le anomalie di costo (picchi insoliti) vengono affrontate immediatamente. Obiettivo: chiudere rapidamente le perdite prima che compromettano i budget mensili.
• Revisione FinOps mensile (60–90 minuti): principali driver di costo, trend, forecast e decisioni sulle azioni. Partecipanti: Service Owner, team piattaforma, Controlling.
• Riunione architettura/portafoglio trimestrale: si priorizzano e stanziamo leve di impatto maggiori (p. es. archiviazione dei dati, redesign del processamento batch, passaggio da always-on a basato su eventi).

Sembrano più riunioni. La differenza rispetto alle „riunioni sui costi“: si tratta di pacchetti di lavoro concreti e attuabili con un Owner e una scadenza — e dell’interazione con l’operazione e l’architettura.

Misure rigorose contro le shadow-workloads: tecniche, organizzative, sostenibili

Le shadow-workloads non sono solo «qualcuno ha prenotato qualcosa», ma un problema strutturale: creazione troppo semplice, visibilità centrale insufficiente e vincoli troppo deboli. Misure rigorose non significa «vietare tutto», ma introdurre punti di controllo nel ciclo di vita.

1) Struttura dei tenant e degli account: imporre la visibilità

Chi gestisce più Cloud-Accounts/Subscriptions/Projekte ha bisogno di una struttura progettata consapevolmente. Una „Landing Zone“ (ambiente base preconfigurato con rete, Identity, logging, policy) dovrebbe essere l’unica via per configurare nuove ambienti con orientamento alla produzione. Senza Landing Zone nascono mondi paralleli: logging separato, regole IAM proprie (Identity and Access Management, cioè gestione di diritti e ruoli), percorsi di rete separati.

Linee guida pratiche:

• Nuove Subscriptions/Accounts solo tramite una procedura centralizzata di richiesta con dati obbligatori (Owner, CostCenter, scopo, data di fine).
• Vista centralizzata di fatturazione: tutti gli account devono essere gestiti sotto un’unica organizzazione/Billing-Entity, altrimenti lo Showback diventa inaffidabile.
• Connessione di rete standardizzata (Hub-and-Spoke o equivalente), in modo che i flussi di dati, il firewalling e i costi di egress rimangano controllabili.

2) Identità & accesso: rendere i carichi di lavoro ombra „scomodi“

Molti carichi di lavoro ombra nascono perché singole persone possono sperimentare con permessi estesi. Un modello robusto si basa su:

• Least Privilege (privilegi minimi) e ruoli invece di diritti amministrativi individuali.
• Just-in-Time-Access (diritti amministrativi limitati nel tempo): l’accesso admin viene attivato solo quando necessario e viene registrato.
• Service Accounts (identità tecniche) con chiara rotazione di secret/chiavi e assegnazione tracciabile ai carichi di lavoro.

Oltre al vantaggio in termini di sicurezza c’è un effetto sui costi: se i carichi di lavoro non nascono „così, per caso“ come istanze permanenti, la proliferazione incontrollata diminuisce. Inoltre i processi di audit e gestione degli incidenti diventano più semplici, perché le responsabilità sono rintracciabili.

3) Budget, quote e policy: binari automatizzati invece di appelli

I budget sono disponibili in molte cloud come meccanismi di allarme e di blocco. Dovrebbero esistere non solo a livello mensile complessivo, ma anche per ambiente e per team. Le quote (contingenti) limitano, ad esempio, il numero o la dimensione di determinate risorse. Le policy possono bloccare risorse che violano gli standard (es. „nessuna Public IP in Prod“, „Storage solo cifrato“, „nessun Kubernetes-Cluster senza collegamento di logging“).

Importante è l’equilibrio: policy troppo stringenti inducono all’elusione. Una pratica consolidata è „Audit-Mode → Avviso → Blocco“, cioè inizialmente segnalare, poi avvisare (con scadenza) e solo successivamente bloccare.

4) Capacità di spegnimento come principio architetturale

La misura più incisiva contro i costi ombra è un’architettura che permetta lo spegnimento. Nella software aziendale i tipici generatori di costi sono componenti sempre attive: worker, scheduler, servizi di integrazione, database di test, indici di ricerca.

Leve pragmatiche:

• Programmazioni per Non-Prod: Dev/Test viene fermato automaticamente al di fuori degli orari definiti. Presupposto: applicazioni e database devono „avviarsi correttamente“ (nessuna operazione manuale come Single Point of Failure).
• Separazione tra batch e online: l’elaborazione batch (es. import dati, estrazioni di reporting) può essere eseguita in finestre temporali limitate. Questo riduce la necessità di capacità 24/7.
• Design basato su eventi invece di polling: il polling (interrogazioni continue) genera un carico permanente. Eventi/code (file di messaggi) consentono di scalare in base alla domanda. Una coda è un buffer che assorbe i picchi di carico e disaccoppia l’elaborazione.

L’effetto non è solo economico: la capacità di spegnimento migliora la manutenibilità. Se un sistema viene riavviato regolarmente, dipendenze nascoste (es. file di stato locali, script di avvio non idempotenti) emergono prima — prima che diventino rilevanti in caso di disaster recovery.

Leve di costo nel dettaglio: cosa conviene davvero (e cosa è rischioso)

Dopo l’assegnazione e le linee guida viene l’ottimizzazione. Importante: la riduzione dei costi non deve generare costi operativi nascosti (più incidenti, peggioramento delle pRESTazioni, tempi di ripristino più lunghi).

Rightsizing: allineare la capacità al fabbisogno reale

Per Rightsizing si intende adattare le dimensioni delle istanze, i tier di database o la capacità dei cluster al carico misurato. È banale, ma spesso fallisce per mancanza di metriche o per timore di cali di pRESTazioni.

Suggerimento pratico: Rightsizing solo con finestra di misurazione e piano di rollback. Se, per esempio, ridimensionate una banca dati, avete bisogno di limiti chiari (CPU/IO/latency) e di una via di ritorno che non richieda giorni. Nei sistemi critici per il business una strategia Blue/Green o di Scale-up/Scale-down (due livelli di capacità pronti in parallelo) è spesso più sicura del „ridurre una volta e sperare“.

Reserved Instances/Savings Plans: un impegno finanziario richiede stabilità tecnica

Le prenotazioni e i Savings Plans riducono i costi, ma vincolano a ipotesi su durata e carico di base. Convengono soprattutto per carichi stabili e di lunga durata (es. database di produzione, capacità di base dei server applicativi). Diventa rischioso se le decisioni architetturali sono ancora aperte (es. migrazione da VM a container) o se il workload varia fortemente.

Una buona regola pratica: prima misurare e consolidare (Tagging, possibilità di spegnimento, Rightsizing), poi impegnarsi finanziariamente. Altrimenti alla fine riserverete risorse sovradimensionate.

Storage, Logs, Backups: driver di costo silenziosi con implicazioni di compliance

I costi di storage raramente sono spettacolari, ma sono duraturi. Particolarmente insidiosi sono i log e i backup, perché sono considerati una „rete di sicurezza“. Qui servono regole chiare:

• Retention in base al livello di protezione: non tutti i sistemi richiedono lo stesso periodo di conservazione. I log rilevanti per audit e i log di debug tecnici vanno separati.
• Lifecycle Policies: passaggio automatico a classi di storage più economiche o cancellazione al termine dei termini.
• Strategia di backup con test di RESTore: un backup mai testato è solo una fattura. I test di RESTore sono anche un controllo dei costi, perché rendono visibili i volumi di dati e i tempi di esecuzione.

Importante: una retention più breve non deve contraddire obblighi di conservazione legali o la compliance interna. Per questo FinOps e la sicurezza delle informazioni dovrebbero definire insieme le linee guida.

Dalla unità di costo all’interfaccia: il controllo dei costi richiede tracciabilità tecnica

In paesaggi consolidati i costi cloud sono spesso legati a pattern di integrazione. Un esempio: una soluzione software prossima al processo importa quotidianamente dati via SFTP, li trasforma in un job ETL e li scrive in un Data Warehouse. Se l’import fallisce per format drift, partono i ritentativi, le aree di buffer crescono, i log esplodono e alla fine risorse di calcolo e storage diventano costose – senza che emerga un „maggior valore“.

Questo dimostra: il controllo dei costi è strettamente collegato alla qualità operativa. Alcuni interventi che in pratica producono rapidamente effetti:

• Monitoraggio con correlazione ai costi: non solo „servizio giù“, ma „costi/giorno per workload“ e „aumento dei costi correlato all’errore“.
• Idempotenza e ritentativi controllati: le interfacce devono tollerare ripetizioni senza duplicare i dati. Questo riduce workarounds di emergenza e carico inutile.
• Dead-Letter-Queues (code per messaggi di errore): invece di ritentativi infiniti, i messaggi falliti vengono separati. Questo protegge stabilità e costi.

Misure di questo tipo non sono una „giocata FinOps“, ma maturità operativa classica. Rendono le spese cloud più prevedibili e non dettate da stati di errore.

Un piano pragmatico di 60 giorni per tenere sotto controllo i costi cloud

Se oggi avete scarsa trasparenza conviene procedere per step. Un piano realistico per 60 giorni (senza un Big Bang) assomiglia spesso a questo:

Fase 1 (settimane 1–2): visibilità e standard minimo

• Identificare i Top-10 driver di costo (servizi/account/sottoscrizioni).
• Definire uno schema di tagging e limitarlo ai campi obbligatori.
• Realizzare il primo report di showback: costi per applicazione/proprietario/ambiente.
• Attivare l'“alert anomalie“ (rilevamento picchi di costo).

Fase 2 (settimane 3–6): enforcement e riduzione dei shadow-workloads

• Policy: risorse senza tag obbligatori solo tramite processo di eccezione.
• Budget per team/ambiente, con percorso di escalation.
• Pilotare finestre di spegnimento per non-prod (es. un team di prodotto).
• Hygiene delle identità: limitare i privilegi admin e introdurre accesso Just-in-Time.

Fase 3 (settimane 7–8): ottimizzazione con garanzia operativa

• Prioritizzare i candidati al rightsizing, ciascuno con finestra di misurazione e rollback.
• Definire retention e lifecycle per log/backup/storage.
• Valutare Reserved/Savings solo per workload di baseline stabili.

Decisivo è che ogni fase produca un risultato sostenibile in esercizio: meno proliferazione incontrollata, meno sorprese, responsabilità più chiare.

Conclusione: il controllo nasce da assegnazione, paletti tecnici e possibilità di disattivazione

I costi cloud sono governabili nel tempo solo se convergono tre elementi: assegnazione chiara (tagging e allocazione dei costi), processi vincolanti (ritmo FinOps con decisioni) e paletti tecnici (policy, budget, regole sull’identità e un’architettura che permetta la disattivazione). I workload in ombra non scompaiono con appelli, ma con regole di ingresso e uscita chiare: chi crea risorse deve indicare ownership, scopo e durata – e il team operativo deve poter reagire in modo consequenziale in caso di violazioni.

Se volete mettere i costi cloud sotto controllo senza destabilizzare l’operatività, conviene un approccio graduale con responsabilità chiare e pochi standard severi. Se vi serve supporto su modello di costo, governance o sull’applicazione tecnica, parlate con noi:

Anche per questo tema sono rilevanti il Cloud Tagging e lo Shadow IT. L’articolo inquadra questi aspetti in modo chiaro e illustra su cosa occorre concentrarsi nella pratica quotidiana.

Discutere un progetto o un intervento di modernizzazione con Net-Base.