AWS Lambda puede ejecutar partes de una arquitectura de microservicios, pero una función no se convierte en microservicio por usar Lambda. Primero define límites de negocio y propiedad de datos; después elige si cada trabajo encaja en el modelo de invocación de Lambda, en un proceso de contenedor o en otra forma de cómputo.
Para entender el ciclo de una función, consulta Fundamentos de AWS Lambda: cómo se ejecuta tu código sin servidores, artículo de Hazel Sáenz en AWS Builder Center.
Este ejemplo usa una tienda: el servicio de pedidos recibe solicitudes, el de inventario reserva unidades y el de notificaciones avisa al cliente. La misma arquitectura sirve para comparar microservicios en AWS con contenedores.
Qué hace que una parte sea un microservicio
Un microservicio agrupa una capacidad de negocio que un equipo puede cambiar y operar con límites claros. Un servicio de pedidos puede tener varias funciones Lambda —por ejemplo, una para crear pedidos y otra para responder consultas— y seguir siendo una sola capacidad. Dividir cada endpoint, tabla o función en un microservicio separado añade llamadas, despliegues y fallas distribuidas sin garantizar autonomía.
Busca límites alrededor de capacidades como pedidos, inventario y pagos. Cada servicio valida sus reglas y escribe su propio estado. El resto de la aplicación lo consulta por una API o recibe hechos de negocio por eventos; no lee directamente las tablas de otro servicio. AWS explica este enfoque en sus guías para descomponer por capacidad de negocio y el patrón de una base de datos por servicio.
Si el dominio todavía cambia mucho, una aplicación modular puede ser más sencilla de mantener. Separa un servicio cuando un límite de negocio, un ritmo de cambio, un equipo o una necesidad de escalado justifican el costo de operar una frontera distribuida. Hazel Sáenz desarrolla esta decisión en Escala inteligente con microservicios serverless, con una explicación de cuándo separar servicios y cómo relacionar eventos, datos y observabilidad.
Ejemplo: pedidos por API y trabajo por eventos
Un flujo pequeño puede ser así:
- El cliente envía
POST /ordersa una API. Amazon API Gateway puede publicar el endpoint y enrutar la solicitud a la función Lambda del servicio de pedidos. - La función valida las reglas, crea el pedido y registra un evento de salida en la misma transacción de datos. Un publicador envía después ese evento a un bus de Amazon EventBridge. El registro de salida —un outbox— evita confirmar un pedido y perder su notificación si falla la publicación; AWS explica el patrón transactional outbox y el problema de la escritura dual.
- Una regla de EventBridge dirige
OrderPlaceda una cola de Amazon SQS para inventario y, si hace falta, a otra cola para notificaciones. Cada consumidor avanza y se recupera por separado. - Una función Lambda consumidora reserva inventario y guarda el resultado en los datos que pertenecen al servicio de inventario.
El cliente necesita una respuesta inmediata para saber si su pedido se aceptó, así que la creación usa una llamada HTTP síncrona. Reservar inventario y enviar una notificación pueden continuar después; una cola desacopla esos trabajos del tiempo de respuesta del cliente. EventBridge enruta hechos, SQS conserva trabajo pendiente y amortigua picos. Para una comparación más detallada, consulta la guía de decisión de AWS para SQS, SNS y EventBridge y el artículo de Marcia Villalba SQS, SNS, EventBridge o Kinesis: ¿cuál usás?, publicado en septiembre de 2026.
El contenido de detail de un evento propio podría verse así:
{
"eventId": "evt-01J9Q2K7M4",
"schemaVersion": 1,
"orderId": "ord-8042",
"occurredAt": "2026-10-06T12:00:00Z",
"items": [
{ "sku": "cafe-250g", "quantity": 2 }
]
}Si se envía a EventBridge, el servicio añade metadatos como source, detail-type, id, cuenta y región. Mantén eventId estable cuando se vuelva a publicar el mismo hecho; versiona el esquema y no incluyas datos personales que los consumidores no necesitan.
Diseña cada llamada para que pueda repetirse
Una entrega puede repetirse. Las funciones invocadas por una API, de forma asíncrona o mediante un mapeo de origen de eventos siguen reglas de error diferentes. Los mapeos que leen colas o streams procesan al menos una vez y pueden entregar registros duplicados; la estrategia depende del origen y su configuración. Revisa la guía de AWS sobre reintentos de Lambda y el comportamiento de mapeos de origen de eventos antes de decidir cuántas veces se intenta un mensaje.
Para que un reintento no cree otro pedido ni descuente inventario dos veces:
- El endpoint de creación acepta una clave de idempotencia del cliente. Si recibe la misma clave y la misma solicitud, devuelve el resultado guardado en vez de crear otro pedido.
- El consumidor conserva
eventIdcomo clave de deduplicación. Registra ese identificador y aplica el cambio de negocio en una operación atómica cuando la base de datos lo permite; si el efecto ocurre en un proveedor externo, usa también su mecanismo de idempotencia o diseña una compensación. - Configura reintentos acotados y una cola de mensajes no procesables (DLQ) en la capa que controla la entrega. Inspecciona el mensaje, corrige la causa y reprocésalo de forma segura; una DLQ no corrige por sí sola los datos ni la lógica.
El servicio sigue siendo dueño de su estado incluso cuando usa una cola. Los otros servicios reaccionan a OrderPlaced o consultan una API acordada, pero no escriben en la tabla de pedidos.
Cuándo elegir Lambda
| Lambda suele encajar cuando… | Compara con un contenedor cuando… |
|---|---|
| El trabajo empieza por una solicitud o un evento y termina al procesarlo. | El proceso debe permanecer activo, mantener conexiones o atender protocolos de larga duración. |
| El volumen sube y baja, y quieres escalar cada consumidor por separado. | La carga es estable, necesita control del sistema operativo o depende de un runtime y herramientas que no encajan con Lambda. |
| El equipo quiere delegar la administración de servidores y puede trabajar con los límites de invocación del servicio. Una función Lambda estándar puede ejecutarse hasta 15 minutos por invocación; AWS documenta excepciones para ciertos tipos de invocación con Lambda Managed Instances en sus cuotas vigentes. | El trabajo debe exceder el límite aplicable, mantener un proceso residente o usar una unidad de despliegue basada en una imagen de contenedor. |
No elijas Lambda solo por una promesa de menor costo. El costo depende de invocaciones, duración y configuración, además de API Gateway, EventBridge, SQS, almacenamiento, registros, red y base de datos. Recursos como una tabla o una capacidad aprovisionada pueden seguir generando cargos aunque haya pocas invocaciones. Consulta los precios de Lambda y de los otros servicios que formen la arquitectura.
Una imagen de contenedor también puede ser un formato de paquete para una función Lambda. Lambda sigue ejecutando esa imagen bajo su modelo de invocación; no crea una tarea de larga duración ni un servicio de contenedores. La documentación de imágenes para Lambda describe ese formato. ECS y EKS cumplen otra función: orquestan contenedores. Para elegir entre ambos enfoques, revisa el artículo complementario sobre ECS, EKS, Fargate y EC2.
Opera con fallas visibles y permisos acotados
- Asigna un rol de ejecución mínimo a cada función. La función de pedidos no necesita permisos para escribir el inventario; la función de inventario sí necesita acceso a su cola y sus propios datos.
- Configura timeout, memoria y concurrencia según mediciones representativas. La concurrencia puede proteger una base de datos o un proveedor externo de una ráfaga excesiva.
- Registra de forma estructurada
eventId,orderIdy un identificador de correlación. No escribas secretos ni datos personales completos en los logs. - Observa invocaciones, errores, throttles y duración en CloudWatch. Para consumidores de SQS, sigue también la cantidad y antigüedad de mensajes, las fallas y el crecimiento de la DLQ. Define quién recibe la alerta y cómo se recupera el flujo.
- Prueba la lógica de negocio sin AWS, y prueba aparte la integración entre API Gateway, Lambda, colas, permisos y almacenamiento en un entorno controlado. Una prueba simulada no confirma permisos, cuotas ni entrega real del servicio.
Para ajustar memoria, concurrencia, secretos y alarmas de estas funciones, continúa con las mejores prácticas de AWS Lambda. Esa guía desarrolla los controles operativos sin cambiar los límites de negocio del servicio.
Recursos y comunidades para practicar microservicios con Lambda
Para practicar la parte de eventos, la grabación AWS SQS vs SNS vs EventBridge: ¿cuál escoger? de Marcia Villalba compara los modelos de mensajería. Para seguir con servicios de API, lee Amazon API Gateway: la puerta de entrada a tu backend en la nube, una introducción en español publicada por AWS.
Si quieres compartir dudas con personas que trabajan con Lambda, visita el AWS User Group Serverless Colombia. También puedes consultar el grupo general AWS User Group Córdoba, que reúne a personas interesadas en computación en la nube para compartir experiencias sobre AWS y otras tecnologías. Revisa cada ficha para conocer sus actividades y condiciones de participación.
Para discutir la elección de cómputo, el AWS User Group Tlaxcala FireflyCloud anuncia la sesión online EC2 vs Lambda para el 16 de octubre de 2026, de 16:00 a 17:00 (UTC−06:00). La ficha propone comparar ventajas, costos y escenarios de ambos servicios; el enlace de reunión es visible para asistentes. Confirma el registro y las condiciones en la página del organizador.
El AWS User Group Serverless Colombia anuncia El Combo Indestructible de AWS: SQS + Lambda, una sesión virtual para el 20 de octubre de 2026 a las 19:00 (UTC−05:00). La ficha indica acceso libre; el enlace de reunión se muestra a las personas asistentes, así que confirma la inscripción y los detalles vigentes allí. La agenda se consultó el 6 de octubre de 2026. Para encontrar otras comunidades y eventos, consulta el directorio de comunidades AWS y la agenda actual de eventos. El directorio de videos AWS en español reúne más grabaciones de grupos de usuarios y creadores; busca allí recursos de Lambda, API Gateway y arquitectura dirigida por eventos.
