AWS Local Zone w Warszawie: co daje, ile kosztuje i kiedy warto z niej skorzystać
Większość polskich firm, które zaczynają przygodę z AWS, automatycznie wybiera region Frankfurt (eu-central-1). To sensowny wybór — najbliższy pełny region AWS, zgodny z RODO, z szerokim wachlarzem usług. Ale od października 2022 roku AWS ma infrastrukturę fizycznie w Warszawie: AWS Local Zone eu-central-1-waw-1a.
Co to zmienia? Kiedy warto z tego skorzystać? I — przede wszystkim — kiedy to nie ma sensu?
Czym jest Local Zone i czym różni się od regionu
Żeby uniknąć nieporozumień: Warsaw Local Zone to nie pełny region AWS. To rozszerzenie regionu Frankfurt — fizyczna infrastruktura w warszawskim centrum danych, na której można uruchomić wybrane usługi AWS bez opuszczania granic Polski.
Pełny region AWS (jak Frankfurt) to trzy lub więcej stref dostępności, setki usług, pełna redundancja. Local Zone to jedno miejsce, ograniczony zestaw usług, za to z jedną konkretną przewagą: dane i compute fizycznie w Warszawie, kilka milisekund od polskich użytkowników.
Warsaw Local Zone jest dzieckiem regionu Frankfurt. VPC, IAM, Route 53, S3 i wszystkie inne usługi niedostępne lokalnie — nadal działają, tylko z Frankfurtu. Local Zone rozszerza Twoje istniejące VPC — tworzysz w nim subnet, a reszta infrastruktury działa dokładnie tak samo.
Co jest dostępne w Warsaw Local Zone
Zestaw usług jest ograniczony, ale pokrywa kluczowe potrzeby obliczeniowe i storage'owe.
Compute — Amazon EC2. Dostępnych jest 10 typów instancji. Najciekawsze dla typowych zastosowań to t3.medium i t3.xlarge (general purpose), c5.2xlarge do c5.24xlarge (compute-optimized), m5.2xlarge (general purpose z większą pamięcią), r5.2xlarge i r5.4xlarge (memory-optimized). Jest też g4dn.2xlarge — instancja z GPU NVIDIA T4, co otwiera drzwi do obliczeń graficznych i inferencji ML z niską latencją.
Storage — Amazon EBS. Wolumeny gp2 (General Purpose SSD) po $0.204/GB/miesiąc. To ponad dwukrotnie drożej niż gp3 we Frankfurcie ($0.0952/GB), a nowszego gp3 w Warszawie nie ma. Dane leżą fizycznie w Polsce, ale za to płacisz.
Sieć — Amazon VPC, subnety, Internet Gateway. Subnet w Local Zone tworzysz dokładnie tak samo jak w zwykłej strefie dostępności. Ruch między Warszawą a Frankfurtem idzie po prywatnym łączu AWS.
Load Balancing — Application Load Balancer. Można postawić ALB bezpośrednio w Warsaw Local Zone i serwować ruch z polskich adresów IP.
Kontenery — Amazon ECS i EKS. Klastry kontenerowe z taskami lub podami mogą działać w Warsaw Local Zone.
Czego tu nie ma: Lambda, DynamoDB, S3 (jako lokalny storage), CloudFront, API Gateway, SES, SNS, SQS. Te usługi używasz standardowo z regionu Frankfurt. To ważne ograniczenie — jeśli Twoja architektura opiera się na serverless, Local Zone niewiele Ci da.
Latencja: Warszawa vs Frankfurt — ile to faktycznie daje
Dla aplikacji hostowanej we Frankfurcie użytkownik w Warszawie doświadcza latencji rzędu 25–35 ms (round trip). To kwestia fizyki — światło w światłowodzie potrzebuje czasu na pokonanie ~700 km.
Z Warsaw Local Zone ten sam użytkownik widzi 2–5 ms. Różnica jest ogromna — ale pytanie brzmi: czy Twoja aplikacja tego potrzebuje?
Kiedy 25 ms vs 5 ms robi różnicę:
Gry online i aplikacje czasu rzeczywistego — tak, absolutnie. 20 ms w grze multiplayer to kwestia grywalności. Jeśli budujesz serwer gry dla polskiego rynku, Warsaw Local Zone to oczywisty wybór.
Zdalne środowiska deweloperskie — People Can Fly (twórcy m.in. Outriders) publicznie mówili o tym, że Local Zone w Warszawie przyspiesza ich zdalne środowiska do pracy nad grafiką 4K. Jeśli Twój zespół pracuje na zdalnych maszynach, 5 ms zamiast 30 ms to realna różnica w komforcie.
Aplikacje tradingowe i fintech — zależy od typu. Dla high-frequency trading każda milisekunda ma cenę. Dla standardowego fintechu, gdzie użytkownik klika przycisk i czeka na odpowiedź — 25 ms jest niezauważalne.
Standardowe aplikacje webowe, SaaS, e-commerce — nie. Użytkownik ładujący stronę sklepu internetowego nie odróżni 25 ms od 5 ms. Czas renderowania frontendu, zapytania do bazy, przetwarzanie logiki — to wszystko zajmuje znacznie więcej niż 20 ms różnicy. A jeśli serwujesz statyczne zasoby przez CloudFront (a powinieneś), to i tak lecą z najbliższego edge location, nie z serwera aplikacyjnego.
Rezydencja danych: „serwery w Polsce" — co to naprawdę oznacza
Dla wielu polskich firm kluczowe pytanie brzmi: „czy nasze dane muszą leżeć w Polsce?" W większości przypadków odpowiedź to: nie.
RODO wymaga, żeby dane osobowe były przetwarzane na terenie EOG (Europejskiego Obszaru Gospodarczego) lub w krajach z odpowiednim poziomem ochrony. Frankfurt jest w Niemczech, Niemcy są w EOG — RODO jest spełnione. Nie ma ogólnego wymogu, żeby dane polskich obywateli leżały fizycznie w Polsce.
Ale są wyjątki. Niektóre sektory regulowane — bankowość, ubezpieczenia, sektor publiczny — mogą mieć dodatkowe wymogi nadzorcze dotyczące lokalizacji danych na terenie kraju. Jeśli Twój regulator wymaga, żeby określone dane nie opuszczały granic Polski, Warsaw Local Zone to jedyny sposób na osiągnięcie tego w ekosystemie AWS.
Są też sytuacje, gdzie „serwery w Polsce" to nie wymóg prawny, ale handlowy. Klient przetargowy chce mieć zapis, że dane leżą w polskim centrum danych. Audytor chce wskazać fizyczny adres. Zarząd czuje się pewniej, wiedząc, że dane są „u nas". To realne potrzeby — i Local Zone je adresuje, nawet jeśli technicznie nie jest to konieczne.
Koszty: ile za to zapłacisz
Local Zone nie jest darmowym dodatkiem. Instancje EC2 w Warszawie są droższe niż odpowiedniki we Frankfurcie — typowo o 10–20%.
Kilka przykładów (ceny on-demand, za godzinę):
t3.medium (2 vCPU, 4 GB): $0.0552 w Warszawie vs $0.0468 we Frankfurcie. Różnica ~18%.
c5.2xlarge (8 vCPU, 16 GB): $0.446 w Warszawie vs $0.388 we Frankfurcie. Różnica ~15%.
m5.2xlarge (8 vCPU, 32 GB): $0.529 w Warszawie vs $0.461 we Frankfurcie. Różnica ~15%.
EBS gp2: $0.204/GB/miesiąc w Warszawie vs $0.0952/GB za gp3 we Frankfurcie. Ponad dwukrotna różnica — i w Warszawie nie ma gp3.
Co ważne: brak Spot Instances i Reserved Instances w Warsaw Local Zone. Płacisz wyłącznie ceny on-demand. Dla workloadów, które we Frankfurcie kupiłbyś na Savings Plans z 30–40% rabatem, brak tej opcji w Warszawie oznacza, że realna różnica kosztowa jest większa niż same 15–18% premii cenowej.
W przeliczeniu na złotówki: t3.medium w Warszawie to ok. 170 zł/miesiąc (on-demand, 24/7). Ten sam typ we Frankfurcie z rocznym Reserved Instance kosztowałby ok. 100 zł/miesiąc. Decyzja o Local Zone to decyzja o prawie dwukrotnie wyższym rachunku za compute — nie o 15% premii.
Architektura: jak sensownie korzystać z Local Zone
Local Zone nie zastępuje regionu. Najlepsze rezultaty daje architektura hybrydowa — wrażliwe na latencję części w Warszawie, reszta we Frankfurcie.
Wzorzec 1: Compute w Warszawie, dane we Frankfurcie. EC2 lub kontenery ECS w Warsaw Local Zone serwują ruch polskim użytkownikom z niską latencją. Baza danych (RDS, DynamoDB), storage (S3), kolejki, Lambda — wszystko działa we Frankfurcie. Komunikacja backend → baza idzie po prywatnej sieci AWS z latencją ~20 ms. Dla typowej aplikacji webowej to transparentne.
Wzorzec 2: Zdalne środowiska deweloperskie. Instancje EC2 (np. c5.2xlarge albo g4dn.2xlarge z GPU) w Warszawie dla polskiego zespołu. Developerzy łączą się przez SSH, VS Code Remote, czy zdalny pulpit z latencją 2–5 ms zamiast 25–35 ms. Szczególnie odczuwalne przy grafice, kompilacjach i dużych projektach.
Wzorzec 3: Edge inference z GPU. g4dn.2xlarge z NVIDIA T4 w Warszawie to ciekawa opcja na inferencję ML. Model wytrenowany w regionie (na p3/p4 instancjach), wdrożony w Local Zone do obsługi polskich użytkowników z minimalną latencją.
Wzorzec 4: Wymogi regulacyjne. Compute i dane w Warszawie, minimalny ruch do Frankfurtu. Wymaga starannego planowania — nie wszystkie usługi są dostępne lokalnie, więc trzeba dokładnie zmapować, które komponenty mogą, a które nie mogą opuścić Local Zone.
Czego nie robić
Nie przenoś całej infrastruktury do Local Zone. To nie pełny region. Nie ma Multi-AZ, nie ma większości zarządzanych usług. Jeśli postawisz jedyną instancję w Warsaw Local Zone i padnie Ci serwer — nie masz automatycznego failoveru.
Nie zakładaj, że Warszawa = taniej. Jest drożej. Jedyny powód, żeby płacić więcej, to latencja albo rezydencja danych. Jeśli żaden z nich nie jest wymaganiem — zostań we Frankfurcie.
Nie licz na serverless lokalnie. Lambda, API Gateway, DynamoDB — to wszystko działa wyłącznie w regionie. Jeśli Twoja architektura to serverless-first, Local Zone nie wniesie nic poza dodatkową złożonością.
Nie ignoruj braku RI/Spot. Policz pełny koszt miesięczny z uwzględnieniem braku rabatów, zanim podejmiesz decyzję. 15% premii na papierze zamienia się w 40–70% realnej różnicy po uwzględnieniu rabatów dostępnych we Frankfurcie.
Jak włączyć Warsaw Local Zone
Local Zone jest domyślnie wyłączona. Aktywacja w kilku krokach:
W konsoli AWS: EC2 → Settings → Zones → znajdź eu-central-1-waw-1 → Enable.
Z CLI: aws ec2 modify-availability-zone-group --group-name "eu-central-1-waw-1" --opt-in-status "opted-in"
Po aktywacji tworzysz subnet w swoim istniejącym VPC, przypisujesz go do eu-central-1-waw-1a i uruchamiasz instancję EC2 wybierając jeden z dostępnych typów. VPC, security groups, IAM — wszystko działa jak zwykle, bo Local Zone to rozszerzenie regionu, nie osobne środowisko.
Dla kogo to naprawdę jest
Warsaw Local Zone ma sens w kilku konkretnych scenariuszach:
Firmy z polskiego sektora regulowanego — banki, ubezpieczyciele, instytucje publiczne — które mają wymóg przetwarzania danych na terenie Polski.
Studia gier i firmy real-time — gdzie milisekundy mają cenę. Serwery gier, zdalne środowiska graficzne, streaming.
Firmy z dużymi polskimi zespołami deweloperskimi — gdzie zdalne maszyny w Warszawie dają odczuwalnie lepszy komfort pracy niż te we Frankfurcie.
Projekty ML z polskimi użytkownikami końcowymi — model trenowany centralnie, inferencja blisko użytkownika na GPU.
Dla standardowej polskiej firmy stawiającej stronę, sklep, SaaS czy wewnętrzne narzędzie — Frankfurt jest lepszym wyborem. Więcej usług, tańsze instancje, rabaty RI/Spot, Multi-AZ. Różnica 20 ms nie uzasadnia wyższych kosztów i ograniczeń.
Tabelka decyzyjna
| Pytanie | Tak → Local Zone | Nie → Frankfurt |
|---|---|---|
| Wymóg rezydencji danych w Polsce? | ✓ | |
| Aplikacja wymaga <10 ms do polskich użytkowników? | ✓ | |
| Zespół na zdalnych maszynach deweloperskich? | ✓ rozważ | |
| GPU blisko polskich użytkowników (ML, grafika)? | ✓ | |
| Standardowa aplikacja web / SaaS / e-commerce? | ✓ | |
| Architektura serverless (Lambda, DynamoDB)? | ✓ | |
| Chcesz korzystać ze Spot / RI / Savings Plans? | ✓ |
W Otocolobus pomagamy polskim firmom projektować infrastrukturę AWS dopasowaną do ich potrzeb — od prostych stron na S3 po złożone architektury z Local Zone. Jeśli zastanawiasz się, czy Twój projekt powinien działać z Warszawy czy z Frankfurtu — napisz do nas. Przeanalizujemy Twój przypadek i powiemy wprost.