Cuándo conviene migrar un microservicio a AWS Lambda (y cuándo no hacerlo)

Introducción

AWS Lambda es una herramienta excelente cuando tu problema encaja con su modelo: ejecución por eventos, cargas variables y operación simplificada. El error común es tratarla como una receta universal para “abaratar y acelerar” cualquier microservicio.

En este artículo te dejo criterios prácticos para decidir con calma: qué tipo de problemas resuelve bien, en qué casos sale caro o frágil, y un checklist para tomar la decisión con datos (no con hype).

El mito de “Lambda es más barato y rápido”

Lambda puede ser más barata cuando pagas por uso real, pero puede ser más cara si tienes tráfico constante, funciones con mucha duración, o sobrecostos operativos (observabilidad, tracing, reintentos, DLQs, permisos, límites de concurrencia). En rendimiento, el “peaje” típico es el cold start y el costo de integrar con VPC/red, no el CPU.

La pregunta no es “¿Lambda es mejor?”, sino: ¿este microservicio se comporta como una función?

Qué tipo de problemas resuelve Lambda

Eventos

Si tu lógica se dispara por un evento claro (un mensaje, un archivo, un webhook, un cambio en base de datos, un cron), Lambda calza natural. Ejemplos típicos: procesamiento de S3, consumidores de SQS, handlers de EventBridge, webhooks, transformaciones, notificaciones y tareas de “pegamento” entre sistemas.

Picos

Para cargas con picos impredecibles (campañas, lanzamientos, cierres de mes), Lambda escala sin que tú mantengas capacidad o autoscaling. Lo importante aquí es que tu sistema soporte la presión aguas abajo (DB, terceros, APIs) y que limites con backpressure (SQS, throttling, rate limits).

Cargas irregulares

Si tu servicio tiene “silencios” largos y ráfagas cortas, un microservicio en contenedor suele pagar idle. Lambda, en cambio, paga por invocación y duración. Aquí sí suele ganar en costo, siempre que la latencia extra del cold start sea aceptable.

Señales claras de que NO debes migrar

Procesos largos

Si tu microservicio hace trabajos largos, pesados o con mucha orquestación (batch grande, ETL, video, reportes complejos), Lambda puede volverse incómodo: límites de tiempo, reintentos, idempotencia y manejo de estado. En esos casos suele encajar mejor ECS/Fargate, EKS o Step Functions como orquestador (y Lambda como piezas pequeñas).

Conexiones persistentes

Servicios que dependen de conexiones persistentes (WebSockets, streaming, sesiones largas, TCP “pegado”) no son el caso ideal para Lambda. Aunque hay soluciones (API Gateway WebSockets, ALB + Lambda), el costo/operación suele ser peor que un servicio siempre activo.

Estado complejo

Si el servicio guarda estado “vivo” (cachés locales críticos, colas internas, pipelines en memoria, locks), migrar a Lambda obliga a externalizarlo (DynamoDB, Redis/ElastiCache, S3, etc.) y eso cambia arquitectura, latencia y costos. Si el estado es parte central del diseño, probablemente no conviene.

Comparación real

Esta tabla no pretende “ganador absoluto”, sino ayudarte a mapear trade-offs.

Factor	Microservicio tradicional (VM/Contenedor)	AWS Lambda
Costos	Pagas capacidad (idle incluido). Bueno para tráfico constante y estable.	Pagas por invocación y duración. Excelente para cargas irregulares, puede encarecerse con tráfico constante.
Latencia	Latencia estable. No hay cold start.	Puede tener cold start (depende runtime, memoria, VPC, tamaño). Buena si toleras picos de latencia.
Operación	Gestión de despliegue, autoscaling, base images, parches, capacity planning.	Menos infraestructura, pero más diseño de eventos: idempotencia, reintentos, DLQ, tracing, permisos IAM.
Debug/local	Más directo: misma app local/CI.	Requiere emulación/paridad (SAM, LocalStack), eventos de prueba y observabilidad fuerte.

Caso real: Controla el crecimiento

En proyectos reales he visto un patrón repetido: integraciones que deben consumir servicios en un entorno On-Premise donde no hay capacidad de escalar infraestructura rápidamente ni de incorporar nuevos servicios de forma ágil.

El riesgo aparece cuando la base de datos y/o los servicios internos empiezan a degradar rendimiento; si no se controla, en un pico de transaccionalidad pueden volverse un cuello de botella o incluso fallar.

Solución

La clave es controlar la tasa de entrada. Limita la cantidad de requests que llegan a la función (y por ende al On-Prem)antes de ejecutar la lógica. Un enfoque típico es aplicar throttling en API Gateway(y, si aplica, usar cola para amortiguar picos).

Checklist de decisión

Si respondes “sí” a varias de estas preguntas, Lambda suele ser buen candidato. Si respondes “no” o “depende” en puntos críticos, probablemente conviene quedarte en contenedor/VM (o migrar parcialmente).

¿La carga es irregular (picos + valles) y pagas demasiado por capacidad ociosa?
¿El servicio es event-driven o se puede dividir en handlers por evento?
¿Toleras picos de latencia (cold start) o puedes mitigarlos (warming, provisioned concurrency)?
¿Tu lógica es idempotente o la puedes hacer idempotente (reintentos sin efectos secundarios)?
¿Tienes estrategia para reintentos, DLQ y manejo de fallos (sin duplicar operaciones)?
¿La dependencia principal (DB/terceros) aguanta la escala o puedes controlar concurrencia con colas?
¿Tienes observabilidad lista (logs estructurados, métricas, tracing) para operar en serverless?
¿La migración se puede hacer gradual (estrangulamiento) y con rollback simple?

Conclusión

Lambda es una herramienta potente cuando el problema encaja: eventos, picos y cargas irregulares. Cuando no encaja (procesos largos, conexiones persistentes, estado complejo), la migración suele pagar en complejidad y costo.

Lambda como herramienta, no religión. Si la decisión está basada en señales técnicas (y en tu realidad de operación), la arquitectura te va a agradecer.