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 di servizi che operano in sede

Questa sezione illustra le opzioni di connettività tra i carichi di lavoro SaaS nei data center locali Cloud AWS e quelli locali. Molti consumatori con requisiti locali, in particolare a livello aziendale, vedono il cloud come un'estensione della loro rete fisica e vogliono rifletterli nella loro architettura. Ciò significa connettività privata all'offerta SaaS nel cloud, tramite tunnel logici o anche tramite una connessione fisica privata. Altri consumatori accetteranno la connettività tramite la rete Internet pubblica, argomento trattato anche in questa sezione.

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.

Connettersi con AWS Site-to-Site VPN

AWS Site-to-Site VPNle connessioni possono terminare su un gateway privato virtuale o su un gateway di transito. Un gateway privato virtuale è l'endpoint VPN sul AWS lato della connessione Site-to-Site VPN che può essere collegato a un singolo VPC. Un gateway di transito è un hub di transito che può essere utilizzato per interconnettere più reti locali VPCs . Può essere utilizzato anche come endpoint VPN per il AWS lato della Site-to-Site connessione VPN. Questa sezione illustra entrambe le opzioni.

Connessione tramite un gateway privato virtuale

Dopo aver creato un gateway privato virtuale, lo colleghi al VPC che contiene la tua offerta SaaS. Quindi, abiliti la propagazione delle rotte per propagare le rotte VPN alla tabella delle rotte VPC. Questi percorsi possono essere statici o dinamici pubblicizzati da BGP.

Per garantire un'elevata disponibilità, una connessione Site-to-Site VPN dispone di due tunnel VPN che terminano lateralmente in due zone di disponibilità. AWS Se uno diventa non disponibile, il secondo tunnel può prendere il sopravvento. Un singolo tunnel consente una larghezza di banda massima di 1,25 Gbps. Poiché i gateway privati virtuali non supportano il routing multipercorso (ECMP) a costo uguale, è possibile utilizzare solo un tunnel alla volta.

Per aumentare la tolleranza agli errori, è possibile configurare una seconda connessione VPN a un secondo gateway fisico per il cliente. Una volta stabilita la connessione, il consumatore può accedere alle risorse nel VPC del provider SaaS.

Il diagramma seguente mostra questa architettura.

I vantaggi di questo approccio sono i seguenti:

Di seguito sono riportati gli svantaggi di questo approccio:

Connessione tramite un gateway di transito

Le connessioni tramite gateway di transito sono simili ai gateway virtuali. Tuttavia, ci sono alcune differenze da tenere a mente.

Innanzitutto, le route per l'allegato VPN possono essere propagate automaticamente all'interno della tabella delle rotte del gateway di transito, ma è necessario aggiungere manualmente le rotte all'allegato VPCs.

Rispetto a un gateway virtuale, Transit Gateway supporta ECMP. Se il gateway del cliente supporta ECMP, può utilizzare entrambi i tunnel per raggiungere un throughput massimo totale di 2,5 Gbps. È possibile stabilire più connessioni tra la stessa rete locale e il gateway di transito. Utilizzando questo approccio, è possibile aumentare la larghezza di banda massima fino a 2,5 Gbps per connessione.

Il diagramma seguente mostra questa architettura.

I vantaggi di questo approccio sono i seguenti:

Di seguito sono riportati gli svantaggi di questo approccio:

Connessione con AWS Direct Connect

AWS Direct Connectcollega la rete interna a una Direct Connect posizione tramite un cavo Ethernet standard in fibra ottica. A differenza delle altre opzioni di architettura, non è possibile stabilire una connessione dedicata in pochi minuti. Al contrario, questo processo può richiedere fino a diversi giorni se tutti i requisiti sono soddisfatti. In caso contrario, potrebbe volerci più tempo. Pertanto, ti suggeriamo di contattare il team del tuo AWS account o di Supporto AWS chiedere aiuto in merito a questo approccio. Facoltativamente, puoi scegliere una connessione ospitata fornita da un AWS partner e condivisa con altri clienti. L'architettura è la stessa a prescindere. Puoi scegliere Direct Connect perché riduce la latenza, migliora la larghezza di banda o è conforme ai requisiti normativi.

Per utilizzare la Direct Connect connessione, i consumatori devono creare un'interfaccia virtuale pubblica, privata o di transito. Sono disponibili diverse opzioni di architettura. La più flessibile a cui connettere più sedi locali Cloud AWS è un'interfaccia virtuale di transito connessa a un Direct Connect gateway. Un Direct Connect gateway è un componente logico globale che consente al fornitore di servizi di collegare fino a sei gateway di transito ad esso. Inoltre, è possibile connettere fino a 30 interfacce virtuali al gateway. Per motivi di scalabilità, puoi creare Direct Connect gateway aggiuntivi. Nell'account del provider SaaS, i gateway di transito si collegano quindi a VPCs, come descritto in precedenza.

I consumatori possono connettersi utilizzando da una a quattro Direct Connect connessioni da un totale di una o due Direct Connect postazioni, a seconda del livello di resilienza desiderato. Per ulteriori informazioni, consulta Configurazione Direct Connect per la massima resilienza. Una AWS Site-to-Site VPN connessione via Internet può anche fungere da percorso di backup a basso costo per una connessione. Direct Connect Le connessioni Direct Connect dedicate supportate possono essere utilizzate MACsecper crittografare il collegamento sul livello 2 tra la Direct Connect posizione e il data center. È comune disporre di una connessione Site-to-Site VPN per una maggiore riservatezza dei dati. La connessione Site-to-Site VPN può terminare sul gateway di transito utilizzando un normale allegato VPN. Il diagramma seguente mostra questa architettura.

I vantaggi di questo approccio sono i seguenti:

Di seguito sono riportati gli svantaggi di questo approccio:

Connessione con un'architettura VPC di transito

Transit VPC è un'opzione di architettura che offre flessibilità ai consumatori su come connettersi e consente ai AWS provider SaaS di trarre vantaggio dall'accesso unificato al proprio servizio tramite. AWS PrivateLink Il consumatore si connette dall'ambiente locale a un VPC di transito che contiene solo un punto di ingresso (come un gateway privato virtuale) e un endpoint VPC di interfaccia, che è una risorsa. AWS PrivateLink Il transito VPCs dovrebbe essere di proprietà del provider SaaS o dei consumatori. Questa sezione illustra entrambe le opzioni.

È possibile creare il VPC di transito e le sottoreti con intervalli CIDR compatibili con il data center locale. Se richiedono una connettività privata, i consumatori possono connettersi a quel VPC tramite AWS Direct Connect o. AWS Site-to-Site VPN Puoi anche configurare l'accesso all'account di transito dalla rete Internet pubblica utilizzando un Application Load Balancer o un Network Load Balancer che punti all'endpoint VPC.

VPC di transito gestito dai consumatori

In questo approccio, il provider SaaS lascia la gestione del VPCs transito ai consumatori. Da un punto di vista tecnico, l'architettura del provider SaaS è la stessa di quando si connette ai consumatori in modalità through. Cloud AWS AWS PrivateLink Dal punto di vista delle vendite e del prodotto, si tratta di uno sforzo aggiuntivo, perché alcuni consumatori non lo hanno Account AWS ancora fatto. Potrebbero essere riluttanti ad aprire e gestire un account. Il provider SaaS dovrebbe fornire indicazioni ai propri consumatori su come creare Account AWS e connettere il proprio data center locale. Il diagramma seguente mostra una combinazione di accesso pubblico e privato, in cui il transito è di proprietà dei consumatori. VPCs

I vantaggi di questo approccio sono i seguenti:

Di seguito sono riportati gli svantaggi di questo approccio:

VPC di transito gestito dal provider

Questo approccio utilizza le stesse tecnologie, ma i confini e le responsabilità degli account cambiano. Qui, il provider SaaS è proprietario del transito VPCs, preferibilmente in un account separato dall'offerta SaaS. Questo disaccoppiamento riduce i costi, riduce i rischi e consente all'account di transito di scalare in modo indipendente. Per gli ambienti che richiedono un elevato grado di isolamento, è possibile creare una separazione aggiuntiva tra i tenant utilizzando una sottorete o creando un VPC di transito separato per ogni consumatore. I consumatori possono quindi scegliere come connettersi al VPC di transito. Questo approccio offre più opzioni per espandere il mercato indirizzabile totale, ma ha un TCO più elevato per il provider SaaS a causa della necessità di gestire e monitorare componenti architettonici aggiuntivi.

I vantaggi di questo approccio sono i seguenti:

Di seguito sono riportati gli svantaggi di questo approccio:

Connessione tramite Internet pubblico

L'accesso pubblico a Internet è anche un'opzione valida per fornire l'accesso a un'offerta SaaS, sebbene non offra connettività privata nel senso tradizionale. Alcuni consumatori potrebbero comunque preferire un approccio ad accesso pubblico perché non richiede un'infrastruttura di rete aggiuntiva tra loro e il provider SaaS. Riduce la complessità, i costi e i tempi di integrazione in cambio di una maggiore superficie di attacco. Potenti meccanismi di autenticazione e autorizzazione possono aiutare a mitigare l'aumento del livello di minaccia e dovresti sempre crittografare il traffico. Si consiglia comunque di disporre di un ulteriore livello di sicurezza in questo scenario, ad esempio utilizzando. AWS WAF

L'architettura in questo scenario è semplice. Il consumatore si connette a un host pubblico (il provider SaaS) tramite Internet. L'applicazione può essere ospitata direttamente su un'istanza pubblica di Amazon Elastic Compute Cloud (Amazon EC2) con un indirizzo IP elastico. L'opzione preferita è ospitarlo dietro un Application Load Balancer o un servizio simile. Per prestazioni migliori e memorizzazione nella cache delle risorse statiche, puoi utilizzare una rete di distribuzione di contenuti, come Amazon CloudFront. Per servire un'applicazione con una latenza minima su due indirizzi IP Anycast statici globali, puoi posizionarla davanti AWS Global Acceleratora un'istanza Amazon EC2, Network Load Balancer o Application Load Balancer. Inoltre CloudFront, Application Load Balancer e Amazon API Gateway si integrano tutti con. AWS AppSync AWS WAF Il diagramma seguente fornisce una panoramica delle opzioni di connettività per l'accesso pubblico a Internet.

La tabella seguente descrive i protocolli e le integrazioni supportati per questo scenario.

I vantaggi di questo approccio sono i seguenti:

Di seguito sono riportati gli svantaggi di questo approccio:

Si applicano altri vantaggi e svantaggi, a seconda dei servizi scelti.