Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Multi-Region replica per pool di utenti
Con la replica multiregionale (MRR), è possibile creare un pool di utenti di replica aggiuntivo Regione AWS per fornire funzionalità di continuità aziendale e disaster recovery per l'infrastruttura di autenticazione. Con MRR, gli utenti registrati possono continuare ad autenticarsi con le applicazioni anche quando si perde la connettività alle risorse in una regione, garantendo che le applicazioni rimangano disponibili.
Quando configuri MRR, Amazon Cognito crea pool di utenti separati con un ID pool di utenti condiviso. Ogni pool di utenti di replica ospita servizi di autenticazione per una directory utente condivisa. Il pool di utenti primario funge da fonte autorevole per la configurazione amministrativa e le operazioni di scrittura come la reimpostazione delle password e la registrazione degli utenti. I pool di utenti secondari non possono creare utenti. Ereditano la maggior parte delle impostazioni dal pool di utenti primario e, in uno stato di failover, possono gestire operazioni di autenticazione come l'accesso degli utenti e la generazione di token.
Importante
Multi-Region la replica non è disponibile per tutti i pool di utenti in questo momento. Multi-Region la replica richiede la moderna infrastruttura Amazon Cognito con funzionalità e scalabilità avanzate. Alcuni pool di utenti si trovano ancora su un'infrastruttura precedente e verranno aggiornati AWS alla nuova infrastruttura, che sbloccherà questa funzionalità. Nella console Amazon Cognito, i pool di utenti idonei visualizzano opzioni di configurazione di replica in più regioni e i pool non idonei visualizzano messaggi di eccezione. Per ulteriori informazioni, consulta Amazon Cognito che sblocca funzionalità avanzate con un'infrastruttura di nuova generazione nel Security Blog.
Cose da sapere sulla replica in più regioni
-
Multi-Region la replica ha costi aggiuntivi separati e richiede che il pool di utenti sia iscritto al piano di funzionalità Essentials o Plus. Piani di funzionalità del pool di utenti Non è possibile abilitare MRR sui pool di utenti con il piano di funzionalità Lite.
-
AWS KMS Prima di abilitare la replica, è necessario configurare il pool di utenti con una chiave gestita da più regioni. La chiave deve essere disponibile in tutti coloro Regioni AWS che dispongono di repliche di pool di utenti. Per ulteriori informazioni, consulta Crittografia dei dati.
-
Per una convalida coerente dei token tra le regioni, ti consigliamo di configurare il tuo pool di utenti con un emittente aggiornato. Per ulteriori informazioni, consulta I pool di utenti di Amazon Cognito fungono da emittente OIDC.
-
I nuovi pool di utenti secondari iniziano nello
INACTIVEstato. Rivedi e configura le impostazioni regionali prima di attivare il pool di utenti per l'uso in produzione. -
Le configurazioni regionali possono differire tra le repliche. È possibile configurare le seguenti impostazioni in modo indipendente nelle repliche. Tutte le altre impostazioni vengono impostate nel pool di utenti primario e sincronizzate automaticamente con quello secondario.
-
Configurazione e-mail
-
Configurazione e-mail per le notifiche di protezione dalle minacce
-
Configurazione SMS
-
Trigger Lambda
-
Tag
-
Configurazione dell'esportazione dei log
-
AWS WAF ACL web
-
-
La replica dei dati tra le regioni potrebbe introdurre brevi ritardi. Il pool di utenti primario sincronizza le impostazioni e gli aggiornamenti della directory utente con quello secondario e questo processo è infine coerente.
Limitazioni della replica in più regioni
-
Non è possibile generare nuovi utenti in pool di utenti secondari, tramite registrazione o creazione da amministratore. Gli utenti federati possono accedere a un pool di utenti secondario nello stato di failover solo se hanno precedentemente effettuato l'accesso al pool di utenti principale.
-
Gli utenti non possono reimpostare le proprie password o modificare i propri profili nei pool di utenti secondari. In uno stato di failover, disabilita queste operazioni nell'interfaccia utente e rendile disponibili dopo che il controllo dello stato di integrità ripristina l'accesso al pool di utenti principale.
-
È possibile avere al massimo una replica secondaria in una regione aggiuntiva per directory utente. Qualsiasi pool di utenti idonei può avere una replica secondaria.
-
L'MFA TOTP non è supportato nelle repliche secondarie. Gli utenti con TOTP MFA configurato devono autenticarsi quando il pool di utenti nella regione primaria soddisfa le richieste.
-
Il numero di tentativi di autenticazione basati su password prima del blocco non è sincronizzato tra le regioni. Ogni replica mantiene il proprio numero di tentativi di autenticazione non riusciti.
Configurazione della replica in più regioni
Prima di poter abilitare la replica in più regioni, assicurati che il tuo pool di utenti soddisfi i prerequisiti: piano di funzionalità Essentials o Plus e chiave KMS gestita dal cliente in più regioni.
Operazioni API supportate nelle regioni secondarie
Amazon Cognito supporta un sottoinsieme di operazioni API in regioni secondarie. Le operazioni disponibili dipendono dallo stato della replica. Le repliche in INACTIVE stato supportano un set limitato di operazioni di lettura e configurazione. Le repliche in ACTIVE stato supportano ulteriori operazioni di autenticazione e gestione delle sessioni. Le operazioni non elencate qui sono disponibili solo nella regione principale.
Operazioni per le regioni secondarie INATTIVE
I pool di utenti di replica nelle regioni secondarie in INACTIVE stato consentono le seguenti operazioni sull'API Amazon Cognito.
Operazioni aggiuntive per le regioni secondarie ACTIVE
I pool di utenti di replica nelle regioni secondarie in ACTIVE stato consentono tutte le operazioni precedenti, oltre alle seguenti operazioni di autenticazione e gestione delle sessioni.
Failover nei pool di utenti con più regioni
Con i pool di utenti multiregionali, puoi eseguire il failover dell'accesso gestito, dell'accesso federato e delle chiamate API dirette tra due. Regioni AWS Il failover di accesso gestito e federativo è disponibile con un dominio personalizzato o un dominio con prefisso (Cognito) configurato con il pool di utenti. Non è possibile configurare un dominio personalizzato diverso con pool di utenti di replica.
Failover per accesso gestito, federazione e autorizzazione da macchina a macchina
Il failover è disponibile quando il pool di utenti principali ha un dominio personalizzato o un dominio con prefisso. Utilizzo del dominio con prefisso Amazon Cognito per l'accesso gestito Il dominio del pool di utenti serve le risorse OAuth 2.0, inclusi gli endpoint di autorizzazione e token, e gestisce le risposte IdP di provider federativi di terze parti, tra cui OIDC, SAML e provider social.
Per abilitare il failover, imposta un controllo dello stato in Route 53 e imposta il campo sul tuo dominio. Routing Sei tu a determinare cosa scatena uno stato sano o malsano. Quando il controllo dello stato non è integro, Amazon Cognito fornisce pagine di accesso gestite e operazioni di autenticazione dal pool di utenti della replica secondaria. Quando il controllo dello stato di integrità entra in uno stato di integrità, Amazon Cognito inizia a indirizzare il traffico verso la replica primaria.
Il record DNS per il tuo dominio personalizzato può utilizzare Route 53 o qualsiasi provider DNS di terze parti. Assicurati di avere un record CNAME valido nel tuo provider DNS che punti all'alias di destinazione, che è una distribuzione. CloudFront Puoi trovare l'alias target nella pagina Dominio della console Amazon Cognito.
Per aggiornare l'ID del controllo sanitario nella console
-
Accedi alla console Amazon Cognito
. -
Scegli Pool di utenti, quindi scegli il tuo pool di utenti.
-
Scegli Dominio in Branding dal menu.
-
Nella sezione Dominio personalizzato, scegli l'opzione di modifica e seleziona Modifica failover multiregionale.
-
Attiva l'opzione Abilita il failover multiregionale.
-
Seleziona il tuo ID di controllo sanitario di Route 53 tra i controlli sanitari disponibili.
-
Scegli Save changes (Salva modifiche).
Failover per API e SDK di Amazon Cognito
Se utilizzi le API o gli SDK di Amazon Cognito, non viene utilizzato un dominio personalizzato e l'applicazione è responsabile del routing del traffico verso l'endpoint regionale del servizio Amazon Cognito per gestire l'autenticazione e altre chiamate API.
Se disponi solo di un frontend applicativo che utilizza un client pubblico, ad esempio un'applicazione a pagina singola (SPA) o un'app mobile, l'applicazione deve essere dinamica per indirizzare le chiamate API di conseguenza. Prendi in considerazione un backend di applicazioni serverless per determinare da quale regione deve iniziare l'autenticazione con Amazon Cognito.
Se hai un'applicazione con un backend, qui puoi determinare la logica per determinare con quale pool di utenti autenticarti.
Se utilizzi sia endpoint di accesso gestiti che API, utilizza lo stesso controllo di integrità di Route 53 per determinare a quale regione l'applicazione indirizza le chiamate API Amazon Cognito.
