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

Anti-pattern per l'accesso alla rete in Cloud AWS

Un anti-pattern è una soluzione utilizzata frequentemente per un problema ricorrente in cui la soluzione è controproducente, inefficace o meno efficace di un'alternativa. Le opzioni di progettazione menzionate in questa sezione di solito funzionano, ma presentano notevoli svantaggi. Se possibile, dovrebbero essere evitate perché sono disponibili alternative migliori.

Mancata corrispondenza della zona di disponibilità con AWS PrivateLink

Quando forniscono l'accesso a un'applicazione tramite AWS PrivateLink, i consumatori SaaS possono creare endpoint VPC di interfaccia solo nelle zone di disponibilità in cui è distribuita l'applicazione. Ad esempio, se l'applicazione viene distribuita in use1-az1 euse1-az2, il consumatore non può implementare un endpoint VPC in. use1-az3 Ti consigliamo di implementare l'offerta SaaS in ogni zona di disponibilità. La maggior parte Regioni AWS ha tre zone di disponibilità, anche se alcune ne hanno di più. Per un elenco completo, consulta Regioni e zone di disponibilità. Considera il numero di zone di disponibilità quando scegli un Regione AWS.

Se un provider SaaS sceglie di non effettuare l'implementazione in tutte le zone di disponibilità, ci sono alcune conseguenze. Supponiamo che l'offerta SaaS sia implementata in use1-az1 anduse1-az2, ma che il consumatore utilizzi tutte e tre le zone di disponibilità, incluse. use1-az3 Gli endpoint VPC di interfaccia vengono implementati sul lato consumer use1-az1 e use1-az2 ora l'applicazione use1-az3 deve accedere a uno di questi endpoint. Innanzitutto, il traffico deve essere consentito dalle sottoreti nelle zone di disponibilità senza pari verso i rispettivi endpoint VPC. Il consumatore può decidere di utilizzare il nome AWS PrivateLink DNS regionale, che può essere risolto in entrambi gli endpoint VPC e che distribuisce uniformemente il traffico tra i due. Oppure il consumatore potrebbe scegliere di inviare il traffico direttamente a un endpoint, ad esempio. use1-az2 Ciò comporta che il 67% del traffico arrivi dal lato provider use1-az2 e il 33% in entrata. use1-az1 La figura seguente illustra questo scenario.

Con un numero significativo di consumatori e una distribuzione non uniforme del traffico, un carico di lavoro potrebbe riscontrare problemi di capacità in una zona di disponibilità e risultare insufficiente in un'altra. Per risolvere questo problema, il provider SaaS può decidere di bilanciare il carico in modo uniforme sul proprio lato abilitando il bilanciamento del carico tra zone sul Network Load Balancer. Ciò comporta costi aggiuntivi.

Se il fornitore di servizi corrisponde a una sola zona di disponibilità, tutto il traffico entrerà in un unico endpoint. Ciò crea uno squilibrio ancora maggiore. Di conseguenza, l'offerta SaaS non è più altamente disponibile per il consumatore. Per il consumatore non importa se l'applicazione viene fornita su zone di disponibilità aggiuntive che non utilizza autonomamente. Nel peggiore dei casi, un provider SaaS potrebbe non essere in grado di servire un consumatore che non utilizza nessuna delle stesse zone di disponibilità.

Nel raro caso in cui non sia possibile per il provider SaaS fornire la propria applicazione su tutte le zone di disponibilità, è anche possibile creare una sottorete solo nelle zone di disponibilità mancanti e quindi estendere il servizio a quelle zone di disponibilità vuote. Il bilanciamento del carico tra zone può quindi distribuire il traffico in entrata sugli endpoint effettivi dell'applicazione nelle altre zone di disponibilità.

AWS Site-to-Site VPN connessioni tra Account AWS

Le aziende che migrano da ambienti locali al cloud a volte cercano di sollevare e spostare l'intera rete. Ciò può causare problemi perché esistono differenze significative tra le pratiche di rete locali e quelle di rete cloud. Se questo cambiamento di mentalità non avviene, possono verificarsi cose come le AWS Site-to-Site VPN connessioni da un VPC a un altro VPC. Questo approccio non riesce a sfruttare i servizi di rete appositamente creati in the Cloud AWS, che semplificano la gestione e migliorano le prestazioni. L'adattamento ai design nativi del cloud aiuta a ridurre il sovraccarico operativo e si traduce in una connettività più affidabile e scalabile tra. VPCs

Se state pensando di fornire questa opzione di connettività come provider SaaS, chiedete a voi stessi o al consumatore perché AWS Site-to-Site VPN dovrebbe essere utilizzata. Quindi, procedi a ritroso rispetto a tali requisiti per trovare un'opzione di connettività migliore. La sezione relativa al confronto delle funzionalità dei servizi di questa guida contiene una matrice che è possibile utilizzare per identificare le opzioni. Quindi, puoi consultare le sezioni pertinenti di questa guida per trovare un approccio architettonico adatto al tuo caso d'uso.