Środowisko AWS – o czym pamiętać przy wdrażaniu i skalowaniu?

Jeśli jesteś właścicielem startupu,  być może martwisz się skalowaniem swojej aplikacji wraz ze wzrostem jej popularności. Z kolei jako CTO przedsiębiorstwa możesz się zastanawiać, jak poradzić sobie ze skalowaniem w chmurze,  kiedy firmy rosną organicznie i dokonują fuzji oraz przejęć. Jakie wyzwania nosi ze sobą środowisko AWS i  zarządzania jego zasobami?

Wdrażając środowisko chmurowe, najczęściej zaczynasz od założenia pojedynczego konta i wprowadzenia do niego użytkownika. Z czasem do tego konta dodajesz następnych użytkowników, a następnie w miarę skalowania lub potrzeby zmiany uprawnień widzisz potrzebę utworzenia kolejnego konta wraz z nowymi użytkownikami. Pomimo poprawnej konfiguracji tych dwóch kont organizacja dalej rośnie i się skaluje, więc wkrótce, zanim się zorientujesz, masz wiele różnych kont, z czego większość jest do siebie podobna. W pewnym momencie koszty drastycznie rosną, a zespół finansowy zadaje pytania o potrzebę istnienia wszystkich tych kont. 

Takie zamieszanie wynika z braku wcześniejszego planowania architektury. Pomysł na udane skalowanie polega na przewidywaniu i ustawieniu architektury chmurowej tak, aby później było łatwiej ją skalować. Choć nie zawsze możesz przewidzieć przyszłość, już na początku musisz przyjąć pewne założenia. Doświadczenie pokazuje, że wolniejszy wzrost na początku pomoże w dokonywaniu szybszych zmian w przyszłości.  O czym zatem należy pamiętać przy wdrażaniu środowiska AWS? W tym artykule skupimy się na planowaniu elementów wymagających skalowania.

Elementy struktury środowiska AWS

Kiedy mówimy o strukturze, chcemy o niej myśleć, jak o budowaniu budynku. Jest to najprostszy sposób, aby zrozumieć, co się w niej dzieje, jeśli chodzi o budowanie środowiska chmury. Myśląc o budowaniu budynku, masz do dyspozycji wiele różnych elementów. Na pewno składa się z cegieł,  jako zasadniczych elementów tworzących budynek. Następnie myślisz o ramie lub strukturze, która definiuje, jak wygląda twój budynek.

Kiedy budynek jest już ukończony, potrzebujesz menedżera, który ma wszystkie potrzebne narzędzia do skutecznego zarządzania tym budynkiem. 

Na koniec chcesz posiadać rozwinięty system bezpieczeństwa, który jest w stanie np. zablokować drzwi, utrzymać ludzi, którzy w nim przebywają, a następnie również ma wpływ na bezpieczeństwo wszystkich procesów w budynku.

Przełóżmy to teraz na wszystkie elementy struktury chmury AWS.

Konta AWS jako bloki konstrukcyjne

Konta AWS są jak te cegły,  bloki konstrukcyjne w chmurze. Możesz tworzyć instancje chmurowe szybko oraz elastycznie je rozwijać. Myśląc o koncie, bierzesz pod uwagę zasoby, które rozwijasz, usługi i aplikacje, które służą twoim klientom.np., oprogramowanie, sieci lub przechowywanie danych. Chodzi o myślenie o koncie jako kontenerze zasobów, a nie pojedynczym użytkowniku.

Co brać pod uwagę przy skalowaniu na różnych kontach?

• Ograniczenia 

Powodem, dla którego zalecamy skalowanie pomiędzy kontami, jest zasadniczo to, że kiedy trafisz na limit w ramach jednego konta, to możesz skalować w ramach zasobów drugiego konta.

• Bezpieczeństwo (naturalne granice, izolacja)

Jeśli chodzi o bezpieczeństwo, operowanie na różnych kontach daje naturalne granice izolacji. Gdy tworzysz kolejne konto dla innego projektu lub usługi, nie jest ono domyślnie połączone z Twoimi innymi kontami, nie ma do niego dostępu. Jeśli wystąpi problem na jednym z Twoich kont, jest on izolowany od bieżącego konta. 

• Zgodność z przepisami/procesy biznesowe

Jeśli potrzebujesz, aby pewne obciążenia były zgodne z określonymi przepisami, możesz tworzyć konta i budować je tak, aby były zgodne z tymi regulacjami. Daje to dużą elastyczność w zakresie budowania środowiska dla konkretnych potrzeb. 

Jednostki organizacyjne (OU) jako struktura, która pomaga skategoryzować konta

Aby zbudować konstrukcję, potrzebne są podpory, wiązania lub ramy, które wyznaczają wzór dla cegieł. Jednostki organizacyjne są strukturą, pewną ramą, która umieszcza konta na miejscu i daje możliwość dostosowania różnych środowisk do większego środowiska AWS. Jednostka organizacyjna (OU) to logiczne zgrupowanie kont w Twojej organizacji, utworzone przy użyciu AWS Organizations. Jednostki OU umożliwiają organizowanie kont w hierarchię i ułatwiają stosowanie kontroli zarządzania.

Kiedy projektujesz strukturę jednostek organizacyjnych, rodzaj swojego środowiska, chcesz zacząć od mniejszej struktury, a następnie ją rozszerzać. Polega to na budowaniu tych niestandardowych środowisk oraz umieszczeniu w nich zabezpieczeń, które określają, jakie działania mają mieć miejsce. 

Jeśli nie posiadasz żadnej struktury, jednostek organizacyjnych, zacznij od jednej, a potem rozszerzaj na inne.

Co robić, jeśli chcesz mieć skalowalny model środowiska AWS?

Jeśli projektujesz OU wokół swoich zespołów biznesowych, te zespoły biznesowe ulegają znacznym wahaniom. Właściciel konta lub zespołu może się zmienić z dnia na dzień. Dlatego warto rozważyć zaprojektowanie swoich jednostek organizacyjnych lub kont wokół aplikacji, usług i bezpieczeństwa, a niekoniecznie wokół zespołów biznesowych. 

4 podstawowe jednostki organizacyjne, które działają w różnych formach działalności

 

1. Bezpieczeństwo (Security)  –  zawiera archiwum logów, określa zasady i narzędzia bezpieczeństwa.
2. Infrastruktura (Infrastructure)  –  zawiera konta dla infrastruktury Twojego środowiska (usługi współdzielone, usługi sieciowe).
3. Sandbox — hostuje wszystkie konta, które są zbudowane dla deweloperów, aby testować rozwój aplikacji bez ograniczeń innych jednostek organizacyjnych (stały limit wydatków, odłączenie od sieci).
4. Obciążenia (Workloads) – miejsce, w którym skaluje się oprogramowanie na wiele różnych kont, np. zagnieżdżone OU odzwierciedlające cykl rozwoju oprogramowania. Oddziela środowisko, chroniąc produkcyjne obciążenia, a następnie nadal pozwala na skalowanie do dodatkowych aplikacji i usług w miarę ich rozwoju.

Inne polecane OUs

• Policy staging — Weryfikacja i testowanie zmian SCP, miejsce, w którym testujesz polityki, zanim zastosujesz je w swojej organizacji.
• Suspended — Zamykanie kont, oznaczanie ich przed przeniesieniem.
• Individual Users — Jeśli masz indywidualnych użytkowników w swojej organizacji, którzy potrzebują specjalnych kont, np. zespół analityków biznesowych wymaga miejsca do hostowania wszystkich swoich tabel, możesz chcieć mieć konta indywidualnych użytkowników w ramach konkretnego OU. Są one samoistnie zdefiniowane poza innymi obciążeniami i zasobami.
• Exeptions — Miejsca wysoce spersonalizowane, nowy produkt, który wymaga on wysoce niestandardowych zasad, niemających zastosowania do reszty środowiska. 
• Deployments — przeznaczona dla kont, które hostują wdrażanie CI/CD.
• Transition — gdy dochodzi do wielu fuzji i przejęć, istnieje wiele przypadków, w których konta przychodzą i odchodzą z Twojej organizacji. Przejściowe OU jest miejscem, gdzie można hostować te konta i testować ich funkcjonalność, polityki, tak by upewnić się, że będą pasować do innych miejsc w organizacji. 

Administrowanie środowiskiem AWS

Organizacja ma trzy konkretne elementy:

Root — Definiuje granice Twojej organizacji, określa jakie konta są w Twojej organizacji. 

OU — Jednostki organizacyjne, o których wspomnieliśmy wcześniej

Konta członkowskie — Konta mieszczące się w tych jednostkach organizacyjnych.

 Ponieważ konto zarządzające jest używane do administrowania środowiskiem, zaleca się, aby było bezpieczne. W tym celu, jeśli  tylko jest to możliwe, najlepiej jest delegować obowiązki poza kontem zarządzającym.

System bezpieczeństwa — jak chronić środowisko AWS?

Najlepsze praktyki, które zalecamy, jeśli chodzi o bezpieczeństwo środowiska, to:

1. Zatrudnianie proaktywnych mechanizmów bezpieczeństwa

Kontrola prewencyjna – Security preventative controls (SCP) -SCP pozwala na tworzenie i stosowanie niestandardowych barier ochronnych, mówimy o stosowaniu niestandardowych polityk, które dyktują działania, jakie mogą być podejmowane w ramach kont.

Najczęstsze przypadki użycia SCP

• Korzystanie z usług wspólnych dla każdego OU
• Ograniczenie użycia do określonych regionów AWS
• Wymaganie tagów przy tworzeniu zasobów
• Określanie dozwolonych rozmiarów instancji
• Zapobieganie działaniom użytkowników “root”,  
• Uniknięcie usuwania lub modyfikowania ról
• Zapobieganie wyłączaniu domyślnego szyfrowania

Jeśli chodzi o projektowanie polityki bezpieczeństwa i  kontroli usług, najlepiej  zacząć od najwyższego szczebla organizacji, zejść do bardziej szczegółowej polityki na niższych poziomach organizacji.

Na przykład możesz wdrożyć  EC2 na wszystkich  instancjach na poziomie organizacji, ale niekiedy lepiej ograniczyć go do mniejszych rozmiarów w ramach konkretnych jednostek OU, które nie wymagają ogromnych rozmiarów instancji EC2.

Więcej na temat wdrożenia EC2 przeczytasz w artykule

2. Centralna widoczność i kontrolowane dostępy

Jeśli chodzi o centralną widoczność, najlepiej wykorzystywać usługi bezpieczeństwa AWS, które istnieją w całej organizacji. W ramach bezpieczeństwa AWS zalecamy utrzymanie dwóch odrębnych kont.

•  Konto archiwum logów — to miejsce, w którym przechowywane są wszystkie logi z CloudTrail, (usługi AWS, która pomaga w przeprowadzaniu audytu operacyjnego, zarządzania i zapewniania zgodności konta) W ten sposób zespół bezpieczeństwa działający w ramach tego konta może mieć wgląd w całą organizację, jeśli chodzi o to, co się dzieje. 
• Konto narzędzi bezpieczeństwa — jest wiele usług bezpieczeństwa AWS (np. GuardDuty,Security Hub, IAM Access Analyzer itp), których administrowanie możesz delegować do tego konta narzędzi bezpieczeństwa. Wtedy Twój zespół ds. bezpieczeństwa może sprawdzić wszystkie ustalenia, które istnieją i podjąć stosowne działania.

Ustawienie bezpieczeństwa i innych usług najczęściej zawiera się w dwóch krokach:

• Skonfigurować usługę dla organizacji

• Zarejestrować delegowanego administratora do konta związanego z zarządzaniem

Powodem, dla którego zalecamy to zrobić, jest ograniczenia działań w ramach konta zarządzającego.

Zarządca budynku — czyli jak skalować w chmurze?

Zarządca budynku jest tym, który wie, co się dzieje, ponieważ żyje w tym budynku na co dzień i upewnia się, że jest on sprawny. Jakie to ma znaczenie w architekturze AWS?

1. Operacje to miejsce, gdzie sprawdzamy, czy nasz plan przetrwa na polu walki.
2. Wszystko, co ustawisz, jest testowane w warunkach kryzysowych.
3. Musisz mieć dane i narzędzia, aby zobaczyć, co się dzieje i gdzie są słabsze punkty.

Jedno narzędzie do zarządzania operacjami — jest to ważne, żeby mieć jedno narzędzie łączące wszystkie potrzebne funkcje w sobie, bez przełączania się pomiędzy różnymi zakładkami przeglądarki i loginami.

Buduj runbook’i i automatyzację — zdolność do wykrywania i natychmiastowej reakcji poprzez automatyzację jest krytyczna. Musisz poświęcić czas w swoich sprintach zespołowych, w procesie rozwoju, aby dodać automatyzację i kompilacje rutynowych procedur i operacji tak by można było szybko reagować bez negatywnego wpływu na reakcje klientów.

Pętla zwrotna — Istotne jest regularne otrzymywanie informacji zwrotnej, dzięki której można dostosować zachowanie oprogramowania na produkcji bez konieczności wdrażania nowego oprogramowania. Takie rzeczy trzeba planować z wyprzedzeniem, abyś mógł, na przykład, zwiększyć lub zmniejszyć liczbę wątków, lub liczbę jednoczesnych operacji w tle, które odbywają się w Twojej aplikacji. 

https://studiosoftware.com/blog/aws-elastic-load-balancing-why-is-it-important/

Najlepsze praktyki i kluczowe wnioski

Wykonując przegląd swojej architektury, najważniejsze jest zaplanowanie skutecznej struktury. Warto myśleć o kontach jak o cegłach i zbudować strukturę jednostek OU wokół tych cegieł. Następnie powinno się ograniczyć dostępy  i używać kontroli prewencyjnych, gdzie to możliwe.

Konieczne jest również wyposażenie zespołów w scentralizowane narzędzia, tak aby w przypadku ryzyka utraty bezpieczeństwa miały one pełną widoczność działań. Jeśli są operacje, powinieneś mieć pewność, że każda z nich działa sprawnie. Buduj runbooki i automatyzację, a także prewencyjne pętle zwrotne w obrębie organizacji i kont.

1. STARTUP — Jeśli jesteś małą firmą i masz jedno konto, stwórz organizację, zbuduj drugie konto, aby oddzielić je od siebie.
2. SCALE-UP – Jeśli jesteś organizacją z kilkoma kontami, ale jeszcze nie zagłębiłeś się w polityki kontroli usług, stwórz politykę, która zapobiega opuszczaniu organizacji przez konta i przetestuj ją na koncie testowym w organizacji.
3. ENTERPRISE – Jeśli jesteś dużą organizacją, masz kilka jednostek organizacyjnych, ale niekoniecznie masz ustalony mechanizm zarządzania kontami, zbuduj automatyzację.

Zarządzanie architekturą chmury AWS nie jest czymś, co dzieje się z dnia na dzień. Wymaga planowania, wcześniejszego podejmowania decyzji w celu ustalenia pewnych ram i myślenia konkretnych decyzjach w dłuższej perspektywie. 

Jeśli masz pytania dotyczące zarządzania strukturą AWS, skontaktuj się z naszymi ekspertami. Z pewnością pomogą Ci w zapewnieniu standardowych kontroli bezpieczeństwa i operacji dla twojego zespołu. Wszystko po to by Twoja struktura była przygotowana na przyszły wzrost.