---
id: serverless-functions
title: "Lambda và Azure Functions"
shortTitle: "Lambda, Functions"
track: serverless
trackTitle: "Serverless"
order: 1
level: core
status: published
estimatedMinutes: 40
prerequisites:
  - cloud-providers
next: serverless-edge
reviewedAgainst: 2026-10-12
sources:
  - title: "Lambda — timeout"
    url: https://docs.aws.amazon.com/lambda/latest/dg/configuration-timeout.html
  - title: "Azure Functions — scale and hosting"
    url: https://learn.microsoft.com/en-us/azure/azure-functions/functions-scale
---

# Lambda và Azure Functions

Không có lab tạo function trên cloud, vì mỗi lần invoke có thể phát sinh phí và cần account. Bài này nói mô hình chạy, giới hạn thời gian, và chỗ người ta cấu hình sai.

Cloud Run functions và Netlify nằm ở các bài sau. Cùng mô hình: một hàm chạy theo event, platform lo máy.

## Để làm gì

Bạn phân biệt được việc function chịu được, và việc phải đưa ra VM hoặc container. Đọc timeout trước khi đưa job dài vào Lambda hoặc Azure Functions.

## Gồm những gì

- Trigger, handler, stateless.
- Timeout của Lambda và của Azure Functions theo plan.
- Cold start.
- Quyền: execution role và managed identity.

Cloudflare Workers và Vercel ở bài sau. Cả hai chạy ở edge, và runtime có trần chặt hơn.

## Dùng khi nào

HTTP ngắn, xử lý một message trong queue, một file vừa upload, một lịch cron. Xong việc thì process biến mất.

Không hợp: WebSocket giữ lâu, server giữ file local giữa hai request, job chạy vài giờ. Lambda thường trần 15 phút. Job dài hơn thì container hoặc VM.

## Kiến thức cốt lõi

Bạn đưa một handler. Platform gọi handler khi có event. Event là HTTP request, message queue, lịch, hoặc object mới trong storage. Không có request thì không có process để SSH vào. Log nằm ở CloudWatch hoặc Application Insights, không nằm ở `/var/log` trên một máy bạn giữ.

Handler phải stateless. File ghi vào `/tmp` có thể còn trong cùng môi trường chạy ấm, và mất khi platform tạo môi trường mới. Đừng giữ session trên disk local.

Cold start: request đầu sau lúc rảnh phải tạo môi trường và nạp runtime. Request đó chậm hơn. Java và .NET thường nặng hơn Node hoặc Python. Không thiết kế SLA mili-giây trên function vừa ngủ.

Timeout, đã đối chiếu docs ngày viết bài:

| Nền | Mặc định | Trần hay gặp |
| --- | --- | --- |
| Lambda | 3 giây | 900 giây (15 phút) |
| Lambda Managed Instances, gọi async hoặc qua event source mapping | cùng cấu hình function | tới 5400 giây (90 phút). Gọi đồng bộ vẫn trần 15 phút |
| Azure Functions Consumption | 5 phút | 10 phút |
| Azure Functions HTTP trigger |  | Tối đa khoảng 230 giây để trả lời, do load balancer, dù plan cho chạy lâu hơn |

Đưa timeout của Lambda từ 3 giây lên mức job thật sự cần. Để 3 giây rồi gọi API nội bộ chậm là function bị giết giữa chừng, client nhận 502, log có `Task timed out`.

Quyền: Lambda dùng execution role. Azure Functions dùng managed identity. Gắn đúng quyền tới queue hoặc storage đó, không gắn `*` trên cả account.

## Lệnh và code mẫu

Không deploy. Một handler Node, đủ để thấy hình dạng. AWS gọi export `handler`. Azure model v4 dùng `app.http`, khác chữ nhưng cùng việc: nhận request, trả status.

Lambda:

```javascript
export const handler = async (event) => {
  const name = event.queryStringParameters?.name ?? "world";
  return {
    statusCode: 200,
    body: JSON.stringify({ ok: true, name }),
  };
};
```

Local, bạn gọi được bằng một test event JSON. Không cần `listen` port.

## Thực hành

1. Viết ra giấy một job bạn đang chạy bằng cron trên VM. Ước lượng nó chạy bao lâu.
2. Nếu dưới 10 phút và không cần disk local: ghi "Lambda hoặc Azure Functions được". Nếu cần socket mở mãi: ghi "không".
3. Với job được, chọn nơi để dữ liệu giữa hai lần chạy. Phải là database, queue, hoặc object storage, không phải `/tmp`.
4. Đọc một function có sẵn trong tài liệu công ty, nếu có. Tìm timeout đang cấu hình. Thiếu thì nó đang ăn mặc định 3 giây bên Lambda hoặc 5 phút bên Consumption.

## Kết quả mong đợi

- Một job được xếp đúng vào function hoặc không.
- Chỗ lưu trạng thái không phải disk của lần chạy.
- Bạn đọc được bảng timeout mà không nhớ nhầm 15 phút là mặc định.

## Checklist

- [ ] Function không giữ state trên disk local.
- [ ] Timeout đặt theo job, không để mặc định khi job dài hơn 3 giây.
- [ ] HTTP trên Azure Functions không giả định chạy quá 230 giây.
- [ ] Quyền là role hoặc managed identity, hẹp theo resource.
- [ ] Job vài giờ không nhét vào Lambda trần 15 phút.

## Lỗi thường gặp

**Timeout 3 giây.** Default của Lambda. API nội bộ hơi chậm là hết giờ. Tăng timeout, và đặt client HTTP timeout ngắn hơn timeout của function để còn kịp trả lỗi.

**Ghi session vào `/tmp`.** Lần sau có thể là môi trường khác, session mất. Session để database hoặc cookie ký.

**HTTP function Azure chạy báo cáo 9 phút.** Load balancer cắt khoảng 230 giây. Trả 202 rồi xử lý tiếp bằng queue.

## Nguồn

1. [Configure Lambda function timeout](https://docs.aws.amazon.com/lambda/latest/dg/configuration-timeout.html) — AWS, mặc định 3 giây, trần 900 giây, ngoại lệ Managed Instances.
2. [Azure Functions hosting options](https://learn.microsoft.com/en-us/azure/azure-functions/functions-scale) — Microsoft Learn, timeout theo plan và giới hạn HTTP.

## Tiếp theo

[Cloudflare Workers và Vercel](./02-edge.md)