Cuando tus funciones Lambda viven dentro de una VPC, están completamente aisladas del mundo exterior. Eso es exactamente lo que buscamos: mantenerlas invisibles para los usuarios. Pero entonces surge la pregunta fundamental: ¿cómo accedemos a ellas? La respuesta está en configurar un API Gateway que actúe como puerta de entrada, definiendo endpoints públicos que enrutan las peticiones hacia los Lambdas correctos.

¿Qué es el single point of failure y por qué importa en API Gateway?

Cuando utilizamos un API Gateway, este se convierte en el único punto de falla o single point of failure [01:06]. Este concepto significa que, si este componente presenta muchas fallas, puede afectar a todo el sistema completo. Para mitigar este riesgo existen varias técnicas:

• Colocar un balanceador de carga al frente del API Gateway.
• Validar entradas dentro del propio API Gateway para fallar rápido y bloquear peticiones inválidas.
• Implementar un Lambda de autorización que filtre únicamente las peticiones confiables [01:40].

Estas estrategias permiten que el API Gateway sea robusto y no se convierta en un cuello de botella para toda la arquitectura.

¿Cómo crear una HTTP API en la consola de AWS?

Desde la consola de AWS, al buscar API Gateway encontramos varios tipos disponibles: HTTP, WebSocket, REST API y REST API privada [02:08]. En este caso se selecciona una HTTP API, que es la opción más directa para conectar Lambdas.

¿Cómo añadir integraciones con Lambdas?

Al crear la API, se añaden integraciones que definen hacia dónde se conectará cada ruta [02:24]. Las integraciones pueden apuntar a URLs HTTP o directamente a funciones Lambda. Se configuran dos Lambdas:

• HandleGitHubWebhook: recibe notificaciones de GitHub.
• GetMetrics: consulta métricas desde la base de datos.

La API recibe el nombre Plazicourse y se procede a definir las rutas [02:52].

¿Cómo definir las rutas y recursos?

Cada integración necesita una ruta específica con su método HTTP y su resource path [03:00]:

• POST /commit: apunta a HandleGitHubWebhook, recibiendo información de commits.
• GET /metrics/{email}: apunta a GetMetrics, donde el parámetro email se usa para consultar la base de datos y traer todas las métricas correspondientes a un usuario [03:24].

Usar el email como parámetro permite mantener la consulta general y extensible, facilitando futuras modificaciones sin cambiar la estructura de la API.

La sección de stages viene por defecto y es opcional, así que se puede avanzar directamente a la creación [03:54].

¿Cómo probar que el API Gateway enruta correctamente?

Una vez creada la API, lo más importante es obtener el invoke URL [04:14]. Esta URL pública es el endpoint que conecta con los Lambdas internos. Se encuentra en la configuración general de la API, en el panel izquierdo de la consola.

Para verificar el enrutamiento se usa Postman o cualquier herramienta similar [04:28]:

• Un GET a {invoke_url}/metrics/{email} devuelve la respuesta del Lambda GetMetrics.
• Un POST a {invoke_url}/commit devuelve la respuesta de HandleGitHubWebhook con el mensaje "Hello from HandleGitHubNotifications" [05:00].

Ambas respuestas confirman que el enrutamiento funciona correctamente y que las Lambdas permanecen seguras e inaccesibles directamente, solo alcanzables a través del API Gateway.

El siguiente paso será implementar un Lambda de autorización con Auth0 para validar que solo el engineering manager pueda acceder a las métricas. ¿Ya has trabajado con autorizadores en API Gateway? Comparte tu experiencia.