La decisione tra un proprio data center e il cloud oggi è meno ideologica che economica. La parola chiave di riferimento Rechenzentrum vs. Cloud TCO apre questo contributo, perché il Total Cost of Ownership (TCO) deve fornire il criterio decisionale centrale — ma solo se calcolato in modo completo, conforme ai periodi di competenza e verificabile in sede di audit. Questo articolo fornisce un modello decisionale pragmatico, indicatori concreti, checklist per compliance e governance e una roadmap attuabile per decisioni di migrazione.
Perché un modello TCO formale è importante
Una valutazione dei costi superficiale porta rapidamente a decisioni errate. Molti decisori confrontano solo i prezzi orari del cloud con l’ammortamento dell’hardware attuale e trascurano:
- costi operativi continui (personale, supporto 24/7, monitoring),
- costi energetici e delle facility inclusi raffreddamento e PUE (Power Usage Effectiveness — misura dell’efficienza del data center),
- costi di rete e di transito, in particolare per i trasferimenti di dati (egress),
- costi per rischio e compliance (p.es. certificazioni, obblighi di rendicontazione, maggiori oneri di audit),
- costi di migrazione e trasformazione nonché costi una tantum per refactoring, integrazione e test.
Solo un modello completo consente di rendere visibili i costi nascosti e di prendere in modo appropriato la decisione tra data center proprio e cloud.
Rechenzentrum vs. Cloud TCO: Struttura di base del modello
Il modello decisionale suddivide la TCO in tre orizzonti temporali e tre classi di costo:
- Orizzonti temporali: a breve termine (1 anno), medio termine (3 anni), lungo termine (5 anni).
- Classi di costo: CapEx (costi di investimento), OpEx (costi operativi ricorrenti) e costi di rischio (guasti, compliance, sicurezza).
- Vista per workload: TCO per applicazione/service, non solo per l’unità del data center.
Ne risulta una matrice in cui ogni cella contiene indicatori concreti (p.es. CapEx per TB, OpEx al mese per vCPU, costi attesi per interruzioni all’anno) — questa matrice è la base per analisi NPV e di sensitività.
Assunzioni fondamentali e limiti dell’ambito
Importante: definite l’ambito e le assunzioni prima di iniziare il calcolo. Elementi tipici nella definizione dell’ambito di progetto sono:
- Quali workload vengono considerati? (Produzione, test, backup, archivio)
- Orizzonte temporale dell’analisi (preferibilmente 3 o 5 anni)
- Livello di servizio / requisiti SLA
- Sovranità geografica dei dati / requisiti normativi
Componenti TCO: elementi di costo dettagliati
Di seguito i singoli blocchi di costo con tipiche grandezze misurate e indicazioni per la raccolta dati.
1. Infrastruttura e facility (CapEx)
Si tratta di acquisizioni per server, storage, rete, UPS, rack e sicurezza fisica. Indicatori rilevanti:
- CapEx per rack fisico o per TB di capacità utilizzabile
- Periodo di ammortamento (tipico 3–5 anni)
- Costi di deployment una tantum (installazione rack, cablaggio, attività di setup)
2. Energia, raffreddamento e Facility‑OpEx
Metriche: costi annui dell’energia, PUE, gestione cold‑aisle/hot‑aisle, costi immobiliari. L’energia è spesso il fattore sottostimato per il TCO on‑premises.
3. Personale e sforzi operativi (OpEx)
Il personale comprende amministrazione di sistema, team storage e rete, security‑ops, incident management. KPI tipici:
- Quote di FTE per 1000 server o per X vCPU
- Costo per FTE inclusivo di oneri
- Contratti di outsourcing (p.es. facility management) come costi ricorrenti
4. Software, licenze e subscriptions
I modelli di licenza (per socket, per vCPU, per utente) devono essere confrontati per piattaforma. Trappole particolari sono:
- Regole di License Mobility dei fornitori (p. es. alcuni produttori non consentono l’utilizzo delle licenze on‑premise nel cloud)
- Costi per software di gestione e backup
5. Rete, transito ed egress
I provider cloud addebitano spesso il data egress (dati in uscita) per GB. In sede on‑premise possono verificarsi costi di transito, ridondanza ISP o linee MPLS. KPI: costi per TB/mese per egress vs. costi di transito on‑premise.
6. Sicurezza, Compliance e Audit
Costi per penetration test, gestione ISMS, log‑retention (storage), crittografia, key‑management, evidenze di verifica. Considerare requisiti normativi specifici (p. es. DSGVO, NIS2) e l’eventuale incremento di lavoro nella raccolta delle prove per gli auditor.
7. Costi di rischio e di indisponibilità
Quantificare i danni annui attesi (ALE — Annualized Loss Expectancy). Ciò include perdite dirette da indisponibilità, penali SLA, costi reputazionali e oneri di personale aggiuntivi per il ripristino. Spesso si utilizza un modello probabilistico per questo.
8. Costi di migrazione e trasformazione
Costi una tantum per replatforming, refactoring, migrazione dei dati, test nonché, se necessario, adeguamenti delle licenze. Questi costi possono essere elevati e devono essere distribuiti su più anni per garantire la comparabilità.
Indicatori concreti (KPI) per la decisione
I seguenti KPI dovrebbero essere almeno inclusi in ogni matrice decisionale:
- TCO per anno e per 3/5 anni
- TCO per workload / per business‑unit
- Quota CapEx/OpEx
- Costi per vCPU‑mese / costi per TB‑mese
- PUE (solo per on‑premise)
- Impegno in FTE per x workload
- Costi annuali attesi per indisponibilità (ALE)
- Costi di egress per TB
Standardizzare le metriche affinché i confronti tra workload siano possibili. Valori di esempio (ipotetici) aiutano la comprensione, ma non sostituiscono i vostri dati di misura.
Esempio di un calcolo TCO semplice (ipotetico)
Supponiamo che un workload provochi nel data center i seguenti costi annui:
- Ammortamento CapEx: 80.000 € / anno
- Energia e facility: 20.000 € / anno
- Personale e operazioni: 60.000 € / anno
- Software e licenze: 30.000 € / anno
- Costi di rischio (ALE): 10.000 € / anno
- Costi di migrazione (una tantum distribuiti su 3 anni): 30.000 € / anno
Totale: 230.000 € / anno. Un’offerta cloud per i requisiti di prestazione identici potrebbe comportare:
- Compute e storage: 140.000 € / anno
- Egress e rete: 15.000 € / anno
- Servizi gestiti / Supporto: 20.000 € / anno
- Costi di rischio (ALE, tendenzialmente inferiori grazie ai controlli del provider): 6.000 € / anno
- Migrazione distribuita: 10.000 € / anno
Totale cloud: 191.000 € / anno. In questo esempio il cloud risulta 39.000 € più economico all’anno. Decisiva però è l’analisi di sensibilità (vedi sotto) e non solo il valore puntuale.
Modello decisionale: passi, strumenti e fondamento matematico
Un modello robusto segue questi passaggi:
- Raccolta dati: inventario, utilizzo, SLA, requisiti di compliance.
- Categorie: mappare tutti i costi nella matrice (CapEx/OpEx/Rischio/Migrazione).
- Orizzonte temporale e sconto: calcolare il NPV (Net Present Value) su 3–5 anni.
- Scenari: Best‑Case, Base‑Case, Worst‑Case con driver chiave (prezzi dell’energia, turnover del personale, crescita dei dati).
Formula NPV e esempio
Il NPV è la somma dei flussi di cassa scontati su n anni. Formula:
NPV = Σ (Cashflow_t / (1 + r)^t) , t = 0..nr è il tasso di sconto (p.es. costo del capitale o tasso interno di rendimento). Usare in scenari valori di r conservativi (p.es. 6–8%) per aziende statali; per società tech in forte crescita, eventualmente più alti.
Sensibilità — un esempio
Se il TCO cloud nel caso base è del 15% inferiore, ma la decisione è sensibile ai costi di Egress (con +50% di volume di Egress il risultato si inverte), allora la misura è condizionata: verificate modifiche architetturali (p.es. localizzazione dei dati, caching) prima di migrare.
Aspetti finanziari e fiscali
Per la direzione finanziaria, CapEx, OpEx e regole di ammortamento non sono solo numeri ma regole contabili. La scelta tra On‑Prem e Cloud influenza la struttura di bilancio e il timing dei flussi di cassa.
Rilevazione CapEx e ammortamento
L’hardware viene normalmente capitalizzato e ammortizzato secondo la vita utile economica. Ciò incide su EBIT e base imponibile. Le spese cloud sono per lo più costi operativi e riducono immediatamente il risultato operativo. Considerate le regole fiscali e gli obblighi di reporting, in modo che le ipotesi TCO rimangano verificabili in sede di audit.
Chargeback e ricarichi interni
Per responsabilità e disciplina dei costi è importante un modello di Chargeback o Showback. Utilizzate tagging e centri di costo per attribuire i costi per business unit. Un addebito trasparente aumenta l’accettazione delle migrazioni e promuove comportamenti FinOps.
FinOps e monitoraggio continuo del TCO
La decisione sul TCO non è statica. FinOps è un processo operativo che definisce responsabilità sui costi, cadenza di reporting e cicli di ottimizzazione.
- KPI principali: Monthly Run‑Rate, Unused/Idle Ratio, Reservation Coverage, Cost per Business Transaction.
- Alert automatizzati: superamenti di budget, anomalie di Egress, costi di storage insoliti.
- Rituali di governance: cost review settimanali, report mensili del FinOps board, riconciliazione TCO trimestrale.
Calcolo NPV: piccolo script pratico
# Esempio NPV semplice in Python
cashflows = [-100000, 50000, 60000, 70000] # Jahr 0..3
r = 0.07 # Diskontsatz 7%
npv = sum(cf / ((1 + r) ** i) for i, cf in enumerate(cashflows))
print(f"NPV: {npv:,.2f} €")
Ottimizzazione dei costi: lista di controllo e modelli
Per la categoria ottimizzazione dei costi sono centrali misure concrete, modelli e requisiti normativi. Una lista di implementazione concisa:
- Ripulire l’inventario: archiviare o eliminare i dati di test non più necessari.
- Tiering dello storage: dati caldi su SSD, dati freddi su object storage con lifecycle policy.
- Rightsizing: analisi delle istanze non utilizzate e job automatici di downsizing.
- Prenotazioni: valutare impegni per carichi stabili (1–3 anni).
- Strategie spot: impiegarle solo per job batch non critici.
- Ottimizzazione della rete: CDN e edge caching per carichi ricorrenti di Egress.
- Negoziare e documentare limiti contrattuali di Egress.
Per il contesto di audit e compliance documentate ogni ottimizzazione con le ipotesi di costo, il risparmio previsto e la metodologia di misurazione. Così create prove verificabili per finanza e compliance.
Operatività: impatti e adeguamenti necessari
La migrazione modifica il funzionamento, il monitoring e la logica di backup. Adeguamenti concreti:
- Monitoring: integrare le metriche cloud (CloudWatch, Azure Monitor) con le metriche locali; introdurre un tracking SLO uniforme.
- Backup/RESTore: adattare la strategia di backup allo storage cloud, pianificare test di recovery.
- Runbooks & Runbook‑Automation: aggiornare i playbook per incident handling, rollback ed escalation.
- Change‑Management: integrare CI/CD‑pipeline, Infrastructure as Code (IaC) e processi di approvazione.
Esempio: query SQL per l’export di billing cloud per determinare i costi di egress
-- Beispiel für Billing-Exportanalyse (Pseudo-SQL)
SELECT
service_name,
SUM(case when charge_type = 'Egress' then cost_amount else 0 end) AS total_egress_cost,
SUM(cost_amount) AS total_cost
FROM billing_export
WHERE usage_start BETWEEN '2025-01-01' AND '2025-12-31'
GROUP BY service_name
ORDER BY total_egress_cost DESC
LIMIT 50;
Governance: ruoli, responsabilità e percorsi di verifica
Un organo decisionale necessita di responsabilità chiare. Un modello RACI pragmatico:
- Decisore (CIO/dirigenza IT): Accountable — approva budget e strategia.
- Team di architettura IT: Responsible — elabora il modello TCO e gli scenari.
- Compliance/Legal: Consulted — verifica le implicazioni regolamentari.
- Finanza: Consulted — valida le ipotesi, il tasso di sconto e la pianificazione CapEx.
- Security: Informed / Consulted — valuta i rischi residui e i controlli.
Prioritizzazione e roadmap di migrazione (90/180/365 giorni)
La prioritizzazione pratica considera risparmio sui costi, rischio e fattibilità. Procedura in tre ondate:
- 90 giorni (analisi & quick wins): individuare inventario, classificazione e i primi workload con chiaro bilancio di vantaggio economico.
- 180 giorni (pilota & governance): migrazioni pilota con audit‑trail completo, test dei processi di replica, backup e sicurezza.
- 365 giorni (rollout & ottimizzazione): migrazione dei volumi, stabilire regole FinOps, ottimizzazione continua (savings, rightsizing).
Checklist di prioritizzazione
- Vantaggio TCO del workload ≥ 15% su 3 anni → High Priority
- Barriere di compliance assenti o risolvibili tecnicamente → Medium/High
- Sforzo di refactoring > 60% dei costi di migrazione → Low Priority
- Criticità business elevata (+ SLA stringenti) → migrazione conservativa o approccio ibrido
Rischi, insidie e contromisure tipiche
Rischi comuni e come affrontarli:
- Egress dei dati e costi mensili inattesi — Contromisura: limiti di egress, caching, localizzazione dei dati.
- Clausole contrattuali e rischi di exit — Contromisura: clausole per il recupero dei dati, esercitazioni di uscita.
- Mancanza di competenze nel team — Contromisura: training mirati, staff augmentation per la migrazione.
- Over‑Provisioning in cloud — Contromisura: rightsizing, auto‑scaling e strategie di reservation/spot.
- Gap di audit dopo la migrazione — Contromisura: log‑retention, integrazione SIEM, evidence bundle automatizzati.
Audit‑Readiness: documentazione probatoria e evidenze
Per gli auditor dovete dimostrare che l’analisi TCO è solida. Artefatti di evidenza consigliati:
- Export dell’inventario e estratti d’uso
- Esportazioni del cloud billing e analisi SQL
- Copie dei contratti con il provider cloud e i sub-responsabili
- Analisi dei gap di compliance e valutazioni del rischio
- Protocolli di test per il ripristino e il failover
Conclusione: quando la cloud è economicamente vantaggiosa
La cloud offre spesso vantaggi per workload agili e variabili, per esigenze di scalabilità rapida e quando il personale operativo è scarso o costoso. Un data center proprio rimane sensato per applicazioni molto stabili, critiche in termini di latenza o altamente regolamentate, se i modelli TCO comparabili sull’orizzonte temporale desiderato dimostrano questi vantaggi.
Importante è la metodologia: rilevate tutti i blocchi di costo, utilizzate analisi NPV e di sensitività, definite chiari percorsi di governance e audit e priorizzate le migrazioni in base a criteri misurabili. Dopo la migrazione gestite un programma FinOps continuo per validare le previsioni TCO e rendere le ottimizzazioni verificabili. Solo così la decisione tra data center e cloud non diventerà una decisione d’istinto, ma una decisione di economicità solida e sottoponibile ad audit.
Strumenti di approfondimento
Utilizzate i seguenti deliverable come modelli: Inventory‑Export, Compliance‑Checkliste, Migrations‑Scorecard e lo snippet di policy mostrato sopra. Questi artefatti permettono un’analisi rapida e ripetibile e costituiscono la base per i processi FinOps.
Nota: I numeri mostrati qui sono illustrativi. Sostituiteli con i vostri valori misurati ed eseguite una completa analisi di sensitività prima di prendere una decisione finale.
Per questo tema sono inoltre importanti il confronto TCO cloud vs data center e il modello TCO per la migrazione in cloud. L’articolo inquadra questi aspetti in modo comprensibile e mostra cosa conta nella pratica quotidiana.