VPS w Kanadzie: czy lokalizacja serwera ma znaczenie?

Czy VPS musi znajdować się w Kanadzie?

Hosting VPS w Kanadzie warto wybrać, gdy prawo lub umowa wymagają przechowywania danych na terytorium Kanady. Jest to jedyny twardy powód. Czas odpowiedzi (RTT) z domowego łącza w Toronto do centrum danych w Nowym Jorku wynosi około 18 ms, w porównaniu do około 3 ms w przypadku serwera w Toronto, a niemal żadna aplikacja internetowa nie jest w stanie odczuć tej różnicy.

Trzy czynniki skłaniają użytkowników ku serwerom kanadyjskim. Rezydencja danych jest obowiązkiem prawnym, więc kwestia ta rozstrzyga się sama. Opóźnienie jest mierzalne i zazwyczaj mniejsze, niż oczekują użytkownicy. Rozliczenia w dolarach kanadyjskich stanowią udogodnienie dla księgowości. Przed podjęciem decyzji o zakupie należy ustalić, czy pierwszy z wymienionych punktów dotyczy Twojej sytuacji.

Niniejszy wpis wyjaśnia ogólne zasady działania. Nie stanowi on porady prawnej. Jeśli Twoją organizację wiążą przepisy o ochronie prywatności, wiążącej odpowiedzi udzieli Twój radca prawny.

Lokalizacja danych: jedyny twardy wymóg

PIPEDA (Personal Information Protection and Electronic Documents Act) to kanadyjska federalna ustawa o ochronie prywatności w sektorze prywatnym, która nie wymaga przechowywania danych osobowych w kraju. Traktuje ona przesyłanie danych do podmiotu przetwarzającego za granicą jako transfer w celu przetwarzania: organizacja pozostaje odpowiedzialna za dane, podmiot przetwarzający musi zapewnić porównywalny poziom ochrony, a użytkownicy muszą zostać poinformowani o takim fakcie. Urząd Komisarza ds. Prywatności (Office of the Privacy Commissioner) konsultował zaostrzenie tych przepisów w 2019 roku, po czym utrzymał dotychczasowe stanowisko. Ustawa Bill C-36, przedłożona w czerwcu 2026 roku w celu zastąpienia przepisów PIPEDA dotyczących sektora prywatnego nową ustawą Protecting Privacy and Consumer Data Act, do października 2026 roku nie dotarła do drugiego czytania, zatem PIPEDA pozostaje obowiązującym prawem. Powszechne twierdzenie, że PIPEDA wymusza przechowywanie danych w Kanadzie, jest błędne, mimo że wiele ofert hostingowych powiela ten mit.

Rzeczywiste zasady dotyczące lokalizacji danych istnieją, ale dotyczą węższego zakresu spraw.

• Ustawa 25 (Law 25) w Quebecu wymaga przeprowadzenia oceny przed wysłaniem danych osobowych poza prowincję oraz zapewnienia im odpowiedniej ochrony w miejscu docelowym. Przepis ten obowiązuje od września 2023 roku. Jest to kwestia dokumentacji i decyzji, którą należy umieć uzasadnić, a nie całkowity zakaz.
• Przepisy sektora publicznego wiążą instytucje publiczne oraz obsługujące je firmy. Ustawa PIIDPA w Nowej Szkocji ogranicza przechowywanie danych osobowych poza Kanadą; nowa ustawa Freedom of Information and Protection of Privacy Act, przyjęta w październiku 2025 roku, zastąpi ją 1 kwietnia 2027 roku. Ustawa FIPPA w Kolumbii Brytyjskiej zawierała podobną zasadę do czasu nowelizacji w 2021 roku, która po przeprowadzeniu oceny dopuściła przechowywanie danych za granicą.
• Prace rządu federalnego podlegają wytycznym Government of Canada dotyczącym chmury, które wymagają, aby dane o poziomie ochrony Protected B i wyższym pozostawały w Kanadzie.
• Prowincjonalne ustawy o ochronie prywatności w służbie zdrowia nakładają własne warunki dotyczące miejsca przechowywania dokumentacji medycznej, różniące się w zależności od prowincji.
• Kontrakty z klientami i przetargi publiczne są w praktyce najczęstszym czynnikiem decydującym. Kwestionariusz bezpieczeństwa zawierający wymóg "data at rest in Canada" jest równie wiążący co ustawa, ponieważ został podpisany.

Praktyczny test jest prosty. Czy potrafisz wskazać odpowiedni zapis? Jeśli nikt w organizacji nie potrafi nazwać ustawy lub umowy wymagającej lokalizacji w Kanadzie, wybór opiera się jedynie na opóźnieniach i cenie.

Czy kanadyjskie centrum danych znajduje się poza zasięgiem amerykańskiego prawa?

Nie samo z siebie. Amerykańska ustawa CLOUD Act (Clarifying Lawful Overseas Use of Data Act) obejmuje dane znajdujące się w posiadaniu, pod opieką lub pod kontrolą amerykańskiego dostawcy, niezależnie od fizycznej lokalizacji sprzętu. Zatem region w Toronto obsługiwany przez amerykańską firmę znajduje się w jej zasięgu. Jeśli rzeczywistym wymogiem jest uniknięcie zagranicznych procedur prawnych, a nie kwestia geografii, kluczowe jest to, kto obsługuje usługę i kto posiada klucze szyfrujące. Kanadyjski adres budynku sam w sobie nie rozwiązuje tego problemu.

Drugim zaskoczeniem jest routing. Ruch między dwoma kanadyjskimi miastami często przechodzi przez Stany Zjednoczone, ponieważ to tam historycznie znajdowały się tanie punkty wymiany ruchu (peering). Badacze nazywają to routingiem typu bumerang. Uruchom traceroute, zanim zapewnisz kogokolwiek, że Twoje pakiety nigdy nie opuszczają kraju.

traceroute vps.example.com

Nazwy przeskoków zawierają kody miast, takie jak nyc, chi lub ash. Nazwy te są jedynie wskazówkami i mogą być nieaktualne, więc traktuj je jako powód do zapytania dostawcy, a nie jako dowód. W przypadku danych w tranzycie wiarygodnym rozwiązaniem jest szyfrowanie, które kontrolujesz, a nie mapa. Jeśli potrzebujesz prywatnej ścieżki między własnymi maszynami, samodzielnie hostowany WireGuard VPN zapewnia połączenie, dla którego nie ma znaczenia, przez który kraj przebiega światłowód.

Opóźnienia: mierz je, nie zakładaj ich

Światło w światłowodzie pokonuje około 200 km na milisekundę, więc każde 100 km odległości kosztuje w przybliżeniu 1 ms czasu podróży w obie strony (RTT), zanim uwzględni się jakiekolwiek urządzenia. Trasa z Toronto do Vancouver to około 3400 km w linii prostej, a w rzeczywistości więcej ze względu na przebieg kabli, co wyznacza dolną granicę na poziomie około 40 ms. Rzeczywiste ścieżki generują wyższe wartości.

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

Są to typowe publikowane wartości dla dobrze połączonego łącza konsumenckiego w Toronto. Stanowią one punkt wyjścia, a nie gwarancję. Własne wyniki zależą od sieci dostępowej, peeringu dostawcy oraz pory dnia.

Dwa wiersze warto przeczytać dwukrotnie. Trasa Toronto – Montreal to około 12 ms; miasta te są na tyle blisko, że dla większości celów funkcjonują jako jeden region. Trasa Toronto – Vancouver to około 62 ms, czyli dalej niż Toronto – Północna Wirginia, gdzie wynik wynosi 26 ms. "W Kanadzie" nie oznacza tego samego, co "blisko użytkowników".

Ostatnia mila zazwyczaj i tak dominuje. Światłowód domowy dodaje kilka milisekund. Łącze kablowe dodaje więcej, gdy jest obciążone. Połączenie mobilne samo w sobie dodaje dziesiątki milisekund. Użytkownik telefonu w Toronto może odnotować 50 ms do serwera w Toronto. Przeniesienie serwera do Nowego Jorku dodaje około 15 ms, co daje łącznie 65 ms, a łącze radiowe nadal stanowi większość czasu oczekiwania użytkownika.

Jak testować opóźnienia z lokalizacji użytkowników

Najpierw ustal, gdzie faktycznie znajdują się użytkownicy. Twoje narzędzia analityczne dzielą sesje według miast lub regionów. Korzystaj z tych danych zamiast zgadywać na podstawie lokalizacji biura.

Następnie przeprowadź pomiary z tych miejsc. Nie da się przetestować opóźnień dla Vancouver, siedząc przy biurku w Ottawie. Wynajmij na dwadzieścia minut VPS w docelowym mieście i usuń go po zakończeniu testów. Poproś współpracownika lub klienta o wykonanie jednego polecenia. Możesz również skorzystać z darmowej sieci pomiarowej RIPE Atlas pod adresem https://atlas.ripe.net, która posiada sondy w kanadyjskich miastach i umożliwia wykonywanie z nich poleceń ping.

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

Odczytaj dwie ostatnie linie.

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 to główna wartość. mdev to jitter, czyli rozrzut czasu między pakietami. Każda utrata pakietów na krótkiej trasie jest błędem wymagającym analizy. Wysoki jitter bardziej szkodzi komunikacji głosowej i grom niż nieco wyższa średnia opóźnienia, ponieważ odbiornik musi buforować dane pod kątem najgorszego pakietu, a nie typowego.

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

mtr wyświetla utratę dla każdego przeskoku. Jeśli polecenie kończy się błędem uprawnień, uruchom je z sudo. Środkowe przeskoki często wykazują utratę, która nie jest rzeczywista, ponieważ routery nadają generowanym przez siebie odpowiedziom ICMP najniższy priorytet. Tylko utrata, która utrzymuje się aż do ostatniej linii, jest utratą, której doświadcza Twój ruch. Czytaj najpierw dolny wiersz, a następnie analizuj kolejne w górę.

Gdy ruch ICMP jest blokowany lub ograniczany, mierz czas rzeczywistego protokołu.

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/

Każde pole to skumulowana liczba sekund od rozpoczęcia żądania. connect minus dns to jeden czas obiegu TCP (RTT). tls minus connect to czas nawiązywania połączenia (handshake). ttfb minus tls to kolejny czas obiegu plus czas, jakiego aplikacja potrzebowała na odpowiedź. Ta ostatnia różnica to miejsce, w którym większość wolnych witryn traci najwięcej czasu. ttfb na poziomie 0.8 s na krótkiej trasie oznacza problem z aplikacją, a przeniesienie serwera do innego miasta go nie rozwiąże.

Aby sprawdzić przepustowość, uruchom serwer na VPS, a klienta po stronie użytkownika. iperf3 nasłuchuje na porcie TCP 5201, więc otwórz port za pomocą ufw na czas testu i zamknij go po zakończeniu.

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 odwraca kierunek, dzięki czemu mierzysz zarówno pobieranie, jak i wysyłanie. -P 8 otwiera osiem równoległych strumieni. Jeśli osiem strumieni jest znacznie szybszych niż jeden, ograniczeniem jest okno TCP na długiej trasie, a nie samo łącze, ponieważ pojedynczy strumień może przenieść tylko jedno okno na czas obiegu. To samo okno na trasie do Vancouver przesyła mniej więcej jedną trzecią danych na sekundę w porównaniu z trasą do Nowego Jorku. Kopie zapasowe przesyłane na duże odległości zachowują się tak samo, dlatego kopie zapasowe poza siedzibą z użyciem restic wydają się wolne przy odległym celu, nawet na szybkim łączu.

Uruchom ping w drugim terminalu podczas pracy iperf3. Jeśli czas obiegu wzrośnie z 20 ms do 300 ms w trakcie transferu, oznacza to zjawisko bufferbloat w Twoim sprzęcie dostępowym, którego nie naprawi żadna zmiana lokalizacji centrum danych.

Wykonuj pomiary wielokrotnie i przeprowadzaj je wieczorem. Zatory o godzinie 21:00 to rzeczywistość Twoich użytkowników. Wynik z godziny 4:00 rano to ten, który chętniej prezentuje się w materiałach sprzedażowych.

Co czas podróży w obie strony oznacza dla obciążenia

Zimne ładowanie strony wymaga czterech cykli podróży w obie strony, zanim przeglądarka będzie mogła cokolwiek wyświetlić.

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

Wyszukiwanie DNS trafia do resolvera, a nie bezpośrednio do serwera, i zazwyczaj jest buforowane, więc ciepła wizyta je pomija. Licząc od początku do końca, zimne ładowanie zaczyna się z opóźnieniem 72 ms na ścieżce do Nowego Jorku oraz 248 ms na ścieżce do Vancouver. Wartość dla Nowego Jorku jest niewielka w porównaniu z pojedynczym zapytaniem do bazy danych trwającym 400 ms. Wartość dla Vancouver już nie: stanowi ponad połowę czasu tego zapytania, co zimny użytkownik realnie odczuje. Gdy połączenie jest otwarte, HTTP/2 i HTTP/3 przesyłają wiele żądań jednocześnie, więc koszt ten jest ponoszony raz, a nie dla każdego pliku z osobna. Umieszczenie zasobów statycznych w CDN (content delivery network) sprawia, że miasto pochodzenia przestaje mieć znaczenie, dlatego europejski użytkownik, dla którego czas do Toronto wynosi 98 ms, nadal może korzystać z szybkiej strony.

Gry wieloosobowe w czasie rzeczywistym to przypadek odwrotny, ponieważ czas podróży w obie strony stanowi o jakości doświadczenia. Wynik poniżej 50 ms w szybkiej grze akcji jest odczuwalny jako natychmiastowy, w okolicach 80 ms gracze zaczynają zauważać opóźnienia, a powyżej 120 ms winią serwer. Tutaj region faktycznie decyduje o tym, czy produkt jest dobry. Serwery gier o wolniejszym tempie są znacznie bardziej wyrozumiałe, dlatego uruchomienie serwera Minecraft na VPS pozwala na akceptowalne działanie przy odległościach, które zrujnowałyby strzelankę.

Bazy danych to obszar, w którym wybór regionu powoduje realne szkody. Nigdy nie należy umieszczać aplikacji w jednym regionie, a bazy danych w innym. Każde zapytanie to podróż w obie strony. Strona generująca 40 zapytań wykonuje ich 40: przy 18 ms każde, to większość sekundy, a przy 62 ms każde, to ponad dwie sekundy, dla strony, która przy bazie danych na tej samej maszynie profilowała się na 30 ms. Asynchroniczna replikacja do innego regionu jest dopuszczalna dla replik odczytu i odzyskiwania po awarii. Synchroniczne zatwierdzanie (commit) przez długą ścieżkę dodaje ten czas do każdego zapisu.

Sesje interaktywne plasują się pomiędzy tymi przypadkami. SSH pozostaje komfortowe do około 100 ms, powyżej staje się ociężałe, ponieważ każde naciśnięcie klawisza czeka na powrót echa. mosh przewiduje lokalnie i ukrywa większość tego efektu. Webhooki i wewnętrzne API powinny zawsze znajdować się w tym samym regionie, co usługa, którą wywołują.

Rozliczenia, waluta i podatki

Płatność w dolarach kanadyjskich pozwala uniknąć prowizji za przewalutowanie, którą pobiera wystawca karty, wynoszącej zazwyczaj około 2,5% według stanu na sierpień 2026 roku, a także ułatwia prowadzenie księgowości w jednej walucie. Kanadyjski dostawca wystawia faktury z podatkiem GST lub HST, który zarejestrowany podmiot gospodarczy może odliczyć jako podatek naliczony. Jest to kwestia finansowa z finansową odpowiedzią i nie powinna ona decydować o tym, gdzie kierowany jest ruch sieciowy. Aby dowiedzieć się, ile faktycznie kosztuje serwer i jak porównywać plany bez ryzyka zaskoczenia cenami odnowienia, przeczytaj ile faktycznie kosztuje VPS miesięcznie.

Koszty mniejszego rynku

Kanada jest niewielkim rynkiem hostingowym w porównaniu do Stanów Zjednoczonych, dlatego uczciwa analiza wymaga wskazania ograniczeń, z którymi należy się liczyć.

• Mniejsza liczba dostawców konkurujących o klienta sprawia, że cena za gigabajt pamięci RAM lub dysku jest zazwyczaj wyższa w przypadku maszyn tej samej klasy.
• Zasoby koncentrują się w Toronto i Montrealu, przy mniejszej dostępności w Vancouver i Calgary. Drugi kanadyjski region na potrzeby failover często oznacza długą ścieżkę sieciową lub konieczność wyjścia poza granice kraju.
• Niewielki regionalny dostawca może korzystać z jednego budynku i jednego lub dwóch operatorów szkieletowych. Należy pytać o liczbę operatorów oraz o procedury na wypadek awarii jednego z nich.
• Oferta sprzętowa jest węższa. Duże instancje oraz maszyny z GPU są łatwiej dostępne w regionach USA, dlatego GPU VPS o pożądanych parametrach może nie być dostępny w wybranym mieście.
• Dostępność wsparcia technicznego u małego dostawcy jest kwestią realną, a nie marketingową. Należy ustalić godziny pracy personelu.

Montreal stanowi wyjątek pod względem cen. Tania energia hydroelektryczna w Quebecu oraz zimy obniżające koszty chłodzenia sprawiają, że okolice Montrealu oferują dużą przepustowość w cenach konkurencyjnych wobec regionów USA. Jeśli wymogiem jest Kanada, a nie konkretne miasto, warto rozpocząć poszukiwania właśnie tam.

Jeśli kanadyjskie plany VPS wydają się zbyt małe dla danego obciążenia, przed podjęciem decyzji o zmianie kraju warto porównać VPS z serwerem dedykowanym.

Kiedy hosting VPS w Kanadzie jest właściwym wyborem

1. Ustawa, umowa lub polityka sektora publicznego wskazują Kanadę. Hostuj w Kanadzie. Żaden inny punkt tego wpisu nie ma zastosowania, a zobowiązanie dotyczące rezydencji danych należy uzyskać od dostawcy na piśmie.
2. Użytkownicy znajdują się w jednym kanadyjskim obszarze metropolitalnym, a obciążenie jest ograniczone opóźnieniami: gry wieloosobowe, komunikacja głosowa, zdalne pulpity lub handel finansowy. Hostuj w najbliższym mieście i zmierz obie opcje przed podpisaniem jakiejkolwiek umowy.
3. Użytkownicy są rozproszeni po całym kraju. Toronto lub Montreal obejmują największą część populacji, a CDN przed zasobami statycznymi zrobi więcej dla użytkownika z Vancouver niż przeniesienie serwera źródłowego.
4. Wszystkie pozostałe przypadki, czyli większość. Wybieraj na podstawie ceny i rzeczywistych parametrów sprzętowych, a następnie sprawdź, jak wygląda wsparcie o godzinie 2:00 w nocy. Najpierw przetestuj kandydata, ponieważ dwa plany o tej samej specyfikacji nie oferują tej samej wydajności: jak poprawnie przeprowadzić benchmark VPS.

Niezależnie od wyboru, zapisz powód podjętej decyzji. Kolejna osoba, która zapyta, czy serwer powinien znajdować się w Kanadzie, zasługuje na coś więcej niż zgadywanie, a jeśli odpowiedzią była klauzula umowna, ktoś będzie musiał ją ponownie odnaleźć. Gdy serwer już istnieje, pierwsze dziesięć minut na nowym VPS ma większe znaczenie dla bezpieczeństwa niż jego lokalizacja.

FAQ

Czy PIPEDA wymaga, aby moje dane znajdowały się w Kanadzie?

Nie. Ustawa PIPEDA (Personal Information Protection and Electronic Documents Act) nie zawiera wymogu rezydencji danych dla sektora prywatnego. Przesyłanie danych osobowych do podmiotu przetwarzającego w innym kraju jest transferem w celu przetwarzania: organizacja pozostaje odpowiedzialna za dane, podmiot przetwarzający musi chronić je w porównywalny sposób, a użytkownicy muszą zostać poinformowani o takim fakcie. Urząd Komisarza ds. Prywatności (Office of the Privacy Commissioner) konsultował zmianę tego stanowiska w 2019 roku, po czym utrzymał je w mocy. Wymogi dotyczące rezydencji danych wynikają z innych źródeł: oceny w ramach ustawy Law 25 w Quebecu, ustaw sektora publicznego, takich jak PIIDPA w Nowej Szkocji, wytycznych rządu Kanady dotyczących chmury lub klauzuli w Twojej własnej umowie z klientem.

Czy kanadyjscy użytkownicy zauważą serwer w Stanach Zjednoczonych?

W przypadku typowej aplikacji internetowej – nie. Czas podróży w obie strony (round trip) z Toronto do Nowego Jorku wynosi około 18 ms, a do północnej Wirginii około 26 ms; oba te wyniki są krótsze niż czas z Toronto do Vancouver, który wynosi 62 ms. Użytkownicy zauważą czas odpowiedzi serwera i wagę strony znacznie wcześniej, niż odczują 20 ms opóźnienia sieciowego. Zauważają to w grach czasu rzeczywistego, połączeniach głosowych oraz w sytuacjach, w których jedna osoba reaguje na działania drugiej.

Czy kanadyjskie centrum danych jest poza zasięgiem prawa USA?

Nie automatycznie. Ustawa US CLOUD Act obejmuje dane będące w posiadaniu, pod opieką lub pod kontrolą dostawcy z USA, niezależnie od tego, gdzie znajduje się serwer. Kanadyjski region obsługiwany przez amerykańską firmę nadal podlega tym przepisom. Jeśli rzeczywistym problemem jest zagraniczna procedura prawna, należy zwrócić uwagę na to, kto obsługuje usługę i kto posiada klucze szyfrujące, a nie na adres budynku. Szyfrowanie kluczami, które przechowujesz samodzielnie, zmienia zakres danych, które dostawca jest w stanie przekazać.

Jak zmierzyć opóźnienie z miasta, w którym nie mieszkam?

Wynajmij godzinowy VPS w tym mieście, uruchom ping -c 20 oraz mtr --report --report-cycles 50 w kierunku własnego serwera, a następnie usuń instancję. Sieć RIPE Atlas to darmowa alternatywa z sondami w kanadyjskich miastach. Jeśli protokół ICMP jest zablokowany, zmierz czas rzeczywistego żądania za pomocą curl -o /dev/null -s -w '%{time_connect} %{time_starttransfer}\n' https://your.server/, co pozwoli uzyskać czas podróży TCP w obie strony oraz pełny czas do pierwszego bajtu (TTFB).