Tối ưu chi phí Cloud (FinOps): Automation tìm và tắt EC2, S3 không dùng

Tối ưu chi phí Cloud (FinOps) bằng Workflow Automation – một quy trình tự động quét, cảnh báo và tắt các tài nguyên EC2, S3 không dùng, giúp giảm chi phí lên tới 30 % chỉ trong vài tuần.
Bài viết sẽ đưa ra tóm tắt nội dung, vấn đề thực tế, giải pháp tổng quan, hướng dẫn chi tiết, template quy trình, các lỗi phổ biến, cách mở rộng, chi phí thực tế, số liệu trước‑sau, FAQ và cuối cùng là hành động bạn nên thực hiện ngay.

1. Tóm tắt nội dung chính

• Mục tiêu: Giảm chi phí Cloud không cần thiết (FinOps) bằng workflow tự động.
• Công cụ: AWS Lambda, CloudWatch Events, Boto3 (Python), SNS/Slack webhook.
• Quy trình: Scan → Filter → Notify → Stop → Report.
• Kết quả thực tế: Giảm 20‑35 % chi phí hàng tháng, giảm 40 % thời gian quản trị.
• Tài liệu kèm: Bảng chi phí, sơ đồ workflow, template YAML, mã nguồn mẫu.

2. Vấn đề thật mà mình và khách hay gặp mỗi ngày

Câu chuyện 1 – “EC2 “ma” trong môi trường dev”

Khách công ty phần mềm vừa triển khai môi trường dev trên AWS. Sau 3 tháng, hóa đơn tăng 15 % mà không có dự án mới. Khi mình kiểm tra, phát hiện 20 instance EC2 chạy ở trạng thái stopped nhưng vẫn giữ Elastic IP và EBS volume. Mỗi instance tốn trung bình $12/tháng, tổng cộng $240 không cần thiết.

Câu chuyện 2 – “S3 “đầy” vô hình”

Một startup fintech dùng S3 để lưu trữ log. Họ không có lifecycle policy, nên log cũ 6 tháng vẫn tồn tại. Kết quả: 15 TB dữ liệu, chi phí lưu trữ $300/tháng. Khi mình đề xuất tự động xóa log > 30 ngày, chi phí giảm còn $120.

Câu chuyện 3 – “Chi phí “bất ngờ” khi scale”

Một công ty quảng cáo chạy batch processing trên EMR. Khi job kết thúc, cluster không được terminate do script lỗi. Họ mất $800 chỉ trong một đêm. Sau khi triển khai workflow tự động tắt cluster sau 2 giờ không hoạt động, chi phí giảm 90 %.

⚡ Lưu ý: Các tài nguyên “không dùng” thường không chỉ là EC2, S3 mà còn bao gồm RDS snapshots, Elastic Load Balancers, và các IAM role không gán policy.

3. Giải pháp tổng quan (text art)

+-------------------+      +-------------------+      +-------------------+
|   Scan Resources  | ---> |   Filter Idle     | ---> |   Notify Owner    |
|   (Lambda)        |      |   (Python)        |      |   (SNS/Slack)     |
+-------------------+      +-------------------+      +-------------------+
          |                         |                         |
          v                         v                         v
+-------------------+      +-------------------+      +-------------------+
|   Auto Stop       | ---> |   Generate Report | ---> |   Archive Logs    |
|   (Lambda)        |      |   (S3)            |      |   (Glacier)       |
+-------------------+      +-------------------+      +-------------------+

🛡️ Best Practice: Đặt CloudWatch Event chạy mỗi 6 giờ để cân bằng giữa độ chính xác và chi phí Lambda.

4. Hướng dẫn chi tiết từng bước

Bước 1 – Tạo IAM Role cho Lambda

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:StopInstances",
        "s3:ListBucket",
        "s3:DeleteObject",
        "cloudwatch:PutMetricData",
        "sns:Publish"
      ],
      "Resource": "*"
    }
  ]
}

⚠️ Đừng cấp quyền * cho toàn bộ tài nguyên, chỉ cấp Read‑Only + Stop/Delete cho các service cần.

Bước 2 – Viết Lambda để quét EC2

import boto3, datetime

ec2 = boto3.client('ec2')
def lambda_handler(event, context):
    idle_instances = []
    now = datetime.datetime.utcnow()
    resp = ec2.describe_instances(Filters=[{'Name':'instance-state-name','Values':['running']}])
    for reservation in resp['Reservations']:
        for instance in reservation['Instances']:
            launch_time = instance['LaunchTime']
            # Kiểm tra thời gian không có CPU > 24h (đơn giản)
            if (now - launch_time).total_seconds() > 86400:
                idle_instances.append(instance['InstanceId'])
    # Gửi SNS nếu có
    if idle_instances:
        sns = boto3.client('sns')
        message = f"EC2 idle: {idle_instances}"
        sns.publish(TopicArn='arn:aws:sns:region:acct-id:FinOpsAlert', Message=message)
    return {'idle_instances': idle_instances}

Bước 3 – Tự động tắt EC2 (Lambda thứ 2)

def stop_instances(instance_ids):
    ec2.stop_instances(InstanceIds=instance_ids)

Bước 4 – Quét S3 và áp dụng Lifecycle Policy

{
  "Rules": [
    {
      "ID": "DeleteOldLogs",
      "Prefix": "logs/",
      "Status": "Enabled",
      "Expiration": {"Days": 30}
    }
  ]
}

🛡️ Đặt Versioning cho bucket trước khi áp dụng policy để tránh mất dữ liệu quan trọng.

Bước 5 – Thiết lập CloudWatch Event (cron)

cron(0 */6 * * ? *)   # Mỗi 6 giờ

Bước 6 – Gửi báo cáo hàng tuần tới Slack

{
  "channel": "#finops-report",
  "username": "FinOps Bot",
  "text": "Weekly Cloud Cost Report: ...",
  "icon_emoji": ":moneybag:"
}

5. Template quy trình tham khảo

⚡ Tip: Đặt Lambda timeout 300 giây để tránh bị timeout khi quét số lượng lớn.

6. Những lỗi phổ biến & cách sửa

> Best Practice: Luôn log chi tiết trong CloudWatch để nhanh chóng xác định lỗi.

7. Khi muốn scale lớn thì làm sao

1. Sử dụng Step Functions – Điều phối nhiều Lambda, cho phép retry, parallel execution.
2. Chia nhỏ Region – Đặt một workflow cho mỗi region để giảm latency và tránh giới hạn API.
3. Áp dụng Tag‑Based Filtering – Gắn tag finops:managed cho tài nguyên được quản lý, tránh vô tình tắt tài nguyên quan trọng.
4. Sử dụng DynamoDB để lưu trạng thái “idle” lâu hơn 24 h, tránh tắt nhầm các instance đang khởi động.

⚡ Công thức tính ROI (tiếng Việt, không LaTeX)
ROI = (Tổng lợi ích – Chi phí đầu tư) / Chi phí đầu tư × 100 %

LaTeX công thức (tiếng Anh)

Giải thích: Savings là phần trăm chi phí giảm được sau khi áp dụng workflow tối ưu.

8. Chi phí thực tế

🛡️ Chi phí Lambda và SNS không thay đổi đáng kể vì chúng chỉ tiêu thụ tài nguyên nhỏ.

9. Số liệu trước – sau

⚡ Kết quả: Nhóm DevOps giảm 30 giờ công việc thủ công mỗi tháng, tập trung vào phát triển tính năng.

10. FAQ hay gặp nhất

Q1: Workflow có ảnh hưởng tới performance của ứng dụng không?
A: Không, vì Lambda chỉ chạy mỗi 6 giờ và sử dụng API call không đồng thời.

Q2: Làm sao tránh tắt nhầm instance đang chạy job?
A: Thêm tag finops:protected hoặc kiểm tra CloudWatch metric CPUUtilization > 5 % trong 30 phút gần nhất.

Q3: Có thể áp dụng cho Azure/GCP không?
A: Nguyên tắc tương tự, chỉ thay đổi SDK (Azure Functions, Google Cloud Functions) và API tương ứng.

Q4: Chi phí Lambda có tăng khi số tài nguyên lớn?
A: Lambda tính phí dựa trên thời gian thực thi và memory. Với 10 000 instance, thời gian quét vẫn dưới 2 phút, chi phí < $30/tháng.

Q5: Cần bao lâu để thấy hiệu quả?
A: Thông thường 2‑4 tuần để thu thập đủ dữ liệu và tối ưu hoá policy.

11. Giờ tới lượt bạn

• Bước 1: Kiểm tra danh sách tài nguyên hiện tại, gắn tag finops:managed.
• Bước 2: Triển khai mẫu Lambda và CloudWatch Event từ repo mẫu (link GitHub).
• Bước 3: Theo dõi báo cáo hàng tuần, điều chỉnh threshold (CPU < 5 % → 24 h).
• Bước 4: Khi đã ổn định, mở rộng sang các region và dịch vụ khác (RDS, DynamoDB).

> Best Practice: Đặt alert threshold linh hoạt, không cố định một con số; luôn kiểm tra log trước khi auto‑stop.

Nếu anh em đang cần giải pháp trên, thử ngó qua con Serimi App xem, mình thấy API bên đó khá ổn cho việc scale. Hoặc liên hệ mình để được trao đổi nhanh hơn nhé.