AWS Lambda en profundidad: guía de diseño serverless aprendida comparando Google Cloud Functions, Cloud Run y Azure Functions

Introducción (resumen clave)

• El tema principal de este artículo es AWS Lambda, la plataforma de ejecución serverless de AWS. Lambda es un servicio de ejecución de funciones que permite desplegar código como “funciones” sin pensar en el número de servidores, el SO o el middleware, y se ejecuta automáticamente en respuesta a eventos.
• El precio se basa en el número de solicitudes y en tiempo de ejecución × memoria, con un modelo de pago por uso en el que no se paga por tiempo inactivo. El tiempo de ejecución se mide en milisegundos, y el nivel gratuito incluye 400.000 GB-segundos al mes de tiempo de cómputo, además de un cierto número de solicitudes.
• Los servicios comparables de Google son principalmente Cloud Functions (v2 se integra sobre Cloud Run como Cloud Run functions), y el equivalente en Azure es Azure Functions. Todos comparten la misma idea central: “despliega solo código, ejecútalo en respuesta a eventos y libérate de la gestión de servidores”.
• Lectores previstos:
  • Ingenieros backend que quieren migrar APIs o batch jobs a serverless
  • Líderes técnicos/arquitectos que quieren decidir arquitectura considerando Lambda vs ECS/EKS, y diferencias entre GCP/Azure
  • Equipos pequeños y startups que buscan sistemas escalables con baja carga operativa
• Al final, el objetivo es que puedas explicar con tus propias palabras:
  • “Esta carga de trabajo sí (o no) encaja bien con Lambda”.
  • “En qué se diferencia Lambda de Cloud Functions y Azure Functions”.
  • “Qué plataforma(s) serverless conviene combinar de forma realista para tu proyecto”.

1. ¿Qué es AWS Lambda? Piensa en ello como “un pequeño servidor que reacciona a eventos”

1.1 Concepto central de Lambda

AWS Lambda es el servicio de computación serverless de AWS. Sin aprovisionar ni administrar servidores, despliegas una función (una unidad pequeña de código) y haces que se ejecute automáticamente en respuesta a diversos eventos.

En resumen:

• No ves servidores (aunque, por supuesto, existen detrás de escena)
• Solo especificas código y configuración (memoria, timeout, variables de entorno, etc.)
• Eventos como S3, API Gateway, EventBridge, SQS, SNS pueden disparar la ejecución
• Pagas solo por el tiempo que realmente se ejecuta

En lugar de “levantar una instancia EC2 solo para un trabajo pequeño”, la idea pasa a ser: “sube el código de ese trabajo y deja que se ejecute tantas veces como sea necesario en respuesta a eventos”.

1.2 Lenguajes compatibles, tiempo de ejecución y límites de recursos

Lambda admite múltiples runtimes y, a 2025, los oficialmente soportados incluyen Node.js / Python / Ruby / Java / .NET / Go, etc. Con un runtime personalizado, también pueden ejecutarse otros lenguajes.

Límites típicos:

• Tiempo máximo de ejecución: 15 minutos (900 segundos)
• Memoria: 128 MB a 10.240 MB, en incrementos de 1 MB
• Almacenamiento efímero: 512 MB por defecto, ampliable hasta 10 GB
• Concurrencia: existen límites a nivel de cuenta; el valor por defecto ronda 1.000 (puede aumentarse mediante solicitud de soporte)

GCP Cloud Functions y Azure Functions tienen restricciones similares: tiempo máximo, límites de memoria, controles de concurrencia, etc.

2. Comparación con Google Cloud Functions / Cloud Run functions y Azure Functions

2.1 Rasgos compartidos como “funciones serverless”

AWS Lambda, Google Cloud Functions (v2 como Cloud Run functions) y Azure Functions comparten:

• Despliegue de código sin gestionar servidores
• Arquitectura orientada a eventos (HTTP, almacenamiento, mensajería, planificadores, etc.)
• Auto-scaling, coste casi cero en inactividad
• Pago por uso (solicitudes + tiempo de ejecución + memoria)

2.2 El “territorio natural” de cada plataforma

Un encuadre útil a alto nivel:

• AWS Lambda
  • Integraciones ricas con servicios de AWS como S3 / DynamoDB / API Gateway / EventBridge / SQS
  • La elección más natural si tu arquitectura ya está centrada en AWS
• Google Cloud Functions / Cloud Run functions
  • Integración fluida con servicios GCP como Cloud Storage / Firestore / Pub/Sub / Cloud Run
  • Muy adecuado para microservicios HTTP y flujos pequeños
• Azure Functions
  • Integración estrecha con Azure Storage / Cosmos DB / Event Hubs / Service Bus
  • Gran afinidad con el ecosistema .NET; ampliamente adoptado en entornos empresariales

Más que “cuál es mejor”, la selección suele depender de factores prácticos:

• Integración con servicios cloud que ya usas
• Lenguajes y toolchains familiares para el equipo
• Preferencia organizacional por un proveedor concreto

2.3 Diferencias de escalado y modelo de precios (a grandes rasgos)

Todos son “auto-escala + pago por uso”, pero el comportamiento difiere en detalles:

• Lambda
  • Añade entornos de ejecución automáticamente según la demanda; tiene comportamiento de “burst” por función y límites de concurrencia a nivel de cuenta
  • Precio: solicitudes + GB-segundos. Recientemente, el precio puede variar entre ARM (Graviton) y x86; existe un nivel gratuito.
• Cloud Functions / Cloud Run functions
  • Auto-escala para HTTP/eventos, permite configurar conteo de instancias y concurrencia
  • Precio: solicitudes + tiempo de ejecución + memoria/CPU, con opciones de nivel gratuito
• Azure Functions
  • Varios planes de ejecución: Consumo (pago por uso), Premium / App Service (más estabilidad/flexibilidad), etc., elegidos según el caso de uso

Los precios cambian con el tiempo, así que para decisiones reales de arquitectura conviene estimar con las páginas oficiales de precios y calculadoras.

3. Arquitectura de AWS Lambda: eventos, disparadores y entorno de ejecución

3.1 Qué “arranca” una Lambda: tipos de disparador

Parte del atractivo de Lambda es la variedad de disparadores. Ejemplos comunes:

• Solicitudes HTTP vía API Gateway o ALB
• Eventos de subida/borrado de objetos en S3
• Eventos de cambios en DynamoDB Streams
• Mensajes que llegan a una cola SQS
• Notificaciones de un tema SNS
• Programaciones y reglas de EventBridge
• Eventos de Cognito, CodeCommit, CloudWatch Logs y más

Esta sensación de “todo puede ser un evento” también existe en Cloud Functions (Cloud Storage / Pub/Sub / Firebase) y Azure Functions (Storage / Event Hubs / Service Bus). Las funciones serverless suelen actuar como el “pegamento” que conecta servicios cloud.

3.2 Ciclo de vida del entorno de ejecución y cold starts

Internamente, Lambda ejecuta funciones en un entorno aislado que se comporta como un contenedor.

• En la primera invocación o tras un periodo de inactividad, debe crearse un nuevo entorno: esto es un cold start.
• Una vez creado, el entorno puede reutilizarse durante un tiempo, de modo que varias solicitudes pueden manejarse dentro del mismo contenedor (permitiendo optimizaciones como caché en variables globales).

Este patrón es similar en Cloud Functions y Azure Functions: “la primera llamada puede ser más lenta; las siguientes son más rápidas”.

3.3 Ejemplo: la función Lambda más simple en Node.js

Un ejemplo mínimo de handler HTTP:

// index.mjs (Node.js 20, etc.)
export const handler = async (event, context) => {
  console.log("Request ID:", context.awsRequestId);
  console.log("Event:", JSON.stringify(event));

  return {
    statusCode: 200,
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      message: "¡Hola desde Lambda!",
      input: event,
    }),
  };
};