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à.

Consumatori SaaS che operano su AWS

Questa sezione illustra le opzioni di connettività se sia tu che i tuoi consumatori operate in. Cloud AWS Questo scenario offre la massima flessibilità perché molte si integrano Servizi AWS in modo nativo e perché entrambe le parti hanno accesso all'intero Servizio AWS portafoglio.

La seguente mappa dei valori di rete riassume il punteggio di ciascuna di queste opzioni per ogni metrica di valutazione. Per ulteriori informazioni sulle metriche di valutazione, consulta Metriche di valutazione in questa guida. Nella mappa, un cinque rappresenta il punteggio migliore, ad esempio il TCO più basso, il miglior isolamento di rete o il minor tempo di riparazione. Per ulteriori informazioni su come leggere questo grafico radar, Mappa dei valori della rete consulta questa guida.

Il grafico radar mostra i seguenti valori.

Integrazione con AWS PrivateLink

AWS PrivateLinkè il modo più nativo per il cloud per integrare un'offerta SaaS. I provider SaaS possono ospitare le proprie applicazioni utilizzando un Network Load Balancer. Il Network Load Balancer si integra direttamente con un Application Load Balancer, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service(Amazon EKS) e gruppi Auto Scaling. È anche possibile instradare il traffico dal Network Load Balancer per interfacciare gli endpoint VPC nell'account del provider SaaS. Questo ti aiuta a utilizzare un'API per raggiungere le applicazioni, ad esempio tramite Amazon API Gateway o AWS AppSync. Se la tua applicazione richiede l'accesso a risorse nell'ambiente del cliente che non sono bilanciate dal carico, come un database, puoi utilizzare gli endpoint VPC delle risorse.

AWS PrivateLink supporta una larghezza di banda fino a 100 Gbps per zona di disponibilità. Il diagramma seguente mostra una configurazione di base con alcune possibili integrazioni. Collega due account consumer all'account del provider SaaS tramite. AWS PrivateLink Sono presenti endpoint di servizio negli account dei consumatori e un Network Load Balancer nell'account del provider SaaS.

I vantaggi di questo approccio sono i seguenti:

Di seguito sono riportati gli svantaggi di questo approccio:

Condivisione di un servizio Amazon VPC Lattice

Per utilizzare Amazon VPC Lattice come opzione di connettività per la tua applicazione SaaS, devi prima creare uno o più servizi VPC Lattice che rappresentano i componenti dell'applicazione SaaS. Puoi configurare listener e regole di routing per indirizzare il traffico verso i tuoi obiettivi di backend, come istanze, contenitori o funzioni di Amazon EC2. AWS Lambda Per ulteriori informazioni, vedere Connessione dei servizi Saas all'interno di una rete di servizi VPC Lattice AWS (post del blog). Dal punto di vista concettuale, è quasi la stessa cosa che configurare un Application Load Balancer. Quindi, condividi il tuo servizio SaaS in modo sicuro con clienti Account AWS o organizzazioni utilizzando AWS Resource Access Manager (AWS RAM), specificando le autorizzazioni di cui dispongono. Dopo che i clienti hanno accettato la condivisione delle risorse, possono associare il servizio SaaS alle loro reti di servizi VPC Lattice esistenti o di nuova creazione per consentire la comunicazione. service-to-service

Ogni servizio VPC Lattice può supportare fino a 10 Gbps e 10.000 richieste al secondo per zona di disponibilità. Implementando le politiche di autenticazione, i tuoi clienti possono avere un controllo granulare su quali servizi e risorse possono accedere all'applicazione SaaS. È possibile utilizzare i gateway di risorse per accedere a risorse che richiedono una connessione TCP. Ad esempio, potrebbe trattarsi di un cluster Amazon EKS che gestisci o di una risorsa gestita dal cliente a cui l'applicazione deve accedere. Per ulteriori informazioni sull'utilizzo dei gateway di risorse per le offerte SaaS, consulta Estendere le funzionalità SaaS Account AWS utilizzando il AWS PrivateLink supporto per le risorse VPC (post del blog).AWS

Il diagramma seguente mostra una configurazione VPC Lattice di alto livello con alcuni esempi di integrazioni. Utilizza reti di servizi gestite dal cliente per accedere all'applicazione SaaS.

I vantaggi di questo approccio sono i seguenti:

Di seguito sono riportati gli svantaggi di questo approccio:

Creazione di connessioni peering VPC

Quando utilizzi il peering VPC per connettere il VPC del provider SaaS con il VPC del consumatore, entrambe le parti sono in grado di avviare connessioni. Ciò richiede una corretta configurazione dei gruppi di sicurezza, dei firewall e delle liste di controllo degli accessi alla rete () in entrambi gli account. NACLs In caso contrario, il traffico indesiderato potrebbe entrare nella rete tramite la connessione peering. È possibile utilizzare i gruppi di sicurezza per fare riferimento ai gruppi di sicurezza provenienti dal VPCs peering. Questo può aiutarvi a controllare l'accesso all'applicazione, perché i gruppi di sicurezza che inseriscono gli elenchi consentiti forniscono un controllo degli accessi più esplicito e granulare rispetto agli indirizzi IP che elencano gli indirizzi IP consentiti.

Con il peering VPC, l'offerta SaaS può essere raggiunta tramite un servizio o una risorsa distribuiti nel VPC. La maggior parte delle applicazioni SaaS si basa su un Application Load Balancer o un Network Load Balancer. AWS AppSync private APIs o Amazon API Gateway private APIs sono altri punti di accesso comuni alle applicazioni SaaS, in quanto possono fungere da destinazione tramite una connessione peering tramite endpoint VPC di interfaccia.

Dopo aver stabilito una connessione peering, è necessario aggiornare le tabelle di routing per entrambi gli account per definire la VPCs connessione peering come hop successivo per il rispettivo intervallo CIDR. Questa soluzione è consigliata solo ai provider SaaS che hanno pochi consumatori perché la gestione di più connessioni peering diventa rapidamente troppo complessa.

Il diagramma seguente mostra una configurazione di base con alcune possibili integrazioni. VPCs su due account consumer è presente una connessione peering con un VPC nell'account del provider SaaS.

I vantaggi di questo approccio sono i seguenti:

Di seguito sono riportati gli svantaggi di questo approccio:

Connessione VPCs con AWS Transit Gateway

Quando ti connetti VPCs AWS Transit Gateway, crea allegati VPC e distribuisce interfacce di rete nelle sottoreti di ogni zona di disponibilità che dovrebbero instradare il traffico da e verso il VPC. Si consiglia di disporre di una /28 sottorete dedicata in ogni zona di disponibilità per l'allegato VPC. Per ulteriori informazioni, consulta le best practice di progettazione di Amazon VPC Transit Gateway. VPCs È necessaria una tabella di routing aggiornata per inviare il traffico attraverso l'interfaccia di rete distribuita e le tabelle di routing Transit Gateway devono essere aggiornate di conseguenza. In una configurazione multi-tenant, si desidera che il VPC del provider SaaS disponga di un percorso verso tutti i consumatori. VPCs Il consumatore VPCs dovrebbe avere un percorso solo verso il VPC del provider SaaS.

Transit Gateway è altamente disponibile fin dalla sua progettazione. Supporta il monitoraggio con VPC Flow Logs e la larghezza di banda massima per un allegato Transit Gateway è di 100 Gbps per zona di disponibilità. Come il peering VPC, questo approccio consente il riferimento ai gruppi di sicurezza tra VPC, semplificando il controllo degli accessi tra gli ambienti.

Esistono due opzioni principali per connettere i consumatori alla tua offerta SaaS con Transit Gateway.

Opzione 1: utilizzo della RAM

Nella prima opzione, il fornitore di servizi condivide il Transit Gateway con i consumatori utilizzando AWS Resource Access Manager (AWS RAM). Ciò consente ai consumatori di implementare gli allegati VPC nei propri account. Il diagramma seguente mostra questa opzione a un livello elevato.

Opzione 2: gateway di transito peer-to-peer

La seconda opzione consiste nel collegare il gateway di transito con un gateway di transito negli account dei consumatori. Ciò offre ai consumatori una maggiore flessibilità perché ora possono controllare completamente le tabelle di percorso all'interno del loro gateway di transito. Ad esempio, potrebbero impostare un'ispezione centralizzata tra il servizio e i loro carichi di lavoro. Uno svantaggio di questa opzione è che è supportato solo il routing statico tra i gateway di transito. Il diagramma seguente mostra questa opzione a un livello elevato.

I vantaggi di questo approccio sono i seguenti:

Di seguito sono riportati gli svantaggi di questo approccio: