Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Antipatrones para el acceso a la red en el Nube de AWS

Un antipatrón es una solución que se utiliza con frecuencia para un problema recurrente en el que la solución es contraproducente, ineficaz o menos eficaz que una alternativa. Las opciones de diseño que se mencionan en esta sección suelen funcionar, pero presentan desventajas importantes. Si es posible, deben evitarse porque hay mejores alternativas disponibles.

La zona de disponibilidad no coincide con AWS PrivateLink

Al proporcionar acceso a una aplicación AWS PrivateLink, los consumidores de SaaS pueden crear puntos de enlace de VPC de interfaz solo en las zonas de disponibilidad en las que se implementa la aplicación. Por ejemplo, si la aplicación se implementa en use1-az1 yuse1-az2, el consumidor no puede implementar un punto final de VPC en. use1-az3 Le recomendamos que implemente la oferta de SaaS en todas las zonas de disponibilidad. La mayoría Regiones de AWS tienen tres zonas de disponibilidad, aunque algunas tienen más. Para obtener una lista completa, consulte Regiones y zonas de disponibilidad. Tenga en cuenta el número de zonas de disponibilidad al elegir una Región de AWS.

Si un proveedor de SaaS decide no realizar la implementación en todas las zonas de disponibilidad, hay algunas consecuencias. Suponga que la oferta de SaaS se implementa en use1-az1 yuse1-az2, pero el consumidor utiliza las tres zonas de disponibilidad, incluidas. use1-az3 Los puntos finales de la VPC de la interfaz se implementan en el lado del consumidor use1-az1 yuse1-az2, ahora, la aplicación use1-az3 necesita acceder a uno de estos puntos de enlace. En primer lugar, se debe permitir el tráfico desde las subredes de las zonas de disponibilidad no coincidentes hacia los puntos finales de VPC respectivos. El consumidor puede decidir usar el nombre AWS PrivateLink DNS regional, que se puede resolver en cualquiera de los extremos de la VPC y que distribuye uniformemente el tráfico entre los dos. O bien, el consumidor puede optar por enviar el tráfico directamente a un punto final, por ejemplo. use1-az2 Esto se traduce en que el 67% del tráfico llega al proveedor use1-az2 y el 33% entrause1-az1. En la siguiente figura se muestra este escenario.

Con un número significativo de consumidores y una distribución desigual del tráfico, una carga de trabajo puede tener problemas de capacidad en una zona de disponibilidad y estar insuficiente en otra. Para solucionar este problema, el proveedor de SaaS puede decidir equilibrar de manera uniforme la carga del tráfico de su lado habilitando el equilibrio de carga entre zonas en el Network Load Balancer. Esto conlleva cargos adicionales.

Si el proveedor de servicios solo coincide con una zona de disponibilidad, todo el tráfico entrará por un único punto final. Esto crea un desequilibrio aún mayor. Como resultado, la oferta de SaaS ya no está muy disponible para el consumidor. Al consumidor no le importa si la aplicación se entrega en zonas de disponibilidad adicionales que no esté utilizando él mismo. En el peor de los casos, es posible que un proveedor de SaaS no pueda atender a un consumidor que no utilice ninguna de las mismas zonas de disponibilidad.

En el raro caso de que el proveedor de SaaS no tenga una opción viable para aprovisionar su aplicación en todas las zonas de disponibilidad, también es posible crear una subred solo en las zonas de disponibilidad que faltan y, a continuación, extender el servicio a esas zonas de disponibilidad vacías. El equilibrio de carga entre zonas permite entonces distribuir el tráfico entrante entre los puntos finales de las aplicaciones reales de las demás zonas de disponibilidad.

AWS Site-to-Site VPN conexiones entre Cuentas de AWS

Las empresas que migran de entornos locales a la nube a veces intentan impulsar y cambiar toda la red. Esto puede causar problemas porque existen diferencias significativas entre las prácticas de red locales y en la nube. Si este cambio de mentalidad no se produce, pueden ocurrir cosas como AWS Site-to-Site VPN las conexiones de una VPC a otra. Este enfoque no aprovecha los servicios de red diseñados específicamente para tal fin Nube de AWS, que simplifican la administración y mejoran el rendimiento. La adaptación a los diseños nativos de la nube ayuda a reducir la sobrecarga operativa y da como resultado una conectividad más confiable y escalable entre ellos. VPCs

Si está pensando en ofrecer esta opción de conectividad como proveedor de SaaS, pregúntese a sí mismo o al consumidor por qué AWS Site-to-Site VPN debería utilizarla. Luego, analice esos requisitos para encontrar una mejor opción de conectividad. La sección de comparación de las capacidades de los servicios de esta guía contiene una matriz que puede utilizar para identificar las opciones. A continuación, puede revisar las secciones pertinentes de esta guía para encontrar un enfoque arquitectónico que aborde su caso de uso.