Creación de aplicaciones altamente resilientes con interdependencias de sus instalaciones mediante las zonas locales de AWS

Traducción y adaptación por José Lorenzo Cuéncar, Arquitecto Senior de Soluciones de Amazon Web Services (AWS)

Las AWS Local Zones son un tipo de implementación de infraestructura que coloca instancias, almacenamiento, bases de datos y otros servicios selectos de AWS cerca de grandes centros de población e industria.

Tras el exitoso lanzamiento de las AWS Local Zones en 16 ciudades de Estados Unidos desde 2019, en febrero de 2022, AWS anunció planes para lanzar nuevas AWS Local Zones en 32 áreas metropolitanas de 26 países en todo el mundo.

Con las Local Zones, hemos visto casos de uso en dos categorías comunes.

La primera categoría de casos de uso es para cargas de trabajo que requieren una latencia extremadamente baja entre los dispositivos de los usuarios finales y los servidores de las cargas de trabajo. Por ejemplo, consideremos la creación de contenido multimedia y los juegos multijugador en tiempo real. Para estos casos de uso, implementar la carga de trabajo en una Local Zone puede ayudar a lograr una latencia de milisegundos de un solo digito entre los dispositivos de los usuarios finales y la infraestructura de AWS, lo cual es ideal para una buena experiencia de usuario.

Este artículo se centrará en abordar la segunda categoría de casos de uso, que se ve comúnmente en una arquitectura híbrida empresarial, donde los clientes deben lograr una baja latencia entre la infraestructura de AWS y los centros de datos locales existentes. En comparación con la primera categoría de casos de uso, estos casos pueden tolerar una latencia ligeramente mayor entre los dispositivos de los usuarios finales y la infraestructura de AWS. Sin embargo, estas cargas de trabajo tienen dependencias con estos sistemas alojados en centros de datos locales, por lo que se requiere que la sea la más baja posible entre la infraestructura de AWS y los centros de datos locales para lograr un mejor rendimiento de la aplicación. Aquí hay algunos ejemplos de estos sistemas:

Cargas de trabajo de mainframe en el sector de servicios financieros alojadas en las instalaciones para atender a clientes regionales.
Active Directory empresarial alojado en las instalaciones para atender a cargas de trabajo en la nube y en las instalaciones.
Aplicaciones empresariales alojadas en las instalaciones que procesan un alto volumen de datos generados localmente.

Para las cargas de trabajo implementadas en AWS, el tiempo requerido para cada interacción con componentes aún alojados en el centro de datos local se incrementa debido a la latencia. A su vez, esto retrasa las respuestas recibidas por el usuario final. La latencia total se acumula y resulta en experiencias de usuario subóptimas.

Al implementar cargas de trabajo modernas en las Local Zones, puedes reducir la latencia y al tiempo que sigues teniendo acceso a sistemas alojados en centros de datos locales, lo que reduce la latencia total para el usuario final. Al mismo tiempo, puedes disfrutar de los beneficios de agilidad, elasticidad y seguridad ofrecidos por AWS, y aplicar las mismas prácticas recomendadas de automatización, cumplimiento y seguridad con las que estás familiarizado en las Regiones de AWS.

Resiliencia de cargas de trabajo empresariales con Local Zones

Al diseñar arquitecturas híbridas con Local Zones, la resiliencia es una consideración importante. Lo que se desea dirigir el tráfico a la Local Zone más cercana para una baja latencia. Sin embargo, cuando ocurren desastres, es fundamental realizar la conmutación por error automáticamente a la Región principal.

Veamos los detalles del diseño de la arquitectura híbrida basada en implementaciones del mundo real desde diferentes perspectivas para comprender cómo la arquitectura logra todos los objetivos de diseño.

Arquitectura híbrida con conectividad de red resiliente

El siguiente diagrama muestra una descripción general de alto nivel de una arquitectura híbrida empresarial resiliente con Local Zones, donde se tienen conexiones redundantes entre la Región de AWS, la Local Zone y el centro de datos corporativo.

Aquí hay algunos puntos clave de este diseño de conectividad de red:

Utiliza AWS Direct Connect o AWS Site-to-Site VPN para conectar el centro de datos corporativo y la Región de AWS.
Utiliza Direct Connect o una VPN autohospedada para conectar el centro de datos corporativo y la Local Zone. Esta conexión proporcionará una conectividad dedicada de baja latencia entre la Local Zone y el centro de datos corporativo.
Transit Gateway es un servicio regional. Al adjuntar la VPC a AWS Transit Gateway, solo puedes agregar subredes aprovisionadas en la Región. Las instancias en las subredes de la Local Zone aún pueden usar Transit Gateway para acceder a los recursos en la Región.
Para las subredes aprovisionadas en la Región, la tabla de rutas de la VPC debe configurarse para dirigir el tráfico hacia el centro de datos corporativo a través de Transit Gateway.
Para las subredes aprovisionadas en la Local Zone, la tabla de rutas de la VPC debe configurarse para dirigir el tráfico hacia el centro de datos corporativo a través de la instancia de VPN autohospedada o Direct Connect.

Arquitectura híbrida con implementación resiliente de cargas de trabajo

Los siguientes ejemplos muestran una carga de trabajo orientada al público y una carga de trabajo privada.

Para simplificar el diagrama y centrarse en la arquitectura de la capa de aplicación, los siguientes diagramas asumen que estás utilizando Direct Connect para conectar AWS con el centro de datos local.

Ejemplo 1: Carga de trabajo resiliente y orientada al público

Con una carga de trabajo orientada al público, el tráfico de los usuarios finales se dirigirá a la Local Zone. Si la Local Zone no está disponible, entonces el tráfico se dirigirá automáticamente a la Región utilizando una política de conmutación por error de Amazon Route 53.

Aquí están las consideraciones clave de diseño para esta arquitectura:

Implementa la carga de trabajo en la Local Zone y coloca la capa de cómputo en un grupo de Auto Scaling de AWS, para que la aplicación pueda escalar hacia arriba y hacia abajo según el volumen de solicitudes.
Implementa la carga de trabajo tanto en la Local Zone como en una Región de AWS, y coloca la capa de cómputo en un grupo de escalado automático. La implementación regional actuará como una pilot light un warm standby con una huella mínima. Pero puede escalar cuando la Local Zone no esté disponible.
Se requieren dos balanceadores de carga de aplicaciones (ALB): uno en la Región y otro en la Local Zone. La política de conmutación por error de Amazon Route 53 enviará tráfico a la Local Zone, pero cambiará automáticamente a la Región si la Local Zone no está disponible.
Se requiere una puerta de enlace a Internet para las cargas de trabajo públicas. Cuando se utiliza una zona local, no se necesita configuración adicional: defina una única puerta de enlace de Internet y adjúntela a la VPC.

Si desea especificar una dirección IP elástica para que sea el extremo público de la carga de trabajo, la zona local tendrá un grupo de direcciones diferente al de la región. Tenga en cuenta que BYOIP no es compatible con las zonas locales.

Cree un registro DNS de Route 53 con «Failover» como política de enrutamiento.

Para el registro principal, apúntelo al alias del ALB en la Zona local. Esto establecerá la Zona local como el destino preferido para el tráfico de la aplicación, lo que minimiza la latencia para los usuarios finales.
Para el registro secundario, apúntelo al alias del ALB en la región de AWS.
Habilite la verificación de estado para el registro principal. Si falla la verificación de estado del registro principal, lo que indica que la carga de trabajo implementada en la zona local no respondió, Route 53 apuntará automáticamente al registro secundario, que es la carga de trabajo implementada en la región de AWS.

Ejemplo 2: Carga de trabajo privada y resiliente

Para una carga de trabajo privada a la que solo pueden acceder los usuarios internos, se deben realizar algunas consideraciones adicionales para mantener el tráfico dentro de la red privada de confianza.

La arquitectura para la carga de trabajo resistente privada tiene los mismos pasos que la carga de trabajo dirigida al público, pero con algunas diferencias clave, como son:

En lugar de utilizar una zona alojada pública, cree zonas alojadas privadas en Route 53 para responder a las consultas de DNS para la carga de trabajo.
Cree los registros principal y secundario en Route 53 al igual que la carga de trabajo pública pero haciendo referencia a los ALB privados.
Para permitir que los usuarios finales accedan a la red corporativa (dentro de las oficinas o conectados a través de VPN) para resolver la carga de trabajo, use Route 53 Resolver con un punto de conexión de entrada. Esto permite que los usuarios finales ubicados en las instalaciones resuelvan los registros en la zona alojada privada. Route 53 Resolver está diseñado para integrarse con un servidor DNS local.
No se requiere una puerta de enlace de Internet para alojar la carga de trabajo privada. Es posible que necesite una puerta de enlace de Internet en la Zona local para otros fines: por ejemplo, para alojar una solución de VPN autoadministrada para conectar la Zona local con el centro de datos corporativo.

Alojar múltiples cargas de trabajo

Los clientes que alojan múltiples cargas de trabajo en una sola VPC generalmente deben considerar cómo segregarlas. Al igual que con las cargas de trabajo en la región de AWS, la segregación se puede implementar a nivel de subred o VPC.

Si desea segregar las cargas de trabajo a nivel de subred, puede ampliar su arquitectura de VPC existente aprovisionando conjuntos adicionales de subredes a la zona local.

Aunque no se muestra en el diagrama, para aquellos que usan una VPN autohospedada para conectar la zona local con un centro de datos local, la solución VPN se puede implementar en una subred centralizada.

Puede seguir usando grupos de seguridad, listas de control de acceso a la red (NACL) y tablas de enrutamiento de VPC, tal como lo haría en la región para segregar las cargas de trabajo.

Si desea segregar las cargas de trabajo en el nivel de VPC, como hacen muchos de nuestros clientes, dentro de la región, Transit Gateway generalmente maneja el enrutamiento entre VPC. Sin embargo, en este caso, puede no ser deseable enviar tráfico a la región para llegar a una subred en otra VPC que también se extiende a la zona local.

Las consideraciones clave para este diseño son las siguientes:

Direct Connect se implementa para conectar la zona local con el centro de datos corporativo. Por lo tanto, cada VPC tendrá aprovisionada una puerta de enlace privada, virtual y dedicada para permitir la asociación con la puerta de enlace de conexión directa.
Para habilitar el tráfico entre VPC dentro de la zona local, interconecte las dos VPC juntas.
Cree una tabla de enrutamiento de VPC en la VPC A. Agregue una ruta para la subred Y donde el destino es el enlace de interconexión. Asigne esta tabla de rutas a la subred X.
Cree una tabla de enrutamiento de VPC en la VPC B. Agregue una ruta para la subred X donde el destino es el enlace de interconexión. Asigne esta tabla de rutas a la subred Y.
Si es necesario, agregue rutas para redes locales y la puerta de enlace de tránsito a ambas tablas de rutas.

Este diseño permite que el tráfico entre las subredes X y Y permanezca dentro de la zona local, lo que evita cualquier latencia desde la zona local a la región de AWS y, al mismo tiempo, permite la conectividad total con todas las demás redes.

Conclusión

En esta publicación, resumimos los casos de uso de la arquitectura híbrida empresarial con zonas locales y le mostramos:

Arquitecturas de referencia para alojar cargas de trabajo en zonas locales con conectividad de baja latencia a centros de datos corporativos y resiliencia para permitir la conmutación por error a la región de AWS automáticamente.
Diferentes consideraciones de diseño para cargas de trabajo públicas y privadas que utilizan esta arquitectura híbrida.
Consideraciones de segregación y conectividad al extender esta arquitectura híbrida para albergar múltiples cargas de trabajo.

Ojalá puedas seguir estas arquitecturas de referencia para crear y ejecutar aplicaciones altamente resistentes con interdependencias del sistema local mediante las zonas locales.

Sobre el autor

José Lorenzo Cuéncar ha trabajado en empresas de consultoría, sector de la construcción ,y logística, así como startups de comercialización de bienes y servicios, apoyando en la adopción de tecnologías en la nube en América Latina. Actualmente se desempeña como Arquitecto Senior de Soluciones en Amazon Web Services para el Sector Educativo y Gobierno en México donde se especializa en Cómputo y Computo de Alto desempeño, apoya a la transformación digital de instituciones en México.

Blog de Amazon Web Services (AWS)