AWS Local Zone w Warszawie - co to tak naprawdę daje?

W czwartek 2 grudnia 2021 roku, w trakcie re:Invent 2021, Werner Vogels zapowiedział powstanie w 2022 roku Local Zone w Warszawie. Zapanował ogólny entuzjazm i radość.

Postaram się wyjaśnić czym Local Zone jest, a czym zdecydowanie nie jest.

AWS Region i High Availability

W żadnym wypadku nie możemy porównywać Local Zone do regionu. To zupełnie coś innego.

Region w AWS to koncepcja połączonych ze sobą data centers, zgromadzonych, nomen omen, w jakimś regionie. Taka grupa data centers to z kolei Availability Zone. Każdy z regionów składa się więc z wielu, odseparowanych od siebie AZs.

Każda z takich availability zon posiada odrębne źródła zasilania i połączone są między sobą szybkimi i redundantnymi sieciami.

Takich regionów w chwili obecnej mamy w AWS 25. Są to naprawdę ogromne pod kątem infrastruktury rozwiązania.

Projektując wysoko dostępne rozwiązania w chmurze AWS najczęściej koncentrujemy się na jednym regionie. Najczęściej, ponieważ w przypadku konieczności zapewnienia naprawdę bardzo wysokiej dostępności, rozwiązania mogą być tworzone za pomocą kilku regionów. To na wypadek awarii jednego z nich.

Załóżmy jednak, że pozostajemy na poziomie jednego regionu. Także w takim przypadku warto zadbać o HA. Przypadki, w których usługi w jakiejś availability zonie przestają działać się zdarzają. Dlatego warto używać ich więcej niż jednej, w ramach regionu.

Tutaj sprawy zaczynają się komplikować. Usługi zarządzane przez vendora, takie jak Amazon S3 lub moja ulubiona AWS Lambda, domyślnie uruchamiane są w kilku AZs i ten problem, z naszego punktu widzenia nie istnieje. W przypadku usług bardziej typowych, uruchamianych w sieciach, takich jak maszyny wirtualne w usłudze Amazon EC2 lub klastry kubernetesa w Amazon EKS to od nas zależy jak rozmieścimy zasoby. I w znacznej większości przypadków umieszczamy je w ramach kilku AZs.

Siła regionu. Awaria nawet całego data center nie powoduje awarii naszej aplikacji.

AWS Local Zone

Zacznę od powodu wprowadzenia local zones do oferty. W większości przypadków wydajność zapewniana przez zasoby w regionach jest całkowicie wystarczająca. Istnieją jednak aplikacje, które wymagają bardzo krótkich czasów odpowiedzi lub ogromnej przepustowości. Gry real-time, streaming video na żywo, machine learning, procesy migracyjne to niektóre z przykładów. Dla takich rozwiązań local zone, które rozmieszczone są blisko dużych aglomeracji powinny dobrze się sprawdzić. Nie są one jednak regionem. Są częścią regionu, jeszcze jedną zoną, umieszczoną bliżej użytkownika.

W chwili obecnej dostępne są one tylko w USA. Na przyszły rok AWS zapowiedział uruchomienie kolejnych, na całym świecie. W tym jedną w Polsce.

Oprócz opisanych już różnic, local zone od regionu różni się także dostępnością usług.

W każdej z dotychczasowo dostępnych local zones dostępne są na chwilę obecną następujące usługi:

• Amazon EC2 - maszyny wirtualne
• Amazon EBS - storage blokowy
• Amazon EKS - klastry kubernetesa
• Amazon ECS - własne rozwiązanie AWS do orkiestracji kontenerów
• Amazon VPC - sieci

Local zone w Los Angeles ma kilka dodatkowych usług jak bazy danych RDS czy ElastiCache, ale nigdzie nie znajdziemy usług Cloud Native w rodzaju AWS Lambda, Amazon DynamoDB czy Amazon S3. Możemy z nich oczywiście korzystać, ale w ramach głównego regionu.

Poza dostępnością usług, różnią się także ich ceny. Przykładowo, gdy to piszę, instancja t3.xlarge w regionie Ohio kosztuje 0,1664$ za godzinę w modelu on-demand. Ten sam region, ale local zone w Miami to koszt 0,208$ za godzinę. Dodatkowo nie w każdej local zonie dostępne będą na przykład instancje typu spot, przy wykorzystaniu których oszczędności sięgają nawet 90%.

Jak to wygląda w praktyce?

Domyślnie local zony nie są nawet dostępne. Aby umożliwić sobie korzystanie z nich, należy je włączyć w Dashboardzie EC2 na poziomie regionu.

Ja uruchomiłem sobie taką zonę w regionie Ohio, w Bostonie.

Od tego momentu mogę z takiej local zony korzystać podobnie do availability zony. Pokażę na przykładzie sieci.

VPC w AWS tworzymy na poziomie regionu. Podsieci na poziomie availability zon. Bez korzystania z local zony możemy mieć więc coś podobnego do schematu poniżej:

Wszystkie podsieci mogą być oczywiście ze sobą połączone. Dodajmy teraz do tego podsieć w local zone w Bostonie i nasza sieć będzie wyglądała na przykład tak:

Nic nie stoi na przeszkodzie abyśmy umieszczali nasze zasoby w każdej z podsieci. Przy odpowiedniej konfiguracji będą one mogły się pomiędzy sobą komunikować.

Elementy krytyczne z punktu widzenia wydajności możemy umieścić w local zone, a pozostałe w innych AZs w ramach regionu.

Podsieci może być oczywiście więcej, po kilka w jednej AZ.

Podsumowanie

Zawsze powtarzam, że nawet uruchomienie całego regionu w naszym kraju w wielu przypadkach nie zmieni aż tyle, ile mogłoby się wydawać. Tym bardziej nie zmieni tego local zone uruchomione w Warszawie.

W większości przypadków już to co oferuje AWS sprawdzi się doskonale w ramach zaspokajania naszych potrzeb. Korzystajmy więc po prostu mądrze z tego co jest dostępne.

Nie popadajmy w euforię z powodu local zone w Polsce, ale także nie wstrzymujmy ekspansji chmurowej w oczekiwaniu na region w Polsce. Nie kierujmy się też przypadkiem tym czynnikiem przy wyborze dostawcy chmurowego. Oczywiście jeżeli nie stoją na przeszkodzie względy prawne.