Mở đầu — vì sao bài này quan trọng
Có một câu nói khá quen trong giới DevOps: "Cloud thì rẻ, cho đến khi bạn nhận hóa đơn." Nghe qua thì có vẻ đùa, nhưng đằng sau đó là một sự thật mà rất nhiều đội kỹ thuật tại Việt Nam đã học được theo cách đau đớn. Bạn khởi tạo vài con máy ảo, bật thêm một database, gắn một cái load balancer, rồi vài tuần sau kế toán gọi điện hỏi "sao tháng này AWS thu gần 300 triệu, tháng trước có 80 triệu thôi?".
Cloud khác hoàn toàn với hạ tầng vật lý truyền thống. Ngày xưa bạn mua một con server, trả tiền một lần, dùng ba năm. Chi phí là cố định và có thể dự đoán. Còn trên cloud, mọi thứ tính theo giờ, theo GB, theo request. Chi phí trở thành một biến số động, thay đổi liên tục theo cách bạn thiết kế và vận hành hệ thống. Điều này vừa là lợi thế (chỉ trả cho thứ mình dùng) vừa là cạm bẫy (dễ dùng quá tay mà không hay biết).
Trong ngành DevOps hiện đại, quản lý chi phí cloud — hay còn gọi là FinOps (Financial Operations) — đã trở thành một kỹ năng bắt buộc, không còn là việc riêng của phòng tài chính. Một kỹ sư hạ tầng giỏi không chỉ biết dựng hệ thống chạy được, mà còn phải biết hệ thống đó tốn bao nhiêu tiền, tiền chảy vào đâu, và làm sao để tối ưu mà không ảnh hưởng tới chất lượng dịch vụ. Bài học này sẽ trang bị cho bạn ba trụ cột nền tảng của việc kiểm soát chi phí: Tagging (gắn nhãn để biết tiền đi đâu), Budgets (đặt ngân sách), và Alerts (cảnh báo khi vượt ngưỡng).
Khái niệm cốt lõi
Các yếu tố sinh chi phí chính (cost drivers)
Trước khi kiểm soát chi phí, bạn phải hiểu tiền cloud chảy vào đâu. Có bốn nhóm chi phí lớn mà hầu như dịch vụ nào cũng gặp:
Compute — đây thường là khoản lớn nhất. Bạn trả tiền cho thời gian máy ảo (VM) chạy, thời gian container hoạt động, hay số lần gọi hàm serverless. Một con VM loại m5.xlarge trên AWS bật 24/7 cả tháng có thể tốn 130–150 USD, dù bạn chỉ thực sự dùng nó 8 tiếng mỗi ngày. Phần lớn lãng phí đến từ việc để máy chạy khi không cần.
Storage — tính theo GB-tháng. Nghĩa là bạn lưu 1000 GB trong một tháng thì trả tiền cho 1000 GB-tháng đó. Object storage như S3 khá rẻ (khoảng 0.023 USD/GB/tháng cho tier tiêu chuẩn), nhưng snapshot, backup và các ổ đĩa "mồ côi" (không còn gắn với máy nào nhưng vẫn tồn tại) tích tụ dần thành khoản không nhỏ.
Data transfer — đây là cái bẫy kinh điển. Dữ liệu đi VÀO cloud (ingress) thường miễn phí, nhưng dữ liệu đi RA (egress) — ra Internet, hay sang region khác — thì tính tiền, và không hề rẻ. AWS tính khoảng 0.09 USD/GB cho egress ra Internet ở vùng Singapore. Một ứng dụng phục vụ nhiều video hay file lớn cho người dùng có thể "cháy" tiền ở khoản này mà bạn không ngờ tới.
Managed services — các dịch vụ được quản lý như database (RDS), cache, message queue, load balancer… đều có phí riêng, thường cao hơn tự dựng nhưng đổi lại đỡ công vận hành. Cần cân nhắc bài toán chi phí kỹ sư so với chi phí dịch vụ.
Tagging — chìa khóa để biết tiền đi đâu
Tag (nhãn) là các cặp khóa–giá trị (key–value) mà bạn gắn vào từng tài nguyên cloud. Ví dụ: Environment=production, Team=payment, Project=mobile-app, Owner=nam.tran. Bản thân tag không tốn tiền, nhưng nó là công cụ mạnh nhất để phân bổ và phân tích chi phí.
Hãy tưởng tượng công ty bạn có 200 tài nguyên trên AWS. Cuối tháng hóa đơn về 500 triệu. Nếu không có tag, bạn chỉ biết tổng số đó, không cách nào biết đội nào tiêu bao nhiêu, dự án nào ngốn tiền nhất. Nhưng nếu mọi tài nguyên đều được gắn tag Team và Environment, bạn có thể lọc và thấy ngay: "À, đội data ngốn 60% vì cụm xử lý dữ liệu, môi trường staging tốn 80 triệu dù chẳng ai dùng cuối tuần."
Nguyên tắc vàng: thiết kế chiến lược tag TRƯỚC khi hệ thống phình to. Gắn tag cho 500 tài nguyên đã tồn tại là ác mộng; gắn từ đầu qua Infrastructure as Code thì gần như miễn phí về công sức.
Budgets — đặt giới hạn ngân sách
Budget là ngưỡng chi tiêu bạn khai báo trước. AWS Budgets, GCP Budgets và Azure Cost Management đều cho phép bạn nói: "Tôi dự tính đội payment tháng này tiêu tối đa 100 triệu." Hệ thống sẽ theo dõi chi tiêu thực tế so với con số đó.
Budget có thể đặt theo nhiều chiều: theo tổng tài khoản, theo tag cụ thể, theo dịch vụ (chỉ tính riêng compute), hay theo dự báo (forecast — cloud dự đoán bạn sẽ tiêu bao nhiêu vào cuối tháng dựa trên đà hiện tại). Budget theo forecast đặc biệt hữu ích vì nó cảnh báo bạn từ giữa tháng, khi còn kịp hành động.
Alerts — cảnh báo khi vượt ngưỡng
Alert là cơ chế thông báo tự động khi chi tiêu chạm hoặc dự kiến vượt các mốc bạn đặt (ví dụ 50%, 80%, 100% của budget). Alert có thể gửi qua email, Slack, Telegram, hoặc kích hoạt một hành động tự động. Đây là "chuông báo cháy" — không có nó, bạn chỉ phát hiện vấn đề khi hóa đơn đã về, tức là quá muộn.
Tình huống thực tế
Tình huống 1: Startup thương mại điện tử và cụm staging bị bỏ quên
Một startup e-commerce ở TP.HCM, tạm gọi là ShopFast, có đội kỹ thuật 12 người, dùng AWS ở vùng Singapore. Trong giai đoạn phát triển nhanh, các bạn dev tự khởi tạo môi trường test bằng tay qua console. Mỗi lần cần thử tính năng mới, một bạn dựng vài con EC2, một RDS, gắn load balancer. Xong việc thì… quên tắt.
Sau ba tháng, hóa đơn từ 90 triệu vọt lên 240 triệu. Khi CTO yêu cầu rà soát, họ phát hiện có 7 cụm staging đang chạy 24/7, trong đó 4 cụm không ai còn nhớ là của tính năng nào. Vấn đề cốt lõi: không có tag, không có budget, không có alert. Tiền cứ âm thầm chảy.
Cách họ xử lý: gắn tag Owner và TTL (time-to-live) cho mọi tài nguyên staging, viết một script tự động tắt máy staging lúc 8 giờ tối và cuối tuần, đặt budget 120 triệu với alert ở mốc 70% và 90% gửi vào kênh Slack của đội. Kết quả: hóa đơn giảm còn 110 triệu/tháng, tiết kiệm hơn 50%.
Bài học: phần lớn lãng phí cloud không đến từ hệ thống production được thiết kế kỹ, mà từ những tài nguyên "tạm" bị bỏ quên. Tag + tự động tắt máy là đòn bẩy tiết kiệm lớn nhất và dễ làm nhất.
Tình huống 2: Công ty fintech và cú sốc data egress
Một công ty fintech ở Hà Nội cung cấp dịch vụ e-KYC (xác thực danh tính điện tử), xử lý ảnh chụp CCCD và video khuôn mặt của người dùng. Họ lưu ảnh gốc trên S3 và có một dịch vụ AI ở region khác đọc các ảnh này để xử lý. Mọi thứ chạy tốt cho tới khi lượng người dùng tăng gấp 5 lần trong một chiến dịch.
Hóa đơn tháng đó có một dòng bất thường: chi phí data transfer chiếm gần 40% tổng bill, cao hơn cả compute. Nguyên nhân: dịch vụ AI đọc ảnh liên tục qua region khác, mỗi lần đọc là một lần egress giữa các region — mà egress cross-region bị tính tiền. Với hàng triệu ảnh mỗi ngày, con số phình lên chóng mặt.
Cách khắc phục: họ chuyển dịch vụ AI về cùng region với S3 để egress nội region gần như miễn phí, thêm một lớp cache cho các ảnh hay được truy cập lại, và dùng Cost Explorer lọc theo tag service=ekyc để giám sát riêng khoản data transfer. Chi phí transfer giảm hơn 70%.
Bài học: data egress là chi phí ẩn dễ bị bỏ qua nhất vì nó không hiện rõ khi bạn thiết kế kiến trúc. Luôn đặt tài nguyên giao tiếp nhiều với nhau gần nhau về mặt địa lý, và giám sát dòng chi phí transfer riêng biệt.
Tình huống 3: Đội nội bộ và bài toán "ai chịu trách nhiệm"
Một doanh nghiệp vừa ở Đà Nẵng chuyển từ server vật lý lên GCP. Ban đầu mọi tài nguyên nằm chung một project, hóa đơn về một cục. Ba đội (web, mobile, data) dùng chung, nhưng không ai thấy mình phải chịu trách nhiệm về chi phí — kiểu "của chung không ai khóc".
Ban giám đốc quyết định áp dụng mô hình showback: gắn nhãn (label trên GCP) cho mọi tài nguyên theo đội, rồi mỗi tháng gửi báo cáo chi phí riêng cho từng trưởng nhóm. Không phạt, không trừ lương, chỉ đơn giản là cho mọi người NHÌN THẤY con số của đội mình.
Chỉ riêng việc minh bạch hóa này đã khiến tổng chi phí giảm 22% trong hai tháng. Đội data tự nguyện chuyển các job phân tích sang chạy ban đêm với máy giá rẻ hơn; đội web dọn dẹp các snapshot cũ tích tụ hàng năm trời.
Bài học: con người tiết kiệm khi họ NHÌN THẤY chi phí của mình. Tag không chỉ là công cụ kỹ thuật, nó là công cụ tạo trách nhiệm. Showback (cho xem) và chargeback (tính tiền thật vào ngân sách đội) là những mô hình FinOps mạnh mẽ.
Hướng dẫn từng bước
Dưới đây là quy trình thiết lập kiểm soát chi phí cơ bản mà bạn có thể áp dụng cho bất kỳ đội nào.
Bước 1 — Thiết kế chiến lược tag. Ngồi lại với đội và thống nhất một bộ tag bắt buộc. Tối thiểu nên có: Environment (production/staging/dev), Team (đội sở hữu), Project (dự án), Owner (người chịu trách nhiệm). Viết bộ tag này thành tài liệu chuẩn để mọi người tuân theo.
Bước 2 — Ép buộc gắn tag qua Infrastructure as Code. Đừng trông cậy vào việc gắn tag bằng tay. Trong Terraform, dùng khối default_tags (với AWS provider) để mọi tài nguyên tự động nhận tag. Với AWS, có thể bật Tag Policies ở cấp tổ chức để từ chối tạo tài nguyên thiếu tag bắt buộc.
Bước 3 — Kích hoạt Cost Allocation Tags. Trên AWS, tag mặc định chưa xuất hiện trong báo cáo chi phí cho tới khi bạn vào Billing console và "activate" chúng làm cost allocation tag. Đây là bước rất hay bị quên. GCP và Azure thì label/tag tự động khả dụng trong báo cáo.
Bước 4 — Đặt budget theo nhiều chiều. Tạo một budget tổng cho cả tài khoản, và các budget con theo tag Team hoặc Environment. Nên dùng cả budget theo chi phí thực tế lẫn theo forecast để được cảnh báo sớm.
Bước 5 — Cấu hình alert đa mức. Đặt cảnh báo ở các mốc 50%, 80%, 100% và 120% (forecast) của mỗi budget. Định tuyến alert vào nơi đội thực sự đọc — Slack, Telegram, chứ đừng chỉ gửi email dễ bị trôi.
Bước 6 — Lập nhịp rà soát định kỳ. Mỗi tuần hoặc mỗi hai tuần, mở Cost Explorer (AWS), Cost Management (Azure) hay Cost Reports (GCP) ra xem xu hướng. Tìm các dòng tăng bất thường, các tài nguyên "mồ côi", các máy chạy 24/7 không cần thiết.
Bước 7 — Hành động tự động hóa. Viết script hoặc dùng công cụ như AWS Instance Scheduler để tự tắt tài nguyên non-production ngoài giờ làm việc. Dọn snapshot cũ, xóa ổ đĩa không gắn với máy nào, gỡ IP tĩnh không dùng (AWS tính tiền Elastic IP không gắn máy).
Lỗi thường gặp & mẹo
Lỗi 1 — Gắn tag không nhất quán. Đội này viết team=payment, đội kia viết Team=Payment, đội khác TEAM=pay. Cloud coi đây là ba tag khác nhau, báo cáo vỡ vụn. Mẹo: chuẩn hóa chữ hoa/thường và từ vựng ngay từ đầu, ép qua IaC.
Lỗi 2 — Chỉ đặt alert ở mốc 100%. Khi alert 100% kêu thì tiền đã tiêu hết ngân sách rồi. Luôn đặt cảnh báo sớm ở 50–80% và dùng cảnh báo theo forecast để có thời gian phản ứng.
Lỗi 3 — Quên egress và các chi phí ẩn. Nhiều người chỉ nhìn compute mà bỏ qua data transfer, phí NAT Gateway, phí API request của S3, phí log. Mẹo: mỗi tháng dành 15 phút phân tích chi phí theo từng loại dịch vụ, không chỉ nhìn tổng.
Lỗi 4 — Alert gửi vào hư không. Cấu hình alert nhưng gửi vào email của một tài khoản không ai đọc. Mẹo: gửi vào kênh chat đội đang dùng và cử người rõ ràng chịu trách nhiệm phản ứng.
Lỗi 5 — Không dùng cam kết dài hạn khi đã ổn định. Với workload chạy ổn định 24/7, trả giá on-demand là lãng phí. Reserved Instances hay Savings Plans (AWS), Committed Use Discounts (GCP) có thể giảm 30–70% chi phí. Mẹo: chờ workload ổn định vài tháng rồi mới cam kết, đừng cam kết cho thứ còn đang biến động.
Mẹo tổng quát: đặt mục tiêu "chi phí là một metric được giám sát như latency hay uptime". Đưa con số chi phí lên dashboard mà đội nhìn hàng ngày, đừng để nó là bí mật của riêng phòng tài chính.
Bài tập thực hành
- Thiết kế bộ tag. Giả sử bạn là DevOps của một công ty có ba đội (web, mobile, data) và ba môi trường (dev, staging, production). Hãy viết ra bộ tag bắt buộc gồm ít nhất 4 khóa, kèm quy ước đặt giá trị (chữ thường, dùng dấu gạch ngang…). Giải thích mỗi tag phục vụ mục đích phân tích gì.
- Săn lãng phí. Mở tài khoản cloud của bạn (hoặc tài khoản free-tier tự tạo). Liệt kê tất cả tài nguyên đang tồn tại. Xác định: có ổ đĩa nào không gắn máy không? Có IP tĩnh nào không dùng không? Có máy nào chạy 24/7 mà thực ra chỉ cần giờ hành chính không? Ước tính số tiền tiết kiệm được nếu dọn dẹp.
- Đặt budget và alert. Trên AWS Budgets (hoặc GCP/Azure tương đương), tạo một budget 50 USD/tháng cho tài khoản của bạn, với alert ở mốc 50%, 80% và một alert theo forecast ở 100%. Định tuyến alert tới email của bạn và mô tả bạn sẽ làm gì khi mỗi alert kêu.
- Phân tích tình huống. Đọc lại tình huống fintech e-KYC. Nếu là bạn, ngoài việc chuyển region, bạn còn nghĩ ra cách nào khác để giảm chi phí data transfer? Viết ra ít nhất hai phương án và cân nhắc đánh đổi của mỗi phương án.
Tóm tắt
Quản lý chi phí cloud không phải việc làm một lần rồi thôi, mà là một kỷ luật vận hành liên tục — chính là tinh thần của FinOps. Bốn nhóm chi phí bạn cần luôn để mắt là compute, storage, data transfer (đặc biệt egress) và các managed service. Ba trụ cột để kiểm soát là Tagging để biết tiền đi đâu, Budgets để đặt giới hạn, và Alerts để được cảnh báo kịp thời trước khi hóa đơn thành cú sốc.
Ba tình huống thực tế đều dạy chúng ta cùng một điều: phần lớn lãng phí không đến từ hệ thống được thiết kế cẩn thận, mà từ những thứ bị bỏ quên, những chi phí ẩn không ai giám sát, và sự thiếu minh bạch khiến không ai thấy mình chịu trách nhiệm. Gắn tag từ đầu qua Infrastructure as Code, đặt cảnh báo sớm, tự động tắt tài nguyên không dùng, và cho mọi đội nhìn thấy con số của mình — đó là những đòn bẩy đơn giản mà hiệu quả nhất.
Hãy coi chi phí như một metric kỹ thuật quan trọng ngang với hiệu năng và độ ổn định. Một kỹ sư DevOps giỏi là người dựng được hệ thống chạy tốt, và biết chính xác nó tốn bao nhiêu tiền cùng cách để nó tốn ít hơn mà không hy sinh chất lượng.