Forem: Kevin Catucuamba

Forzar nuevas versiones de AWS Lambda cuando solo cambias dependencias

Kevin Catucuamba — Fri, 09 Jan 2026 16:17:26 +0000

Problema

Al utilizar AWS Lambda para nuestros servicios, podemos encontrarnos con un escenario común: el código fuente de la función no cambia, pero sí se actualiza alguna de las dependencias, ya sea una librería propia o de terceros; el asunto cambia un poco.

En estos casos, es necesario forzar un nuevo despliegue para que la función incorpore los cambios. Sin embargo, AWS Lambda no genera una nueva versión si no detecta modificaciones en el código fuente, lo que puede provocar que la función siga ejecutándose con dependencias desactualizadas, aun cuando estas hayan sido modificadas o recompiladas.

Contexto

Cabe destacar que este problema se ha presentado utilizando las siguientes herramientas (aunque es probable que también ocurra con otras configuraciones o tecnologías):

Node.js v22.15.0
Se usa alias y versions de aws lambda y se usa una version alias (prod)

Solución

Variables de entorno

También es importante mencionar que agregar o modificar dinámicamente una variable de entorno podría parecer una solución al problema; sin embargo, esto no lo resuelve.

AWS Lambda no detecta cambios cuando únicamente se modifica el valor de una variable de entorno, por lo que no se publica una nueva versión de la función, manteniéndose el mismo artefacto desplegado.

Solución aplicada

Una de las soluciones es usar la propiedad AutoPublishCodeSha256 en la definición de AWS Lambda:

Una de las soluciones consiste en utilizar la propiedad AutoPublishCodeSha256 en la definición de la función AWS Lambda.

Esta propiedad corresponde a un hash del artefacto de despliegue; mientras su valor no cambie, AWS Lambda no publicará una nueva versión, incluso si el despliegue es ejecutado nuevamente.

Por lo tanto, es indispensable que este valor se actualice para forzar la publicación de una nueva versión. Si el código o las dependencias cambian pero el valor de AutoPublishCodeSha256 permanece igual, la nueva versión de la función no será desplegada.

Con este cambio se introduce una configuración que inyecta un valor dinámico en cada despliegue, garantizando que AWS Lambda detecte el cambio y publique una nueva versión.

No obstante, es importante destacar que, aunque las librerías no hayan cambiado, esta solución provoca igualmente la creación de un nuevo Layer, ya que se estaría actualizando la versión definida en el package.json.

En términos generales, esto no representa un inconveniente siempre que se cuente con un buen ciclo de vida y una correcta gestión de los layers, eliminando o descontinuando aquellos que ya no están en uso.

Otras posibles soluciones

Otra alternativa, simple y directa, consiste en utilizar la propiedad PublishLambdaVersion en el recurso del layer (AWS::Serverless::LayerVersion). No obstante, según el comportamiento actual de AWS SAM, tanto la definición del layer como la de la función Lambda deben encontrarse dentro del mismo manifiesto (template.yaml); de lo contrario, la publicación de una nueva versión no se ejecuta correctamente. Para más detalles sobre esta limitación, se puede revisar el siguiente issue:
https://github.com/aws/serverless-application-model/issues/3802

En mi caso particular, esta solución no funcionó debido a que manejo múltiples manifiestos de CloudFormation. El layer está definido en un template de nivel superior y es compartido por varias funciones Lambda, lo cual impide aprovechar esta propiedad en dicho escenario.

Cierre

Con alguna de las configuraciones mencionadas aseguras que cada cambio en tu Layer, ya sea una actualización de dependencias, un parche de seguridad o una nueva librería, desencadene automáticamente una nueva versión de tu función Lambda que apunte al Layer actualizado. Esto elimina la brecha entre lo que despliegas y lo que realmente se ejecuta en producción, garantizando que tus funciones siempre utilicen las versiones correctas de las dependencias sin intervención manual. El resultado: deploys predecibles, menos bugs ocultos y la tranquilidad de saber que lo que probaste localmente es exactamente lo que está corriendo en AWS.

Aurora DSQL, una alternativa a PostgreSQL

Kevin Catucuamba — Fri, 31 Oct 2025 14:55:02 +0000

Introducción

Aurora DSQL de Amazon es una base de datos relacional distribuida y sin servidor, diseñada para manejar cargas de trabajo transaccionales de forma eficiente. Permite crear clústeres en una sola región o en múltiples regiones, conectarse a ellos y cargar esquemas de ejemplo. A través de la consola de administración de AWS y la herramienta psql, los usuarios pueden interactuar con la base de datos. Al finalizar la configuración, se obtiene un clúster de Aurora DSQL completamente funcional, listo para usarse en entornos de prueba o producción.

Contexto

Según la documentación, Aurora DSQL es compatible con ORMs y otras herramientas comunes utilizadas para interactuar con bases de datos en aplicaciones backend. En los ejemplos que se presentan a continuación, se mostrará de manera rápida cómo se realiza la interacción y cuáles son algunas de sus limitaciones, considerando que ciertas características propias de PostgreSQL se encuentran deshabilitadas.

Se realizaron pruebas en dos tipos de backend:

B1: Spring Boot con JPA (Hibernate ORM)
B2: Node.js con Knex.js (query builder)

En ambos casos, se trata de pruebas de concepto rápidas, enfocadas en ofrecer una primera impresión de la funcionalidad de Aurora DSQL con estas herramientas, sin profundizar en todos los detalles avanzados de su uso.

Requisitos

Para comprender esta prueba realizada en este documento con Amazon DSQL es preferente tener conocimiento mínimo en estas herramientas:

Java / Spring Boot (Spring JPA, JDBC)
NodeJS / KnexJS Query Builder

Creando un cluster de Aurora DSQL

La creación de un cluster en Aurora DSQL es bastante sencilla; para este caso, lo creamos usando la consola web de AWS.

Seleccionamos crear un cluster y seleccionamos la opción de "Single-Region", para este caso dejamos las configuraciones por defecto y creamos el cluster.

Esperar a que se cree el recurso y estaríamos listos para conectarnos a la base de datos.

Ingresamos al cluster y seleccionamos el botón Conectar y seleccionamos Get Token, en dicha pantalla se despliegan las credenciales que debemos usar para conectarnos a la base de datos: host, port, database y password (token)

A modo de ejemplo, se crea una tabla de productos en Aurora DSQL para verificar el funcionamiento.

B1 Spring Boot JPA

Para el caso de Spring Boot tenemos realizadas las siguientes configuraciones:

dependencias

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-jpa</artifactId>
        </dependency>
        <dependency>
            <groupId>org.postgresql</groupId>
            <artifactId>postgresql</artifactId>
            <scope>runtime</scope>
        </dependency>
        <dependency>
            <groupId>software.amazon.dsql</groupId>
            <artifactId>aurora-dsql-jdbc-connector</artifactId>
            <version>1.2.0</version>
        </dependency>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <scope>annotationProcessor</scope>
        </dependency>
    </dependencies>

Notar que estamos usando la librería aurora-dsql-jdbc-connector para usarla como driver en las configuraciones de conexión a la base de datos.

application.yml

spring:
  application:
    name: my-sb-app
  datasource:
    url: jdbc:aws-dsql:postgresql://${AURORA_HOST}:${AURORA_PORT:5432}/${AURORA_DB}
    username: ${AURORA_USER}
    password: ${AURORA_PASSWORD}
    driver-class-name: software.amazon.dsql.jdbc.DSQLConnector
  jpa:
    hibernate:
      ddl-auto: none   
create-drop
    show-sql: true
    properties:
      hibernate:
        format_sql: true
        dialect: org.hibernate.dialect.PostgreSQLDialect

Dado que no es una base de datos nativa de PostgreSQL, note que el spring datasource y driver tinen un ligero cambio, tal como se explica en la documentación de Aurora DSQL: https://docs.aws.amazon.com/aurora-dsql/latest/userguide/SECTION_program-with-jdbc-connector.html

Se adjunta las configuraciones minimas necesarias para consultar y crear usuarios:

@Entity
@Table(name = "products", schema = "pfinance")
@Getter
@Setter
public class ProductEntity {

    @Id
    @Column(name = "prd_id", nullable = false)
    private Integer id;

    @Column(name = "prd_name", length = 50)
    private String name;

    @Column(name = "prd_price", precision = 18, scale = 6)
    private BigDecimal price;

    @Column(name = "prd_created_at", columnDefinition = "timestamp default now()")
    private LocalDateTime createdAt;

    @Column(name = "prd_updated_at", columnDefinition = "timestamp default now()")
    private LocalDateTime updatedAt;

    @Column(name = "prd_creator", length = 50)
    private String creator;

}

public interface ProductJPARepository extends JpaRepository<ProductEntity, Integer> {
}


@RestController
@RequiredArgsConstructor
public class TwoController {

    private final ProductJPARepository productJPARepository;
    private static final String CREATOR_ID = "1f8ba4c8-9d86-472d-8881-b90bb13bf643";

    @GetMapping("/users")
    public ResponseEntity<List<ProductEntity>> getProducts() {
        List<ProductEntity> products = productJPARepository.findAll();
        return ResponseEntity.ok(products);
    }

    @PostMapping("/users")
    public ResponseEntity<String> createProduct(@RequestBody ProductEntity productEntity) {
        productEntity.setCreatedAt(java.time.LocalDateTime.now());
        productEntity.setUpdatedAt(java.time.LocalDateTime.now());
        productEntity.setCreator(CREATOR_ID);
        productJPARepository.save(productEntity);
        return ResponseEntity.ok("Product created successfully");
    }


}

Una vez realizadas las configuraciones necesarias, el servicio se ha conectado sin problemas, dando como resultado que efectivamente se puede usar ORMs con esta base de datos relacional de tipo serverless.

Nota importante: El conector JDBC propio de Amazon Aurora DSQL que se esta usando administra el flujo de generación de tokens cuando se caduca, es por eso que a pesar de que haya pasado los 15 minutos de tiempo de vida del token incial, dicho driver tiene la capacidad de generar nuevos tokens de forma automática facilitando la integración con aplicaciones existentes, para ello el servicio tiene que tener los permisos IAM necesarios o en defecto tener las key access con permisos para generar nuevos tokens, para más información revisar: https://docs.aws.amazon.com/aurora-dsql/latest/userguide/SECTION_program-with-jdbc-connector.html

B2 NodeJS Knex.js

Para esta prueba se utiliza Knex.js, un query builder (constructor de consultas SQL) para Node.js que facilita la creación y ejecución de consultas en diferentes bases de datos de forma programática y flexible.

Para obtener el token (password) necesario para conectarse a la base de datos, AWS proporciona la librería aws-sdk/dsql-signer para Node.js. Su configuración es bastante sencilla, como se muestra a continuación:

import { DsqlSigner } from "@aws-sdk/dsql-signer";
import { getDSQLEnvs } from "./utils";
import { buildKnexConfig } from "./knex-config";


export const getKnexConfig = async () => {

    const { user, clusterEndpoint, region, port, database } = getDSQLEnvs();

    const signer = new DsqlSigner({
        hostname: clusterEndpoint,
        region: region,
    });

    const token = await signer.getDbConnectAdminAuthToken();

    return buildKnexConfig({
        host: clusterEndpoint,
        port: port,
        user: user,
        password: token,
        database: database,
    });
}

Nota: recordar que para que el programa pueda obtener las credenciales debe tener los permisos correspondientes o si es local las llaves de acceso correspondientes.

Configuración de Knex.Config:

import { Knex } from "knex";

export const buildKnexConfig = (conn: ConnectionDetails) => {
    const config: Knex.Config = {
        client: "pg",
        connection: {
            host: conn.host,
            port: conn.port,
            user: conn.user,
            password: conn.password,
            database: conn.database,
            ssl: {
                rejectUnauthorized: true,
            },
        },
        debug: false
    }
    return config;
}

Clase que inicializa una conexión para knexjs:

import knex, { Knex } from "knex";
import { getKnexConfig } from "./dsql-ds";

export class KnexjsDB {
    private static instance: KnexjsDB;
    private db: Knex;

    private constructor(db: Knex) {
        this.db = db;
    }

    static async create(): Promise<KnexjsDB> {
        if (!KnexjsDB.instance) {
            const config = await getKnexConfig();
            KnexjsDB.instance = new KnexjsDB(knex(config));
        }
        return KnexjsDB.instance;
    }

    get connection(): Knex {
        return this.db;
    }

}

Script para realizar una prueba de conexión:

import { KnexjsDB } from "./db/knexdb";

(async () => {
    const knexdb = await KnexjsDB.create();
    const conn = knexdb.connection;
    const products = await conn
    .select("*")
    .from("pfinance.products")
    .limit(3)
    console.log("Database Products:", products);
})();

Realizando una prueba para consultar productos de la base de datos de Amazon Aurora DSQL:

Tomar en cuenta que está versión de PostgreSQL no disponibiliza todas las características que una base de datos PostgreSQL normal, si intentamos ejecutar una funcionalidad que no soporta evidentemente fallará, uno de esas características justamente es generar secuenciales:

Si se ejecuta:

await conn.raw(`CREATE SEQUENCE spike_seq START WITH 1 INCREMENT BY 1;`);

Se genera un error como el siguiente:

Para más ejemplos en diferentes lenguajes y herramientas revisar estos ejemplos de AWS: https://github.com/aws-samples/aurora-dsql-samples

Conclusiones finales Aurora DSQL

Aurora DSQL es una excelente opción para implementar una base de datos compatible con PostgreSQL en aplicaciones nuevas o existentes que requieran el poder y la flexibilidad del lenguaje SQL. Sin embargo, es importante considerar sus limitaciones actuales, entre las que destacan la ausencia de llaves foráneas, secuencias (sequences), triggers y otras características avanzadas del ecosistema PostgreSQL. Para revisar en detalle estas restricciones, se recomienda consultar la documentación oficial de AWS: https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility.html
Aurora DSQL es una base de datos distribuida y serverless, cuyo modelo de costos se basa en el consumo de DPUs (Distributed Processing Units) y en el almacenamiento utilizado. Este esquema de facturación permite pagar únicamente por el uso real de los recursos, representando un alivio significativo en costos para aplicaciones con actividad variable. Además, el clúster ajusta automáticamente su capacidad y puede reducir su consumo a cero cuando está inactivo, algo poco común en bases de datos transaccionales, revisar costos en: https://aws.amazon.com/rds/aurora/dsql/pricing/
En cuanto a la compatibilidad con herramientas comunes de bases de datos como PostgreSQL, Aurora DSQL ofrece un buen nivel de compatibilidad. Para conectarse y generar las credenciales necesarias, es recomendable utilizar las librerías proporcionadas por AWS. Por lo tanto, esta base de datos puede integrarse en aplicaciones existentes, siempre considerando las limitaciones propias de Aurora DSQL.
Finalmente, Aurora DSQL según la documentación resulta ideal para cargas de trabajo dinámicas o impredecibles, como aplicaciones que experimentan picos de tráfico en ciertos momentos del día o de la semana. Sin embargo, en entornos con uso constante, alto rendimiento sostenido o requerimientos avanzados de PostgreSQL, podría resultar más adecuado optar por Aurora PostgreSQL o Amazon RDS PostgreSQL, que ofrecen un comportamiento más tradicional y completo.

Referencias

Dominio personalizado en Amazon API Gateway. Dominio desde GoDaddy.

Kevin Catucuamba — Sat, 04 Jan 2025 17:24:22 +0000

Cuando se implementan servicios utilizando Amazon API Gateway, configurar un dominio personalizado es fundamental para ofrecer una experiencia de usuario coherente. Esto permite que los clientes accedan a nuestra la API a través de un dominio que refleje y fortalezca la identidad de nuestra marca o empresa, en lugar de utilizar el dominio predeterminado que AWS proporciona, que además puede ser cambiante.

En este artículo, exploraremos cómo aprovechar esta funcionalidad para mejorar la experiencia de los usuarios y fortalecer la identidad de tu marca en tus API.

La configuración de un dominio personalizado en Amazon API Gateway presenta una serie de beneficios, incluyendo la mejora de la legibilidad de las URL de la API, el refuerzo de la identidad de tu marca y la facilitación del acceso de los usuarios a tus servicios.

Antes de configurar un dominio personalizado, asegúrate de tener una cuenta de AWS en funcionamiento, una API ya creada en Amazon API Gateway y un dominio personalizado registrado a tu nombre.

Para este caso particular se tiene registrado el dominio en "GoDaddy", en otros proveedores de dominio, la configuración será muy similar.

Route 53

Se debe registrar una zona hosteada en Route 53 para apuntar al dominio personalizado.

En la pantalla principal de zonas hosteadas de Route 53 debe aparecer un nuevo registro.

Accedemos al detalle y debemos observar la siguiente configuración.

Los valores deben ser registrados en los servidores de nombres en GoDaddy.

Dominio GoDaddy

Se configura los nombres de dominios de la siguiente manera en el panel de GoDaddy.

Solicitud de cerificado AWS Certificate Manager (ACM)

Se realiza una solicitud de certificado SSL/TLS para nuestro dominio.

Este proceso puede tardar un momento en verificarse correctamente para su uso.

Una vez realizado estas configuraciones estamos listos para crear un subdominio para nuestras apis desplegadas.

Creación de recursos

En este caso se muestra la configuración a nivel de plantillas CloudForamation y veremos que configuraciones o recursos son creados en la consola web de AWS.

Necesitamos localizar y estructurar los siguientes parámetros.

CustomDomainName: Será el subdominio que vamos a darle a nuestra api.
PublicCertificateArn: Es el ARN del certificado reclamado en ACM.
Hosted Zone Id: ID de la zona hosteada que acabamos de crear.

Si estamos usando plantillas de cfn podemos crear los siguientes recursos necesarios para la configuración del dominio:

AWS::ApiGatewayV2::DomainName

Verificar la creación de los recursos en la consola de AWS:

AWS::ApiGatewayV2::ApiMapping

Esta configuración es por cada api que tengamos:

Verificar la creación de los recursos en la consola de AWS:

Se mapean las diferentes apis de A. API Gateway al dominio:

Registro en Route 53

El valor de "API Gateway domain name" mostrado en la sección anterior es clave, ya que es la URL que usaremos para registrar en Route 53:

En "value" colocar el valor de domain name de API Gateway:

Notar que el "record-name" debe coincidir con el nombre de dominio que le estamos asignando en API Gateway.

Una vez creado estamos listos para usar el dominio personalizado para consumir nuestras APIS.

Script personalizado

Para que el registro del "record" en Route 53 sea un poco más automatizado se adjunta un script de ejemplo:

#!/bin/bash
#Register public record set in Route 53 in shared resources account for the api
pwd
ls -la

cd .stack/

CUSTOM_DOMAIN_NAME=<YOUR_CUSTOM_DOMAIN>
PUBLIC_CERTIFICATE_ARN=<YOUR_CERTIFICATE_AN>
ARN_API_DOMAIN_NAME=<YOUR_ARN_API_DOMAIN>
HOSTED_ZONE_ID=<YOUR_HOSTED_ZONE_ID>

echo "Showing variables..."
echo "CUSTOM_DOMAIN_NAME: $CUSTOM_DOMAIN_NAME"
echo "STACK_NAME: $STACK_NAME"
echo "ARN_API_DOMAIN_NAME: $ARN_API_DOMAIN_NAME"
echo "PUBLIC_CERTIFICATE_ARN: $PUBLIC_CERTIFICATE_ARN"
echo "HOSTED_ZONE_ID: $HOSTED_ZONE_ID"

if [ -n "$CUSTOM_DOMAIN_NAME" ] && [ -n "$PUBLIC_CERTIFICATE_ARN" ] && [ -n "$ARN_API_DOMAIN_NAME" ]; then
   echo "Consulting the Record Set HZ $HOSTED_ZONE_ID Name $CUSTOM_DOMAIN_NAME"
   EXISTING_RECORD=$(aws route53 list-resource-record-sets --hosted-zone-id $HOSTED_ZONE_ID --query "ResourceRecordSets[?Name=='$CUSTOM_DOMAIN_NAME.' && Type=='CNAME'].Name" --output text)
   if [ -n "$EXISTING_RECORD" ]; then
      echo "The register or CNAME already exists in Route 53."
      echo "EXISTING_RECORD: $EXISTING_RECORD"
   else
      echo "The register or CNAME does not exist in Route 53. A new one will be created."
      #Create the CNAME record set in Route 53
      aws route53 change-resource-record-sets \
         --hosted-zone-id $HOSTED_ZONE_ID \
         --change-batch '{
            "Changes": [
            {
               "Action": "CREATE",
               "ResourceRecordSet": {
                  "Name": "'"$CUSTOM_DOMAIN_NAME"'",
                  "Type": "CNAME",
                  "TTL": 300,
                  "ResourceRecords": [
                  {
                     "Value": "'"$ARN_API_DOMAIN_NAME"'"
                  }
                  ]
               }
            }
            ]
         }'
      echo "Register or CNAME created successfully"
   fi
else                      
    echo "It is omitted to create the public DNS record since a domain is not specified"
fi

El valor de ARN_API_DOMAIN_NAME es el valor de API Gateway domain name.

Pruebas

Podemos ejecutar cualquier prueba usando el dominio configurado:

EL path mapping se lo configura en el recurso AWS::ApiGatewayV2::ApiMapping, esta configuración es por cada api que tengamos.

Concurrencia en AWS Lambda

Kevin Catucuamba — Sun, 29 Sep 2024 12:18:44 +0000

En AWS Lambda, comprender cómo se gestiona la concurrencia es fundamental, ya que en muchos casos necesitaremos controlar el número de instancias activas en un momento específico. En este artículo, exploraremos los conceptos clave sobre la concurrencia en AWS Lambda, su importancia y cómo optimizar su comportamiento para lograr un rendimiento eficiente."

Empezemos mirando algunos conceptos de concurrencia en AWS Lambda:

Concurrencia

La concurrencia o simultaneidad es la cantidad de solicitudes que una función lambda pueda manejar al mismo tiempo.
Para cada solicitud simultánea, lambda proporciona una instancia separada de su entorno de ejecución.
A medida que las funciones reciben más solicitudes, Lambda se encarga automáticamente de escalar la cantidad de entornos de ejecución hasta que alcance el límite de simultaneidad de la cuenta.

Tipos de concurrencia en funciones lambdas

Concurrencia reservada: Reservar una parte de la simultaneidad de la cuenta para una función, útil cuando no se desea que otras funciones ocupen toda la simultaneidad sin reserva disponible.

Concurrencia provisionada: Preinicializar entornos para una función, útil para reducir latencias de arranque en frío.

*Como calcular la concurrencia *
La documentación recomienda tomar en cuenta lo siguiente:

Tomar el pico más alto como simultaneidad reservada si no se quiere descartar solicitudes o si es una función importante para el negocio.
Tomar el número promedio de ejecuciones simultáneas (puede perderse solicitudes).

Mirar: https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html
También podemos hacer uso de la siguiente fórmula:

Concurrency = (avg requests per second) * (avg request duration in seconds)
Calcular Concurrencia:

Solicitudes promedio por segundo.
Duración promedio de las solicitudes en segundos.

Ejemplo:

Concurrency = (100 solicitudes/segundo) * (0.5 segundos/solicitud) = 50

Cada entorno de ejecución soporta 2 ejecuciones por segundo.

Limitantes

La concurrencia reservada es la cantidad máxima de instancias simultáneas que se desea asignar a una función. Cuando se dedica concurrencia reservada a una función, ninguna otra función puede usar esa concurrencia. Esto puede afectar el grupo de simultaneidad que está disponible para otras funciones.
Las funciones que no tienen simultaneidad reservada comparten el grupo restante de simultaneidad no reservada. Ejemplo:

Concurrencia total de la cuenta: 1000 (900 disponibles para reservar|provisionar)
F1 = 200 OK
F2 = 200 OK
F3 = 500 OK
F4 = 150 FAIL (No puede tomar esta configuración sobrepasa el limite de concurrencia de la cuenta)
Como mínimo concurrencia no reservada: 100

Cada entorno de ejecución como máximo puede soportar 10 solicitudes por segundo, esto asumiendo que tiene una duración media de solicitud inferior a 100 ms, en ese caso la fórmula no funcionaria del todo bien. Ejemplo:

Solicitudes por segundo = 200 
Tiempo en segundos por solicitud = 0.05 (50 ms)

Concurrencia = (200) * (0.05) = 10

La concurrencia calculada es 10. En 10 entornos de ejecución la función lambda puede soportar 100
solicitudes por segundo de las 200 solicitudes. Experimenta un throttling.

En este caso como mínimo se necesitaria 20 entornos de ejecución reservada.

Cada función Lambda deberían ir ajustándose a nuevos recursos desplegados: Lambdas o concurrencia de cuenta.
Reservar una mala simultaneidad reservada puede provocar limitaciones y malas experiencias al usuario.
La simultaneidad reservada es útil para funciones que se invocan de forma asíncrona o mediante sondeadores internos. (por ejemplo, integraciones de S3, SQS o DynamoDB)

Cierre

Ahora que ya conoces los puntos claves de concurrencia en AWS Lambda ya podrás configurar más sabiamente a tus funciones lambdas para que puedan estar optimizadas cuando existen grandes ráfagas de peticiones o si solo quieres controlar el autoescalamiento.

Gran parte de este artículo está basada en la documentación oficial. Puedes revisar en este link que tiene más ejemplos acerca de concurrencia en funciones lambdas: https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html

Desplegar imagen docker usando AWS CodeBuild.

Kevin Catucuamba — Wed, 24 Jan 2024 18:16:04 +0000

¿Qué es AWS CodeBuild?

AWS CodeBuild es un servicio de integración continua totalmente administrado que compila código fuente, ejecuta pruebas y produce paquetes de software listos para implementar. Con CodeBuild, no necesita aprovisionar, administrar ni escalar sus propios servidores de compilación. CodeBuild escala continuamente y procesa múltiples compilaciones al mismo tiempo, para que sus compilaciones no queden esperando en una cola.

Dentro del conjunto de herramientas para desarrolladores, destaco el papel fundamental de AWS CodeBuild, una herramienta que utilizo de manera extensiva para automatizar la creación y despliegue de artefactos. En esta guía, nos centraremos de manera específica en agilizar el despliegue rápido de una imagen de Docker.

Herramientas

Para este caso particular se usan las siguientes herramientas para llevar a cabo el tutorial.

Proyecto almacenado en GitHub: La base de nuestro desarrollo.
Docker: Utilizado para la creación y carga de la imagen.
DockerHub: Plataforma para alojar nuestras imágenes.
AWS CodeBuild: Automatiza el proceso de creación y despliegue de la imagen Docker.
Comandos de bash: Herramientas esenciales en la ejecución de diversas operaciones.

Nota: Es importante destacar que AWS ofrece herramientas equivalentes e integradas de manera más eficiente, eliminando la necesidad de servicios de terceros. Por ejemplo:

En lugar de GitHub, podemos utilizar AWS CodeCommit.

Para DockerHub, podemos optar por Amazon ECR, una alternativa totalmente integrada en el ecosistema de AWS.

Estructura de proyecto

Este proyecto incluye todos los elementos necesarios para la creación de una imagen de Docker, junto con varios scripts que exploraremos en detalle más adelante.

El primer archivo que examinaremos es el buildspec.yml. Este archivo de configuración es crucial para CodeBuild, ya que contiene las instrucciones que la herramienta seguirá durante las distintas ejecuciones.

El buildspec.yml cuenta con varias propiedades, siendo la más esencial la sección "phases", donde se configura el proceso de despliegue.

Nota: Existen diversas propiedades adicionales que pueden personalizarse según las necesidades del proyecto, pero nos centraremos en las configuraciones mínimas para la fase de despliegue.



version: 0.2
phases:
  #install:
  pre_build:
    commands:
      - echo "*** PRE_BUILD ***"
      - docker system prune -f
      - ls -la
      - free -h
      - chmod +x ./scripts/*
      - ./scripts/loginDocker.sh
  build:    
    commands:
      - echo "*** BUILD ***"
      - export TAG_TEST=$(date +"%Y%m%d%H%M%S")
      - ./scripts/buildDocker.sh
  post_build:
    commands:
      - echo "*** POST_BUILD ***"
      - echo "TAG_TEST=$TAG_TEST"
      - ./scripts/pushDocker.sh

Se detalla rápidamente cada etapa:

install: Esta fase se emplea para la instalación de dependencias necesarias para la construcción del artefacto. Puede incluir la instalación de versiones específicas de Java o Node.js, recordando que se pueden ejecutar comandos adaptados al sistema operativo configurado para la construcción.
pre_build: Se destina a especificar los comandos que deben ejecutarse antes de que inicie el proceso de construcción propiamente dicho. En nuestro caso, otorgamos permisos a los scripts y realizamos el inicio de sesión en DockerHub.
build: En esta fase, se ejecutan los comandos necesarios para la construcción del artefacto; en nuestro caso, la creación de la imagen Docker.
post_build: Se utiliza para realizar tareas de limpieza o pasos adicionales después de que concluye la construcción. En nuestro escenario, este paso implica la carga de la imagen en DockerHub.

Nota: Es posible incluir los comandos directamente en la plantilla buildspec.yml. Sin embargo, cuando se trata de comandos extensos, resulta más eficiente dividirlos en scripts independientes y luego ejecutarlos.

A continuación se muestra el contenido de los scripts sh:

loginDocker.sh
Este script lleva a cabo la autenticación en DockerHub mediante el uso de variables de entorno que contienen el nombre de usuario y la contraseña. Los valores específicos de estas variables se definirán más adelante en el proceso.



#!/bin/bash
echo "Login to Docker Hub"
echo "Docker user: $DOCKER_USER"

echo $DOCKER_PASSWORD | docker login --username $DOCKER_USER --password-stdin

buildDocker.sh
Este script crea la imagen de docker usando el comando correspondiente, cabe resaltar que se genera un tag para la imagen y se alamcena temporalmente en un archivo txt para poder usarlo en la siguiente fase, otra forma puede ser como variable de entorno.



#!/bin/bash
echo "Build Docker image"
DOCKER_TAG=$(date +"%Y%m%d%H%M%S")
echo "$DOCKER_TAG" > docker_tag.txt
echo "Docker Tag: $DOCKER_TAG"
echo "Docker user: $DOCKER_USER"
echo "Docker image: $DOCKER_IMAGE"
docker build -t $DOCKER_USER/$DOCKER_IMAGE:$DOCKER_TAG .

pushDocker.sh
Se sube la imagen al repositorio de dockerHub con el tag correspondiente:



#!/bin/bash

echo "Push Docker image"

ls -la

DOCKER_TAG=$(cat docker_tag.txt)

echo "Docker Tag: $DOCKER_TAG"

echo "Docker user: $DOCKER_USER"

echo "Docker image: $DOCKER_IMAGE"

docker push $DOCKER_USER/$DOCKER_IMAGE:$DOCKER_TAG

Creación de proyecto de construcción en AWS CodeBuild.

Dentro de la pantalla de Developer Tools accedemos a CodeBuild para crear el proyecto de construcción, a continuación se adjunta las configuraciones utilizadas:

Debemos conectar nuestro proyecto de GitHub con CodeBuild; durante este proceso, nos solicitarán los permisos necesarios. En la sección de configuración de la fuente, debemos especificar la versión del código indicando la rama correspondiente.

Para que cada commit active la construcción, activa los eventos de webhook. Además, puedes aplicar filtros para que la construcción se desencadene únicamente en cumplimiento de ciertas condiciones específicas.

Configuración de entorno.

Se detallan todas las variables de entorno utilizadas a lo largo de las distintas fases. En este caso, se configuran las siguientes

Nota: Almacenar contraseñas directamente como variables de entorno no es la práctica más segura. Se recomienda utilizar Secret Manager para gestionar y resguardar de manera más segura información sensible como contraseñas

Automáticamente, CodeBuild buscará el archivo de configuración en la raíz del proyecto.

Con esas configuraciones podemos crear el proyecto de CodeBuild.

Ejecución

Después de realizar un commit, el proceso de construcción del artefacto debería iniciarse automáticamente. En caso de no haber configurado el webhook, también es posible iniciar la construcción manualmente.

Al acceder a los detalles de la construcción, podremos observar los logs correspondientes. Si todos los pasos se completan correctamente, la construcción quedará marcada como exitosa.

Verificación de imagen en dockerhub.

Conclusiones

CodeBuild destaca por su eficacia en la construcción y despliegue automatizado de diversos artefactos, simplificando procesos y facilitando la gestión de repositorios correspondientes.
CodeBuild tiene varias integraciones con los servicios de terceros más populares, asi que si tenemos un proyecto en otras teconologías adaptarlo a CodeBuild será muy sencillo.
CodeBuild no solo opera de manera aislada, sino que se integra de manera fluida con servicios clave como CodeCommit, CodeDeploy y CodeArtifact. Esta capacidad de adaptación le permite ser una parte esencial en la creación de pipelines complejos para procesos de entrega continua más sofisticados.

Para saber más pueden revisar los links adjuntados.

Referencias

Implementación de custom Lambda Authorizer para Amazon API Gateway

Kevin Catucuamba — Sun, 05 Nov 2023 23:40:26 +0000

Al desarrollar servicios mediante Amazon API Gateway, es fundamental considerar cómo garantizar la seguridad de nuestros recursos y prevenir el abuso por parte de ciertos usuarios. En el contexto de Amazon API Gateway, existen varias formas de autorizar las solicitudes.

En este breve tutorial, se presentará un ejemplo práctico de cómo asegurar nuestra API Gateway mediante el uso de tokens. Utilizaremos una función Lambda como autorizador, y los tokens serán generados por el servicio de Amazon Cognito, que cuenta con un conjunto de usuarios.

Objetivos del ejemplo:

Implementar los recursos esenciales en AWS utilizando AWS SAM (Serverless Application Model), y validar la correcta creación de estos recursos en la AWS Management Console.
Configurar, a través de una plantilla con especificaciones OpenAPI, todas las medidas necesarias para asegurar una API, garantizando su protección integral.
Demostrar el proceso de autenticación de un usuario a través de Amazon Cognito y cómo enviar el token correspondiente para habilitar la invocación de una API en AWS de manera segura.
Realizar pruebas de la funcionalidad de la función Lambda autorizadora implementada, asegurando su correcto funcionamiento.

En la consola de AWS se visualizarán los recursos que se deben crear, por lo que es importante tener un entendimiento básico de las funciones Lambda y las APIs en AWS.

Lambda Authorizer

Una Lambda Authorizer es un componente del servicio Amazon API Gateway que gestiona el acceso a las APIs y los recursos de backend. Opera antes de que las solicitudes de una API en Amazon API Gateway se procesen y determina si un usuario o una solicitud de aplicación tiene el permiso necesario para acceder a los recursos protegidos.

En este caso, se presentará un ejemplo de una Lambda Authorizer basada en tokens:

1.- Un cliente efectúa una solicitud HTTP hacia un servicio a través de Amazon API Gateway.
2.- Amazon API Gateway transmite la información requerida, incluyendo el token, a la función lambda encargada de la autorización. En esta función, se lleva a cabo la validación del token o acciones necesarias para determinar su validez.

Ejemplo de los datos de entrada:

{
    "type": "TOKEN",
    "methodArn": "arn:aws:execute-api:us-east-1:818802983213:4dxds2wsdf/v1/GET/labs/products",
    "authorizationToken": "Bearer eyJraWQi...."
}

3.- Dentro de la lambda se implementa la lógica necesaria para validar el token y retornar un documento de politica que contiene una lista de declaraciones de políticas, indicando si pemite o deniega el acceso.

Ejemplo de politica generada:

{
    "principalId": "user/unauthorized",
    "policyDocument": {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Action": "execute-api:Invoke",
                "Effect": "Deny",
                "Resource": [
                    "arn:aws:execute-api:us-east-1:00XXXXXXXX00:XXXXXXXXX/v1/GET/labs/products"
                ]
            }
        ]
    },
    "context": {
        "key": "value",
        "number": 1,
        "bool": true
    }
}

4.- Devuelve la política generada a Amazon API Gateway para su evaluación.
5.- En caso de que la política generada permita el acceso al recurso configurado, el acceso al recurso desplegado, que en este caso es una función lambda, es autorizado.

Pool de Usuarios

Un grupo de usuarios (Pool Users) de Amazon Cognito es un directorio de usuarios para la autenticación y autorización de aplicaciones web y móviles. Un pool de usuarios en Amazon Cognito actúa como un repositorio centralizado de usuarios y proporciona funciones de autenticación, autorización y administración de usuarios para sus aplicaciones.

Mayor información en: Grupos de usuarios de Amazon Cognito

Plantilla de SAM para crear un pool de usuarios.

AWSTemplateFormatVersion: "2010-09-09"
Transform: AWS::Serverless-2016-10-31
Description: >
  SAM template for the Cognito resources.

Parameters:
  EnvironmentId:
    Type: String
    Description: Environment Name

  CompanyPrefix:
    Type: String
    Description: "A name for environment id"

Resources:
  SystemsUsersPool:
    Type: AWS::Cognito::UserPool
    Properties:
      UserPoolName : !Join ['-',[!Ref "EnvironmentId"  ,"system-users" ]]
      AdminCreateUserConfig:
        AllowAdminCreateUserOnly: false
      UserPoolTags:
        ORGANIZATION: !Ref CompanyPrefix
      Policies:
        PasswordPolicy:
          MinimumLength: 8
          RequireLowercase: true
          RequireNumbers: true
          RequireSymbols: true
          RequireUppercase: true
      AutoVerifiedAttributes:
        - email
      AliasAttributes:
        - email
      Schema:
        - AttributeDataType: String
          Name: email
          Required: true
          Mutable: true

  ClientAppAuth:
    Type: AWS::Cognito::UserPoolClient
    Properties:
      UserPoolId: !Ref SystemsUsersPool
      GenerateSecret: true
      ReadAttributes:
        - address
        - nickname
        - birthdate
        - phone_number
        - email
        - phone_number_verified
        - email_verified
        - picture
        - family_name
        - preferred_username
        - gender
        - profile
        - given_name
        - zoneinfo
        - locale
        - updated_at
        - middle_name
        - website
        - name

SystemsUsersPool: Este recurso representa un grupo de usuarios en Cognito. Este recurso se utiliza para crear un grupo de usuarios con configuraciones específicas, como políticas de contraseña y atributos permitidos.

ClientAppAuth: Es un recurso que representa una aplicación cliente que se autentica con el grupo de usuarios creado anteriormente. Este recurso define las propiedades de la aplicación cliente, como los atributos que se pueden leer y si se debe generar un secreto para la autenticación.

En el servicio de Amazon Cognito se puede observar los grupos de usuarios creados:

Por defecto, el grupo de usuarios recién creado no incluirá a ningún usuario. Para agregar uno, se debe crear un nombre de usuario, proporcionar una dirección de correo electrónico y establecer una contraseña que cumpla con la política especificada.

Una vez que se ha creado el usuario, este se encontrará en un estado en el que debe cambiar su contraseña. Para confirmar la creación del usuario, se puede utilizar el siguiente comando:

aws cognito-idp admin-set-user-password --user-pool-id us-east-1_7W6X0n6v0 --username userdemo --password kevin??890KZNA --permanent

Para conocer más comandos disponibles visitar: cognito-idp

En este escenario, ya existen usuarios registrados y preparados para autenticarse y generar tokens.

Nota: Para ejecutar este comando, es necesario configurar las credenciales en el archivo "credentials" de AWS.

Configuración en especifiación

Es importante tener en cuenta que es necesario configurar la propiedad "securitySchemes" a nivel de la especificación dentro de los componentes.

Tener en cuenta que se configuran dos partes: "api_key" y "authorizer". El último es el encargado de validar el token dentro de la función lambda autorizadora..

  securitySchemes:
    api_key:
      type: apiKey
      in: header
      name: x-api-key
      description: 'API key or aborts with Unauthorized'
    authorizer:
      type: apiKey
      in: header
      name: Authorization
      description: 'Token JWT para el consumo del API.'
      x-amazon-apigateway-authtype: custom
      x-amazon-apigateway-authorizer:
        type: token
        identitySource: v1
        authorizerUri:
          Fn::Sub: arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:${LambdaAuthorizer}:production/invocations
        authorizerResultTtlInSeconds: 3000
        identityValidationExpression: ^Bearer [-0-9a-zA-z\.]*$

A nivel de cada endpoint, es esencial garantizar que se utilicen esos esquemas de seguridad.

Una vez que la API se haya desplegado con estas configuraciones, se podrá verificar los cambios en la consola de AWS:

Ejemplo de código

Autenticación de usuario:

Un ejemplo para autenticar a un usuario de nuestro pool es el siguiente código en Node.js:

Command file

import {EnvUtil} from "../utils/env.util";
import {CognitoIdentityProviderClient, InitiateAuthCommand} from "@aws-sdk/client-cognito-identity-provider";
import {AuthLoginResponse, AuthUserCredentials} from "../models/auth-login.model";
import {loggerUtil as log} from "../utils/logger.util";
import crypto from "crypto";
import {HttpStatusCode} from "axios";
export const LogInCommandExecutor = async (authUserCredentials: AuthUserCredentials): Promise<AuthLoginResponse> => {

    const [region, clientId, secretClient] = EnvUtil.getObjectEnvVarOrThrow(
        ['AUTH_AWS_REGION', 'AUTH_CLIENT_ID', 'AUTH_SECRET_CLIENT']);

    const {username, password} = authUserCredentials;

    const client = new CognitoIdentityProviderClient({region});

    const hash = crypto.createHmac('sha256', secretClient).update(`${username}${clientId}`).digest('base64');

    const command = new InitiateAuthCommand({
        AuthFlow: "USER_PASSWORD_AUTH",
        ClientId: clientId,
        AuthParameters: {
            USERNAME: username,
            PASSWORD: password,
            SECRET_HASH: hash
        }
    });

    try {
        const response = await client.send(command);
        if (!response.AuthenticationResult && response.ChallengeName === "NEW_PASSWORD_REQUIRED") {
            return {
                statusMessage: "It is necessary to change the password",
                credentials: null
            }
        }
        return {
            statusMessage: "Authentication successful",
            credentials: {
                idToken: response.AuthenticationResult.IdToken,
                accessToken: response.AuthenticationResult.AccessToken,
                refreshToken: response.AuthenticationResult.RefreshToken
            }
        }


    } catch (error) {
        const errorResponse = {
            status: 500,
            body: "Hay muchos errores",
            headers: {
                "Content-Type": "application/json",
            }
        }
        throw new Error(HttpStatusCode.InternalServerError.toString());
    } finally {
        client.destroy();
    }


}

En términos generales, este código realiza la autenticación de un usuario en Cognito utilizando su dirección de correo y contraseña. Utiliza el SDK de Cognito para Node.js y recupera todas las variables de entorno necesarias para llevar a cabo la autenticación:

región: La región en la que se ha desplegado el grupo de usuarios.
clientId: Un identificador único para el cliente de integración.
secretClient: Es una cadena constante que nuestra aplicación debe incluir en todas las solicitudes de API al cliente de la aplicación..

Puedes obtener esta información en la pestaña "App Integration" de Amazon Cognito:

Para obtener más información de las diferentes acciones que se puede realizar, vistiar: API Reference Cognito - Actions

Verificación de token:

Dentro de la función lambda autorizadora, es esencial verificar la validez del token recibido. Si el token es válido, la función debe devolver una política que indique si se permite o deniega el acceso al recurso. La lógica puede ser la siguiente (Node.js):

import {APIGatewayAuthorizerResult, APIGatewayTokenAuthorizerEvent} from "aws-lambda";
import {CognitoJwtVerifier} from "aws-jwt-verify";

const AWS_ACCOUNT = process.env.AUTH_AWS_ACCOUNT_ID;
const AWS_REGION = process.env.AUTH_AWS_REGION;

export class KcUtil {

    static ALLOW_TEXT = "Allow";
    static DENY_TEXT = "Deny";
    static PRINCIPAL_ID = "user|kcatucuamba";

    static async validateToken(token: string): Promise<boolean> {

        const userPoolId = process.env.AUTH_USER_POOL_ID;
        const clientId = process.env.AUTH_CLIENT_ID;

        const verifier = CognitoJwtVerifier.create({
            userPoolId,
            tokenUse: "access",
            clientId
        });

        token = token.replace("Bearer ", "");

        try {
            const response = await verifier.verify(token as any);

            return true;
        }catch (e) {
            return false;
        }

    }

    static async generatePolicy(event: APIGatewayTokenAuthorizerEvent): Promise<APIGatewayAuthorizerResult> {

        const isTokenFailed = !(await KcUtil.validateToken(event.authorizationToken));

        if (isTokenFailed) {
            return await KcUtil.createPolicy("user/unauthorized", KcUtil.DENY_TEXT, event.methodArn);
        }

        const resource = "arn:aws:execute-api:" + AWS_REGION + ":" + AWS_ACCOUNT + ":*/*/*/*";
        return await KcUtil.createPolicy(KcUtil.PRINCIPAL_ID, KcUtil.ALLOW_TEXT, resource);
    }


    static async createPolicy(
        principalId: string,
        effect: string,
        resource: string): Promise<APIGatewayAuthorizerResult> {
        return {
            principalId: principalId,
            policyDocument: {
                Version: '2012-10-17',
                Statement: [
                    {
                        Action: 'execute-api:Invoke',
                        Effect: effect,
                        Resource: [resource]
                    }
                ]

            },
            context: {
                key: 'value',
                number: 1,
                bool: true
            }
        };

    }
}

Se adjunta el archivo package.json que especifica las dependencias utilizadas tanto para la lambda autorizadora como para la generación del token:

  "devDependencies": {
    "@types/aws-lambda": "^8.10.114",
    "@types/axios": "^0.14.0",
    "@types/jsonwebtoken": "^9.0.2",
    "@types/jwk-to-pem": "^2.0.1",
    "@types/node": "^18.15.11",
    "aws-lambda": "^1.0.7",
    "aws-sdk": "^2.1409.0",
    "ts-node": "^10.9.1",
    "typescript": "^5.0.3"
  },
  "dependencies": {
    "@aws-sdk/client-cognito-identity-provider": "^3.363.0",
    "aws-jwt-verify": "^4.0.0",
    "axios": "^1.4.0",
    "crypto": "^1.0.1",
    "jsonwebtoken": "^9.0.0",
    "jwk-to-pem": "^2.0.5",
    "winston": "^3.8.2"
  }

Verificando funcionalidad

Token:

Generamos el token (accessToken) utilizando otra API de Amazon y funciones lambda en este caso:

1.- Enviando token inválido

En primer lugar, llevamos a cabo una prueba sin enviar un token válido. Dependiendo de la configuración de la API, esta responderá con un mensaje de error en este caso:

Verificamos la traza generada:

Es claro que la validación se lleva a cabo exclusivamente en la función lambda autorizadora, y no se intenta acceder al endpoint en sí, ya que el token ha fallado. Como resultado, se ha generado una política denegada para el recurso que se intentaba acceder a través de API Gateway.

Enviando token válido

Si enviamos el token previamente generado (accessToken), la API debería realizar una llamada a la función lambda autorizadora. Si la validación es exitosa, la API ejecutará y permitirá el acceso a los recursos configurados, que en este caso también son funciones lambda.

Verificamos la traza:

La sección anaranjada indica que el token ha sido validado con éxito en la función lambda autorizadora, lo que permite el acceso al recurso requerido, en este caso, una lambda que realiza una consulta de productos.

Si se envía nuevamente una solicitud con el mismo token, ocurre algo interesante:

Se observa que no se lleva a cabo la validación en la función lambda autorizadora. Esto se debe a la configuración de una caché de una hora. Es decir, como el token previamente se había verificado y resultó válido, se almacena en la caché durante ese período y no se vuelve a verificar en las siguientes solicitudes. Esta estrategia es beneficiosa en términos de tiempo de respuesta, ya que no sería eficiente realizar la validación en cada petición.

Conclusiones

La función lambda autorizadora es independiente del lenguaje o la tecnología utilizada, lo que demuestra la flexibilidad y facilidad para implementar estos esquemas de seguridad con las herramientas permitidas por AWS.
Es esencial tener en cuenta el tiempo de caché de la función lambda autorizadora, el cual debe adaptarse a la duración del token. En este ejemplo, se ha configurado una duración de una hora debido a la vigencia del token.
La configuración de seguridad implementada aquí es una de las más simples disponibles. Se recomienda consultar la documentación oficial para implementar técnicas de seguridad más avanzadas.

Referencias

Desplegar funciones Lambdas usando Layers con Java

Kevin Catucuamba — Sun, 22 Jan 2023 20:54:45 +0000

El servicio de AWS Lambas ofrece una gran variedad de configuraciones, con el objetivo de minimizar costos, optimizar código y mejorar tiempos de respuesta. En esta ocasión se hará uso de Layers para centralizar las dependencias/libs (jars) en un solo lugar, y que todas las lambdas desplegadas puedan acceder a esa configuración donde se almacenan las dependencias.

Layers o Capas AWS Lambda

AWS Lambda Layers es una característica de AWS Lambda que permite a los desarrolladores empaquetar y reutilizar código común en múltiples funciones. Esta característica se puede utilizar para compartir bibliotecas de código, tiempos de ejecución personalizados y otras dependencias entre funciones, lo que puede simplificar el proceso de desarrollo y reducir el tamaño de los paquetes de implementación.

Uno de los principales beneficios de utilizar Layers en Lambda es que permite a los desarrolladores separar el código de las dependencias, esto permite actualizar las dependencias en un solo lugar y no tener que hacerlo en cada función, esto también reduce el tamaño de los paquetes de implementación ya que las dependencias no se incluyen en cada función.

La imagen proporcionada por DZone sobre Layers en Lambdas es super simple de entender. Con el uso de Lambda Layers podemos centralizar todas las dependencias en un solo lugar, y las definiciones de las funciones lambdas deben tener la capacidad de consumir dicho repositorio para realizar las tareas sin problemas, además de que el tamaño de las funciones van a ser muy ligeras.

Ejercicio AWS Lambda Layers

Para mostrar el uso de Lambda Layers se usa un proyecto dummy en Java con dos lambdas para desplegar con la ayuda de SAM CLI.

Nota: Este ejercicio se ha realizdo en un SO Linux (Mint).

Configuración de Layers

Para configurar un Layer se usa las plantillas de AWS CloudFormation con la extensión del framework SAM, el tipo de recurso a crear es AWS::Serverless::LayerVersion.

Resources:
  LabsLayer:
    Type: AWS::Serverless::LayerVersion
    Properties:
      LayerName: !Sub ${AWS::StackName}-LabsLayer
      Description: Layer libs for kc-labs-serverless
      ContentUri: kc-labs-app/dependencies
      CompatibleRuntimes:
        - java11
        - java8
      CompatibleArchitectures:
        - x86_64
      LicenseInfo: "MIT"
      RetentionPolicy: Retain
...
...

En las definiciones de las funciones lambdas se debe vincular el layer creado:

Nota: Se configura la propiedad Metadata para personalizar la construcción del empaquetado de las funciones lambdas.

Librerías de proyecto en pom.xml

Para este ejercicio se tienen algunas dependencias usadas en el proyecto de Lambdas.

Makefile

En la raiz del proyecto de Java se debe crear un archivo Makefile:

build-lambda:
    cp -rf ./target/classes/* $(ARTIFACTS_DIR)/

build-LabsGreetingsGETHelloLambda: build-lambda

build-LabsGreetingGETNameLambda: build-lambda

Dentro de ese archivo se configura el comando para copiar las definiciones de nuestras clases, ahí estarán los handlers/manejadores de entrada para las lambdas. En este caso se tiene dos lambdas, se debe configurar con el nombre lógico para cada lambda.

Construir proyecto

Dentro de la raíz del proyecto Java se ejecutan los siguiente comandos.

Para construir el empaquetado del proyecto:

mvn clean package

Para obtener todas las dependencias (jars) usadas en el proyecto en una carpeta:

mvn dependency:copy-dependencies -DoutputDirectory=dependencies/java/lib -Dmdep.prependGroupId=true -DexcludeScope=provided

Nota: Verificar que la carpetas target y dependencies/java/lib hayan sido creadas.

Nota: Verificar la ruta de la capa, para cada runtime es diferente: Layer dependecies.

Un directorio más atrás donde esta definido el archivo template.yaml ejecutar el comando:

sam build

Finalmente para desplegar usar el comando:

sam deploy o sam deploy --guided si es un primer despliegue.

Resultados

Una vez desplegado el stack se puede verificar las lambdas desde la consola de Lambda en la sección Code:

Se puede verificar que la lambda pesa muy poco, esto debido a que no se esta incluyendo las dependencias jars para cada lambda.

Se verifica la creación del layer:

Con la creación de este layer todas las lambdas tienen la posibilidad de acceder a este recurso para consumir las dependencias que se hayan subido.

Conclusiones

AWS Lambda Layers es una característica poderosa que permite a los desarrolladores reutilizar código y dependencias en múltiples funciones, lo que simplifica el proceso de desarrollo y reduce el tamaño de los paquetes de implementación.
Esta característica también permite actualizar las dependencias en un solo lugar y compartir código entre múltiples funciones, esto ayudaría a la escalabilidad de la aplicación debido a que se puede tener diferentes capas para cada responsabilidad y las lógicas de negocio aisladas del handler principal.
Si la capa layer es bastante pesada es considerable usar un bucket de S3 y referenciar ese bucket en la creación del Layer.

Referencias

Validación de Api Gateway con OpenAPI

Kevin Catucuamba — Mon, 16 Jan 2023 05:23:28 +0000

La validación de AWS API Gateway con OpenAPI es una práctica recomendada para garantizar que las peticiones y respuestas cumplen con los estándares esperados. OpenAPI, también conocido como Swagger, es un estándar abierto para describir y documentar APIs. Al utilizar OpenAPI en conjunto con AWS API Gateway, se pueden validar automáticamente las peticiones y respuestas y garantizar que solo se procesan las que cumplen con los estándares esperados.

OpenAPI

Es un estándar para describir la estructura de una API, incluidos los endpoints (puntos finales URL), los formatos de solicitud y respuesta y las operaciones HTTP (GET, POST, PUT, etc) que se implementa en una API generalmente. Este documento también llamado Swagger utiliza el formato JSON o YAML para definir una API. Para más información revisar: OpenAPI

API Gateway y OpenAPI

El servicio API Gateway de AWS es compatible con la especificación OpenAPI, esto permite estructurar información de la API, puntos finales, autorizadores (token y api-keys), esquemas y validar entradas que se realizan.

La validación de las peticiones en AWS API Gateway se puede realizar utilizando los esquemas definidos en el archivo OpenAPI. Los esquemas especifican el formato esperado de las peticiones, incluyendo los parámetros de la URL, los encabezados y el cuerpo de la petición. Al utilizar estos esquemas, se pueden validar automáticamente las peticiones para garantizar que cumplen con los estándares esperados.

Funcionamiento API Gateway

Todo empieza cuando un cliente realiza una petición (GET para este ejemplo) hacia nuestra Api Gateway. Api Gateway lo que hace es crear un objeto json típico de una petición HTTP, y mediante una integración que se especifica en la plantilla OpenApi, realiza un POST a un servicio de AWS (una lambda para este caso). Esto ejecuta la lambda y realiza la transacción, para el retorno de los datos se debe modelar como una respuesta HTTP válida, esto para que lo transforme Api Gateway y pueda retornar la solicitud HTTP de manera exitosa. Mediante la especificación de Open API la idea es realizar una validación a nivel de ese Api Gateway y no en la lambda.

Escenario a probar

Para este caso se valida algunos endpoints implementados en API Gateway, estos endpoints mandan a llamar una función lambda. La configuración de la plantilla del stack y de open api es independiente del lenguaje que se use, para este caso se usa Java.

Código Actual

Se muestra las funciones lambdas en Java para esta prueba:

Función para recuperar todos los clientes:

package com.kc.cloud.labs.aws.lambda.customers;

import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyRequestEvent;
import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyResponseEvent;
import com.kc.cloud.labs.aws.lambda.customers.models.Customer;
import com.kc.cloud.labs.aws.lambda.customers.services.CustomerService;
import java.util.HashMap;
import java.util.List;
import java.util.logging.Logger;

public class LabsCustomersGETAll implements RequestHandler
        <APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent> {

    private static final Logger logger = Logger.getLogger(LabsCustomersGETAll.class.getName());

    @Override
    public APIGatewayProxyResponseEvent handleRequest(APIGatewayProxyRequestEvent input, Context context) {
        APIGatewayProxyResponseEvent response = new APIGatewayProxyResponseEvent();
        logger.info("LabsCustomersGETAll.handleRequest() invoked");
        List<Customer> customers = CustomerService.getAllCustomers();
        response.setHeaders(getHeaders());
        response.setBody(getBody(customers));
        response.setStatusCode(200);
        return response;
    }

    public String getBody(List<Customer> customers){
        StringBuilder customersJson = new StringBuilder("[");
        for (Customer customer : customers) {
            customersJson.append(customer.toJSON()).append(",");
        }
        customersJson.deleteCharAt(customersJson.length() - 1);
        customersJson.append("]");
        return customersJson.toString();
    }

    public HashMap<String, String> getHeaders() {
        HashMap<String, String> headers = new HashMap<>();
        headers.put("Content-Type", "application/json");
        headers.put("X-Custom-Header", "application/json");
        return headers;
    }
}

Función para recuperar un Cliente por id:

package com.kc.cloud.labs.aws.lambda.customers;

import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyRequestEvent;
import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyResponseEvent;
import com.kc.cloud.labs.aws.lambda.customers.models.Customer;
import com.kc.cloud.labs.aws.lambda.customers.services.CustomerService;

import java.util.HashMap;
import java.util.logging.Logger;

public class LabsCustomersGETById implements RequestHandler
        <APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent> {

    private static final Logger logger = Logger.getLogger(LabsCustomersGETById.class.getName());

    @Override
    public APIGatewayProxyResponseEvent handleRequest(APIGatewayProxyRequestEvent input, Context context) {

        logger.info("LabsCustomersGETById.handleRequest() invoked");

        String id = input.getPathParameters().get("id");
        Customer customer = CustomerService.getCustomerById(Integer.parseInt(id));

        if (customer == null) {
            return new APIGatewayProxyResponseEvent()
                    .withStatusCode(404)
                    .withBody("{\"message\": \"Customer not found\"}");
        }

        return new APIGatewayProxyResponseEvent()
                .withStatusCode(200)
                .withHeaders(getHeaders())
                .withBody(customer.toJSON());
    }

    public HashMap<String, String> getHeaders() {
        HashMap<String, String> headers = new HashMap<>();
        headers.put("Content-Type", "application/json");
        headers.put("X-Custom-Header", "application/json");
        return headers;
    }

}

Función para crear un Cliente

package com.kc.cloud.labs.aws.lambda.customers;

import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyRequestEvent;
import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyResponseEvent;
import com.kc.cloud.labs.aws.lambda.customers.models.Customer;
import com.kc.cloud.labs.aws.lambda.customers.services.CustomerService;

import java.util.HashMap;
import java.util.logging.Logger;


public class LabsCustomersPSTCreate implements RequestHandler
        <APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent> {

    private static final Logger logger = Logger.getLogger(LabsCustomersPSTCreate.class.getName());


    @Override
    public APIGatewayProxyResponseEvent handleRequest(APIGatewayProxyRequestEvent input, Context context) {
        logger.info("LabsCustomersPSTCreate.handleRequest() invoked");
        String body = input.getBody();
        Customer customerCreated = CustomerService.createCustomer(body);
        return new APIGatewayProxyResponseEvent()
                .withStatusCode(201)
                .withHeaders(getHeaders())
                .withBody("{\"message\": \"Customer created\", \"customerId\": \"" + customerCreated.getId() + "\"}");
    }

    public HashMap<String, String> getHeaders() {
        HashMap<String, String> headers = new HashMap<>();
        headers.put("Content-Type", "application/json");
        headers.put("X-Custom-Header", "application/json");
        return headers;
    }
}

Plantilla para crear el stack SAM yaml

Se tiene una API con tres endpoints una para listar todos los clientes, obtener un cliente y crear un cliente, la idea es validar las solicitudes que se realizan utilizando la especificación Open API que se está hablando.

Se muestra la plantilla SAM para desplegar el stack:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
  kc-labs-serverless
  Sample SAM Template 

Globals:
  Function:
    CodeUri: kc-labs-app
    Timeout: 20
    Tracing: Active
    Runtime: java11
    MemorySize: 512
    Architectures:
      - x86_64
  Api:
    TracingEnabled: True

Resources:
  ApiGatewayApi:
    Type: AWS::Serverless::Api
    Properties:
      StageName: v1
      DefinitionBody:
        Fn::Transform:
          Name: AWS::Include
          Parameters:
            Location: ./specs/open_api.yaml

  LabsCustomersGETAllLambda:
    Type: AWS::Serverless::Function
    Properties:
      Handler: com.kc.cloud.labs.aws.lambda.customers.LabsCustomersGETAll::handleRequest
      FunctionName: !Sub ${AWS::StackName}-LabsCustomersGETAll
      Environment:
        Variables:
          PARAM1: VALUE
          JAVA_TOOL_OPTIONS: -XX:+TieredCompilation -XX:TieredStopAtLevel=1
      Events:
        EventApiLabsCustomersGETAll:
          Type: Api
          Properties:
            Path: /labs/customers
            Method: get
            RestApiId: !Ref ApiGatewayApi

  LabsCustomersGETByIdLambda:
    Type: AWS::Serverless::Function
    Properties:
      Handler: com.kc.cloud.labs.aws.lambda.customers.LabsCustomersGETById::handleRequest
      FunctionName: !Sub ${AWS::StackName}-LabsCustomersGETById
      Environment:
        Variables:
          PARAM1: VALUE
          JAVA_TOOL_OPTIONS: -XX:+TieredCompilation -XX:TieredStopAtLevel=1
      Events:
        EventApiLabsCustomersGETById:
          Type: Api
          Properties:
            Path: /labs/customers/{id}
            Method: get
            RestApiId: !Ref ApiGatewayApi

  LabsCustomersPSTCreateLambda:
    Type: AWS::Serverless::Function
    Properties:
      Handler: com.kc.cloud.labs.aws.lambda.customers.LabsCustomersPSTCreate::handleRequest
      FunctionName: !Sub ${AWS::StackName}-LabsCustomersPSTCreate
      Environment:
        Variables:
          PARAM1: VALUE
          JAVA_TOOL_OPTIONS: -XX:+TieredCompilation -XX:TieredStopAtLevel=1
      Events:
        EventApiLabsCustomersPSTCreate:
          Type: Api
          Properties:
            Path: /labs/customers
            Method: post
            RestApiId: !Ref ApiGatewayApi

Tomar en cuenta que se crea el recurso para desplegar una Api en AWS, y se especifica la plantilla de Open API para que pueda tomar esa configuración al momento de realizar el despliegue:

Nota: Toda esa implementación de OpenAPI puede ir en la misma plantilla SAM, pero es conveniente separarlo, ya que generalmente la plantilla de OpenAPI es grande.

Se muestra a continuación la plantilla OpenAPI utilizada.

openapi: 3.0.1
info:
  title: 
    Fn::Sub: Labs Validate Request - ${AWS::StackName} 
  version: 1.0.0
  description: |
    This API validates the request body and returns the request body as a response.
    This API is used for testing the API Gateway Labs.

x-amazon-apigateway-request-validators:
  all:
    validateRequestBody: true
    validateRequestParameters: true
  params-only:
    validateRequestBody: false
    validateRequestParameters: true

paths: 
  /labs/customers:
    get:
      summary: Get all customers
      description: Get all customers
      operationId: LabsCustomersGETAllLambda
      responses:
        200:
          description: OK
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/Customer'
      x-amazon-apigateway-integration:
        type: aws_proxy
        timeoutInMillis: 20000
        httpMethod: POST
        uri:
          Fn::Sub: arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${LabsCustomersGETAllLambda.Arn}/invocations
        responses:
          default:
            statusCode: 200

    post:
      summary: Get a customer by ID
      description: Get a customer by ID
      operationId: LabsCustomersPSTCreateLambda
      x-amazon-apigateway-request-validator: all
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/Customer'


      responses:
        201:
          description: OK
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Customer'
      x-amazon-apigateway-integration:
        type: aws_proxy
        timeoutInMillis: 20000
        httpMethod: POST
        uri:
          Fn::Sub: arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${LabsCustomersPSTCreateLambda.Arn}/invocations
        responses:
          default:
            statusCode: 201


  /labs/customers/{id}:
    get:
      summary: Get a customer by ID
      description: Get a customer by ID
      operationId: LabsCustomersGETByIdLambda
      x-amazon-apigateway-request-validator: params-only
      parameters:
        - name: id
          in: path
          description: Customer ID
          required: true
          schema:
            type: integer
            minimum: 1
        - name: custom
          in: header
          description: custom
          required: true
          schema:
            type: boolean
        - name: page
          in: query
          description: Page number
          required: true
          schema:
            type: integer
      responses:
        200:
          description: OK
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Customer'
      x-amazon-apigateway-integration:
        type: aws_proxy
        timeoutInMillis: 20000
        httpMethod: POST
        uri:
          Fn::Sub: arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${LabsCustomersGETByIdLambda.Arn}/invocations
        responses:
          default:
            statusCode: 200

components:
  schemas:
    Customer:
      type: object
      properties:
        id:
          type: integer
        fullName:
          type: string
        isPremium:
          type: boolean
      required:
        - id
        - fullName
        - isPremium

Nota: En las plantillas OpenAPI también podemos usar las funciones intrínsecas para inyectar valores de los recursos o del mismo stack.

A continuación se detalla cada una de las partes de esta plantilla mostrada anteriormente:

Información general de la API

Se detalla la información general de la API que se está implementado como el título, la descripción y la versión:

Exensiones para validar las solicitudes

AWS ofrece algunas extensiones que se usan con el estándar OpenAPI y para validar la data entrante de usa x-amazon-apigateway-request-validators, para más información consultar OpenAPI extensiones:

all: Indica que la validación lo hace en el cuerpo de la solicitud y en los parámetros (headers, paths y queries)
params-only: Solo válida los parámetros

Configuración de los endpoints

En esta parte se define los puntos finales, el tipo de solicitud, información general y mediante la extensión x-amazon-apigateway-integration se puede anexar la función lambda a utilizar.

Obtener todos los clientes:

Para este caso no se realiza ninguna validación en la solicitud, simplemente se configura información general del endpoint, las respuestas esperadas y la integración con el servicio de AWS.

Nota: La parte del esquema $ref: '#/components/schemas/Customer', hace referencia a un modelo de dato que se lo define en el mismo documento OpenAPI por lo general aunque se puede tener por archivos separados.

Crear un cliente:

Para este caso se valida el cuerpo de la solicitud y los parámetros.

Obtener un cliente por ID:

Para este caso se valida los parámetros de la solicitud, en este caso se tiene path, header y una query que todas son obligatorias.

Componentes

Los componentes son una manera de modelar datos y ser referenciadas para validar entrada de datos, tomar en cuenta que en este caso todos los campos son obligatorios.

Despliegue de Stack

Una vez realizadas esas configuraciones en las plantillas y creadas las funciones se puede desplegar el stack usando SAM.

sam build
sam deploy
Si es un nuevo stack:
sam deploy --guided

Probando funcionalidad

Después podemos probar los endpoints y ver si la especificación de OpenAPI realizada esta funcionando de manera adecuada:

Obtener todos los clientes:

Recordar que para el endpoint de obtener todos los clientes no se configuró ninguna validación, por lo que funciona sin problemas.

Obtener un cliente por ID:

Para este caso recordar que se configuró la validación a nivel de parámetros, en este caso para los tres tipos, en headers, paths y queries.

Si se enviá todas esas configuraciones la ejecución de la API lo realiza sin problemas.

Pero si faltan algunos de los puntos que son requeridos la petición es rechazada:

Esto quiere decir que la falla fue a nivel de la API Gateway y la lambda nunca ha sido llamada, eso se lo puede comprobar en X-RAY:

Crear un cliente:

Para este caso la validación era en ambos casos, sin embargo solo se envía un cuerpo en la solicitud, que es la información del cliente, se envía un body válido y se ejecuta sin problemas:

Si se envía un campo con un tipo de dato que no está registrado en el componente Customer, la ejecución no lo realiza correctamente:

Conclusiones

AWS API Gateway con OpenAPI es una excelente manera de garantizar que las peticiones y respuestas cumplen con los estándares esperados y de documentar de forma automatizada la API.
Al utilizar OpenAPI en conjunto con AWS API Gateway, se pueden validar automáticamente las peticiones y respuestas, lo que ayuda a aumentar la confianza en la API y a disminuir los errores.
No todas las propiedades del esquema OpenAPI son compatibles, en este caso la validación lo realiza solo verificando si el campo requerido efectivamente viene en la solicitud, sin embargo otras propiedades como el maximum o minimum solo se coloca por temas de documentación.

Referencias.

Probando SnapStart en funciones lambdas

Kevin Catucuamba — Fri, 16 Dec 2022 18:53:26 +0000

SnapStart mejora el coldstart de las ejecuciones de las funciones lambdas en AWS, la documentación de esta configuración especifica que se puede mejorar hasta 10 veces el tiempo de inicialización sin costo adicional y sin cambios en el código de la función, se puede usar para mejorar el levantamiento de entornos pesados o que hacen uso de frameworks como Spring o Quarkus.

¿Qué es coldstart en funciones lambdas?

El término "cold start" o "inicio en frío" en funciones lambda se refiere a la situación en la que la lambda es invocada por primera vez después de un período prolongado sin haber sido llamada por ningún cliente. En este caso, la función lambda necesita más tiempo para configurar el entorno de ejecución o el contenedor y poder ejecutar la acción solicitada. Esta demora puede resultar una mala experiencia para los usuarios que consumen la función.

Consideraciones para SnapStart

A la fecha que se escribe este post existen algunas consideraciones que debe tener en cuenta al momento de configurar SnapStart en nuestras funciones lambdas.

Soporte para java 11
Soporte para arquitecturas x86_64 (no arm64)
No soporta la activación de tracing para la función lambda

Planteamiento del problema

Para probar SnapStart funcionando se toma como referencia una función que se demora alrededor de 5 segundos en inicializar por primera vez, luego se implementa SnapStart y se compara resultados, se realiza pruebas de cargas relativamente pequeñas para ver su comportamiento en ambos escenarios. La función a probar es de tipo GET reservada, pero a grandes rasgos lo que hace es consultar información desde una base de datos relacional, validar la información que entra y sale, entre algunas otras ejecuciones.

Escenario sin SnapStart

Primero se realiza un consumo directo desde la consola de Lambda para verificar tiempos de respuesta:

Vemos que el tiempo de inicialización de la función es un poco más de 5 segundos y de 1.8 segundos ejecutando el código.

Prueba de carga con Jmeter

Configuración de Jmeter para ambos casos:

Se realiza una prueba de carga usando Jmeter para poder visualizar las inicializaciones en coldstart, esto lo verificamos realizando una consulta en Logs Insights de AWS:

Se puede verificar que con la configuración de Jmeter mostrada anteriormente se pudo generar 100 inicios en frío (cold start).

La consulta que se utilizó en Logs Insights para ambos casos es la siguiente:

filter @type = "REPORT"
  | parse @log /\d+:\/aws\/lambda\/(?<function>.*)/
  | parse @message /Restore Duration: (?<restoreDuration>.*) ms/
  | stats
count(*) as invocations,
pct(@duration+coalesce(@initDuration,0)+coalesce(restoreDuration,0), 50) as p50,
pct(@duration+coalesce(@initDuration,0)+coalesce(restoreDuration,0), 90) as p90,
pct(@duration+coalesce(@initDuration,0)+coalesce(restoreDuration,0), 99)as p99,
pct(coalesce(@initDuration,0)+coalesce(restoreDuration,0), 50) as pi50,
pct(coalesce(@initDuration,0)+coalesce(restoreDuration,0), 90) as pi90,
pct(coalesce(@initDuration,0)+coalesce(restoreDuration,0), 99) as pi99
group by function, (ispresent(@initDuration) or ispresent(restoreDuration)) as coldstart
  | sort by coldstart desc

Escenario con SnapStart

Lo primero será configurar SnapStart para esta función, para ello en configuración general de la función editar la parte donde dice SnapStart:

Se debe crear una nueva versión de la lambda, y el alias que se tenga debe apuntar a la nueva versión. Al crear una nueva versión se podrá notar que toma algo de tiempo, esto debido a que está preparando la imagen y almacenándola en caché para poder utilizarla cuando se invoque por primera vez. Podremos verificar que en los logs de CloudWatch empieza a ejecutarse algunas acciones de configuraciones:

En la configuración general de la nueva versión se debe poder observar activado el SnapStart:

De igual manera se realiza una prueba directa en la consola de lambda para verificar tiempos de respuesta.

Se observa que con SnapStart activado el tiempo de inicialización bajo de 5 segundos a menos de un segundo, validando de esta manera la funcionalidad de SnapStart, sin embargo se aprecia que la duración de la ejecución del código se demora un poco más, dando como resultado la facturación más elevada.

Prueba de carga

De igual manera se realiza pruebas de carga para poder sacar tiempos en inicio en ColdStart obteniendo los siguientes resultados:

Con la misma configuración de Jmeter mostrada en el primer escenario se genera 101 invocaciones en frío, se observa que los tiempos de inicialización han mejorado notablemente a menos de un segundo, entonces SnapStart está funcionando de manera adecuada.

Conclusiones

Los inicios en frío con SnapStart mejoran notablemente, según los resultados arrojados en Logs Insights de CloudWatch, mejoró 15 veces la inicialización de la lambda, ¡fantástico!.
Parecería que cuando se activa SnapStart, la duración de ejecución de código se demora un poco más, eso se lo puede notar claramente cuando ejecutamos la lambda directamente desde la consola.
SnapStart cumple con lo que dice en cuanto a tiempos de inicialización de la lambda, personalmente veo una característica muy potente que seguramente se irá mejorando con el tiempo y dando soporte a otras plataformas y versiones.

Referencias

Despliegue Canary en funciones lambdas

Kevin Catucuamba — Mon, 05 Dec 2022 06:44:53 +0000

En esta ocasión se realizará un ejemplo sencillo para comprender los fundamentos de un despliegue Canario usando servicios de AWS, este tipo de despliegue está siendo muy usado en la industria por el crecimiento de serverless y contenedores.

¿Qué es el despliegue de tipo Canary?

El despliegue Canary consiste en desplegar nuevas versiones de software de manera incremental, es decir, durante un tiempo una porción de usuarios acceden a la nueva versión desplegada y otro grupo de usuarios siguen consumiendo a la versión anterior, los usuarios sirven como carnada para consumir los servicios e indicar que todo está marchando bien y esto permite seguir incrementando de forma gradual a la última versión desplegada. Si durante el uso existe un error, se realiza un rollback dejando en la versión anterior y sin afectar a los demás usuarios.

Ejemplo práctico

Para el ejemplo práctico se crea dos funciones lambdas y se usa el servicio de Api Gateway para poder realizar pruebas mediante Postman y evidenciar el despliegue incremental Canary.

Requisitos previos

Cuenta de AWS y tener configurado AWS CLI y SAM CLI
Conocimientos esenciales cloudformation, lambdas y api gateway
Manejo de Postman y Jmeter
NodeJs con typescript

Inicio de proyecto

Se inicia el proyecto a partir de una plantilla básica proporcionada en SAM CLI, ejecutando el siguiente comando:

sam init

Seguir las instrucciones

Se genera un proyecto básico de un hello world, se borra la entrada principal app.ts y todos los test. Se crea una estructura de carpetas de la siguiente manera:

Nota: la carpeta hello-world ahora es app.

En el directorio donde está definido el package.json instalar las dependencias:

npm install

A continuación se muestra el código de ejemplo de cada función, no se está conectando a ninguna base de datos para este ejemplo, pero ya depende de lo que necesitemos, el objetivo es demostrar el despliegue:

createCustomer.ts

import { APIGatewayProxyEvent, APIGatewayProxyResult } from 'aws-lambda';
import { Customer } from '../models/Customer';

export const handler = async (event: APIGatewayProxyEvent): Promise<APIGatewayProxyResult> => {
    const customer: Customer = JSON.parse(event.body ?? '{}');
    //TODO: generate id for customer
    customer.id = '1234';
    return {
        statusCode: 200,
        body: JSON.stringify({
            message: 'Customer created',
            customer
        }),
    };
};

getCustomerById.ts

import { APIGatewayProxyEvent, APIGatewayProxyResult } from 'aws-lambda';
import { Customer } from '../models/Customer';

export const handler = async (event: APIGatewayProxyEvent): Promise<APIGatewayProxyResult> => {

    const id = event.pathParameters?.id;

    const customer: Customer = {
        id: id ?? '',
        name: 'John Doe',
        email: 'doe@qw.com',
        age: 30
    };

    return {
        statusCode: 200,
        body: JSON.stringify({
            message: 'Customer found',
            customer
        }),
    };
};

Customer.ts

En models solo se tiene definido un tipo de dato Customer:

export type Customer = {
    id: string;
    name: string;
    email: string;
    age: number;
};

Archivo template.yaml

Listo ahora que está todo el código fuente, es necesario configurar la infraestructura a desplegar en AWS.

Se realiza las configuraciones globales de las funciones y de la api:

Nota: La propiedad DeploymentPreference configura a la función lambda para realizar el despliegue incremental. Para conocer todos los tipos que existen se puede revisar el siguiente enlace: Deploy Canary.

En los recursos se definen las Lambdas y el ApiGateway a utilizar:

Nota: Se configura un alias de producción para simular sobre ese escenario.

Se muestra toda la configuración en template.yaml

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
  init-app

  Sample SAM Template for customers

Globals:
  Function:
    CodeUri: app
    Timeout: 10
    Tracing: Active
    Runtime: nodejs16.x
    Architectures:
      - x86_64
    DeploymentPreference:
      Enabled: true
      Type: 'Linear10PercentEvery1Minute'
  Api:
    TracingEnabled: True

Resources:

  ApiGateway:
    Type: AWS::Serverless::Api
    Properties:
      StageName: v1
      Variables:
        version_alias: 'production'
      EndpointConfiguration:
        Type: REGIONAL 

  CreateCustomerFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: src/functions/createCustomer.handler
      FunctionName: !Sub ${AWS::StackName}-create-customer
      AutoPublishAlias: production
      Events:
        CreateCustomer:
          Type: Api
          Properties:
            Path: /customers
            Method: post
            RestApiId: !Ref ApiGateway
    Metadata:
      BuildMethod: esbuild
      BuildProperties:
        Minify: true
        Target: "es2020"
        EntryPoints: 
        - src/functions/createCustomer.ts

  GetCustomerByIdFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: src/functions/getCustomerById.handler
      FunctionName: !Sub ${AWS::StackName}-get-customer-by-id
      AutoPublishAlias: production
      Events:
        CreateCustomer:
          Type: Api
          Properties:
            Path: /customers/{id}
            Method: get
            RestApiId: !Ref ApiGateway
    Metadata: 
      BuildMethod: esbuild
      BuildProperties:
        Minify: true
        Target: "es2020"
        EntryPoints: 
        - src/functions/getCustomerById.ts

Nota: Algunos recursos como permisos y roles se crea detrás de escena gracias a la ayuda de SAM.

Despliegue de stack

En el directorio principal en donde está la plantilla template.yaml ejecutar los siguientes comandos para empaquetar y desplegar:

sam build
sam deploy --guided --capabilities CAPABILITY_NAMED_IAM

Se revisa en la consola de cloudformation para ver los recursos creados en el stack:

Si se revisa una de las funciones podemos ver el alias y una tercera versión creada, esto debido a que anteriormente se hizo unos despliegues de prueba, si es primer despliegue desde cero estará una versión 1:

Para el ejemplo se toma la función que simula crear un Cliente para realizar las pruebas, revisar el recurso de ApiGateway para obtener la URL a consultar:

Se comprueba el funcionamiento en Postman:

Actualizar código para evidenciar el despliegue Canary

Para poder ver la ejecución de Canary hay que editar el código y desplegar, se podrá ver que de a poco va incrementando el peso de la versión.

En este caso se edita la función que simula crear un Cliente.

Se instala las siguientes dependencias y se edita el código como se muestra:

npm i short-uuid

Una vez realizado los cambios se debe ejecutar los comandos:

sam build
sam deploy --capabilities CAPABILITY_NAMED_IAM

Prueba de Canary

El despliegue tipo Canary empieza, por cada minuto se incrementa de forma lineal un 10% para pasar a la versión 4.

Para poder evidenciar que la carga se está distribuyendo entre las dos versiones se realiza una prueba de carga con Jmeter.

Nota: Si no conoces sobre Jmeter para pruebas de carga puedes revisar el siguiente recurso.

En los logs de la función de Cloudwatch se puede observar como ha realizado llamadas entre las dos versiones 3 y 4.

Espero hayas aprendido las bases sobre canary con este sencillo ejemplo en funciones lambdas, gracias.

Referencias

Crud Dynamodb usando funciones lambdas y apigateway

Kevin Catucuamba — Sun, 04 Dec 2022 18:55:51 +0000

Amazon Web Services

La plataforma en la nube Amazon Web Services (AWS) ofrece múltiples servicios integrales para que los desarrolladores de software puedan implementar sus soluciones de manera rápida y relativamente fácil.

Hoy en día es indispensable crear servicios web para entregar y capturar información para que las aplicaciones puedan conectarse entre ellas, los servicios rest son de los más usados actualmente.

Ejercicio práctico

Para este ejemplo se crea una api rest que realice operaciones CRUD (Crear, Leer, Actualizar y Eliminar) de productos dentro de una base de datos NoSQL proporcionada por AWS, se implementa funciones lambdas para realizar el código y el servicio de Apigateway para consumir desde un cliente.

Requisitos previos:

Cuenta activa de AWS
Tener configurada las credenciales AWS (AWS CLI y SAM CLI) en el ordenador.
Conocimientos esenciales de serverless.
Conocimientos esenciales de Cloudformation.
Tener instalado nodejs (para este ejercicio se usa v16)

Tecnologías a usar en AWS

AWS CLI y SAM CLI
Cloudformation
Lambdas (Nodejs)
Dynamodb
Apigateway

A continuación se detalla brevemente y se pone en contexto de las herramientas de AWS a usar.

Serverless

Serverless quiere decir sin servidor, permite al desarrollador crear y ejecutar aplicaciones con rapidez y menor costo, no se preocupa por gestionar infraestructura de servidores donde se aloja el código, simplemente se enfoca en codear. Puedes revisar más del tema en este artículo: Serverless.

AWS CLI y SAM CLI

AWS CLI es una herramienta de línea de comandos de AWS, se usa para administrar sus servicios en AWS. Se debe configurar las credenciales con aws configure, ver el siguiente enlace:AWS CLI.

SAM

Significa modelo de aplicación sin servidor de AWS, es un framework que se utiliza para crear aplicaciones sin servidor en AWS. También tiene una interfaz de línea de comandos para poder desplegar servicios, revisar el siguiente link para su instalación dependiendo del sistema operativo: SAM CLI.

Cloudformation

AWS CloudFormation es un servicio que ofrece a desarrolladores una manera sencilla de crear una colección de recursos de AWS y organizarlos como si fuese archivos de código.

Lambdas

AWS Lambda permite correr código sin administrar servidores, el desarrollador solo escribe trozos de código (funciones) y se las sube a estos servicios, se puede usar con varios lenguajes entre ellos: python, javascript y java. Para más información revisar: AWS Lambda.

Dynamodb

Es un servicio de base de datos NoSQL de AWS, permite almacenar datos en documentos y valores clave.

Api Gateway

Amazon Api Gateway es un servicio de AWS para administrar y proteger servicios de API REST, HTTP y WebSockets. Permite conectarse a otros servicios y consumirlas mediante una url.
Para más información revisar el siguiente enlace: AWS Api Gateway.

Infraestructura a crear

Se indica un pequeño diagrama de como va a funcionar la aplicación CRUD a crear:

Inicio de proyecto

Dentro de un directorio en la consola colocar el comando sam init y completar las instrucciones de la siguiente manera:

Se debe generar un proyecto en la siguiente estructura:

Esta estructura solo nos sirve como ejemplo de partida, para un mejor control del proyecto se configura de la siguiente manera, quitar la carpeta de tests y el archivo principal app.ts, la carpeta hello-world se cambia por app:

Instalar dependencias

Dentro de la carpeta app en donde se encuentra el package.json ejecutar lo siguiente:

npm install
npm install aws-sdk
npm install short-uuid

DynamoDB, servicios y modelo

En las siguientes carpteas crear los archivos:

DynamoClient.ts

Nos genera una instancia cliente para poder realizar operaciones en una tabla de Dynamodb.

import DynamoDB from 'aws-sdk/clients/dynamodb';
export const dynamoClient = new DynamoDB.DocumentClient();

Product.ts

Es un molde de los campos que va a contener el producto.

export interface Product{
    id: string;
    name: string;
    price: number;
    description: string;
}

ProductService.ts

Es una clase que nos va a permitir realizar la lógica de cada una de las funciones que estamos usando, en este caso operaciones CRUD:

import { dynamoClient } from "../dynamodb/DynamoClient";
import { Product } from '../models/Product';
import { generate } from 'short-uuid';


export class ProductService {

    static async getProducts(): Promise<Product[]> {
        try {
            const tableName = process.env.TABLE_NAME ?? ''
            const response = await dynamoClient.scan({
                TableName: tableName
            }).promise();

            return response.Items as Product[];
        } catch (error) {
            throw new Error("Error getting products: " + error);
        }
    }

    static async getProductById(id: string): Promise<Product> {
        try {
            const tableName = process.env.TABLE_NAME ?? ''
            const response = await dynamoClient.get({
                TableName: tableName,
                Key: {
                    id
                }
            }).promise();
            return response.Item as Product;
        } catch (error) {
            throw new Error("Error getting product by id: " + error);
        }
    }

    static async createProduct(product: Product): Promise<Product> {
        try {
            const tableName = process.env.TABLE_NAME ?? ''
            product.id = generate();
            await dynamoClient.put({
                TableName: tableName,
                Item: product
            }).promise();
            return product;
        } catch (error) {
            throw new Error("Error creating product: " + error);
        }
    }

    static async updateProductById(product: Product): Promise<Product> {
        try {
            const tableName = process.env.TABLE_NAME ?? ''
            await dynamoClient.update({
                TableName: tableName,
                Key: {
                    id: product.id
                },
                UpdateExpression: "set #name = :name, #price = :price, #description = :description",
                ExpressionAttributeNames: {
                    "#name": "name",
                    "#price": "price",
                    "#description": "description"
                },
                ExpressionAttributeValues: {
                    ":name": product.name,
                    ":price": product.price,
                    ":description": product.description
                }
            }).promise();
            return product;
        } catch (error) {
            throw new Error("Error updating product: " + error);
        }
    }

    static async deleteProductById(id: string): Promise<void> {
        try {
            const tableName = process.env.TABLE_NAME ?? ''
            await dynamoClient.delete({
                TableName: tableName,
                Key: {
                    id
                }
            }).promise();
        } catch (error) {
            throw new Error("Error deleting product: " + error);
        }
    }

}

Funciones

Dentro de la carpeta funciones se crea un archivo por cada función.

En las funciones solo hace falta llamar al servicio creado anteriormente y retornar datos:

create.ts

import { APIGatewayProxyEvent, APIGatewayProxyResult } from 'aws-lambda';
import { ProductService } from '../services/ProductService';
import { Product } from '../models/Product';

/**
 * Function to create a new product
 * @param event 
 * @returns 
 */
export const handler = async (event: APIGatewayProxyEvent): Promise<APIGatewayProxyResult> => {
    const newProduct: Product = JSON.parse(event.body as string);
    const product = await ProductService.createProduct(newProduct);
    return {
        statusCode: 201,
        body: JSON.stringify({
            item: product
        })
    }
}

deleteById.ts

import { ProductService } from '../services/ProductService';
import { APIGatewayProxyEvent, APIGatewayProxyResult } from 'aws-lambda';

/**
 * Function to delete a product by id
 * @param event 
 * @returns 
 */
export const handler = async (event: APIGatewayProxyEvent): Promise<APIGatewayProxyResult> => {
    const id = event.pathParameters?.id;
    if (!id) {
        return {
            statusCode: 400,
            body: JSON.stringify({
                message: "id is required"
            })
        }
    }
    await ProductService.deleteProductById(id);
    return {
        statusCode: 204,
        body: 'Product deleted'
    }
}

getAll.ts

import { ProductService } from '../services/ProductService';
import { APIGatewayProxyEvent, APIGatewayProxyResult } from 'aws-lambda';

/**
 * Function to get all products
 * @param event 
 * @returns 
 */
export const handler = async (event: APIGatewayProxyEvent): Promise<APIGatewayProxyResult> => {
    const products = await ProductService.getProducts();
    return {
        statusCode: 200,
        body: JSON.stringify({
            items: products
        })
    }
}

getById.ts

import { ProductService } from '../services/ProductService';
import { APIGatewayProxyEvent, APIGatewayProxyResult } from 'aws-lambda';

/**
 * 
 * @param event Function to get product by id
 * @returns 
 */
export const handler = async (event: APIGatewayProxyEvent): Promise<APIGatewayProxyResult> => {
    const id = event.pathParameters?.id;
    if (!id) {
        return {
            statusCode: 400,
            body: JSON.stringify({
                message: "id is required"
            })
        }
    }
    const product = await ProductService.getProductById(id);
    return {
        statusCode: 200,
        body: JSON.stringify({
            item: product
        })
    }
}

updateById.ts

import { APIGatewayProxyEvent, APIGatewayProxyResult } from 'aws-lambda';
import { ProductService } from '../services/ProductService';
import { Product } from '../models/Product';

/**
 * Function to update a product by id
 * @param event 
 * @returns 
 */
export const handler = async (event: APIGatewayProxyEvent): Promise<APIGatewayProxyResult> => {
    const updatedProduct: Product = JSON.parse(event.body as string);
    const product = await ProductService.updateProductById(updatedProduct);
    return {
        statusCode: 200,
        body: JSON.stringify({
            item: product
        })
    }
}

Template.yaml

En este archivo se configura toda la infraestructura que se va a desplegar en AWS: lambdas, apigateway, roles, tablas, etc. La configuración es cloudformation con características avanzadas proporcionadas por SAM para desplegar aplicaciones serverless.

Se configura las propiedades de algunos recursos de manera global para evitar repetir cosas:

En los recursos para cada una de las funciones debe quedar de la siguiente manera:

La parte de Policies es muy importante, se le da permisos a la función lambda para ejecutar operaciones en la tabla de dynamodb que estamos creando.

A continuación se muestra el template completo:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
  crud-products-serverless

  Sample SAM Template for crud-products-serverless

# More info about Globals: https://github.com/awslabs/serverless-application-model/blob/master/docs/globals.rst
Globals:
  Function:
    CodeUri: app
    Timeout: 10
    Tracing: Active
    Runtime: nodejs16.x
    Architectures:
      - x86_64
    Environment:
      Variables:
        TABLE_NAME: !Ref ProductTable

  Api:
    TracingEnabled: True

Resources:
  CreateProductFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: src/functions/create.handler
      Events:
        CreateProduct:
          Type: Api
          Properties:
            Path: /products
            Method: post
      Policies:
        - DynamoDBCrudPolicy:
            TableName: !Ref ProductTable
    Metadata:
      BuildMethod: esbuild
      BuildProperties:
        Minify: true
        Target: "es2020"
        EntryPoints: 
        - src/functions/create.ts

  UpdateProductFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: src/functions/updateById.handler
      Events:
        CreateProduct:
          Type: Api
          Properties:
            Path: /products
            Method: put
      Policies:
        - DynamoDBCrudPolicy:
            TableName: !Ref ProductTable
    Metadata:
      BuildMethod: esbuild
      BuildProperties:
        Minify: true
        Target: "es2020"
        EntryPoints: 
        - src/functions/updateById.ts

  DeleteByIdProductFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: src/functions/deleteById.handler
      Events:
        CreateProduct:
          Type: Api
          Properties:
            Path: /products/{id}
            Method: delete
      Policies:
        - DynamoDBCrudPolicy:
            TableName: !Ref ProductTable
    Metadata:
      BuildMethod: esbuild
      BuildProperties:
        Minify: true
        Target: "es2020"
        EntryPoints: 
        - src/functions/deleteById.ts

  GetAllProductsFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: src/functions/getAll.handler
      Events:
        CreateProduct:
          Type: Api
          Properties:
            Path: /products
            Method: get
      Policies:
        - DynamoDBCrudPolicy:
            TableName: !Ref ProductTable
    Metadata:
      BuildMethod: esbuild
      BuildProperties:
        Minify: true
        Target: "es2020"
        EntryPoints: 
        - src/functions/getAll.ts

  GetProductByIdFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: src/functions/getById.handler
      Events:
        CreateProduct:
          Type: Api
          Properties:
            Path: /products/{id}
            Method: get
      Policies:
        - DynamoDBCrudPolicy:
            TableName: !Ref ProductTable
    Metadata:
      BuildMethod: esbuild
      BuildProperties:
        Minify: true
        Target: "es2020"
        EntryPoints: 
        - src/functions/getById.ts

  ProductTable:
    Type: AWS::DynamoDB::Table
    Properties:
      TableName: !Sub ${AWS::StackName}-products
      AttributeDefinitions:
        - AttributeName: id
          AttributeType: S
      KeySchema:
        - AttributeName: id
          KeyType: HASH
      BillingMode: PAY_PER_REQUEST

Despliegue

Eso sería todo en cuanto a las plantillas y el código para realizar operaciones CRUD. Dentro de la carpeta donde está la plantilla template.yaml ejecutar:

sam build

Seguidamente ejecutar:

sam deploy --guided

A continuación realiza algunas preguntas, se recomienda configurar de la siguiente manera:

Luego confirmar el despliegue y esperar:

Es probable que en windows la consola se queda congelada, revisar en la consola aws directamente.

Se revisa en la consola de cloudformation de AWS:

Los recursos han sido creados:

En el recurso de apigateway se puede ver la implementación para poder consumirlas.

Probando apis

Consultando productos (se creo uno previamente):

Se crea un producto:

Producto por ID.:

Despedida

Eso sería todo, puedes ir probando todas las demás funciones, de esta manera es sencillo desplegar apis con AWS. Si alguna duda no dudes en comentarlo.