Cloudflare Workers vs AWS Lambda Comparación

Cómputo que se ejecuta en el edge global con V8 isolates, sin arranque en frío de VM

VS
AWS Lambda

Cómputo serverless que se ejecuta sobre una microVM de Firecracker, profundamente integrado con el ecosistema de AWS

17 min de lecturaBackend

Veredicto rápido

No hay un ganador absoluto: para cargas de trabajo cortas, sensibles a la latencia y de alcance global (autenticación, enrutamiento, personalización, API gateway, webhooks), Cloudflare Workers ofrece tanto menor costo como menos fricción por arranque en frío. En trabajos de larga duración, con alto consumo de memoria o dependientes de recursos de AWS dentro de una VPC, Lambda va por delante: sus límites son más amplios y el acceso a red privada ya está en disponibilidad general (GA), mientras que en Workers sigue en beta. El patrón de producción más común es híbrido: Workers como capa ligera en el edge, Lambda encargándose del trabajo pesado detrás.

Cloudflare WorkersAWS Lambda
Leer el veredicto completo

Comparación de puntuaciones

Cargando gráfico...

Puntuación detallada

Puntuación detallada: Cloudflare Workers y AWS Lambda — puntuaciones por categoría sobre 10
CategoríaCloudflare WorkersAWS Lambda
Rendimiento
8/10
7/10
Facilidad de aprendizaje
7/10
6/10
Ecosistema
6/10
9/10
Comunidad
6/10
8/10
Mercado laboral
6/10
8/10
A prueba de futuro
9/10
8/10

Pros y contras

Cloudflare Workers

Pros

  • El V8 isolate arranca, según Cloudflare, hasta ~100 veces más rápido que un proceso Node
  • Precios basados en CPU-time; el tiempo de espera de I/O es gratuito
  • Capa de datos integrada en la misma plataforma: KV, D1, R2, Durable Objects, Hyperdrive
  • Desarrollo local ligero con Wrangler y despliegue global con un solo comando
  • 100.000 solicitudes/día en el plan gratuito; base de $5 + cuota incluida amplia en el plan de pago
  • El runtime workerd es de código abierto bajo licencia Apache-2.0
  • Pool de conexiones a Postgres/MySQL existentes (incluido AWS RDS) mediante Hyperdrive
  • Compatibilidades con APIs de Node.js, como node:fs, que facilitan migrar librerías existentes

Contras

  • CPU-time por defecto de 30 s, con un tope de 5 min en solicitudes HTTP (plan de pago) — no apto para trabajos síncronos largos
  • Memoria fija de 128 MB, no se puede aumentar
  • Incluso en Cron Triggers y Queue Consumers una sola invocación tiene un tope de 15 min (en Cron solo con intervalos de 1 hora o más; por debajo, 30 s) — los trabajos por lotes de horas no son nativos
  • El modelo de V8 isolate no admite addons nativos de Node.js
  • En el plan gratuito el CPU-time está limitado a 10 ms; para tráfico de producción es obligatorio el plan de pago
  • No tiene la profundidad de disparadores directos/event source mapping de los servicios de AWS; el ecosistema es más reducido

Ideal para

Procesamiento de solicitudes globales cortas y sensibles a la latencia, como autenticación, enrutamiento o personalizaciónCapa ligera delante de un API gateway o de webhooksPruebas A/B y manipulación de respuestas en el edgeLógica dinámica ligera adyacente a la CDNRespuestas de baja latencia para audiencias distribuidas geográficamente

AWS Lambda

Pros

  • Configuración de memoria flexible entre 128 MB y 10.240 MB
  • Duración máxima de ejecución de 15 min; con Managed Instances es posible pasar a cargas de trabajo más largas
  • Acceso VPC con conexión directa a recursos de red privada como RDS o ElastiCache
  • Integración nativa con servicios de AWS: S3, DynamoDB, SQS, Kinesis, EventBridge, API Gateway y Cognito pueden invocar la función directamente
  • Observabilidad profunda con CloudWatch + X-Ray
  • Amplio soporte de runtimes: Node.js, Python, Java, Go, .NET, Ruby, runtime personalizado
  • Capa gratuita: 1M de solicitudes + 400.000 GB-segundo/mes

Contras

  • El arranque en frío de la microVM de Firecracker es más lento que el de un V8 isolate (en VPC se reduce con Hyperplane ENI, pero no se elimina)
  • Precios basados en GB-segundo; se cobra por memoria×duración
  • Una función conectada a una VPC queda sin acceso a internet por defecto — es obligatorio un NAT Gateway/VPC endpoint
  • No tiene presencia global de PoPs; funciona por región y no enruta automáticamente al edge más cercano
  • El desarrollo local con SAM/CDK no es tan ligero como con Wrangler
  • La amplia superficie de integración de servicios conlleva complejidad y riesgo de vendor lock-in

Ideal para

Cargas de trabajo dependientes de recursos privados de AWS dentro de una VPC, como RDS/ElastiCacheProcesamiento de datos de larga duración, ETL, tareas de consumo de batch/queueProcesamiento de imágenes/video o inferencia de ML que requiere mucha memoriaOrquestación event-driven en una arquitectura nativa de AWS (S3, DynamoDB, Step Functions)Equipos empresariales que ya tienen una inversión profunda en AWS

Comparación de código

Cloudflare Workers
// Cloudflare Workers - API que se conecta a Postgres mediante Hyperdrive
import { Hono } from "hono";
import postgres from "postgres";

interface Env {
  HYPERDRIVE: Hyperdrive;
}

const app = new Hono<{ Bindings: Env }>();

app.get("/api/users/:id", async (c) => {
  // Abrir un cliente nuevo en cada solicitud es rápido — Hyperdrive
  // ya mantiene el pool de conexiones en la plataforma.
  const sql = postgres(c.env.HYPERDRIVE.connectionString, {
    max: 5,
    fetch_types: false,
  });

  // Hyperdrive limpia la conexión por sí solo al terminar la solicitud; no hace falta llamar a sql.end().
  const id = c.req.param("id");
  const rows = await sql`
    SELECT id, name, plan FROM users WHERE id = ${id} LIMIT 1
  `;

  if (rows.length === 0) {
    return c.json({ error: "not_found" }, 404);
  }

  return c.json(rows[0]);
});

export default app;

/*
wrangler.jsonc
{
  "name": "edge-api",
  "main": "src/index.ts",
  "compatibility_date": "2026-09-01",
  "hyperdrive": [
    { "binding": "HYPERDRIVE", "id": "<hyperdrive-config-id>" }
  ]
}
*/
AWS Lambda
// AWS Lambda (Node.js) - handler que se conecta a RDS Postgres dentro de una VPC
import { Client } from "pg";

let client; // se conserva al reutilizar el contenedor (warm start)

export const handler = async (event) => {
  const id = event.pathParameters?.id;

  if (!client) {
    client = new Client({
      host: process.env.DB_HOST, // endpoint privado de RDS (dentro de la VPC)
      port: 5432,
      database: process.env.DB_NAME,
      user: process.env.DB_USER,
      password: process.env.DB_PASSWORD,
      ssl: { rejectUnauthorized: true },
    });
    await client.connect();
  }

  try {
    const result = await client.query(
      "SELECT id, name, plan FROM users WHERE id = $1 LIMIT 1",
      [id]
    );

    if (result.rows.length === 0) {
      return { statusCode: 404, body: JSON.stringify({ error: "not_found" }) };
    }

    return { statusCode: 200, body: JSON.stringify(result.rows[0]) };
  } catch (err) {
    console.error(err);
    return { statusCode: 500, body: JSON.stringify({ error: "internal" }) };
  }
};

/*
template.yaml (AWS SAM) — VPC + memory + timeout
Resources:
  UsersFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs22.x
      MemorySize: 512
      Timeout: 15 # segundos (tope 900 = 15 min)
      VpcConfig:
        SecurityGroupIds: [sg-xxxxxxxx]
        SubnetIds: [subnet-xxxxxxxx, subnet-yyyyyyyy]
      Policies:
        - VPCAccessPolicy: {}
*/

Conclusión

No hay un ganador absoluto: para cargas de trabajo cortas, sensibles a la latencia y de alcance global (autenticación, enrutamiento, personalización, API gateway, webhooks), Cloudflare Workers ofrece tanto menor costo como menos fricción por arranque en frío. En trabajos de larga duración, con alto consumo de memoria o dependientes de recursos de AWS dentro de una VPC, Lambda va por delante: sus límites son más amplios y el acceso a red privada ya está en disponibilidad general (GA), mientras que en Workers sigue en beta. El patrón de producción más común es híbrido: Workers como capa ligera en el edge, Lambda encargándose del trabajo pesado detrás.

Solicita una consultoría gratuita
FAQ

Preguntas frecuentes

Depende, hay que calcularlo según la carga de trabajo. El plan de pago de Workers incluye una base de $5/mes + 10M de solicitudes + 30M de CPU-ms; por encima de eso se cobran $0,30/millón de solicitudes + $0,02/millón de CPU-ms, y el tiempo de espera de I/O es gratuito. Lambda, en cambio, cobra por solicitud + GB-segundo (memoria×duración); su capa gratuita incluye 1M de solicitudes + 400.000 GB-segundo/mes. En trabajos cortos y dominados por I/O, el modelo de CPU-time de Workers puede salir más barato; en trabajos largos e intensivos en CPU, el modelo de GB-segundo de Lambda varía según la carga de trabajo.

Artículos de blog relacionados

Ver todos los artículos

Proyectos relacionados

Ver todos los proyectos
Todas las comparaciones