W poniższym tekście przyjrzymy się usłudze AWS Organizations. Zapoznasz się z wyzwaniami jakie niesie za sobą posiadanie jednego konta AWS oraz jak przy pomocy organizacji ułatwić sobie życie. Zobaczysz również jakie mechanizmy przygotował AWS, by ułatwić zarządzanie wieloma kontami.
AWS Organizations
Na samym początku przygody z AWS zapewne stworzyłeś lub stworzysz swoje indywidualne konto AWS, czyli zbiór użytkowników, polityk, ról oraz zasobów. Zasoby w ramach jednego konta mogą znajdować się w różnych regionach na świecie, wchodzić ze sobą w interakcję i tak dalej i tak dalej. Krótko mówiąc konto AWS otwiera przed nami świat chmury AWS.
Wszystko jest proste tak długo jak aplikacji na koncie mamy stosunkowo mało lub pracujemy tylko w kilka osób. Problem pojawia się, gdy zaczynamy pracę nad dużymi projektami w wieloosobowych zespołach oraz gdy współdzielimy konto na poziomie dużej organizacji. Ale o tym w dalszej części.
Jak łatwo zauważyć takie wykorzystanie chmury to nie jest rzadki przypadek, ale z pomocą przychodzi usługa organizacji. Organizacja grupuje jedno lub więcej kont AWS, które dodatkowo mogą być segregowane za pomocą Organization Units.
By uzyskać taki efekt, używając pierwszego konta musisz utworzyć Organizację oraz przypisać do niej kolejne konta. Możesz zrobić to na dwa sposoby, utworzyć nowe konto, lub zaprosić już istniejące. Proces jest bardzo łatwy, więc nie będę się nim zajmował, szczególnie że napisano już o tym wiele tutoriali.
Od tej chwili konto, którego użyliśmy do utworzenia organizacji staje się kontem master lub root i służy do zarządzania organizacją.
Tylko po co się tak męczyć?
Na pewno zadajesz sobie pytanie, jak to się ma do pracy i wdrażania dużych systemów chmurowych. Fajnie, że mogę utworzyć strukturę kont, tylko po co to wszystko?
Zastanówmy się jakie problemy możemy napotkać i to bardzo szybko, pracując na jednym koncie AWS.
Po pierwsze mieszamy zasoby różnego przeznaczenia. Na jednym koncie posiadamy aplikacje produkcyjne oraz testowe, a na dodatek wszelkiego rodzaju wersje deweloperskie oraz R&D. Dlaczego jest to problem? Nic nie chroni nas na przykład przed wrzuceniem testowej wersji aplikacji w miejsce produkcyjnej.
Kolejną rzeczą, tym razem mniej oczywistą są limity, które nakłada na konto AWS. Niektóre z nich można zmieniać wystawiając stosowną prośbę do działu supportu(Jak to zrobić można przeczytać tutaj). Inne natomiast są sztywne i niestety nie ma możliwości ich edycji. Rozłożenie zasobów na różne konta pozwala łatwiej zarządzać limitami oraz zredukować potrzebę ich powiększania.
Dwa powyższe potencjalne problemy posiadają synergię, niestety negatywną. Posiadając wszystkie środowiska na jednym koncie bardzo łatwo przekroczyć limity. Przykład? Testujemy nowy mechanizm wysyłający kampanie mailowe przy użyciu AWS Lambda. Jeśli wywołamy zbyt dużo Lambd, to dobijemy do limitu jednocześnie działających lambd na konto, a co za tym idzie zablokujemy również ich działające na produkcji.
Kolejnym wyzwanie jest zarządzanie dostępami. Nie zawsze chcemy, by wszyscy mieli dostęp do produkcyjnych zasobów. Wyobraźmy sobie nowego juniora dołączającego do zespołu, od razu musimy zaufać, że nic nie zepsuje i dać mu dostęp do całego konta, czyli również do produkcji… Oczywiście można kombinować z politykami i rolami, ale jest to bardzo pracochłonne.
Pozostaje jeszcze aspekt zarządzania kosztami. Przy jednym koncie trzeba nieźle się napracować, żeby odpowiedzieć na pytanie ile kosztuje produkcja, a ile środowisko testowe. Przy kilku kontach czarno na białym widać za co ile płacimy. Jednocześnie nie ma problemu z kilkoma fakturami, ponieważ organizacja oferuje wspólną fakturę dla wszystkich kont.
Idealna struktura organizacji
Poznałeś już kilka wyzwań związanych z posiadaniem jednego konta AWS. Zastanówmy się teraz jak możemy wykorzystać Organizacje, żeby rozwiązać wspomniane problemy.
Zanim zaczniemy zastanawiać się jak można zaprojektować strukturę organizacji, zwróć proszę uwagę na to, że nie dla każdej firmy wszystkie wymienione problemy są kluczowe, a czasem nawet w ogóle nie istnieją. Może ochrona dostępu do produkcji w małym startupie nie ma znaczenia, albo nie martwimy się dywersyfikacją kosztów, ponieważ mamy jedną aplikację. Tak samo jak pisząc kod, czy projektując infrastrukturę, zanim zabierzesz się do roboty, zastanów się co tak naprawdę chcesz osiągnąć i jakie problemy rozwiązać.
Projektując strukturę organizacji, pierwszą rzeczą, która przychodzi do głowy, to podział na środowiska.
Przyjrzyjmy się najprostszemu podziałowi na konta: Development, Staging i Production. Taka struktura pozwala rozwiązać większość z wspomnianych wcześniej niedogodnień. Nie mamy problemu z zarządzaniem dostępem do produkcji, nie nadpiszemy przez przypadek żadnej aplikacji produkcyjnej oraz w teorii nie mamy problemu z limitami.
Oczywiście wszystko zależy od skali. Jeżeli system urośnie i zrobi się bardzo skomplikowany, albo na jednym koncie będziemy mieli wiele aplikacji, to kilka problemów powraca:
- przede wszystkim limity
- zarządzanie dostępem – może nie każdy powinien mieć dostęp do wszystkich aplikacji
- zarządzanie kosztami – ciężko jednoznacznie określić, jaki jest koszt poszczególnych aplikacji
By rozwiązać ten problem możemy utworzyć kolejne konta AWS i wykorzystać Organization Unity, by połączyć konta tego samego typu.
Jak widać mechanizm jest bardzo elastyczny i możemy zarządzać kontami w taki sposób, by spełnić potrzeby biznesowe naszej organizacji.
To jednak nie koniec dobrych praktyk, które możemy zastosować w AWS Organizations. Co z fazą R&D? Otóż warto dodać konto Sandbox, na którym możliwe będą wszelakie testy nowych rozwiązań. Największym benefitem takiego rozwiązania jest łatwość w usuwaniu zbędnych zasobów, ponieważ możemy spokojnie cyklicznie co kilka dni, tygodni, czy miesięcy po prostu wyczyścić całe konto do zera. Zaoszczędzi to sporo czasu poświęcanego na wyłapywanie i usuwanie śmieci powstałych w fazie wdrażania nowych pomysłów.
Kolejnym rodzajem konta, które warto rozważyć podczas projektowania struktury jest konto Networks, służące do zarządzania sieciami. Takie podejście pozwala na scentralizowanie zarządzania sieciami i brak ingerencji w nie po stronie dewelopmentu.
Kilka plusów takiego podejścia:
- możliwość współdzielenia jednego VPC przez kilka kont – uproszczenie architektury sieciowej
- łatwiejsze zarządzanie zasobami sieciowymi i ich optymalizacja
- zmniejszenie kosztów poprzez reużywanie zasobów, takich jak np. NAT gateway
Centralne zarządzanie kontami
Poza wieloma korzyściami płynącymi z posiadania wielu kont, niestety dostajemy w pakiecie nowe wyzwania. Jednym z nich jest utrudnione zarządzanie. Z pomocą przychodzą polityki(AWS Service Control Policy oraz Tag Policy), które możemy nakładać na poszczególne konta lub jednostki organizacyjne.
AWS Service Control Policies
Kilka przykładów co możemy osiągnąć nakładając politykę na konto:
- wskazać jakie tagi muszą być przypięte do danych zasobów
- wymusić szyfrowanie wiaderek S3
- zastrzec dostęp do poszczególnych regionów
- zabronić usuwania VPC Flow Logów
- zabronić wstrzymania usługi CloudTrail
Jeśli dokładnie przyjrzałeś się przykładowi powyżej, to zapewne zauważyłeś, że jedną politykę można przypiąć do kilku kont lub jednostek organizacji.
Polityki mogą być przypinane na różnych poziomach, a co za tym idzie kolejne konta dziedziczą je po koncie głównym oraz kolejnych jednostkach organizacji.
Główne zasady rządzące dziedziczeniem polityk:
- politykę przypiętą do konta root dziedziczy każde konto w organizacji
- politykę przypiętą do Organization Unit dziedziczy każde jego dziecko
- polityka przypięta do konta dotyczy tylko i wyłącznie tego konta
Oczywiście to tylko bardzo uproszczony model dziedziczenia polityk. Bardzo dokładnie ten mechanizm opisano w dokumentacji AWS.
Tag Policies
Możemy również globalnie zarządzać tagami, przypinanymi do zasobów. Tag policy służy do tego, by nałożyć ramy na poszczególne tagi. Możemy na przykład zawęzić dopuszczalne wartości danego taga lub wymusić sposób zapisu jego nazwy z uwzględnieniem wielkości liter. Więcej możesz przeczytać w artykule o tagach.
Billing
Kolejnym potencjalnym wyzwaniem związanym z posiadaniem wielu kont AWS jest kwestia opłacania faktur. Jednak tak jak wspominałem już wcześniej usługa Organizacji pozwala ujednolicić fakturę i płacić jednorazowo za wszystkie konta w organizacji.
Dobre praktyki dla konta master/root
Konto root jest kluczowe w obrębie organizacji, dlatego warto przestrzegać kilku zasad:
- przeznaczone tylko do zarządzania organizacją
- nie powinno posiadać żadnych zasobów
- powinno być monitorowane przy użyciu usługi CloudTrail
- główny użytkownik kategorycznie musi być zabezpieczone przy pomocy podwójnego uwierzytelnienia
Kilka ciekawostek
AWS nie pobiera żadnych dodatkowych opłat za posiadanie większej ilości kont podpiętych pod organizację.
Darmowe limity dla różnych usług(free tier) dostępne są tylko raz w ramach całej organizacji.
Usługę Supportu wykupuje się dla każdego konta osobno, jednak jest ona zależna od wysokości rachunku, więc w teorii nawet posiadając support na każdym koncie, opłata powinna być praktycznie taka sama. Można ten model wykorzystać, by trochę zaoszczędzić, uruchamiając usługę supportu tylko na niektórych kontach, tam gdzie jest najbardziej potrzebna.
