Hồi mới vào nghề, mình từng deploy một con server nhỏ để chạy một cái API gửi email thông báo — chạy 24/7, hết 15 USD/tháng, nhưng thực ra 23 giờ mỗi ngày nó chỉ ngồi không. Rồi một hôm traffic tăng đột biến, server đơ, khách complain, mình phải mất cả buổi sáng ngồi fix. Đó là lúc mình bắt đầu tìm hiểu về AWS Lambda — và nó thay đổi hoàn toàn cách mình nghĩ về backend.

AWS Lambda là gì? Giải thích theo kiểu "không biết gì về server"

Hãy tưởng tượng bạn cần một người giao hàng. Cách cũ: bạn thuê một nhân viên full-time, trả lương cả tháng dù anh ta chỉ giao 10 đơn hàng. Cách Lambda: bạn gọi Grab mỗi khi có đơn — chỉ trả tiền khi có việc, không việc không mất đồng nào.

AWS Lambda là dịch vụ Function-as-a-Service (FaaS) của Amazon. Bạn viết một function (bằng Python, Node.js, Java, Go, Ruby...), upload lên Lambda, rồi cấu hình "trigger" — tức là điều kiện để hàm đó chạy. Khi trigger kích hoạt, AWS tự động: cấp phát tài nguyên, chạy code của bạn, trả kết quả, rồi giải phóng tài nguyên. Bạn không cần quan tâm server nào đang chạy, bao nhiêu RAM, OS gì.

Số liệu đáng chú ý: Lambda miễn phí 1 triệu lần gọi đầu tiên mỗi tháng và 400.000 GB-giây compute. Với dự án startup hay side project, bạn có thể chạy miễn phí mãi mãi nếu traffic không quá lớn. Đây là lý do Serverless đang bùng nổ trong 2024-2026 — không chỉ tiết kiệm chi phí, mà còn giúp team nhỏ làm được việc của team lớn.

Khi nào nên dùng AWS Lambda? (Use Case thực tế)

Lambda không phải "silver bullet" — nó có điểm mạnh rõ ràng và điểm yếu không kém. Đây là các use case Lambda tỏa sáng nhất:

API backend không thường xuyên: Một SaaS B2B có 500 khách hàng nhưng mỗi người chỉ dùng vài lần/ngày. Thay vì chạy EC2 24/7, dùng Lambda + API Gateway — chi phí giảm 80-90%. Thực tế: startup chiendung.com đang dùng Lambda cho các endpoint ít traffic, tiết kiệm được ~30 USD/tháng so với lúc dùng EC2 t3.micro.
Xử lý sự kiện bất đồng bộ: Khi user upload ảnh lên S3, trigger Lambda để resize ảnh, tạo thumbnail, ghi metadata vào DynamoDB — tất cả tự động, không cần polling hay cron job thủ công. Pipeline này xử lý được hàng nghìn ảnh/phút mà không cần scale thủ công.
Webhook và tích hợp bên thứ ba: Nhận webhook từ Stripe, Slack, GitHub → xử lý logic → gửi thông báo. Lambda phù hợp hoàn hảo vì các sự kiện này không đều đặn, có thể tăng đột biến rồi lại im lặng hoàn toàn. Không cần server "chờ" suốt ngày.

Viết Lambda Function đầu tiên: Từng bước thực chiến

AWS Lambda function lifecycle và event-driven architecture

Mình sẽ hướng dẫn tạo một Lambda function đơn giản bằng Python — nhận request từ API Gateway, xử lý, trả về JSON. Đây là nền tảng của 90% use case Lambda thực tế.

Bước 1: Tạo function trên AWS Console

Vào AWS Console → Lambda → Create function. Chọn Author from scratch, đặt tên, chọn runtime Python 3.12. Với IAM role, chọn Create a new role with basic Lambda permissions — đủ để bắt đầu.

Bước 2: Viết code handler

Mỗi Lambda function cần có một handler — điểm vào khi function được gọi. Cấu trúc chuẩn:

import json

def lambda_handler(event, context):
    # event: dữ liệu đầu vào (từ API Gateway, S3, v.v.)
    # context: thông tin runtime (thời gian còn lại, memory, v.v.)
    
    name = event.get('queryStringParameters', {}).get('name', 'World')
    
    return {
        'statusCode': 200,
        'headers': {'Content-Type': 'application/json'},
        'body': json.dumps({'message': f'Hello, {name}!'})
    }

Bước 3: Thêm trigger API Gateway

Trong trang Lambda function, click Add trigger → API Gateway → Create new API → HTTP API. AWS sẽ tạo endpoint public cho bạn ngay lập tức. Copy URL, test bằng curl:

curl "https://abc123.execute-api.ap-southeast-1.amazonaws.com/default/my-function?name=Chien"
# {"message": "Hello, Chien!"}

Bước 4: Hiểu Cold Start và cách xử lý

Đây là điều mà docs AWS không nói rõ nhưng cực kỳ quan trọng. Khi Lambda chưa được gọi trong một thời gian, AWS giải phóng container — lần gọi tiếp theo phải khởi động lại từ đầu (cold start), mất thêm 200-2000ms. Với Python, cold start thường 200-500ms. Với Java, có thể lên 2-5 giây — đau lắm nếu user đang chờ.

Cách giảm cold start: dùng Provisioned Concurrency (Lambda luôn có X instance sẵn sàng, nhưng tốn thêm tiền), hoặc dùng scheduled warm-up (EventBridge ping Lambda mỗi 5 phút).

Mẹo thực chiến: Đặt biến toàn cục (database connection, config) NGOÀI hàm handler. Lambda tái sử dụng container giữa các invocation — biến toàn cục chỉ khởi tạo 1 lần, tiết kiệm đáng kể thời gian cho mỗi request sau cold start đầu tiên.

Kinh nghiệm thực chiến: Những "ổ gà" mình đã ngã

Sau khi dùng Lambda cho nhiều dự án thực tế, đây là những lỗi phổ biến và cách fix:

1. Timeout quá thấp hoặc quá cao: Default timeout Lambda là 3 giây — đủ cho API đơn giản nhưng sẽ fail nếu bạn gọi database chậm hoặc xử lý file lớn. Đừng set timeout = 15 phút (max) cho mọi function "cho chắc" — nếu có bug vòng lặp vô tận, bạn sẽ bị tính tiền cho 15 phút idle. Nguyên tắc: timeout = thời gian xử lý bình thường × 3, tối đa 30 giây cho API.

2. Quên giới hạn concurrency: Lambda mặc định cho phép 1000 concurrent executions trong một region (tất cả functions cộng lại). Nếu traffic tăng đột biến, một function "ngốn" hết quota → các function khác bị throttle. Giải pháp: set Reserved Concurrency cho từng function quan trọng để cô lập tài nguyên.

3. Nhầm lẫn giữa stateless và stateful: Lambda là stateless — mỗi invocation là một instance riêng biệt, không share memory. Mình từng có bug vì store session trong biến local rồi tự hỏi sao session mất sau mỗi request. State phải lưu ở ngoài: DynamoDB, ElastiCache, S3.

FAQ — Những câu hỏi gai góc nhất về Lambda

Q: Lambda có thể thay thế hoàn toàn EC2 không?
A: Không. Lambda không phù hợp cho: ứng dụng cần chạy liên tục (WebSocket server, long polling), tác vụ xử lý lâu hơn 15 phút, ứng dụng cần file system lớn (Lambda chỉ có 512MB đến 10GB /tmp), hoặc workload cần GPU. Với những trường hợp đó, EC2, ECS, hay EKS phù hợp hơn.

Q: Chi phí Lambda so với EC2 như thế nào trong thực tế?
A: Phụ thuộc traffic pattern. Lambda rẻ hơn khi traffic thấp hoặc rất không đều (burst traffic). Khi traffic cao và đều đặn (ví dụ API phục vụ 10 triệu request/ngày liên tục), EC2 thường rẻ hơn vì bạn không phải trả overhead per-invocation. Điểm break-even thường ở mức 500K-1M requests/ngày tùy memory configuration.

Q: Serverless có thực sự "không cần DevOps" không?
A: Không hoàn toàn. Bạn vẫn cần hiểu IAM permissions (sai là security hole), VPC configuration nếu cần truy cập RDS private, monitoring với CloudWatch, và cost optimization. Serverless giảm đáng kể gánh nặng infrastructure nhưng không loại bỏ hoàn toàn — nó chuyển complexity từ "manage server" sang "manage function ecosystem".

Lambda không phải tương lai — nó đã là hiện tại

Serverless không phải buzzword nữa. Năm 2026, phần lớn startup mới ra đời không bao giờ chạm vào EC2 — họ xây trên Lambda, DynamoDB, S3 từ ngày đầu và scale lên hàng triệu user mà không cần một DevOps engineer thuê thêm. Đó là sức mạnh thực sự của mô hình này.

Bắt đầu nhỏ: chuyển một endpoint ít dùng sang Lambda, đo chi phí và performance sau một tháng. Khi đã quen với tư duy event-driven và stateless, bạn sẽ thấy nhiều bài toán kiến trúc nhìn theo cách hoàn toàn khác. Bài tiếp theo mình sẽ đi sâu vào cách kết hợp Lambda với API Gateway để xây dựng một REST API production-ready hoàn chỉnh — đừng bỏ lỡ.