Eine Organisation nutzt AWS Organizations mit separaten Konten für Finanzen und Marketing. Die Datenverarbeitungs-App des Finanzteams (im Finanzkonto) verwendet Lambda und speichert vertrauliche Daten in einer DynamoDB-Tabelle. Das Marketingteam (in einem anderen Konto) darf nur auf bestimmte Attribute dieser DynamoDB-Tabelle zugreifen. Wie sollte ein Solutions Architect dem Marketingteam den erforderlichen eingeschränkten Zugriff ermöglichen?

Die korrekte Lösung ist die Erstellung einer IAM-Rolle im Finanzkonto mit detaillierten Berechtigungen und einem Vertrauensverhältnis zum Marketingkonto. Das Marketingkonto kann dann eine Rolle erstellen, die diese Rolle im Finanzkonto übernimmt, um auf die spezifischen DynamoDB-Attribute zuzugreifen. Dies ist der Standardweg für den sicheren, kontoübergreifenden Zugriff mit detaillierter Kontrolle. Eine SCP (Service Control Policy) ist ungeeignet, da sie Berechtigungen nur einschränken, nicht gewähren kann. Eine ressourcenbasierte Richtlinie allein reicht nicht aus, da das Marketingkonto immer noch eine Rolle benötigt, um diese Richtlinie nutzen zu können. Eine Berechtigungsgrenze (permissions boundary) schränkt die maximalen Berechtigungen einer Rolle ein, gewährt aber selbst keine Berechtigungen und ist hier nicht der primäre Mechanismus für den kontoübergreifenden Zugriff.