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à.
Best practice per le applicazioni multi-tenant
I pool di utenti di Amazon Cognito operano con applicazioni multi-tenant che generano un volume di richieste che deve rimanere entro le quote di Amazon Cognito. Per aumentare questa capacità man mano che la tua base di clienti cresce, puoi acquistare quote di capacità aggiuntive.
Nota
Le quote di Amazon Cognito vengono applicate singolarmente. Account AWS Regione AWS Queste quote vengono condivise tra tutti i tenant dell'applicazione. Controlla le quote del servizio Amazon Cognito e assicurati che la quota soddisfi il volume previsto e il numero previsto di tenant nella tua applicazione.
Questa sezione descrive i metodi che puoi implementare per separare i tenant tra le risorse di Amazon Cognito all'interno della stessa regione e. Account AWS Puoi anche suddividere i tuoi inquilini in più di una Account AWS regione e assegnare a ciascuno di loro la propria quota. Altri vantaggi della multi-tenancy multiregionale includono il massimo livello di isolamento possibile, il tempo di transito di rete più breve per gli utenti distribuiti a livello globale e l'aderenza ai modelli di distribuzione esistenti nell'organizzazione.
La multi-tenancy a regione singola può avere vantaggi anche per i clienti e gli amministratori.
L'elenco seguente illustra alcuni dei vantaggi della multi-tenancy con risorse condivise.
Vantaggi della multi-tenancy
- Elenco utenti comune
-
La multi-tenancy supporta modelli in cui i clienti dispongono di account in più di un'applicazione. È possibile collegare le identità di provider terzi in un unico profilo di pool di utenti coerente. Nei casi in cui i profili utente sono unici per il relativo tenant, qualsiasi strategia multi-tenancy con un unico pool di utenti prevede un unico punto di accesso per l'amministrazione degli utenti.
- Sicurezza comune
-
In un pool di utenti condiviso, è possibile creare un unico standard di sicurezza e applicare la stessa sicurezza avanzata, l'autenticazione a più fattori (MFA) e AWS WAFgli stessi standard a tutti i tenant. Poiché un AWS WAF Web ACL deve trovarsi nella Regione AWS stessa risorsa a cui lo si associa, la multi-tenancy offre l'accesso condiviso a una risorsa complessa. Se desideri mantenere una configurazione di sicurezza coerente in applicazioni Amazon Cognito multiregionali, devi applicare standard operativi che replichino la configurazione tra le risorse.
- Personalizzazione comune
-
Puoi personalizzare i pool di utenti e i pool di identità con AWS Lambda. La configurazione dei trigger Lambda nei pool di utenti e degli eventi di Amazon Cognito nei pool di identità può diventare complessa. Le funzioni Lambda devono trovarsi nello stesso pool Regione AWS di utenti o pool di identità. Le funzioni Lambda condivise possono applicare gli standard per i flussi di autenticazione personalizzati, la migrazione degli utenti, la generazione di token e altre funzioni all'interno di una regione.
- Messaggistica comune
-
Amazon Simple Notification Service (AmazonSNS) richiede una configurazione aggiuntiva in una regione prima di poter inviare SMSmessaggi ai tuoi utenti. Puoi inviare messaggi e-mail con identità e domini verificati di Amazon Simple Email Service (AmazonSES) contenuti in una regione.
Con la multi-tenancy, puoi condividere questo sovraccarico di configurazione e manutenzione tra tutti i tuoi tenant. Poiché Amazon SNS e Amazon SES non sono tutti disponibili Regioni AWS, la suddivisione delle risorse tra le regioni richiede un'ulteriore considerazione.
Quando utilizzi provider di messaggistica personalizzati, ottieni la personalizzazione comune di una singola funzione Lambda per gestire la consegna dei messaggi.
L'interfaccia utente ospitata imposta un cookie di sessione nel browser in modo da riconoscere un utente che si è già autenticato. Quando autentichi gli utenti locali in un pool di utenti, il relativo cookie di sessione li autentica per tutti i client dell'app nello stesso pool di utenti. Un utente locale esiste esclusivamente nella directory del pool di utenti senza federazione tramite un IdP esterno. Il cookie di sessione è valido per un'ora. Non è possibile modificare la durata del cookie di sessione.
Esistono due modi per impedire l'accesso tra client di app con un cookie di sessione dell'interfaccia utente ospitato.
-
Separa i tuoi utenti in pool di utenti per tenant.
-
Sostituisci l'accesso all'interfaccia utente ospitata con l'accesso ai pool di utenti API di Amazon Cognito.
Argomenti
- Le migliori pratiche di multi-tenancy con pool di utenti
- Le migliori pratiche di multi-tenancy tra app e client
- Migliori pratiche di multi-tenancy per gruppi di utenti
- Best practice per la multi-tenancy con attributi personalizzati
- Best practice di multi-tenancy con ambito personalizzato
- Suggerimenti per la sicurezza del multi-tenancy
