Kontynuując mini serię artykułów na temat sieci w AWS zajmiemy się teraz tematem VPC Endpointów. Poznamy ich rodzaje oraz problemy z jakimi pozwalają nam sobie poradzić. Omawiając każdy z rodzajów przyjrzymy się również tematowi kosztów. Jak zawsze rozważania przeprowadzamy w kontekście rzeczywistych użyć.
VPC Endpoint
VPC Endpoint to usługa pozwalająca na wpięcie do naszego VPC publicznych usług AWSa. Przykładem takich usług są: S3, DynamoDB, API Gateway, Systems Manager, etc. Pod spodem endpointy oparte są na AWS PrivateLink, dzięki czemu cały ruch nie opuszcza sieci AWS. Powoduje to, że nasze zasoby nie muszą być adresowalne publicznie ani nawet nie muszą mieć połączenia z Internetem. W niektórych przypadkach pomogą także ze zmniejszeniem kosztów!
Podczas wykorzystania VPC Endpointów nie musimy zajmować się tworzeniem odpowiedniej liczby instancji, tak by mogły obsłużyć ruch w naszej sieci. Jednocześnie nie musimy zaprzątać głowy zapewnieniem zastępczych tras czy instancji w przypadku awarii. Wszystko to dzięki temu, że VPC Endpoint jest usługą o wysokiej dostępności, redundancji oraz jest skalowalna w poziomie.
Gateway endpoints
Ten rodzaj endpointów pozwala na dostęp do dwóch usług S3 oraz DynamoDB. Tworzy się je na poziomie VPC, w jednym VPC może znajdować się kilka endpointów do tej samej usługi. Dzięki temu możemy korzystać z różnych polityk dostępu dla każdego z nich.
Ruch do takich endpointów kieruje się za pomocą tablic routingu. Daje to w prosty sposób możliwość wyboru, które z naszych subnetów mają korzystać z serwisu przez określony VPC Endpoint, a które nie.
Interface endpoints
Ten rodzaj endpointów pozwala na dostęp do dużej liczby usług, m.in. Systems Manager, API Gateway, SNS, SQS. Pełna lista wspieranych usług dostępna jest w dokumentacji AWS pod tym adresem.
Interface endpoint ruch może otrzymać na jeden z dwóch sposobów. Pierwszym z nich jest wykorzystanie prywatnego DNSa w VPC – w tym rozwiązaniu cały ruch z VPC przekierowany jest przez ten endpoint. Ten rodzaj użycia nie wymaga żadnych zmian w kodzie. Drugim rozwiązaniem jest korzystanie z prywatnych adresów endpointów i rekonfiguracja klientów tak by używały ich zamiast domyślnych adresów usług lub załączały nagłówek Host (tak jest w przypadku endpointa dla API Gateway’a).
Dostęp do S3 – Gateway endpoint
W tym przypadku mamy aplikację, która przetwarza pliki składowane na S3. Przykładem takiego procesu może być na przykład generacja faktur. Po pobraniu danych z wewnętrznych systemów tworzymy plik html/pdf z naszą fakturą, zapisujemy go w celu archiwizacji oraz udostępniamy użytkownikowi do pobrania.
Trzeba zwrócić tutaj uwagę na to, że jedynym powodem dla którego nasza aplikacja musi znajdować się w publicznym subnecie jest dostępu do usługi S3. Gdyby nie to, aplikacja mogłaby być wrzucona do prywatnego subnetu – bez dostępu do Internetu. Dzięki temu nasz Admin i SecOps będą nieco spokojniejsi. Dodatkowym atutem użycia endpointu jest jego koszt, wynoszący dokładnie zero. AWS nie pobiera opłat za wykorzystanie endpointów typu gateway. Dzięki temu możemy zmniejszyć koszt naszego rozwiązania.
Rozwiązanie
Z pomocą przychodzi tutaj VPC Endpoint, pozwalający na dostęp do S3. Wykorzystanie go eliminuje potrzebę dostępu do publicznego Internetu. Sieciowo wygląda to w następujący sposób.
Usunięcie Internet Gateway’a i dodanie VPC Endpointu wymusza zmianę w tablicy routingu. Polega ona na przekierowaniu pakietów zmierzających do S3 przez VPC Endpoint.
Gotowe CloudFormation dostępne jest poniżej.
Koszt takiego rozwiązania
Przyjmijmy założenie, że nasza sieć działa w regionie EU-WEST-1 – Irlandii a objętość danych które przesyłamy to 10GB.
Jak już wcześniej wspomniałem AWS nie pobiera kosztów za użycie endpointów typu gateway.
W rozważanym przypadku nie będzie dodatkowej oszczędności ponieważ AWS nie pobiera opłat za wykorzystanie Internet Gateway’a.
Natomiast jeżeli nasz ruch do S3 przechodzi przez NAT Gateway jesteśmy w stanie redukować koszta na dwa sposoby.
Pierwszy z nich to eliminacja kosztu transferu, który w przypadku NAT Gateway’a wynosi $0.048 za GB – przy naszych założeniach to oszczędność na poziomie $0.48. Dodatkowo jeżeli NAT Gateway jest wykorzystywany tylko w celu umożliwienia ruchu do S3 będzie można go usunąć, oszczędzając dodatkowe $34.56 (miesięczny koszt istnienia NAT Gateway’a).
Do tego wszystkiego trzeba też dodać koszt transferu danych z naszej aplikacji na EC2 do S3 przez Internet wynoszący $0.09/GB. Jeśli użyjemy VPC Endpointa nasz ruch nie opuszcza sieci AWS-a. Zakładając dodatkowo, że dane leżą w tym samym regionie co nasza aplikacja koszt transferu spada do zera!
Parameter Store – Interface Endpoint
Rzadko kiedy zdarza się, żeby aplikacja korzystała tylko z jednej usługi AWS. W praktycznie każdej aplikacji wymagana jest możliwość konfiguracji zachowania. Trzeba w jakiś sposób przekazać dane dostępowe jak hasła, tokeny czy klucze do API. Nie inaczej jest w przypadku naszej aplikacji. Tutaj zdecydowano się na użycie Systems Managera a dokładniej Parameter Store. Jest to usługa publiczna a co za tym idzie dostęp do niej wymaga komunikacji z publicznym endpointem przez publiczny Internet.
Kilka akapitów wyżej ochoczo usunęliśmy możliwość wyjścia z naszej aplikacji do Internetu. Czy to znaczy, że musimy cofnąć nasze zmiany a przynajmniej przywrócić sam Internet Gateway?
Rozwiązanie
By pozostać w całkowicie prywatnym subnetcie mamy dwie możliwości – wykorzystanie NAT Gateway albo użycie tańszej opcji – VPC Endpoint for SSM. Tym razem jest to jednak inny rodzaj endpointu. Poprzednio wykorzystaliśmy endpoint typu Gateway, tym razem skorzystamy z typu Interface.
Do naszego VPC dodajemy lambdę by móc testować dostęp do Parameter Store. Zakłądamy tutaj, że nasz sekret ma nazwę /application/config/password
Wywołanie tej lambdy bez dodania endpointu kończy się timeoutem.
Dodanie endpointu dla Parameter Store sprowadza się do dodania security grupy oraz endpointu. Musimy uwzględnić tutaj ruch pochodzący z naszej aplikacji oraz samej security grupy lambdy.
Dzięki wykorzystaniu prywatnego DNSa (PrivateDnsEnabled: true na endpointcie) w dostępie do Parameter Store nic się nie zmienia. Klienci nie muszą zmieniać żadnego kodu!
Teraz wywołanie lambdy zwraca poprawnie wartość konfiguracji z Parameter Store:
CloudFormation z oboma endpointami znajduje się tutaj.
Koszt tego rozwiązania
W przypadku Interface Endpointów koszt trzeba rozbijać na dwa składniki: istnienie endpointu oraz transfer. Samo stworzenie endpointu jest obarczone kosztem $0.011 za godzinę, dodatkowo każdy przetworzony GB kosztuje nas $0.01. W omawianym przypadku tworzymy trzy instancje endpointu (trzy AZ) więc automatycznie miesięczny koszt utrzymania samych endpointów wynosi $24.09.
Podsumowanie
VPC Endpoint jako usługa jest przydany jeżeli zależny nam na zupełnym odcięciu się od dostępu do publicznego Internetu. Dzięki temu, że jest to usługa zarządzana przez AWS jej użycie nie dodaje narzutu w utrzymaniu. AWS zapewnia nam wysoką dostępność, skalowanie w poziomie oraz redundancję tej usługi.
Koszt użycia tego mechanizmu jest zdecydowanie niższy w porównaniu do wykorzystania NAT Gateway’a tylko w celu dostępu do publicznych usług AWS. Różnica nie jest mała ponieważ VPC Endpoint pozwoli na zredukowanie rachunku o prawie 80% w przypadku korzystania z jednej usługi (np. S3), patrząc na stały koszt godzinowy endpointu. Jeżli za endpointu będziemy korzystać z pięciu i więcej usług niestety nasz koszt w tym wymiarze wzrośnie.
Patrząc na koszta przez pryzmat transferu VPC Endpoint jest zdecydowanie faworytem. W jego wypadku koszt jest stały i wynosi $0.01 w porównaniu do $0.048 dla Gateway’a za każdy przetworzony GB. Mamy tu stały, 80% zysk.
