Cách tôi cắt giảm chi phí AWS CloudWatch mà vẫn giữ nguyên khả năng giám sát

Việc tối ưu chi phí AWS CloudWatch là cực kỳ quan trọng, bởi vì các khoản phí này có thể đội lên lúc nào không hay đâu. Đặc biệt là khi hệ thống có lượng log lớn, gửi metrics thường xuyên, và dùng các dashboard tùy chỉnh. Dưới đây là một chiến lược nhỏ gọn để giúp mọi người tối ưu chi phí mà vẫn đảm bảo khả năng quan sát cần thiết.

1. Quản Lý Thời Gian Lưu Trữ và Dung Lượng Log

Hãy xác định rõ chính sách lưu giữ log. Đừng bao giờ lưu log mãi mãi, vì nó tốn tiền lắm.

Ví dụ: Bạn có thể đặt thời gian lưu giữ là 7, 14, hoặc 30 ngày tùy theo yêu cầu tuân thủ hay nhu cầu kinh doanh.

Nếu cần lưu trữ lâu hơn, hãy xuất log sang S3 để lưu trữ dài hạn. Bạn có thể dùng S3 kết hợp với Glacier để lưu trữ với chi phí cực rẻ.

Đừng quên xóa log groups không còn dùng nữa, đặc biệt là những cái còn sót lại từ các môi trường cũ.

2. Tối Ưu Hóa Metrics

Hãy ưu tiên sử dụng các số liệu tiêu chuẩn nếu có thể. Các dịch vụ AWS thường đẩy các số liệu cơ bản miễn phí, ví dụ CPUUtilization của EC2.

Cố gắng tránh tạo custom metrics, vì mỗi số liệu này sẽ tốn tiền hàng tháng.

Cân nhắc việc tổng hợp các số liệu hoặc gửi chúng theo batching để giảm chi phí.

Hãy dùng EMF cho các log có cấu trúc mà cũng hoạt động như số liệu.

3. Quản Lý Dashboard và Cảnh Báo

Tránh tạo các dashboard hay cảnh báo trùng lặp, đặc biệt là khi chúng sử dụng các số liệu bị chồng chéo.

Sử dụng composite alarms, tức là một cảnh báo kết hợp nhiều điều kiện. Điều này giúp giảm chi phí và cả những cảnh báo rác không cần thiết.

Chỉ thiết lập cảnh báo cho những ngưỡng quan trọng thôi nhé.

4. Giảm Dung Lượng Log

Hãy lọc log ngay tại nguồn. Đừng ghi log mọi thứ ở mức độ debug/info trừ khi thực sự cần thiết.

Sử dụng các thư viện ghi log một cách thông minh. Ví dụ trong Java như Logback, bạn có thể lọc và lấy mẫu log.

5. Tối Ưu Hóa Log Insights

Hạn chế sử dụng các truy vấn tốn kém.

Tránh các truy vấn trên phạm vi quá lớn, ví dụ 30 ngày gần nhất, trừ khi thực sự cần.

Sử dụng các truy vấn theo lịch một cách tiết kiệm.

Nếu có thể, hãy lên lịch chạy truy vấn vào giờ thấp điểm hoặc giảm tần suất.

6. Thiết Kế Ghi Log Tập Trung

Thay vì để nhiều tài khoản đẩy log riêng lẻ, hãy tập trung tất cả log aggregation account.

Điều này giúp quản lý việc nạp log và kiểm soát chi phí tốt hơn.

Các Giải Pháp Thay Thế

Bạn có thể cân nhắc sử dụng OpenTelemetry + Prometheus + Grafana cho các số liệu/log tùy chỉnh thay vì CloudWatch, đặc biệt nếu bạn đang tự quản lý hạ tầng của mình như EKS.

Sử dụng Fluent Bit/Fluentd + S3 + Athena để tìm kiếm log hiệu quả về chi phí.

Mẹo Nhỏ: Dùng AWS Cost Explorer

Hãy lọc theo CloudWatch trong AWS Cost Explorer để phân tích chi phí theo từng tài nguyên (nhóm log, số liệu, v.v.).

Từ đó, bạn có thể dễ dàng xác định những thứ đang ngốn tiền nhiều nhất.

INFO và DEBUG

Hãy hình dung log của bạn giống như bảng điều khiển trên ô tô:

INFO là tốc độ, mức nhiên liệu, những thứ mà một tài xế quan tâm khi đang lái xe.
DEBUG là chẩn đoán động cơ, những thứ mà một thợ máy quan tâm khi có gì đó không ổn.

Thực hành tốt nhất:

Chỉ sử dụng DEBUG khi thực sự cần thiết và tắt nó ở môi trường production.
Sử dụng ghi log có điều kiện, ví dụ if log.isDebugEnabled() trong Java.
Hãy dùng INFO cho các sự kiện quan trọng trong vòng đời ứng dụng: Khởi động, tắt máy, vào/ra API, các thông báo thành công.
Sử dụng WARN/ERROR cho các lỗi hoặc hành vi không mong muốn.
Tránh ghi các dữ liệu nhạy cảm vào log ở mức độ DEBUG hoặc INFO.
Sử dụng structured logging để dễ dàng lọc hơn, ví dụ log dạng JSON với đầy đủ ngữ cảnh.

Mẹo cho AWS CloudWatch: Đặt mức độ ghi log một cách linh hoạt thông qua cấu hình bên ngoài, ví dụ file logback-spring.xml hoặc Spring Cloud Config, và chỉ đẩy các log từ mức INFO trở lên lên CloudWatch để giảm chi phí nạp dữ liệu.