Amazon RDS hiển thị chi phí từng snapshot: quản trị backup rõ hơn

Một hóa đơn backup RDS tăng lên thường chỉ cho biết database nào tạo chi phí, không chỉ ra snapshot nào đang giữ dung lượng lâu nhất. Đội FinOps phải ghép thủ công ngày tạo, chủ sở hữu và chính sách lưu. Ngày 02/11/2026, AWS bật cách xem chi phí cho từng snapshot RDS.

Bài dành cho quản trị database, cloud và FinOps. Thay đổi mới giúp trả lời ai tạo bản sao, vì sao còn giữ và chi phí thuộc dự án nào; nó không tự xóa snapshot hoặc thay thế chính sách phục hồi.

Per-snapshot billing có gì mới

Theo AWS What's New ngày 02/11/2026, Cost and Usage Report cùng Cost Explorer trước đây gộp phí snapshot ở cấp DB instance. Nay doanh nghiệp có thể dùng cost allocation tags trên snapshot để xem chi phí riêng của từng bản sao.

Tính năng được bật mặc định cho toàn bộ RDS snapshot, không thu thêm phí tính năng, hỗ trợ tất cả RDS engines tại các khu vực thương mại và AWS GovCloud. Không thu phí tính năng không có nghĩa snapshot miễn phí; dung lượng backup vẫn tính theo bảng giá và điều kiện của dịch vụ.

Từ số liệu đến quyết định

Chi phí riêng từng snapshot giúp phát hiện bản sao không có chủ sở hữu, bản thử nghiệm giữ quá lâu, snapshot thủ công nằm ngoài vòng đời tự động hoặc bản sao liên vùng không còn mục tiêu phục hồi. Khi gắn thẻ môi trường, ứng dụng, chủ sở hữu và thời hạn lưu, đội tài chính có thể phân bổ chi phí mà không đoán từ tên DB.

Tuy nhiên, snapshot đắt không đồng nghĩa nên xóa ngay. Một bản sao có thể phục vụ tuân thủ, điều tra sự cố hoặc mục tiêu khôi phục theo hợp đồng. Quyết định cần dựa trên Recovery Point Objective (RPO, mức dữ liệu tối đa có thể mất) và Recovery Time Objective (RTO, thời gian cần để khôi phục), không chỉ hóa đơn tháng.

Checklist chuẩn hóa snapshot RDS

1. Bắt buộc thẻ owner, application, environment, retention và cost-center cho snapshot thủ công; chặn tên tùy ý không có chủ sở hữu.
2. Kiểm tra cost allocation tags đã được kích hoạt để xuất hiện trong báo cáo chi phí; gắn thẻ nhưng không kích hoạt sẽ không đủ cho phân bổ.
3. Đối chiếu snapshot tự động, thủ công, bản sao liên vùng và snapshot được chia sẻ; ghi rõ vòng đời của từng loại.
4. Đặt báo cáo hàng tuần cho snapshot không có thẻ, vượt thời hạn hoặc không còn DB nguồn; chuyển danh sách cho chủ ứng dụng xác nhận.
5. Thử khôi phục định kỳ. Snapshot tồn tại và phát sinh chi phí nhưng không khôi phục được không đáp ứng mục tiêu backup.
6. Tách quyền tạo, chia sẻ và xóa snapshot; bật ghi log và cảnh báo cho thao tác làm thay đổi khả năng phục hồi.
7. Chỉ tự động xóa sau khoảng chờ và cơ chế ngoại lệ, tránh biến tối ưu chi phí thành mất bản sao cần thiết.

Ý nghĩa với doanh nghiệp dùng nhiều nền tảng

Nếu doanh nghiệp vừa dùng RDS vừa vận hành database trên VPS hoặc máy chủ riêng, nên chuẩn hóa cùng một bảng: loại bản sao, vị trí, mã hóa, chủ sở hữu, thời hạn lưu, chi phí và lần khôi phục gần nhất. RDS cung cấp dữ liệu chi phí chi tiết hơn, nhưng đội vận hành vẫn phải quyết định bản sao nào cần tồn tại.

Đội hạ tầng có thể chuẩn bị dung lượng database, RPO/RTO, số ngày lưu và yêu cầu bản sao ngoài hệ thống rồi gửi qua trang thuê máy chủ. Mục đích là so sánh thiết kế backup và chi phí toàn vòng đời; không nên chọn máy chủ chỉ dựa trên dung lượng snapshot hiện tại.

Nguồn tham khảo

• AWS What's New, “Amazon RDS now supports per snapshot billing”, đăng và có hiệu lực ngày 02/11/2026.
• AWS xác nhận tính năng bật mặc định, không thu thêm phí tính năng và áp dụng cho mọi RDS engine ở các khu vực được nêu trong thông báo.