Regiony AWS - który wybrać z Polski? Pomiary opóźnień i ceny

Pytanie o wybór regionu pada zwykle raz, przy zakładaniu konta, i zostaje na lata. Polskie poradniki zbywają je jednym zdaniem: Frankfurt, bo najbliżej i bo RODO. Pierwsza część tego zdania jest prawdziwa, druga jest skrótem myślowym, a razem nie wystarczają do decyzji, której później nie da się tanio zmienić.

Postanowiłem sprawdzić, ile ta decyzja faktycznie waży. Zmierzyłem czasy odpowiedzi z polskiego łącza do dwunastu regionów, wyciągnąłem ceny z cennikowego API AWS i porównałem, czego brakuje w tańszych lokalizacjach. Poniżej wszystkie liczby wraz z metodyką, żebyś mógł je powtórzyć u siebie.

Region, strefa dostępności i strefa lokalna

Region to zestaw centrów danych w jednej okolicy geograficznej, z własnym kodem: eu-central-1 to Frankfurt, eu-north-1 Sztokholm, us-east-1 Wirginia Północna. Regiony są od siebie odseparowane - zasób utworzony w jednym nie istnieje w drugim, a większość usług działa wyłącznie w obrębie regionu, w którym je uruchomiłeś.

Strefa dostępności (Availability Zone, AZ) to jedno lub kilka centrów danych wewnątrz regionu, z niezależnym zasilaniem, chłodzeniem i siecią. AWS podaje, że strefy jednego regionu leżą w odległości do 100 kilometrów od siebie - wystarczająco daleko, żeby pożar albo zalanie nie dotknęły dwóch naraz, i wystarczająco blisko, żeby replikacja synchroniczna bazy danych między strefami miała sens.

Na sierpień 2026 AWS ma 39 regionów i 124 strefy dostępności, a zapowiedział kolejne siedem stref oraz dwa regiony: w Arabii Saudyjskiej i w Chile.

Strefa lokalna (Local Zone) to wysunięty kawałek regionu, postawiony bliżej użytkowników w mieście, które nie ma własnego regionu. Warszawa ma taką od października 2022 pod kodem eu-central-1-waw-1 - jest przedłużeniem Frankfurtu, nie osobnym regionem. Wracam do niej w dalszej części, bo to jedyna infrastruktura AWS fizycznie stojąca w Polsce.

Zmierzyłem opóźnienia z Polski do regionów AWS

Prawie każde polskie środowisko AWS, z którym miałem do czynienia, stoi we Frankfurcie. Sprawdziłem, czy ten domyślny wybór ma pokrycie w liczbach - i o ile wyprzedza resztę Europy. Dla każdego regionu wykonałem 15 prób nawiązania połączenia TCP z regionalnym punktem końcowym API EC2 i zapisałem czas samego uzgadniania połączenia, z pominięciem zapytania DNS. Ten czas to jeden obieg pakietu tam i z powrotem, czyli RTT.

Pełne liczby, razem z minimum z każdej serii:

Poza Europą zmierzyłem jeszcze trzy lokalizacje, po pięć prób każda: Oregon us-west-2 175,6 ms, São Paulo sa-east-1 233,6 ms, Sydney ap-southeast-2 306,0 ms.

Najciekawszy jest wynik Sztokholmu. Geograficznie leży dalej niż Frankfurt, ale różnica wyszła na 1,5 ms - mniej niż rozrzut między najlepszym a najgorszym pomiarem w obrębie jednej serii. Dla aplikacji webowej, w której użytkownik i tak czeka kilkaset milisekund na render strony, taka różnica nie istnieje. W cenniku - już tak.

Drugi wniosek dotyczy Irlandii. To najstarszy europejski region AWS i domyślny wybór wielu firm z rozpędu, ale z Polski odpowiada o 16 ms wolniej niż Frankfurt. Przy aplikacji, która robi kilkanaście zapytań do bazy na jedno żądanie użytkownika, te milisekundy się sumują.

Ten sam serwer, inny rachunek

Ceny wyciągnąłem z cennikowego API AWS (AWS Price List Bulk API) - to samo źródło, z którego generują się strony cennikowe. Publikacja danych: 19 sierpnia 2026. Poniżej stawki godzinowe on-demand dla Linuksa oraz miesięczne za gigabajt magazynu.

Wszystkie stawki w USD. Względem Frankfurtu Sztokholm jest tańszy o 10 procent na t3.medium, o 11,3 procent na m7i.large i o 12,2 procent na dyskach EBS gp3. Zurych z kolei jest droższy o 10 procent na maszynach i o 20 procent na dyskach. Te proporcje zmieniają się rzadko, więc tańszy region zostaje tańszy na lata.

Ile to robi na rachunku

Weźmy skromną aplikację produkcyjną: dwie maszyny m7i.large działające całą dobę, 200 GB dysku gp3 i 500 GB w S3 Standard. Transfer i bazę zarządzaną pomijam, żeby porównanie zostało czyste.

276 dolarów rocznie przy trzech zasobach. Przy dziesięciu maszynach i kilku terabajtach w S3 różnica robi się czterocyfrowa - a jedyne, co robisz, to wybierasz inną pozycję z listy rozwijanej przy zakładaniu zasobu. Więcej o tym, z czego składa się rachunek za chmurę, zebrałem w artykule ile kosztuje AWS.

Czego nie znajdziesz w tańszym regionie

Regiony różnią się zestawem dostępnych usług, i to mocno. Nowa usługa startuje zwykle w Wirginii Północnej, potem trafia do Oregonu i Irlandii, a do mniejszych regionów dociera z opóźnieniem liczonym w kwartałach. Część nigdy tam nie dociera.

Konkretny przykład, który sprawdziłem w dokumentacji punktów końcowych AWS: AWS App Runner działa we Frankfurcie, Irlandii, Londynie i Paryżu. Nie ma go w Sztokholmie, Zurychu, Mediolanie ani Hiszpanii. Jeśli budujesz na App Runnerze, wybór regionu jest już za Ciebie podjęty.

Poza App Runnerem w Sztokholmie brakuje między innymi Amazon Rekognition, Amazon Textract, Amazon Comprehend, Amazon Lex, Amazon Personalize, AWS Audit Manager i Amazon WorkSpaces. W Zurychu lista braków jest ponad dwa razy dłuższa i obejmuje rzeczy tak podstawowe jak Amazon Lightsail czy AWS Amplify - obie te usługi w Sztokholmie działają, sprawdziłem endpointy w dokumentacji.

RODO, rezydencja danych i chmura suwerenna

Zdanie "wybierz Frankfurt ze względu na RODO" jest skrótem, który myli dwie rzeczy. RODO nie nakazuje trzymania danych w Unii i nie zakazuje ich transferu poza Europejski Obszar Gospodarczy. Wymaga natomiast podstawy prawnej dla takiego transferu i odpowiednich zabezpieczeń. Wybór regionu daje co innego: rezydencję danych, czyli pewność, gdzie fizycznie leżą dane w spoczynku.

AWS deklaruje to wprost w oświadczeniu o prywatności danych: "We will not move or replicate your content outside of your chosen AWS Region(s) without your agreement". Innymi słowy, region jest granicą, poza którą Twoje dane nie wyjdą bez Twojej zgody. Tym argumentem odpowiadasz działowi prawnemu i wypełniasz ankiety bezpieczeństwa od klientów - i dlatego dla polskiej firmy wybór regionu w UE bywa wymogiem kontraktowym, nawet gdy przepisy dopuszczałyby więcej.

Dla organizacji, którym to nie wystarcza, AWS uruchomił 14 stycznia 2026 osobną partycję: AWS European Sovereign Cloud z pierwszym regionem eusc-de-east-1 w Brandenburgii. Jest obsługiwana przez personel z UE, ma własne systemy tożsamości i rozliczeń, a rachunki wystawia w euro.

Ma to jednak konsekwencję, którą łatwo przeoczyć przy planowaniu: potrzebujesz nowego konta. Istniejące konto AWS nie daje dostępu do tej partycji, logujesz się przez nazwę partycji aws-eusc, a organizacje, role i sieci z konta globalnego nie sięgają do środka. Do tego zestaw usług jest tam znacznie węższy niż we Frankfurcie. Jeśli rozważasz ten kierunek, zaplanuj go jak osobne wdrożenie: z własnym kontem, własnym IAM i osobnym rachunkiem.

Local Zone Warszawa - kiedy ma sens

Warszawska strefa lokalna eu-central-1-waw-1 to jedyna infrastruktura AWS fizycznie stojąca w Polsce. Włączasz ją w ustawieniach konta jako dodatkową strefę regionu Frankfurt, a potem uruchamiasz w niej zasoby jak w każdej innej strefie.

Dostaniesz tam instancje EC2 z rodzin T3, C5, R5, M5 i G4dn, dyski EBS w wariancie gp2, VPC, Application Load Balancer, Direct Connect, Route 53, ECS, EKS, RDS oraz Shield Standard. Nie ma tam S3, ElastiCache, FSx ani EMR - te usługi wywołujesz z macierzystego regionu we Frankfurcie.

Strefa lokalna ma sens w dwóch sytuacjach: gdy potrzebujesz opóźnień jednocyfrowych dla użytkowników w Polsce (gry, transmisje na żywo, zdalne stacje robocze, przetwarzanie obrazu w czasie rzeczywistym) albo gdy przepisy branżowe każą trzymać część przetwarzania w kraju. Do zwykłej aplikacji webowej to nadmiar - dokładasz sobie ograniczony wybór instancji i starsze typy dysków, żeby zejść z 21 ms na kilka.

Ukryte koszty: transfer między strefami i regionami

Sprawdziłem przy okazji obiegową opinię, że amerykańskie regiony mają tańszy transfer. Nie mają: transfer wychodzący do internetu kosztuje 0,09 USD za GB w pierwszym przedziale i tyle samo we Frankfurcie, Sztokholmie, Irlandii, Zurychu i Wirginii Północnej. Pierwsze 100 GB miesięcznie jest bezpłatne w skali całego konta. Ten składnik rachunku nie różnicuje regionów.

Różnicę robią dwie inne pozycje, o których łatwiej zapomnieć:

• Ruch między strefami dostępności w obrębie regionu: 0,01 USD za GB, naliczane po obu stronach. Aplikacja rozłożona na trzy strefy, która intensywnie gada między węzłami, generuje z tego tytułu rachunek, którego nie widać w żadnej kalkulacji "ile kosztuje serwer".
• Ruch między regionami: 0,02 USD za GB przy wyjściu z Frankfurtu. Jeśli aplikacja siedzi w Sztokholmie, a korzysta z usługi dostępnej tylko we Frankfurcie, płacisz za każdy gigabajt wymieniany między nimi.

Ten drugi punkt potrafi zjeść całą oszczędność z tańszego regionu. Przy 200 GB dziennego ruchu międzyregionalnego dopłacasz około 120 USD miesięcznie - pięciokrotnie więcej, niż zaoszczędziłeś na maszynach w przykładzie z tabeli.

Czego us-east-1 nie odda

Wirginia Północna to najstarszy region AWS i kilka rzeczy jest tam przypiętych na stałe, niezależnie od tego, gdzie stoi Twoja aplikacja.

Najczęstszy przypadek: certyfikat SSL dla CloudFront musi być wystawiony w AWS Certificate Manager w regionie us-east-1. Certyfikat z Frankfurtu nie pojawi się na liście wyboru w konfiguracji dystrybucji. Wynika to z konstrukcji usługi: CloudFront jest globalny i swoje certyfikaty czyta z jednego miejsca. Rozliczenia konta, Route 53 i IAM też mają charakter globalny z zapleczem w Wirginii.

Praktyczny wniosek: nawet jeśli cała Twoja infrastruktura siedzi we Frankfurcie, kilka zasobów będziesz miał w us-east-1. Ta wiedza oszczędza godzinę szukania certyfikatu, który "zniknął".

Jak wybieram region - kolejność pytań

Kiedy zaczynam nowy projekt, przechodzę przez pytania w tej kolejności. Pierwsza odpowiedź, która zawęża wybór do jednego regionu, kończy szukanie.

1. Czy umowa albo regulacje wskazują lokalizację danych? Jeśli klient wymaga przetwarzania w Niemczech, dyskusja jest skończona. Jeśli wymaga chmury suwerennej, patrzysz na osobną partycję i osobne konto.
2. Czy któraś z potrzebnych usług jest dostępna tylko w wybranych regionach? Sprawdź punkty końcowe w dokumentacji usługi. Jedna pozycja potrafi zdeterminować cały wybór.
3. Gdzie są użytkownicy? Dla polskiej i środkowoeuropejskiej publiczności zostaje Frankfurt albo Sztokholm. Dla użytkowników z zachodu Europy sensowniejsza bywa Irlandia.
4. Czy aplikacja jest wrażliwa na pojedyncze milisekundy? Jeśli tak, rozważ warszawską strefę lokalną. Jeśli nie, różnica między 21 a 23 ms jest szumem.
5. Dopiero teraz cena. Przy równorzędnych opcjach wybieram tańszą - w praktyce oznacza to Sztokholm zamiast Frankfurtu, o ile zestaw usług się zgadza.

Osobno traktuję środowiska nieprodukcyjne. Środowiska testowe i szkoleniowe mogą stać w tańszym regionie niż produkcja, bo nikt nie mierzy tam opóźnień. Sam rachunek za dev potrafi być wtedy o kilkanaście procent niższy bez żadnego kompromisu.

Czego nie da się cofnąć

Region wybiera się per zasób, nie per konto - i tu zaczynają się schody. Nie ma przycisku "przenieś do innego regionu". Migracja oznacza odtworzenie infrastruktury w nowym miejscu, przeniesienie danych i przełączenie ruchu, czyli tyle pracy, ile kosztowało pierwsze wdrożenie.

Poszczególne zasoby migruje się różnymi drogami: obrazy maszyn kopiuje się między regionami, migawki EBS też, bucket S3 replikuje się przez Cross-Region Replication, a bazę RDS odtwarza z migawki albo przez replikę odczytu w regionie docelowym. Każda z tych operacji kosztuje transfer międzyregionalny i wymaga okna serwisowego.

Gorzej niż migracja wygląda rozjazd: część zasobów w jednym regionie, część w drugim, bo ktoś kiedyś kliknął w domyślną wartość na liście. Zanim zaczniesz porządki, sprawdź, gdzie faktycznie masz zasoby.

for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  n=$(aws ec2 describe-instances --region "$r" \
        --query 'length(Reservations[].Instances[])' --output text)
  [ "$n" != "0" ] && echo "$r: $n instancji"
done

for b in $(aws s3api list-buckets --query 'Buckets[].Name' --output text); do
  loc=$(aws s3api get-bucket-location --bucket "$b" --output text)
  echo "$b -> ${loc:-us-east-1}"
done

Jeśli po tej inwentaryzacji znajdziesz zasoby w regionach, o których nie wiedziałeś - taki rozjazd trafia się częściej, niż wypada przyznać, i opisałem go w artykule o najczęstszych błędach na AWS.

Najczęstsze pytania