Podemos probar las funciones directamente desde la interfaz de usuario. Para ello debemos clicar en el botón de probar función. Dado que las funciones consumen eventos tenemos que elegir qué evento de prueba queremos utilizar. Como hemos creado la función aún no tenemos ningún evento de prueba definido por lo que definimos uno. Un evento de prueba simplemente es un JSON con la estructura que recibirá nuestra función.

Una vez definido el evento y lanzada la prueba podemos ver en el apartado en verde el resultado de esta. Donde podemos validar que la función ha realizado lo que esperábamos. Las funciones Lambda soportan versiones y etiquetas. Cuando se realiza una versión, el código de esa versión ya no es modificable. Un alias se puede entender como si fuera un puntero a una o varias versiones.

La función editable no pertenece a ninguna versión y nos podemos referir a él mediante el alias $LATEST. Cuando publiquemos una versión lo haremos del código que se encuentra referenciado desde este alias. Adicionalmente podemos añadir una descripción.

En este caso estamos accediendo a un parámetro del evento que nos generará API Gateway.

Una vez ya publicada esta segunda versión vamos a crear un alias. Como ya se ha comentado en el apartado anterior un alias puede referenciar a una o varias versiones. En este caso vamos a ver como se define para varias versiones (un alias ponderado). Cuando vayamos a crear un alias ponderado debemos de indicar el porcentaje de peso que tiene cada versión. Este porcentaje definirá cuántos evento procesa cada una de las versiones. En este ejemplo hemos indicado un 50% por lo que uno de cada dos eventos será procesado en cada versión.

Los alias también se pueden probar con lo que podemos validar que realizando múltiples pruebas cada vez nos responde una función distinta.

Crear una API simple desde el API Gateway es igual de simple que crear una Lambda. Simplemente tenemos que acceder al servicio API Gateway desde nuestra consola de AWS. Cuando vayamos a crearla se nos preguntará qué tipo de API queremos crear. En este caso elegiremos HTTP API. A continuación tendremos la opción de crearla directamente o de importar su definición a través de un archivo Swagger (OpenAPI v2) o OpenAPI (OpenAPI v3). Por simplicidad la crearemos vacía.

A continuación se nos permitirá elegir las integraciones (servicios que procesaran los eventos que genere el API). En este caso elegimos integrar Lambda y elegimos la función que hemos creado en el apartado anterior. Si no se indica la versión se utiliza $LATEST.

Finalmente creamos las rutas de nuestra api y elegimos a qué función dentro de nuestra Lambda se realizará la llamada.

Por último, se nos permitirá agregar etapas (stages). Cada etapa se puede entender como un entorno diferente. Por ejemplo podríamos definir sandbox y production. En este caso dejaremos la etapa que se crea por defecto $default.

Podemos editar la integración para indicar la versión determinada que queremos utilizar. Para ello simplemente debemos de añadir al final del identificador ARN el alias o versión a utilizar.

Podemos ayudarnos de las etapas definidas para que dependiendo de en cual nos encontremos se utilice una versión u otra de forma dinámica. Para ello nos serviremos de las variables de la etapa.

Por un lado definiremos en variables de la etapa la variable lambdaAlias cuyo valor será el alias que deseemos utilizar. En este caso ponderado.

Finalmente volvemos a definición de la integración y sustituimos el alias indicado anteriormente por un valor evaluado dinámicamente (${stageVariables.lambdaAlias})