Funciones Serverless Avanzadas en JavaScript en AWS Lambda

Entrenador de Python en Línea para Principiantes

Aprende Python fácilmente sin sobrecargarte de teoría. Resuelve tareas prácticas con verificación automática, recibe pistas y escribe código directamente en el navegador, sin instalar nada.

Start Course

Funciones Serverless Avanzadas en JavaScript en AWS Lambda: de la teoría a producción

La arquitectura Serverless basada en AWS Lambda se ha convertido en el estándar para construir microservicios y sistemas orientados a eventos. Si ya dominas las funciones básicas (disparadores desde S3, API Gateway, DynamoDB), es hora de pasar al siguiente nivel. En este artículo, analizaremos técnicas avanzadas para trabajar con AWS Lambda en Node.js: optimización del arranque en frío, trabajo en VPC, uso de capas, monitoreo y depuración adecuados. Cada sección incluye ejemplos prácticos de código.

\n\n

1. Optimización del arranque en frío (Cold Start)

El arranque en frío es el principal enemigo del rendimiento de las funciones Serverless. Cuando una función Lambda no se ha utilizado durante un tiempo, AWS crea un nuevo contenedor, carga el código e inicializa las dependencias. Esto puede tardar desde 200 ms hasta varios segundos. Veamos cómo minimizar este efecto.

\n\n

1.1. Uso del ámbito global

El código fuera del manejador se ejecuta solo una vez al crear el contenedor. Coloca allí las operaciones pesadas: conexión a la base de datos, carga de configuración, inicialización del SDK.

// ❌ Mal: cada invocación crea una nueva conexión\nexports.handler = async (event) => {\n  const AWS = require('aws-sdk');\n  const dynamoDB = new AWS.DynamoDB.DocumentClient();\n  // ...\n};\n\n// ✅ Bien: la conexión se crea una sola vez\nconst AWS = require('aws-sdk');\nconst dynamoDB = new AWS.DynamoDB.DocumentClient();\n\nexports.handler = async (event) => {\n  // usamos dynamoDB\n};

\n\n

1.2. Reducción del tamaño del paquete

Cada módulo adicional aumenta el tiempo de carga. Usa aws-sdk versión 3 con tree-shaking o importa solo los clientes necesarios:

// En lugar del SDK completo:\nconst { DynamoDBClient } = require('@aws-sdk/client-dynamodb');\nconst { DynamoDBDocumentClient } = require('@aws-sdk/lib-dynamodb');

\n\n

1.3. Provisioned Concurrency

Para funciones críticas en latencia (por ejemplo, API bajo carga), activa Provisioned Concurrency. Esto garantiza que un número determinado de contenedores esté siempre "caliente".

// Ejemplo mediante AWS CLI:\naws lambda put-provisioned-concurrency-config \\\n  --function-name my-function \\\n  --qualifier PROD \\\n  --provisioned-concurrent-executions 10

\n\n

2. Trabajo con VPC: seguridad y rendimiento

Cuando una función Lambda necesita acceder a recursos dentro de una VPC (RDS, ElastiCache, APIs privadas), se requiere configurar el acceso de red. Sin embargo, conectarse a una VPC aumenta el arranque en frío de 5 a 10 segundos debido a la creación de ENI (Elastic Network Interface).

\n\n

2.1. Optimización de funciones en VPC

Usa VPC Endpoints para servicios de AWS (S3, DynamoDB, SQS) — esto permite acceder a ellos sin pasar por NAT/Internet Gateway.
Minimiza el número de subredes — Lambda crea una ENI en cada subred especificada. Limítate a dos (diferentes AZ).
Almacena en caché las conexiones — si la función se conecta a RDS, usa un pool de conexiones (por ejemplo, pg-pool para PostgreSQL).

const { Pool } = require('pg');\n\n// El pool se crea fuera del manejador\nconst pool = new Pool({\n  host: process.env.DB_HOST,\n  database: 'mydb',\n  max: 5, // límite de conexiones\n  idleTimeoutMillis: 30000,\n});\n\nexports.handler = async (event) => {\n  const client = await pool.connect();\n  try {\n    const result = await client.query('SELECT NOW()');\n    return { statusCode: 200, body: result.rows };\n  } finally {\n    client.release();\n  }\n};

\n\n