Módulo 3: Serverless & Lambda for AI

1. Introducción: Serverless & Lambda for AI

Descripción

Esta es la primera cápsula del Módulo 3 de la Guía de Deployment & Cloud Infrastructure. Aquí vas a entender por qué AWS Lambda merece un módulo dedicado cuando hablamos de deployment para sistemas AI — y por qué "serverless para AI" no es lo mismo que "serverless para web apps." Los cold starts que en una web app son un inconveniente menor, en una función que carga librerías de ML se convierten en un problema de ingeniería real. Este módulo te enseña Lambda como herramienta de deployment para AI, no como tecnología genérica.

Por qué importa: En el Módulo 1 construiste un framework de decisión. En el Módulo 2 implementaste deployment local con Docker Compose multi-container. Ahora vas a implementar la segunda estrategia del landscape: serverless. Lambda es la opción más adoptada para APIs event-driven y workloads variables — pero para AI tiene particularidades que no existen en tutoriales genéricos. Cold starts de 5-15 segundos con dependencias pesadas, timeouts de 15 minutos que parecen generosos hasta que tu prompt chain hace 3 llamadas secuenciales a GPT-4, memory limits que importan cuando necesitas embeddings en memoria. Este módulo confronta esos problemas desde el primer momento.

Al terminar este módulo tendrás un endpoint Lambda funcional que invoca un LLM, expuesto via API Gateway, con configuración optimizada para AI workloads. Entenderás cuándo Lambda es la opción correcta y cuándo no lo es — con números reales, no opiniones.

¿Dónde Estamos en la Guía?

Contexto

Phase 1: Deployment Strategies (Módulos 1-3)
├── Módulo 1: Understanding Deployment Options    ✅ COMPLETADO
├── Módulo 2: Local & Container Deployment        ✅ COMPLETADO
└── Módulo 3: Serverless & Lambda for AI          ← ESTÁS AQUÍ

Phase 2: Cloud Infrastructure & Migration (Módulos 4-6)
├── Módulo 4: LocalStack — AWS Local Development
├── Módulo 5: AWS Services for AI (S3, Lambda, SageMaker Basics)
└── Módulo 6: Cloud Migration Patterns

Phase 3: Alternatives & Production (Módulos 7-8)
├── Módulo 7: Alternative Platforms (Render, Railway, Fly.io)
└── Módulo 8: Proyecto Integrador — Deployed AI System

Duración total estimada de la guía: 10-12 horas (self-paced).

Transición desde Módulo 2

En el Módulo 2 dominaste deployment local con Docker Compose: multi-container, health checks, networking, secrets. Eso funciona perfecto para desarrollo y para producción con tráfico predecible. Pero hay escenarios donde gestionar infraestructura — incluso con Docker Compose en un VPS — no es la mejor opción:

Tráfico impredecible — Tu app AI tiene picos (lanzamiento de feature, mención en redes) y valles (3am). Con un servidor siempre-on, pagas por el valle.
Zero ops — No quieres (o no tienes equipo para) gestionar servidores, actualizaciones, y scaling.
Event-driven — Tu función responde a eventos (archivo subido, webhook, request HTTP) y no necesita correr continuamente.
Costes variables — Prefieres pagar por invocación en lugar de un coste fijo mensual.

Lambda resuelve estos escenarios. Pero Lambda para AI no es Lambda para una web app tradicional — y esa diferencia es el corazón de este módulo.

Qué Es Serverless para AI

Serverless en una frase

Serverless significa que no gestionas servidores. Subes tu código, el cloud provider lo ejecuta cuando llega un evento, escala automáticamente, y te cobra solo por el tiempo de ejecución. "Serverless" no significa "sin servidores" — significa que los servidores no son tu problema.

Por qué Lambda para AI es diferente

Un tutorial genérico de Lambda te muestra una función "Hello World" de 50ms. Eso no tiene nada que ver con lo que vas a hacer aquí. Cuando tu Lambda invoca un LLM, la ecuación cambia completamente:

Lambda genérica (web app):
├── Cold start:    200-500ms
├── Execution:     50-200ms
├── Memory:        128MB
├── Dependencies:  requests, json (pequeñas)
└── Total:         <1s

Lambda para AI (este módulo):
├── Cold start:    1-15s (depende de dependencias)
├── Execution:     2-30s (depende del LLM y tokens)
├── Memory:        256MB-1GB+
├── Dependencies:  openai, langchain, numpy (grandes)
└── Total:         3-45s

Las implicaciones son directas:

Cold starts pasan de "imperceptible" a "el usuario piensa que la app se rompió"
Timeouts de 15 minutos parecen generosos hasta que haces 3 llamadas secuenciales a un LLM con retries
Memory importa cuando tu función necesita cargar librerías de ML en memoria
Costes escalan diferente cuando cada invocación dura 10-30 segundos en vez de 50ms
Packaging es un reto cuando tus dependencias Python pesan 50-250MB

Cada cápsula de este módulo aborda uno de estos problemas con soluciones concretas.

La analogía del restaurante de AI

Piensa en Lambda para AI como un food truck especializado en ramen (plato que requiere preparación):

Sin Lambda (servidor siempre-on): Tienes el restaurante abierto 24/7. Pagas alquiler, luz, y chef incluso a las 3am cuando no hay clientes.
Con Lambda (serverless): El food truck solo se activa cuando hay pedido. No pagas cuando no hay clientes. Pero cada vez que arranca después de estar apagado, necesita tiempo para calentar el caldo (cold start). Y si el ramen tarda 20 minutos, necesitas que el cliente espere (timeout).
El problema AI-specific: Tu food truck no hace hamburguesas rápidas. Hace ramen elaborado. El tiempo de preparación (inferencia LLM) es largo, y calentar el caldo (cargar librerías de ML) toma más que calentar una plancha.

La pregunta no es "¿Lambda es bueno?" sino "¿es tu plato compatible con el formato food truck?"

Objetivo del Módulo

Al terminar este módulo serás capaz de:

✅ Implementar una función Lambda en Python que invoque un LLM (OpenAI/Anthropic) y retorne la respuesta procesada
✅ Configurar API Gateway como trigger HTTP para invocar Lambda, con CORS y autenticación básica
✅ Elegir entre container deployment y zip deployment para Lambda, con trade-offs documentados
✅ Medir y mitigar cold starts en AI Lambdas: provisioned concurrency, keep-warm, optimización de paquete
✅ Configurar timeout y memory adecuados para inferencia LLM, con razonamiento
✅ Gestionar environment variables y secrets de forma segura (API keys de LLM providers)
✅ Estimar costes de Lambda para AI workloads: invocaciones × duración × memoria
✅ Distinguir invocación síncrona vs asíncrona y cuándo usar cada una para AI

Objetivo profesional

Cuando alguien te diga "vamos a poner nuestra app AI en Lambda," no vas a aceptar sin cuestionar ni rechazar por default. Vas a preguntar: "¿Cuál es el patrón de tráfico? ¿Cuánto pesan las dependencias? ¿Qué latencia tolera el usuario? ¿Has calculado el coste a 10K invocaciones diarias?" Y vas a tener experiencia real para respaldar tus respuestas.

Roadmap del Módulo

Mapa de cápsulas

#	Cápsula	Qué aprenderás	Tipo
01	Introducción (esta)	Context, objetivos, setup, roadmap	Intro
02	Lambda Fundamentals para AI	Handler anatomy, Python Lambda para AI, packaging, secrets	Técnica
03	Container vs Zip Deployment	Dos formas de deployar Lambda, trade-offs, step-by-step	Técnica
04	Cold Starts en AI	Qué son, medición real, impacto por dependencia, mitigación	Técnica
05	Timeout y Memory Config	Configuración para inferencia LLM, right-sizing, power tuning	Técnica
06	API Gateway Integration	HTTP trigger, CORS, auth, endpoint completo	Técnica
07	Cost Estimation Serverless	Pricing model, cálculos para AI, comparativa con servidor	Técnica
08	Proyecto: Lambda AI Endpoint	Endpoint Lambda completo con LLM, API Gateway, optimizado	Proyecto

Flujo de aprendizaje

Primero entenderás la anatomía de Lambda para AI: handler, packaging, secrets (cápsula 02). Luego compararás las dos formas de deployment — zip vs container — con trade-offs específicos para dependencias AI (cápsula 03). Después confrontarás el problema de cold starts con números reales y estrategias de mitigación (cápsula 04). Configurarás timeout y memory con razonamiento para inferencia LLM (cápsula 05). Conectarás Lambda con API Gateway para tener un endpoint HTTP completo (cápsula 06). Aprenderás a estimar costes para evitar sorpresas en la factura (cápsula 07). Y finalmente integrarás todo en un Lambda AI Endpoint funcional (cápsula 08).

La progresión es: fundamentos → deployment → cold starts → configuración → endpoint → costes → proyecto.

Duración estimada del módulo: 1.25-1.5 horas.

Conexión con el Proyecto

Proyecto de este módulo: Lambda AI Endpoint

El Lambda AI Endpoint es una función Lambda que:

Recibe un prompt via API Gateway (HTTP POST)
Invoca un LLM (OpenAI o Anthropic)
Procesa la respuesta (formato, validación, metadata)
Retorna el resultado al cliente

User Request (HTTP POST /ask)
    ↓
┌─────────────────────────────┐
│ API Gateway                  │
│ ├── CORS configurado         │
│ ├── API Key auth             │
│ └── Rate limiting            │
└─────────────────────────────┘
    ↓
┌─────────────────────────────┐
│ Lambda Function              │
│ ├── Recibe event (prompt)    │
│ ├── Invoca OpenAI API        │
│ ├── Procesa response         │
│ └── Retorna JSON             │
└─────────────────────────────┘
    ↓
User Response (JSON)
{
  "answer": "...",
  "model": "gpt-4o-mini",
  "tokens": 245,
  "duration_ms": 2300
}

Configuración optimizada para AI

El endpoint no es un Lambda genérico. Incluye:

Timeout: 60s (suficiente para LLM con retries, no más)
Memory: 512MB (openai SDK + processing)
Cold start mitigation: Package optimizado, provisioned concurrency opcional
Error handling: Timeout de LLM vs timeout de Lambda, retries con backoff
Cost awareness: Logging de duración y tokens para monitoreo de costes

Conexión con módulos posteriores

Módulo 3: Lambda AI Endpoint → función Lambda funcional
    ↓
Módulo 4: LocalStack → ejecutar el mismo Lambda localmente, sin AWS
    ↓
Módulo 5: AWS Services → integrar Lambda con S3, explorar SageMaker
    ↓
Módulo 6: Migration → mismo código en LocalStack y AWS
    ↓
Módulo 8: Proyecto Integrador → Lambda como pieza del sistema (si aplica)

Prerequisitos

Lo que ya sabes

✅ Docker — Dockerfile, images, containers (guía #15)
✅ CI/CD — Pipelines de deployment, GitHub Actions (guía #16)
✅ Decision Framework — Las 4 categorías de deployment, decision matrix (Módulo 1)
✅ Docker Compose — Multi-container, health checks, secrets (Módulo 2)
✅ Python intermedio — FastAPI, Pydantic, async/await
✅ REST APIs — HTTP, requests, responses, JSON
✅ Apps AI — Has construido al menos una app que invoca un LLM

Lo que aprenderás aquí (nuevo)

AWS Lambda: handler, context, packaging
Container vs zip deployment para Lambda
Cold starts: medición, impacto, mitigación
API Gateway: HTTP trigger, CORS, auth
Serverless cost estimation para AI
Lambda-specific debugging y troubleshooting

Si te falta algo

Te falta	Recurso recomendado
Docker	Docker Essentials Guide (#15) — NIEVA
CI/CD	CI/CD for AI Systems Guide (#16) — NIEVA
Módulo 1 (Decision Framework)	Módulo 1 de esta guía
Módulo 2 (Docker Compose)	Módulo 2 de esta guía
Python + FastAPI	Python REST APIs for AI Guide — NIEVA
Apps AI	AI Engineering Bootcamp — NIEVA

Setup Técnico

Herramientas necesarias

# Python 3.10+ (mismo que módulos anteriores)
python --version
# Python 3.10+ esperado

# Docker (prerequisite — lo usarás para container deployment)
docker --version
# Docker version 24.0+ esperado

# AWS CLI v2
aws --version
# aws-cli/2.x.x esperado
# Si no lo tienes: https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html

# AWS SAM CLI (para desarrollo local de Lambda)
sam --version
# SAM CLI, version 1.x.x esperado
# Si no lo tienes: https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/install-sam-cli.html

Instalación de herramientas nuevas

# AWS CLI v2 (macOS)
curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"
sudo installer -pkg AWSCLIV2.pkg -target /

# AWS CLI v2 (Linux)
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

# SAM CLI (macOS con Homebrew)
brew install aws-sam-cli

# SAM CLI (pip — alternativa multiplataforma)
pip install aws-sam-cli

# Alternativa: Serverless Framework (si prefieres)
npm install -g serverless

Configurar AWS CLI (mínimo)

# Para desarrollo local con LocalStack (M4), no necesitas cuenta AWS real.
# Para deployment real a AWS, necesitas credenciales:

aws configure
# AWS Access Key ID: tu-access-key
# AWS Secret Access Key: tu-secret-key
# Default region: us-east-1
# Default output format: json

# Verificar configuración
aws sts get-caller-identity

Crear estructura del proyecto

mkdir -p module-03/{lambda-function,tests}
cd module-03

# Estructura inicial
# module-03/
# ├── lambda-function/
# │   ├── handler.py          # Función Lambda
# │   ├── requirements.txt    # Dependencias
# │   └── Dockerfile          # Para container deployment
# ├── template.yaml           # SAM template
# ├── tests/
# │   └── test_handler.py     # Tests
# └── .env                    # Variables locales

LocalStack como alternativa sin coste

Si no tienes cuenta AWS o prefieres no gastar dinero durante el aprendizaje, el Módulo 4 te enseña a usar LocalStack para ejecutar Lambda localmente. Puedes adelantar la instalación:

# LocalStack (preview — se cubre en detalle en M4)
pip install localstack
localstack start

# Verificar
aws --endpoint-url=http://localhost:4566 lambda list-functions

No necesitas LocalStack para este módulo — es una opción. Los ejercicios usan SAM CLI para testing local.

Límites: Qué NO Cubre Este Módulo

❌ SageMaker — Deploy de modelos ML propios en SageMaker se cubre en Módulo 5. Este módulo es Lambda para AI inference via API (OpenAI, Anthropic), no para hosting de modelos.
❌ Step Functions — Orquestación de múltiples Lambdas. Es un tema avanzado que va más allá del scope. Aquí es una Lambda, un endpoint.
❌ Multi-region deployment — Deployment en múltiples regiones AWS para latencia global. Avanzado, fuera de scope.
❌ Lambda@Edge / CloudFront Functions — Funciones en edge locations. Diferente caso de uso.
❌ Terraform/CDK — Infrastructure as Code avanzado. Usamos SAM CLI por simplicidad.
❌ Lambda genérica — No vas a ver "Hello World" en Lambda. Cada ejemplo es AI-specific. Si buscas Lambda tutorial genérico, la documentación de AWS es excelente.
❌ Modelos pesados en Lambda — Si tu workload necesita torch, transformers, o modelos de >1GB en memoria, Lambda no es la herramienta. SageMaker (M5) o ECS/Fargate son opciones mejores.

Qué sí cubrimos (y por qué)

Tema	Razón
Lambda handler para AI	La base: cómo funciona una función Lambda que invoca LLMs
Container vs zip deployment	Decisión crítica: tus dependencias AI definen la estrategia
Cold starts con datos reales	El problema #1 de Lambda para AI — no puedes ignorarlo
Timeout y memory config	Configurar mal = tu función falla o te cuesta 5x más
API Gateway	Sin él, Lambda es una función que nadie puede invocar
Cost estimation	Lambda "pay per use" puede ser caro para AI — necesitas calcular antes

Evidencia de Éxito

Al terminar este módulo, sabrás que tuviste éxito si:

✅ Tu Lambda invoca un LLM y retorna una respuesta procesada via API Gateway
✅ Puedes explicar por qué elegiste container vs zip deployment para tu caso
✅ Conoces el cold start de tu función (medido, no estimado) y tienes estrategia de mitigación
✅ Tu timeout y memory están configurados con razonamiento ("60s porque..." no "puse 300s por si acaso")
✅ Las API keys están en environment variables, no hardcodeadas
✅ Puedes estimar el coste mensual de tu Lambda para 1K, 10K, y 100K invocaciones/día
✅ Puedes argumentar cuándo Lambda NO es la opción correcta para un AI workload

Test rápido de autoevaluación

Si puedes responder estas preguntas, vas por buen camino:

¿Cuál es la diferencia entre zip y container deployment en Lambda?
¿Por qué un cold start de Lambda con langchain es 10x más lento que con openai?
¿Cuánto cuesta 10K invocaciones diarias de 10s con 512MB de memory?
¿Cuándo usarías invocación async en vez de sync para AI?

Resumen

Serverless para AI ≠ serverless genérico. Cold starts, timeouts, memory, y costes cambian radicalmente cuando tu función invoca LLMs o carga librerías de ML.
Lambda es la opción más adoptada para APIs event-driven y workloads variables en AWS.
Este módulo te enseña Lambda AI-specific: cada ejemplo, cada configuración, cada trade-off es en contexto de AI inference.
El proyecto del módulo es un Lambda AI Endpoint completo: función + API Gateway + configuración optimizada.
No es evangelismo serverless. Vas a aprender cuándo Lambda es la opción correcta Y cuándo no lo es.
El Lambda que construyes aquí se reutiliza en M4 (LocalStack), M5 (AWS Services), y M8 (Integrador).

Recursos Adicionales

AWS Lambda Developer Guide — Python — Documentación oficial de Lambda con Python
AWS SAM CLI Documentation — SAM para desarrollo local
API Gateway REST API Documentation — Documentación de API Gateway
Lambda Power Tuning — Herramienta para optimizar memory/cost de Lambda
Serverless Framework Documentation — Alternativa a SAM para deployment
AWS Lambda Pricing — Pricing oficial y calculadora
LocalStack Documentation — Para desarrollo local sin coste AWS

← Anterior8. Proyecto: Local Multi-Container AI App Siguiente →2. Lambda Fundamentals para AI