VPS in Canada: quando serve davvero

Il tuo VPS deve trovarsi in Canada?

Scegliere un hosting VPS in Canada è opportuno quando una legge o un contratto stabilisce che i dati devono rimanere sul territorio canadese. Questo è l’unico motivo vincolante. Un andata e ritorno da una connessione domestica di Toronto a un data center di New York richiede circa 18 ms, rispetto a circa 3 ms verso un data center di Toronto; quasi nessuna applicazione web è in grado di rilevare la differenza.

Tre fattori spingono a scegliere un server canadese. La localizzazione dei dati è un obbligo legale e risolve da sola la questione. La latenza è misurabile e di solito è inferiore a quanto ci si aspetta. La fatturazione in dollari canadesi è una comodità per chi gestisce la contabilità. Verifica se il primo fattore si applica al tuo caso prima di valutare qualsiasi altro aspetto.

Questo articolo spiega in generale come funzionano le regole. Non costituisce una consulenza legale. Se alla tua organizzazione si applica una normativa sulla privacy, la risposta deve arrivare dal tuo consulente legale.

Residenza dei dati: l'unico requisito vincolante

Il PIPEDA (Personal Information Protection and Electronic Documents Act) è la legge federale canadese sulla privacy applicabile al settore privato e non impone che le informazioni personali restino nel Paese. Considera l'invio dei dati a un responsabile del trattamento all'estero un trasferimento per il trattamento: la responsabilità dei dati resta a carico della propria organizzazione, il responsabile deve garantire una protezione comparabile e l'organizzazione deve informare gli interessati del trasferimento. Nel 2019 l'Office of the Privacy Commissioner ha consultato gli interessati sulla possibilità di rendere questa regola più stringente, ma ha poi mantenuto la posizione esistente. Il Bill C-36, presentato nel giugno 2026 per sostituire le norme del PIPEDA sul settore privato con una nuova legge denominata Protecting Privacy and Consumer Data Act, a ottobre 2026 non era ancora arrivato alla seconda lettura; pertanto, il PIPEDA resta la legge applicabile. È quindi errata l'affermazione comune secondo cui il PIPEDA impone che i dati risiedano in Canada, anche se molti contenuti promozionali dei servizi di hosting la ripetono.

Esistono effettivamente norme sulla residenza dei dati. Si applicano in ambiti più circoscritti.

• La Law 25 del Quebec impone una valutazione prima di inviare informazioni personali fuori dalla provincia e richiede che le informazioni ricevano una protezione adeguata nel luogo di destinazione. Questa disposizione è in vigore da settembre 2023. Si tratta di documentare la valutazione e di adottare una decisione che si possa difendere, non di un divieto.
• Le norme sul settore pubblico vincolano gli enti pubblici e le aziende che li servono. La PIIDPA della Nuova Scozia limita la conservazione delle informazioni personali fuori dal Canada; una nuova Freedom of Information and Protection of Privacy Act, approvata a ottobre 2025, la sostituirà il 1 aprile 2027. La FIPPA della Columbia Britannica prevedeva una regola analoga, fino alla modifica del 2021 che ha consentito la conservazione all'estero dopo una valutazione.
• Le attività per il governo federale seguono le direttive cloud del Government of Canada, che impongono di mantenere in Canada i dati classificati Protected B o a un livello superiore.
• Le leggi provinciali sulla privacy dei dati sanitari aggiungono condizioni specifiche sul luogo in cui possono essere conservate le cartelle cliniche, con differenze tra le province.
• Nella pratica, i contratti con i clienti e i bandi pubblici sono il fattore più comune. Un questionario di sicurezza che indica "dati a riposo in Canada" vincola l'organizzazione quanto una legge, perché è stato sottoscritto.

La verifica pratica è semplice. Si può indicare la clausola? Se nessuno nella propria organizzazione sa citare la legge o il contratto che impone il Canada, la scelta si sta facendo in base a latenza e prezzo.

Un data centre canadese è al di fuori della giurisdizione legale statunitense?

Non necessariamente. Lo US CLOUD Act (Clarifying Lawful Overseas Use of Data Act) si applica ai dati in possesso, sotto la custodia o sotto il controllo di un provider statunitense, indipendentemente dalla posizione dell’hardware. Di conseguenza, una regione di Toronto gestita da un’azienda americana rientra nel suo ambito. Se il requisito riguarda l’accesso legale da parte di autorità straniere, non la posizione geografica, contano il soggetto che gestisce il servizio e chi possiede le chiavi di crittografia. Il fatto che l’edificio si trovi in Canada non è sufficiente a rispondere.

Anche il routing può riservare sorprese. Il traffico tra due città canadesi attraversa spesso gli Stati Uniti, perché il peering a basso costo è stato storicamente disponibile soprattutto lì. I ricercatori chiamano questo fenomeno boomerang routing. Esegui un traceroute prima di dichiarare che i tuoi pacchetti non lasciano mai il Paese.

traceroute vps.example.com

I nomi degli hop contengono codici di città come nyc, chi o ash. Questi nomi sono indicativi e possono diventare obsoleti, quindi usali come motivo per chiedere conferma al provider, non come prova. Per i dati in transito, la risposta affidabile è la crittografia sotto il tuo controllo, non una mappa. Se vuoi un percorso privato tra le tue macchine, una VPN WireGuard self-hosted te ne offre uno, indipendentemente dal Paese attraversato dalla fibra.

Latenza: misurarla, senza darla per scontata

La luce nella fibra percorre circa 200 km per millisecondo, quindi ogni 100 km di distanza aggiunge circa 1 ms al round trip, prima di considerare qualsiasi apparato. Toronto e Vancouver distano circa 3.400 km in linea d'aria e ancora di più lungo il percorso dei cavi; il limite teorico è quindi vicino a 40 ms. I percorsi reali producono valori più elevati.

[
  {
    "label": "Toronto",
    "rtt_ms": 3
  },
  {
    "label": "Montreal",
    "rtt_ms": 12
  },
  {
    "label": "New York",
    "rtt_ms": 18
  },
  {
    "label": "Chicago",
    "rtt_ms": 24
  },
  {
    "label": "Northern Virginia",
    "rtt_ms": 26
  },
  {
    "label": "Dallas",
    "rtt_ms": 42
  },
  {
    "label": "Vancouver",
    "rtt_ms": 62
  },
  {
    "label": "London",
    "rtt_ms": 88
  },
  {
    "label": "Frankfurt",
    "rtt_ms": 98
  }
]

Questi sono valori tipici pubblicati per una linea consumer ben collegata a Toronto. Sono un punto di partenza, non una garanzia. I valori effettivi dipendono dalla rete di accesso e dal peering del provider e variano nel corso della giornata.

Due righe meritano particolare attenzione. Il round trip tra Toronto e Montreal è di circa 12 ms, abbastanza basso perché le due città si comportino come un'unica regione nella maggior parte dei casi. Tra Toronto e Vancouver è di circa 62 ms, un valore superiore a quello tra Toronto e Northern Virginia, pari a 26 ms. Essere in Canada non equivale a essere vicini agli utenti.

In ogni caso, l'ultimo miglio è spesso il fattore dominante. La fibra domestica aggiunge pochi millisecondi. Il cavo ne aggiunge di più quando la linea è congestionata. Una connessione mobile aggiunge da sola decine di millisecondi. Un utente mobile a Toronto potrebbe rilevare 50 ms verso un server a Toronto. Spostando il server a New York, il percorso aggiunge gli stessi circa 15 ms che aggiungerebbe per tutti, portando il totale a circa 65 ms; il collegamento radio continua comunque a rappresentare gran parte del tempo di attesa dell'utente.

Come testare la latenza dalla posizione degli utenti

Prima di tutto, verifica dove si trovano realmente gli utenti. I dati di analisi suddividono già le sessioni per città o regione. Usa questi dati invece di basarti sulla posizione del tuo ufficio.

Poi esegui le misurazioni da quella posizione. Non puoi misurare la latenza verso Vancouver da una scrivania a Ottawa. Noleggia per 20 minuti un VPS orario nella città di destinazione e distruggilo al termine. Chiedi a un collega o a un cliente di eseguire un comando. In alternativa, usa la rete di misurazione gratuita RIPE Atlas all'indirizzo https://atlas.ripe.net, che dispone di probe nelle città canadesi e consente di eseguire ping da queste posizioni.

sudo apt update && sudo apt install -y mtr-tiny traceroute iperf3
ping -c 20 vps.example.com

Leggi le ultime due righe.

20 packets transmitted, 20 received, 0% packet loss, time 19031ms
rtt min/avg/max/mdev = 17.412/18.006/19.882/0.594 ms

avg è il valore principale. mdev è il jitter, cioè la variazione tra i pacchetti. La perdita di pacchetti su un percorso breve indica un problema da analizzare. Un jitter elevato penalizza le comunicazioni vocali e i giochi più di una media leggermente superiore, perché il destinatario deve usare un buffer dimensionato sul pacchetto più lento, non su quello tipico.

mtr --report --report-cycles 50 vps.example.com

mtr mostra la perdita per ogni hop. Se termina con un errore di permesso, eseguilo con sudo. Gli hop intermedi mostrano spesso una perdita che non è reale, perché i router assegnano la priorità più bassa alle risposte ICMP generate da loro stessi. Solo la perdita che continua fino alla riga finale è una perdita effettivamente subita dal traffico. Leggi prima la riga in fondo, quindi procedi verso l'alto.

Quando ICMP è bloccato o soggetto a rate limiting, misura direttamente il protocollo effettivo.

curl -o /dev/null -s -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://vps.example.com/

Ogni campo indica i secondi cumulativi trascorsi dall'inizio della richiesta. connect meno dns corrisponde a un round trip TCP. tls meno connect corrisponde all'handshake. ttfb meno tls corrisponde a un altro round trip più il tempo impiegato dall'applicazione per rispondere. È soprattutto in quest'ultimo intervallo che i siti lenti perdono tempo. Un ttfb di 0.8 s su un percorso breve indica un problema dell'applicazione; spostare il server in un'altra città non lo risolverà.

Per misurare il throughput, esegui il server sul VPS e il client dalla posizione dell'utente. iperf3 resta in ascolto sulla porta TCP 5201, quindi apri la porta con ufw per il test e richiudila al termine.

iperf3 -s

iperf3 -c vps.example.com -t 20
iperf3 -c vps.example.com -t 20 -R
iperf3 -c vps.example.com -t 20 -P 8

-R inverte la direzione, quindi misura sia il download sia l'upload. -P 8 apre otto stream paralleli. Se otto stream sono molto più veloci di uno, il limite è la finestra TCP su un percorso lungo, non il collegamento stesso, perché un singolo stream può trasmettere soltanto una finestra per round trip. La stessa finestra sul percorso verso Vancouver trasferisce all'incirca un terzo dei dati al secondo rispetto al percorso verso New York. Lo stesso vale per i backup su lunga distanza, motivo per cui i backup fuori sede con restic risultano lenti verso una destinazione distante anche su una linea veloce.

Mantieni un ping in esecuzione in un secondo terminale mentre iperf3 lavora. Se il round trip aumenta da 20 ms a 300 ms durante il trasferimento, si tratta di bufferbloat nell'apparato di accesso locale; nessuna posizione del data center può risolvere il problema.

Esegui le misurazioni più volte e ripetile la sera. La congestione alle 21:00 è quella con cui convivono gli utenti. Il valore delle 04:00 è quello che una pagina commerciale preferirebbe citare.

Cosa comporta il round trip per il carico di lavoro

Il caricamento di una pagina senza cache richiede quattro round trip prima che il browser possa visualizzare qualsiasi elemento.

[
  {
    "label": "DNS lookup",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "TCP handshake",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "TLS 1.3 handshake",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "Request and first byte",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "All four round trips",
    "toronto_to_new_york_ms": 72,
    "toronto_to_vancouver_ms": 248
  }
]

La ricerca DNS viene eseguita da un resolver, non dal server, e di solito viene messa in cache; per questo una visita successiva la salta. Considerando il percorso end-to-end, un caricamento senza cache parte con 72 ms di ritardo sul percorso verso New York e con 248 ms sul percorso verso Vancouver. Il valore per New York è ridotto rispetto a una singola query al database da 400 ms. Quello per Vancouver non lo è: supera metà della durata di tale query e viene effettivamente pagato da chi visita la pagina per la prima volta. Dopo l'apertura della connessione, HTTP/2 e HTTP/3 trasportano contemporaneamente molte richieste sulla stessa connessione, quindi questo costo viene sostenuto una sola volta anziché una volta per file. Distribuendo gli asset statici tramite una CDN (content delivery network), la città in cui si trova l'origine smette del tutto di essere rilevante per tali asset. Per questo un visitatore europeo con 98 ms verso Toronto può comunque ricevere rapidamente la pagina.

I giochi multiplayer in tempo reale rappresentano il caso opposto, perché il round trip determina direttamente l'esperienza. In un gioco d'azione rapido, un valore inferiore a circa 50 ms sembra immediato, i giocatori iniziano a notare il ritardo intorno a 80 ms e oltre 120 ms attribuiscono il problema al server. In questo caso la regione determina realmente la qualità del prodotto. I server per giochi più lenti sono molto più tolleranti; per questo eseguire un server Minecraft su un VPS consente distanze che rovinerebbero un gioco sparatutto.

È nei database che la scelta della regione può causare i problemi maggiori. Non collocare mai l'applicazione in una regione e il database in un'altra. Ogni query è un round trip. Una pagina che esegue 40 query sostiene 40 round trip: con 18 ms ciascuno, il tempo totale è quasi un secondo; con 62 ms ciascuno, supera i due secondi, mentre la stessa pagina era stata misurata a 30 ms con il database sullo stesso server. La replica asincrona verso un'altra regione è adatta alle repliche di lettura e al disaster recovery. Un commit sincrono su un percorso lungo aggiunge la latenza di quel percorso a ogni singola scrittura.

Le sessioni interattive si collocano in una posizione intermedia. SSH resta confortevole fino a circa 100 ms e oltre questo valore appare lento, perché ogni pressione di un tasto deve attendere il ritorno dell'eco. mosh esegue la predizione localmente e nasconde gran parte del ritardo. Webhook e API interne dovrebbero risiedere sempre nella stessa regione del servizio che chiamano.

Fatturazione, valuta e imposte

Pagare in dollari canadesi evita la commissione sulle transazioni in valuta estera applicata dall'emittente della carta, generalmente pari a circa il 2.5% ad agosto 2026, e consente di gestire la contabilità in un'unica valuta. Un provider canadese emette fatture con GST o HST, che un'azienda registrata può recuperare come credito d'imposta sugli acquisti. Questa è una questione finanziaria, che richiede una risposta finanziaria, e non deve mai determinare dove vengono instradati i pacchetti. Per sapere quanto costa realmente un server e come confrontare i piani senza subire prezzi di rinnovo più elevati, leggi quanto costa realmente un VPS al mese.

Quanto costa operare in un mercato più piccolo

Il Canada è un mercato dell'hosting più piccolo rispetto agli Stati Uniti. Una valutazione corretta deve considerare anche ciò a cui si rinuncia.

• Sono presenti meno provider in concorrenza per il tuo budget, quindi il prezzo per gigabyte di RAM o di storage è generalmente più alto a parità di categoria della macchina.
• La capacità è concentrata a Toronto e Montreal, con una presenza minore a Vancouver e Calgary. Una seconda regione canadese per il failover spesso richiede un percorso di rete lungo oppure implica comunque lasciare il Paese.
• Un piccolo host regionale può gestire un solo edificio collegato a uno o due carrier upstream. Chiedi quanti carrier sono disponibili e cosa succede quando uno di loro ha un guasto.
• Il catalogo hardware è più limitato. Le istanze di grandi dimensioni e le macchine GPU sono più facili da trovare nelle regioni statunitensi, quindi un VPS con GPU potrebbe non essere disponibile nella dimensione o nella città desiderata.
• La copertura del supporto presso un piccolo host è una questione concreta, non di marketing. Chiedi in quali orari è disponibile un operatore.

Montreal è un'eccezione sul piano dei prezzi. L'energia idroelettrica del Québec è economica e gli inverni riducono i costi di raffreddamento. Per questo l'area di Montreal offre molta capacità a tariffe competitive rispetto alle regioni statunitensi. Se il requisito è il Canada, senza vincoli su una città specifica, inizia da qui.

Se i piani VPS canadesi sembrano troppo limitati per il carico di lavoro, confronta un VPS con un server dedicato prima di concludere che il problema sia il Paese.

Quando scegliere un hosting VPS in Canada

1. Una legge, un contratto o una policy del settore pubblico indica il Canada. In questo caso, ospita il servizio in Canada. Nessun altro punto di questo articolo è applicabile e dovresti inoltre ottenere dal provider un impegno scritto sulla residenza dei dati.
2. Gli utenti si trovano in un'unica area metropolitana canadese e il carico di lavoro è vincolato dalla latenza: giochi multiplayer, comunicazioni vocali, desktop remoti o trading. Ospita il servizio nella città più vicina e misura entrambe le opzioni prima di firmare qualsiasi contratto.
3. Gli utenti sono distribuiti in tutto il Paese. Toronto o Montréal coprono la quota maggiore della popolazione, mentre una CDN davanti alle risorse statiche offre più vantaggi a un utente di Vancouver rispetto allo spostamento dell'origine.
4. In tutti gli altri casi, cioè nella maggior parte delle situazioni, scegli in base al prezzo e all'hardware effettivamente disponibile, quindi verifica come funziona il supporto alle 2:00. Esegui prima un benchmark del candidato, perché due piani con la stessa scheda tecnica non offrono necessariamente le stesse prestazioni: come eseguire correttamente il benchmark di un VPS.

Qualunque sia la scelta, annota il motivo accanto alla decisione. La persona che in futuro chiederà se il servizio debba essere ospitato in Canada merita qualcosa di meglio di un'ipotesi. Se la risposta dipendeva da una clausola contrattuale, qualcuno dovrà poterla ritrovare. Una volta creato il server, i primi dieci minuti su un nuovo VPS avranno un impatto sulla sicurezza maggiore di quello della sua città.

FAQ

PIPEDA richiede che i miei dati restino in Canada?

No. PIPEDA (Personal Information Protection and Electronic Documents Act) non impone requisiti di residenza dei dati al settore privato. L'invio di informazioni personali a un responsabile del trattamento in un altro Paese è un trasferimento per l'elaborazione: la responsabilità dei dati resta alla tua organizzazione, il responsabile deve proteggerli in modo comparabile e devi informare le persone che il trasferimento avviene. Nel 2019 l'Office of the Privacy Commissioner ha consultato le parti interessate sulla possibilità di cambiare questa posizione, ma l'ha poi mantenuta. I requisiti di residenza derivano da altre fonti: la valutazione prevista dalla Law 25 del Quebec, leggi del settore pubblico come la PIIDPA della Nova Scotia, le direttive del Government of Canada per il cloud oppure una clausola del tuo contratto con il cliente.

Gli utenti canadesi noteranno un server negli Stati Uniti?

Per una normale applicazione web, no. Un round trip da Toronto a New York dura circa 18 ms, mentre verso la Northern Virginia dura circa 26 ms; entrambi i valori sono inferiori ai 62 ms da Toronto a Vancouver. Gli utenti notano i tempi di risposta del server e il peso delle pagine molto prima di notare 20 ms di latenza di rete. La differenza è invece percepibile nei giochi in tempo reale, nelle chiamate vocali e in tutte le situazioni in cui una persona reagisce a un'altra.

Un data centre canadese è al di fuori della portata delle leggi statunitensi?

Non automaticamente. Il US CLOUD Act si applica ai dati in possesso, sotto la custodia o sotto il controllo di un provider statunitense, indipendentemente dalla posizione del server. Di conseguenza, una regione canadese gestita da un'azienda americana rientra comunque nel suo ambito. Se il problema concreto riguarda le richieste legali provenienti dall'estero, verifica chi gestisce il servizio e chi possiede le chiavi di cifratura, invece di considerare soltanto l'indirizzo dell'edificio. La cifratura con chiavi che conservi autonomamente modifica ciò che un provider può consegnare.

Come posso misurare la latenza da una città in cui non vivo?

Noleggia un VPS con tariffazione oraria in quella città, esegui ping -c 20 e mtr --report --report-cycles 50 verso il tuo server, quindi distruggilo. La rete RIPE Atlas è un'alternativa gratuita, con probe presenti in diverse città canadesi. Se ICMP è bloccato, misura invece il tempo della richiesta reale con curl -o /dev/null -s -w '%{time_connect} %{time_starttransfer}\n' https://your.server/, che restituisce il round trip TCP e il tempo complessivo fino al primo byte.