Cloudflare Workers and AWS Lambda both run serverless functions, but they optimize for different problems. Workers execute at the edge—close to users—while Lambda runs in AWS regions with deep integration into the rest of the AWS ecosystem. Startups do not need to pick one religion; they need a clear split of responsibilities.

The decision in one sentence

Use Workers for request handling at the edge (auth gates, routing, A/B, lightweight APIs, static sites with dynamic hooks). Use Lambda for business logic tied to VPC resources, heavy runtimes, long-running workflows, and AWS-native services (SQS, Step Functions, RDS, etc.).

Latency and user experience

Workers run in Cloudflare’s global network, so simple handlers often respond in milliseconds worldwide without multi-region Lambda configuration. That matters for:

  • Marketing sites and personal brands (like this site on Workers static assets)
  • Global SaaS with auth/session checks at the edge
  • API gateways that fan out to origin services

Lambda in a single region (e.g. us-east-1) adds round-trip latency for distant users unless you invest in multi-region architecture. For US-only B2B tools, one region is often fine.

Cold starts and runtime limits

Workers use V8 isolates with very fast startup—ideal for high-churn, short handlers. Lambda cold starts vary by runtime and memory; Node and Python are common for startups but can sting on bursty traffic if not provisioned carefully.

Lambda supports longer executions, larger memory, and more traditional server runtimes. Workers have CPU time limits suited to request/response work, not hour-long batch jobs—those belong on Lambda, ECS, or Step Functions.

Data and VPC

If your product’s source of truth is RDS MySQL in a private VPC, Lambda (with VPC attachment) or EC2/ECS is the natural path. Workers should not pretend to be your database layer; pair them with D1, Hyperdrive, or external APIs when data lives at the edge or behind a public API.

I often deploy: Workers for public HTTP + Lambda for transactional APIs + MySQL on RDS or managed SQL—with clear boundaries and no duplicate business rules in both places.

Cost model (how founders should think about it)

  • Workers — strong economics for high-volume, lightweight requests; generous free tier for experiments
  • Lambda — pay per invoke and duration; predictable when traffic is moderate; watch NAT gateway and VPC costs

Total cost is never “Lambda vs Workers” alone—it includes data transfer, databases, observability, and engineer time. The cheaper platform you cannot operate is the expensive one.

Developer experience and operations

Teams already on AWS often move faster on Lambda day one. Teams living on Cloudflare for DNS, WAF, and CDN often ship faster on Workers because deploys and routing are unified.

Wrangler gives you local dev, static assets, and Workers in one config—excellent for marketing sites, edge middleware, and small APIs. SAM/CDK/Terraform on AWS are heavier but scale with enterprise compliance requirements.

Common patterns that work

Pattern A: Edge + regional core

Worker validates JWT, applies rate limits, caches GET responses → Lambda handles writes and database transactions. Clean security boundary.

Pattern B: AWS-only MVP

API Gateway + Lambda + DynamoDB or RDS until product-market fit. Add Workers later for global performance.

Pattern C: Cloudflare-first product

Static front end on Workers assets, APIs on Workers, D1 or external HTTP data store—minimal AWS footprint for early-stage capital efficiency.

Red flags when choosing

  • Duplicating payment or auth logic in both Workers and Lambda
  • Putting long-running ML inference on Workers without measuring CPU limits
  • Lambda in VPC without understanding cold start impact on user-facing routes
  • Ignoring observability—use structured logs and tracing on both sides

Bottom line

Choose Workers when the user-facing path benefits from edge speed and simple handlers. Choose Lambda when your system is AWS-centric, VPC-heavy, or needs longer compute and mature backend integrations. Most growth-stage startups I work with end up using both, with a written rule for what runs where.