VPC Lattice: Descubrimiento de servicios entre clústeres y malla de servicios

13 Mayo, 2025

By Masoom Tulsiani, Cloud Solution Architect, Rackspace Technology

Introducción

A medida que las organizaciones avanzan hacia los microservicios y las arquitecturas de aplicaciones distribuidas, la gestión de una comunicación segura, escalable y fiable entre servicios se convierte en un reto cada vez mayor. Los modelos de red tradicionales a menudo se quedan cortos en entornos grandes y dinámicos, especialmente cuando los servicios abarcan varias cuentas de AWS y VPC.

Para abordar estas limitaciones, AWS presentó VPC Lattice, un servicio de red de aplicaciones totalmente administrado que simplifica la comunicación de servicio a servicio en entornos nativos de la nube. VPC Lattice aúna el enrutamiento en la capa de aplicación, la detección de servicios, la autenticación y la capacidad de observación, todo ello sin necesidad de que los desarrolladores gestionen complejas configuraciones de red o mallas de servicios basadas en sidecar.

Este blog técnico explora cómo VPC Lattice puede ayudar a modernizar la conectividad de servicios y simplificar la implementación de patrones de malla de servicios en Amazon EKS, ECS y Lambda. Conocerá los componentes principales de VPC Lattice, patrones de diseño comunes, casos de uso prácticos y guías de implementación para crear arquitecturas de microservicios seguras, escalables y eficientes.

< entidad-drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

Comprender la arquitectura de malla de servicios en la nube

La arquitectura de malla de servicios aborda muchos de los retos operativos y de red a los que se enfrentan los desarrolladores en sistemas distribuidos o basados en microservicios. En esencia, una malla de servicios ayuda a gestionar el modo en que los servicios se comunican entre sí, gestionando las políticas de enrutamiento, descubrimiento, seguridad, observabilidad y tráfico sin necesidad de modificar el código de la aplicación.

Uno de los pilares fundamentales es el descubrimiento de servicios, que permite localizarlos de forma dinámica y conectarlos entre sí. En una malla de servicios nativa de la nube típica, las características suelen incluir:

Descubrimiento dinámico de servicios
Equilibrio de la carga
PLAZO ; TERMINACIÓN.
HTTP/2 y proxy gRPC
Disyuntores
Controles sanitarios
Conformación del tráfico (por ejemplo, despliegues canarios o división del tráfico)
Inyección de fallos para pruebas
Métricas enriquecidas y observabilidad

Entrar en VPC Lattice

VPC Lattice es la solución de malla de servicios y redes de aplicaciones de capa 7 totalmente administrada de AWS. Permite la comunicación de servicio a servicio a través de VPC, cuentas y plataformas de cómputo como EKS, ECS, EC2 y Lambda, sin requerir proxies sidecar o configuración manual de la red.

Evolución de la red Kubernetes: de la API Ingress a la API Gateway

En entornos Kubernetes, el recurso Ingress ha sido durante mucho tiempo el estándar para exponer servicios a clientes externos. Sin embargo, a medida que los casos de uso de las redes han ido evolucionando, las limitaciones de la API Ingress se han hecho más evidentes.

Para solucionar esto, la comunidad de Kubernetes introdujo la API Gateway, que representa la próxima generación de recursos de red L4/L7 para Kubernetes. Mejora y, con el tiempo, pretende sustituir a la API Ingress al ofrecer funciones de enrutamiento más flexibles y expresivas.

El controlador de API de gateway de AWS para VPC Lattice aprovecha esta evolución. Cuando se crea una puerta de enlace y se asocia a una VPC de clúster Kubernetes, el controlador aprovisiona automáticamente una red de servicios. Esta red de servicios actúa como tejido de comunicación, permitiendo un flujo de tráfico seguro, escalable y observable entre servicios.

Además, al definir nuevas CustomResourceDefinitions (CRD) de Kubernetes, el servidor API de Kubernetes expone nuevas rutas de recursos RESTful, lo que permite configuraciones de red más extensibles y declarativas a través de la API de Gateway y VPC Lattice.

Retos de las arquitecturas tradicionales de malla de servicios

A medida que los entornos de microservicios crecen en complejidad, la gestión de la comunicación entre servicios -especialmente entre cuentas, regiones y plataformas- se hace cada vez más difícil. Aunque las arquitecturas de malla de servicios pretenden resolver estos problemas, su implantación en entornos de nube pública introduce una nueva serie de retos.

Complejidad de instalación y gestión

Las mallas de servicios tradicionales pueden ser difíciles de desplegar y manejar, sobre todo en entornos de nube pública donde los desarrolladores ya gestionan diversas herramientas y servicios.

Complejidad de despliegue: La configuración de mallas de servicios como Istio o Linkerd suele implicar la gestión de proxies sidecar, planos de control, gestión de certificados e integración con servicios como AWS IAM o Google Cloud Identity.
Mantenimiento continuo: Actualizar los componentes de la malla, gestionar las políticas y supervisar el comportamiento de los servicios a escala aumenta el riesgo de errores de configuración, que pueden provocar una degradación del rendimiento o vulnerabilidades de seguridad.

Latencia y sobrecarga de rendimiento

El modelo de proxy sidecar central de muchas mallas de servicios puede introducir una sobrecarga innecesaria en entornos en los que cada milisegundo y cada ciclo de cálculo cuentan.

Mayor latencia: La comunicación de servicio a servicio se enruta a través de sidecars, lo que añade saltos adicionales y puede ralentizar los tiempos de respuesta, especialmente para aplicaciones sensibles a la latencia.
Mayor coste: Los sidecars consumen más CPU y memoria, y el aumento del tráfico de red entre servicios incrementa los costes de entrada y salida de la nube pública.

Retos de la nube múltiple y la nube híbrida

Las organizaciones modernas operan con frecuencia a través de múltiples nubes públicas y entornos locales, lo que dificulta la implementación coherente de la malla de servicios.

Problemas de interoperabilidad: Cada plataforma tiene su propio modelo de red y sistema de gestión de identidades, lo que complica los esfuerzos por crear una malla de servicios unificada.
Incoherencia de las políticas: La aplicación de políticas coherentes de gestión del tráfico, seguridad y supervisión en entornos heterogéneos requiere herramientas personalizadas o un esfuerzo manual.

Considerar la complejidad de la seguridad

Aunque las mallas de servicios ofrecen funciones de seguridad integradas, como TLS mutuo (mTLS) y autorización detallada, su gestión a escala puede resultar compleja.

Carga operativa: Configurar y rotar certificados mTLS en cientos de servicios lleva mucho tiempo y es propenso a errores, lo que aumenta el riesgo de interrupciones o brechas de seguridad.
Superposición de modelos de seguridad: Los mecanismos de seguridad nativos de la nube, como las funciones de IAM, los grupos de seguridad y las configuraciones de VPC pueden entrar en conflicto con las políticas basadas en malla, lo que da lugar a configuraciones redundantes o incoherentes.

Observabilidad y complejidad de la supervisión

Una de las principales ventajas de una malla de servicios es la mejora de la visibilidad, pero la captura e integración de datos telemétricos conlleva sus propios retos.

Gran volumen de datos: Las trazas, métricas y registros generados por la malla pueden suponer importantes costes de almacenamiento y ancho de banda en entornos de nube.
Integración de herramientas: La combinación de herramientas de observabilidad nativas de malla (por ejemplo, Prometheus, Jaeger) con herramientas nativas de plataforma (por ejemplo, CloudWatch, Stackdriver) requiere conocimientos adicionales de configuración y funcionamiento.

Retos de escalado en grandes clústeres

A medida que crecen las implantaciones de malla de servicios en miles de servicios y varios clústeres, surgen problemas de escalabilidad, especialmente en entornos Kubernetes.

Consumo de recursos: Los proxies Sidecar en cada pod aumentan el consumo de recursos a nivel de nodo, reduciendo la eficiencia general del clúster.
Cuellos de botella en el plano de control: Los componentes de malla centralizados (como Pilot de Istio) pueden convertirse en puntos de estrangulamiento del rendimiento, especialmente en entornos multicloud o de alto rendimiento.

Transición de App Mesh a VPC Lattice

AWS ha ofrecido históricamente varias soluciones de malla de servicios, incluidas App Mesh y VPC Lattice.

App Mesh se diseñó para cargas de trabajo que se ejecutan en ECS, EKS y EC2, y proporciona funciones de malla de servicios del lado del cliente, como resistencia del tráfico (por ejemplo, reintentos, tiempos de espera, agrupación de conexiones) y cifrado TLS mutuo (mTLS). Sin embargo, se basaba en proxies sidecar basados en Envoy, que introducían complejidad de configuración y sobrecarga adicional de infraestructura.

AWS ha anunciado que App Mesh quedará obsoleta. Después del 30 de septiembre de 2026, los clientes dejarán de tener acceso a la consola o los recursos de App Mesh, lo que supone un cambio más amplio hacia una red de servicios más integrada y simplificada.

Por el contrario, VPC Lattice es la solución de red de aplicaciones y malla de servicios de capa 7 moderna y totalmente administrada de AWS. Tiende un puente entre las redes tradicionales y la comunicación de la capa de aplicación, lo que permite a las organizaciones conectar microservicios que se ejecutan a través de Kubernetes, EC2, grupos de Auto Scaling, Lambda y Fargate.

VPC Lattice es ideal para equipos que desean automatizar el descubrimiento de servicios, la gestión del tráfico, la autenticación, la autorización y la observabilidad, sin la complejidad de las mallas de servicios basadas en sidecar. Es especialmente adecuado para los usuarios que desean implantar arquitecturas de aplicaciones modernas sin grandes conocimientos de redes VPC ni de gestión de infraestructuras de malla.

3. Resumen de la solución

AWS VPC Lattice proporciona una solución de red de aplicaciones y malla de servicios totalmente administrada y diseñada para simplificar la comunicación de servicio a servicio en los entornos de AWS. Permite la conectividad entre servicios que se ejecutan en Amazon EKS, ECS, EC2, Lambda y más, sin necesidad de proxies sidecar ni configuraciones de red complejas.

Las principales ventajas de VPC Lattice son:

Gestión del tráfico y equilibrio de carga: Aprovecha las API de gateway nativas de Kubernetes para definir reglas de enrutamiento del tráfico y equilibrar la carga entre puntos finales en varios clústeres de AWS.
Observabilidad: Ayuda a supervisar y solucionar problemas de comunicación entre servicios, incluidos los tipos de solicitudes, volúmenes de tráfico, errores y tiempos de respuesta.
Descubrimiento de servicios y conectividad a gran escala: Conecta miles de servicios entre VPC y cuentas sin aumentar la complejidad de la red.
Autenticación y autorización con políticas IAM: Utiliza IAMAuthPolicy, adjunta a redes de servicios VPC Lattice o servicios individuales, para controlar el acceso a los servicios. Estas políticas pueden asociarse directamente a los recursos API de Gateway.
Control de acceso granular: Mejora la seguridad de servicio a servicio con permisos de acceso centralizados que admiten arquitecturas de confianza cero mediante autenticación y autorización específicas para cada contexto.
Controles de tráfico avanzados: Admite funciones de enrutamiento de granularidad fina como el enrutamiento a nivel de solicitud y los objetivos ponderados, lo que permite estrategias de despliegue como los despliegues azul/verde y canario.
Configuración de red abstraída: Simplifica el descubrimiento de servicios y el enrutamiento entre tareas ECS que se ejecutan en diferentes clústeres al eliminar la necesidad de peering VPC o pasarelas de tránsito.
Gestión eficaz del tráfico entre regiones: Gestiona el tráfico entre regiones y entornos, lo que admite casos de uso como el análisis y las alertas de fraude en tiempo real.
Compatibilidad con la capacidad de recuperación del enrutamiento: Permite el enrutamiento automático y las capacidades de conmutación por error para ayudar a mantener la disponibilidad de la aplicación, incluso si partes del sistema tienen problemas.

VPC Lattice gestiona automáticamente la comunicación entre servicios, la conectividad entre VPC y entre cuentas y el control avanzado del tráfico, lo que facilita la implantación y el funcionamiento de aplicaciones distribuidas modernas a escala.

Figura: Componentes del entramado VPC y redes de servicios

4. Descripción detallada de la solución

VPC Lattice elimina las complejidades de la infraestructura de red subyacente, lo que permite a los equipos centrarse en la comunicación segura y escalable entre servicios. En lugar de basarse en estructuras de red tradicionales como el peering de VPC o las puertas de enlace de tránsito, VPC Lattice introduce una arquitectura similar a una malla de servicios que simplifica la interacción de los microservicios en los entornos de AWS. Los componentes clave incluyen:

Red de servicios: En el corazón de VPC Lattice se encuentra la red de servicios, que actúa como un límite lógico para agrupar servicios. Dentro de una red de servicios, puede definir y aplicar reglas de enrutamiento, aplicar políticas de seguridad y gestionar el flujo de tráfico entre servicios. Estas redes admiten recursos basados y no basados en VPC, lo que ofrece flexibilidad en entornos híbridos y sin servidores.
Gestión del acceso: VPC Lattice se integra con AWS Identity and Access Management (IAM) para controlar qué servicios pueden comunicarse entre sí. Las políticas de IAM de granularidad fina ayudan a definir el acceso a nivel de servicio o de red de servicios, dando soporte a interacciones seguras y conscientes del contexto entre microservicios.
Comunicación entre regiones y cuentas: VPC Lattice elimina la necesidad de complejos peering VPC entre regiones o de gestión de extremos a nivel de cuenta. Los servicios pueden comunicarse de forma segura entre cuentas y regiones de AWS, sin necesidad de una configuración de red personalizada o manual.

La siguiente sección ilustra un caso de uso práctico: la comunicación de servicio a servicio entre clústeres utilizando VPC Lattice.

Figura - Comunicación de servicio a servicio entre clústeres de Amazon EKS mediante Amazon VPC Lattice

Dos conceptos fundamentales en VPC Lattice son la Red de Servicio y el Servicio. Dentro de un Servicio, AWS proporciona construcciones familiares, similares a las utilizadas en los Application Load Balancers (ALBs) - incluyendo listeners y grupos de destino. Estos grupos de destino pueden incluir recursos como pods de Amazon EKS o tareas de ECS. A efectos de este blog, nos centraremos específicamente en ejemplos relacionados con Amazon EKS y Amazon ECS.

Flujo de tráfico VPC Lattice

VPC Lattice ofrece un enfoque potente y flexible para administrar el flujo de tráfico y las llamadas a API entre servicios implementados en varios recursos de AWS, incluidos los grupos de Auto Scaling y las funciones de Lambda.

Para conectar un grupo de Amazon EC2 Auto Scaling a un servicio Lattice de VPC, siga estos pasos:

Cree un grupo de destino que dirija las solicitudes a instancias EC2, identificadas por el ID de instancia.
Configure una escucha en el servicio VPC Lattice para reenviar las solicitudes entrantes a este grupo de destino.
Adjunte el grupo de destino a su grupo de Autoescalado.

Una vez conectado, Amazon EC2 Auto Scaling administra automáticamente el ciclo de vida de registro de destino. Registra las nuevas instancias en el grupo de destino a medida que se lanzan y las da de baja cuando está prevista su finalización, lo que garantiza un enrutamiento coherente y preciso.

El grupo de destino se convierte en el punto de entrada de todo el tráfico entrante a su grupo de Autoescalado. Las solicitudes entrantes se enrutan en función de las reglas de escucha definidas en el servicio VPC Lattice, lo que permite un control preciso sobre cómo se distribuye el tráfico entre las instancias.

Estrategias, patrones de diseño y guía de aplicación

En un entorno AWS multicuenta, VPC Lattice proporciona una forma segura y escalable de habilitar la comunicación de servicio a servicio entre VPC y cuentas de AWS. Lo consigue estableciendo redes de servicios y asociaciones de servicios, que simplifican la conectividad al tiempo que mantienen sólidos límites de seguridad.

Considera la siguiente arquitectura:

La Cuenta del Consumidor A y la Cuenta del Consumidor B necesitan comunicarse con los servicios alojados en la Cuenta del Proveedor A y la Cuenta del Proveedor B, respectivamente.
En la Cuenta de Proveedor A, una VPC Lattice Service Network 1 está asociada con la VPC Lattice Service 1. Esta configuración permite que las instancias EC2 de la cuenta de consumidor A se conecten a través de resolvedores DNS configurados con las asociaciones de VPC adecuadas.
En la cuenta de proveedor B, la red de servicios 2 está asociada con el servicio Lattice 2 de VPC. Una función Lambda en la cuenta de consumidor B utiliza una interfaz de red elástica (ENI) para conectarse, lo que permite una comunicación de servicio a servicio segura y dinámica.
Mientras tanto, la cuenta de proveedor B aloja instancias EC2 en un grupo de Auto Scaling, lo que garantiza la elasticidad y la alta disponibilidad para admitir cargas de trabajo variables de ambas cuentas de consumidor.

Esta arquitectura simplifica enormemente la interconexión entre cuentas, eliminando la necesidad de complejas configuraciones punto a punto. Al desacoplar la conectividad del servicio de la infraestructura de red subyacente, VPC Lattice admite:

Control de acceso detallado
Enrutamiento del tráfico en la capa de aplicación
Comunicación escalable y segura en diversos entornos informáticos

El resultado es una reducción de la sobrecarga operativa, una mejor capacidad de observación y una mayor flexibilidad arquitectónica para las organizaciones que administran servicios en varias cuentas de AWS y VPC.

Figura: Ilustración de la comunicación servicio a servicio de múltiples clústeres/VPCs

Ejemplo: Comunicación entre clusters EKS

En este ejemplo, se utiliza Amazon VPC Lattice para permitir una comunicación segura y escalable entre los servicios que se ejecutan en clústeres EKS independientes.

Figura: Tráfico HTTPS a través de VPC Lattice

El Gateway API Controller gestiona la creación de recursos VPC Lattice basándose en las definiciones HTTPRoute e IAMAuthPolicy.
External-DNS es responsable de generar registros DNS en una Zona Alojada Privada Route 53. Utiliza los mismos objetos HTTPRoute que definen los nombres de dominio personalizados para los servicios.
Cuando un HTTPRoute de API Gateway incluye un dominio personalizado, Amazon VPC Lattice crea automáticamente un punto de enlace DNS correspondiente para esa entrada.
Para la autorización, la solución utiliza políticas de autenticación IAM en combinación con EKS Pod Identity. Este enfoque simplifica el proceso para que los administradores de Kubernetes concedan permisos IAM a las aplicaciones que se ejecutan en el clúster.

Esta configuración permite que los servicios de los clústeres se comuniquen de forma segura mediante las herramientas nativas de Kubernetes y la infraestructura de malla de servicios administrada por AWS.

Nueva funcionalidad: Acceso a recursos VPC cruzados con Privatelink para VPC Lattice.

Como se anunció en AWS Re:Invent 2024 el 1 de diciembre de 2024, PrivateLink ahora admite conectividad nativa entre regiones.

AWS PrivateLink representa una tecnología altamente disponible y escalable que establece una conectividad privada y unidireccional desde sus VPC a los servicios de punto de enlace de VPC. Esta conectividad se extiende a los servicios de AWS compatibles y, ahora, directamente a los recursos de la VPC. Anteriormente, el acceso y el uso compartido de servicios se limitaba a aquellos que utilizaban un equilibrador de carga de red o un equilibrador de carga de puerta de enlace, y los puntos finales de la VPC de interfaz sólo admitían la conectividad a los servicios de punto final de la VPC en la misma región.

Aportando ventajas como la conectividad de VPC a VPC a través de Privatelink o VPC Lattice, la compartición multicuenta a través de Resource Access Manager (RAM), la gestión escalable del tráfico (heredando las ventajas de Lattice y Privatelink) y la mejora de la seguridad heredando los mecanismos de seguridad y las configuraciones de recursos de VPC Lattice.

Compartición integrada con RAM

Con esta mejora, los clientes ya pueden compartir cualquier recurso de VPC a través de AWS Resource Access Manager (AWS RAM). El recurso compartido puede ser un recurso nativo de AWS (como una base de datos de Amazon RDS, un nombre de dominio o una dirección IP) ubicado en otra VPC o en un entorno local. Una vez compartidos, los usuarios autorizados pueden acceder a estos recursos de forma privada a través de los puntos finales de la VPC.

Arquitectura basada en eventos Integraciones

Los cusomers pueden compartir recursos de AWS, como instancias de Amazon Elastic Compute Cloud (EC2), servicios de contenedor Elastic Container Service (ECS) y Elastic Kubernetes Service (EKS), y sus propios servicios HTTPS a través de Amazon VPC y los límites de las cuentas de AWS, y utilizarlos para crear aplicaciones basadas en eventos mediante EventBridge y orquestar flujos de trabajo con AWS Step Functions.

Los clientes ya pueden crear y utilizar pasarelas de recursos y configuraciones de recursos. EventBridge y Step Functions trabajan ahora mano a mano con PrivateLink y VPC Lattice para permitir la integración de aplicaciones públicas y privadas basadas en HTTPS en arquitecturas y flujos de trabajo basados en eventos.

Puntos finales de la VPC

Los clientes de AWS PrivateLink ahora pueden aprovechar los puntos finales de VPC, con tecnología de AWS PrivateLink, para acceder de forma segura y privada a los recursos de VPC. Estos recursos, que incluyen, entre otros, bases de datos y clústeres, pueden residir en su VPC o en un entorno local y no están limitados a un equilibrio de carga.

Los clientes pueden configurar un punto de enlace de VPC de recursos para dirigir un único recurso o agregar varios recursos dentro de una red de servicios Lattice de Amazon VPC y, posteriormente, obtener acceso a la red de servicios mediante un punto de enlace de VPC de red de servicios dedicado.

Casos prácticos y ejemplos

1. Detección del fraude en tiempo real en los servicios financieros

Una organización de servicios financieros utiliza un sistema de detección de fraudes en tiempo real para controlar las transacciones de los clientes e identificar comportamientos sospechosos. La aplicación se basa en Amazon ECS Fargate e incluye varios microservicios, como monitorización de transacciones, puntuación basada en reglas y alertas.

Para funcionar eficazmente, la aplicación requiere una comunicación segura y de baja latencia a través de múltiples clústeres y la integración con sistemas nativos de la nube y locales, incluidos:

Centro de datos in situ: aloja datos históricos, incluidas transacciones heredadas y registros de clientes, que son fundamentales para un análisis preciso del fraude.
Amazon RDS para PostgreSQL - Almacena datos de transacciones recientes, alertas de fraude y metadatos utilizados para el análisis y la elaboración de informes.

Anteriormente, la organización había implantado Cloud Map y experimentado con App Mesh para apoyar la conectividad de los servicios. Sin embargo, a medida que aumentaban los requisitos de escalabilidad y cumplimiento de normativas, también lo hacía la necesidad de una solución más ágil y manejable.

Al adoptar VPC Lattice como una malla de servicios gestionados, la compañía habilitó la conectividad segura entre clústeres a través de los servicios de ECS Fargate, que abarcan varias cuentas de AWS y VPC, así como la infraestructura local.

Entre los elementos clave de la solución figuran:

1. Descubrimiento y encaminamiento de servicios entre clústeres

Las tareas de ECS Fargate en distintos clústeres se comunican sin necesidad de complejas configuraciones de red.
Servicios como la monitorización de transacciones se registran en VPC Lattice, que enruta las peticiones en función de las reglas de tráfico definidas. Por ejemplo, las transacciones marcadas se envían de la supervisión a los servicios de calificación para su evaluación.

2. Acceso local a los datos

AWS Direct Connect enlaza el centro de datos local con las VPC de AWS.
VPC Lattice enruta de forma segura las solicitudes entre las tareas de ECS y las bases de datos locales, aplicando controles de acceso basados en IAM e impidiendo el acceso no autorizado.
Esto permite al motor de detección de fraudes recuperar datos históricos a petición, enriqueciendo el análisis en tiempo real.

3. Acceso en tiempo real a Amazon RDS para PostgreSQL

Las tareas de ECS interactúan con Amazon RDS para consultar y almacenar registros de transacciones recientes.
VPC Lattice facilita el acceso directo a la instancia RDS, lo que permite que los servicios ECS distribuidos se comuniquen con una base de datos central, incluso entre clústeres.
La arquitectura se adapta perfectamente al aumento del volumen de transacciones.

4. Seguridad y observabilidad unificadas

La organización aplica políticas de seguridad coherentes, incluido el cifrado en tránsito y controles IAM detallados.
VPC Lattice proporciona visibilidad del tráfico de servicio a servicio, incluidas métricas como la latencia, el volumen de solicitudes y las tasas de error.
Esto contribuye al cumplimiento de la normativa al ofrecer una pista de auditoría completa de las interacciones entre servicios.

2. Aplicación de viajes y comercio electrónico usando ECS y Lambda

Una empresa de viajes y comercio electrónico necesitaba conectar de forma segura aplicaciones creadas en Amazon ECS y AWS Lambda. La plataforma incluía múltiples servicios que requerían una conectividad y una gestión del tráfico coherentes en los distintos tipos de computación.

En esta configuración:

La aplicación de reservas de viajes front-end se ejecuta en Amazon ECS y se expone a los usuarios de Internet a través de un Application Load Balancer (ALB) público.
El servicio de caja también funciona con ECS.
El servicio de reservas se ejecuta en AWS Lambda.

Tanto el servicio de pago como el de reserva se publican como servicios de Amazon VPC Lattice y son accesibles dentro de la misma red de servicios de VPC Lattice.

Para admitir la integración de Lambda, VPC Lattice se configuró para utilizar Lambda como tipo de grupo de destino, con una función designada especificada para la invocación.

Esta solución proporcionaba un equilibrio de carga en la capa de aplicaciones y una conectividad de red sin fisuras entre los servicios. Permitió al equipo de la plataforma centrarse en el desarrollo de aplicaciones en lugar de gestionar las complejidades de la infraestructura subyacente, como la configuración de VPC, la gestión de redes entre cuentas o la gestión de rangos de direcciones IP solapados.

Retos y consideraciones

Aunque VPC Lattice aborda muchos de los problemas tradicionales asociados a las implantaciones de malla de servicios, es importante comprender los retos y compensaciones más generales que pueden surgir, especialmente en escenarios de malla de servicios gestionados, híbridos y con varios clústeres.

Retos de las redes multiclúster

Un problema habitual en los entornos multiclúster es el solapamiento de rangos de direcciones IP, que puede complicar el enrutamiento y la conectividad entre servicios de distintas VPC o cuentas.

VPC Lattice ayuda a mitigar estos retos mediante:

Compatible con la API de Kubernetes Gateway de forma nativa, lo que elimina la necesidad de integraciones personalizadas.
Evitar el uso de definiciones de recursos personalizadas (CRD) para la configuración de servicios.
Gestión automática de la conectividad de red entre VPC y cuentas, incluida la traducción de direcciones de red (NAT) entre IPv4 e IPv6, y a través de rangos IP solapados.

Este soporte integrado reduce significativamente la complejidad operativa de las implantaciones multiclúster.

Bloqueo de proveedores y limitaciones de personalización

Las soluciones de malla de servicios gestionados suelen estar estrechamente acopladas a sus respectivas plataformas en la nube, lo que puede limitar la portabilidad y la personalización.

Las soluciones de malla nativas de la nube, como AWS App Mesh o Google Cloud Service Mesh, ofrecen una profunda integración con los servicios de la plataforma, pero este estrecho vínculo puede dificultar el traslado de cargas de trabajo a otros proveedores o entornos locales.
También pueden surgir restricciones de personalización. Las mallas gestionadas por nubes públicas suelen ofrecer menos flexibilidad en comparación con proyectos de código abierto como Istio, especialmente para organizaciones con políticas de tráfico únicas o necesidades de observabilidad avanzadas.

Estas consideraciones son importantes a la hora de evaluar si una solución gestionada como VPC Lattice se alinea con su estrategia de arquitectura a largo plazo.

Por qué VPC Lattice debería formar parte de su estrategia de redes de AWS

AWS VPC Lattice simplifica el modo en que las organizaciones conectan, protegen y monitorizan los servicios entre cuentas, VPC y regiones. Al automatizar el descubrimiento de servicios, la gestión del tráfico y la aplicación de políticas de seguridad, reduce la complejidad operativa al tiempo que admite arquitecturas de aplicaciones escalables y resistentes.

Ventajas de utilizar VPC Lattice en un escenario de detección de fraudes

Reducción de la complejidad de la red - Resume la configuración de red necesaria para la comunicación entre clústeres y dentro de las instalaciones, simplificando el descubrimiento de servicios y el enrutamiento entre tareas ECS.
Rendimiento escalable y de baja latencia - Gestiona eficazmente el tráfico entre regiones y entornos para apoyar la detección de fraudes y las alertas en tiempo real con una latencia mínima.
Seguridad y conformidad mejoradas - Utiliza políticas IAM, cifrado y controles de acceso centralizados para proteger los datos confidenciales en tránsito y cumplir los requisitos normativos.
Alta disponibilidad y resistencia - Admite el enrutamiento y la conmutación por error automáticos, lo que ayuda a que los sistemas críticos sigan disponibles incluso si partes de la arquitectura experimentan problemas.

Tanto si está creando flujos de trabajo de detección de fraudes en tiempo real, modernizando sistemas heredados o escalando en varias cuentas de AWS, VPC Lattice proporciona las capacidades de malla de servicios y las herramientas de red de capa de aplicación necesarias para simplificar su arquitectura, sin la carga que supone administrar la infraestructura de malla de servicios tradicional.

Referencia

https://aws.amazon.com/blogs/aws/securely-share-aws-resources-across-vpc-and-account-boundaries-with-privatelink-vpc-lattice-eventbridge-and-step-functions/

VPC Lattice Documentación de AWS: Visión general de VPC Lattice

Gateway API Controller - gateway API controller

Blogpost: https://aws.amazon.com/blogs/containers/build-secure-application-networks-with-vpc-lattice-amazon-ecs-and-aws-lambda/

API de la pasarela Kubernetes https://aws.amazon.com/blogs/containers/introducing-aws-gateway-api-controller-for-amazon-vpc-lattice-an-implementation-of-kubernetes-gateway-api/

Gestionar el flujo de tráfico con un grupo de destino VPC Lattice https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-vpc-lattice.html

IAM https://docs.aws.amazon.com/vpc-lattice/latest/ug/security_iam_service-with-iam.html

Comunicación segura entre clústeres en EKS https://aws.amazon.com/blogs/containers/secure-cross-cluster-communication-in-eks-with-vpc-lattice-and-pod-identity-iam-session-tags/