Firma przeniosła obciążenia deweloperskie i produkcyjne do nowej organizacji AWS Organization i utworzyła oddzielne konta członkowskie dla środowisk deweloperskiego (dev) i produkcyjnego (prod). Skonsolidowane rozliczenia są powiązane z kontem zarządzającym. Architekt rozwiązań musi utworzyć użytkownika IAM na koncie zarządzającym, który będzie mógł zatrzymywać lub terminować zasoby na obu kontach członkowskich. Które podejście spełnia to wymaganie?

Prawidłowe podejście polega na utworzeniu użytkownika IAM na koncie zarządzającym i ról cross-account na każdym koncie członkowskim. Te role cross-account powinny mieć uprawnienia o najniższych możliwych przywilejach (zasada least privilege) do zatrzymywania lub terminowania zasobów. Polityki zaufania ról na kontach członkowskich powinny zezwalać użytkownikowi IAM z konta zarządzającego na przejmowanie tych ról. To jest standardowa i bezpieczna metoda zarządzania dostępem między kontami w AWS Organizations. Pierwsza opcja jest nieprawidłowa, ponieważ rola cross-account powinna być utworzona na kontach członkowskich, a nie na koncie zarządzającym, aby umożliwić dostęp do zasobów na tych kontach. Druga opcja jest nieprawidłowa, ponieważ tworzenie użytkowników IAM na każdym koncie członkowskim jest nieefektywne i niepotrzebne, gdy użytkownik na koncie zarządzającym może przejmować role. Trzecia opcja jest nieprawidłowa, ponieważ nie można dodać użytkownika IAM z jednego konta do grupy IAM na innym koncie; grupy IAM są specyficzne dla danego konta.