Konwertujesz istniejące, efemeryczne środowisko AWS inne niż produkcyjne na szablon CloudFormation. Środowisko to obejmuje instancję EC2, której profil instancji umożliwia przyjęcie roli na koncie nadrzędnym. Utworzyłeś ponownie rolę w stosie CloudFormation (używając tej samej nazwy roli) i wdrożyłeś stos na koncie podrzędnym. Następnie instancja EC2 nie może przyjąć roli na koncie nadrzędnym z powodu niewystarczających uprawnień. Co należy zrobić, aby rozwiązać ten problem?

Problem wynika z tego, że polityka zaufania roli na koncie nadrzędnym prawdopodobnie odwołuje się do konkretnego ARN roli instancji EC2 na koncie podrzędnym. Ponowne utworzenie roli za pomocą CloudFormation, nawet z tą samą nazwą, zmienia jej ARN. Instancja EC2 próbuje przyjąć rolę na koncie nadrzędnym, ale polityka zaufania tej roli nadal oczekuje starego ARN, co prowadzi do błędu odmowy dostępu. Zaktualizowanie polityki zaufania na koncie nadrzędnym, aby odzwierciedlała nowy ARN roli na koncie podrzędnym, rozwiąże ten problem. Inne opcje są nieprawidłowe, ponieważ modyfikacja polityki zaufania w celu zezwolenia na sts:AssumeRole dla głównego podmiotu konta podrzędnego jest zbyt szeroka i nie jest najlepszą praktyką. Możliwości CloudFormation (CAPABILITYIAM, CAPABILITYNAMEDIAM) dotyczą uprawnień do tworzenia zasobów IAM w stosie, a nie rozwiązywania problemów z politykami zaufania między kontami.