Hóa đơn AWS tháng trước của bạn có một dòng Lambda vài trăm đô. Mở CloudWatch ra xem: 80% invocation là mấy việc lặt vặt — verify JWT, nhận webhook từ Stripe, redirect A/B test, trả JSON dưới 50ms. Mỗi function chạy chưa tới 100ms nhưng bị tính tròn theo GB-second, cộng thêm cold start thỉnh thoảng đội p95 lên hơn 2 giây khiến team phải bật provisioned concurrency — lại thêm tiền.
Đó là mẫu hình rất phổ biến năm 2026: trả tiền Lambda cho những việc edge function làm nhanh hơn và rẻ hơn. Vấn đề không phải Lambda tệ. Vấn đề là ta đang chia workload theo thương hiệu cloud ("team mình dùng AWS") thay vì theo mô hình tính.
Con số 240x và vì sao nó không phải lúc nào cũng quan trọng
Số đo 2026: Cloudflare Workers cold start dưới 5ms. Lambda trên Node.js 20 có cold start p95 khoảng 1.2–2.8s. Chênh nhau cỡ 240 lần.
Lý do nằm ở kiến trúc. Workers chạy V8 isolate — một sandbox nhẹ trong process đã có sẵn, spin up gần như tức thì. Lambda phải khởi tạo microVM (Firecracker), load runtime Node.js, chạy init code. Đó là hai mô hình tính khác nhau về bản chất, không phải một bên "tối ưu hơn" một bên.
Nhưng con số này chỉ quan trọng với workload request-response: có người dùng (hoặc dịch vụ) đang đứng chờ phản hồi. Với batch job chạy 5 phút, cold start 2 giây là sai số làm tròn. Với API auth check mà client chờ, cold start 2 giây là incident.
Nói cách khác: đừng đọc benchmark cold start rồi kết luận "phải chuyển hết sang edge". Hãy hỏi: workload này có ai đang chờ synchronous không?
Bảng phân loại: việc nào đi đâu
| Workload | Nên chạy ở đâu | Vì sao |
|---|---|---|
| Auth check / verify JWT | Edge (Workers) | Ngắn, latency-sensitive, gần user |
| Webhook receiver (Stripe, GitHub...) | Edge | Nhận, validate, đẩy vào queue — xong trong vài ms |
| A/B test, redirect, rewrite | Edge | Chạy trước khi request chạm origin |
| API latency-sensitive, đọc-nhiều | Edge | Cold start ~0, chạy tại PoP gần user |
| Batch processing, ETL | Lambda / container | Chạy lâu, cần CPU/memory lớn, không ai chờ |
| ML inference | Lambda / container | Cần model lớn, GPU, memory vượt giới hạn edge |
| Việc dính IAM, VPC, RDS private | Lambda | Edge không vào được VPC; IAM là chất keo AWS |
| Job cần CloudWatch/X-Ray sâu | Lambda | Observability stack đã gắn sẵn |
Quy tắc rút gọn: edge cho lớp trước, Lambda cho lớp sau. Cái gì ngắn, synchronous, gần user — edge. Cái gì dài, asynchronous, gắn sâu hệ sinh thái AWS — Lambda.
Hai mô hình tính tiền, một bài tính tay
Đây là phần đáng tiền nhất, theo nghĩa đen.
Lambda tính theo GB-second: memory bạn cấu hình nhân với thời gian chạy (làm tròn 1ms), cộng phí per-request. Điểm chết người: bạn trả cả thời gian function chờ — chờ database, chờ API bên thứ ba. Function 128MB chạy 200ms nhưng 150ms trong đó là chờ Postgres trả lời? Bạn vẫn trả đủ 200ms.
Workers tính theo per-request + CPU-milliseconds. Thời gian chờ I/O không tính tiền. Chỉ tính lúc CPU thực sự chạy code của bạn.
Tính tay cho một API auth check điển hình, 10 triệu request/tháng, mỗi request ~100ms wall time nhưng chỉ ~5ms CPU (còn lại là chờ verify key, gọi 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.
Bài học không nằm ở con số tuyệt đối (giá thay đổi, hãy tự tính lại với hóa đơn của bạn) mà ở cấu trúc: với workload ngắn và nhiều I/O, chi phí Lambda thật sự nằm ở những thứ xung quanh — API Gateway, provisioned concurrency, NAT Gateway nếu function trong VPC. Phân tích Mintec 2026 ghi nhận mức tiết kiệm ~70% khi chuyển nhóm workload request-response ngắn từ Lambda sang Workers — và phần lớn khoản tiết kiệm đến từ việc bỏ được các phụ kiện đó, không phải từ giá compute.
Ngược lại, với batch job 5 phút ăn 3GB RAM, mô hình GB-second của Lambda lại hợp lý — và Workers thậm chí không cho bạn chạy (giới hạn CPU time).
Hệ sinh thái edge đủ dùng chưa?
Câu hỏi hợp lý: "edge nhanh, nhưng data ở đâu?" Đến 2026, câu trả lời khá hơn nhiều:
- Edge database đã GA: Cloudflare D1, Turso (SQLite phân tán), Neon (Postgres serverless) đều production-ready, có read replica gần PoP. Framework edge-first — Next.js, Remix, SvelteKit — coi đây là mặc định.
- Nhưng giới hạn vẫn thật: Workers không cho mở TCP connection tùy ý (kết nối Postgres truyền thống phải đi qua driver HTTP hoặc connection pooler như Hyperdrive/Neon proxy). CPU time bị giới hạn — vài chục ms trên plan thường. Không vào được VPC của bạn. Bundle size có trần.
Nghĩa là: edge không phải nơi chạy "mọi thứ". Nó là nơi chạy lớp mỏng phía trước — và làm việc đó cực tốt.
Kiến trúc hybrid: cái mà 78% team đang chạy
Thực tế 2026 không phải "edge vs Lambda" mà là cả hai: khoảng 78% team chạy hybrid serverless + container. Mẫu hình phổ biến:
flowchart LR
U[User] --> E[Edge Workers<br/>auth, routing, cache,<br/>A/B, webhook intake]
E -->|"hit cache / trả luôn"| 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 làm gác cổng: chặn request rác trước khi nó tốn tiền Lambda, verify token, trả cache, nhận webhook rồi đẩy queue. Lambda và container làm việc nặng phía sau, nơi IAM, VPC và CloudWatch phát huy giá trị thật.
Cách migrate thực dụng: đừng viết lại. Mở billing dashboard, sort Lambda function theo invocation count, lọc những function có duration dưới ~100ms và bản chất request-response. Chuyển từng cái một sang edge, đo lại p95 và hóa đơn sau một tháng. Thường 5–10 function đầu bảng đã chiếm phần lớn cả invocation lẫn nỗi đau cold start.
Câu hỏi "AWS hay Cloudflare" là câu hỏi của phòng procurement. Câu hỏi của kỹ sư là: workload này ngắn hay dài, có ai chờ không, và mình đang trả tiền cho CPU hay cho thời gian ngồi chờ I/O. Trả lời đúng ba câu đó, hóa đơn tự khắc gọn lại — bất kể logo nào trên invoice.
