Il 5 novembre 2026 AWS ha annunciato AWS Account Access Manager (AAM), un servizio che permette di assegnare in modo centralizzato ruoli IAM già esistenti agli utenti e ai gruppi di un’istanza organizzativa di IAM Identity Center. AWS dice che AAM può affiancare i permission set di Identity Center e non comporta costi aggiuntivi; l’abilitazione predefinita riguarda le regioni commerciali AWS, con esclusioni per le regioni commerciali a opt-in, GovCloud (US), Cina e le altre regioni non commerciali. L’annuncio di AWS descrive requisiti, assegnazioni e modalità di accesso.
Un entitlement collega identità, account e ruolo
Ogni assegnazione, chiamata entitlement, associa tre elementi: un utente o un gruppo di IAM Identity Center, un account AWS e l’ARN del ruolo IAM da assegnare. Il ruolo esiste già nell’account; AAM centralizza l’associazione con le identità dell’organizzazione. Le autorizzazioni restano definite nel ruolo e nelle relative policy.
Secondo AWS, AAM può essere usato da solo oppure insieme ai permission set di IAM Identity Center. In questo modo un’organizzazione può gestire centralmente l’accesso ai ruoli già presenti nei singoli account senza dover ricondurre ogni esigenza allo stesso modello di autorizzazioni.
Che cosa deve predisporre l’organizzazione
AWS indica una sequenza di prerequisiti per configurare AAM:
- L’organizzazione deve avere un’istanza di IAM Identity Center e gli utenti o i gruppi a cui assegnare l’accesso.
- Un amministratore deve abilitare AAM dall’account di gestione dell’organizzazione.
- I ruoli scelti negli account devono avere una policy di trust che autorizzi il principal di servizio
account-access.amazonaws.com. Nell’esempio AWS aggiunge condizioni sull’account sorgente e sull’ARN dell’applicazione AAM per limitare il rischio del confused deputy. - L’amministratore crea gli entitlement dalla console, dall’API o dalla CLI. La console non individua i ruoli IAM nei vari account: occorre conoscerne i nomi. È possibile assegnare un ruolo a un gruppo; se lo stesso ruolo va assegnato a più utenti singoli, AWS indica di creare le assegnazioni individualmente oppure automatizzarle tramite API, SDK o CLI.
Per le organizzazioni che filtrano il traffico AWS tramite firewall o gateway web sicuri, AWS chiede di autorizzare gli endpoint di AAM. Sono dual-stack: AWS non mette a disposizione endpoint solo IPv4. Se le policy successive usano tag di sessione propagati da attributi SAML, occorre consentire anche sts:TagSession; senza questa autorizzazione, l’assunzione del ruolo può riuscire, ma i tag di sessione non vengono propagati.
Accesso dal portale o dalla CLI
Gli utenti possono aprire i ruoli assegnati dal portale AAM oppure dal portale di accesso di IAM Identity Center, nella scheda Applications. Per il flusso da riga di comando descritto da AWS serve aws login con AWS CLI versione 2.36.0 o successiva; i comandi specifici di IAM Identity Center, come aws sso configure, non funzionano con le assegnazioni AAM. La durata della sessione segue il limite configurato per il ruolo IAM sottostante, fino a un massimo di 12 ore.
Le date distinguono tutorial, istanza e annuncio
AWS aveva pubblicato il proprio tutorial il 17 agosto 2026. Una schermata della console AWS indicava che una singola istanza era stata abilitata il 23 settembre. Il 14 ottobre Lumos ha scritto che la propria piattaforma leggeva le assegnazioni AAM nel grafo delle identità, per rendere visibili i percorsi di accesso di identità umane e macchina e segnalare problemi da esaminare. Nello stesso post Lumos descriveva il provisioning tramite AAM e il supporto a provider di identità oltre Microsoft Entra ID come sviluppi futuri. AWS ha pubblicato l’annuncio di AAM il 5 novembre.
Per assegnare un ruolo senza sorprese, controlla prima la sua policy di trust: l’associazione centrale non sostituisce l’autorizzazione prevista dal ruolo.
