VPS en Canadá: qué importa realmente

¿Su VPS debe estar en Canadá?

El alojamiento VPS en Canadá merece la pena cuando una ley o un contrato exige que los datos permanezcan en territorio canadiense. Esa es la única razón determinante. Un viaje de ida y vuelta desde una conexión doméstica de Toronto hasta un centro de datos de Nueva York tarda aproximadamente 18 ms, frente a unos 3 ms hasta uno de Toronto, y casi ninguna aplicación web puede notar la diferencia.

Tres factores llevan a elegir un servidor canadiense. La residencia de los datos es una obligación legal, por lo que resuelve la cuestión por sí sola. La latencia se puede medir y normalmente es menor de lo que la gente espera. Facturar en dólares canadienses es una comodidad para su contable. Determine si el primer factor se aplica a su caso antes de considerar cualquier otro.

Esta publicación explica cómo funcionan las reglas en general. No constituye asesoramiento jurídico. Si una ley de privacidad es aplicable a su organización, la respuesta debe proporcionarla su asesor jurídico.

Residencia de los datos: el único requisito estricto

PIPEDA (Personal Information Protection and Electronic Documents Act) es la ley federal de privacidad del sector privado de Canadá y no exige que la información personal permanezca en el país. Considera el envío de datos a un encargado del tratamiento en el extranjero como una transferencia para su procesamiento: su organización sigue siendo responsable de los datos, el encargado debe ofrecer una protección comparable y usted debe informar de forma transparente a las personas de que esto ocurre. La Office of the Privacy Commissioner consultó sobre el endurecimiento de esta norma en 2019 y después mantuvo su posición vigente. Por tanto, es incorrecta la afirmación habitual de que PIPEDA exige que sus datos residan en Canadá, aunque muchos textos de proveedores de hosting la repitan.

Sí existen normas reales sobre residencia. Se aplican en ámbitos más específicos.

• La Law 25 de Quebec exige una evaluación antes de enviar información personal fuera de la provincia, y la información debe recibir una protección adecuada en el lugar de destino. Esta disposición está en vigor desde September 2023. Requiere documentación y una decisión que usted debe poder justificar; no es una prohibición.
• Las normas del sector público obligan a los organismos públicos y a las empresas que les prestan servicios. La PIIDPA de Nova Scotia restringe el almacenamiento de información personal fuera de Canadá. La FIPPA de British Columbia tenía una norma similar hasta que se modificó en 2021 para permitir el almacenamiento en el extranjero después de una evaluación.
• Los trabajos para el Gobierno federal siguen la directiva de nube del Government of Canada, que exige que los datos Protected B y de niveles superiores permanezcan en Canadá.
• Las leyes provinciales de privacidad sanitaria añaden sus propias condiciones sobre la ubicación de los historiales médicos, y estas condiciones varían entre provincias.
• En la práctica, los contratos con clientes y las licitaciones públicas son el factor más habitual. Un cuestionario de seguridad que indique "data at rest in Canada" le obliga tanto como una ley, porque usted lo firmó.

La prueba práctica es sencilla. ¿Puede señalar la cláusula? Si nadie en su organización puede indicar el estatuto o el contrato que exige Canadá, entonces está tomando la decisión por latencia y precio.

¿Un centro de datos canadiense está fuera del alcance legal de Estados Unidos?

No por sí solo. La US CLOUD Act (Clarifying Lawful Overseas Use of Data Act) se aplica a los datos que están en posesión, custodia o bajo el control de un proveedor estadounidense, sin importar dónde se encuentre el hardware. Por tanto, una región de Toronto operada por una empresa estadounidense está dentro de su alcance. Si el requisito real se refiere a procesos legales extranjeros y no a la geografía, lo importante es quién opera el servicio y quién conserva las claves de cifrado. Una dirección canadiense en el edificio no responde por sí sola a esa cuestión.

El enrutamiento es la segunda sorpresa. El tráfico entre dos ciudades canadienses suele atravesar Estados Unidos porque históricamente allí se encontraba el peering más barato. Los investigadores llaman a esto enrutamiento de tipo boomerang. Ejecute traceroute antes de afirmar que sus paquetes nunca salen del país.

traceroute vps.example.com

Los nombres de los saltos contienen códigos de ciudad como nyc, chi o ash. Esos nombres son indicios y pueden quedar obsoletos, así que considérelos un motivo para consultar al proveedor, no una prueba. Para los datos en tránsito, la respuesta fiable es el cifrado bajo su control, no un mapa. Si quiere una ruta privada entre sus propias máquinas, una VPN WireGuard autohospedada le proporciona una que no depende del país por el que pase la fibra.

Latencia: mídala, no la dé por supuesta

La luz en la fibra recorre unos 200 km por milisegundo, por lo que cada 100 km de distancia añade aproximadamente 1 ms de ida y vuelta antes de tener en cuenta cualquier equipo. Toronto y Vancouver están a unos 3,400 km en línea recta y a una distancia mayor por cable, lo que sitúa el mínimo cerca de 40 ms. Las rutas reales presentan valores superiores.

[
  {
    "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
  }
]

Son cifras publicadas típicas de una línea de consumo con buena conectividad en Toronto. Sirven como punto de partida, no como garantía. Sus propios valores dependen de su red de acceso y de las relaciones de peering de su proveedor, y varían según la hora del día.

Conviene revisar dos filas con atención. Toronto y Montreal presentan unos 12 ms, una latencia suficientemente baja para que ambas ciudades funcionen como una sola región en la mayoría de los casos. Toronto y Vancouver presentan unos 62 ms, una latencia superior a la de Toronto y Northern Virginia, que es de 26 ms. Estar en Canadá no equivale a estar cerca de sus usuarios.

De todos modos, la última milla suele ser el factor dominante. La fibra doméstica añade unos pocos milisegundos. El cable añade más latencia cuando la línea está congestionada. Una conexión móvil añade por sí sola decenas de milisegundos. Un usuario móvil en Toronto podría obtener 50 ms hasta un servidor en Toronto, y trasladar ese servidor a Nueva York cambiaría su experiencia unos pocos puntos porcentuales.

Cómo probar la latencia desde la ubicación de tus usuarios

Primero averigua dónde están realmente tus usuarios. Tus análisis ya desglosan las sesiones por ciudad o región. Usa esos datos en lugar de hacer suposiciones basadas en la ubicación de tu oficina.

Después mide desde allí. No puedes probar la latencia hacia Vancouver desde un escritorio en Ottawa. Alquila un VPS por horas en la ciudad de destino durante veinte minutos y destrúyelo después. Pide a un colega o cliente que ejecute un comando. También puedes usar la red gratuita de medición RIPE Atlas en https://atlas.ripe.net, que tiene sondas en ciudades canadienses y permite ejecutar pings desde ellas.

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

Lee las dos últimas líneas.

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 es el valor principal. mdev es el jitter, es decir, la variación entre paquetes. Cualquier pérdida de paquetes en una ruta corta indica un problema que debes investigar. Un jitter alto afecta más a la voz y a los juegos que una media ligeramente superior, porque el receptor debe almacenar datos según el peor paquete y no según el paquete típico.

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

mtr muestra la pérdida de cada salto. Si termina con un error de permisos, ejecútalo con sudo. Los saltos intermedios suelen mostrar pérdidas que no son reales, porque los routers asignan la prioridad más baja a las respuestas ICMP que generan ellos mismos. Solo la pérdida que continúa hasta la línea final afecta a tu tráfico. Lee primero la fila inferior y después sube.

Cuando ICMP está bloqueado o limitado por frecuencia, mide directamente el protocolo real.

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/

Cada campo contiene los segundos acumulados desde el inicio de la solicitud. connect menos dns es un viaje de ida y vuelta de TCP. tls menos connect es el handshake. ttfb menos tls es otro viaje de ida y vuelta más el tiempo que tardó tu aplicación en responder. En esa última diferencia es donde los sitios lentos suelen perder la mayor parte del tiempo. Un ttfb de 0.8 s en una ruta corta indica un problema de la aplicación, y mover el servidor a otra ciudad no lo solucionará.

Para medir el rendimiento, ejecuta el servidor en el VPS y el cliente desde la ubicación del usuario. iperf3 escucha en TCP 5201, así que abre el puerto con ufw para la prueba y vuelve a cerrarlo cuando termines.

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 invierte la dirección, por lo que mides tanto la descarga como la subida. -P 8 abre ocho flujos paralelos. Si ocho flujos son mucho más rápidos que uno, el límite es la ventana de TCP en una ruta larga y no el enlace en sí, porque un solo flujo solo puede transportar una ventana por viaje de ida y vuelta. La misma ventana mueve aproximadamente un tercio de datos por segundo en la ruta hacia Vancouver que en la ruta hacia Nueva York. Las copias de seguridad de larga distancia se comportan igual. Por eso las copias de seguridad externas con restic parecen lentas frente a un destino distante incluso con una conexión rápida.

Mantén un ping en ejecución en otra terminal mientras iperf3 trabaja. Si el viaje de ida y vuelta aumenta de 20 ms a 300 ms durante la transferencia, se trata de bufferbloat en tu propio equipo de acceso, y ninguna ubicación del centro de datos lo solucionará.

Mide más de una vez y hazlo por la tarde o por la noche. La congestión de las 9pm es la cifra que experimentan tus usuarios. La cifra de las 4am es la que una página comercial preferiría citar.

Qué significa el tiempo de ida y vuelta para su carga de trabajo

La carga inicial de una página realiza cuatro viajes de ida y vuelta antes de que el navegador pueda mostrar algo.

[
  {
    "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 búsqueda DNS se realiza en un resolver, no en su servidor, y normalmente está almacenada en caché, por lo que una visita posterior la omite. De extremo a extremo, una carga inicial empieza con 72 ms de retraso en la ruta a New York y con 248 ms en la ruta a Vancouver. Ambas cifras son insignificantes frente a una sola consulta de base de datos de 400 ms. Una vez abierta la conexión, HTTP/2 y HTTP/3 transportan muchas solicitudes simultáneamente por ella, por lo que ese coste se paga una sola vez y no una vez por archivo. Coloque los recursos estáticos en una CDN (red de distribución de contenido) y la ciudad del origen deja de importar para esos recursos. Por eso, un visitante europeo con 98 ms hasta Toronto todavía puede obtener una página rápida.

Los juegos multijugador en tiempo real son el caso contrario, porque el viaje de ida y vuelta forma parte de la experiencia. En un juego de acción rápido, menos de aproximadamente 50 ms se percibe como inmediato. Los jugadores empiezan a notar el retraso alrededor de 80 ms y, por encima de 120 ms, culpan al servidor. En este caso, la región determina realmente si el producto funciona bien. Los servidores de ritmo más lento toleran mucho mejor la latencia. Por eso, ejecutar un servidor de Minecraft en un VPS soporta distancias que arruinarían un juego de disparos.

Las bases de datos son el ámbito en el que elegir una región equivocada causa más problemas. Nunca coloque la aplicación en una región y su base de datos en otra. Cada consulta es un viaje de ida y vuelta. Una página que ejecuta 40 consultas paga 40 viajes: con 18 ms cada uno, eso suma casi un segundo; con 62 ms cada uno, supera los dos segundos. Esto ocurre en una página que registró 30 ms con la base de datos en el mismo equipo. La replicación asíncrona a otra región es adecuada para réplicas de lectura y recuperación ante desastres. Un commit síncrono a través de una ruta larga añade esa latencia a cada escritura.

Las sesiones interactivas quedan entre ambos casos. SSH sigue siendo cómodo hasta aproximadamente 100 ms y empieza a sentirse lento por encima de ese valor, porque cada pulsación de tecla espera a que vuelva su eco. mosh predice localmente y oculta gran parte de ese retraso. Los webhooks y las API internas siempre deben estar en la misma región que el servicio al que llaman.

Facturación, moneda e impuestos

Pagar en dólares canadienses evita la comisión por transacciones en moneda extranjera que cobra el emisor de la tarjeta, normalmente de alrededor del 2.5% en agosto de 2026, y mantiene la contabilidad en una sola moneda. Un proveedor canadiense factura con GST o HST, que una empresa registrada puede reclamar como crédito fiscal soportado. Esta es una cuestión financiera y debe resolverse con criterios financieros. Nunca debe determinar adónde se envían los paquetes. Para saber cuánto cuesta realmente un servidor y cómo comparar planes sin verse afectado por los precios de renovación, lee cuánto cuesta realmente un VPS al mes.

Lo que cuesta un mercado más pequeño

Canadá es un mercado de hosting pequeño en comparación con Estados Unidos, y un asesoramiento honesto debe incluir aquello a lo que renuncia.

• Hay menos proveedores compitiendo por su dinero, por lo que el precio por gigabyte de RAM o disco suele ser más alto para la misma clase de máquina.
• La capacidad se concentra en Toronto y Montreal, con menos presencia en Vancouver y Calgary. Una segunda región canadiense para la conmutación por error suele implicar una ruta larga o salir del país de todos modos.
• Un proveedor regional pequeño puede operar un solo edificio con uno o dos operadores upstream. Pregunte cuántos operadores hay y qué sucede cuando uno de ellos falla.
• El catálogo de hardware es más limitado. Las instancias grandes y las máquinas con GPU son más fáciles de encontrar en regiones de Estados Unidos, por lo que puede que no exista un VPS con GPU con el tamaño que necesita en la ciudad que quiere.
• La cobertura de soporte de un proveedor pequeño es una cuestión real, no de marketing. Pregunte cuándo hay una persona disponible.

Montreal es la excepción en cuanto al precio. La energía hidroeléctrica de Quebec es barata y los inviernos reducen los costes de refrigeración, por lo que el área de Montreal concentra mucha capacidad con tarifas que compiten con las regiones de Estados Unidos. Si su requisito es Canadá y no una ciudad concreta, empiece allí.

Si los niveles de VPS canadienses parecen demasiado pequeños para la carga de trabajo, compare un VPS con un servidor dedicado antes de decidir que el problema es el país.

Cuándo es adecuado usar alojamiento VPS en Canadá

1. Una ley, un contrato o una política del sector público exige Canadá. Aloje el servicio en Canadá. Nada más de este artículo se aplica, y también debe obtener del proveedor por escrito el compromiso de residencia de los datos.
2. Sus usuarios se encuentran en una misma área metropolitana canadiense y la carga de trabajo depende de la latencia: juegos multijugador, voz, escritorios remotos o trading. Aloje el servicio en la ciudad más cercana y mida ambas opciones antes de firmar nada.
3. Sus usuarios están distribuidos por todo el país. Toronto o Montreal cubren la mayor parte de la población, y una CDN delante de los recursos estáticos beneficia más a un visitante de Vancouver que trasladar el origen.
4. Todo lo demás, que es la mayoría de los casos. Elija en función del precio y del hardware que realmente obtiene. Después, compruebe cómo funciona el soporte a las 2am. Haga una prueba de rendimiento del candidato primero, porque dos planes con la misma hoja de especificaciones no ofrecen el mismo rendimiento: cómo evaluar correctamente el rendimiento de un VPS.

Elija la opción que elija, anote el motivo junto a la decisión. La siguiente persona que pregunte si esto debe estar en Canadá merece algo mejor que una suposición. Si la respuesta fue alguna vez una cláusula contractual, alguien tendrá que encontrarla de nuevo. Cuando el servidor ya exista, los primeros diez minutos en un VPS nuevo influirán más en su seguridad que la ciudad en la que esté.

FAQ

¿PIPEDA exige que mis datos permanezcan en Canadá?

No. PIPEDA (Personal Information Protection and Electronic Documents Act) no establece una obligación de residencia de datos para el sector privado. Enviar información personal a un procesador de otro país es una transferencia para su procesamiento: su organización sigue siendo responsable de los datos, el procesador debe protegerlos de forma comparable y usted debe informar claramente a las personas de que esto ocurre. The Office of the Privacy Commissioner consultó sobre un posible cambio de esta posición en 2019 y después la mantuvo. Las obligaciones de residencia provienen de otras fuentes: la evaluación exigida por la Law 25 de Quebec, leyes del sector público como la PIIDPA de Nova Scotia, las directrices de nube del Government of Canada o una cláusula del contrato con su propio cliente.

¿Notarán los usuarios canadienses que el servidor está en Estados Unidos?

En una aplicación web normal, no. Un viaje de ida y vuelta de Toronto a New York tarda aproximadamente 18 ms, y a Northern Virginia aproximadamente 26 ms. Ambos tiempos son inferiores al de Toronto a Vancouver, que es de 62 ms. Los usuarios perciben el tiempo de respuesta del servidor y el peso de la página mucho antes de percibir 20 ms de red. Sí lo notan en juegos en tiempo real, llamadas de voz y cualquier actividad en la que una persona reacciona a otra.

¿Un centro de datos canadiense está fuera del alcance de la legislación estadounidense?

No automáticamente. US CLOUD Act se aplica a los datos que estén en posesión, custodia o bajo el control de un proveedor estadounidense, sin importar dónde esté ubicado el servidor. Por tanto, una región canadiense operada por una empresa estadounidense sigue estando cubierta. Si su preocupación real es un procedimiento legal extranjero, revise quién opera el servicio y quién posee las claves de cifrado, en lugar de fijarse en la dirección del edificio. El cifrado con claves que usted conserva cambia lo que un proveedor puede entregar.

¿Cómo mido la latencia desde una ciudad en la que no vivo?

Alquile un VPS por horas en esa ciudad, ejecute ping -c 20 y mtr --report --report-cycles 50 hacia su propio servidor y después destrúyalo. La red RIPE Atlas es una alternativa gratuita con probes en ciudades canadienses. Si ICMP está bloqueado, mida el tiempo de la solicitud real con curl -o /dev/null -s -w '%{time_connect} %{time_starttransfer}\n' https://your.server/. Este comando proporciona el viaje de ida y vuelta de TCP y el tiempo total hasta el primer byte.