Quản Lý Chi Phí S3: Tự Động Hóa Báo Cáo với Lambda và Python ☕

S3 là dịch vụ lưu trữ đám mây phổ biến của AWS, nhưng chi phí có thể tăng nhanh chóng một cách không mong đợi. Một ngày nọ, khi nhìn vào hóa đơn AWS, tôi nhận ra rằng chi phí lưu trữ S3 đã âm thầm tiêu tốn một phần lớn ngân sách của mình. Với nhiều bucket trải dài qua các nhóm, dự án và thử nghiệm mà không ai nhớ đến, tôi phải tìm ra giải pháp:

Làm Thế Nào Để Theo Dõi Chi Phí S3?

Làm thế nào để xác định các bucket nào đang tiêu tốn nhiều chi phí nhất?
Làm thế nào để có báo cáo hàng tuần mà không phải truy vấn Athena thủ công?

Vì vậy, như một kỹ sư lười biếng không muốn làm việc lặp đi lặp lại, tôi quyết định tự động hóa quy trình này. 😎

Bước 1: Kiểm Kê Kho Lưu Trữ 📦

Đầu tiên, tôi đã kích hoạt báo cáo kiểm kê S3 ở định dạng Parquet (JSON sẽ quá phức tạp). Những báo cáo này chứa tất cả thông tin về đối tượng, loại lưu trữ và kích thước. Đây là điều hoàn hảo cho các truy vấn Athena.

Sau khi kích hoạt, các báo cáo bắt đầu được gửi đến một bucket S3 chuyên dụng. Từ đó, tôi đã xây dựng nhiều bảng Athena trỏ đến các tệp Parquet này—bởi vì SQL > việc cuộn vô tận qua bảng điều khiển S3.

Bước 2: Viết Truy Vấn Athena Như Một Thám Tử 🕵️

Ý tưởng rất đơn giản:

Đối với mỗi bảng (kiểm kê theo bucket/prefix), tính toán kích thước lưu trữ.
Ước lượng chi phí dựa trên giá loại lưu trữ.
Tìm ra 'N' bucket đứng đầu (những bucket tiêu tốn nhiều chi phí nhất).

Dưới đây là một ví dụ về truy vấn Athena mà tôi đã sử dụng trong mã của mình để lấy chi phí và kích thước (theo loại lưu trữ) của một bucket:

sql Copy

WITH filtered_data AS (
    SELECT 
        storage_class, 
        intelligent_tiering_access_tier,
        SUM(size) AS total_size
    FROM 
        my_bucket_1
    WHERE 
        dt = '2025-08-19-01-00'
    GROUP BY 
        storage_class, intelligent_tiering_access_tier
)
SELECT 
    storage_class,
    intelligent_tiering_access_tier,
    total_size,
    CASE 
        WHEN storage_class = 'STANDARD' THEN total_size * 0.0210 / (1024 * 1024 * 1024)
        WHEN storage_class = 'GLACIER' THEN total_size * 0.0036 / (1024 * 1024 * 1024)
        WHEN storage_class = 'DEEP_ARCHIVE' THEN total_size * 0.00099 / (1024 * 1024 * 1024)
        ELSE 0
    END AS estimated_cost_usd
FROM 
    filtered_data;

Về cơ bản, tôi đang hỏi Athena:
💡 “Chào bạn, hãy cho tôi biết loại lưu trữ nào đang âm thầm tiêu tốn tín dụng của tôi.”

Bước 3: Lambda + Boto3 = Tự Động Hóa ❤️

Giờ đến phần thú vị—đóng gói nó vào một hàm Lambda để tôi không phải chạy truy vấn bằng tay.

Chức Năng Của Lambda:

Đối với mỗi bảng kiểm kê S3, Lambda chạy một truy vấn SQL duy nhất trả về các chỉ số theo prefix và theo loại lưu trữ: object_count, total_size (bytes) và estimated_cost_usd (tôi đã mã hóa giá per-GB cho STANDARD, GLACIER, DEEP_ARCHIVE và các mức truy cập thông minh ngay trong truy vấn).
Nó kiểm tra Athena (vòng lặp classic get_query_execution với time.sleep(5)) cho đến khi mỗi truy vấn hoàn thành, sau đó lấy kết quả CSV được viết vào S3.
Nó tổng hợp các hàng truy vấn thành một cấu trúc Python được khóa bởi (table, prefix)—tính tổng số đối tượng, bytes và chi phí ước tính, và giữ một danh sách phân tích cho mỗi loại lưu trữ / tầng.
Khi tất cả các bảng đã được xử lý, Lambda tính toán tổng chi phí cho mỗi (table,prefix) và sắp xếp theo thứ tự giảm dần để chọn ra N bucket hàng đầu (có thể cấu hình, tôi đã sử dụng 15).
Sau đó, nó xây dựng một báo cáo CSV chi tiết với một hàng tóm tắt cha cho mỗi prefix xếp hạng (tổng chi phí, tổng kích thước, tổng số đối tượng) tiếp theo là các hàng phân tích cho mỗi loại lưu trữ/tầng (object_count, size_GB, cost_USD).
CSV được tải lên S3 (báo cáo này có phiên bản, có thể chia sẻ và dễ kiểm tra).
Cuối cùng, Lambda gửi một email tóm tắt ngắn gọn qua SES (các dòng hàng đầu + kích thước/chi phí) và bao gồm đường dẫn S3 đến CSV—vì vậy mỗi sáng thứ Hai (thông qua lịch EventBridge), tôi nhận được một báo cáo có thể hành động mà tôi có thể chuyển tiếp cho các nhóm hoặc sử dụng để kích hoạt dọn dẹp.

Kiểm tra mã Python đầy đủ trên kho lưu trữ GitHub của tôi, hãy thử nghiệm nhé. 💪

Giờ đây, thay vì phải tìm kiếm Athena vào mỗi thứ Hai, tôi chỉ việc nhâm nhi cà phê và mở hộp thư đến của mình ☕📧.

Bước 4: Lịch Trình với EventBridge (hay người hầu cuối tuần của tôi)

Để làm cho điều này thực sự tự động, tôi đã lên lịch cho Lambda chạy mỗi Chủ Nhật lúc nửa đêm thông qua EventBridge. Bằng cách đó, khi tôi bước vào buổi họp sáng thứ Hai, tôi đã biết những bucket nào là kẻ xấu của tuần.

(Và đúng, điều này đôi khi làm tôi trông có vẻ chuẩn bị hơn thực tế. 😎)

Hình Dạng Báo Cáo Cuối Cùng 📊

Email tôi nhận được trông giống như sau:

Bảng: my_bucket_1 | Bucket: my-bucket-1 | Kích thước: 12.3 TB | Chi phí: 257.23$
Bảng: my_bucket_2 | Bucket: my.bucket.2 | Kích thước: 9.1 TB | Chi phí: 198.72$
… và tiếp tục như vậy.
Ngắn gọn, đơn giản, có thể hành động.

Tại Sao Điều Này Quan Trọng

Nhìn Nhận: S3 dễ bị bỏ qua, nhưng chi phí có thể tăng lên nhanh chóng.
Tự Động Hóa: Không cần truy vấn thủ công, không còn “ôi, tôi đã quên.”
Tiết Kiệm Chi Phí: Phát hiện dự án cũ, bucket thử nghiệm hoặc loại lưu trữ được cấu hình sai ngay từ đầu.

Điều bắt đầu như một thử nghiệm vào cuối tuần giờ đã trở thành bài kiểm tra chi phí hàng tuần của tôi.
Nó không phải là khoa học tên lửa, nhưng tiết kiệm $$$ và thời gian suy nghĩ.

Nếu bạn cũng đang bị ám ảnh bởi “bucket bí ẩn” trên hóa đơn AWS của mình, hãy thử phương pháp này. Bạn sẽ cảm ơn bản thân vào mỗi sáng thứ Hai.

Bạn đã từng thử một phương pháp tương tự để kiểm soát chi phí S3 chưa? Hay có thể bạn đã tìm ra một cách tốt hơn? Hãy để lại ý kiến—tôi rất muốn học hỏi (và có thể sẽ đánh cắp ý tưởng của bạn 😅).

Quản Lý Chi Phí S3: Tự Động Hóa Báo Cáo với Lambda và Python