DEV Community: Hazel Saenz

Escala Inteligente con Microservicios Serverless

Hazel Saenz — Tue, 24 Mar 2026 17:57:16 +0000

Cuándo dividir, cómo conectar y qué patrones usar para no crear un monolito distribuido.

Hace un tiempo me tocó trabajar en un proyecto donde todo funcionaba. Un monolito. Un deploy, un repo, un equipo. Respondía rápido, los usuarios estaban contentos, el jefe estaba contento.

Hasta que alguien en una conferencia dijo: "los microservicios son el futuro".

Y miramos nuestro monolito y pensamos: "esto no escala, necesitamos microservicios".

Tres meses después teníamos 15 servicios. Un request del usuario pasaba por 7 de ellos antes de responder. Si inventario iba lento, el checkout se caía. Si notificaciones fallaba, nadie sabía por qué el pedido se quedó a medias.

Teníamos un monolito distribuido. Los mismos problemas de antes, pero ahora con latencia de red y 12 dashboards que nadie entendía.

La complejidad no desapareció. Solo cambió de forma.

Si alguna vez sentiste que migrar a microservicios iba a resolver todos tus problemas y terminó creando nuevos... este artículo es para ti.

¿Realmente necesitas microservicios?

Antes de hablar de cómo, hablemos de cuándo. Porque la decisión más inteligente a veces es no dividir.

Cuando empecé a investigar más sobre el tema, me di cuenta de que muchas migraciones a microservicios no nacen de un problema real. Nacen del hype. De escuchar que "Netflix usa microservicios" y asumir que nosotros también deberíamos.

Pero Netflix llegó a microservicios después de años de crecimiento y con miles de ingenieros dedicados a esa transición. El contexto importa: lo que funciona para una empresa con esa escala no necesariamente aplica para todos los equipos.

Señales reales vs. falsas alarmas

✅ Señales reales para dividir	❌ Falsas alarmas
Equipos se bloquean entre sí para hacer deploy	"Netflix usa microservicios"
Un componente necesita escalar 100x más que el resto	"Mi monolito es legacy"
Dominios de negocio claramente independientes	"Quiero usar tecnologías diferentes por servicio"
Ciclos de release muy diferentes entre componentes	"Los microservicios son más modernos"
Un fallo en un módulo tumba todo el sistema	"Mi equipo de 3 personas necesita agilidad"

Si tu equipo es pequeño y todo cabe en un deploy, no necesitas microservicios. Necesitas un monolito bien estructurado.

Divide cuando el dolor es real: equipos que se bloquean, componentes que necesitan escalar de forma radicalmente diferente, dominios de negocio que evolucionan a ritmos distintos.

No dividas porque suena moderno.

No es binario — hay un espectro

Algo que me costó entender al principio es que no es "monolito o microservicios". Hay un espectro completo entre ambos:

La mayoría de los sistemas no necesitan ir directo a microservicios.

Empieza con un monolito modular: un solo deploy, pero con límites claros entre dominios. Cuando un módulo necesite escalar o evolucionar independientemente, lo extraes.

Eso es escalar inteligente: dividir cuando hay evidencia, no cuando hay hype.

Serverless cambia las reglas

Cuando trabajas con microservicios tradicionales, cada servicio necesita su servidor, su scaling, su service discovery. Es mucha carga operativa.

Serverless cambia eso por completo:

Microservicios Tradicionales	Microservicios Serverless
Tú manejas servidores por servicio	Sin servidores que gestionar
Tú configuras auto-scaling	Escala automática por función
Pagas por servidor encendido	Pagas por ejecución
Tú manejas service discovery	Eventos y colas conectan servicios
Kubernetes, Docker, load balancers	Lambda, API Gateway, EventBridge

Pero hay algo que quiero dejar claro porque es una confusión muy común:

Un microservicio serverless no es UNA Lambda.

Es la colección de Lambdas detrás de un API Gateway que resuelven un dominio de negocio. Pedidos, inventario, pagos, cada uno es un microservicio compuesto por varias funciones pequeñas y enfocadas.

Si metes toda la lógica en una sola Lambda gigante, estás creando un monolito dentro de una función.

La pregunta ya no es "cómo escalo este servicio" sino "cómo conecto estos servicios de forma inteligente".

Y ahí es donde entran los patrones.

Los 3 patrones clave

Después de haber pasado por varias migraciones (algunas exitosas, otras no tanto), identifiqué tres patrones que marcan la diferencia entre una arquitectura de microservicios que funciona y un monolito distribuido disfrazado.

Los presento aquí a nivel conceptual. Cada uno tendrá su artículo dedicado con implementación práctica y código real.

Patrón 1: Comunicación desacoplada — eventos, no llamadas directas

Este fue el error que más me costó entender.

Cuando empezamos a dividir servicios, lo primero que hicimos fue conectar Lambdas en cadena. Lambda A llama a B, B llama a C. Parecía lógico.

El problema:

Si C falla, todo falla. Las latencias se suman. Estás recreando el monolito pero con más latencia.

El patrón correcto es usar eventos asíncronos:

Tu microservicio responde al usuario y emite un evento. Los demás microservicios reaccionan al evento a su propio ritmo.

Desacoplados. Independientes. Resilientes.

Amazon EventBridge actúa como un bus de eventos serverless que desacopla la lógica de enrutamiento de tus microservicios. Amazon SQS te da colas de mensajes para procesamiento asíncrono con garantías de entrega. Ambos son piezas fundamentales para este patrón.

En el próximo artículo de la serie vamos a implementar este patrón paso a paso con EventBridge y SQS, incluyendo las trampas que te puedes encontrar.

Patrón 2: Cada servicio, su data

Este es directo y no tiene vuelta:

Si todos tus servicios leen y escriben en la misma tabla de DynamoDB, no tienes microservicios. Tienes un monolito disfrazado.

El patrón correcto:

Cada servicio es dueño de su data. Si otro servicio necesita esa información, la pide por evento o por API.

Nunca por query directo a la base de datos ajena.

¿Por qué? Porque si compartes la base de datos, cualquier cambio de schema puede romper múltiples servicios al mismo tiempo. Y ahí se fue tu independencia.

Esto se conoce como database per service y suena simple, pero tiene implicaciones importantes, como qué pasa cuando una transacción involucra múltiples servicios (spoiler: necesitas el patrón Saga).

En el tercer artículo de la serie vamos a profundizar en este patrón y en cómo manejar transacciones distribuidas con Sagas.

Patrón 3: Observabilidad desde el día 1

En un monolito, un error aparece en un log. En microservicios, un error puede estar en cualquiera de 10 servicios.

Sin observabilidad, estás debuggeando a ciegas. Y te lo digo por experiencia: no hay nada más frustrante que saber que algo falló y no poder encontrar dónde.

Los tres pilares que necesitas desde el día 1:

1. Logs estructurados con correlation ID

Nota importante: Cada request que entra a tu sistema debe llevar un ID único que viaje por todos los servicios. Cuando algo falla, buscas ese ID y ves el camino completo.

Lambda Powertools te lo da casi gratis, inyecta correlation IDs, estructura tus logs en JSON y agrega contexto automáticamente.

2. Traces distribuidos

AWS X-Ray y AWS Distro for OpenTelemetry (ADOT) te permiten ver el viaje completo de cada request a través de todos los servicios. Puedes identificar exactamente dónde está el bottleneck.

Nota importante: AWS está convergiendo hacia OpenTelemetry como estándar de instrumentación. ADOT te da una distribución optimizada para AWS que envía traces y métricas a X-Ray, CloudWatch y otros destinos.

3. Métricas de negocio

No solo "cuántos errores 500" sino "cuántos pedidos se perdieron por minuto". Las métricas técnicas te dicen que algo falló. Las métricas de negocio te dicen cuánto te costó.

Si no puedes ver qué pasa, no puedes arreglar lo que falla. En el cuarto artículo de la serie vamos a implementar observabilidad completa con Lambda Powertools, X-Ray y métricas custom.

El framework de decisión

Después de todo lo que vimos, quiero dejarte algo práctico. Un framework que puedes usar la próxima vez que alguien diga "necesitamos microservicios":

No empieces por la tecnología. Empieza por las preguntas.

Si la respuesta a todo es no, quédate con tu monolito. Si es sí, extrae con estrategia.

Lo que quiero que te lleves

🧠 Decide con evidencia, no con hype: Microservicios no son el default. Son una herramienta para problemas específicos.
📐 Empieza modular, extrae después: Monolito modular → macro-servicios → microservicios. En ese orden.
🔌 Eventos sobre llamadas directas: Desacopla con EventBridge/SQS. Nunca encadenes Lambdas síncronamente.
🗄️ Cada servicio, su data: Base de datos compartida = monolito disfrazado.
👀 Observabilidad no es opcional: Correlation IDs, X-Ray/OpenTelemetry, métricas de negocio. Desde el día 1.

Qué sigue

Este artículo es el mapa conceptual. Los siguientes artículos de la serie van a profundizar en cada patrón con implementación práctica y código real:

Comunicación desacoplada con EventBridge y SQS: Implementación paso a paso, trampas comunes y demo funcional
Database per service y el patrón Saga: Cómo manejar transacciones distribuidas con acciones compensatorias
Observabilidad en microservicios serverless: Lambda Powertools, X-Ray/OpenTelemetry y métricas de negocio en acción

"Escalar inteligente no es tener más servicios. Es tomar mejores decisiones."

Recursos

Si quieres profundizar más, estos son los recursos oficiales de AWS que recomiendo:

Implementing Microservices on AWS — Whitepaper completo sobre patrones API-driven, event-driven y data streaming
Microservices on Serverless Technologies — Arquitecturas serverless con Lambda, API Gateway y Fargate
Integrating Microservices by Using AWS Serverless Services — Guía prescriptiva sobre comunicación síncrona y asíncrona entre microservicios
Cloud Design Patterns, Architectures, and Implementations — Patrones como Saga, circuit breaker, event sourcing y strangler fig aplicados con servicios AWS

¿Te resultó útil este artículo? Compártelo con tu equipo. Y si ya pasaste por una migración a microservicios exitosa o no me encantaría escuchar tu experiencia.

AWS Lambda Durable Functions + IA: el combo que no sabías que necesitabas

Hazel Saenz — Wed, 18 Mar 2026 16:56:38 +0000

Cómo instalar y usar el nuevo Kiro Power para Lambda Durable Functions paso a paso.

En el artículo anterior vimos que Lambda Durable Functions y Step Functions no compiten. Son dos filosofías diferentes para resolver el mismo problema: orquestación de workflows.

Step Functions orquesta visualmente. Durable Functions orquesta en código.

Y prometí que en este artículo íbamos a pasar de la teoría a la práctica.

Pero hay un detalle que no mencioné:

👉 Construir tu primera Durable Function no tiene que ser complicado.

Porque desde marzo de 2026, existe un Kiro Power que te guía paso a paso. Con IA. Dentro de tu IDE.

Y eso cambia todo.

Espera... ¿qué es Kiro?

Si es la primera vez que escuchas el nombre, no te preocupes.

Kiro es un IDE creado por AWS, potenciado con IA. Piensa en él como tu editor de código, pero con un agente de IA integrado que entiende lo que estás construyendo y te ayuda a hacerlo mejor.

No es un chatbot que pega código de internet. No es un autocompletado glorificado.

Es un agente que entiende el contexto de tu proyecto, sigue buenas prácticas, y te guía mientras escribes código.

Puedes usarlo para escribir código, debuggear, hacer deploy, y mucho más. Si quieres conocerlo a fondo, te recomiendo esta guía de primeros pasos con Kiro. Pero lo que lo hace especial para este artículo es algo llamado Powers.

¿Qué es un Kiro Power?

Un Power es como darle superpoderes especializados al agente de IA de Kiro.

Sin un Power, el agente sabe de todo un poco. Con un Power instalado, el agente se convierte en experto en un tema específico.

Piensa en esto: si le pides a un asistente genérico que te ayude a construir una Durable Function, probablemente te dé una respuesta genérica. Puede que funcione. Puede que no.

Pero si ese asistente tiene cargado un Power de Lambda Durable Functions, se convierte en un experto que sabe las reglas, los patrones, y las trampas comunes. Y carga esa información dinámicamente según lo que estés haciendo.

El Lambda Durable Functions Power

El 5 de marzo de 2026, AWS lanzó el Kiro Power para Lambda Durable Functions.

Incluye guía especializada para todo el ciclo de desarrollo: desde el setup del proyecto y las reglas del replay model, pasando por steps, waits, callbacks, ejecución en paralelo, manejo de errores, testing local, hasta deploy con CDK, SAM, o CloudFormation.

No tienes que leer toda la documentación antes de empezar. El Power te da lo que necesitas, cuando lo necesitas.

Instalando el Power

Esto es la parte más fácil. Literalmente un clic.

Abre Kiro
Ve al panel de Powers (en la barra lateral)
En la sección Available, busca "Lambda Durable Functions"
Haz clic en Install

Eso es todo.

No hay configuración adicional. No hay dependencias que instalar manualmente para el Power. Una vez instalado, el agente de Kiro ya tiene acceso a toda la guía especializada.

Nota: No todos los servicios de AWS tienen un Power dedicado. Los Powers son módulos especializados que se van agregando con el tiempo. Puedes explorar los disponibles en el panel de Powers de Kiro.

Ahora sí, vamos a construir algo.

Prerequisitos

Antes de escribir código, necesitas tener algunas herramientas instaladas. Los siguientes comandos te ayudan a verificar si ya las tienes. Si alguno falla, sigue el link de documentación correspondiente para instalarlo.

AWS CLI instalado (versión 2.33.22 o superior) y configurado con tus credenciales:

aws --version
aws sts get-caller-identity

Node.js 22+ instalado (para este tutorial usaremos TypeScript):

node --version

AWS CDK instalado globalmente (versión 2.237.1 o superior). Este se instala a nivel global en tu máquina, no dentro del proyecto:

npm install -g aws-cdk
cdk --version

Si prefieres Python, Lambda Durable Functions también soporta Python 3.11+. Pero para este tutorial vamos con TypeScript porque es el lenguaje que más uso y el que me resulta más natural para explicar.

Creando tu primer proyecto

Abre Kiro y crea una carpeta nueva para tu proyecto. Luego, en el chat del agente, puedes pedirle directamente:

"Crea un proyecto de Lambda Durable Function con TypeScript y CDK"

El agente, con el Power instalado, va a:

Inicializar el proyecto con la estructura correcta
Instalar las dependencias necesarias
Configurar TypeScript
Crear los archivos base

Pero para que entiendas qué está pasando, vamos a hacerlo paso a paso.

Inicializar el proyecto

mkdir image-processor
cd image-processor
npm init -y

Instalar dependencias

npm install @aws/durable-execution-sdk-js
npm install --save-dev @aws/durable-execution-sdk-js-testing typescript @types/node

Ese primer paquete es el SDK de Durable Execution. Es el core de las Durable Functions: lo que hace posible que tu función guarde checkpoints y sobreviva a fallos.

El segundo paquete (-testing) es para testear localmente sin necesidad de deployar a AWS.

Estructura del proyecto

Kiro va a generar esta estructura por ti cuando le pidas crear el proyecto. Pero si prefieres hacerlo manual, así es como debería verse:

image-processor/
├── src/
│   └── handler.ts          # Tu función durable
├── tests/
│   └── handler.test.ts     # Tests locales
├── infrastructure/
│   └── stack.ts             # CDK stack para deploy
├── tsconfig.json
└── package.json

Simple. Sin carpetas innecesarias. Sin archivos que no vas a usar.

Tu primera Durable Function (generada por el Power)

Ahora viene la parte divertida.

¿Recuerdas el ejemplo del artículo anterior? Un usuario sube una foto y necesitas: validar que sea una imagen válida, redimensionar a diferentes tamaños, aplicar marca de agua, generar thumbnails, y guardar en S3.

Abre el chat de Kiro y escríbele algo como:

"Crea una Durable Function que procese imágenes: validar el archivo, redimensionar, aplicar marca de agua, generar thumbnails y guardar en S3"

El agente, con el Power instalado, genera el código por ti. No copia y pega de internet. Entiende las reglas del replay model, sabe qué va dentro de un step y qué no, y estructura el workflow siguiendo las buenas prácticas del SDK.

Esto es lo que el Power generó para mí cuando le pedí exactamente eso:

...
export const handler = withDurableExecution(async (event: ImageEvent, context: DurableContext) => {
  const outputBucket = event.outputBucket ?? event.bucket;
  const outputPrefix = event.outputPrefix ?? 'processed';
  const baseName = event.key.replace(/\.[^.]+$/, '');
  const ext = event.key.match(/\.[^.]+$/)?.[0] ?? '.jpg';

  // Step 1: Validate the file
  const imageBuffer = await context.step('validate-file', async () => {
    const response = await s3.send(new GetObjectCommand({
      Bucket: event.bucket,
      Key: event.key,
    }));

    if (!response.Body) {
      throw new Error(`File not found: ${event.key}`);
    }

    const buffer = Buffer.from(await response.Body.transformToByteArray());
    const metadata = await sharp(buffer).metadata();

    if (!metadata.format || !['jpeg', 'png', 'webp', 'tiff'].includes(metadata.format)) {
      throw new Error(
        `Unsupported image format: ${metadata.format}. Supported: jpeg, png, webp, tiff`
      );
    }

    if (buffer.length > 50 * 1024 * 1024) {
      throw new Error('File exceeds 50MB limit');
    }

    context.logger.info('File validated', {
      format: metadata.format,
      width: metadata.width,
      height: metadata.height,
      size: buffer.length,
    });

    return buffer.toString('base64');
  });

  // Step 2: Resize the image
  const resizedBase64 = await context.step(
    'resize-image',
    async () => {
      const buffer = Buffer.from(imageBuffer, 'base64');
      const maxWidth = event.maxWidth ?? 1920;
      const maxHeight = event.maxHeight ?? 1080;

      const resized = await sharp(buffer)
        .resize(maxWidth, maxHeight, { fit: 'inside', withoutEnlargement: true })
        .toBuffer();

      const resizedKey = `${outputPrefix}/${baseName}-resized${ext}`;
      await s3.send(new PutObjectCommand({
        Bucket: outputBucket,
        Key: resizedKey,
        Body: resized,
        ContentType: `image/${ext.replace('.', '')}`,
      }));

      context.logger.info('Image resized', { key: resizedKey });
      return resized.toString('base64');
    },
    { retryStrategy }
  );
...

Ver codigo completo: https://github.com/hsaenzG/durable-funtions-demo/blob/main/src/handler.ts

Parece código normal, ¿verdad? Y lo es. Pero con superpoderes.

Qué está pasando aquí

Cada context.step() es un checkpoint. Si tu función falla aplicando la marca de agua (paso 3), cuando se reintente, no va a volver a validar ni redimensionar. Salta directamente al paso 3 con los resultados que ya tenía guardados.

Eso es el replay model en acción. Y para un workflow de procesamiento de imágenes, donde cada paso puede tardar segundos o minutos, no repetir trabajo es la diferencia entre una buena experiencia y una pesadilla.

Fíjate también en context.logger en lugar de console.log: es replay-aware. No duplica logs cuando la función se reintenta.

El Kiro Power y la regla de oro del Replay Model

Aquí es donde el Kiro Power realmente brilla. Porque hay una regla que la mayoría no conocemos hasta que algo se rompe:

Todo código no determinístico DEBE ir dentro de un step.

Y el Power te avisa cuando estás a punto de violar esa regla. No tienes que memorizar todos los casos. El agente los detecta y te sugiere la corrección antes de que sea un problema.

Pero, ¿por qué importa tanto esta regla?

Cuando una Durable Function se reintenta (replay), ejecuta todo el código desde el principio. Los steps que ya completaron se saltan (usa el resultado guardado). Pero el código que está fuera de los steps se ejecuta de nuevo.

Si ese código da un resultado diferente en el replay... las cosas se rompen.

¿Qué es código no determinístico? Cualquier cosa que puede dar un resultado diferente cada vez:

Date.now() → diferente cada vez
Math.random() → diferente cada vez
Llamadas a APIs externas → pueden devolver datos diferentes
Consultas a bases de datos → los datos pueden haber cambiado
Generación de UUIDs → diferente cada vez

Veamos un ejemplo concreto:

// ❌ MAL: Date.now() fuera de un step
const timestamp = Date.now(); // Diferente en cada replay
await context.step('save', async () => save(timestamp));

// ✅ BIEN: Date.now() dentro del step
const result = await context.step('save-with-timestamp', async () => {
  const timestamp = Date.now(); // Se guarda con el checkpoint
  return save(timestamp);
});

Sin el Power, descubrir este tipo de errores es prueba y error. Con el Power, el agente te lo señala mientras escribes.

Además, puedes instalar el plugin de ESLint para Durable Functions que atrapa estos errores en tiempo de desarrollo:

npm install --save-dev @aws/durable-execution-sdk-js-eslint-plugin

Testeando localmente

No necesitas hacer deploy para probar tu función. El SDK incluye un test runner local.

import { LocalDurableTestRunner } from '@aws/durable-execution-sdk-js-testing';
import { handler } from '../src/handler';

describe('Image Processing Workflow', () => {
  it('should process an image successfully', async () => {
    const runner = new LocalDurableTestRunner(handler, { skipTime: true });

    const result = await runner.run({
      input: {
        bucket: 'my-images-bucket',
        key: 'uploads/photo.jpg',
        userId: 'user-123'
      }
    });

    // Verificar que el procesamiento se completó
    expect(result.status).toBe('completed');
    expect(result.originalKey).toBe('uploads/photo.jpg');

    // Verificar que los steps se ejecutaron
    const steps = runner.getOperations();
    const validateStep = steps.find(op => op.name === 'validate-image');
    const resizeStep = steps.find(op => op.name === 'resize-image');
    const watermarkStep = steps.find(op => op.name === 'apply-watermark');
    const thumbnailStep = steps.find(op => op.name === 'generate-thumbnails');
    const saveStep = steps.find(op => op.name === 'save-to-s3');

    expect(validateStep).toBeDefined();
    expect(resizeStep).toBeDefined();
    expect(watermarkStep).toBeDefined();
    expect(thumbnailStep).toBeDefined();
    expect(saveStep).toBeDefined();
  });
});

El skipTime: true es clave: hace que los wait se salten instantáneamente en los tests.

Y fíjate que buscamos los steps por nombre, no por índice. Eso es una buena práctica que el Power te recuerda constantemente: siempre nombra tus steps de forma descriptiva.

Haciendo deploy con CDK

Ya tienes tu función funcionando localmente. Ahora toca subirla a AWS.

Para esto usamos AWS CDK, que te permite definir tu infraestructura en código (TypeScript, en nuestro caso).

import * as cdk from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as logs from 'aws-cdk-lib/aws-logs';
import * as iam from 'aws-cdk-lib/aws-iam';

export class DurableFunctionStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // Log group explícito para mejor control
    const logGroup = new logs.LogGroup(this, 'ImageProcessingLogs', {
      logGroupName: '/aws/lambda/imageProcessing',
      retention: logs.RetentionDays.ONE_WEEK,
      removalPolicy: cdk.RemovalPolicy.DESTROY,
    });

    // La función durable
    const imageFunction = new lambda.Function(this, 'ImageProcessing', {
      runtime: lambda.Runtime.NODEJS_24_X,
      handler: 'handler.handler',
      code: lambda.Code.fromAsset('dist'),
      logGroup: logGroup,
      durableConfig: {
        executionTimeout: cdk.Duration.hours(1),
        retentionPeriod: cdk.Duration.days(7),
      },
    });

    // Política de permisos para durable execution
    imageFunction.role?.addManagedPolicy(
      iam.ManagedPolicy.fromAwsManagedPolicyName(
        'service-role/AWSLambdaBasicDurableExecutionRolePolicy'
      )
    );

    // Crear alias para invocación
    const version = imageFunction.currentVersion;
    const alias = new lambda.Alias(this, 'ProdAlias', {
      aliasName: 'prod',
      version: version,
    });

    new cdk.CfnOutput(this, 'FunctionAliasArn', {
      value: alias.functionArn,
    });
  }
}

Lo que importa aquí

Hay tres cosas que no puedes olvidar al hacer deploy de una Durable Function:

durableConfig: Sin esto, tu función es una Lambda normal. El executionTimeout define cuánto tiempo máximo puede correr tu workflow (hasta 1 año). El retentionPeriod define cuánto tiempo se guardan los datos de ejecución.
AWSLambdaBasicDurableExecutionRolePolicy: Esta política le da a tu función permisos para hacer checkpoints (lambda:CheckpointDurableExecution) y leer el estado de ejecución (lambda:GetDurableExecutionState). Sin ella, los steps no pueden guardar su progreso.
ARN calificado: Las Durable Functions requieren un ARN calificado para ser invocadas. Un ARN (Amazon Resource Name) es el identificador único de un recurso en AWS. "Calificado" significa que incluye la versión o alias de la función. No puedes invocar una Durable Function con el ARN sin calificar.

# ✅ Correcto: con alias
aws lambda invoke --function-name 'MiStack-MiFuncion-abc123:prod' response.json

# ✅ Correcto: con versión
aws lambda invoke --function-name 'MiStack-MiFuncion-abc123:1' response.json

# ❌ Incorrecto: sin calificar — va a fallar
aws lambda invoke --function-name MiStack-MiFuncion-abc123 response.json

Nota: CDK genera nombres de recursos con un sufijo aleatorio (ej: ImageProcessorStack-ImageProcessor5D0B0257-lBARjqDaXdWK). Puedes encontrar el nombre exacto de tu función en el output del cdk deploy o en la consola de AWS Lambda.

Deploy

# Compilar TypeScript
npx tsc

# Deploy con CDK
cdk deploy

CDK se encarga de crear todo: la función, el rol de IAM, los permisos, el log group, la versión y el alias.

Invocando tu función

Ya está en la nube. Ahora vamos a probarla.

Primero, sube una imagen de prueba al bucket de S3 que CDK creó:

aws s3 cp tu-imagen.jpg \
  s3://TU-BUCKET-S3/photos/test.jpg \
  --profile TU-PERFIL \
  --region us-east-1

Nota: El nombre del bucket lo genera CDK automáticamente (ej: imageprocessorstack-imagebucket97210811-x5j3e61lysxh). Puedes encontrarlo en el output del cdk deploy o en la consola de S3.

Ahora sí, invoca la función:

aws lambda invoke \
  --function-name 'TU-NOMBRE-DE-FUNCION:prod' \
  --invocation-type Event \
  --durable-execution-name "test-$(date +%s)" \
  --payload '{"bucket":"TU-BUCKET-S3","key":"photos/test.jpg"}' \
  --cli-binary-format raw-in-base64-out \
  --profile TU-PERFIL \
  --region us-east-1 \
  response.json

cat response.json

Tip: Reemplaza TU-NOMBRE-DE-FUNCION, TU-BUCKET-S3 y TU-PERFIL con los valores reales de tu entorno. Revisa los outputs del cdk deploy para encontrarlos.

Algunos detalles sobre estos parámetros:

--invocation-type Event: Invoca la función de forma asíncrona. Para workflows largos como procesamiento de imágenes, esto es lo recomendado. Si quieres esperar la respuesta, usa RequestResponse.
--durable-execution-name "test-$(date +%s)": Genera un nombre único por ejecución usando un timestamp. Esto garantiza idempotencia: si invocas con el mismo nombre dos veces, la segunda no crea una ejecución nueva.
--profile y --region: Si tienes múltiples perfiles de AWS configurados, no olvides especificarlos.

Monitoreando tus ejecuciones

Ya invocaste tu función. ¿Y ahora? ¿Cómo sabes si funcionó?

No estás a ciegas. La consola de AWS Lambda tiene una interfaz dedicada para Durable Functions donde puedes ver todo lo que está pasando.

Ve a tu función en la consola y busca la pestaña Durable executions. Ahí vas a encontrar la lista de todas las ejecuciones con su estado: running, completed, failed.

Haz clic en cualquier ejecución y vas a ver el detalle completo: qué steps se completaron, cuáles fallaron, cuánto tardó cada uno, y los datos que se guardaron en cada checkpoint.

Esto es oro para debuggear. Si algo falló en el paso 3, puedes ver exactamente qué datos tenía en ese momento y qué error se produjo. Sin adivinar. Sin buscar en CloudWatch a ciegas.

Por qué esto importa si estás empezando

Sin el Power, el camino típico es: leer toda la documentación, tropezar con el replay model, configurar el proyecto a mano, y descubrir errores de deploy por prueba y error.

Con el Power, el agente te guía en cada paso. No elimina la necesidad de entender los conceptos (eso sigue siendo importante). Pero reduce drásticamente el tiempo entre "quiero aprender Durable Functions" y "tengo una funcionando en producción".

Limpieza de recursos

Si solo estás probando, recuerda eliminar los recursos para evitar cargos:

cdk destroy

Esto elimina la función Lambda, el rol de IAM, el log group, y todos los recursos asociados. CDK se encarga de todo.

Lo que aprendiste

Instalaste un Kiro Power con un clic, creaste un proyecto desde cero, dejaste que el agente generara tu primera Durable Function con el mismo ejemplo de procesamiento de imágenes del artículo anterior, entendiste la regla de oro del replay model, testeaste localmente sin deploy, y subiste todo a AWS con CDK.

De cero a producción. Con IA guiándote en cada paso.

Qué sigue

Ya tienes el workflow de procesamiento de imágenes funcionando. Pero lo construimos en el camino feliz: todo sale bien, nada falla.

En el próximo artículo vamos a romper cosas a propósito. Vamos a ver cómo los checkpoints automáticos mantienen tu progreso incluso cuando algo truena, y cómo el replay model recupera la ejecución exactamente donde quedó.

Código real. Fallos reales. Recuperación real.

¿Te resultó útil este artículo? Compártelo con tu equipo o déjame saber en los comentarios qué otros temas de serverless te gustaría que cubriera. Y si ya instalaste el Kiro Power y estás construyendo tu primera Durable Function, me encantaría escuchar tu experiencia.

AWS Lambda Durable Functions + IA: el combo que no sabías que necesitabas

Hazel Saenz — Wed, 18 Mar 2026 16:56:38 +0000

Cómo instalar y usar el nuevo Kiro Power para Lambda Durable Functions paso a paso.

En el artículo anterior vimos que Lambda Durable Functions y Step Functions no compiten. Son dos filosofías diferentes para resolver el mismo problema: orquestación de workflows.

Step Functions orquesta visualmente. Durable Functions orquesta en código.

Y prometí que en este artículo íbamos a pasar de la teoría a la práctica.

Pero hay un detalle que no mencioné:

👉 Construir tu primera Durable Function no tiene que ser complicado.

Porque desde marzo de 2026, existe un Kiro Power que te guía paso a paso. Con IA. Dentro de tu IDE.

Y eso cambia todo.

Espera... ¿qué es Kiro?

Si es la primera vez que escuchas el nombre, no te preocupes.

Kiro es un IDE creado por AWS, potenciado con IA. Piensa en él como tu editor de código, pero con un agente de IA integrado que entiende lo que estás construyendo y te ayuda a hacerlo mejor.

No es un chatbot que pega código de internet. No es un autocompletado glorificado.

Es un agente que entiende el contexto de tu proyecto, sigue buenas prácticas, y te guía mientras escribes código.

¿Qué es un Kiro Power?

Un Power es como darle superpoderes especializados al agente de IA de Kiro.

Sin un Power, el agente sabe de todo un poco. Con un Power instalado, el agente se convierte en experto en un tema específico.

Piensa en esto: si le pides a un asistente genérico que te ayude a construir una Durable Function, probablemente te dé una respuesta genérica. Puede que funcione. Puede que no.

El Lambda Durable Functions Power

El 5 de marzo de 2026, AWS lanzó el Kiro Power para Lambda Durable Functions.

No tienes que leer toda la documentación antes de empezar. El Power te da lo que necesitas, cuando lo necesitas.

Instalando el Power

Esto es la parte más fácil. Literalmente un clic.

Abre Kiro
Ve al panel de Powers (en la barra lateral)
En la sección Available, busca "Lambda Durable Functions"
Haz clic en Install

Eso es todo.

No hay configuración adicional. No hay dependencias que instalar manualmente para el Power. Una vez instalado, el agente de Kiro ya tiene acceso a toda la guía especializada.

Nota: No todos los servicios de AWS tienen un Power dedicado. Los Powers son módulos especializados que se van agregando con el tiempo. Puedes explorar los disponibles en el panel de Powers de Kiro.

Ahora sí, vamos a construir algo.

Prerequisitos

AWS CLI instalado (versión 2.33.22 o superior) y configurado con tus credenciales:

aws --version
aws sts get-caller-identity

Node.js 22+ instalado (para este tutorial usaremos TypeScript):

node --version

AWS CDK instalado globalmente (versión 2.237.1 o superior). Este se instala a nivel global en tu máquina, no dentro del proyecto:

npm install -g aws-cdk
cdk --version

Creando tu primer proyecto

Abre Kiro y crea una carpeta nueva para tu proyecto. Luego, en el chat del agente, puedes pedirle directamente:

"Crea un proyecto de Lambda Durable Function con TypeScript y CDK"

El agente, con el Power instalado, va a:

Inicializar el proyecto con la estructura correcta
Instalar las dependencias necesarias
Configurar TypeScript
Crear los archivos base

Pero para que entiendas qué está pasando, vamos a hacerlo paso a paso.

Inicializar el proyecto

mkdir image-processor
cd image-processor
npm init -y

Instalar dependencias

npm install @aws/durable-execution-sdk-js
npm install --save-dev @aws/durable-execution-sdk-js-testing typescript @types/node

Ese primer paquete es el SDK de Durable Execution. Es el core de las Durable Functions: lo que hace posible que tu función guarde checkpoints y sobreviva a fallos.

El segundo paquete (-testing) es para testear localmente sin necesidad de deployar a AWS.

Estructura del proyecto

Kiro va a generar esta estructura por ti cuando le pidas crear el proyecto. Pero si prefieres hacerlo manual, así es como debería verse:

image-processor/
├── src/
│   └── handler.ts          # Tu función durable
├── tests/
│   └── handler.test.ts     # Tests locales
├── infrastructure/
│   └── stack.ts             # CDK stack para deploy
├── tsconfig.json
└── package.json

Simple. Sin carpetas innecesarias. Sin archivos que no vas a usar.

Tu primera Durable Function (generada por el Power)

Ahora viene la parte divertida.

Abre el chat de Kiro y escríbele algo como:

"Crea una Durable Function que procese imágenes: validar el archivo, redimensionar, aplicar marca de agua, generar thumbnails y guardar en S3"

Esto es lo que el Power generó para mí cuando le pedí exactamente eso:

...
export const handler = withDurableExecution(async (event: ImageEvent, context: DurableContext) => {
  const outputBucket = event.outputBucket ?? event.bucket;
  const outputPrefix = event.outputPrefix ?? 'processed';
  const baseName = event.key.replace(/\.[^.]+$/, '');
  const ext = event.key.match(/\.[^.]+$/)?.[0] ?? '.jpg';

  // Step 1: Validate the file
  const imageBuffer = await context.step('validate-file', async () => {
    const response = await s3.send(new GetObjectCommand({
      Bucket: event.bucket,
      Key: event.key,
    }));

    if (!response.Body) {
      throw new Error(`File not found: ${event.key}`);
    }

    const buffer = Buffer.from(await response.Body.transformToByteArray());
    const metadata = await sharp(buffer).metadata();

    if (!metadata.format || !['jpeg', 'png', 'webp', 'tiff'].includes(metadata.format)) {
      throw new Error(
        `Unsupported image format: ${metadata.format}. Supported: jpeg, png, webp, tiff`
      );
    }

    if (buffer.length > 50 * 1024 * 1024) {
      throw new Error('File exceeds 50MB limit');
    }

    context.logger.info('File validated', {
      format: metadata.format,
      width: metadata.width,
      height: metadata.height,
      size: buffer.length,
    });

    return buffer.toString('base64');
  });

  // Step 2: Resize the image
  const resizedBase64 = await context.step(
    'resize-image',
    async () => {
      const buffer = Buffer.from(imageBuffer, 'base64');
      const maxWidth = event.maxWidth ?? 1920;
      const maxHeight = event.maxHeight ?? 1080;

      const resized = await sharp(buffer)
        .resize(maxWidth, maxHeight, { fit: 'inside', withoutEnlargement: true })
        .toBuffer();

      const resizedKey = `${outputPrefix}/${baseName}-resized${ext}`;
      await s3.send(new PutObjectCommand({
        Bucket: outputBucket,
        Key: resizedKey,
        Body: resized,
        ContentType: `image/${ext.replace('.', '')}`,
      }));

      context.logger.info('Image resized', { key: resizedKey });
      return resized.toString('base64');
    },
    { retryStrategy }
  );
...

Ver codigo completo: https://github.com/hsaenzG/durable-funtions-demo/blob/main/src/handler.ts

Parece código normal, ¿verdad? Y lo es. Pero con superpoderes.

Qué está pasando aquí

Fíjate también en context.logger en lugar de console.log: es replay-aware. No duplica logs cuando la función se reintenta.

El Kiro Power y la regla de oro del Replay Model

Aquí es donde el Kiro Power realmente brilla. Porque hay una regla que la mayoría no conocemos hasta que algo se rompe:

Todo código no determinístico DEBE ir dentro de un step.

Y el Power te avisa cuando estás a punto de violar esa regla. No tienes que memorizar todos los casos. El agente los detecta y te sugiere la corrección antes de que sea un problema.

Pero, ¿por qué importa tanto esta regla?

Si ese código da un resultado diferente en el replay... las cosas se rompen.

¿Qué es código no determinístico? Cualquier cosa que puede dar un resultado diferente cada vez:

Date.now() → diferente cada vez
Math.random() → diferente cada vez
Llamadas a APIs externas → pueden devolver datos diferentes
Consultas a bases de datos → los datos pueden haber cambiado
Generación de UUIDs → diferente cada vez

Veamos un ejemplo concreto:

// ❌ MAL: Date.now() fuera de un step
const timestamp = Date.now(); // Diferente en cada replay
await context.step('save', async () => save(timestamp));

// ✅ BIEN: Date.now() dentro del step
const result = await context.step('save-with-timestamp', async () => {
  const timestamp = Date.now(); // Se guarda con el checkpoint
  return save(timestamp);
});

Sin el Power, descubrir este tipo de errores es prueba y error. Con el Power, el agente te lo señala mientras escribes.

Además, puedes instalar el plugin de ESLint para Durable Functions que atrapa estos errores en tiempo de desarrollo:

npm install --save-dev @aws/durable-execution-sdk-js-eslint-plugin

Testeando localmente

No necesitas hacer deploy para probar tu función. El SDK incluye un test runner local.

import { LocalDurableTestRunner } from '@aws/durable-execution-sdk-js-testing';
import { handler } from '../src/handler';

describe('Image Processing Workflow', () => {
  it('should process an image successfully', async () => {
    const runner = new LocalDurableTestRunner(handler, { skipTime: true });

    const result = await runner.run({
      input: {
        bucket: 'my-images-bucket',
        key: 'uploads/photo.jpg',
        userId: 'user-123'
      }
    });

    // Verificar que el procesamiento se completó
    expect(result.status).toBe('completed');
    expect(result.originalKey).toBe('uploads/photo.jpg');

    // Verificar que los steps se ejecutaron
    const steps = runner.getOperations();
    const validateStep = steps.find(op => op.name === 'validate-image');
    const resizeStep = steps.find(op => op.name === 'resize-image');
    const watermarkStep = steps.find(op => op.name === 'apply-watermark');
    const thumbnailStep = steps.find(op => op.name === 'generate-thumbnails');
    const saveStep = steps.find(op => op.name === 'save-to-s3');

    expect(validateStep).toBeDefined();
    expect(resizeStep).toBeDefined();
    expect(watermarkStep).toBeDefined();
    expect(thumbnailStep).toBeDefined();
    expect(saveStep).toBeDefined();
  });
});

El skipTime: true es clave: hace que los wait se salten instantáneamente en los tests.

Y fíjate que buscamos los steps por nombre, no por índice. Eso es una buena práctica que el Power te recuerda constantemente: siempre nombra tus steps de forma descriptiva.

Haciendo deploy con CDK

Ya tienes tu función funcionando localmente. Ahora toca subirla a AWS.

Para esto usamos AWS CDK, que te permite definir tu infraestructura en código (TypeScript, en nuestro caso).

import * as cdk from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as logs from 'aws-cdk-lib/aws-logs';
import * as iam from 'aws-cdk-lib/aws-iam';

export class DurableFunctionStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // Log group explícito para mejor control
    const logGroup = new logs.LogGroup(this, 'ImageProcessingLogs', {
      logGroupName: '/aws/lambda/imageProcessing',
      retention: logs.RetentionDays.ONE_WEEK,
      removalPolicy: cdk.RemovalPolicy.DESTROY,
    });

    // La función durable
    const imageFunction = new lambda.Function(this, 'ImageProcessing', {
      runtime: lambda.Runtime.NODEJS_24_X,
      handler: 'handler.handler',
      code: lambda.Code.fromAsset('dist'),
      logGroup: logGroup,
      durableConfig: {
        executionTimeout: cdk.Duration.hours(1),
        retentionPeriod: cdk.Duration.days(7),
      },
    });

    // Política de permisos para durable execution
    imageFunction.role?.addManagedPolicy(
      iam.ManagedPolicy.fromAwsManagedPolicyName(
        'service-role/AWSLambdaBasicDurableExecutionRolePolicy'
      )
    );

    // Crear alias para invocación
    const version = imageFunction.currentVersion;
    const alias = new lambda.Alias(this, 'ProdAlias', {
      aliasName: 'prod',
      version: version,
    });

    new cdk.CfnOutput(this, 'FunctionAliasArn', {
      value: alias.functionArn,
    });
  }
}

Lo que importa aquí

Hay tres cosas que no puedes olvidar al hacer deploy de una Durable Function:

durableConfig: Sin esto, tu función es una Lambda normal. El executionTimeout define cuánto tiempo máximo puede correr tu workflow (hasta 1 año). El retentionPeriod define cuánto tiempo se guardan los datos de ejecución.
AWSLambdaBasicDurableExecutionRolePolicy: Esta política le da a tu función permisos para hacer checkpoints (lambda:CheckpointDurableExecution) y leer el estado de ejecución (lambda:GetDurableExecutionState). Sin ella, los steps no pueden guardar su progreso.
ARN calificado: Las Durable Functions requieren un ARN calificado para ser invocadas. Un ARN (Amazon Resource Name) es el identificador único de un recurso en AWS. "Calificado" significa que incluye la versión o alias de la función. No puedes invocar una Durable Function con el ARN sin calificar.

# ✅ Correcto: con alias
aws lambda invoke --function-name 'MiStack-MiFuncion-abc123:prod' response.json

# ✅ Correcto: con versión
aws lambda invoke --function-name 'MiStack-MiFuncion-abc123:1' response.json

# ❌ Incorrecto: sin calificar — va a fallar
aws lambda invoke --function-name MiStack-MiFuncion-abc123 response.json

Nota: CDK genera nombres de recursos con un sufijo aleatorio (ej: ImageProcessorStack-ImageProcessor5D0B0257-lBARjqDaXdWK). Puedes encontrar el nombre exacto de tu función en el output del cdk deploy o en la consola de AWS Lambda.

Deploy

# Compilar TypeScript
npx tsc

# Deploy con CDK
cdk deploy

CDK se encarga de crear todo: la función, el rol de IAM, los permisos, el log group, la versión y el alias.

Invocando tu función

Ya está en la nube. Ahora vamos a probarla.

Primero, sube una imagen de prueba al bucket de S3 que CDK creó:

aws s3 cp tu-imagen.jpg \
  s3://TU-BUCKET-S3/photos/test.jpg \
  --profile TU-PERFIL \
  --region us-east-1

Nota: El nombre del bucket lo genera CDK automáticamente (ej: imageprocessorstack-imagebucket97210811-x5j3e61lysxh). Puedes encontrarlo en el output del cdk deploy o en la consola de S3.

Ahora sí, invoca la función:

aws lambda invoke \
  --function-name 'TU-NOMBRE-DE-FUNCION:prod' \
  --invocation-type Event \
  --durable-execution-name "test-$(date +%s)" \
  --payload '{"bucket":"TU-BUCKET-S3","key":"photos/test.jpg"}' \
  --cli-binary-format raw-in-base64-out \
  --profile TU-PERFIL \
  --region us-east-1 \
  response.json

cat response.json

Tip: Reemplaza TU-NOMBRE-DE-FUNCION, TU-BUCKET-S3 y TU-PERFIL con los valores reales de tu entorno. Revisa los outputs del cdk deploy para encontrarlos.

Algunos detalles sobre estos parámetros:

--invocation-type Event: Invoca la función de forma asíncrona. Para workflows largos como procesamiento de imágenes, esto es lo recomendado. Si quieres esperar la respuesta, usa RequestResponse.
--durable-execution-name "test-$(date +%s)": Genera un nombre único por ejecución usando un timestamp. Esto garantiza idempotencia: si invocas con el mismo nombre dos veces, la segunda no crea una ejecución nueva.
--profile y --region: Si tienes múltiples perfiles de AWS configurados, no olvides especificarlos.

Monitoreando tus ejecuciones

Ya invocaste tu función. ¿Y ahora? ¿Cómo sabes si funcionó?

No estás a ciegas. La consola de AWS Lambda tiene una interfaz dedicada para Durable Functions donde puedes ver todo lo que está pasando.

Ve a tu función en la consola y busca la pestaña Durable executions. Ahí vas a encontrar la lista de todas las ejecuciones con su estado: running, completed, failed.

Haz clic en cualquier ejecución y vas a ver el detalle completo: qué steps se completaron, cuáles fallaron, cuánto tardó cada uno, y los datos que se guardaron en cada checkpoint.

Esto es oro para debuggear. Si algo falló en el paso 3, puedes ver exactamente qué datos tenía en ese momento y qué error se produjo. Sin adivinar. Sin buscar en CloudWatch a ciegas.

Por qué esto importa si estás empezando

Sin el Power, el camino típico es: leer toda la documentación, tropezar con el replay model, configurar el proyecto a mano, y descubrir errores de deploy por prueba y error.

Limpieza de recursos

Si solo estás probando, recuerda eliminar los recursos para evitar cargos:

cdk destroy

Esto elimina la función Lambda, el rol de IAM, el log group, y todos los recursos asociados. CDK se encarga de todo.

Lo que aprendiste

De cero a producción. Con IA guiándote en cada paso.

Qué sigue

Ya tienes el workflow de procesamiento de imágenes funcionando. Pero lo construimos en el camino feliz: todo sale bien, nada falla.

Código real. Fallos reales. Recuperación real.

Cold Starts en AWS Lambda: Qué son, por qué ocurren y cómo solucionarlos

Hazel Saenz — Mon, 16 Mar 2026 17:08:25 +0000

Todo lo que necesitas saber sobre cold starts en Lambda y las estrategias para reducir su impacto.

La primera vez que me topé con un cold start, no tenía idea de qué estaba pasando.

Había terminado de deployar una API con Lambda para un proyecto en el que estaba trabajando. Todo funcionaba. Los tests pasaban. El endpoint respondía rápido. Estaba feliz.

Hasta que un compañero me escribió: "Oye, a veces la API tarda como 3 segundos en responder. ¿Es normal?"

Mi primera reacción fue: "No puede ser, a mí me responde en 200ms". Así que abrí CloudWatch, empecé a revisar los logs... y ahí lo vi. Un INIT duration de 2.8 segundos que aparecía de vez en cuando, sin patrón aparente. No había error. No había timeout. Solo... lentitud.

Pasé un buen rato buscando qué significaba ese INIT. ¿Era un bug? ¿Algo que configuré mal? ¿Un problema de red?

No. Era un cold start.

Y cuando entendí qué era y por qué pasaba, todo empezó a tener sentido. Esas peticiones lentas no eran aleatorias. Eran el precio de no tener servidores corriendo 24/7.

Si alguna vez sentiste que tu función Lambda "se dormía" y tardaba en despertar, este artículo es para ti. Te voy a contar todo lo que aprendí sobre cold starts: qué son, por qué ocurren, y las estrategias que uso para reducir su impacto.

¿Qué es un cold start?

Cuando invocas una función Lambda, AWS necesita un lugar donde ejecutar tu código. Ese lugar se llama execution environment: un contenedor aislado con su runtime, tu código, y las dependencias que necesita.

Si ya existe un environment disponible (porque tu función se ejecutó hace poco), Lambda lo reutiliza. Eso es un warm start. Rápido. Sin sorpresas.

Pero si no hay ninguno disponible — porque es la primera invocación, porque pasó mucho tiempo sin actividad, o porque hay un pico de tráfico y Lambda necesita crear más environments — entonces tiene que crear uno nuevo desde cero.

Eso es un cold start.

Y crear un environment desde cero no es instantáneo. Lambda tiene que hacer varias cosas antes de que tu código empiece a ejecutarse:

Container Provisioning: asignar los recursos de cómputo según la memoria configurada
Runtime Initialization: cargar el runtime del lenguaje (Python, Node.js, Java, etc.)
Function Code Loading: descargar y desempaquetar tu código
Dependency Resolution: cargar las librerías y paquetes que tu función necesita

Todo eso es la fase de inicialización (Init phase). Y esa latencia adicional es lo que llamamos cold start.

La buena noticia: el cold start solo ocurre una vez por ciclo de vida del environment. Una vez que el environment está listo, las siguientes invocaciones son warm starts.

La otra buena noticia: según AWS, los cold starts típicamente afectan menos del 1% de las invocaciones. Pero ese 1% puede ser un problema si tu aplicación es sensible a la latencia.

¿Por qué ocurren?

Los cold starts no son un bug. Son una consecuencia natural de cómo funciona el modelo serverless.

Eficiencia de recursos: no pagas cuando tu código no se ejecuta. Eso es genial para tu billetera, pero significa que Lambda apaga los environments que llevan tiempo sin usarse. Cuando llega una nueva invocación, tiene que crear uno nuevo.

Aislamiento de seguridad: cada execution environment es independiente. No comparte memoria ni estado con otros. Esa seguridad requiere crear un environment fresco cada vez.

Auto-scaling: cuando llega un pico de tráfico, Lambda crea nuevos environments para manejar la carga. Cada environment nuevo pasa por la fase de inicialización.

En resumen: los cold starts son el precio que pagas por no tener que administrar servidores. Y en la mayoría de los casos, es un precio muy bajo.

Pero cuando sí importa — APIs de usuario, microservicios interactivos, flujos donde cada segundo cuenta — necesitas saber cómo reducirlos.

Factores que influyen en la duración

No todos los cold starts son iguales. Algunos duran 100 milisegundos. Otros duran 5 segundos. La diferencia depende de varios factores.

Runtime

Los lenguajes interpretados como Python y Node.js inicializan más rápido que los compilados como Java o .NET.

¿Por qué? Java necesita cargar la JVM y hacer JIT compilation. .NET tiene un proceso similar. Python y Node.js simplemente cargan el intérprete y empiezan a ejecutar.

Eso no significa que debas elegir tu lenguaje solo por el cold start. Pero es un factor a considerar si la latencia es crítica.

Tamaño del paquete

Más grande el paquete = más tiempo para descargarlo, descomprimirlo e inicializarlo.

Si tu función incluye dependencias que no usa, estás pagando cold start por código que nunca se ejecuta. Un paquete de 5 MB inicializa mucho más rápido que uno de 250 MB.

Memoria asignada

Esto es contraintuitivo: más memoria = cold starts más rápidos.

¿Por qué? Porque Lambda asigna CPU proporcionalmente a la memoria. Más memoria significa más CPU, y más CPU significa que la inicialización se completa más rápido.

A veces, subir la memoria de 128 MB a 512 MB reduce el cold start significativamente, y el costo adicional es mínimo porque la función termina más rápido.

Configuración de red (VPC)

Si tu función está dentro de una VPC, Lambda necesita crear una Elastic Network Interface (ENI) para conectarla a la red. Eso agrega latencia al cold start.

AWS mejoró esto significativamente con Hyperplane, que redujo la latencia de VPC de segundos a milisegundos. Pero sigue siendo un factor si tu función necesita acceso a recursos dentro de una VPC.

Inicialización estática

Todo el código que se ejecuta fuera del handler se ejecuta durante la fase Init. Si estás importando 15 librerías, creando conexiones a bases de datos, y cargando archivos de configuración... todo eso suma al cold start.

# Todo esto se ejecuta durante el Init (cold start)
import pandas as pd
import numpy as np
import boto3
from langchain import LLMChain

s3_client = boto3.client('s3')
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('my-table')

def lambda_handler(event, context):
    # Esto se ejecuta en cada invocación (warm o cold)
    ...

La inicialización estática es un arma de doble filo: quieres inicializar cosas fuera del handler para reutilizarlas en warm starts, pero todo lo que pongas ahí aumenta el cold start.

Estrategias de optimización (sin costo adicional)

Antes de llegar a las soluciones de AWS que cuestan dinero, hay varias cosas que puedes hacer gratis.

1. Importa solo lo necesario

# ❌ Importa todo el SDK
import boto3

# ✅ Importa solo lo que necesitas
from boto3 import client
s3 = client('s3')

2. Mantén tus paquetes pequeños

Elimina dependencias que no uses. Usa tree shaking en Node.js. Excluye archivos de tests, documentación, y ejemplos de tus paquetes de deployment.

3. Inicializa clientes fuera del handler

# ✅ Se inicializa una vez y se reutiliza en warm starts
s3_client = boto3.client('s3')

def lambda_handler(event, context):
    response = s3_client.get_object(Bucket='my-bucket', Key='my-key')
    ...

4. Asigna memoria adecuada

No te quedes con los 128 MB por defecto si tu función carga dependencias pesadas. Experimenta con 256 MB, 512 MB, o más. Usa AWS Lambda Power Tuning para encontrar el balance óptimo entre costo y rendimiento.

5. Usa layers para dependencias compartidas

Si varias funciones usan las mismas dependencias, empaquétalas en un Lambda Layer. Esto no reduce el cold start directamente, pero te ayuda a mantener paquetes organizados y más fáciles de optimizar.

Provisioned Concurrency: environments siempre calientes

Si las optimizaciones de código no son suficientes, AWS tiene dos soluciones dedicadas. La primera es Provisioned Concurrency.

La idea es simple: le dices a Lambda "mantén X environments siempre listos". Lambda los pre-inicializa y los mantiene calientes, esperando invocaciones.

Resultado: cero cold starts para esas invocaciones. Respuestas en milisegundos de doble dígito.

# Configurar 10 environments siempre listos
aws lambda put-provisioned-concurrency-config \
  --function-name my-function \
  --qualifier prod \
  --provisioned-concurrent-executions 10

Cuándo usarlo

Tu aplicación tiene requisitos estrictos de latencia (APIs de usuario, microservicios interactivos)
El tráfico es predecible o puedes configurar auto-scaling
Estás dispuesto a pagar por environments que están listos aunque no se usen

Cuándo NO usarlo

Tráfico esporádico o impredecible (vas a pagar por environments idle)
Workloads asíncronos donde la latencia no es crítica (procesamiento de datos, colas)
Tu presupuesto es ajustado

Nota importante: Provisioned Concurrency tiene un costo adicional. Pagas por cada environment provisionado, esté o no procesando invocaciones. Pero si la latencia es crítica para tu negocio, el costo vale la pena.

También puedes combinar Provisioned Concurrency con Application Auto Scaling para ajustar automáticamente la cantidad de environments según el tráfico. Puedes usar scheduled scaling (para patrones predecibles) o target tracking (para ajuste dinámico).

SnapStart: snapshots del environment inicializado

La segunda solución es Lambda SnapStart. Y funciona de una manera completamente diferente.

En lugar de mantener environments calientes, SnapStart toma una foto (snapshot) del environment después de que se inicializa. Cuando llega una invocación, en lugar de inicializar desde cero, Lambda restaura el environment desde esa foto.

El resultado: cold starts que bajan de varios segundos a sub-segundo.

Runtimes soportados

Java 11+
Python 3.12+
.NET 8+

Cuándo usarlo

Funciones con inicialización pesada (dependencias grandes, frameworks, modelos ML)
Invocaciones frecuentes a escala
Quieres reducir cold starts sin el costo de Provisioned Concurrency

Cuándo NO usarlo

Funciones que ya inicializan en milisegundos (no vas a notar la diferencia)
Necesitas latencia garantizada de doble dígito de milisegundos (usa Provisioned Concurrency)
Tu función usa EFS, Provisioned Concurrency, o almacenamiento efímero mayor a 512 MB (no es compatible)

SnapStart es especialmente interesante para Python, donde cargar dependencias como Pandas, NumPy, LangChain, o frameworks como Flask y Django puede tomar varios segundos.

👉 En el próximo artículo de esta serie, vamos a profundizar en SnapStart para Python: cómo funciona internamente, cómo activarlo paso a paso, cómo usar runtime hooks, y las mejores prácticas para sacarle el máximo provecho.

¿Cuál estrategia elegir?

No es "una u otra". Puedes (y deberías) combinarlas.

Estrategia	Latencia	Costo adicional	Ideal para
Optimización de código	Reduce el Init	Ninguno	Siempre. Es el primer paso
SnapStart	Sub-segundo	Costo de cache + restauración	Funciones con init pesado a escala
Provisioned Concurrency	Milisegundos	Pago por environment provisionado	Latencia ultra-baja garantizada

La recomendación:

Siempre optimiza tu código primero. Es gratis y ayuda en todos los escenarios.
Si después de optimizar sigues teniendo cold starts largos y tu función se invoca frecuentemente, prueba SnapStart.
Si necesitas latencia garantizada de milisegundos sin excepciones, usa Provisioned Concurrency.

📊 Árbol de decisión (haz clic para expandir)

Monitoreo: cómo saber si tienes un problema

Antes de optimizar, necesitas medir. No asumas que tienes un problema de cold starts solo porque "a veces se siente lento".

Si quieres ir más a fondo en el tema de diagnóstico y optimización de rendimiento en Lambda, te recomiendo este artículo donde comparto mi experiencia: Eleva el rendimiento de AWS Lambda. Ahí cubro métricas de invocación, benchmarks, y estrategias prácticas para llevar tus funciones al siguiente nivel.

Lo que aprendiste

Los cold starts son parte natural del modelo serverless. No son un bug, son un trade-off por no administrar servidores. Afectan menos del 1% de las invocaciones, pero cuando importan, importan mucho.

La duración depende del runtime, el tamaño del paquete, la memoria asignada, y la configuración de red. Optimizar el código es siempre el primer paso y no cuesta nada. Provisioned Concurrency y SnapStart son las dos soluciones de AWS cuando necesitas ir más allá.

Qué sigue

Ya entiendes qué son los cold starts y las estrategias para combatirlos. En el próximo artículo vamos a profundizar en Lambda SnapStart para Python: cómo funciona por debajo (Firecracker snapshots, cache en dos niveles), cómo activarlo paso a paso, cómo usar runtime hooks, y las mejores prácticas para sacarle el máximo provecho a tus funciones Python.

Código real. Configuración real. Resultados reales.

¿Te resultó útil este artículo? Compártelo con tu equipo o déjame saber en los comentarios qué otros temas de serverless te gustaría que cubriera. Y si ya estás lidiando con cold starts en producción, me encantaría escuchar cómo los resolviste.

Lambda Durable Functions mata a Step Functions... ¿o no?

Hazel Saenz — Thu, 12 Mar 2026 00:26:59 +0000

La verdad sobre cuándo usar cada una (y por qué necesitas entender ambas).

Al final de este artículo, sabrás exactamente cuándo elegir cada una.

Cuando AWS anunció Lambda Durable Functions en re:Invent 2025, mi primera reacción fue:

"Espera... ¿no es eso lo que hace Step Functions?"

Y no fui la única. En conversaciones con otros devs, la pregunta era siempre la misma:

¿Por qué dos herramientas para lo mismo?

Si ya tengo Step Functions orquestando workflows, ¿para qué necesito Durable Functions? ¿Es un reemplazo? ¿Debería migrar todo? Pasé días leyendo la documentación, probando ejemplos, y tratando de entender la diferencia real. Y descubrí algo que casi nadie estaba diciendo:

No son lo mismo. Ni siquiera intentan serlo.

La respuesta corta: No

Lambda Durable Functions no mata a Step Functions. Son dos filosofías diferentes para resolver el mismo problema. Step Functions orquesta visualmente, Durable Functions orquesta en código. Y aquí está lo interesante: ambas tienen su lugar. No es "una u otra". Es "cuál para qué".

El problema que ambas resuelven

Antes de hablar de diferencias, hay que entender qué problema están resolviendo.

Imagina que estás construyendo un sistema de procesamiento de imágenes. Un usuario sube una foto y necesitas:

Validar que el archivo es una imagen válida
Redimensionar a diferentes tamaños
Aplicar marca de agua
Generar thumbnails
Optimizar y guardar en S3

Suena simple, ¿no?

Pero cada paso puede fallar.

Cada paso puede tardar segundos... o minutos.

Y necesitas mantener el estado del procesamiento a través de todo el flujo.

Si la validación falla, no puedes continuar.

Si el redimensionamiento truena, necesitas reintentarlo sin volver a validar.

Si algo falla a la mitad, necesitas saber exactamente dónde quedó todo.

Esto es orquestación de workflows: coordinar múltiples pasos sin perder el estado, manejando errores y reintentos de forma elegante.

Tanto Step Functions como Durable Functions resuelven esto. Pero lo hacen de maneras completamente diferentes.

Step Functions: El enfoque visual

Step Functions es declarativo. Eso significa que defines qué debe pasar, no cómo hacerlo. Piensa en pedir un Uber: dices "llévame al aeropuerto" y alguien más decide la ruta, los giros, las autopistas. Tú solo declaras el destino.

Así se ve un workflow en Step Functions:

En el código del workflow en Step Functions no estás escribiendo código que ejecuta cada paso. Estás describiendo el flujo. Y AWS se encarga del resto: mantener el estado, manejar errores, reintentar cuando falla algo.

{
  "StartAt": "ValidateImage",
  "States": {
    "ValidateImage": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:function:ValidateImage",
      "Next": "ResizeImage"
    },
    "ResizeImage": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:function:ResizeImage",
      "Next": "ApplyWatermark"
    },
    "ApplyWatermark": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:function:ApplyWatermark",
      "Next": "GenerateThumbnails"
    },
    "GenerateThumbnails": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:function:GenerateThumbnails",
      "Next": "SaveToS3"
    },
    "SaveToS3": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:function:SaveToS3",
      "End": true
    }
  }
}

Cuándo brilla Step Functions

Hay escenarios donde este enfoque visual es perfecto:

Workflows con múltiples ramas y condiciones complejas
Si tu flujo tiene muchos "si esto, entonces aquello", Step Functions te deja verlo todo de un vistazo.
Equipos no técnicos necesitan entender la lógica
Product managers, QA, stakeholders... todos pueden abrir la consola de AWS y ver exactamente qué está pasando.
El workflow cambia frecuentemente
Ajustar un JSON es más rápido que reescribir código, hacer tests y deployar.
Integraciones directas con servicios AWS
DynamoDB, SNS, SQS... Step Functions los conecta sin escribir código.

Lambda Durable Functions: El enfoque code-first

Durable Functions es completamente diferente. Aquí no describes el flujo. Lo escribes.

Es code-first: código que ejecuta paso a paso, con checkpoints automáticos que mantienen el estado. Siguiendo la analogía del Uber: aquí tú manejas. Gira a la izquierda, sigue derecho tres cuadras, toma la autopista, sal en la salida 12. Tú controlas cada paso del camino.

Así se ve el mismo workflow en Durable Functions:

import { withDurableExecution, DurableContext } from '@aws/durable-execution-sdk-js';

export const handler = withDurableExecution(async (event, context: DurableContext) => {
    // Cada step es un checkpoint automático
    const validated = await context.step('validate-image', async () => 
        validateImage(event)
    );
    const resized = await context.step('resize-image', async () => 
        resizeImage(validated)
    );
    const watermarked = await context.step('apply-watermark', async () => 
        applyWatermark(resized)
    );

    return { status: "completed", result: watermarked };
});

Parece código normal, ¿verdad? Y lo es. Pero con un superpoder: cada step es un checkpoint. Si algo falla, el workflow se reanuda exactamente donde quedó. No pierdes estado. No repites trabajo.

Cuándo brilla Durable Functions

Este enfoque tiene sus propios momentos de gloria:

Workflows secuenciales con lógica compleja
Si tu flujo es más "haz esto, luego esto, luego esto" y menos "si esto entonces aquello", el código es más natural.
Tu equipo vive en el IDE
Developers que prefieren escribir código, hacer tests unitarios, usar breakpoints... esto se siente como casa.
Necesitas reutilizar lógica existente
Si ya tienes funciones de negocio en tu codebase, las puedes llamar directamente.
Transformaciones de datos complejas entre pasos
Escribir esa lógica en código es más claro que en JSON.

Las diferencias que importan

Ahora que viste ambos enfoques, aquí están las diferencias que realmente afectan tu decisión:

Aspecto	Step Functions	Durable Functions
Modelo	Declarativo (JSON/YAML)	Code-first (Python, Node.js, etc.)
Visualización	Nativa en consola AWS	Requiere herramientas externas
Debugging	Logs y trazas visuales	Breakpoints tradicionales
Complejidad	Excelente para flujos con branches	Excelente para lógica secuencial
Curva de aprendizaje	Sintaxis específica de ASL	Tu lenguaje de programación
Límite de payload	256 KB entre estados	6 MB entre pasos

No es que una sea mejor que la otra. Es que cada una brilla en escenarios diferentes.

El límite de payload: un detalle que importa

Hay algo que muchos descubren tarde: Step Functions tiene un límite de 256 KB para los datos que pasan entre estados.

Suena como mucho, hasta que no lo es.

Imagina que estás procesando una imagen grande con metadata extensa. O generando múltiples variaciones con información de cada una. O trabajando con respuestas de APIs que devuelven arrays grandes de datos de procesamiento.

De repente, ese límite de 256 KB se siente pequeño.

La solución típica es guardar los datos en S3 y pasar solo la referencia:

{
  "imageLocation": "s3://my-bucket/processed/image-123.jpg",
  "metadata": {
    "width": 1920,
    "height": 1080
  }
}

Funciona, pero agrega complejidad: más código, más servicios, más cosas que pueden fallar.

Durable Functions tiene un límite mucho más generoso: 6 MB entre pasos. Eso es 24 veces más espacio.

No significa que debas pasar 6 MB de datos entre pasos (probablemente no deberías). Pero sí significa que tienes más margen antes de necesitar workarounds.

Si tu workflow maneja datos grandes, esta diferencia puede ser decisiva.

Cuándo usar cada una

Aquí está la parte más importante del artículo. La pregunta no es "¿cuál es mejor?" sino "¿cuál necesito para este problema específico?"

Usa AWS Step Functions cuando:

Tu workflow tiene múltiples ramas condicionales (if/else complejos) → La visualización te ayuda a no perderte.
Necesitas que stakeholders no técnicos vean y entiendan el flujo → Abrir la consola de AWS es más fácil que explicar código.
El workflow cambia frecuentemente → Ajustar JSON es más rápido que reescribir, testear y deployar código.
Quieres visualización nativa sin configuración adicional → AWS te da todo out-of-the-box.
Trabajas con servicios AWS que tienen integraciones directas → DynamoDB, SNS, SQS... Step Functions los conecta sin escribir código.

Usa Durable Functions cuando:

Tu workflow es principalmente secuencial con lógica compleja → El código es más natural que describir cada paso en JSON.
Tu equipo prefiere trabajar completamente en código → IDE, tests unitarios, control de versiones... todo en un solo lugar.
Necesitas reutilizar lógica de negocio existente → Llamas funciones que ya tienes, sin adaptarlas.
Quieres debugging tradicional con breakpoints → Step-through, inspección de variables, todo lo que ya conoces.
El workflow requiere transformaciones de datos complejas entre pasos → Escribir esa lógica en código es más claro que en JSON.

Si después de leer esto sigues sin estar seguro... probablemente Step Functions es tu mejor opción. La visualización ayuda más de lo que crees cuando estás empezando.

Y si quieres una forma rápida de recordarlo:

📊 *Árbol de decisión *
Te dejo este árbol de decisión que puedes guardar o imprimir para tenerlo a mano cuando necesites elegir:

La verdad: se complementan

Aquí está el secreto que casi nadie menciona: Puedes usar ambas en la misma arquitectura. Imagina una arquitectura donde:

Step Functions orquesta el flujo principal de la aplicación:

→ Recibe la imagen
→ Valida formato
→ Procesa transformaciones
→ Notifica al usuario

Durable Functions maneja sub-procesos complejos dentro de cada paso:

→ Aplicar múltiples filtros con lógica compleja
→ Detección de contenido con reglas de negocio
→ Transformaciones de metadata entre sistemas

Step Functions te da la vista de 10,000 pies. Durable Functions te da el control fino donde lo necesitas. Algunos problemas se resuelven mejor con visualización. Otros se resuelven mejor con código.

Y ahora tienes ambas opciones.

Este es el primer artículo de una serie donde vamos a explorar Durable Functions en profundidad:

Construye tu primera AWS Lambda Durable Function: Instalación, setup y tu primer workflow funcional paso a paso
Multi-step workflows que sobreviven fallos: Cómo los checkpoints automáticos mantienen tu progreso incluso cuando algo truena
Callbacks y aprobaciones externas: Pausar workflows esperando input humano o eventos externos
Waits y condiciones: Suspender ejecución por horas o días sin pagar por tiempo idle
Ejecución en paralelo: Correr múltiples pasos al mismo tiempo y coordinar resultados

La pregunta no es "¿cuál va a sobrevivir?" Es "¿cuál necesito para este problema específico?" Y ahora ya sabes cómo responderla.

¿Qué viene después?

En el próximo artículo, vamos a construir tu primera AWS Lambda Durable Function desde cero: instalación, setup y un workflow funcional paso a paso. Código real, problemas reales, soluciones reales.

¿Te resultó útil este artículo? Compártelo con tu equipo o déjame saber en los comentarios qué otros temas de serverless te gustaría que cubriera. Y si ya estás usando Step Functions o Durable Functions en producción, me encantaría escuchar tu experiencia.

Amazon API Gateway: La puerta de entrada a tu backend en la nube

Hazel Saenz — Tue, 03 Mar 2026 14:57:58 +0000

Cómo API Gateway recibe requests y los conecta con tu lógica de backend.

Ya sabes qué es una API y por qué las aplicaciones se comunican haciendo peticiones.
Ya entiendes cómo una petición viaja desde tu app hasta el servidor.
Ya viste qué es REST y cómo el backend interpreta esa petición y decide qué responder.

Pero quedó una pregunta sin responder:

👉 ¿Cómo se implementa todo esto en la nube?

Porque una cosa es entender el concepto de una API REST, y otra muy distinta es desplegarla, gestionarla, escalarla, y mantenerla funcionando en producción.

Ahí es donde entra Amazon API Gateway.

No como una tecnología complicada que tienes que dominar desde cero. Sino como la puerta de entrada que maneja todo lo que pasa antes de que tu lógica de backend se ejecute.

Este artículo es para entender eso.

El problema que Amazon API Gateway resuelve

Imagina que construiste una aplicación que devuelve información de personajes de Harry Potter. Tu aplicación funciona perfecto: recibe un ID, busca en la base de datos, devuelve el personaje.

Pero ahora necesitas que tu app móvil pueda llamar a esa aplicación.

¿Cómo lo haces?

Podrías montar tu propio servidor. De hecho, eso es lo que los equipos hacían antes. Configuraban servidores con Nginx o Apache, instalaban load balancers, escribían reglas de enrutamiento, configuraban SSL manualmente, y monitoreaban logs constantemente.

Todo esto funcionaba. Pero requería experiencia en DevOps, mantener servidores 24/7, pagar por ellos aunque nadie los usara, y escalar manualmente cuando cambiaba el tráfico.

Amazon API Gateway elimina toda esa complejidad.

Es un servicio administrado que actúa como la puerta de entrada a tu backend. No es tu backend, no es donde vive tu lógica, no es donde guardas tus datos. Es el punto de entrada.

Piensa en API Gateway como el recepcionista de un edificio: recibe a todos los visitantes, verifica que tengan permiso, los dirige al piso correcto, pero no hace el trabajo de los que están en las oficinas.

No tienes que mantener servidores. No pagas cuando no hay tráfico. Escala automáticamente. Maneja HTTPS, configuración de seguridad para navegadores web, autenticación, y límites de peticiones por ti.

Es como tener un equipo de DevOps administrando tu puerta de entrada, pero sin tener que contratar a nadie.

Y lo más importante: te deja enfocarte en tu lógica de negocio, no en la infraestructura.

Cómo funciona el flujo básico

Cuando tu app hace una petición a una API desplegada con API Gateway:

La petición llega a API Gateway - Tu app hace un GET https://api.tuapp.com/personajes/8
API Gateway valida - Verifica que la petición esté bien formada y tenga permisos
Llama a tu backend - En este caso, ejecuta tu función Lambda
Devuelve la respuesta - Tu app recibe el JSON con la información del personaje

Todo ese proceso pasa en milisegundos.

Construyamos nuestra primera API con API Gateway + Lambda

Vamos a construir una API simple que devuelve información de un personaje de Harry Potter.

Para esto usaremos dos servicios de AWS:

AWS Lambda es un servicio que ejecuta tu código sin que tengas que administrar servidores. Tú solo subes tu código y Lambda se encarga de ejecutarlo cuando lo necesites. Aquí es donde vivirá nuestra lógica de negocio.

API Gateway será la puerta de entrada que recibe las peticiones HTTP y las conecta con nuestra función Lambda.

No te preocupes si es tu primera vez usando AWS. Vamos paso a paso.

Nota importante: Este tutorial puede realizarse completamente dentro de la capa gratuita de AWS, así que no tendrá ningún costo si tu cuenta es nueva o si no has excedido los límites gratuitos. Al final del artículo te mostraré cómo limpiar los recursos para evitar que se consuman tus créditos gratuitos (no se hará ningún cargo a tu tarjeta).

Paso 1: Crear la función Lambda

Primero necesitamos crear la función que contendrá nuestra lógica.

Crear la función:

Ve a la consola de AWS y busca "Lambda" en el buscador superior
Haz clic en "Create function" (Crear función)
Selecciona "Author from scratch" (Crear desde cero)
Configura tu función:
- Function name: obtenerPersonaje
- Runtime: Node.js 20.x (o la versión más reciente)
- Architecture: x86_64
Deja las demás opciones por defecto y haz clic en "Create function"

Agregar el código:

Una vez creada, verás el editor de código. Reemplaza el código por defecto con este:

export const handler = async (event) => {
  // Base de datos simulada de personajes
  const personajes = {
    "1": { id: 1, nombre: "Harry Potter", casa: "Gryffindor", poder: 95 },
    "2": { id: 2, nombre: "Hermione Granger", casa: "Gryffindor", poder: 98 },
    "3": { id: 3, nombre: "Ron Weasley", casa: "Gryffindor", poder: 85 },
    "8": { id: 8, nombre: "Ginny Weasley", casa: "Gryffindor", poder: 83 }
  };

  // Obtener el ID del personaje desde la petición
  const id = event.pathParameters?.id || "1";

  console.log('ID recibido:', id);

  // Buscar el personaje
  const personaje = personajes[id];

  // Si no existe, devolver error
  if (!personaje) {
    return {
      statusCode: 404,
      headers: {
        "Content-Type": "application/json"
      },
      body: JSON.stringify({ error: "Personaje no encontrado" })
    };
  }

  // Devolver el personaje encontrado
  return {
    statusCode: 200,
    headers: {
      "Content-Type": "application/json"
    },
    body: JSON.stringify(personaje)
  };
};

Haz clic en "Deploy" para guardar los cambios

Tu función Lambda ya está lista. Ahora vamos a conectarla con API Gateway.

Paso 2: Crear la API en API Gateway

Ve a la consola de AWS y busca "API Gateway"
Haz clic en "Create API" (Crear API)
Selecciona "REST API" (no la opción Private)
Haz clic en "Build" (Crear)
Configura tu API:
- Choose the protocol: REST
- Create new API: New API
- API name: API-Personajes
- Description: API para obtener información de personajes
- Endpoint Type: Regional
Haz clic en "Create API"

Paso 3: Crear el recurso y método

Ahora vamos a definir la estructura de nuestra API.

Crear el recurso principal:

En el panel izquierdo, verás tu API. Haz clic en "Create Resource" (Crear recurso)
Configura el recurso:
- Resource Name: personajes
- Resource Path: /personajes
Marca la opción "Enable API Gateway CORS" (esto permite que tu API sea llamada desde navegadores)
Haz clic en "Create Resource"

Crear el sub-recurso con parámetro:

Con el recurso /personajes seleccionado, haz clic en "Create Resource" nuevamente para crear un sub-recurso
Configura:
- Resource Name: {id}
- Resource Path: /{id}
- Marca "Enable API Gateway CORS"
Haz clic en "Create Resource"

Ahora tienes la ruta /personajes/{id} donde {id} es un parámetro dinámico.

Crear el método GET:

Con el recurso {id} seleccionado, haz clic en "Create Method" (Crear método)
Selecciona "GET" del dropdown y haz clic en el check ✓

Configurar la integración con Lambda:

Configura la integración:
- Integration type: Lambda Function
- IMPORTANTE: Marca la casilla "Use Lambda Proxy integration"
- Lambda Region: (tu región, por ejemplo us-east-1)
- Lambda Function: obtenerPersonaje (empieza a escribir y aparecerá)
- Deja las demás opciones por defecto
Haz clic en "Save"

Nota importante sobre Lambda Proxy Integration: Esta opción le dice a API Gateway que pase toda la información de la petición HTTP (headers, path parameters, query strings, body) directamente a tu función Lambda en el objeto event. Sin esta opción, tendrías que configurar manualmente cómo se mapean los parámetros, lo cual es más complejo y propenso a errores.

Aparecerá un mensaje pidiendo permiso para que API Gateway invoque tu Lambda. Haz clic en "OK"

Este paso es importante: le estás dando permiso a API Gateway para que pueda ejecutar tu función Lambda.

Sin este permiso, API Gateway no podría llamar a tu función cuando llegue una petición.

AWS maneja esto automáticamente por ti cuando haces clic en "OK".

Paso 4: Desplegar la API

Tu API está configurada, pero aún no está disponible públicamente. Necesitas desplegarla.

Haz clic en "Deploy API" en el menú superior
Configura el despliegue:
- Deployment stage: [New Stage]
- Stage name: prod
- Stage description: Producción
Haz clic en "Deploy"

¡Listo! Tu API ya está en producción.

Paso 5: Probar tu API

API Gateway te da una URL pública para tu API.

En la pantalla de "Stages", verás tu stage "prod"
Expande el árbol: prod → /personajes → /{id} → GET
En la parte superior verás la "Invoke URL" La URL se verá algo así:

https://abc123xyz.execute-api.us-east-1.amazonaws.com/prod/personajes/8

Copia esa URL y ábrela en tu navegador (cambia el 8 por 1, 2, 3, u 8 para ver diferentes personajes)

También puedes probarla desde la terminal:

curl https://tu-url-aqui.execute-api.us-east-1.amazonaws.com/prod/personajes/8

Deberías ver una respuesta como esta:

{
  "id": 8,
  "nombre": "Ginny Weasley",
  "casa": "Gryffindor",
  "poder": 83
}

¿Qué acabas de hacer?

Acabas de construir una API REST completa en la nube:

Creaste una función Lambda con tu lógica de negocio
Configuraste API Gateway como punto de entrada
Definiste una ruta con parámetros dinámicos (/personajes/{id})
Desplegaste tu API en producción
Obtuviste una URL pública que cualquiera puede llamar

Todo sin:

Montar servidores
Configurar balanceadores de carga
Manejar certificados SSL
Escribir código de infraestructura

Eso es el poder de serverless + API Gateway.

Limpieza: Eliminar los recursos

Si solo estás probando y no quieres que estos recursos sigan activos en tu cuenta de AWS, es importante eliminarlos para evitar que se consuman tus créditos gratuitos (si estás en la capa gratuita) o para evitar cargos innecesarios.

Eliminar la API en API Gateway

Ve a la consola de API Gateway
Selecciona tu API API-Personajes
Haz clic en "Actions" → "Delete API"
Confirma escribiendo el nombre de la API y haz clic en "Delete API"

Eliminar la función Lambda

Ve a la consola de Lambda
Selecciona tu función obtenerPersonaje
Haz clic en "Actions" → "Delete"
Confirma la eliminación

Con esto, todos los recursos del tutorial están eliminados y no generarán cargos en tu cuenta.

Por qué esto importa para arquitecturas serverless

Porque en serverless, tus funciones no están "corriendo" todo el tiempo. Se ejecutan cuando las llamas. Y se apagan cuando terminan. Pero tu app necesita una URL estable. Un punto de entrada que siempre esté disponible. API Gateway es ese punto de entrada.

Tu app siempre llama a la misma URL. API Gateway siempre está ahí. Y cuando llega una petición, despierta tu Lambda, la ejecuta, y devuelve la respuesta.

Sin API Gateway, serverless no funcionaría para APIs públicas.

Lo que aprendiste

API Gateway es la puerta de entrada, no el backend.
Recibe peticiones HTTP y las conecta con tu lógica real.
Maneja validación, transformación, seguridad, y throttling.
Puede integrarse con Lambda, HTTP endpoints, o servicios de AWS.
Incluye características de gestión de APIs sin código adicional.
Es esencial para arquitecturas serverless.

No es magia. Es infraestructura que alguien más mantiene por ti.

Y esa diferencia es lo que te permite construir APIs en producción sin tener que ser experto en DevOps.

Qué sigue

API Gateway es la puerta de entrada, no el backend.
Recibe peticiones HTTP y las conecta con tu lógica real.
Maneja validación, transformación, seguridad, y límites de peticiones.
Puede integrarse con Lambda, HTTP endpoints, o servicios de AWS.
Incluye características de gestión de APIs sin código adicional.
Es esencial para arquitecturas serverless. Ahora tienes las bases para construir tus propias APIs.

No porque hayas memorizado sintaxis o comandos.

Sino porque entiendes cómo funciona la conversación de principio a fin.

Y esa claridad es lo que te permite construir mejor, debuggear más rápido, y diseñar con más confianza.

Qué es REST y cómo responde a un request

Hazel Saenz — Tue, 24 Feb 2026 20:52:08 +0000

Una explicación simple para entender cómo el backend interpreta lo que pides y decide qué responderte.

Ya sabes que las aplicaciones hacen peticiones, ya sabes que esas peticiones viajan por la red hasta llegar a un servidor, pero quedó una pregunta sin responder:

👉 ¿Qué pasa cuando la petición llega? ¿Cómo sabe el servidor qué hacer con ella?

Esa es la parte que casi nunca se explica bien. Y es justo ahí donde entra REST.

No como una tecnología mágica, no como un framework que instalas. Sino como una forma de organizar la conversación entre quien pide y quien responde.

Este artículo es para entender eso.

La petición llegó. ¿Y ahora qué?

En el artículo anterior vimos el viaje completo de una petición: desde que sale de tu app, viaja por la red, llega al servidor, y regresa con una respuesta.

Pero quedó pendiente entender qué pasa exactamente cuando esa petición llega al servidor.

Imagina que tu app envía esta petición:

GET /personajes/8

El servidor la recibe. La lee. Y tiene que decidir:

¿Qué está pidiendo?
¿Qué debería responder?
¿Cómo debería estructurar esa respuesta?

Si no hay reglas claras, cada servidor podría interpretar eso de forma diferente.

Uno podría pensar que /personajes/8 significa "dame el personaje con ID 8".
Otro podría pensar que significa "borra el personaje 8".
Otro podría no entender nada.

REST existe para evitar ese caos.

Define un conjunto de reglas que hacen que la conversación sea predecible.

REST no es una tecnología

Aquí es donde empieza la confusión.

REST no es:

Un lenguaje de programación
Un framework que instalas
Una librería que importas

REST es un estilo de comunicación.

Un acuerdo sobre cómo estructurar las peticiones y las respuestas para que ambas partes se entiendan sin necesidad de conocerse por dentro.

Piensa en REST como las reglas de una conversación educada:

Cuando preguntas algo, lo haces de forma clara
Cuando respondes, das información útil
Ambas partes saben qué esperar del otro

Eso es REST. Nada más. Nada menos.

Las peticiones expresan intención

En REST, cada petición tiene dos partes clave:

El recurso (qué estás pidiendo)
El verbo HTTP (qué quieres hacer con ese recurso)

Volviendo al ejemplo:

GET /personajes/8

Recurso: /personajes/8 (el personaje con ID 8)
Verbo: GET (quiero obtener información)

El verbo no es un comando. Es una intención.

No le estás diciendo al servidor "ejecuta esta función". Le estás diciendo "esto es lo que quiero hacer". Y el servidor decide cómo hacerlo.

Los verbos HTTP como lenguaje

REST usa los verbos HTTP para expresar intenciones comunes:

GET: "Quiero ver algo"

GET /personajes/8

"Dame información del personaje 8"

No modifica nada. Solo pide información.

POST: "Quiero crear algo nuevo"

POST /personajes
{
  "nombre": "Luna Lovegood",
  "casa": "Ravenclaw"
}

"Crea un nuevo personaje con esta información"

PUT/PATCH: "Quiero actualizar algo"

PATCH /personajes/8
{
  "poder": 90
}

"Actualiza el poder del personaje 8"

DELETE: "Quiero eliminar algo"

DELETE /personajes/8

"Elimina el personaje 8"

No tienes que memorizar esto. Solo tienes que entender que cada verbo expresa una intención diferente. Y REST usa esas intenciones para organizar la conversación.

Recursos, no acciones

Aquí hay algo importante que muchas veces se pasa por alto: En REST, las URLs representan recursos, no acciones.

Por ejemplo:

❌ Mal diseño (acciones en la URL):

POST /crearPersonaje
POST /eliminarPersonaje
POST /actualizarPersonaje

✅ Buen diseño (recursos + verbos):

POST /personajes
DELETE /personajes/8
PATCH /personajes/8

¿Ves la diferencia?

En el primer caso, la URL dice qué hacer. En el segundo caso, la URL dice sobre qué y el verbo dice qué hacer.

Esa separación hace que las APIs sean más claras y predecibles.

El servidor interpreta y decide

Cuando el servidor recibe una petición REST, sigue un proceso:

Lee el verbo: ¿Qué quiere hacer?
Lee el recurso: ¿Sobre qué?
Evalúa: ¿Tiene permiso? ¿Existe ese recurso?
Ejecuta la lógica: Busca en la base de datos, procesa, valida
Construye la respuesta: Decide qué devolver

Por ejemplo, si recibe:

GET /personajes/8

El servidor:

Identifica que es una petición GET (quiere información)
Identifica que el recurso es /personajes/8
Busca en la base de datos el personaje con ID 8
Si lo encuentra, lo devuelve
Si no lo encuentra, responde con un error

Todo eso pasa en el backend.

La app que hizo la petición no sabe cómo se hizo.

Solo sabe que si pide de esa forma, va a recibir lo que necesita.

Las respuestas tienen significado

En REST, las respuestas no son solo datos. Son decisiones estructuradas.

Cada respuesta incluye:

1. Un código de estado

Que dice qué pasó:

200 OK: Todo bien, aquí está lo que pediste
201 Created: Se creó algo nuevo
404 Not Found: No encontré lo que pediste
400 Bad Request: Tu petición está mal formada
500 Internal Server Error: Algo falló de mi lado

Estos son solo algunos de los códigos más comunes. Los códigos de estado HTTP son estándar, pero cada tipo de servidor puede manejar y devolver errores de forma ligeramente diferente. Puedes ver la lista completa de códigos de estado HTTP en la documentación de MDN.

2. Un cuerpo de respuesta

Que contiene la información:

{
  "id": 8,
  "nombre": "Ginny Weasley",
  "casa": "Gryffindor",
  "poder": 83
}

3. Headers (opcional)

Que dan contexto adicional:

Content-Type: application/json
Cache-Control: max-age=3600

Por ejemplo:

Content-Type: application/json indica que la respuesta está en formato JSON
Cache-Control: max-age=3600 indica que la respuesta puede guardarse en caché por 1 hora

Todo eso junto forma una respuesta completa. No es solo "aquí están los datos". Es "esto es lo que pasó, esto es lo que encontré, y así deberías interpretarlo".

Por qué REST reduce la confusión

Porque cuando todos siguen las mismas reglas:

Las peticiones son predecibles
Las respuestas tienen estructura
Los errores tienen significado
No tienes que adivinar cómo funciona cada API

Sin REST (o sin algún estilo similar), cada API sería diferente:

Unos usarían POST para todo
Otros inventarían sus propios códigos de error
Otros mezclarían acciones y recursos sin criterio

REST no es perfecto. Pero es un acuerdo que funciona.

Y cuando lo entiendes, dejas de ver las APIs como algo mágico y empiezas a verlas como lo que son: conversaciones con reglas claras.

Lo que aprendiste

REST es un estilo de comunicación, no una tecnología.
Las peticiones expresan intención a través de verbos HTTP.
Los recursos representan qué, no cómo.
El servidor interpreta la petición y decide qué responder.
Las respuestas tienen significado, no solo datos.
REST reduce el caos al establecer reglas claras para la conversación.
Entender REST no es memorizar verbos. Es entender por qué las APIs se diseñan de cierta forma. Y esa claridad es lo que te permite construir mejor, debuggear más rápido, y diseñar con más confianza.

Qué sigue

Ya entiendes qué es REST y cómo organiza la conversación entre quien pide y quien responde.

En el siguiente artículo vamos a ver cómo se implementa esto en la nube usando Amazon API Gateway.

Vas a entender cómo API Gateway actúa como la puerta de entrada a tu backend, cómo recibe peticiones REST, y cómo las conecta con tu lógica (ya sea en Lambda, en un servidor HTTP, o en otros servicios de AWS).

Ya sabes cómo funciona la conversación. Ahora es momento de ver cómo se despliega en producción.

A dónde va una petición cuando la envías (y qué pasa en el camino)

Hazel Saenz — Tue, 17 Feb 2026 14:35:30 +0000

Una explicación simple del viaje completo: desde que tu app pide algo hasta que recibe respuesta.

Ya sabes que las aplicaciones se comunican haciendo peticiones.

Tocas un botón. ➡️ La app pide algo. ➡️ Algo responde.

Pero entre ese "pedir" y ese "responder" hay un viaje completo. Y casi nunca se explica.

La mayoría de las veces, cuando aprendes sobre APIs, te dicen:

"La app hace una petición"
"El servidor responde"

Y listo.

Como si todo pasara instantáneamente. Como si no hubiera nada en el medio. Pero sí lo hay.

Y entender ese recorrido es lo que te ayuda a dejar de ver las APIs como algo abstracto y empezar a verlas como lo que son: conversaciones con pasos claros. Este artículo es ese mapa.

En el artículo anterior vimos que las aplicaciones no guardan todo localmente.

Cuando necesitan algo, preguntan, hacen una petición y esperan una respuesta.

Eso es una API: el acuerdo que define cómo se hace esa conversación. Pero quedó una pregunta sin responder:

👉 ¿Qué pasa entre el momento en que la app envía la petición y el momento en que recibe la respuesta?

Eso es lo que vamos a ver ahora.

Una petición sale de la app

Imagina que abres una app de Harry Potter y buscas información sobre "Ginny Weasley". (Y sí, si me conoces sabes que soy fan de Harry Potter, así que este ejemplo me hace especialmente feliz 😊)

La app no tiene todos los datos de los personajes guardados en tu teléfono. Así que hace una petición:

GET /personajes?nombre=Ginny+Weasley

Esa petición es un mensaje, no es código que se ejecuta en otro lugar, no es un archivo que se envía, es simplemente información estructurada que dice:

Qué quiero: información de personajes
Sobre quién: Ginny Weasley
Cómo lo pido: usando el método GET

Ese mensaje sale de tu app. Y empieza su viaje.➡️ ✉️

El viaje a través de la red

Tu petición no llega directamente al servidor, pasa por varios puntos en el camino:

Sale de tu dispositivo (tu teléfono, tu computadora)
Pasa por tu red local (tu WiFi o datos móviles)
Viaja por internet (a través de routers, cables, infraestructura)
Llega al servidor que tiene la información

Cada uno de esos pasos toma tiempo, a veces milisegundos y a veces segundos; por eso a veces una app carga rápido y otras veces tarda, no siempre es culpa de la app. A veces es el camino.

👉 Prueba este ejemplo interactivo para ver en acción cómo funciona una petición a una API de Harry Potter. Puedes ver el código de la demo en GitHub para entender cómo está construida.

El servidor recibe la petición

Cuando la petición llega al servidor, no se ejecuta automáticamente.

El servidor la recibe y la evalúa.

Piensa en el servidor como un portero que revisa cada mensaje que llega:

¿Esta petición está bien formada?
¿Tiene permiso para pedir esto?
¿Entiendo lo que está pidiendo?

Si algo falla en esta etapa, el servidor responde con un error.

Por ejemplo:

Si pediste algo que no existe: 404 Not Found
Si no tienes permiso: 403 Forbidden
Si la petición está mal hecha: 400 Bad Request

Pero si todo está bien, el servidor pasa a la siguiente etapa.

El proceso de decisión

Aquí es donde pasa la magia. El servidor no solo devuelve información, decide qué devolver.

Siguiendo el ejemplo de la app de Harry Potter:

El servidor recibe: GET /personajes?nombre=Ginny+Weasley
Busca en su base de datos información sobre "Ginny Weasley"
Recopila todos los datos del personaje (casa, varita, patronus, etc.)
Puede que incluya información relacionada (amigos, hechizos favoritos)
Procesa esa información
La estructura en el formato acordado (generalmente JSON)

Todo eso pasa en el backend.

La app que hizo la petición no sabe cómo funciona ese proceso.
No sabe si el servidor usa una base de datos SQL o NoSQL.
No sabe cómo funciona el algoritmo de recomendación.
No sabe si está en un servidor en California o en Singapur.

Solo sabe que si pide de cierta forma, va a recibir lo que necesita.

Esa es la belleza de las APIs: separan el "qué" del "cómo".

La respuesta regresa

Una vez que el servidor termina de procesar, construye una respuesta:

{
  "id": 8,
  "nombre": "Ginny Weasley",
  "casa": "Gryffindor",
  "poder": 83,
  "hechizo": "Reducto",
  "defensa": 77,
  "imagen": "🧙‍♀️"
}

Esa respuesta hace el viaje de regreso:

Sale del servidor
Viaja por internet
Pasa por tu red local
Llega a tu dispositivo
Tu app la recibe

El mismo camino, pero en reversa.

Cómo reacciona la app

Cuando la app recibe la respuesta, reacciona, no decide, no procesa lógica compleja, solo toma lo que recibió y lo muestra.

En este caso:

Muestra la foto del personaje
Muestra su casa y escudo de Gryffindor
Muestra información sobre su hechizo
Muestra información de defensa

Si la respuesta hubiera sido un error, la app mostraría un mensaje de error.

La app depende completamente de lo que el servidor responda.

Por eso cuando una API falla, la app no puede hacer nada, no puede inventar personajes, no puede adivinar información, solo puede mostrar que algo salió mal.

Por qué importa entender este flujo

Porque cuando entiendes que una petición es un viaje, no un evento instantáneo, empiezas a ver por qué:

Las apps a veces tardan en cargar (el viaje puede ser largo)
Los errores no siempre son culpa de la app (pueden pasar en cualquier punto del camino)
El backend tiene que ser confiable (es el que decide qué responder)
Las APIs bien diseñadas importan (hacen que todo este proceso sea predecible)

No es magia.n Es un proceso con pasos claros.

Y cuando algo falla, saber dónde buscar hace toda la diferencia.

Lo que aprendiste

Una petición no es un solo paso, es un viaje completo:

La app envía un mensaje
Ese mensaje viaja por la red
El servidor lo recibe y evalúa
El servidor decide qué responder
La respuesta regresa por el mismo camino
La app reacciona a lo que recibió

Las aplicaciones dependen de las respuestas.

Los servidores deciden.

Las APIs definen las reglas de esa conversación.

Entender este flujo te da claridad, y esa claridad es lo que te permite construir mejor, debuggear más rápido, y diseñar con más confianza.

Qué sigue

En el siguiente artículo vamos a dar el siguiente paso: construiremos nuestra primera API REST.

Vas a ver cómo crear un servidor que reciba peticiones, procese información y devuelva respuestas.

Ya entiendes el viaje completo de una petición.

Ahora es momento de construir el destino.

AWS Valentine’s LATAM: cuando el amor también se despliega en la nube

Hazel Saenz — Thu, 12 Feb 2026 01:22:37 +0000

Una colección de frases dev-amor inspiradas en AWS, creadas desde LATAM para celebrar San Valentín con humor, ternura y comunidad.

San Valentín no siempre se trata de flores o chocolates. A veces se trata de cómo explicamos lo que sentimos, usando el lenguaje que mejor conocemos.

En nuestro caso: el lenguaje de los devs.

El origen de esta idea

Hace unos días vi una serie de tarjetas de San Valentín creadas por Brooke Jamieson para la comunidad de AWS.
Eran divertidas, simples y muy nerd… y me hicieron sonreír.

Pero sobre todo, me hicieron pensar:

¿Cómo se vería esto si lo contáramos desde LATAM?

Con nuestro humor. Nuestra cercanía. Nuestra forma intensa, caótica y honesta de vivir tanto el código como las relaciones.

Así nació AWS Valentine’s LATAM.

No como una traducción. Sino como una reinterpretación con identidad propia.

Dev-amor, pero con acento latino

Estas frases no están pensadas solo para ingenieras o ingenieros.
Están pensadas para cualquiera que haya:

deployado con miedo, celebrado que “ya funciona”, sufrido un outage o encontrado refugio en alguien que se queda cuando todo falla.

Eres mi región primaria

(Amazon Route 53 / Multi-Region)
Porque mi tráfico siempre apunta a ti. Eres mi región primaria (y no hago failover).

Eres la respuesta correcta

(Amazon API Gateway)

Eres la respuesta correcta, a todas mis peticiones.

No importa la distancia

(Amazon CloudFront)

No importa la distancia, igual llegas a mi edge.

Funciona por fe

(AWS Lambda)

Funciona por fe, y porque tú estás ahí.

Nuestro amor sobrevivió

(Amazon CloudWatch / Outage vibes)

Se cayó todo… menos nosotros. Nuestro amor sobrevivió al outage.

No me asustas, me acompañas

(Kiro – agentic AI, spec-driven dev)

No me asustas, me acompañas. Contigo todo empieza como idea y termina en algo real.

Guardado para siempre

(Amazon S3)

Aunque el mundo se mueva, lo nuestro no se pierde.

¿Por qué compartir esto?

Porque la tecnología también puede ser suave.
Porque no todo contenido técnico tiene que ser rígido.
Porque las comunidades se construyen con conocimiento, sí…
pero también con emoción, cercanía y humanidad.

Y porque en LATAM: amamos intenso, incluso cuando hablamos de la nube.

Para la comunidad

Si alguna de estas frases te hizo sonreír, si te recordó a alguien, o si te dan ganas de compartirla en tu equipo, comunidad o meetup: misión cumplida.

Gracias a la comunidad de AWS por inspirar, y a personas como Brooke por recordarnos que el tech también puede ser divertido.

Feliz San Valentín, desde LATAM, con amor y con cloud.

Qué pasa realmente cuando una app pide algo

Hazel Saenz — Fri, 06 Feb 2026 01:40:19 +0000

Una explicación simple para entender cómo se comunican las aplicaciones (y por qué a eso le llamamos API).

Abres una app. ➡️ Tocas un botón. ➡️ Algo carga.
No piensas mucho en eso. Solo esperas que funcione.
Pero detrás de ese gesto tan simple, hay una conversación ocurriendo.

Tu app de música no guarda millones de canciones en tu teléfono.
Tu app del clima no tiene sensores en cada ciudad.
Tu app de delivery no cocina la comida.

Lo que hacen es pedirle esa información a otros sistemas.

Esa conversación casi nunca se explica.

Si alguna vez viste que una app “pide algo” y otra le responde, y sentiste que entendías lo suficiente para seguir, pero no tanto como para explicarlo… este artículo es para ti.

No es magia. Es una conversación.

Cuando una aplicación necesita algo que no tiene —datos, resultados, información— no entra al sistema del otro lado como si fuera su casa.

No toca lo que no le corresponde.
No improvisa.
No adivina.

Hace algo más simple:

👉 pregunta. Y espera una respuesta.

Imagina que abres Spotify y buscas "Bad Bunny".
La app no tiene todas las canciones guardadas en tu teléfono.
Hace una petición: "Dame las canciones de Bad Bunny".
El servidor responde con la lista.

La app hace una petición clara.
El sistema del otro lado responde solo lo que prometió responder.

Ni más. Ni menos. No hay magia. Hay reglas.

Antes de ponerle nombre, mira lo que pasa

Una app necesita información.
No sabe cómo está construido el sistema del otro lado.
No le importa si usa Java, Python o cualquier otra cosa.

Solo sabe dos cosas: qué puede pedir y qué va a recibir a cambio.

Volviendo al ejemplo:

Petición:
GET /buscar?artista=bad-bunny

Respuesta:
{
  "artista": "Bad Bunny",
  "canciones": ["DÁKITI", "Tití Me Preguntó", "Callaíta", ...]
}

La app no sabe dónde están guardadas esas canciones.
No sabe si el servidor usa una base de datos SQL o NoSQL.
Solo sabe que si pide de esa forma, va a recibir lo que necesita.

Ese intercambio existe aunque casi nunca lo nombremos. Está ahí cada vez que una app pide algo y otra responde.

Eso tiene un nombre: API

A esa forma de comunicarse se le llama API.

No es el sistema completo.
No es la base de datos.
No es la lógica interna.

Es el acuerdo que define cómo dos partes se hablan sin conocerse por dentro.
Y aquí es donde empiezan muchos de los malentendidos.

Mito #1: “Una API es el backend”

No. El backend es todo lo que pasa detrás:lógica, datos, procesos, decisiones.

La API es la puerta, no la casa.

Es lo único que se muestra hacia afuera.
Lo que marca el límite entre lo que se puede usar y lo que no.

Cuando estas dos cosas se confunden, suele pasar que:

se exponen cosas que no deberían
se rompen acuerdos sin darse cuenta
se diseña pensando en el sistema, no en quien lo usa

Mito #2: “Una API es solo una dirección”

Muchas veces se piensa que una API es solo “el lugar al que haces la petición”.

Como si todo se redujera a mandar algo y esperar respuesta.
Pero una dirección por sí sola no explica nada.

Puede decirte a dónde ir, pero no te dice:

qué puedes pedir
cómo hacerlo
ni qué significa lo que recibes de vuelta

Por ejemplo, /buscar?artista=bad-bunny es una dirección.
Pero sin saber que:

debes usar el método GET
el parámetro se llama artista
la respuesta será un JSON con canciones

...esa dirección no te sirve de mucho.

Esa dirección —a la que luego llamamos endpoint—, el punto específico donde se hace la petición, solo cobra sentido cuando existen reglas claras alrededor.

Una API no es solo el punto de entrada. Es el acuerdo completo que le da significado a la conversación.

Entonces… ¿qué hacen realmente las APIs?

Las APIs reducen el caos. Permiten que sistemas distintos:

trabajen juntos
sin depender uno del otro
sin romperse cada vez que algo cambia

Por ejemplo:

Spotify puede mostrar canciones de Bad Bunny sin importar si:

el servidor de música está en AWS o en otro cloud provider
la base de datos cambió de MySQL a PostgreSQL
el equipo de backend reescribió todo en otro lenguaje

Mientras la API siga respondiendo de la misma forma, la app sigue funcionando.

Eso es lo que hace que puedas usar la misma app en tu teléfono durante años, aunque todo detrás haya cambiado varias veces.

Cuando una API está bien diseñada, casi no se nota. Cuando no lo está, se siente en cada error, en cada confusión, en cada workaround.

Por qué importa entender esto desde el inicio

Porque cuando no tienes claro qué es una API, todo parece más complejo de lo que es.

No porque falte aprender más, sino porque muchas veces nadie explicó bien el contexto.

Este es solo el comienzo

Este artículo no es para memorizar definiciones.
Es para empezar a ver algo que ya estaba ocurriendo.

En los siguientes artículos vamos a mirar con más detalle:

qué pasa realmente cuando una app hace una petición
por qué REST no es el problema
por qué muchas APIs fallan sin estar “rotas”
y cómo diseñarlas pensando en personas, no solo en sistemas

Si alguna vez sentiste que las APIs eran algo que usabas, pero que nadie te había explicado con claridad… A veces no falta aprender más, sino que alguien explique mejor.

Guía práctica de colas: el secreto para sobrevivir picos de tráfico

Hazel Saenz — Thu, 29 Jan 2026 16:24:04 +0000

Construir servicios en la nube es emocionante… hasta que llega el primer pico de tráfico serio. Ese día, un servicio que funcionaba perfecto durante semanas, de pronto empieza a fallar, a lanzar timeouts y a colapsar sin piedad.

Cuando lo viví la primera vez, pensé:

"¿Qué hice mal? ¿Por qué si el sistema está bien diseñado… simplemente no aguanta?"

Con el tiempo descubrí que el problema no era el código, ni la infraestructura, ni la configuración. Era algo mucho más básico:

No todos los servicios procesan trabajo al mismo ritmo.

Y cuando un servicio produce más de lo que otro puede consumir… algo truena. Ahí es donde entran las colas. Y una vez las entiendes, te preguntas cómo viviste sin ellas tanto tiempo.

El problema real: servicios que no respiran igual

Imagina un sistema donde un proceso genera miles de operaciones por segundo. Pero el servicio que las recibe sólo puede procesar una parte antes de saturarse. Si no hay nada entre ellos, ocurre el desastre perfecto: el servicio receptor se ahoga, se detiene, entra en cascada el resto de la arquitectura, y llega el apagón.

🔴 El servicio se satura sin un buffer intermedio

Tal como vemos en el gráfico: cuando el proceso genera miles de operaciones por segundo, pero el servicio tiene un límite de procesamiento. Si le llegan más solicitudes de las que puede manejar, colapsa. No hay nada que absorba el impacto, no hay espacio para respirar.

Los tres pilares: eventos, mensajes y colas

Antes de hablar de colas es importante entender tres piezas que siempre trabajan juntas y forman la base de cómo se comunican los sistemas distribuidos: los eventos, los mensajes y las colas.

Vamos de uno en uno.

¿Qué es un evento?

Un evento es algo que ocurrió en tu sistema y que podría ser relevante para otros componentes o servicios, como por ejemplo:

Se registró un usuario
Se pagó una orden
Se generó una factura
Se cargó un archivo

Un evento representa un cambio de estado.

¿Qué es un mensaje y cómo se relaciona con un evento?

El evento no se mueve solo: lo empaquetamos dentro de un mensaje.

El mensaje es el sobre/contenedor
El evento es el contenido que va dentro

Un mensaje suele tener:

body: contiene el evento serializado (generalmente JSON)
metadata: información útil (correlationId, timestamps, tipo de evento, origen)

¿Qué es una cola?

Una cola es un lugar intermedio donde los mensajes esperan hasta que alguien los procese. Si lo llevamos a la vida real, es como la fila del banco o del súper:

Las personas (mensajes) llegan, se forman, avanzan cuando les toca y, cuando las atienden, salen de la fila.

En software pasa lo mismo:

El productor envía mensajes a la cola
La cola los almacena de forma temporal
Uno o varios consumidores los van tomando para procesarlos

Lo importante de una cola no es solo "guardar cosas", sino lo que habilita en tu arquitectura:

Desacopla al que envía del que procesa
Protege a tu sistema de picos de tráfico, actuando como un buffer
Permite escalar consumidores sin cambiar la forma en que los mensajes llegan
Puede ofrecer garantías de orden (como las colas FIFO) o priorizar la velocidad (como las colas estándar)

Si lo vemos en nuestro ejemplo se vería de la siguiente forma:

¿Qué significa enviar un evento a una cola?

El flujo conceptual siempre es el mismo:

Algo ocurre
Se construye un evento
Se crea un mensaje
El mensaje se envía a la cola
La cola lo almacena
Un consumidor lo procesa
Tras procesarlo, el mensaje se elimina

Tipos de colas

Cola FIFO (First In First Out)

Garantizan que el primer mensaje en entrar es el primero en salir. Características:

✅ Deduplicación automática
⚠️ Throughput menor
🎯 Perfectas para flujos secuenciales: pagos, órdenes, pasos obligatorios

Cola estándar (Standard)

No garantiza orden estricto. Características:

✅ Alta velocidad
✅ Throughput masivo
🎯 Ideales para procesamiento masivo: logs, telemetría, tareas repetitivas

Restricciones importantes

⚠️ Restricciones de tamaño

Toma en cuenta que las colas no están diseñadas para transportar información pesada como por ejemplo:

❌ Videos
❌ PDFs enormes
❌ Imágenes grandes
❌ Binarios

El mensaje debe ser pequeño.

Si necesitas manejar algo grande, envía solo una referencia, por ejemplo una URL a un archivo en Amazon Simple Storage Service (Amazon S3):

{
  "fileUrl": "https://s3.com/bucket/reporte.pdf",
  "action": "PROCESS_FILE"
}

Este patrón es universal en casi todos los sistemas de colas.

¿Por qué usar colas? ¿Cuándo sí y cuándo no?

✅ Cuándo SÍ usar colas

Las colas resuelven problemas concretos como el que comenté al inicio, pero existen más casos donde son una buena idea:

✅ Cuando tu backend tarda más de lo que el cliente puede esperar
✅ Cuando necesitas reintentos automáticos
✅ Cuando una dependencia es lenta o poco confiable
✅ Cuando quieres desacoplar partes del sistema

❌ Cuándo NO usar colas

Pero ten cuidado, como todo, existen casos donde no las necesitas y es mejor evitarlas:

❌ Chats o videojuegos en tiempo real
❌ Procesos que requieren respuesta inmediata
❌ Lógica que depende del orden exacto en escenarios donde este no puede garantizarse
❌ Situaciones donde necesitas sincronización estricta entre servicios

Implementación práctica con Amazon Simple Queue Service (Amazon SQS)

Para entender en la vida real cómo una cola puede salvar tu arquitectura de un colapso durante picos de tráfico, preparé un demo completo que compara ambos escenarios: con y sin colas.

🔗 Queue 101 Demo - Repositorio en GitHub

El demo incluye ejemplos de código funcional, configuración de infraestructura con AWS CDK, y una comparación práctica que demuestra cómo las colas protegen tu sistema durante picos de tráfico. Incluye instrucciones paso a paso para reproducir ambos escenarios y ver la diferencia en acción.

Conclusión

Las colas no son un detalle técnico opcional. Son una herramienta esencial cuando buscas construir aplicaciones confiables, escalables y resilientes.

No importa si usas AWS, RabbitMQ, Kafka o cualquier otra plataforma: los conceptos son los mismos. Y con esto en mente ya dominas el superpoder de evitar que tus servicios colapsen durante un pico de tráfico.

🌟 Sigue explorando, sigue aprendiendo y disfruta del proceso.

Chatea con tu propia data: guía práctica con Strands y Amazon Bedrock

Hazel Saenz — Fri, 12 Sep 2025 03:33:39 +0000

En los últimos meses he estado experimentando con diferentes formas de conectar agentes inteligentes con bases de conocimiento en AWS, y uno de los enfoques que más me ha gustado es combinar Strands con una Knowledge Base de Amazon Bedrock.

Cuando comencé esta prueba de concepto, mi objetivo era claro: construir una API de chat que no solo respondiera con información general, sino que también pudiera apoyarse en datos contextuales —en este caso, una Knowledge Base con información de libros de Harry Potter. Y aunque suene complejo, la buena noticia es que con la arquitectura serverless de AWS y librerías como strands-agents, el proceso se vuelve mucho más accesible.

En este artículo te mostraré cómo usar el repositorio strands-poc
para crear tu propia integración paso a paso.

¿Qué vas a lograr?

Una API con dos endpoints: /health y /chat.
Una Lambda en contenedor que usa strands-agents para manejar el flujo conversacional.
Una Knowledge Base en Amazon Bedrock conectada para responder con datos relevantes.
Toda la infraestructur a desplegada con AWS CDK.

Requisitos previos

Cuenta de AWS con acceso a Bedrock y Knowledge Bases.
Python 3.12.
Docker y AWS CLI configurados.
AWS CDK instalado.
Permisos IAM adecuados para Bedrock, Lambda y API Gateway.

Arquitectura general

La solución se compone de:

API Gateway con dos endpoints.
Lambda containerizada (Python 3.12) con Strands.
Knowledge Base en Bedrock (fuente de datos sincronizada).
CDK para desplegar todo.

Paso a paso

Crear la Knowledge Base en Bedrock

Ve a la consola de Amazon Bedrock → Knowledge bases.
Crea una nueva KB con tu modelo de embeddings favorito.
Configura el origen de datos (ejemplo: documentos en S3).
Sincroniza el contenido y toma nota de los IDs (KnowledgeBaseId, DataSourceId).

👉 Documentación oficial: Create a Knowledge Base

Clonar y configurar el repositorio

git clone https://github.com/hsaenzG/strands-poc.git
cd strands-poc

Copia env.template a .env y edita con tus valores reales (IDs, región, modelo, etc.).

Instala dependencias locales:

python3.12 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

Construir y desplegar la Lambda

Construye la imagen con Docker (ya preparada para linux/amd64).

Despliega con CDK:

cdk bootstrap
cdk deploy

Esto creará API Gateway, la Lambda containerizada y toda la configuración necesaria.

Probar los endpoints

Verifica la salud de la API:

curl https://<api_url>/prod/health

Haz una consulta al chat:

curl -X POST https://<api_url>/prod/chat \
  -H "Content-Type: application/json" \
  -d '{"message": "¿Quién es Dumbledore?", "user_id": "usuario1"}'

La respuesta vendrá del modelo, enriquecida con información de la Knowledge Base.

Lecciones aprendidas

Permisos IAM: gran parte de los errores iniciales vienen de no asignar correctamente permisos a la Lambda para acceder a Bedrock.
Región: tanto el modelo, la KB como la Lambda deben estar en la misma región.
Chunking de documentos: la calidad de las respuestas depende mucho de cómo fragmentes tu información antes de subirla a la KB.
Latencia: al usar Knowledge Base + modelos de lenguaje, las llamadas pueden tardar un poco más; considera caching si lo llevas a producción.
Lambda en contenedor: la librería de Strands es considerablemente grande y, aun con layers, excederás los límites de tamaño de Lambda. Evítate dolores de cabeza y despliega tu función directamente como una imagen de Docker.

Conclusión

Usar Strands junto con una Knowledge Base de Amazon Bedrock te permite crear asistentes inteligentes que combinan el poder de los LLMs con el conocimiento específico de tus datos. El ejemplo del repo strands-poc es solo el inicio: puedes reemplazar los libros de Harry Potter por documentación de tu empresa, FAQs de soporte o manuales internos.

Mi invitación es a que lo pruebes, lo adaptes a tu contexto y me cuentes qué casos de uso se te ocurren. ¡Estoy segura de que encontrarás formas sorprendentes de aplicar este patrón!