Esta estrategia, Endpoint Proxy en API Gateway, es muy adecuada especialmente porque tenemos los siguientes beneficios:con

• Implementar el escenario Rehost (lift and shift) para una migración.
• No realizar ninguna modificación a la implementación del API.
• Mantener el servicio web en una red privada y sin acceso a internet.
• Acceder a mejoras de seguridad del API de negocio y poder monitorearlo, dado que vamos a usar API Gateway.
• Posibilita el versionamiento del API de negocio con menor esfuerzo.
• Integración con el escudo de seguridad AWS WAF.

Tutorial Endpoint Proxy con API Gateway

Se piensa en implementar con Amazon API Gateway un Endpoint Proxy de tipo HTTP API, que puede brindar la solución a lo requerido.

Escenario API Público

Para este escenario vamos a utilizar el API ejemplo de Swagger https://petstore.swagger.io/ como referencia, que nos ayuda a probar operaciones RESTful comunes.

Probamos la operación https://petstore.swagger.io/#/pet/findPetsByStatus para mirar los datos disponibles.

Ok, el API está funcionando correctamente.

Definimos una arquitectura Cloud para este efecto en AWS.

Creamos el API Gateway HTTP con el nombre proxy-swagger-api.

Creamos la ruta $default.

La ruta $default actúa como un “catch-all” es decir gestiona cualquier petición que no coincida con otras rutas definidas. Puedes saber más aquí.

Creamos la integración.

Probamos el API RESTful de la misma forma que lo hicimos al inicio.

Debemos cambiar el Endpoint a el nuevo del API Gateway: https://gl1p0rt1gc.execute-api.us-east-2.amazonaws.com/ (reemplaza para tu caso con el apropiado).

Esta vez la prueba la vamos ha hacer desde Postman.

¡Excelente! Funciona igual y como un Endpoint Proxy con las ventajas y funcionalidades que ofrece API Gateway.

Escenario API Privado

¿En la vida real como sería un ejemplo?

Vamos a ver una arquitectura donde este API es una implementación privada que esta en una instancia EC2 en una subred privada de una VPC de la empresa. Por tanto el único que permite acceso y controla los flujos es el API Gateway.

Para este escenario vamos a usar la implementación de un CRUD API RESTful construído con Spring de Código Libre / Opensource en GitHub.

Descargamos el proyecto en la instancia EC2 en la red privada, lo compilamos y corremos de acuerdo a las instrucciones del archivo README.mb en el código .fuente.

Seguido a esto hacemos una prueba. En este caso nos ayudamos de AWS CloudShell.

Son dos comandos curl, que insertan un registro visita y luego recuperan todas los registros visitas.

Cabe mencionar que antes debemos conectarnos a esa máquina con los protocoles estándar de SSH + Server Key, y, primero pasando por un Bastion Host… ya se mucha información pero ese es el camino dado que el servidor EC2 esta en una subred privada.

Creamos un Endpoint Proxy de tipo HTTP API, igual que en primer escenario.

Creamos una Route (ruta) proxy $default.

Para poder direccionar el tráfico a un recurso en una red privada, vamos a usar un Aplication Load Balancer (ALB), el mismo que va incluir en su Target Group a la instancia EC2 que provee el API privado.

El ALB debe ser de tipo “internal” es decir solo se puede usar dentro de la VPC (no desde Internet).

Evidentemente necesitas tener un Target Group que contenga el servidor EC2 privado donde esta el API al cual el ALB va a dirigir las peticiones. Por esto en medio de la creación del ALB tendrás que crear este Target Group.

Debes asegurarte que el grupo de seguridad del ALB permite el tráfico al puerto donde esta el listener.

Continúa con la creación del ALB.

Bien, vamos a continuar con la creación de la integración de nuestro API proxy-api-crud, para esto vamos al servicio API Gateway para iniciar.

La integración debe ser de tipo “Private resource” y en método seleccionamo9s “Select manually” para tener la opción de elegir un ALB/NLB como Target service.

En la lista desplegada de los ALBs, seleccionamos nuestro proxy-alb recién creado.. Además vamos a tener que crear “Create new VPC link” en la selección correspondiente, ya que este será el puente entre nuestro API creado con API Gateway y por defecto en una red propia de AWS, con nuestra VPC propia de la empresa.

Para este caso la VPC es proxy-vpc-vpx, pero debes elegir la correspondiente en tu infraestructura.

Aquí una ampliación al concepto de VPC Link, un VPC Link es un recurso que permite crear una integración con los recursos privados de una VPC desde una ruta del API Gateway de tipo HTTP. De esta forma no tienes que exponer ningún recurso de la VPC al público e igual puedes usarlo como destino final de un API Gateway que si sea público. Si quieres saber más de integraciones privadas para API Gateway HTTP a recursos de tu VPC puedes mirar aquí.

Luego en las opciones siguientes es importante elegir a qué subredes tiene acceso este nuevo VPC Link y que grupos de seguridad se le asignan.

Las subredes son importantes porque deben ser las subredes asociadas a tu ALB y su correspondiente Target Group.

El grupo de seguridad, es que que permite el acceso al puerto correspondiente donde el Listener del ALB esta escuchando peticiones.

Realizada la integración vamos a identificar el url (Invoke URL) del Endpoint Proxy con API Gateway creado.

Listo, con ese url, si todo es correcto podemos hacer las siguientes peticiones:

Para crear una visita:

curl --location 'https://bg4gmloull.execute-api.us-east-2.amazonaws.com/api/visits' \
--header 'Content-Type: application/json' \
--data '{"date":"2024-01-19","name":"Fer","comment":"by CloudIO Strategy"}'

Para consultar visitas:

curl --location 'https://bg4gmloull.execute-api.us-east-2.amazonaws.com/api/visits'

Son las mismas peticiones que usamos con consultar el servicio web RESTful desde el shell de la instancia EC2 mostrada en el ejemplo.

¡Excelente! Hemos creado un Endpoint Proxy con API Gateway, son tocar la implementación, con la funcionalidad esperada y todos los beneficios que tenemos en el servicio Amazon API Gateway.

Conclusiones y pensamientos finales

Hoy en este tutorial hemos visto como podemos implementar un Endpoint Proxy con API Gateway, un requerimiento que viene a partir de una migración al estilo Rehost del cliente que no desea entrar en temas de modificación a sus aplicaciones.

Presentamos dos escenarios, un proxy para un API público, que es infrecuente, y, un proxy a un API privado que si es muy frecuente y en ambos casos el servicio Amazon API Gateway nos permite implementar tal necesidad.

Nuestra arquitectura es solo una posibilidad de implementación del requerimiento, sin embargo en nuestra opinión es la más simple y rápida para dar una respuesta adecuada.

Vimos un concepto “VPC Link” que es importantísimo a la hora de integrar un API HTTP con recursos privados en la VPC, y en nuestro caso, nos integramos a un ABL o Aplication Load Balancer, sin embargo podríamos habernos integrado por ejemplo a AWS Cloud Map. Dado esto, no es la única forma de integración que podrían usar.

El ALB nos habilita todas las ventajas que tenemos de un Load Balancer por ejemplo resiliencia o escalamiento horizontal, y aunque representa un costo adicional es justificable frente a un lineamiento SRT (Server Response Time) del negocio.

Evidentemente, falta muchas configuraciones complementarias a una arquitectura de este estilo, como por ejemplo lo relacionado a las decisiones de stages del API, las seguridades, el monitoreo y la trazabilidad. Además la buena práctica es conectar este API Gateway a un dominio o subdominio apropiado de su empresa para facilidad de uso y estrategias de contingencia, entre otros.