VPS in Canada: quando serve davvero?

Il tuo VPS deve trovarsi in Canada?

Scegliere un servizio di 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 percorso di andata e ritorno da una connessione domestica di Toronto a un data centre di New York richiede circa 18 ms, rispetto a circa 3 ms verso un data centre di Toronto; quasi nessuna applicazione web è in grado di rilevare la differenza.

Tre fattori possono orientare verso un server canadese. La localizzazione dei dati è un obbligo legale, quindi risolve da sola la questione. La latenza è misurabile e di solito è inferiore a quanto si prevede. La fatturazione in dollari canadesi è una comodità per il contabile. Verifica prima se il primo fattore si applica al tuo caso, poi valuta gli altri.

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

Residenza dei dati: l'unico requisito inderogabile

PIPEDA (Personal Information Protection and Electronic Documents Act) è la legge federale canadese sulla privacy nel settore privato e non richiede che le informazioni personali rimangano nel Paese. Considera l'invio dei dati a un responsabile del trattamento all'estero come un trasferimento per il trattamento: la responsabilità dei dati rimane a carico della vostra organizzazione, il responsabile deve garantire una protezione equivalente e dovete informare chiaramente gli interessati che ciò avviene. Nel 2019 l'Office of the Privacy Commissioner ha consultato le parti interessate sulla possibilità di rendere questa regola più rigorosa, ma ha poi mantenuto la propria posizione. È quindi errata l'affermazione comune secondo cui PIPEDA impone di conservare i dati in Canada, anche se molti contenuti promozionali dei servizi di hosting continuano a ripeterla.

Regole effettive sulla localizzazione dei dati esistono. Si applicano in ambiti più specifici.

• La Law 25 del Quebec richiede una valutazione prima di inviare informazioni personali al di fuori della provincia e impone che le informazioni ricevano una protezione adeguata nel luogo di destinazione. Questa disposizione è in vigore da September 2023. Richiede documentazione e una decisione che dovete poter motivare, ma non costituisce un divieto.
• Le norme del settore pubblico vincolano gli enti pubblici e le aziende che li servono. La PIIDPA della Nova Scotia limita la conservazione delle informazioni personali al di fuori del Canada. La FIPPA della British Columbia conteneva una regola simile, finché non è stata modificata nel 2021 per consentire la conservazione all'estero dopo una valutazione.
• Le attività per il governo federale seguono le direttive cloud del Government of Canada, che richiedono che i dati Protected B e di livello superiore rimangano in Canada.
• Le leggi provinciali sulla privacy in ambito sanitario aggiungono condizioni specifiche sul luogo in cui possono essere conservate le cartelle cliniche, e tali condizioni variano da provincia a provincia.
• I contratti con i clienti e i bandi pubblici sono in pratica il fattore più comune. Un questionario di sicurezza che indica "dati inattivi in Canada" vi vincola quanto una legge, perché lo avete sottoscritto.

La verifica pratica è semplice. Potete indicare la clausola applicabile? Se nessuno nella vostra organizzazione sa indicare la legge o il contratto che richiede il Canada, allora state scegliendo in base a latenza e prezzo.

Un data center canadese è al di fuori della portata legale degli Stati Uniti?

Non da solo. 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 da dove si trovi l'hardware. Di conseguenza, una regione di Toronto gestita da un'azienda americana rientra nella sua portata. Se il requisito riguarda il procedimento legale estero anziché la posizione geografica, contano chi gestisce il servizio e chi possiede le chiavi di crittografia. Un indirizzo canadese sull'edificio, da solo, non fornisce questa risposta.

Il routing è il secondo aspetto inatteso. Il traffico tra due città canadesi attraversa spesso gli Stati Uniti, perché storicamente è lì che si trovano le interconnessioni a basso costo. I ricercatori chiamano questo fenomeno boomerang routing. Eseguire un traceroute prima di dichiarare che i 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 diventano obsoleti, quindi usali come motivo per chiedere informazioni al provider, non come prova. Per i dati in transito, la risposta affidabile è una 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 che non dipende dal Paese attraversato dalla fibra.

Latenza: misurala, non darla per scontata

La luce nella fibra percorre circa 200 km per millisecondo, quindi ogni 100 km di distanza aggiunge circa 1 ms al tempo di andata e ritorno, prima ancora di considerare qualsiasi apparato. Toronto e Vancouver distano circa 3.400 km in linea d'aria e ancora di più via cavo, quindi il limite teorico è vicino a 40 ms. I percorsi reali producono valori più alti.

[
  {
    "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 connessione consumer ben collegata a Toronto. Sono un punto di partenza, non una garanzia. I tuoi valori dipendono dalla rete di accesso e dal peering del provider e variano in base all'ora del giorno.

Vale la pena leggere due righe più attentamente. Toronto e Montreal hanno una latenza di circa 12 ms, abbastanza bassa perché, nella maggior parte dei casi, le due città si comportino come un'unica regione. Toronto e Vancouver hanno una latenza di circa 62 ms, superiore a quella tra Toronto e Northern Virginia, pari a 26 ms. Essere in Canada non significa essere vicini ai tuoi utenti.

L'ultimo miglio spesso domina comunque. La fibra fino a casa aggiunge pochi millisecondi. Il cavo ne aggiunge di più quando la linea è congestionata. Una connessione mobile aggiunge autonomamente decine di millisecondi. Un utente mobile a Toronto potrebbe rilevare 50 ms verso un server a Toronto; spostare quel server a New York modifica la sua esperienza di pochi punti percentuali.

Come testare la latenza dalla posizione degli utenti

Per prima cosa, stabilisci dove si trovano realmente gli utenti. I dati di analisi suddividono già le sessioni per città o regione. Usa questi dati invece di dedurre la posizione da quella del tuo ufficio.

Poi misura da quelle località. Non puoi testare la latenza verso Vancouver da una scrivania a Ottawa. Noleggia un VPS a ore nella città di destinazione per venti minuti e distruggilo al termine. Chiedi a un collega o a un cliente di eseguire un comando. In alternativa, usa la rete gratuita di misurazione RIPE Atlas all'indirizzo https://atlas.ripe.net, che dispone di probe nelle città canadesi e consente di eseguire ping da tali 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. Qualsiasi perdita di pacchetti su un percorso breve è un problema da analizzare. Un jitter elevato danneggia le comunicazioni vocali e i giochi più di una media leggermente superiore, perché il ricevitore deve effettuare il buffering in base al pacchetto con il tempo peggiore, non a quello tipico.

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

mtr mostra la perdita per ogni hop. Se termina con un errore di autorizzazione, eseguilo con sudo. Gli hop intermedi mostrano spesso una perdita 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 subita dal traffico. Leggi prima la riga inferiore, quindi procedi verso l'alto.

Quando ICMP è bloccato o soggetto a limitazione della frequenza, misura il tempo del 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 contiene i secondi cumulativi dall'inizio della richiesta. connect meno dns è un round trip TCP. tls meno connect è l'handshake. ttfb meno tls è un altro round trip più il tempo impiegato dall'applicazione per rispondere. Quest'ultimo intervallo è quello in cui i siti lenti perdono realmente più 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 la velocità di trasferimento, 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, consentendo di misurare il download oltre all'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ò trasportare una sola finestra per round trip. La stessa finestra sul percorso verso Vancouver trasferisce circa un terzo dei dati al secondo rispetto al percorso verso New York. I backup su lunga distanza si comportano allo stesso modo. Per questo 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 è attivo. 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ò risolverlo.

Esegui la misurazione più volte e anche di sera. La congestione alle 9pm è il valore con cui convivono gli utenti. Il valore delle 4am è quello che una pagina commerciale preferirebbe citare.

Cosa significa il tempo di andata e ritorno per il carico di lavoro

Il caricamento a freddo di una pagina richiede quattro tempi di andata e ritorno prima che il browser possa visualizzare qualsiasi contenuto.

[
  {
    "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 tuo server, e di solito viene memorizzata nella cache, quindi una visita successiva la evita. Considerando l'intero percorso, un caricamento a freddo parte con 72 ms di ritardo sul percorso verso New York e con 248 ms su quello verso Vancouver. Entrambi i valori sono trascurabili rispetto a una singola query al database da 400 ms. 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é per ogni file. Se metti gli asset statici su una CDN (content delivery network), la città in cui si trova l'origine non è più rilevante per tali asset. Per questo un visitatore europeo con 98 ms fino a Toronto può comunque ottenere una pagina veloce.

I giochi multiplayer in tempo reale sono il caso opposto, perché il tempo di andata e ritorno determina l'esperienza. In un gioco d'azione veloce, un valore inferiore a circa 50 ms sembra immediato, intorno a 80 ms i giocatori iniziano a notare il ritardo e oltre 120 ms lo attribuiscono 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.

I database sono il caso in cui 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 tempo di andata e ritorno. Una pagina che esegue 40 query ne paga 40: con 18 ms per query si arriva a quasi un secondo, mentre con 62 ms per query si superano i due secondi. Questo vale per una pagina che, con il database sullo stesso server, aveva un tempo misurato di 30 ms. La replica asincrona in un'altra regione è adatta alle repliche di lettura e al ripristino di emergenza. Il commit sincrono su un percorso lungo aggiunge quel percorso a ogni singola scrittura.

Le sessioni interattive si trovano a metà. SSH resta comodo fino a circa 100 ms, ma oltre questo valore presenta ritardi, perché ogni pressione di tasto deve attendere il ritorno del relativo carattere visualizzato. mosh esegue previsioni locali e nasconde gran parte del ritardo. Webhook e API interne devono 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 mantiene 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 e richiede una risposta finanziaria; non dovrebbe mai determinare la destinazione dei pacchetti. Per sapere quanto costa realmente un server e come confrontare i piani senza incorrere nei prezzi di rinnovo, leggi quanto costa realmente un VPS al mese.

Quanto ti costa un mercato più piccolo

Il mercato canadese dell'hosting è piccolo rispetto a quello statunitense, e un consiglio onesto deve includere anche ciò a cui rinunci.

• Meno provider competono per i tuoi clienti, quindi il prezzo per gigabyte di RAM o disco è solitamente più alto per la stessa classe di macchina.
• La capacità è concentrata a Toronto e Montreal, con una presenza minore a Vancouver e Calgary. Una seconda regione canadese per il failover spesso implica un percorso lungo oppure richiede comunque di uscire dal 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 si guasta.
• Il catalogo hardware è più limitato. Le istanze di grandi dimensioni e le macchine GPU sono più facili da trovare nelle regioni statunitensi, quindi un GPU VPS potrebbe non essere disponibile con le dimensioni che vuoi nella città che vuoi.
• La copertura del supporto presso un piccolo host è una questione concreta, non di marketing. Chiedi in quali orari è disponibile una persona.

Montreal è l'eccezione per quanto riguarda il prezzo. L'energia idroelettrica del Quebec è economica e gli inverni riducono i costi di raffreddamento, quindi l'area di Montreal offre molta capacità a tariffe competitive con quelle delle regioni statunitensi. Se ti serve il Canada, ma non una città specifica, inizia da qui.

Se i livelli di VPS canadesi sembrano troppo piccoli per il carico di lavoro, confronta un VPS con un server dedicato prima di decidere che il problema sia il Paese.

Quando l'hosting VPS in Canada è la scelta giusta

1. Una legge, un contratto o una policy del settore pubblico indicano il Canada. Ospita il servizio in Canada. Tutto il resto di questo articolo non si applica e dovresti ottenere anche per iscritto dal provider l'impegno sulla localizzazione dei dati.
2. Gli utenti si trovano in un'unica area metropolitana canadese e il carico di lavoro è vincolato dalla latenza: giochi multiplayer, chiamate 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 Montreal coprono la quota maggiore della popolazione, e una CDN davanti alle risorse statiche è più utile a un visitatore di Vancouver che lo spostamento dell'origine.
4. Tutto il resto, cioè la maggior parte dei casi. Scegli in base al prezzo e all'hardware che ricevi effettivamente, poi verifica come funziona l'assistenza alle 2am. Esegui prima un benchmark sul candidato, perché due piani con la stessa scheda tecnica non hanno necessariamente le stesse prestazioni: come eseguire correttamente il benchmark di un VPS.

Qualunque scelta tu faccia, annota il motivo accanto alla decisione. La persona successiva che chiederà se il servizio debba essere in Canada merita qualcosa di più di un'ipotesi; se la risposta era una clausola contrattuale, qualcuno dovrà ritrovarla. Quando il server sarà operativo, i primi dieci minuti su un nuovo VPS avranno un impatto sulla sicurezza maggiore di quello della sua città.

FAQ

PIPEDA impone che i miei dati restino in Canada?

No. La PIPEDA (Personal Information Protection and Electronic Documents Act) non prevede alcun obbligo di localizzazione dei dati per il settore privato. L'invio di informazioni personali a un responsabile del trattamento in un altro Paese è un trasferimento per il trattamento: la vostra organizzazione resta responsabile dei dati, il responsabile deve proteggerli in modo comparabile e dovete informare le persone del trasferimento in modo trasparente. L'Office of the Privacy Commissioner ha valutato una modifica di questa posizione nel 2019, ma l'ha poi mantenuta. Gli obblighi di localizzazione derivano da altre fonti: la valutazione prevista dalla Law 25 del Quebec, leggi del settore pubblico come la PIIDPA della Nuova Scozia, le direttive del Government of Canada sul cloud oppure una clausola del vostro 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 e fino alla Northern Virginia circa 26 ms; entrambi i valori sono inferiori al tempo da Toronto a Vancouver, pari a 62 ms. Gli utenti notano il tempo di risposta del server e il peso della pagina molto prima di notare 20 ms di traffico di rete. Notano invece la latenza 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 giurisdizione 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 statunitense è comunque soggetta alla legge. Se la vostra reale preoccupazione riguarda i procedimenti legali stranieri, verificate chi gestisce il servizio e chi detiene le chiavi di crittografia, invece di considerare solo l'indirizzo dell'edificio. La crittografia con chiavi detenute direttamente da voi modifica ciò che un provider può consegnare.

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

Noleggiate un VPS con tariffazione oraria in quella città, eseguite ping -c 20 e mtr --report --report-cycles 50 verso il vostro server e poi eliminate il VPS. La rete RIPE Atlas è un'alternativa gratuita, con sonde presenti nelle città canadesi. Se ICMP è bloccato, misurate 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 completo fino al primo byte.