Cloud Cost Optimization: Giảm chi phí cloud production an toàn

Cloud cost optimization không phải là cắt giảm tài nguyên bằng mọi giá. Trong môi trường production, tối ưu chi phí cloud đúng nghĩa là hiểu workload, đo mức sử dụng thật, giảm lãng phí có kiểm soát và vẫn giữ được độ ổn định, bảo mật, khả năng mở rộng khi traffic tăng.

Bài này đi theo góc nhìn thực chiến của System Administrator, DevOps và Cloud Engineer: từ cách đọc hóa đơn, gắn tag, phân tích CPU/RAM/disk/network, đến rightsizing, autoscaling, reserved capacity, cảnh báo ngân sách và checklist nghiệm thu sau khi tối ưu.

Cloud cost optimization là gì?

Cloud cost optimization là quá trình liên tục nhằm đưa chi phí cloud về mức hợp lý nhất so với giá trị vận hành. Nó không chỉ là “giảm tiền bill”, mà là tối ưu quan hệ giữa chi phí, hiệu năng, độ sẵn sàng và rủi ro.

Không tắt bừa tài nguyên production chỉ vì thấy ít dùng trong vài giờ.
Không hạ cấu hình database nếu chưa có benchmark và kế hoạch rollback.
Không mua reserved capacity khi workload chưa ổn định.
Không tối ưu một lần rồi bỏ quên; cloud thay đổi theo traffic, release và dữ liệu.

Tài liệu chính thống đáng đọc thêm gồm AWS Well-Architected Cost Optimization Pillar, Microsoft Azure cost optimization guidance và Google Cloud Architecture Framework: Cost Optimization.

Bối cảnh lab/production mẫu

Giả sử anh đang vận hành một hệ thống web gồm load balancer, 4 VM chạy ứng dụng, 1 database managed service, object storage lưu ảnh, snapshot backup hằng ngày và một cụm Kubernetes nhỏ cho worker nền. Hóa đơn cloud tăng đều mỗi tháng, nhưng chưa rõ tăng do traffic thật, cấu hình dư hay tài nguyên bỏ quên.

Mục tiêu tối ưu

Giảm 15–30% chi phí lãng phí trong 30 ngày đầu.
Không làm giảm SLA/SLO của dịch vụ chính.
Có số liệu trước/sau để chứng minh hiệu quả.
Có rollback plan cho mọi thay đổi liên quan production.

Bước 1: Gắn tag để biết tiền đang đi đâu

Nếu không có tag, hóa đơn cloud chỉ là một bảng số tiền khó truy vết. Bộ tag tối thiểu nên có:

Environment = production | staging | dev
Service     = web | api | worker | database | monitoring
Owner       = team-platform | team-product | team-data
CostCenter  = internal-code-or-project-code
ManagedBy   = terraform | ansible | manual

Với AWS CLI, có thể liệt kê EC2 chưa có tag Owner như sau:

aws ec2 describe-instances \
  --query 'Reservations[].Instances[?!not_null(Tags[?Key==`Owner`].Value)]|[].{InstanceId:InstanceId,State:State.Name,Type:InstanceType}' \
  --output table

Output mẫu:

-------------------------------------------------
|              DescribeInstances                |
+----------------------+----------+-------------+
| i-0123456789abcdef0  | running  | t3.large    |
| i-0abcdef1234567890  | stopped  | m5.xlarge   |
+----------------------+----------+-------------+

Dòng stopped vẫn có thể phát sinh chi phí EBS volume hoặc snapshot. Đây là nhóm dễ tối ưu nhưng thường bị bỏ quên.

Bước 2: Phân loại chi phí theo mức rủi ro

Không nên xử lý mọi khoản chi như nhau. Hãy chia thành 4 nhóm:

An toàn để dọn ngay: tài nguyên orphan, snapshot quá hạn, IP public không gắn, volume không attach.
Cần kiểm tra: VM thấp tải, storage tăng bất thường, log retention quá dài.
Cần thử nghiệm: rightsizing database, đổi instance family, chuyển storage tier.
Không đụng nếu chưa có kế hoạch: tài nguyên nằm trên critical path production.

Bước 3: Rightsizing VM và database bằng số liệu thật

Rightsizing là giảm hoặc tăng cấu hình tài nguyên để phù hợp workload. Với VM chạy ứng dụng, hãy xem ít nhất 7–14 ngày metric, tốt hơn là 30 ngày nếu hệ thống có chu kỳ theo tuần.

# Ví dụ kiểm tra nhanh CPU/RAM trên Linux VM
uptime
free -h
vmstat 1 5
iostat -xz 1 5

Giải thích nhanh:

uptime: xem load average, so với số CPU core.
free -h: xem RAM khả dụng, swap có bị dùng nhiều không.
vmstat: xem CPU wait, run queue, memory pressure.
iostat: xem disk latency và utilization.

Nếu CPU trung bình 5–10%, p95 dưới 30%, RAM còn dư lớn và disk I/O thấp trong nhiều tuần, VM có thể đang over-provisioned. Nhưng trước khi hạ size, cần kiểm tra peak traffic, batch job, cron job, backup window và sự kiện marketing.

Bước 4: Autoscaling thay vì chạy dư cố định

Với workload stateless, autoscaling thường hiệu quả hơn việc giữ số VM cố định ở mức cao. Một chính sách đơn giản có thể là:

Minimum capacity: đủ chịu traffic thấp điểm và một node lỗi.
Desired capacity: theo baseline giờ bình thường.
Maximum capacity: đủ chịu peak có kiểm soát ngân sách.
Scale-out: CPU p70 trên 60% hoặc request latency tăng.
Scale-in: chậm hơn scale-out để tránh dao động.

Trong Kubernetes, cần phối hợp Horizontal Pod Autoscaler, request/limit hợp lý và Cluster Autoscaler hoặc Karpenter. Tài liệu Kubernetes về resource management có tại kubernetes.io/docs/concepts/configuration/manage-resources-containers/.

Bước 5: Tối ưu storage, snapshot và log retention

Storage thường tăng âm thầm. Ba nguồn phổ biến là object storage, snapshot backup và log. Hãy đặt lifecycle policy theo nhu cầu khôi phục thật sự.

# Ví dụ kiểm tra dung lượng log trên Linux
sudo du -h --max-depth=1 /var/log | sort -h
sudo journalctl --disk-usage

Output mẫu:

Archived and active journals take up 2.8G in the file system.

Với journald, có thể giới hạn bằng SystemMaxUse, nhưng cần cân bằng với nhu cầu điều tra sự cố. Với cloud log service, hãy tách retention production, staging và dev thay vì dùng một chính sách chung.

Bước 6: Reserved capacity chỉ sau khi workload ổn định

Reserved Instances, Savings Plans hoặc committed use discounts có thể giảm giá đáng kể, nhưng cũng khóa cam kết chi phí. Chỉ nên mua khi:

Workload chạy ổn định nhiều tháng.
Đã rightsizing trước khi cam kết.
Có kế hoạch tăng/giảm tài nguyên trong 6–12 tháng tới.
Đội vận hành hiểu điều khoản vùng, instance family và khả năng chuyển đổi.

Bước 7: Đặt budget alert và guardrail

Cloud cost optimization sẽ thất bại nếu không có cảnh báo sớm. Tối thiểu nên có:

Cảnh báo khi chi phí tháng đạt 50%, 80%, 100% budget.
Cảnh báo anomaly khi một service tăng bất thường.
Policy chặn tạo tài nguyên quá lớn ở môi trường dev.
Báo cáo tuần theo service, owner và environment.

Lỗi thường gặp khi tối ưu chi phí cloud

Chỉ nhìn CPU trung bình: bỏ qua p95/p99, memory, disk I/O và network.
Không có rollback: hạ size xong mới phát hiện latency tăng.
Dọn snapshot không theo policy: mất điểm khôi phục quan trọng.
Mua reserved quá sớm: khóa tiền vào cấu hình chưa tối ưu.
Không gắn owner: không ai chịu trách nhiệm khoản chi.

Troubleshooting khi bill tăng bất thường

Khi hóa đơn tăng đột biến, hãy đi theo thứ tự:

Xác định service tăng nhiều nhất: compute, database, storage, network hay logging.
Lọc theo region và account/project.
So sánh với thời điểm release, migration, incident hoặc batch job.
Kiểm tra tài nguyên mới tạo trong 7 ngày gần nhất.
Kiểm tra egress network, vì chi phí outbound thường bị đánh giá thấp.
Tạo ticket owner xác nhận tài nguyên còn cần dùng hay không.

Checklist nghiệm thu sau tối ưu

Đã có baseline chi phí trước thay đổi.
Đã có metric CPU/RAM/disk/network trước và sau thay đổi.
Không tăng error rate, latency p95/p99 hoặc restart count.
Backup và restore point vẫn đạt RPO/RTO.
Budget alert hoạt động và gửi đúng kênh.
Tag owner/service/environment đầy đủ.
Runbook rollback được lưu trong repository hoặc wiki vận hành.

Bài tập lab cuối bài

Trong môi trường lab hoặc staging, hãy thực hiện bài tập sau:

Liệt kê toàn bộ VM, disk, snapshot và object bucket.
Gắn tag Environment, Service, Owner cho từng tài nguyên.
Tìm ít nhất 3 tài nguyên có khả năng lãng phí.
Đề xuất hành động: xóa, chuyển tier, resize hoặc giữ nguyên.
Viết rollback plan cho một thay đổi rightsizing.
Tạo báo cáo trước/sau gồm chi phí ước tính và rủi ro.

Kết luận

Cloud cost optimization là một thói quen vận hành, không phải chiến dịch một lần. Làm tốt việc gắn tag, đo metric, rightsizing, autoscaling, quản lý storage, đặt budget alert và review định kỳ sẽ giúp hệ thống production tiết kiệm hơn mà vẫn an toàn. Điểm quan trọng nhất là mọi thay đổi tiết kiệm chi phí phải có dữ liệu, có người chịu trách nhiệm và có đường rollback rõ ràng.

Cloud Cost Optimization: Giảm chi phí cloud mà không làm yếu production