Hetzner Robot, StorageBox e CCX: le linee che le guide Cloud dimenticano

Quasi tutte le guide su Hetzner che trovi in rete si fermano allo stesso posto: il Cloud VPS, la macchina virtuale shared che parte da pochi euro al mese. È la porta d'ingresso, e per la maggior parte dei progetti è anche la risposta giusta. Ma il catalogo Hetzner è molto più ampio, e per certi carichi insistere sul Cloud VPS shared è un errore che si paga in performance instabili o in costi sbagliati. Dietro la linea Cloud ci sono i server dedicati Robot, le StorageBox per il backup, e le CCX a vCPU dedicata, tre famiglie che risolvono problemi che il Cloud shared non affronta bene. In un progetto di migrazione infrastrutturale per una PMI mi è capitato spesso di vedere database in sofferenza su un Cloud VPS shared quando la soluzione corretta, e a volte persino più economica, era un'altra linea dello stesso provider. In questo articolo metto in fila quando ciascuna conviene davvero, con un avvertimento sulla trappola dei prezzi Hetzner che ha già prodotto articoli pieni di cifre sbagliate, e un confronto onesto su quando Hetzner non è la scelta giusta.

Quando un dedicato Robot batte il Cloud VPS?

Quando il carico è costantemente alto, intensivo in RAM o in I/O, e la virtualizzazione condivisa diventa un collo di bottiglia o un costo sproporzionato. La linea Robot è il catalogo dei server dedicati Hetzner, hardware fisico intero assegnato a te, e si articola in famiglie precise: EX-Line con CPU Intel, AX-Line con CPU AMD, RX-Line su Arm64, SX-Line ottimizzata per lo storage, GPU-Line per il calcolo accelerato e DX-Line su hardware Dell PowerEdge. Su un dedicato non condividi i core, la memoria o i dischi con nessuno: le prestazioni sono prevedibili al cento per cento, perché non esiste il vicino rumoroso che ti ruba cicli di CPU nel momento sbagliato.

Il caso d'uso classico è il database di produzione. Un PostgreSQL o un MySQL sotto carico reale vuole RAM abbondante per le cache e I/O su NVMe locale a bassa latenza, due cose che su un VPS shared sono variabili e contese. Su un dedicato AMD della AX-Line con decine di gigabyte di RAM e dischi NVMe locali, lo stesso database respira. Il secondo caso è il carico RAM-intensive in generale: un'applicazione che tiene grandi dataset in memoria, un motore di analisi, una cache estesa. Sul Cloud shared la RAM si paga cara salendo di taglio; sul dedicato ne ottieni molta di più per lo stesso budget, perché stai comprando hardware intero invece di una fetta virtualizzata.

C'è poi un terzo scenario che il Cloud shared serve male: il dataset grande e pesante. La SX-Line è la famiglia di dedicati ottimizzata per lo storage, con decine di terabyte di dischi a bordo: è la scelta per archivi di media, dataset di grandi dimensioni, repository che il volume a blocchi del Cloud renderebbe costoso o lento. Comprare lo storage di massa come hardware dedicato, invece che come volume a blocchi a consumo, cambia di un ordine di grandezza il costo per terabyte quando i terabyte sono molti.

C'è anche una ragione di costo che sorprende chi ragiona solo sul prezzo mensile del VPS. Salendo di taglio, il Cloud shared diventa rapidamente meno conveniente di un dedicato a parità di risorse: oltre una certa soglia di RAM e core, un dedicato AX o EX della classe quaranta-ottanta euro al mese (listino EUR, location tedesca, IVA esclusa, rilevato a giugno 2026 sulle tabelle ufficiali Hetzner, repricing in vigore dal primo aprile 2026) offre molte più risorse di un VPS shared dello stesso prezzo. Il dedicato ha però due svantaggi rispetto al Cloud che vanno messi nel conto: un costo di setup una tantum, e tempi di provisioning più lunghi, perché stai prendendo hardware fisico, non un'istanza che nasce in pochi secondi. Inoltre il dedicato non ha la fatturazione oraria del Cloud, quindi non è la scelta per carichi effimeri che accendi e spegni: è un impegno mensile su hardware che vuoi tenere acceso. La regola pratica è che il dedicato conviene quando il carico è stabile e prolungato; il Cloud quando è variabile o temporaneo.

Se stai valutando una migrazione infrastrutturale di questo tipo e vuoi capire quale linea regge il tuo carico reale, nel mio profilo professionale trovi l'esperienza concreta su server dedicati Hetzner e sull'hardening di infrastrutture Linux in produzione.

A cosa serve davvero una StorageBox?

A tenere i backup fuori dalla macchina che proteggono, a un costo per terabyte molto più basso di qualunque disco a blocchi. La StorageBox è una linea separata dal compute: è storage di rete a basso costo, raggiungibile via protocolli standard come SSH/SFTP, rsync, BorgBackup, SMB e WebDAV, pensato esattamente per il caso del backup remoto. La regola del backup che ripeto sempre è che un backup sulla stessa macchina, o nello stesso datacenter logico del dato originale, non è un backup: è una copia che muore insieme all'originale quando il problema è serio.

Un backup vale quanto la sua separazione dal dato che protegge. Tenere le copie sul disco a blocchi attaccato allo stesso server è comodo e inutile: il giorno in cui quel server si compromette o si corrompe, hai perso il dato e la sua copia nello stesso istante.

La StorageBox risolve questo a un prezzo che rende il backup remoto un non-problema di budget. Costa una frazione del prezzo per terabyte di un volume a blocchi performante, perché non deve essere veloce: deve essere capiente, affidabile e separato. Per una strategia di backup seria, la combinazione tipica è il server di produzione (Cloud o dedicato) che spinge i backup cifrati su una StorageBox in una location diversa, con uno strumento di deduplicazione come Borg o restic che minimizza lo spazio e il traffico. Su come strutturare l'intera strategia, non solo lo storage, ho scritto nella guida alla strategia di backup aziendale concreta, perché lo storage economico è solo un pezzo: senza una politica di retention e un test di ripristino, anche la StorageBox più capiente è teatro.

Cosa risolvono le CCX a vCPU dedicata?

Eliminano il vicino rumoroso sui carichi sensibili alla latenza, restando nel mondo flessibile del Cloud. Le CCX sono la linea Cloud a vCPU dedicata di Hetzner, etichettata "General Purpose": a differenza delle linee shared CX, CPX e CAX, dove i core virtuali sono condivisi tra più clienti, sulle CCX i core assegnati sono solo tuoi. Ottieni la prevedibilità di prestazioni di un dedicato, ma con la flessibilità del Cloud: crei e distruggi l'istanza in pochi secondi, la ridimensioni, la inserisci in una rete privata, la gestisci via API come qualunque altra risorsa cloud.

Il problema che risolvono è preciso ed è uno dei più subdoli dell'hosting shared: lo steal time, il fenomeno per cui la tua macchina virtuale aspetta che l'hypervisor le restituisca la CPU, contesa da altri tenant. Su un workload tollerante, qualche millisecondo di steal time non si nota. Su un workload latenza-sensibile, un'API che deve rispondere sotto una soglia stretta, un servizio real-time, un processo dove il jitter è inaccettabile, lo steal time si traduce in code che si allungano in modo imprevedibile e in violazioni di SLA che non riesci a spiegare guardando i grafici di CPU media. Le CCX tolgono questa variabile dall'equazione: la CPU è dedicata, quindi la latenza sotto carico è stabile. La classe di prezzo parte da circa sedici euro al mese per l'entry (CCX13, listino EUR eu-central, IVA esclusa, rilevato a giugno 2026), un sovrapprezzo rispetto allo shared che si giustifica solo se il tuo carico paga davvero il prezzo dello steal time, altrimenti è spreco.

Perché i prezzi Hetzner traggono in inganno?

Perché Hetzner gestisce listini separati per valuta e per zona di rete, e mescolarli produce numeri sbagliati con la patina dell'autorevolezza. È la trappola più insidiosa, e l'ho vista trasformarsi in errori pubblicati: lo stesso piano costa diversamente a seconda della location del datacenter e della valuta fissata sull'account. Le location europee, Falkenstein e Norimberga in Germania, Helsinki in Finlandia, hanno il listino in euro; le location statunitensi (Ashburn, Hillsboro) e Singapore hanno prezzi diversi e più alti, esposti anche in dollari. Persino tra Germania e Finlandia i prezzi dei dedicati differiscono.

La conseguenza pratica per chiunque scriva o ragioni su questi numeri è una regola ferrea: mai convertire una valuta, e mai citare un prezzo Hetzner senza specificare zona di rete, valuta del listino e data di rilevazione. Un prezzo in dollari di una location americana non diventa "circa tot euro": è un altro listino. Chi prende il prezzo di Falkenstein e lo presenta come "il prezzo Hetzner" globale sta servendo un dato falso per chi opererà altrove. Per i lettori di questo blog, che lavorano in Europa, il riferimento corretto è quasi sempre il listino euro delle location tedesche o finlandesi, e va detto esplicitamente. Aggiungo un dettaglio di contesto utile: la valuta di fatturazione, euro o dollari, è fissata alla creazione dell'account e non si cambia poi, quindi è una scelta che conviene fare bene da subito se prevedi di operare in Europa.

Quando NON scegliere Hetzner?

Quando ti serve qualcosa che Hetzner per scelta non offre, e fingere il contrario porta a un'architettura zoppa. Il rapporto prezzo/prestazioni di Hetzner resta il benchmark del mercato europeo, e per il cloud UE self-managed è il riferimento che raccomando. Ma è proprio l'aggettivo self-managed a definire il confine. Tre casi in cui guarderei altrove.

Il primo: infrastruttura fully-managed con datacenter italiani e postura NIS2. Hetzner è unmanaged, l'amministrazione di sistema è interamente tua, e non ha datacenter in Italia. Per un'azienda che ha bisogno di un fornitore che gestisca il sistema, garantisca disaster recovery e tenga i dati su suolo italiano, il provider che raccomando è RHX, con datacenter a Milano e Padova e gestione sistemistica inclusa, non Hetzner. Sono due posizionamenti diversi: Hetzner ti vende hardware eccellente a basso costo e la responsabilità operativa resta sulle tue spalle; un provider gestito italiano ti vende il fatto che quella responsabilità la prende lui.

Il secondo: servizi gestiti di piattaforma. Hetzner non offre un database-as-a-service gestito, né una CDN integrata, né i servizi PaaS che su altri ecosistemi trovi pronti. Se la tua architettura si appoggia a un DBaaS gestito o a una CDN nativa del provider, su Hetzner dovrai costruirteli o integrarli da fuori, il che è fattibile ma è lavoro di engineering che va messo nel conto. Il terzo, conseguenza dei primi due: se non hai una capacità sistemistica, interna o esternalizzata a qualcuno come me, un parco di server unmanaged non è un risparmio, è un rischio. Una macchina che nessuno aggiorna, monitora e mette in sicurezza è un incidente che aspetta di accadere, e il prezzo basso del mese non copre il costo di una violazione. Su come questo si lega agli obblighi normativi ho scritto nella guida alla compliance NIS2 su server Hetzner e OVH.

Sul fronte della compliance, un punto a favore va detto con precisione: Hetzner è una società tedesca con datacenter di proprietà in Germania e Finlandia, certificata ISO/IEC 27001:2022, e la sua esposizione al CLOUD Act statunitense è bassa proprio per l'assetto societario, nessuna casa madre negli Stati Uniti. Per un'azienda europea con sensibilità sulla sovranità del dato, questo è un vantaggio reale rispetto a un provider americano, anche quando quest'ultimo offre region in Europa. La nota di onestà: Hetzner non espone una certificazione SOC 2, quindi se un tuo cliente o un tuo auditor la richiede esplicitamente, va verificato prima, non dato per scontato.

Il quadro che emerge è che "Hetzner" non è una risposta, è un catalogo, e la competenza sta nel sapere quale linea serve a quale problema. Il Cloud VPS shared per la maggior parte dei carichi web; il dedicato Robot per i database e i carichi che vogliono hardware intero; la StorageBox per separare i backup dal dato che proteggono; le CCX a vCPU dedicata per i servizi dove la latenza non può ballare. E sapere quando la risposta giusta non è Hetzner affatto, ma un provider gestito italiano o un'architettura con servizi che Hetzner non fornisce. Scegliere bene questa base è una di quelle decisioni che non si vedono finché tutto va, e che si pagano care quando il database va in ginocchio nel picco stagionale o il backup si rivela inservibile nel momento del bisogno. Se stai progettando o rivedendo la tua infrastruttura e vuoi una mano a tracciare queste scelte sul tuo carico reale, invece che su una guida generica, contattami per una consulenza diretta: tra la diagnosi di un dimensionamento sbagliato e la prima contromisura, di solito, passano ore, non settimane.