Escenarios de acceso a redes avanzados para las ofertas de SaaS en el Nube de AWS - AWS Guía prescriptiva

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.

Escenarios de acceso a redes avanzados para las ofertas de SaaS en el Nube de AWS

Las arquitecturas que se describen en la Escenarios de acceso a redes para ofertas de SaaS en el Nube de AWS sección deberían ayudarle a encontrar una solución para la mayoría de los casos de uso. Sin embargo, hay algunos escenarios que tienen requisitos técnicos específicos. Muchos están fuera del alcance de esta guía.

En esta sección se analizan las siguientes consideraciones y requisitos técnicos avanzados:

Comunicación bidireccional

En algunos casos, las aplicaciones requieren tráfico bidireccional para funcionar según lo esperado. Los casos de uso más comunes son los webhooks o los servicios de notificación. Por lo general, esto se consigue mediante una WebSocket conexión entre el servidor y el cliente. Esta conexión mantiene abierta la sesión TCP y permite a ambos participantes enviar tráfico a través de la conexión. La mayoría de los servicios descritos en esta guía son compatibles de forma nativa WebSocket, incluidos los balanceadores de carga de red, los balanceadores de carga de aplicaciones, Amazon API Gateway y AWS AppSync (a través de AWS PrivateLink puntos de enlace privados en tiempo real).

En otros casos, una aplicación del lado del proveedor de SaaS podría necesitar acceso a recursos del lado del consumidor, como una base de datos. Cuando te conectas a través de canales bidireccionales, como una AWS Site-to-Site VPN conexión, eso no supone ningún problema.

Por otro lado, AWS PrivateLink Elastic Load Balancing solo admite tráfico unidireccional. Si utiliza estos servicios, debe configurar otra ruta de red para el tráfico que se inicia desde su oferta de SaaS. Por ejemplo, puede tratarse de una AWS PrivateLink conexión adicional que vaya en la dirección contraria.

TCP, UDP y protocolos propietarios

Muchas aplicaciones se sirven a través de HTTP o HTTPS, pero no todas. Algunos pueden usar otros protocolos de capa 7 además del TCP, como Message Queuing Telemetry Support (MQTT). Otros podrían incluso utilizar el UDP para atender a los consumidores. En raras ocasiones, los servicios utilizan protocolos propietarios que deben transmitirse dentro de paquetes (capa 3). Para estos escenarios, es importante entender qué servicios respaldan su oferta de SaaS.

Para los servicios de capa 3, puede usar AWS PrivateLink balanceadores de carga de red, los cuales admiten todo el tráfico TCP y UDP.

Para los servicios de capa 7, Application Load Balancers y Amazon CloudFront admiten HTTP WebSocket, HTTPS y Google Remote Procedure Calls (gRPC). Del mismo modo, Amazon API Gateway y AWS AppSync cada uno admiten HTTP, HTTPS y WebSocket. Amazon CloudFront es el único servicio que actualmente admite HTTP/3.

Puede usar Amazon VPC Lattice para conectar aplicaciones de capa 7 y recursos de capa 3. Es compatible con la transferencia HTTP, HTTPS, gRPC, TCP y TLS.

Si la aplicación solo puede atender el tráfico a través de la capa 3, es fundamental que utilice los servicios de AWS red principales, como AWS Transit Gateway, AWS Direct Connect AWS Site-to-Site VPN, y el emparejamiento de VPC. Luego, el tráfico debe enrutarse directamente desde el consumidor de SaaS a la capa de cómputo de la oferta de SaaS.