VPS o server dedicato: quale si adatta davvero al tuo carico di lavoro

La macchina sembra a posto. Il load average è ragionevole, la memoria non è esaurita, il disco ha spazio. L'applicazione resta lenta alle 9 di ogni giorno feriale e nessuno sa dire perché. Oppure ti hanno dato una frase al posto di una metrica: "per questo ti serve hardware dedicato".

La questione VPS o server dedicato si decide su un piccolo numero di segnali misurabili. Per esperienza, la maggior parte dei carichi di lavoro che arrivano qui non ne fa scattare nessuno. Entrambi gli acquisti sono legittimi, e un server dedicato è la risposta giusta quando valgono condizioni precise.

La versione breve

• Il passaggio a hardware dedicato è giustificato quando scatta un segnale preciso, non quando una macchina sembra semplicemente lenta.
• Contano tre segnali operativi: utilizzo CPU sostenuto senza margine residuo, steal time della CPU o IO wait persistenti, e un carico di lavoro che ha superato l'istanza più grande venduta da un provider.
• Due di quei tre segnali sono spesso causati dal provider o dal piano, non dalla virtualizzazione. Verificalo prima di spendere.
• PCI DSS e la HIPAA Security Rule specificano risultati di isolamento e controllo, non un formato hardware. Nessuno dei due, da solo, richiede una macchina fisica.
• L'hardware dedicato vince sul costo solo con un utilizzo sostenuto elevato. Sotto quella soglia, paghi un pavimento hardware fisso che non stai usando.

Che cosa cambia tra un VPS e un server dedicato

Prendi un piano pubblicizzato con 4 vCPU. Su un server dedicato, quattro core sono tuoi che tu li usi o no. Su un VPS, quattro vCPU sono una promessa di scheduling: l'hypervisor presenta quattro processori virtuali al tuo kernel e concede loro tempo su core fisici secondo la propria policy e il carico attuale dell'host.

In condizioni normali i due si comportano allo stesso modo. In contesa, no.

La differenza non è virtuale contro fisico. È tra ciò che ti è garantito e ciò che ti è assegnato.

Il modello di isolamento segue la stessa divisione. Un VPS è isolato logicamente, dall'hypervisor: kernel separato, spazio di memoria separato, dischi virtuali separati, imposti da software che gira su silicio condiviso. VPS contro bare metal è una differenza su dove si traccia quel confine, non sul fatto che ne esista uno.

Entrambi sono isolamento reale. Falliscono in modo diverso e vengono auditati in modo diverso, il che conta nella sezione conformità più avanti.

L'overhead dell'hypervisor ormai raramente è la spiegazione. Su KVM moderno con estensioni di virtualizzazione hardware e driver paravirtualizzati, non ho mai trovato che l'hypervisor fosse il motivo per cui un'applicazione era lenta.

Se un VPS rende meno del previsto, la causa abituale è la contesa o il dimensionamento.

La variabile interessante vive nella contesa, ed è una policy del provider, non una proprietà della virtualizzazione. L'oversubscription significa vendere, tra tutti gli ospiti, più vCPU, più IOPS o più memoria di quanta l'host ne abbia fisicamente, dando per scontato che non tutti raggiungano il picco insieme. Alcuni provider lo fanno appena. Altri lo fanno in modo aggressivo.

La conseguenza è scomoda per chi compra solo in base alla categoria. Un VPS gravemente sovravenduto e un VPS ben gestito sono più distanti nel comportamento di quanto lo siano un VPS ben gestito e un server dedicato.

L'hosting condiviso non rientra in questo confronto: niente accesso root e nessuna garanzia di risorse costante, e la nostra guida spiega quando passare dall'hosting condiviso al VPS se quel passaggio viene prima per te. La colocation resta fuori dal perimetro. Compri e possiedi l'hardware, che è un altro modello di acquisto, con contratti diversi e una storia diversa quando qualcosa si rompe.

I segnali che hai superato un VPS

Sono verifiche sulla tua telemetria, non regole empiriche sul tuo settore. Una condizione governa tutte e tre: un segnale conta solo quando è sostenuto.

Una macchina inchiodata al 95 % di CPU durante una finestra di backup notturna si sta comportando bene. Una macchina inchiodata al 95 % di CPU per quindici giorni ti sta dicendo qualcosa.

Utilizzo CPU sostenuto senza margine

La condizione da osservare è una media mobile su giorni o settimane che non lascia spazio per assorbire un picco di traffico, un processo impazzito o una dipendenza lenta. Non una lettura di picco. A quel punto i tempi di risposta degradano in modo non lineare invece che dolcemente, e il prossimo incidente non ha dove andare.

La forma del carico sposta quella linea. Un consumer di coda costante vicino al suo tetto è più vicino ai guai di un tier web a raffiche che fa picco due volte al giorno e per il resto sta fermo. Leggi la tua curva invece di un numero preso dalla pagina di un fornitore.

Essere CPU-bound non è la stessa cosa che avere bisogno di hardware dedicato. Il primo caso si risolve spesso dentro la virtualizzazione: un'istanza più grande, o una a clock più alto quando il carico è single-thread e sensibile alla latenza.

Conferma quale dei due casi hai prima di chiedere il prezzo di una macchina fisica. Un'applicazione single-thread non diventa più veloce su 32 core.

Steal time e IO wait

Lo steal time della CPU è la percentuale di tempo in cui il tuo processore virtuale era pronto a eseguire e l'hypervisor ha dato il core fisico a qualcun altro. È il numero che distingue un carico troppo grande da un host troppo pieno.

Non trattare una specifica percentuale di steal time come una soglia. Guarda l'andamento sulla tua macchina. Vicino allo zero con sbalzi occasionali è normale. Costantemente diverso da zero e in salita significa che l'host è in contesa.

Sostenuto e alto su un carico sensibile alla latenza significa che vieni scavalcato nello scheduling, e a pagarne il prezzo è l'applicazione.

Consiglio: lancia vmstat 1 30 e osserva la colonna st nel blocco CPU; top riporta lo stesso valore come %st. Prendi la misura nelle tue ore di punta reali, non una volta a mezzanotte. Un host in salute si presenta così:

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 412332  84120 1932144    0    0     0    12  842 1503 21  4 75  0  0
 2  0      0 411980  84120 1932148    0    0     0     0  901 1622 24  5 71  0  0

Uno in contesa si presenta così, e il tempo mancante è nell'ultima colonna:

 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 4  0      0 288104  61228 1104996    0    0     8   140 1502 2210 31  6 45  1 17
 5  0      0 287960  61228 1105004    0    0     0     0 1610 2388 29  7 44  2 18

Uno steal time alto significa che questo host è sovravenduto. È un'affermazione sul tuo provider e sul tuo piano, non sulla virtualizzazione. La prima risposta corretta è passare a un host meglio dimensionato o a un piano con allocazione vCPU dedicata. Lasciare la virtualizzazione viene dopo, non al posto di questo.

Se il tuo riscontro è lo steal time, la diagnosi di sovravendita prima pista da seguire.

Ho spostato due carichi di lavoro fuori da un VPS per questo motivo. Nessuno dei due era CPU-bound. Entrambi stavano su host venduti oltre la loro capacità, e a uno è bastato un provider diverso.

Il tetto di scalabilità

Hai toccato il tetto quando l'istanza più grande venduta dal provider non contiene più il carico, o quando l'ultimo scatto verticale ha portato un miglioramento nettamente inferiore al precedente. Il secondo caso sfugge facilmente. Se raddoppiare l'istanza ha comprato un 20 % di miglioramento, il collo di bottiglia si è spostato dove più vCPU non arrivano.

I trigger lato storage sono quelli che sopravvivono più spesso all'indagine, e di solito arrivano travestiti da database. Il vincolo raramente è il motore. È IO casuale sostenuto su un pool che condividi con sconosciuti.

Qualsiasi carico che legge e scrive blocchi piccoli in continuazione (un database impegnato, una coda con persistenza durevole, un servizio ricco di log) spinge quel pool proprio con lo schema che regge peggio.

Osserva %wa e i tuoi percentili di latenza durante il picco di carico reale. Se la latenza varia in modi che il tuo carico non spiega, stai facendo la coda dietro ad altri tenant, e dei dischi che ti appartengono sono la soluzione affidabile.

Due di questi tre segnali di solito si risolvono senza uscire dalla virtualizzazione, e verificarlo costa meno che comprare hardware.

Quando la conformità richiede hardware dedicato

Un auditor scrive "l'ambiente dei dati dei titolari di carta deve girare su hardware dedicato" e la frase fa due lavori diversi a seconda di chi la legge. Per un professionista della conformità di solito significa un ambiente isolato dagli altri carichi e con un perimetro stretto. Per chi compra hosting sembra una categoria di prodotto.

È nel divario tra queste due letture che il budget se ne va senza alcun guadagno in termini di controllo.

Sia PCI DSS sia la HIPAA Security Rule specificano risultati di isolamento e controllo invece di un formato hardware. Se il tuo requisito è che un insieme definito di sistemi sia segmentato, con accessi controllati, tracciato e valutabile in modo indipendente, un ambiente virtuale ben segmentato lo soddisfa. Se il tuo requisito è che nessun codice di un altro tenant giri sullo stesso silicio, lo soddisfa solo l'hardware fisico.

Stabilisci quale delle due frasi ti è stata consegnata prima di far prezzare qualsiasi cosa.

Per PCI DSS il concetto operante è il perimetro. La stessa guida del Security Standards Council su perimetro e segmentazione di rete fissa come posizione di partenza che tutto è nel perimetro finché non si verifica il contrario. Descrive la segmentazione come uno dei metodi che possono ridurre il numero di componenti di sistema nel perimetro. Quel supplemento non nomina alcun formato hardware in nessun punto del suo testo.

Un ambiente virtuale segmentato male può comunque trascinare nel perimetro molta più parte del tuo stack di quanta ne avessi messa a budget. Quello è il costo di farlo male, non un argomento per non farlo.

HIPAA è più esplicita nel dirsi basata sui controlli. Il testo della disposizione sulla flessibilità di approccio della HIPAA Security Rule, come pubblicato dalla Cornell Law School, afferma che le entità coperte e i loro partner commerciali possono usare qualsiasi misura di sicurezza che consenta loro di attuare gli standard in modo ragionevole e appropriato. La scelta si valuta rispetto alla dimensione dell'organizzazione, all'infrastruttura tecnica, al costo e al rischio. È un test di adeguatezza, non una specifica di apparecchiature.

Per un deployment ospitato il requisito operante è di solito contrattuale. Il testo del 45 CFR § 164.308(b)(1) pubblicato dalla Cornell Law School afferma che un'entità coperta può lasciare che un partner commerciale tratti informazioni sanitarie protette in forma elettronica solo dopo aver ottenuto garanzie soddisfacenti che saranno tutelate in modo adeguato. Un provider che non firma un accordo di partner commerciale si squalifica da solo, qualunque aspetto abbia il suo hardware.

Alcuni casi vanno solo in dedicato. Un contratto con un cliente che prescrive per iscritto l'isolamento fisico è uno di questi.

Un altro è un controllo che non puoi attuare senza accesso all'hardware: cifratura completa del disco con una chiave custodita in un TPM che controlli tu, secure boot verificato, o una baseline del firmware che attesti in prima persona. In quei casi, compra l'hardware e smetti di valutare.

Consiglio: prima di accettare "hardware dedicato" come requisito, chiedi a chi l'ha scritto quale controllo implementa e a quali sistemi si applica. Spesso la risposta è un ambiente isolato circoscritto all'ambiente dei dati dei titolari di carta, non un prodotto chiamato server dedicato. I cartellini del prezzo sono molto diversi.

Gli esiti di conformità dipendono dal tuo valutatore e dal tuo perimetro specifico. Questo ti dà la domanda giusta da porgli, non una decisione da citargli contro.

Dove si incrociano le curve di costo

Dedicated hardware looks cheap per core, and at sufficient scale it is. Across providers publishing public bare metal pricing, entry configurations in the 6-core, 32 GB class typically start from around $150 to $200 per month, while 24-core, 256 GB machines with multi-terabyte NVMe commonly start from $450 and up.

Those are typical list-price ranges as of August 2026, not a market average. Price your own shortlist.

Guarda la forma invece dei numeri assoluti. Il prezzo di un VPS è quasi lineare rispetto alle risorse assegnate e di fatto non ha un pavimento, ed è per questo che un'istanza da 1 GB costa pochi dollari. Il prezzo del dedicato parte da quanto costa un'intera macchina fisica e poi sale lentamente, perché il costo marginale di più core dentro uno chassis che già affitti è basso.

Due rette con pendenze diverse e intercette diverse si incrociano in un punto.

È l'utilizzo a decidere da che parte di quell'incrocio ti trovi. La retta del dedicato è fissa: paghi per 24 core sia che ne usi 24 sia che ne usi 4.

Una macchina dedicata al 20 % di utilizzo costa di più per unità di lavoro svolto rispetto a un VPS ben dimensionato, anche quando la fattura è più bassa per core. Il denominatore è ciò che hai consumato, non ciò che ti hanno venduto.

Il punto di incrocio non è "sopra N core". È "sopra N core che tieni occupati".

Tre costi non compaiono su nessuna delle due fatture e appartengono comunque al confronto:

• Tempo di provisioning. Un VPS è disponibile in minuti. L'hardware fisico si ordina, si monta in rack e si consegna in ore o giorni. Quella attesa è un vincolo di capacity planning, non un fastidio una tantum.
• Niente scale-down. Dopo un picco di traffico puoi rimpicciolire un VPS. Un server dedicato è un impegno mensile a piena taglia fino alla fine del periodo contrattuale.
• Guasto hardware. Quando su un VPS ti cede l'host sotto i piedi, è il provider a migrarlo o ripristinarlo. Quando nella tua macchina dedicata cede un disco o un alimentatore, la via di ripristino è un ticket di supporto e un restore da backup, con il downtime che pesa sul tuo SLA.

Quando un VPS resta la risposta giusta

Nessun segnale è scattato. L'utilizzo ha margine, lo steal time è piatto, il tetto della dimensione dell'istanza è lontano, nessun contratto impone isolamento fisico e il tuo consumo non è neanche vicino all'incrocio dei costi. Resta virtualizzato.

Quella è una capacità, non un premio di consolazione. Gli snapshot rendono un upgrade reversibile e una migrazione rischiosa testabile. Istanze piccole separate ti danno separazione degli ambienti a un prezzo che rende lo staging degno di esistere.

E il guasto hardware delle 3 di notte è di qualcun altro, cosa che per un team piccolo vale più di un delta in un benchmark.

Il divario si è ridotto, ed è un cambiamento nella tecnologia, non un argomento di vendita. I piani con vCPU dedicata, NVMe come impostazione predefinita e driver paravirtualizzati ormai maturi hanno eliminato quasi tutta la distanza pratica di prestazioni per i carichi tipici.

La longevità del provider va nella rosa dei candidati accanto alle specifiche. Un piano VPS che puoi lasciare in un pomeriggio porta meno rischio fornitore di un contratto hardware da dodici mesi. Questo vale solo se il provider al nono mese esiste ancora e risponde ancora ai ticket. Controlla da quanto opera, come pubblica lo storico degli incidenti e come risponde il supporto prima di un disservizio anziché durante.

Esiste anche l'hosting dedicato gestito, che baratta il controllo dell'hardware con un carico operativo minore, il che sta sullo stesso asse della scelta tra gestito e non gestito un gradino più in basso.

Restare su un VPS è una decisione attiva, con un proprio percorso di escalation, non l'impostazione predefinita in cui finisci per non aver scelto.

Se la tua diagnosi è stata contesa e non capacità, l'acquisto di cui stiamo parlando è un VPS, non uno chassis. Quello che vuoi da esso è la libertà di ridimensionarti di nuovo dopo l'evento che ti ha spinto fin qui. È esattamente il caso per cui costruiamo: il nostro Linux VPS gira su storage NVMe con uno SLA di uptime del 99,95 % e fatturazione oraria. Provare un'istanza più grande o a clock più alto ti costa un pomeriggio invece di un contratto. Dimensionalo rispetto alle soglie qui sopra, fagli attraversare il tuo picco reale e ricontrolla lo steal time.

Domande frequenti

Quanto è più veloce un server dedicato rispetto a un VPS?

Dipende dalla risorsa per cui stai competendo. Con la virtualizzazione moderna il divario di CPU su un host ben dimensionato è piccolo, perché l'overhead dell'hypervisor è minimo con le estensioni di virtualizzazione hardware. Le differenze affidabili sono l'assenza di contesa IO e di rete, e si manifestano come costanza della latenza più che come velocità pura. Se il tuo carico al picco non contende mai disco o rete, aspettati un divario troppo piccolo per decidere l'acquisto.

Un VPS basta per un database di produzione?

Per la maggior parte dei database di produzione, sì. Il vincolo determinante di solito è IO casuale sostenuto su storage condiviso, non il motore del database. Un database che legge e scrive blocchi piccoli in continuazione raggiunge il limite di un pool condiviso molto prima di raggiungere quello del motore. Dischi dedicati eliminano quel limite; un'istanza più grande no.

PCI DSS richiede un server dedicato?

No, non come regola generale. PCI DSS specifica requisiti di isolamento e controllo circoscritti all'ambiente dei dati dei titolari di carta, non un formato hardware. La guida sul perimetro del Security Standards Council considera tutto dentro il perimetro finché non si verifica il contrario e descrive la segmentazione di rete come un metodo per ridurre i sistemi nel perimetro. Un ambiente virtuale ben segmentato può soddisfarlo; uno segmentato male trascina nel perimetro molta più parte del tuo stack.

Come faccio a sapere se il mio VPS ha un problema di vicino rumoroso?

Il sintomo è una prestazione incostante al picco su una macchina che per il resto non è carica: tempi di risposta che oscillano mentre il tuo carico, la memoria e l'uso del disco restano piatti e senza nulla di notevole. Nelle ore tranquille sembra tutto normale, ed è per questo che il problema sopravvive così a lungo senza diagnosi. La causa sta sull'host fisico che condividi, quindi la soluzione è un piano meglio dimensionato o un altro provider, non riscrivere la tua applicazione.

Quando conviene passare da un VPS a un server dedicato?

Upgrade when at least one of these holds: CPU utilization sits at a rolling-average level that leaves no headroom for a traffic event; steal time or IO wait stays high after you have already tried a better-provisioned plan; the workload has outgrown the largest instance your provider sells; a contract or a control genuinely requires physical isolation; or sustained utilization is high enough that a fixed hardware cost beats per-resource pricing.