AWS Lambda – Pricing & RAM Optimization
Tài liệu tổng hợp từ cuộc thảo luận về cách Lambda tính tiền, tối ưu RAM, và phân tích theo từng use-case thực tế.
1. Lambda có mất tiền khi không dùng không?
Không. AWS Lambda tính tiền theo pay-per-use thực sự:
- Không có invocation → không có duration → $0 hoàn toàn
- Free tier: 1 triệu requests/tháng + 400,000 GB-seconds/tháng
Các chi phí "xung quanh" Lambda khi idle
| Thứ | Mất tiền khi idle? |
|---|---|
| Lambda itself | ❌ Không |
| CloudWatch Logs | ✅ Có (lưu trữ log cũ) |
| EventBridge rules | ❌ Không |
| VPC / ENI | ❌ Không |
| ECR image (container Lambda) | ✅ Có (lưu trữ image) |
| Provisioned Concurrency | ✅ Có – ngoại lệ lớn nhất |
2. I/O-bound vs CPU-bound là gì?
Đây là khái niệm cốt lõi để hiểu khi nào nên tăng RAM Lambda.
I/O-bound — Lambda ngồi chờ dịch vụ bên ngoài
I/O-bound = phần lớn thời gian Lambda không tính toán gì cả, chỉ đang chờ response từ dịch vụ bên ngoài:
Lambda → gọi DynamoDB → chờ response
Lambda → gọi HTTP API → chờ response
Lambda → đọc file S3 → chờ download
Lambda → gọi ElastiCache → chờ response
Lambda → gọi RDS → chờ queryNhìn vào timeline thực tế:
|--2ms--|----------200ms chờ DynamoDB response----------|--2ms--|
CPU CPU đang idle, không làm gì, chỉ chờ bytes CPU
chạy trả về qua network chạyLambda chạy tổng 204ms, nhưng CPU thực sự chỉ làm việc 4ms.
200ms còn lại là thời gian chờ mạng — tăng RAM/CPU không rút ngắn được.
Tại sao tăng RAM không giảm được I/O-bound execution time?
Hình dung Lambda như một nhân viên văn phòng:
CPU-bound:
Nhân viên tự ngồi tính toán bảng Excel 1000 dòng
→ Thuê nhân viên giỏi hơn (RAM cao hơn) → xong nhanh hơn ✅
I/O-bound:
Nhân viên gửi email cho đối tác, rồi ngồi chờ họ reply
→ Thuê nhân viên giỏi hơn (RAM cao hơn)
→ Vẫn phải chờ đối tác reply như cũ ❌
Vì tốc độ reply phụ thuộc vào đối tác, không phải nhân viênVới Lambda I/O-bound — DynamoDB query chẳng hạn:
1. Lambda gửi request đến DynamoDB ← Lambda làm (1ms)
2. Request đi qua network đến AWS ← mạng (5ms)
3. DynamoDB tìm kiếm data trong storage ← DynamoDB làm (15ms)
4. Response đi qua network về Lambda ← mạng (5ms)
5. Lambda đọc response ← Lambda làm (1ms)
Tổng: 27ms — Lambda chỉ làm việc 2ms, còn 25ms là chờBước 2, 3, 4 xảy ra hoàn toàn bên ngoài Lambda — RAM cao hay thấp không ảnh hưởng gì đến tốc độ network hay tốc độ DynamoDB xử lý.
Tăng RAM chỉ giúp Lambda làm việc nhanh hơn — không giúp thế giới bên ngoài phản hồi nhanh hơn.
Vì vậy với I/O-bound: tăng RAM → duration gần như không đổi → GB-seconds tăng → tốn tiền hơn vô ích.
CPU-bound — Lambda tự tính toán là chính
CPU-bound = Lambda dành phần lớn thời gian tự xử lý data — không cần chờ ai:
Resize ảnh → CPU chạy hết công suất liên tục
Encrypt data → CPU tính toán liên tục
Parse JSON lớn → CPU + RAM xử lý toàn bộ data|----------------------------2000ms CPU chạy liên tục--------------------------|
Resize ảnh, không chờ network, CPU là bottleneck duy nhấtTăng RAM = AWS cấp thêm CPU → Lambda xử lý nhanh hơn → duration giảm → có thể rẻ hơn.
Tại sao AWS gắn CPU với RAM?
AWS không cho phép chọn CPU trực tiếp. CPU được phân bổ tỉ lệ thuận với RAM:
128MB RAM → ~0.08 vCPU
512MB RAM → ~0.32 vCPU
1769MB RAM → 1 vCPU đầy đủ
3008MB RAM → ~1.7 vCPU
10240MB RAM → ~6 vCPU→ Cách duy nhất tăng CPU cho Lambda là tăng RAM.
→ Với I/O-bound: có thêm CPU cũng vô dụng vì Lambda đang chờ network, không tính toán.
Tóm tắt
| CPU-bound | I/O-bound | |
|---|---|---|
| Lambda đang làm gì? | Tự tính toán | Chờ dịch vụ bên ngoài trả lời |
| Bottleneck | CPU / Memory | Network + thời gian xử lý của dịch vụ bên ngoài |
| Ví dụ | Image resize, crypto, ML | DynamoDB, HTTP API, S3, Redis |
| Tăng RAM có giúp không? | ✅ Có | ❌ Không |
| RAM khuyên dùng | 1024–2048MB | 128–256MB |
3. Lambda tính tiền như thế nào?
2.1 Requests
| Giá | |
|---|---|
| Free tier | 1,000,000 requests/tháng |
| Sau free tier | $0.20 / 1 triệu requests |
2.2 Duration
Đơn vị: GB-seconds = memory (GB) × thời gian chạy (seconds)
| Giá | |
|---|---|
| Free tier | 400,000 GB-seconds/tháng |
| Sau free tier | $0.0000166667 / GB-second |
Ví dụ tính:
Lambda 512MB, chạy 200ms, invoke 1 triệu lần/tháng
Duration = 0.5 GB × 0.2s × 1,000,000 = 100,000 GB-seconds → $0 (free tier)
Lambda 1GB, chạy 1s, invoke 1 triệu lần/tháng
Duration = 1,000,000 GB-seconds → (1,000,000 - 400,000) × $0.0000166667 ≈ $10/tháng2.3 Ephemeral Storage (/tmp)
Ephemeral Storage = bộ nhớ tạm thời của Lambda, chính là thư mục /tmp.
Ephemeral nghĩa là tạm thời — data ở đây sẽ mất khi Lambda execution context bị destroy (sau khi idle một thời gian hoặc deploy lại).
Lambda cần xử lý file ảnh 50MB từ S3:
1. Download ảnh từ S3 → lưu tạm vào /tmp/image.jpg ← Ephemeral Storage
2. Sharp xử lý resize
3. Upload kết quả lên S3
4. Lambda kết thúc
→ /tmp/image.jpg vẫn còn nếu Lambda warm (execution context tái sử dụng)
→ /tmp/image.jpg mất nếu Lambda cold start lần sau| Mặc định | Tối đa | |
|---|---|---|
| Dung lượng | 512MB miễn phí | 10GB |
| Chi phí thêm | $0 | $0.0000000309/GB-second |
Khi nào cần tăng /tmp?
✅ Xử lý file lớn (video, PDF nhiều trang)
✅ Unzip archive lớn trước khi xử lý
✅ ML model cần cache xuống local trước khi load
❌ Lưu data cần persist → dùng S3 hoặc DynamoDB
❌ Share data giữa các Lambda → dùng Redis/S32.4 Provisioned Concurrency
Tính tiền liên tục kể cả khi không có request:
- $0.000004646 / GB-second (allocated)
- $0.000009313 / GB-second (khi đang xử lý request)
3. Tại sao RAM cao hơn có thể rẻ hơn?
Lambda tính theo GB-seconds. Nếu tăng RAM giúp giảm duration đủ nhiều → tổng GB-seconds giảm → rẻ hơn.
Ví dụ 1: Image processing – 1 triệu invoke/tháng
| 512MB | 1024MB (2x RAM) | |
|---|---|---|
| Duration/invoke | 2000ms | 800ms |
| GB-seconds/invoke | 1.0 | 0.8 |
| Tổng GB-seconds | 1,000,000 | 800,000 |
| Sau free tier | 600,000 | 400,000 |
| Chi phí | $10.00 | $6.67 ✅ |
→ RAM gấp đôi nhưng rẻ hơn $3.33/tháng
Công thức break-even
RAM_mới / RAM_cũ = Duration_cũ / Duration_mới
Tăng RAM 2x → cần duration giảm > 50%
Tăng RAM 4x → cần duration giảm > 75%4. Mặt tối của việc tăng RAM
4.1 Tốn tiền nếu workload là I/O-bound
Lambda gọi DynamoDB → chờ 50ms network
Dù RAM là 128MB hay 10GB → vẫn chờ 50ms như nhau
Nhưng GB-seconds tăng gấp 80 lần| RAM | Duration (I/O-bound) | GB-seconds |
|---|---|---|
| 128MB | 300ms | 0.038 |
| 1024MB | 290ms | 0.290 |
| 3008MB | 285ms | 0.854 ❌ |
4.2 Concurrency × RAM = giới hạn account
Lambda = 3008MB, concurrent = 1000
→ Tổng memory = ~3TB RAM ảo
→ AWS throttle → các Lambda khác trong account bị ảnh hưởng4.3 Cold start lâu hơn
| RAM | Cold start |
|---|---|
| 128MB | ~200–400ms |
| 1024MB | ~400–800ms |
| 3008MB | ~800–1500ms |
4.4 Lãng phí RAM không dùng đến
Code chỉ cần 100MB thực tế, allocate 3GB
→ 2900MB là tiền vứt đi hoàn toàn4.5 Che giấu vấn đề thực sự (nguy hiểm nhất)
Memory leak → Lambda crash sau 30s với 128MB
Tăng lên 3GB → chạy được 10 phút trước khi crash
Vấn đề vẫn còn đó, chỉ là chậm phát hiện hơn
5. So sánh RAM theo từng Use-case
Use-case 1: Image Resizing (CPU-bound) ✅ Nên tăng RAM
| RAM | Duration | GB-seconds | Cost/1M invoke |
|---|---|---|---|
| 256MB | 3000ms | 0.75 | $5.83 |
| 512MB | 1500ms | 0.75 | $5.83 |
| 1024MB | 600ms | 0.614 | $3.57 |
| 2048MB | 280ms | 0.573 | $2.89 ✅ |
| 3008MB | 270ms | 0.810 | $6.83 ❌ |
Sweet spot: 2048MB — rẻ hơn 50% so với 256MB dù RAM tăng 8x
Use-case 2: DynamoDB Query đơn giản (I/O-bound) ❌ Không nên tăng RAM
| RAM | Duration | GB-seconds | Cost/1M invoke |
|---|---|---|---|
| 128MB | 80ms | 0.010 | $0.00 ✅ |
| 256MB | 75ms | 0.019 | $0.00 |
| 1024MB | 70ms | 0.072 | $0.83 |
| 3008MB | 68ms | 0.204 | $3.40 ❌ |
3008MB đắt hơn 128MB 340 lần mà nhanh hơn... 12ms
Use-case 3: JSON Parsing file lớn (Memory-bound) ✅ Tăng RAM vừa phải
| RAM | Duration | GB-seconds | Cost/100k invoke |
|---|---|---|---|
| 128MB | 8000ms | 1.000 | $9.99 |
| 512MB | 1800ms | 0.900 | $8.33 ✅ |
| 1024MB | 900ms | 0.900 | $8.33 ✅ |
| 2048MB | 850ms | 1.706 | $21.74 ❌ |
Sweet spot: 512MB–1024MB — trên đó file đã load hết vào RAM rồi, tăng thêm = lãng phí
Use-case 4: HTTP External API Call (I/O-bound) ❌ Không nên tăng RAM
| RAM | Duration | GB-seconds | Cost/500k invoke |
|---|---|---|---|
| 128MB | 1200ms | 0.150 | $0.00 ✅ |
| 512MB | 1150ms | 0.575 | $2.91 |
| 3008MB | 1100ms | 3.309 | $48.09 ❌ |
Lambda đang ngồi chờ network 90% thời gian — tăng RAM không rút ngắn được thời gian server bên kia xử lý
Use-case 5: Crypto / JWT signing, hashing (CPU-bound) ✅ Nên tăng RAM
| RAM | Duration | GB-seconds | Cost/1M invoke |
|---|---|---|---|
| 128MB | 5000ms | 0.625 | $3.75 |
| 512MB | 1200ms | 0.600 | $3.33 |
| 1024MB | 580ms | 0.580 | $3.00 ✅ |
| 2048MB | 290ms | 0.580 | $3.00 ✅ |
| 3008MB | 200ms | 0.601 | $3.34 ❌ |
1024MB và 2048MB chi phí như nhau — chọn 2048MB nếu latency quan trọng
Use-case 6: ML Inference nhẹ (CPU + Memory-bound) ✅ Tăng RAM cao
| RAM | Duration | GB-seconds | Cost/200k invoke |
|---|---|---|---|
| 512MB | OOM crash ❌ | - | - |
| 1024MB | 4000ms | 4.000 | $59.99 |
| 2048MB | 1500ms | 3.000 | $43.32 |
| 3008MB | 900ms | 2.707 | $38.44 ✅ |
Model cần ~500MB chỉ để load — bắt buộc RAM cao. Cân nhắc dùng SageMaker nếu model lớn hơn.
6. Tổng hợp: Cheat sheet
| Use-case | Bottleneck | RAM khuyên dùng | Lý do |
|---|---|---|---|
| Image/Video processing | CPU | 1024–2048MB | CPU scale với RAM |
| DynamoDB / RDS query | Network I/O | 128–256MB | Tăng thêm vô nghĩa |
| JSON parsing file lớn | Memory | 512–1024MB | Đủ load data vào RAM |
| HTTP external API | Network I/O | 128MB | Chờ 3rd party, không phải CPU |
| Crypto / JWT / hashing | CPU | 1024–2048MB | CPU-intensive |
| ML inference | CPU + Memory | 2048–3008MB | Model size yêu cầu |
| EventBridge fan-out logic | CPU nhẹ | 256MB | Logic đơn giản |
| Strapi webhook handler | I/O mix | 256–512MB | Parse nhẹ + gọi DB |
7. Khi nào nên / không nên tăng RAM?
✅ Có benchmark thực tế (Lambda Power Tuning)
✅ Workload là CPU/memory-bound (image, crypto, parsing lớn)
✅ Duration giảm đủ để bù chi phí RAM (break-even > 50% nếu tăng 2x)
❌ Tăng vì "cứ nhiều RAM là nhanh"
❌ Workload chủ yếu chờ DB/HTTP
❌ Không đo trước, tăng rồi quên8. Quy trình tối ưu RAM đúng cách
1. Deploy với RAM mặc định (512MB hoặc theo estimate)
2. Chạy AWS Lambda Power Tuning trên staging
3. Đọc đồ thị cost vs performance
4. Chọn mức RAM tối ưu
5. Review lại sau mỗi lần thay đổi logic lớnTool: AWS Lambda Power Tuning — tự động chạy thử nhiều mức RAM và vẽ đồ thị cost vs performance.
Kết luận: Tăng RAM Lambda không phải silver bullet. Nó chỉ có lợi khi CPU/memory là bottleneck thực sự. Với các Lambda I/O-bound (DynamoDB, HTTP calls) thì 128–256MB là tối ưu nhất cả về cost lẫn performance.
Phụ lục: Giải thích thuật ngữ
AWS Services
AWS Lambda Dịch vụ serverless của AWS — chạy code theo từng sự kiện (event), không cần quản lý server. Chỉ tính tiền khi code thực sự chạy.
DynamoDB Database NoSQL của AWS, lưu trữ dạng key-value. Thường là I/O-bound vì Lambda phải gọi qua network để truy vấn.
S3 (Simple Storage Service) Dịch vụ lưu trữ file/object của AWS. Lambda thường đọc/ghi file lên S3, đây là thao tác I/O-bound.
ElastiCache Dịch vụ cache in-memory của AWS, thường dùng Redis hoặc Memcached. Lambda gọi ElastiCache qua network → I/O-bound.
RDS (Relational Database Service) Dịch vụ database quan hệ (MySQL, PostgreSQL...) của AWS. Lambda gọi RDS qua network → I/O-bound.
CloudWatch Logs Dịch vụ thu thập và lưu trữ log của AWS. Lambda tự động ghi log vào đây. Tính tiền theo dung lượng lưu trữ, kể cả khi Lambda không chạy.
EventBridge Dịch vụ event bus của AWS — nhận sự kiện từ nhiều nguồn rồi route đến Lambda hoặc các service khác. Chỉ tính tiền theo số event được publish, không tính tiền khi idle.
ECR (Elastic Container Registry) Dịch vụ lưu trữ Docker image của AWS. Nếu Lambda dùng container image thì image được lưu ở ECR — tính tiền lưu trữ liên tục dù Lambda không chạy.
VPC (Virtual Private Cloud) Mạng ảo riêng trong AWS. Lambda có thể chạy bên trong VPC để truy cập các tài nguyên nội bộ (RDS, ElastiCache...).
ENI (Elastic Network Interface) Card mạng ảo trong VPC. Lambda tạo ENI khi được invoke trong VPC, không tính tiền khi idle.
SageMaker Dịch vụ ML của AWS, phù hợp hơn Lambda khi cần chạy model AI/ML nặng, vì được tối ưu riêng cho workload đó.
Lambda Concepts
Invocation Một lần Lambda được gọi/kích hoạt. Mỗi invocation tính 1 request trong pricing.
Duration Thời gian Lambda thực sự chạy từ lúc bắt đầu đến lúc kết thúc, tính bằng milliseconds. Là yếu tố chính trong pricing (kết hợp với RAM → GB-seconds).
GB-seconds Đơn vị tính tiền của Lambda = RAM (GB) × Duration (seconds). Ví dụ: Lambda 512MB chạy 2 giây = 1 GB-second.
Free Tier Lượng tài nguyên AWS cấp miễn phí mỗi tháng. Với Lambda: 1 triệu invocations + 400,000 GB-seconds.
Cold Start Lần đầu Lambda được invoke sau khi idle — AWS phải khởi tạo môi trường mới (tải code, cấp phát RAM, kết nối network). Gây ra độ trễ thêm 200ms–1500ms tuỳ RAM. Các lần invoke sau (warm) không bị ảnh hưởng.
Warm / Execution Context Sau khi Lambda chạy xong, AWS giữ môi trường đó "ấm" một thời gian. Lần invoke tiếp theo sẽ tái sử dụng context này → không bị cold start, /tmp vẫn còn data cũ.
Provisioned Concurrency Tính năng giữ Lambda luôn "ấm" sẵn sàng, không bao giờ bị cold start. Nhưng tính tiền liên tục kể cả khi không có request — đây là ngoại lệ duy nhất của mô hình pay-per-use.
Concurrent Executions Số lượng Lambda đang chạy song song cùng lúc. Mặc định giới hạn 1,000 per account per region. Tăng RAM → mỗi instance chiếm nhiều tài nguyên hơn → có thể ảnh hưởng các Lambda khác trong account.
Ephemeral Storage (/tmp) Bộ nhớ tạm thời của Lambda, dùng để lưu file trong quá trình xử lý. Mặc định 512MB miễn phí, tối đa 10GB. Data mất khi execution context bị destroy.
Memory Leak Lỗi lập trình khiến Lambda liên tục cấp phát RAM nhưng không giải phóng → RAM cạn dần → crash. Tăng RAM chỉ trì hoãn crash, không fix được root cause.
OOM (Out of Memory) Lambda crash vì hết RAM được cấp phát. Thường xảy ra khi RAM allocate quá thấp so với nhu cầu thực tế của code.
Performance Concepts
I/O-bound Lambda dành phần lớn thời gian chờ response từ dịch vụ bên ngoài (DynamoDB, HTTP API, S3...). CPU gần như idle trong lúc chờ. Tăng RAM không giúp giảm duration vì bottleneck là network, không phải CPU.
CPU-bound Lambda dành phần lớn thời gian tự tính toán (resize ảnh, mã hoá, parse data lớn...). CPU chạy liên tục. Tăng RAM = AWS cấp thêm vCPU → Lambda xử lý nhanh hơn → duration giảm.
Memory-bound Lambda cần nhiều RAM để load data vào bộ nhớ trước khi xử lý (ví dụ: file JSON 10MB). Tăng RAM giúp đến một ngưỡng nhất định — khi data đã load hết vào RAM rồi thì tăng thêm không có tác dụng.
Bottleneck Điểm nghẽn — thứ đang làm chậm toàn bộ quá trình. Phải xác định đúng bottleneck mới tối ưu được. Ví dụ: I/O-bound → bottleneck là network, không phải CPU.
Latency Độ trễ — thời gian từ lúc gửi request đến lúc nhận response. Với Lambda thường quan tâm P50 (trung vị), P90, P99 (99% request hoàn thành trong bao lâu).
P90 / P99 Percentile — P90 = 90% request hoàn thành trong thời gian X. P99 = 99% request. Dùng để đo latency thực tế, tránh bị ảnh hưởng bởi outlier.
Throughput Số lượng request Lambda xử lý được trong một đơn vị thời gian. Khác với latency — throughput cao không có nghĩa là latency thấp.
vCPU (virtual CPU) Đơn vị CPU ảo AWS phân bổ cho Lambda. Không thể chọn trực tiếp — được tính tỉ lệ thuận với RAM (1769MB = 1 vCPU đầy đủ).
Break-even Điểm hoà vốn khi tăng RAM — mức duration giảm tối thiểu cần đạt được để tổng GB-seconds không tăng. Tăng RAM 2x → cần duration giảm >50% mới có lợi.
Sweet spot Mức RAM tối ưu — cân bằng giữa cost và performance tốt nhất, không quá thấp (chậm) cũng không quá cao (lãng phí).
Tools & Methods
Lambda Power Tuning Tool mã nguồn mở của AWS (github.com/alexcasalboni/aws-lambda-power-tuning) — tự động invoke Lambda với nhiều mức RAM khác nhau, đo duration và cost, vẽ đồ thị để tìm sweet spot.
Benchmark Quá trình đo hiệu suất thực tế của Lambda dưới các điều kiện cụ thể. Phải benchmark trước khi quyết định tăng RAM — không nên tăng theo cảm tính.
Pay-per-use Mô hình tính tiền theo mức sử dụng thực tế — chỉ trả tiền khi Lambda chạy, không trả khi idle. Đây là đặc điểm cốt lõi của serverless.
Serverless Mô hình triển khai không cần quản lý server — AWS tự lo infrastructure, scaling, patching. Developer chỉ cần viết code và cấu hình. Lambda là serverless compute của AWS.
Throttle AWS giới hạn (chặn) request khi Lambda vượt quá quota (concurrent executions, memory...). Request bị throttle sẽ nhận lỗi hoặc được retry tuỳ cấu hình.
Silver bullet Thuật ngữ ẩn dụ — giải pháp "thần kỳ" giải quyết được mọi vấn đề. Trong docs này dùng để nhấn mạnh: tăng RAM Lambda không phải giải pháp tối ưu cho mọi trường hợp.