AWS ogłosiło Account Access Manager (AAM) 5 listopada 2026 r. Usługa pozwala centralnie przypisywać istniejące role IAM w poszczególnych kontach AWS użytkownikom i grupom z organizacyjnej instancji IAM Identity Center. Jedno przypisanie łączy tożsamość, konto i rolę, a AAM może działać obok permission sets. AWS opisuje usługę i jej konfigurację.
Zanim przypiszesz użytkownika lub grupę, przygotuj rolę IAM tak, by jej polityka zaufania dopuszczała Account Access Manager.
Jedno przypisanie łączy tożsamość, konto i rolę
W IAM rola określa uprawnienia dostępne w koncie AWS. AAM pozwala przypisać istniejącą rolę konkretnemu użytkownikowi lub grupie z IAM Identity Center. AWS nazywa takie przypisanie uprawnieniem: składa się ono z identyfikatora użytkownika albo grupy, identyfikatora konta AWS oraz ARN roli IAM.
Takie podejście przydaje się organizacjom, które chcą zachować własne role skonfigurowane w różnych kontach, a zarządzać przypisaniami centralnie. AWS podaje, że AAM można stosować samodzielnie albo równolegle z permission sets IAM Identity Center. Administratorzy mogą tworzyć przypisania w konsoli, przez API lub CLI; w konsoli da się przypisać rolę grupie. Przy ręcznym przypisywaniu tej samej roli wielu osobom trzeba utworzyć osobne przypisania dla poszczególnych użytkowników.
Co administrator musi przygotować
Konfiguracja zaczyna się od organizacyjnej instancji IAM Identity Center z użytkownikami lub grupami. Następnie administrator włącza AAM z konta zarządzającego organizacją. Role, które mają być przypisywane, muszą mieć politykę zaufania pozwalającą na dostęp podmiotowi usługi account-access.amazonaws.com. Przykład AWS ogranicza ją również warunkami dotyczącymi konta źródłowego i ARN aplikacji AAM.
Konsola AAM nie wyszukuje ról IAM we wszystkich kontach, więc administrator musi znać ich nazwy. Kwalifikują się tylko role, których polityka zaufania zezwala na użycie AAM. Jeżeli polityki dalszego dostępu korzystają z tagów sesji przekazywanych z oświadczeń SAML dostawcy tożsamości, AWS wskazuje także uprawnienie sts:TagSession; bez niego sesja roli może nadal powstać, ale tagi sesji nie zostaną przekazane.
Organizacje filtrujące ruch AWS przez zaporę lub bezpieczną bramę internetową muszą dopuścić wymagane punkty końcowe AAM. AWS podaje, że są one dwustackowe i nie oferuje punktów końcowych działających wyłącznie przez IPv4. Szczegóły wymagań i ustawień AWS opisuje w swoim ogłoszeniu o Account Access Manager.
Samouczek AWS opublikowany 17 sierpnia 2026 r. pokazuje włączanie usługi, zmianę polityki zaufania oraz tworzenie przypisań dla użytkowników i grup.
Dostęp przez portal lub AWS CLI
Użytkownicy mogą otwierać przypisane konta i role w portalu AAM albo w portalu dostępu IAM Identity Center, na karcie Applications. W opisanym przez AWS przepływie CLI logowanie odbywa się poleceniem aws login; wymagany jest AWS CLI w wersji 2.36.0 lub nowszej. Polecenia IAM Identity Center, takie jak aws sso configure, nie obsługują przypisań AAM.
Czas sesji zależy od maksymalnego czasu skonfigurowanego dla danej roli IAM i może wynosić najwyżej 12 godzin. AWS deklaruje, że AAM nie wiąże się z dodatkową opłatą. Usługa jest domyślnie włączona w regionach Commercial z wyjątkami obejmującymi regiony wymagające opt-in, GovCloud (US), Chiny i pozostałe regiony niekomercyjne.
Wcześniejszy samouczek, data jednej instancji i integracja Lumos
AWS opublikowało samouczek 17 sierpnia 2026 r. Zrzut konsoli zamieszczony w listopadowym ogłoszeniu pokazuje jedną instancję AAM z datą włączenia 23 września. Z kolei 14 października Lumos opisało własną integrację: jego platforma odczytywała przypisania AAM do grafu tożsamości ludzi i maszyn oraz oznaczała problemy do przeglądu. W tym samym wpisie provisioning przez AAM i obsługę dostawców tożsamości innych niż Microsoft Entra ID przedstawiono jako plany na przyszłość. Lumos opisało zakres swojej integracji. AWS ogłosiło Account Access Manager 5 listopada 2026 r.
