Strona Główna / Blog

Razem czy Osobno? Czy Da się Połączyć AWS z Azure?

Łukasz Dorosz

Łukasz Dorosz

Ponad 14 lat w branży IT. Konsultant i architekt projektów Amazon Web Services. Entuzjasta rozwiązań serverless. Współtwórca AWS User Group (2900+ osób). Jeden z nielicznych w Polsce posiadaczy certyfikacji - AWS Certified Solutions Architect - Professional, AWS Certified DevOps Engineer - Professional. Masz pytanie, napisz do mnie.

Wraz ze wzrostem popularności rozwiązań chmury publicznej zwiększa się gama jej zastosowań oraz mnożą różne koncepcje wykorzystania. Niektóre firmy opierają się na jednej chmurze, jak AWS czy Azure, i tam uruchamiają swoje systemy. Z kolei inni wykorzystują więcej niż jednego dostawcę chmury publicznej.

Dostawcy chmury – łączyć ich czy dzielić?

Powody tego drugiego podejścia są różne. Jednym z takich przypadków może być posiadanie systemów u jednego dostawcy, np. MS Azure, a następnie robienie kopii bezpieczeństwa bądź realizowanie scenariuszy Disaster Recovery w drugiej chmurze. Innym wariantem jest budowanie systemów rozproszonych między różnymi dostawcami. Część funkcjonalności działa w jednej chmurze, ale inne elementy są uruchomione i podłączone do innego dostawcy, który zapewnia je jako usługę. Czasem zdarza się też, że chmura w danym zastosowaniu działa lepiej lub jest po prostu tańsza.

Bez względu na to, co jest powodem połączenia kilku chmur, zawsze kluczowy będzie sposób, w jaki zapewnimy komunikację między elementami systemu rozproszonymi po różnych dostawcach. Przyjrzyjmy się kilku metodom i zobaczmy, jak możemy z nich skorzystać.

1. Komunikacja po API

Kiedy korzystamy z usług umożliwiających interakcję po publicznym API, model zapewnienia łączności jest dość prosty. W tym wypadku „widzialność” pomiędzy serwisami jest praktycznie natychmiastowa. Musimy oczywiście uwzględnić dodatkowe szczegóły, jak np. bezpieczeństwo, ale sama komunikacja będzie zachodzić prawie automatycznie.

Spójrzmy na przykład.

Załóżmy, że mamy fragment prostej aplikacji, część której wystawiona jest na MS Azure. Jest to aplikacja uruchomiona w Web Apps dostępna z Internetu. W pewnym momencie pojawia się potrzeba skorzystania z serwisu Amazon S3 (usługa do przechowywania danych obiektowych). Poprzez część aplikacji wystawionej w Web Apps ładowane będą pliki, na przykład zdjęcia, które następnie będą odkładane w koszyku na S3.

 

Serwis S3 jest publicznie dostępny po API, a komunikacja sieciowa w tym wypadku nie jest problemem. Jedyne, o co pozostaje nam się zatroszczyć, to uwierzytelnienie i odpowiednie uprawnienia.

Jak to działa?

Użytkownik wchodzi do aplikacji wystawionej przez Web Apps i uruchamia proces ładowania plików. Następnie aplikacja z odpowiednimi uprawnieniami komunikuje się z usługą S3 (cała transmisja jest oczywiście szyfrowana) i przesyła do niej dane, które zapisane są w odpowiednim koszyku. Proste, prawda?

2. Mniej bezpośrednio

Przejdźmy jednak dalej i wyobraźmy sobie, że nasza „apka” się rozwija. Teraz pojawia się nowa funkcjonalność, w której użytkownik może filtrować obrazki na podstawie przypisanych im tagów. Na platformie AWS w usłudze DynamoDB znajduje się NoSQL-owa baza danych, w której przechowywane są dodatkowe informacje o obrazkach, jak np. URL do zdjęć na S3, id użytkownika, który dane zdjęcie umieścił, oraz przypisane dodatkowe tagi.

Teraz chcemy, aby nasza aplikacja w MS Azure mogła wysłać zapytanie do bazy danych o URL o wszystkie zdjęcia z konkretnym tagiem. Oto, jak może wyglądać przykładowe rozwiązanie i przede wszystkim kolejna możliwość zapewnienia komunikacji:



Oczywiście jest to uproszczony diagram pokazujący konkretny wycinek funkcjonalności, ale generalnie w ten sposób możnaby zobrazować kolejną metodę zapewnienia komunikacji między naszymi chmurami. Zatem co my tutaj mamy?

Bramka API

Jak wspomniałem przed chwilą, w tabeli DynamoDB przechowywujemy dodatkowe informacje o zdjęciach, jak chociażby tagi. Poza tym pojawia się tutaj jeszcze jeden serwis AWS Lambda, czyli Function as a Service. Jego zadaniem jest obsługa zapytań od aplikacji w MS Azure, czyli zwracanie listy plików o podanym tagu. Jednak mimo że zarówno DynamoDB jak i Lambda są rozwiązaniami komunikującymi się po API, to nie łączymy się z nimi bezpośrednio z Internetu.

Dlatego w tym wypadku wykorzystujemy jeszcze jeden serwis, Amazon API Gateway, który pełni rolę bramki API dla wspomnianych wcześniej serwisów.

Teraz, kiedy użytkownik zechce wyświetlić zdjęcia o podanym tagu, aplikacja wyśle to żądanie do funkcji lambda wystawionej poprzez API Gateway. Następnie funkcja lambda pobierze z tabeli DynamoDB listę URL-i i tą samą drogą przekaże ją do aplikacji.

3. Trochę bardziej „staromodnie”

Jednak to nie wszystko. Nasza aplikacja rozwija się dalej, ale tym razem w naszej architekturze pojawiają się bardziej klasyczne elementy jak…. wirtualne maszyny. Celowo wybrałem takie usługi, gdyż tym razem zależy nam, aby zapewnić im bardziej bezpośrednią komunikację sieciową.

Każda z plaform chmurowych ma własną, ale bardzo podobną do siebie koncepcję sieci. W MS Azure do dyspozycji mamy VNET-y, a w AWS VPC. Koncepcja ich działania jest zbliżona. Każdy VNET/VPC jest takim trochę wirtualnym data center, w ramach którego określamy blok sieciowy, a potem dzielimy na mniejsze podsieci. Każdy VNET/VPC zapewnia izolację oraz dostarcza różne mechanizmy kontroli przepływu ruchu, listy dostępu, Security Groups, czy Routing Tables.

Wróćmy jednak do naszego przypadku. W Azure i w AWS mamy teraz części aplikacji uruchomione na wirtualnych maszynach. Każda z nich umieszczona jest odpowiednio w VNET i VPC:

 

Naszym celem jest zapewnienie bezpiecznej komunikacji między tymi środowiskami. Tym razem wykluczam wystawianie czegoś po API, a po prostu chcę spiąć bezpieczene połączenie między sieciami. Jak to zrobić?

Dwie platformy, dwie możliwości

Każda z platform oferuje gotową funkcjonalność do kreowania dedykowanych połączeń szyfrowanych VPN. Jednak z racji odmiennego podejścia do komunikacji, trudno jest tu zestawić takie połączenie z wykorzystaniem natywnych rozwiązań po obu stronach. Do wyboru mamy zatem dwie opcje:

  • Virtual Network Gateway po stronie Azure i dedykowana maszyna po stronie AWS.
  • Virtual Private Gateway po stronie AWS i dedykowana maszyna po stronie Azure.

Należy zdecydować, po której stronie wybierzemy rozwiązanie natywne danego dostawcy, a po której uruchomimy własną maszynę wirtualną, która będzie terminować połączenie VPN i przez którą będzie przechodził cały ruch.

 

Wybierzmy wariant pierwszy, czyli w MS Azure korzystamy z natywnego VPN-a oferowanego w ramach platformy. Na AWS zainstalujemy dedykowaną maszynę.

Teraz, kiedy elementy naszej aplikacji będą komunikować się ze sobą, cały ruch sieciowy będzie „przepychany” przez dedykowane połącznie szyfrowane VPN. Tutaj warto zwrócić uwage, że po stronie AWS mamy maszynę wirtualną. W tym wypadku warto zastanowić się nad ewentualną redundancją takiego połączenia.

A zatem czy się da? Jak widać – TAK!

I to na kilka sposobów. W zależności od tego, z jakich serwisów korzystamy, w grę wchodzą różne opcje. Od wariantu prawie bezpośredniej komunikacji po API, tak jak w pierwszym przypadku, aż po zestawianie szyfrowanego połączenia VPN.

Pamiętać jednak należy, że w chmurze płacimy za ruch sieciowy, w większości przypadków wychodzący z chmury. Ważne jest zatem, aby dobrze policzyć koszty, uwzględniając też różne ceny usług.

 

Dołącz do listy mailingowej!

Dołącz do naszego newslettera

Staramy się wysyłać tylko wartościowe informacje, np. co miesiąc dostaniesz spis najważniejszych nowości z chmur Azure, AWS i GCP, z krótkimi opisami i linkami.