Un'azienda vuole fornire agli utenti l'accesso alle risorse AWS. L'azienda ha 1.500 utenti e gestisce il loro accesso alle risorse on-premise tramite gruppi di utenti di Active Directory sulla rete aziendale. L'azienda non vuole che gli utenti mantengano un'altra identità per accedere alle risorse. Un architetto di soluzioni deve gestire l'accesso degli utenti alle risorse AWS preservando l'accesso alle risorse on-premise. Cosa dovrebbe fare l'architetto di soluzioni per soddisfare questi requisiti?

L'opzione corretta è configurare la federazione basata su SAML 2.0. Questo permette all'azienda di utilizzare le identità esistenti in Active Directory (AD) per autenticare gli utenti in AWS, eliminando la necessità di creare nuove credenziali. Gli utenti possono accedere alle risorse AWS con le stesse credenziali AD, e i ruoli AWS con policy appropriate vengono mappati ai gruppi AD, garantendo un controllo granulare degli accessi. Creare un utente IAM per ogni utente non è scalabile e richiede la gestione di identità separate. Amazon Cognito è più adatto per applicazioni web e mobili che richiedono l'autenticazione tramite provider di identità esterni, non per la federazione diretta con AD on-premise per l'accesso alla console AWS o alle API. Definire ruoli cross-account è per l'accesso tra account AWS diversi, non per la federazione di identità on-premise.