Hóa Đơn Thật: Serverless Tốn Bao Nhiêu, và Tiết Kiệm Ở Đâu

Mọi kiến trúc serverless cuối cùng phải trả lời một câu: tốn bao nhiêu? Câu trả lời của serverless khác với server truyền thống ở chỗ chi phí bám theo lượng dùng chứ không theo thời gian bật máy. Bài này không lý thuyết về giá mà mở thẳng hóa đơn thật của sản phẩm đã dựng suốt series, rồi giải thích mô hình giá và những chỗ thiết kế đã tiết kiệm.

Mục tiêu

Xem chi phí thật của stack qua Cost Explorer, hiểu mô hình giá từng dịch vụ chính, và nhận ra các lựa chọn thiết kế trong series đã cắt tiền ở đâu. Bản thân việc xem chi phí không tốn gì.

Hóa đơn thật: gần như bằng không

Hỏi Cost Explorer chi phí theo dịch vụ cho mấy ngày dựng và test cả series, kết quả cho từng dịch vụ serverless là số không hoặc nhỏ tới mức không đọc nổi:

$ aws ce get-cost-and-usage --time-period Start=2026-05-24,End=2026-05-27 \
    --granularity DAILY --metrics UnblendedCost --group-by Type=DIMENSION,Key=SERVICE
...
Amazon Simple Queue Service          0
Amazon Simple Notification Service   0
AmazonCloudWatch                     0
Amazon Elastic Compute Cloud         0
Amazon Simple Storage Service        0.0000473711
...

Các dịch vụ hiện trong danh sách (SQS, SNS, CloudWatch...) đều là 0. Còn Lambda, DynamoDB, API Gateway, EventBridge, Step Functions không xuất hiện trong kết quả: Cost Explorer chỉ liệt kê dịch vụ có phát sinh chi phí, nên việc chúng vắng mặt nghĩa là khoản tính tiền bằng không (nằm trong free tier). Khoản nhìn thấy được duy nhất là vài phần nghìn cent cho S3, nơi SAM cất gói code khi deploy. Toàn bộ việc dựng một hệ thống đầy đủ (API, database, auth, event bus, hàng đợi, realtime, state machine, observability) và test nó nhiều lần tốn một khoản không đáng để nhắc.

Lý do nằm ở hai điều. Thứ nhất, serverless không tính tiền lúc nghỉ: không request nào thì phần compute bằng không, khác hẳn một EC2 hay RDS chạy 24/7 tính tiền cả lúc rảnh. Thứ hai, lượng dùng khi test nằm gọn trong free tier. Đây là điều khiến serverless hợp với cả việc học lẫn sản phẩm tải thất thường: chi phí co theo lượng dùng, và khi lượng dùng nhỏ thì hóa đơn cũng nhỏ theo.

Mô hình giá từng dịch vụ

Hiểu vì sao gần như miễn phí cần biết từng dịch vụ tính tiền ra sao. Các con số dưới đây là để tham khảo mô hình, giá cụ thể đổi theo thời điểm và region nên luôn kiểm trang pricing chính thức trước khi tính nghiêm túc.

• Lambda tính theo số lần gọi (cỡ $0,20 cho mỗi triệu request) cộng thời gian chạy nhân bộ nhớ (GB-giây). Free tier always-free khá rộng: một triệu request và 400.000 GB-giây mỗi tháng. Một URL shortener thường không chạm tới đó.
• API Gateway HTTP API tính theo request, và đây là chỗ lựa chọn ở bài 03 đáng giá: HTTP API rẻ hơn REST API nhiều lần cho mỗi triệu request. Chọn HTTP API ngay từ đầu là một quyết định chi phí, không chỉ tính năng.
• DynamoDB on-demand tính theo từng đơn vị đọc/ghi và dung lượng lưu, không tính tiền công suất cấp sẵn. Lúc không ai dùng, chỉ còn phí lưu cho vài item, gần như không. Bảng rỗng để qua đêm không sinh hóa đơn đáng kể.
• EventBridge tính theo triệu sự kiện tùy biến; SQS theo triệu request (một triệu đầu mỗi tháng miễn phí); Step Functions Standard theo nghìn lần chuyển state (4.000 lần mỗi tháng miễn phí).
• Cognito miễn phí tới hàng chục nghìn người dùng hoạt động mỗi tháng. CloudWatch tính theo dung lượng log nạp vào, theo alarm, và theo dashboard; X-Ray miễn phí một lượng trace nhất định mỗi tháng rồi mới tính.
• WebSocket API tính theo triệu message và theo phút-kết-nối, cũng có free tier năm đầu.

Điểm chung: mọi thứ tính theo lượng dùng, và phần lớn có một ngưỡng miễn phí. Một sản phẩm mới hoặc tải nhỏ thường ở dưới ngưỡng đó, nên hóa đơn thật bằng không hoặc vài xu.

Những chỗ thiết kế đã tiết kiệm

Nhiều quyết định rải suốt series không chỉ là kỹ thuật mà còn là chi phí, dù lúc đó ta nói tới chúng vì lý do khác.

Chọn HTTP API thay REST API (bài 03) cắt phí mỗi request xuống còn một phần. Chọn arm64 (bài 02) cho compute rẻ hơn x86 ở cùng thời lượng. DynamoDB on-demand (bài 04) bỏ chi phí công suất cấp sẵn, hợp với tải thất thường và để hóa đơn lúc rảnh về gần không. Đẩy metric bằng EMF qua log (bài 13) thay vì gọi API PutMetricData riêng nên không tốn thêm lời gọi API. Single-table (bài 04) giữ số tài nguyên tối thiểu. GSI sparse (bài 05) chỉ lập chỉ mục những item cần, giảm dung lượng và lượt ghi index. Và TTL tự xóa marker (bài 10) giữ bảng không phình theo thời gian.

Không cái nào trong số đó được làm chỉ để tiết kiệm, nhưng cộng lại chúng giải thích vì sao một hệ thống đầy đủ tính năng vẫn gần như không tốn gì khi tải nhỏ.

Cẩn thận với cái tính tiền cả lúc nghỉ

Mặt trái cần nhớ: vài thứ trong và quanh kiến trúc serverless không theo mô hình trả-theo-dùng. Dashboard CloudWatch tính phí cố định theo tháng (có một ít miễn phí). Một NAT Gateway, nếu đặt Lambda trong VPC private có ra Internet, tính tiền theo giờ bất kể lưu lượng. Provisioned concurrency, nếu bật, giữ môi trường ấm liên tục nên tính tiền cả lúc không ai gọi. Sản phẩm này tránh được tất cả: không VPC, không NAT, không provisioned concurrency, và chỉ một dashboard. Khi thêm những thành phần đó, hóa đơn đổi tính chất, từ "theo dùng" sang "có phần cố định", và đó là lúc cần theo dõi sát hơn.

Tổng kết

Hóa đơn thật của cả series chỉ vài phần nghìn cent, vì serverless không tính tiền lúc nghỉ và lượng dùng nằm trong free tier. Mỗi dịch vụ tính theo lượng dùng với một ngưỡng miễn phí, và nhiều lựa chọn thiết kế rải suốt series (HTTP API, arm64, on-demand, EMF, single-table, sparse index, TTL) cộng lại giữ chi phí ở mức thấp nhất. Cái cần canh là số ít thành phần tính phí cố định hoặc theo giờ, thứ mà sản phẩm này cố tình không dùng.

Chi phí thấp một phần vì ta chưa dội tải thật vào nó. Bài sau làm đúng điều đó: load test bằng k6, đẩy lượng request lớn vào hệ thống, rồi đọc lại metric và trace dưới tải để xem nó co giãn ra sao và nút thắt nằm ở đâu, đặc biệt với giới hạn concurrency 10 đã gặp nhiều lần.