Conectividad transitiva entre cargas de trabajo mediante AWS PrivateLink

Cómo utilizar AWS PrivateLink para habilitar la comunicación de Microservicios entre varias cuentas y el centro de datos corporativo.

Uno de los puntos clave hoy en día en los procesos de adopción de la nube es la solución de conectividad, hay casos en los que las empresas necesitan administrar la conexión entre múltiples cargas de trabajo y su centro de datos. Las grandes empresas suelen tener pocos bloques de direcciones IP disponibles para extender sus redes a la nube. Otro factor común es garantizar un control granular del acceso entre entornos.

La definición de la arquitectura de conectividad de cargas de trabajo en varias cuentas requiere planificar y distribuir CIDR privado, crear VPC, configurar la resolución de nombres (DNS), establecer el enrutamiento transitorio entre redes a través de conexiones mediante AWS Direct Connect o túneles VPN.

Existen soluciones para facilitar la gestión de esta conectividad, proporcionando transitividad entre redes privadas, especialmente en escenarios multicuentas. Los modelos más comunes hacen uso de Transit Gateway o Transit VPC, sin embargo, requieren que el cliente tenga disponibilidad de direcciones IP privadas para usar en redes de nube privadas.

Otro enfoque es el uso de AWS PrivateLink, que permite la conectividad privada y segura entre VPC o servicios de AWS sin necesidad de una puerta de enlace de Internet, o NAT Gateway, VPNs o AWS Direct Connect. La interconexión puede ocurrir entre cuentas, sin necesidad de IP pública, con alta escalabilidad, redundante y alta disponibilidad. Todavía podemos destacar:

- Facilidad de despliegue;
- Posibilidad de tener superposición de IP con su red local;
- Alto rendimiento, hasta 10 Gbps;

En este artículo analizaremos cómo establecer conectividad de red mediante las tecnologías AWS PrivateLink y Amazon API Gateway para los siguientes escenarios:

Conexión de cargas de trabajo de centros de datos empresariales a AWS
Conexión de cargas de trabajo en una cuenta de AWS con otra cuenta de AWS
Conexión de cargas de trabajo en AWS con cargas de trabajo en el centro de datos empresarial

Conexión de cargas de trabajo de centros de datos empresariales a AWS

En el primer escenario tenemos una aplicación en el centro de datos de la empresa que accede a microservicios alojados en varias cuentas de AWS en la misma región y expuestos por Amazon API Gateway en modo privado. Tenga en cuenta que en el siguiente dibujo tenemos una cuenta intermedia, llamada «Cuenta de tráfico», que concentra las conexiones con el centro de datos (VPN y AWS Direct Connect) y es la única dentro de todas las cuentas de la empresa que mantienen el enrutamiento directo a las redes corporativas.

El flujo de conectividad en este escenario tiene el siguiente aspecto:

La aplicación en el centro de datos realiza una llamada a Amazon API Gateway Endpoint
La IP ENI se devolverá a la cuenta de tránsito al resolver el nombre del punto final creado, al ser alcanzado por AWS Direct Connect o VPN
AWS PrivateLink Endpoint redirigirá la llamada a Amazon API Gateway en la cuenta de microservicio.

Cuando configure Amazon API Gateway VPC Endpoint en su cuenta de tránsito, creará una Elastic Network Interfaces (ENI) en cada zona de disponibilidad (AZ) que elija y un único Endpoint para acceder a las API de microservicios de esa región, como se muestra a continuación:

Conexión de cargas de trabajo en una cuenta de AWS con otra cuenta de AWS

En el segundo escenario, demostrado por la figura siguiente, tenemos conectividad entre varios microservicios en diferentes cuentas, donde el microservicio puede llamar a un punto final privado desde Amazon API Gateway, simplemente creando una interfaz de extremo de VPC, disponible en las mismas zonas de disponibilidad y región, para el Gateway del servicio API de Amazon.

Conexión de cargas de trabajo en AWS con cargas de trabajo en el centro de datos empresarial

Por último, en el tercer escenario, presentamos el modelo de conectividad para que las cargas de trabajo en AWS puedan acceder a un servicio alojado en el centro de datos empresarial a través de un VPC Endpoint Service y un equilibrador de carga de red configurados en Transit VPC.

En la imagen anterior, tenemos un NLB en la cuenta transitiva con un grupo de destino apuntando a direcciones IP de servicios en el centro de datos, en este caso, un servidor de base de datos.

Implementación de escenarios

Escenarios 1 y 2

Ahora vamos a crear un punto final para el servicio de Amazon API Gateway, como se describe en los escenarios 1 y 2, dentro de la cuenta de tránsito y las cuentas de carga de trabajo, para ello, realizaremos los siguientes pasos:

Vaya a «VPC» en «Services» y en el menú «Endpoints» haga clic en «Create Endpoint». Seleccione la opción «AWS Services» en «Service Category» y «com.amazonaws.region.Execute-API» como se muestra en el ejemplo siguiente:

Desplácese hacia abajo, seleccione la «VPC» en la que el servicio estará disponible y todos los «Subnet ID» , correspondientes a todas las AZ donde estarán disponibles Microservicios. Mantenga seleccionada la opción «Enable Private DNS Name»

Es importante configurar VPC Endpoint Service en todas las zonas de disponibilidad para garantizar que tiene conectividad a los servicios de otras cuentas de las mismas zonas de disponibilidad en una región:

También en la misma página seleccione «Security Group» y «IAM User Policy«. Finalice haciendo clic en el botón «Create Endpoint«.

Una vez creado, Endpoint proporcionará un DNS de resolución para cada ENI, en cada subred, en el ejemplo siguiente:

vpce-053e263e9b391129f-atzcq2wb.execute-api.us-east-1.vpce.amazonaws.com

Ahora en la cuenta de Microservice crearemos una Amazon API Gateway manteniendo la opción «Endpoint Type» como «Private«.

Dado que Amazon API Gateway VPC Endpoint Interface le permite acceder a cualquier API publicada en la misma región, es importante crear una directiva de recursos bloqueando todos los ID de endpoints de VPC y liberando solo aquellos a los que pueda acceder, como se muestra en el ejemplo siguiente:

{
   «Versión»: «2012-10-17",
   «Declaración»: [
   {
   «Efecto»: «Denegar»,
   «Principal»: «*»,
   «Acción»: «Ejecute-API:Invoke»,

   «Resource»: [«arn:aws:execute-api:region:account-id:api-id/»
   ],
   «Condición»: {
   «stringNotEquals& quot;: {
   «aws:sourcevpce»: «vpce-1a2b3c4d»

   }
   }
   ]
}

Recuerde que después de cambiar una política de recursos de Amazon API Gateway, debe volver a implementar la API.

La aplicación, en el centro de datos corporativo, al realizar una solicitud a una API privada alojada en API Gateway, debe poder resolver el nombre generado por la interfaz de extremo de VPC de Amazon API Gateway, de modo que la solicitud se redirigirá hasta que llegue a cualquier Amazon API Gateway dentro de la misma región, siempre y cuando que hay una versión preestablecida.

curl -X GET https://01234567ab.execute-api.us-west-2.amazonaws.com/test/pets

También puede crear un alias en su dominio interno dirigiendo a los puntos finales de las cuentas transitivas y agregando en el encabezado de llamada de descanso el ID de Amazon API Gateway para la segmentación adecuada. Puede encontrar más información sobre las llamadas a Amazon API Gateway en https://docs.thinkwithwp.com/apigateway/latest/developerguide/apigateway-private-api-test-invoke-url.html.

4.2. Escenario 3

Para el tercer escenario, crearemos un NLB dentro de la cuenta de tráfico, donde este grupo de destino apunta a las IP de una base de datos dentro del centro de datos corporativo. Vaya al servicio «Amazon EC2» y en el elemento «Load Balancers» haga clic en «Create Load Balancer«.

Elija la opción para crear NLB y en la siguiente pantalla establezca un nombre y elija «Scheme» como «Internal«. Establezca «Listeners«, elija TCP o TLS para aumentar la seguridad de la solución en el «Load Balancer Protocol» y establezca un puerto en el «Load Balancer Port«, como se muestra en el ejemplo siguiente:

En la misma pantalla vamos a definir las zonas de disponibilidad, siempre seleccionar todas las que son posibles para tener mayor disponibilidad.

Si ha seleccionado el protocolo TLS, deberá asociar un certificado, puede generarlo mediante el servicio AWS Certificate Manager:

A continuación, configuraremos el «Target Group«, ingresaremos el protocolo TCP y elegiremos el puerto en el que se ejecuta el banco:

Ahora agregue las direcciones IP de destino para su base de datos:

Avance y revise los datos de creación de NLB, una vez finalizados, se crearán los puntos finales de acceso para NLB. En la misma cuenta de tráfico crearemos en VPC un Endpoint Service conectado a NLB para compartir con las otras cuentas que consumirán este servicio:

Antes de continuar, es importante autorizar el ARN de la cuenta de origen en los «Whitelisted Principals» de VPC Endpoint Service de la cuenta de Transit, solo entonces puede crear la interfaz de extremo de VPC en la cuenta de origen. Una vez configurado todo, el acceso a la base de datos se produce a través del DNS generado en la configuración de VPC Endpoint Interface en la cuenta de cliente.

También necesitaremos el «Service Name» ubicado en la pestaña Detalles del punto final:

En la cuenta que consumirá la base de datos, en el servicio VPC, crearemos Endpoint usando la opción «Find Service by Name» con el nombre del Endpoint creado en la cuenta de tránsito. Después de ingresar el nombre y hacer clic en «Verify» verá en qué AZ estará disponible el recurso. Si esto no sucede, asegúrese de que está creando el recurso en la misma región.

Introduzca el grupo de seguridad y acceda a su base de datos con Endpoint creado:

Conclusión

En este artículo explicamos cómo conectar varias VPC mediante la solución AWS Private Link y Amazon API Gateway, lo que permite la superposición de IP y reduce la complejidad en la gestión de la conectividad entre cargas de trabajo. Puede utilizar AWS PrivateLink VPC Endpoint Interface con varios servicios de AWS o endpoints con comunicación TCP; consulte la lista completa en https://docs.thinkwithwp.com/pt_br/vpc/latest/userguide/vpce-interface.html.

Autores

Cristiano Scandura

Scandura es Arquitecto de Infraestructura de la Nube en AWS, trabaja con clientes en largos viajes de migración a la nube y adopta buenas prácticas de la base de la nube. Con 20 años de experiencia en TI, Scandura ya ha desarrollado e implementado docenas de proyectos de misión crítica en clientes de diferentes segmentos.

Alex Rosa

Alex Rosa es arquitecto de infraestructura de Mr. Cloud en AWS con sede en Florida. En los últimos años, ha ayudado a docenas de clientes empresariales a agilizar sus negocios mediante la adopción de la nube de AWS.

Blog de Amazon Web Services (AWS)