Panoramica

Le aziende di SaaS offrono soluzioni per un gran numero di tenant. Le implementazioni multi-tenant dei servizi AWS Edge (ad esempio CloudFront, AWS WAF, ecc...) richiedono decisioni di progettazione accurate per soddisfare i requisiti aziendali come flessibilità, costo, scalabilità e costi operativi.

Decisioni sull'architettura

Considera le seguenti decisioni architetturali quando progetti una soluzione multi-tenant utilizzando CloudFront:

  • Utilizzi lo stesso nome host per tutti i tenant (ad esempio saas.com/tenant1, saas.com/tenant2), oppure nomi host separati? Se utilizzi lo stesso nome host, hai la possibilità di eseguire l’implementazione utilizzando un'unica distribuzione CloudFront.
  • Se utilizzi nomi host separati, stai utilizzando lo stesso nome di dominio (ad esempio tenant1.saas.com, tenant2.saas.com), oppure utilizzi nomi diversi (ad esempio tenant1.com, tenant2.com)? Una distribuzione CloudFront può essere associata a un singolo certificato TLS, che può ospitare più nomi host (certificati SAN). Quando utilizzi lo stesso nome di dominio, puoi scegliere di implementare una distribuzione CloudFront per tenant, oppure un'unica distribuzione con wildcard CNAME e certificato TLS (*.saas.com) per tutti i tenant. Se i domini sono diversi, puoi scegliere di implementare una distribuzione CloudFront per tenant, oppure implementare più distribuzioni, ognuna con un certificato SAN che può ospitare fino a 100 domini diversi. Tuttavia, più sono i domini si collegano allo stesso certificato TLS, maggiore è l'attrito che si aggiunge al processo di emissione del certificato TLS.
  • Chi controlla il nome di dominio? Se i tenant controllano il proprio dominio, saranno necessari passaggi aggiuntivi per aggiungere il loro nome host come CNAME a una distribuzione CloudFront. Per motivi di sicurezza, CloudFront richiede di dimostrare la proprietà del dominio allegando un certificato TLS valido che copra il nome host. I tenant devono condividere il proprio certificato TLS, che caricherai su ACM, oppure devono permetterti di emettere un certificato TLS per loro conto utilizzando ACM. Con il secondo approccio, ACM richiede loro di creare un token CNAME nel loro DNS per dimostrare la proprietà del dominio.
  • I tenant condividono lo stesso contenuto, oppure hanno contenuti diversi? Se condividono contenuti comuni, valuta la possibilità di ospitare i contenuti condivisi su un singolo dominio che può essere utilizzato da tenant diversi. Ciò si traduce in una migliore percentuale di accessi alla cache per i contenuti condivisi.
  • Se utilizzi una distribuzione CloudFront per più tenant, li ospiti sulla stessa origine o su origini diverse? Se utilizzi la stessa origine (ad esempio un singolo bucket S3 o un singolo ALB), puoi differenziare i tenant in base al percorso URL o all'intestazione host. Aggiungi l'intestazione host alla chiave della cache se scegli questo metodo di differenziazione dei tenant. Se utilizzi origini diverse (ad esempio un bucket S3 per tenant, o la partizione su cluster ALB), hai bisogno di un evento di richiesta all’origine su Lambda@Edge per indirizzare il traffico all'origine corretta. Tieni presente che se utilizzi percorsi per differenziare i tenant (ad esempio saas.com/tenant1, saas.com/tenant2), puoi indirizzare nativamente diversi tenant alle loro origini utilizzando i comportamenti della cache di CloudFront, ma hai delle quote sul numero di comportamenti per distribuzione CloudFront.
  • Il tuo progetto rispetta le quote AWS per servizio AWS e per account AWS?

Considera i seguenti compromessi nel tuo progetto. Tieni presente che puoi implementare compromessi differenziati per offerte a più livelli. Ad esempio, nel livello base in cui controlli il nome di dominio, tutti i tenant condividono la stessa distribuzione CloudFront. I tuoi tenant premium avrebbero ciascuno una distribuzione CloudFront dedicata, con un dominio personalizzato e protezioni di sicurezza utilizzando AWS WAF.

  Ogni tenant è ospitato su una distribuzione CloudFront dedicata Più tenant ospitati sulla stessa distribuzione CloudFront
Osservabilità Disponibile nativamente per ciascun tenant Disponibile a livello di distribuzione, è necessario uno sforzo aggiuntivo per estrarre i parametri relativi ai singoli tenant utilizzando i log
Raggio di impatto Una modifica riguarda solo un tenant Una singola modifica riguarda tutti i tenant
Carico operativo Richiede un'automazione su larga scala, con implementazioni in batch per evitare limitazioni della larghezza di banda della rete a livello di API CloudFront Bassa
Personalizzazione Ogni tenant può avere una propria configurazione diversa Stessa configurazione per tutti i tenant. Quando abiliti il WAF, viene addebitato un costo per tutte le richieste
Prestazioni Ogni distribuzione CloudFront deve essere riscaldata dal traffico separatamente (ad esempio connessioni all'origine) Tutti i tenant traggono vantaggio da una distribuzione CloudFront riscaldata

Una distribuzione CloudFront può essere collegata a una singola lista di controllo degli accessi web (WebACL) di AWS WAF. La stessa WebACL può essere utilizzata su più distribuzioni CloudFront. I compromessi sopra menzionati si applicano anche all'implementazione di WAF, oltre ai seguenti:

  Utilizzo di una WebACL per tenant Utilizzo della stessa WebACL per più tenant
Prezzo Il costo di WebACL/Regole scala linearmente in base al numero dei tenant Il costo di WebACL/Regole è indipendente dal numero dei tenant
Falsi positivi Un aggiornamento delle regole potrebbe causare falsi positivi relativi a un singolo tenant Un aggiornamento delle regole potrebbe causare falsi positivi relativi a molti tenant singoli

Casi di utilizzo comune

Sottodominio per tenant

In questo scenario, crei un sottodominio (tenant1.saas.com) per ogni tenant. Route 53 è configurato con un registro di Alias wildcard (*.saas.com) su una distribuzione CloudFront, nonché configurato anche con wildcard CNAME (*.saas.com), con l'intestazione Host inclusa nella chiave della cache. Un'origine ALB che serve richieste dinamiche distingue nativamente i tenant utilizzando l'intestazione Host. Tieni presente che in questo scenario, una singola invalidazione del contenuto verrà applicata a tutti i tenant, poiché le invalidazioni di CloudFront sono indipendenti dalle intestazioni che fanno parte della chiave della cache, come l'intestazione Host. Un bucket S3 che serve contenuti statici avrebbe bisogno di una funzione CloudFront configurata sull'evento di richiesta del visualizzatore per leggere l'intestazione Host e riscrivere l'URL nella directory del tenant in S3 (ad esempio tenant1.saas.com/index.html -> s3://bucket:arn/tenant1/index.html). Se offri lo stesso contenuto a tutti i tenant di S3, ad esempio la stessa applicazione a pagina singola, ma li distingui con mediante delle API, prendi in considerazione questa semplice soluzione.

Se ospiti tenant su origini diverse, è necessaria una funzione Lambda@Edge configurata sull'evento di richiesta di origine per instradare le richieste di un tenant all'origine che lo ospita. Per saperne di più su questa implementazione, leggi i seguenti casi di studio:

Tenant con domini propri

In questo scenario, dedica una distribuzione CloudFront per ogni tenant e automatizza il processo (ad esempio creazione della distribuzione ed emissione del certificato TLS utilizzando Amazon Certificate Manager). Assicurati di aumentare preventivamente le quote pertinenti (ad esempio numero di distribuzioni per account, numero di certificati TLS). In alcuni casi, sarà necessario effettuare la partizione delle tue distribuzioni CloudFront su più account AWS.

Termina TLS sui tuoi server

Se la scala dei tuoi requisiti non può essere soddisfatta da CloudFront, prendi in considerazione la creazione di un parco istanze di proxy inversi (ad esempio basati su NLB ed EC2) per terminare le connessioni TCP/TLS e utilizza Global Accelerator per migliorare sicurezza e prestazioni. Tieni presente che in questo scenario è necessario implementare la memorizzazione nella cache nel tuo reverse proxy, se necessario.

Risorse

Questa pagina ti è stata utile?

 Feedback