A czy może trzy konta AWS to nie za dużo?
Jak to jest z tymi kontami AWS? Czy jedno konto AWS jest wystarczające? Czy warto od początku myśleć o separacji zasobów?
To przykładowe pytania, które warto sobie postawić w momencie gdy przygotowujemy odpalenie projektu w chmurze AWS.
Zdaje te pytania myśląc o niedużych, szybkim projektach, które odpalane są w chmurze AWS.
Duże organizacje klasy enterprise to zupełnie inna bajka, tam bardzo często od początku tworzonych jest wiele kont chmurowych, gdzie każde z nich ma inne przeznaczenie.
Dla przykładu w jednym z projektów, gdzie pomagam klientowi stworzyć bezpieczne środowisko chmurowe (w sektorze mocno regulowanym), mamy już ponad 5 kont AWS, a jeszcze nie odpaliliśmy żadnej aplikacji ?.
Ale temat dużych organizacji zostawmy na inny wpis. Dziś skupmy się na na prostej sytuacji. Jest projekt aplikacji X, która trzeba odpalić w chmurze.
Ile kont AWS warto założyć? Zanim do tego dojdziemy, postawmy inne pytanie:
Jakie możliwości daje konto AWS?
Na początek odpowiedzmy sobie na pytanie, jakie możliwości daje konto AWS?
Kiedy chcesz założyć konto, wchodzisz na stronę aws.amazon.com rejestrujesz się podajesz adres email, wprowadzasz wszystkie niezbędne dane i już po chwili lądujesz w konsoli AWS.
W ramach takiego pojedynczego konta AWS, każdy z użytkowników otrzymuję:
SEPARACJA ZASOBÓW W CHMURZE
Wszystko co zostanie skonfigurowane w ramach tego konta AWS, wszystko co zostanie w nim umieszczone (dane) jest widoczne tylko i wyłącznie DLA CIEBIE.
Każde konto AWS ma swoje tzw Account ID. Dla przykładu Twoje konto ma id np. 11111111, a moje konto id 22222222.
Wszystko co zostanie skonfigurowane na koncie 11111111 jest tylko i wyłącznie widoczne na nim, o ile nie nastąpi jakieś celowe udostępnienie zasobów innemu kontu, np. 22222222.
Dla przykładu, obraz wirtualnej maszyny (AMI) stworzony na jednym koncie AWS, zostanie udostępniony na inne konto.
LIMITY W CHMURZE
Każda platforma chmurowa nakłada na użytkowników limity. Zarówno limity miękkie, czyli takie, które można zmieniać, oraz limity sztywne lub maksymalne, których nie da się przekroczyć.
Limity nakładane są na dane konto chmurowe. W zależności od usługi per konto globalnie lub per region ale wciąż w ramach jednego konta AWS.
Mamy zatem do czynienia z limitami na zasoby w ramach usług. Dla przykładu limit ilości wirtualnych maszyn jakie możemy uruchomić.
Inne limity czy ograniczenia, to też na operacje API w ramach usługi. Chodzi tutaj np. o limity związane z możliwością jednoczesnych takich samych wywołań API dla danej usługi. Dla przykładu, jeśli ktoś kiedyś próbował w jednym regionie stworzyć naraz kilkanaście środowisk AWS Elastic Beanstalk, to wie o czym mówię ?
KOSZTY W CHMURZE
Rozliczanie kosztów za zużyte zasoby. Te również zliczane są dla wszystkich zasobów uruchomionych w ramach danego konta AWS.
Bardzo często jest to jeden z powodów dzielenia zasobów, na konta, aby mieć szybki i klarowny widok ile kosztuję np. środowisko developerskie patrząc na koszt konta developerskiego.
Dlaczego jedno konto AWS to za MAŁO?
Praca na jednym koncie AWS może okazać się ryzykowana z kilku powodów.
Po pierwsze, istnieje ryzyko, że gdy wykorzystanie chmury rośnie, coraz więcej osób i zespołów będzie miało dostęp do zasobów w chmurze.
Pojawia się tutaj zagrożenia chociażby przypadkowego nadpisania konfiguracji lub zasobów. Przykrym przypadkiem może być to, że ktoś skasuje zasoby bądź konfigurację (np. wirtualną maszynę).
Dodatkowo może pojawić się potrzeba kontroli i separacji uprawnień i dostępów do danych zasobów w chmurze.
Innym ryzykiem jest to, że jedna aplikacja będzie konsumować nadmiarową ilość zasobów, kosztem pozostałych.
Bardzo często różne Business Unity mają inne procesy, bądź wymagają innych standardów bezpieczeństwa lub większej izolacji zasobów.
Pozostaje też wspomniana wcześniej kwestia separacji billingów i rozliczania chmury. Tak jak wspomniałem poza mechanizmami tagowania zasobów, innym dość ciekawym elementem jest podziała zasobów na konta pod kątem centrum kosztowych.
Skoro już wiemy, że praca na jednym koncie może być ryzykowna, zatem…
To ile tych kont AWS?
Ostatnio podczas jednej z sesji Live z uczestnikami mojego kursu chmurowego mieliśmy właśnie dyskusje, o tym, ile kont AWS jest potrzebne na start?
Zakładamy tutaj nawet, niezbyt duży projekt, nowa aplikacja, lub migracja jakiegoś niezbyt skomplikowanego rozwiązania.
Pierwsza propozycja jaka padła, to TRZY konta AWS, jednak po dłuższej dyskusji doszliśmy do wniosku, że jednak CZTERY konta to niezbędne minimum.
Cztery konta AWS na start? Czy to przypadkiem nie przesada?
Być może przecierasz oczy ze zdumienia ?
Pozwól zatem, że przedstawię Ci propozycję jaką często stosuję z mojego punktu widzenia.
KONTO NR 1 – AWS Master Account
W momencie, kiedy zakładasz konto w chmurz AWS, podajesz tam różne dane jak np. email adres (to jest ten główny login tzw root), oraz co najważniejsze, kartę płatniczą.
To konto AWS traktujemy jako tzw. AWS Master Account, lub też AWS Organization Master.
Konto, jak sama nazwa wskazuje służy jedynie do zarządzania naszą organizacją, nie uruchamiamy na nim ŻADNYCH zasobów.
Konto to charakteryzuje się tym, że:
- służy do rozliczanie kosztów za zużyte zasoby na wszystkich przynależnych kontach (tzw. Consolidated Billing),
- dodatkowo agreguje i zlicza zużycie zasobów w celu stosowania zniżek typu Volume Discount,
- pracując w tym modelu możliwe jest też współdzielenie wykupionych rezerwacji na maszyny wirtualne (Reserved Instances),
- zapewnia konfigurację samej organizacji ( z wykorzystaniem usługi AWS Organizations)
- zapewnia kontrole uprawnień z wykorzystaniem Service Control Policies (SCP), które nakładamy na przynależne konta,
- posiada skonfigurowane jedynie te zasoby, które są niezbędne do zarządzania organizacja,
- dostęp do tego konta jest ograniczony jedynie do administratorów organizacji,
KONTO NR 2 – AWS Logging Account
W ramach platformy, dostępna jest usługa, która zbiera logi związane, że wszystkimi aktywnościami jakie dzieją się na każdym koncie AWS.
Usługa AWS CloudTrail, zapewnia coś w stylu audit logu, dzięki któremu można dowiedzieć się:
- kto, kiedy i skąd logował się na konto AWS,
- kto, kiedy uruchomił lub zmienił konfigurację jakiegoś konkretnego zasoby czy usługi,
- itp.
Sama usługa, przechowuje takie logi przez 90 dni, dlatego warto jest stworzyć bezpieczne miejsce (w tym wypadku bucket S3), gdzie wszystkie te logi będą składowane.
Dobrą praktyką jest aby stworzyć dedykowany bucket S3, ale dodatkowo dobrze jest aby znajdował się na odseparowanym koncie AWS.
W tym właśnie celu zakładamy konto, tzw. Logging Account, którego głównym i jedynym zadaniem jest bezpieczne przechowywanie logów z usługi CloudTrial, jak też innych, które wymagają bezpiecznego składowania.
Ograniczony dostęp do tego konta, plus odpowiednio nałożona polityka na bucket S3 pozwoli na bezpieczne przechowywani tych logów.
W ramach usługi AWS Organization możliwe jest „globalne” wymuszenie, aby na każdym koncie skonfigurować usługę CloudTrail, aby automatycznie odkładała logi na ten dedykowany bucket S3.
KONTO NR 3, 4? – Application Account
Teraz dopiero dochodzimy do konta AWS, na którym będziemy konfigurować usługi i zasoby dla naszej aplikacji.
Tutaj warto właśnie zastanowić się, czy to jedno konto będzie wystarczające? W sytuacji kiedy będziemy mieć kilka środowisk danej aplikacji (Dev, Test czy PROD).
Jeśli odpowiednia separacja na poziomie infrastruktury (serwery, sieć itp) jest dla nas OK, to wtedy rzeczywiście te TRZY konta to jest to minimum jakie warto założyć dla każdego projektu.
Jednak, jak to wyszło w trakcie wspomnianej już wcześniej dyskusji, mój dobry kolega Przemek Malak, przekonywał mnie i pozostałych uczestników, że jednak warto również separować środowiska na różne konta.
Może to się okazać przydatne szczególnie w sytuacji gdy z jakiegoś powodu nie chcemy, aby programiści mieli bezpośredni dostęp do środowiska produkcyjnego.
Innym powodem, może być fakt tego w jaki sposób zarządzamy wdrażaniem aplikacji i konfiguracji infrastruktury. O ile w fazie development, czy testu jest to konfiguracja ręczna czy częściowo zautomatyzowana, o tyle produkcja jest już w pełni automatyczne wdrażana.
Na koniec, może też chodzić o prostą separację kosztową. Jeśli istotnym jest aby dość łatwo oszacować koszty i odpowiedzieć np. na pytanie, „to ile w tym miesiącu kosztowało mnie środowisko produkcyjne?”
Idąc zatem tym tropem, dochodzimy do wniosku, że CZTERY konta to jest to minimum, które warto rozpatrywać w każdym projekcie.
Podsumowując
Warto jest dzielić zasoby na więcej kont AWS.
Dzięki temu zyskujemy nie tylko większą kontrolę nad tym kto do czego ma dostęp, ale również zabezpieczamy się prze różnego rodzaju błędami i pomyłkami, które czasem mogą skutkować dużymi konsekwencjami.
Stosując taką samą logikę jaka przyświeca ideologii Regionów AWS (im większa separacja tym mniejsze pole rażenia w przypadku problemów), dzieląc zasoby na konta zawsze zmniejszamy „zasięg” potencjalnego błędu, nieuprawnionego dostępu czy zwykłej pomyłki.
Samo konto AWS nic Cię nie kosztuje, czy masz ich jedno czy pięć nic to nie zmienia.
Używanie AWS Organizations to zarządzania kontami też nic Cię nie kosztuje.
Owszem kosztują Cię elementy poboczne, jak CloudTrail, ale nadal koszt ten względem korzyści jest znikomy.
Dlatego, szczerze i gorąco polecam, używanie min trzech a nawet czeterech kont AWS dla każdego, nawet małego projektu.
Dziel i zwyciężaj! Cheers ?
Artykuł oryginalnie ukazał się na blogu WELASTIC.PL
Zbuduje swoje bezpieczne środowisko AWS.
