Migracja AWS Organizations to rzadko poruszany temat, który szybko staję sie wyzwaniem administracyjno-technicznym, gdy trzeba zmienić konto zarządzające, ponieważ AWS Organizations nie pozwala na zmianę raz wybranego roota organizacji. W rezultacie konieczne jest stworzenie nowej organizacji i ręczne przenoszenie wszystkich kont członkowskich w celu dokonania migracji.
W moim wypadku poza samą migracją kont AWS pod nowe konto zarządcze w nowej organizacji zmieniłem też sposób uwierzytelniania. Z użytkowników IAM przeszedłem na AWS Identity Center, czyli SSO. W tym artykule dzielę się własnymi doświadczeniami z tego procesu, trudnościami, które napotkałem, oraz wnioskami, które mogą być pomocne dla innych.
Dlaczego musiałem migrować?
Moja AWS Organization jest moją prywatną organizacją, której używam do nauki i realizacji małych projektów. Pierwsze konto założyłem w roku 2016 z zamiarem nauki serverless. W miarę rozwoju moich potrzeb dodawałem kolejne konta. Ostatecznie utworzyłem AWS Organization. Z powodu braku doświadczenia na początku, użyłem mojego pierwszego konta jako konta zarządzającego. Na tym koncie znajdowały się już wtedy różne zasoby, głównie projekty serverlessowe. Z czasem dowiedziałem się, że taki sposób zarządzania zasobami łamie najlepsze praktyki i wymaga poprawy, ale nie mogłem już wtedy wprowadzić żadnych zmian. Przez długi czas funkcjonowałem w takiej konfiguracji - w końcu była to moja prywatna organizacja i nie musiałem przechodzić żadnych audytów 😉
Po latach pojawiło się AWS Identity Center (dawna nazwa SSO), które chciałem włączyć, ale nie miałem zamiaru tego robić w starej, nieuporządkowanej organizacji. Wiedziałem, że gdy to zrobię, jeszcze trudniej będzie mi dojść do poziomu zgodności z najlepszymi praktykami. Dlatego jego włącznie odwlekałem w czasie.
Sytuacja zmieniła się w 2024 roku, gdy pojawiło się AWS Q Developer Pro, które chciałem włączyć, aby mi pomagało w programowaniu. Wymaga ono wdrożonego AWS Identity Center, co pchnęło mnie do działania. Chciałem wdrożyć to rozwiązanie, ale nie w starej, nieuporządkowanej organizacji. Wiedziałem, że implementacja Identity Center w obecnej strukturze jeszcze bardziej oddali mnie od zgodności z najlepszymi praktykami AWS.
Trzecim powodem, opartym jedynie na domysłach i pewnych poszlakach, było to, że stare konta AWS różnią się od tych stworzonych niedawno. Nie znam szczegółów, ale raczej lepiej mieć nowe konto jako konto zarządcze organizacji. Pamiętam, że gdy wreszcie po latach AWS włączył możliwość ustawiania wielu kluczy sprzętowych MFA dla użytkowników IAM, to moje stare konto AWS z 2016 roku uzyskało tę funkcjonalność dopiero kilka tygodni po ogłoszeniu jej przez AWS, jego wiek był podany przez Support jako przyczyna opóźnienia.
Jak przebiegał proces migracji?
Migracja w moim przypadku skupiała się wyłącznie na przeniesieniu kont członkowskich do nowej organizacji, bez przenoszenia zasobów między kontami. Oto główne kroki:
Przygotowanie nowej organizacji – Rozpocząłem od utworzenia nowej AWS Organization, zakładając świeże konto AWS, które miało pełnić rolę konta zarządzającego.
Przenoszenie kont członkowskich – Następnie rozpoczął się najbardziej czasochłonny etap - przenoszenie kont członkowskich. Każde konto wymagało odpięcia ze starej organizacji, co wiązało się z usunięciem polityk SCP blokujących możliwość opuszczenia organizacji. Dla kont utworzonych bezpośrednio w starej organizacji musiałem skonfigurować hasło root, zabezpieczenie MFA oraz - co szczególnie istotne - metodę płatności. Ten ostatni element był kluczowy, ponieważ w przypadku consolidated billing metoda płatności jest zwykle konfigurowana tylko na koncie zarządzającym.
Przyjęcie zaproszenia do nowej organizacji – Po odpięciu konta ze starej organizacji stawało się ono niezależnym kontem. W nowej organizacji wysyłałem zaproszenie do takiego konta, które musiało być zaakceptowane z poziomu konta root. Dopiero wtedy konto dołączało do nowej organizacji.
Źródło: AWS.
Wyzwania, na które napotkałem
- Kwestie związane z płatnościami – Główne trudności polegały na konieczności ustawienia metod płatności na kontach, które wcześniej były tworzone w ramach starej organizacji bez konieczności definiowania płatności. Musiałem to zrobić ręcznie dla każdego konta.
- Brak automatyzacji – Drugim istotnym wyzwaniem był brak automatyzacji ze strony AWS. Platforma nie oferuje narzędzi do automatycznego przenoszenia całych, bądź części organizacji, co oznaczało konieczność ręcznego wykonania wszystkich kroków. Na szczęście w moim przypadku dotyczyło to tylko siedmiu kont, więc zadanie pozostawało wykonalne w rozsądnym czasie.
- Polityki SCP i IAM – Istniejące polityki SCP przeniosłem metodą copy-paste (definicja JSONa), a konfiguracje IAM pozostały na kontach bez zmian.
AWS Identity Center - nowe otwarcie
Wdrożenie AWS Identity Center w nowej organizacji stanowiło znaczącą zmianę w podejściu do zarządzania dostępem i bezpieczeństwem. Więcej na ten temat znajdziesz w poprzednim artykule Uproszczona konfiguracja profili SSO w AWS CLI za pomocą sesji SSO. Dodatkowo, w przeciwieństwie do starej organizacji, gdzie zasoby były deployowane bezpośrednio na koncie zarządzającym, teraz postanowiłem ściśle przestrzegać najlepszych praktyk AWS i pozostawić to konto pustym.
Co ciekawe, samo Identity Center zgodnie z zaleceniami AWS konfiguruje się na koncie zarządzającym, więc nie pozostaje ono całkowicie puste. Jest to jednak jedyny wyjątek od reguły nieumieszczania zasobów na koncie zarządzającym.
Rekomendacje
Jeśli potrzebujesz pomocy w konfiguracji swojej Organizacji AWS lub Identity Center to polecam znakomite filmiki instruktażowe Łukasza Dorosza, które pomogły mi szybko oswoić się z tematem. Zresztą, o ile pamięć mnie nie myli, to Łukasz już w 2023 roku doradzał mi przejście na Identity Center. Dziękuję.
Podsumowanie
Migracja AWS Organizations to złożone zadanie, które może wymagać wielu ręcznych kroków, ale jest wykonalne przy odpowiednim podejściu. W moim przypadku decyzja o stworzeniu nowej organizacji i ręcznym przeniesieniu kont była najlepszym rozwiązaniem, które pozwoliło na uporządkowanie zasobów i wdrożenie lepszych praktyk bezpieczeństwa. A docelowo odblokowała mi możliwość używania AWS Q Developer Pro.
Dla osób rozważających podobną migrację, najważniejsza rada to dokładne zaplanowanie procesu i przygotowanie wszystkich niezbędnych elementów, szczególnie w zakresie płatności i dostępów do kont root wszystkich przenoszonych kont AWS. Warto także pamiętać, że chociaż proces jest czasochłonny, korzyści z uporządkowanej struktury i zwiększonego bezpieczeństwa znacząco przewyższają włożony wysiłek.
Jeśli dopiero rozpoczynasz swoją przygodę z AWS Organizations, pamiętaj o utworzeniu dedykowanego konta zarządzającego bez zasobów produkcyjnych. Unikniesz dzięki temu konieczności migracji w przyszłości i od początku będziesz zgodny z najlepszymi praktykami AWS.
Mam nadzieję, że moja historia okaże się pomocna dla osób, które stoją przed podobnym wyzwaniem, a tym z Was, którzy jeszcze nie mają własnej AWS Organization pozwoli uniknąć moich błędów w czasie jej tworzenia.
