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 di utenti 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 multiregionale e i pool non idonei visualizzano messaggi di eccezione. Per ulteriori informazioni, consulta Amazon Cognito sblocca funzionalità avanzate con un'infrastruttura di nuova generazione
Cose da sapere sulla replica in più regioni
-
Multi-Region la replica ha costi aggiuntivi separati e richiede che il pool di utenti disponga del piano di funzionalità Essentials o Plus. Non è possibile abilitare MRR sui pool di utenti con il piano di funzionalità Lite.
-
È necessario configurare il pool di utenti con una chiave multiregionale gestita dal cliente AWS KMS prima di abilitare la replica. 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.
-
Il pool di utenti deve utilizzare un emittente OIDC multiregionale per garantire una convalida coerente dei token in tutte le regioni. Per ulteriori informazioni, consulta Pool di utenti di Amazon Cognito come emittente OIDC.
-
I nuovi pool di utenti secondari iniziano nello stato.
INACTIVERivedi 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 sono impostate nel pool di utenti primario e sincronizzate automaticamente con quello secondario.
-
Configurazione della posta elettronica
-
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 regioni potrebbe introdurre brevi ritardi. Il pool di utenti primario sincronizza le impostazioni e gli aggiornamenti delle directory utente con quello secondario e questo processo alla fine è coerente.
Limitazioni della replica in più regioni
-
Non è possibile generare nuovi utenti in pool di utenti secondari, né tramite registrazione né tramite creazione da parte dell'amministratore. I nuovi 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 primario.
-
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 di integrità ha ripristinato l'accesso al pool di utenti primario.
-
È possibile avere al massimo una replica secondaria in una regione aggiuntiva per directory utente. Qualsiasi pool di utenti può avere una replica secondaria.
-
L'MFA TOTP non è supportata nelle repliche secondarie. Gli utenti con TOTP MFA configurato devono autenticarsi quando il pool di utenti nella regione principale sta gestendo 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 abilitare la replica in più regioni, assicurati che il pool di utenti soddisfi i prerequisiti: piano di funzionalità Essentials o Plus, chiave KMS gestita dal cliente in più regioni e configurazione dell'emittente OIDC multiregionale.
Failover in pool di utenti multiregionali
Con i pool di utenti multiregionali, è possibile eseguire il failover di accesso gestito, accesso federato e chiamate API dirette tra due. Regioni AWS L'accesso e la federazione gestiti richiedono un dominio personalizzato configurato con il pool di utenti principale. 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 principale ha un dominio personalizzato. Quando entrambi i pool di utenti hanno un dominio con prefisso, è possibile testare manualmente le operazioni sulla replica secondaria accedendo direttamente al dominio con prefisso secondario. I domini personalizzati possono essere serviti dalla replica e dalla regione principali o aggiuntive.
Il tuo pool di utenti richiede un dominio personalizzato perché quel dominio 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 configurare il failover, configura un controllo dello stato in Route 53. Siete voi a determinare cosa innesca uno stato sano o malsano. Il controllo dello stato di salute non è direttamente collegato al record DNS CNAME, ma controlla se il traffico viene indirizzato al pool di utenti principale o al pool di utenti di replica.
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 la destinazione dell'alias nella pagina Dominio della console Amazon Cognito.
Quando il controllo dello stato non è integro, Amazon Cognito fornisce pagine di accesso gestite e operazioni di autenticazione per il dominio personalizzato dal pool di utenti di replica secondaria. Quando il controllo di integrità entra in uno stato integro, Amazon Cognito inizia a reindirizzare il traffico verso la replica principale.
Ogni pool di utenti ha il proprio dominio di prefisso, così come questi. Region-isolated Puoi comunque chiamare direttamente questi endpoint per gestire l'autenticazione. Tuttavia, se la federazione è configurata con terze parti IdPs, devono esserci due configurazioni dell'applicazione per ogni endpoint con prefisso. Come best practice, utilizza un dominio personalizzato per garantire che Amazon Cognito gestisca automaticamente il routing da e verso l'accesso gestito in base allo stato del controllo di integrità della Route 53.
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 sotto Branding dal menu.
-
Nella sezione Dominio personalizzato, scegli l'opzione di modifica e seleziona Modifica failover multiregionale.
-
Attiva l'opzione Abilita failover multiregionale.
-
Seleziona l'ID del tuo test sanitario 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'applicazione frontend che utilizza un client pubblico, ad esempio un'applicazione a pagina singola (SPA) o un'app mobile, l'applicazione deve essere dinamica per instradare le chiamate API di conseguenza. Prendi in considerazione un backend applicativo serverless per determinare da quale regione iniziare l'autenticazione con Amazon Cognito.
Se disponi di un'applicazione con un backend, puoi determinare qui la logica per determinare con quale pool di utenti eseguire l'autenticazione.
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 di Amazon Cognito.
