Cloud repatriation: quando conviene davvero tornare on-premise nel 2026
Non è un trend ideologico: è un calcolo. Ecco i criteri tecnici ed economici per decidere se spostare workload dal cloud a hardware proprio ha senso nel 2026.
Pubblicato il 4 maggio 2026 · 7 min di lettura
Il numero che cambia la conversazione
Dhruv Malhotra, VP Engineering di una SaaS mid-market europea, ha condiviso pubblicamente nel 2024 i costi AWS della sua piattaforma: 2,1 milioni di dollari l'anno per workload che giravano su istanze r6i.4xlarge con utilizzo medio del 68%. Dopo la migrazione parziale su bare-metal propri in colo, la spesa operativa è scesa a 740.000 dollari. Non perché il cloud sia sbagliato. Perché in quel contesto specifico era sbagliato.
Il fenomeno ha un nome: cloud repatriation. Non è un ritorno ideologico all'on-premise degli anni 2000. È una decisione architetturale che nel 2026 alcune organizzazioni stanno prendendo con dati in mano.
Perché il cloud ha smesso di essere automaticamente più economico
La narrativa "cloud = cheaper" reggeva quando le aziende migravano da datacenter sottoutilizzati, mal gestiti, con CAPEX gonfiati da hardware acquistato per il picco. Oggi molte organizzazioni mature hanno workload con caratteristiche opposte:
- Utilizzo stabile e prevedibile: nessun beneficio dall'elasticità, che si paga comunque come overhead nei prezzi.
- Alto rapporto compute/storage: database OLAP, rendering, ML inference. Su cloud il costo per vCPU-ora di istanze ottimizzate per memoria è cresciuto del 12-18% tra 2022 e 2025.
- Egress elevato: trasferire dati fuori da AWS, GCP o Azure costa. Un cluster Kafka con 50 TB/mese di throughput cross-region può generare 4.000-8.000 USD/mese solo di egress.
Il cloud ha ancora senso dove serve elasticità reale, gestione delegata di servizi complessi, o presenza geografica distribuita senza infrastruttura propria. Ma "senso" non è sinonimo di "sempre".
I workload candidati alla repatriation
Non tutto torna on-premise. La decisione si applica a categorie specifiche.
1. Database con pattern di accesso stabile
PostgreSQL o MySQL con 10.000 query/secondo costanti, su db.r6g.4xlarge RDS, costano circa 8.000 USD/mese reserved 1 anno. Un server bare-metal con 256 GB RAM e NVMe in colo di qualità costa 1.200-2.000 USD/mese all-in. Il breakeven si raggiunge in meno di 4 mesi.
Il costo nascosto è la gestione: backup, failover, patching. Ma se hai già un DBA interno, o un partner che eroga quel servizio in white-label, il gap operativo è colmabile.
2. ML inference a volume fisso
Servire un modello da 7B parametri in produzione su GPU A10G su AWS costa circa 1,2 USD/ora per istanza g5.xlarge. Per 730 ore/mese (utilizzo continuo) sono 876 USD per GPU. Due GPU in un server proprio in colo: investimento una tantum di circa 20.000 USD, ammortizzato in 24 mesi. Dal mese 25 in poi il costo marginale è quasi zero.
Se invece il carico è burst-heavy (inferenza solo nelle ore di picco), il cloud rimane superiore.
3. Storage ad alta capacità con accesso frequente
S3 Standard costa 0,023 USD/GB/mese. Per 500 TB sono 11.500 USD/mese, escluso egress e request fee. Uno storage Ceph su hardware proprio, in colo, può scendere a 0,003-0,005 USD/GB/mese all-in. Su 500 TB: risparmio potenziale di 9.000-10.000 USD mensili.
L'architettura ibrida è il punto di arrivo reale
Nessuna organizzazione seria sta tornando al modello datacenter-only del 2005. La repatriation selettiva porta a un'architettura ibrida dove:
- On-premise/colo: compute stabile, storage caldo ad alta capacità, ML inference su GPU proprie.
- Cloud: burst capacity, disaster recovery, servizi managed complessi (Kafka gestito, search, CDN), edge computing.
Un pattern concreto:
[Traffico utente]
|
[CDN cloud] → [Load balancer cloud] → [API layer cloud]
|
[Backend on-premise via VPN/Direct Connect]
|
[DB on-premise] + [Object storage on-prem]
|
[Backup cold su S3 Glacier]Il VPN o Direct Connect introduce latenza (tipicamente 1-3 ms tra un colo europeo e la region cloud più vicina). Per la maggior parte dei backend applicativi non è un problema. Per sistemi real-time sotto i 10 ms end-to-end, va misurato prima di decidere.
Il framework decisionale in 4 domande
Prima di avviare qualsiasi progetto di repatriation, rispondi a queste domande con dati reali:
1. Qual è il tuo utilizzo medio effettivo? Se le istanze cloud sono al di sotto del 50% di utilizzo, hai un problema di sizing prima ancora di avere un problema di dove girare il workload.
2. Il tuo workload ha picchi imprevedibili? Se sì, quantifica il gap tra baseline e picco. Se il picco è 3x la baseline per 200 ore/anno, il cloud conviene solo per il delta: la baseline può tornare on-premise.
3. Hai o puoi avere le competenze interne per gestire l'infrastruttura? Il costo nascosto della repatriation è il personale. Un ingegnere infrastrutturale senior costa 70.000-90.000 EUR/anno in Italia. Se non ce l'hai, devi includerlo nel TCO, oppure esternalizzare la gestione.
4. Qual è il tuo orizzonte di pianificazione? La repatriation richiede CAPEX iniziale (hardware, rack, cablaggio, contratto colo). Se il tuo runway è sotto i 18 mesi o la strategia prodotto è incerta, il cloud offre flessibilità che ha un valore reale.
Cosa non fare
Tre errori comuni osservati nei progetti di repatriation:
- Migrare senza misurare: spostare tutto perché "costa troppo" senza un'analisi workload per workload produce risultati deludenti e spesso peggiora la situazione.
- Replicare il cloud on-premise: comprare bare-metal e poi installarci Kubernetes con un layer di astrazione pesante annulla gran parte del risparmio compute.
- Ignorare la connettività: un colo con uplink da 1 Gbps condiviso è insufficiente per workload I/O-intensivi. Specifica la connettività nel contratto.
Take-away operativo
La repatriation conviene quando: utilizzo stabile oltre il 60%, orizzonte di pianificazione oltre 24 mesi, workload compute/storage-intensivi, competenze infrastrutturali disponibili (interne o in outsourcing). In tutti gli altri casi, ottimizza prima lo spending cloud con Reserved Instances, Savings Plans e rightsizing.
Il punto non è dove gira il codice. È il TCO a 36 mesi, calcolato onestamente.
---
Evviva Group supporta aziende tecnologiche nella progettazione e gestione di architetture ibride in modalità white-label. Se stai valutando un'analisi TCO per un progetto di repatriation, contattaci.