Your AWS bill from last month has a Lambda line item for several hundred dollars. Open CloudWatch: 80% of invocations are trivial tasks — verifying JWT, receiving Stripe webhooks, A/B test redirects, returning JSON in under 50ms. Each function runs for less than 100ms but is rounded up by GB-second, plus occasional cold starts pushing p95 over 2 seconds, forcing the team to enable provisioned concurrency — adding more cost.
This is a very common pattern in 2026: paying for Lambda for tasks that edge functions do faster and cheaper. The problem isn't that Lambda is bad. The problem is that we are splitting workloads by cloud brand ("our team uses AWS") instead of by computing model.
The 240x figure and why it isn't always important
2026 metrics: Cloudflare Workers cold start is under 5ms. Lambda on Node.js 20 has a p95 cold start of around 1.2–2.8s. That is a difference of about 240x.
The reason lies in the architecture. Workers run V8 isolates — a lightweight sandbox within an existing process that spins up almost instantly. Lambda must initialize a microVM (Firecracker), load the Node.js runtime, and run init code. These are two fundamentally different computing models, not one being "more optimized" than the other.
But this number only matters for request-response workloads request-response: where a user (or service) is waiting for a response. For a 5-minute batch job, a 2-second cold start is rounding error. For an API auth check where the client is waiting, a 2-second cold start is an incident.
In other words: don't read cold start benchmarks and conclude "we must migrate everything to the edge." Ask: is anyone waiting synchronously for this workload?
Classification table: which task goes where
| Workload | Where to run | Why |
|---|---|---|
| Auth check / verify JWT | Edge (Workers) | Short, latency-sensitive, close to user |
| Webhook receiver (Stripe, GitHub...) | Edge | Receive, validate, push to queue — done within a few ms |
| A/B test, redirect, rewrite | Edge | Runs before the request reaches origin |
| API latency-sensitive, read-heavy | Edge | Cold start ~0, run at PoP near user |
| Batch processing, ETL | Lambda / container | Long-running, requires high CPU/memory, non-interactive |
| ML inference | Lambda / container | Requires large model, GPU, memory exceeding edge limits |
| Tasks involving IAM, VPC, private RDS | Lambda | Edge cannot access VPC; IAM is the AWS glue |
| Jobs requiring deep CloudWatch/X-Ray | Lambda | Observability stack is pre-configured |
Reduction rules: edge for the previous layer, Lambda for the subsequent layerWhat is short, synchronous, and close to the user — edge. What is long, asynchronous, and deeply integrated into the AWS ecosystem — Lambda.
Two billing models, one manual calculation
This is the most expensive part, literally.
Lambda is billed by GB-second: your configured memory multiplied by execution time (rounded to 1ms), plus per-request fees. The killer point: you pay for the entire function waiting — waiting for the database, waiting for third-party APIs. A 128MB function runs for 200ms, but 150ms of that is waiting for Postgres to respond? You still pay for the full 200ms.
Workers are billed by per-request + CPU-millisecondsI/O wait time is not charged. Only charge when the CPU is actually executing your code.
Manual calculation for a typical auth check API, 10 million requests/month, each request ~100ms wall time but only ~5ms CPU (the rest is waiting for key verification, calling cache):
Lambda (128MB, 100ms/request):
Compute: 10M × 0.1s × 0.125GB = 125,000 GB-s
≈ 125,000 × $0.0000166667 ≈ $2.08
Requests: 10M × $0.20/1M = $2.00
+ Provisioned concurrency để tránh cold start p95 2s:
1 instance 128MB chạy 24/7 ≈ $1.35–$4/tháng/instance,
thực tế cần nhiều instance → đây mới là khoản lớn
+ API Gateway phía trước: 10M × $1.0/1M = $10.00
Workers (paid plan):
Requests: 10M × $0.30/1M = $3.00
CPU: 10M × 5ms = 50,000 CPU-s → phần lớn nằm trong included
Không cần API Gateway, không cần provisioned concurrency.
The lesson is not in the absolute numbers (prices change, recalculate with your own invoices) but in the structure: for short workloads with high I/O, the real Lambda cost lies in the surrounding components — API Gateway, provisioned concurrency, NAT Gateway if the function is in a VPC. Mintec 2026 analysis recorded ~70% savings when migrating short request-response workload groups from Lambda to Workers — and most of those savings come from eliminating those accessories, not from the compute price.
Conversely, for a 5-minute batch job consuming 3GB RAM, Lambda's GB-second model is reasonable — and Workers won't even let you run it (CPU time limits).
Is the edge ecosystem sufficient?
A reasonable question: "edge is fast, but where is the data?" By 2026, the answer is much better:
- Edge databases have reached GA: Cloudflare D1, Turso (distributed SQLite), Neon (serverless Postgres) are all production-ready, with read replicas near the PoP. Edge-first frameworks — Next.js, Remix, SvelteKit — treat this as default.
- But the limitations are real: Workers do not allow arbitrary TCP connections (traditional Postgres connections must go through an HTTP driver or a connection pooler like Hyperdrive/Neon proxy). CPU time is limited — a few dozen ms on the standard plan. Cannot access your VPC. Bundle size has a ceiling.
Meaning: edge is not the place to run "everything." It is the place to run the thin front-end layer — and it does that extremely well.
Hybrid architecture: what 78% of teams are running
In reality, 2026 is not "edge vs Lambda" but both: approximately 78% of teams run hybrid serverless + container. Common patterns:
flowchart LR
U[Please provide the Vietnamese HTML fragment you would like me to translate.] --> E[Edge Workers<br/>auth, routing, cache,<br/>A/B, webhook intake]
E -->|"hit cache / return immediately"| U
E --> Q[Queue]
E --> L[Lambda / container<br/>business logic nặng,<br/>batch, ML inference]
L --> DB[(RDS / DynamoDB<br/>trong VPC)]
Q --> L
Edge acts as a gatekeeper: block junk requests before they consume Lambda costs, verify tokens, serve cache, receive webhooks, and push to a queue. Lambda and containers handle the heavy lifting in the background, where IAM, VPC, and CloudWatch provide real value.
A pragmatic migration approach: don't rewrite. Open the billing dashboard, sort Lambda functions by invocation count, and filter for functions with a duration under ~100ms that are essentially request-response. Move them one by one to the edge, then re-measure p95 and the bill after one month. Usually, the top 5–10 functions account for most of both the invocations and the cold start pain.
The "AWS or Cloudflare" question is a procurement question. An engineer's question is: is this workload short or long, is anyone waiting, and are we paying for CPU or for I/O wait time. Answer those three questions correctly, and the bill will naturally shrink — regardless of which logo is on the invoice.
