title: "Cost Optimization with AI: Dùng AI phân tích chi phí Cloud và đưa ra giải pháp cắt giảm"
series: "AI-Native Solutions Architect: Từ Coder đến Kiến trúc sư AI"
season: "Season 2 — AI-Augmented Architecture & System Design"
order: 13
audience: "Software Engineer hướng tới Solutions Architect"
reading_time: "~11 phút đọc"
tags: ["cost optimization", "FinOps", "cloud", "AWS", "AI", "right-sizing"]

Cost Optimization with AI: Dùng AI phân tích chi phí Cloud và đưa ra giải pháp cắt giảm

Tháng nào cũng vậy: hóa đơn AWS về, số tăng nhẹ so với tháng trước, không ai buồn mở ra xem chi tiết vì "chắc do traffic tăng". Ba tháng liên tiếp như thế, đến lúc CFO hỏi thẳng "tại sao chi phí hạ tầng tăng 42% trong quý mà số lượng khách hàng chỉ tăng 12%", đội kỹ thuật mới ngồi lại mở Cost Explorer ra và... không ai biết trả lời từ đâu. Dữ liệu billing có hàng chục nghìn dòng, trải trên hàng chục service, hàng trăm resource ID, không có ai làm chủ (owner) rõ ràng cho từng dòng chi phí.

Đây không phải tình huống hiếm. Cloud cost là một dạng "kỹ thuật nợ" (technical debt) đặc biệt: nó không gây lỗi, không có alert PagerDuty, không làm sập production — nó chỉ âm thầm tích lũy. Một EBS volume quên detach sau khi xóa EC2 instance. Một RDS instance size XL được launch "tạm thời" cho load test rồi không ai downsize lại. Một load balancer trỏ vào target group rỗng vẫn chạy 24/7. Từng khoản riêng lẻ chỉ vài chục đô, nhưng cộng dồn qua nhiều team, nhiều tháng, nó trở thành khoản chi phí không giải thích được.

Bài này không nói AI sẽ "tự động cắt giảm chi phí cloud" — chuyện đó vẫn cần con người quyết định cuối cùng. Cái AI làm tốt là giúp bạn rút ngắn thời gian từ "nhìn vào một bảng billing khổng lồ" xuống "danh sách anomaly cụ thể cần review", một việc mà làm thủ công có thể mất cả ngày mỗi tháng.

Vấn đề

Cost optimization theo cách truyền thống thường thất bại vì ba lý do:

Không ai sở hữu việc review. Trong hầu hết tổ chức, không có role "cost owner" rõ ràng cho từng service. DevOps launch hạ tầng để phục vụ feature, xong việc là quên. FinOps (nếu có) chỉ nhìn số tổng, không đủ ngữ cảnh kỹ thuật để biết instance nào đang thật sự cần, instance nào là rác.

Dữ liệu quá lớn để review thủ công. Một AWS Cost and Usage Report (CUR) hoặc export từ Cost Explorer có thể có hàng chục nghìn dòng mỗi tháng, chia theo service, region, usage type, linked account, tag. Con người không đọc nổi hết, nên thường chỉ nhìn vào biểu đồ tổng theo service — và bỏ lỡ anomaly ở resource-level.

Công cụ billing hiện có cho số, không cho lý do. AWS Cost Explorer, Trusted Advisor, hay GCP Cost Management đều tốt ở việc hiển thị "chi phí bao nhiêu", nhưng phần diễn giải "tại sao tăng" và "nên làm gì" vẫn phải do con người tự suy luận. Trusted Advisor có một số recommendation cứng (idle load balancer, low-utilization EC2) nhưng không giải thích theo ngữ cảnh nghiệp vụ của bạn, và không tổng hợp được xu hướng đa chiều.

Kết quả: cost review trở thành việc "khi nào rảnh thì làm", tức là gần như không bao giờ làm, cho tới khi hóa đơn đủ lớn để ai đó phải hỏi.

Kỹ thuật cốt lõi

Ý tưởng cốt lõi ở đây không có gì huyền bí: bạn xuất billing data ra dạng có cấu trúc (CSV/JSON từ Cost Explorer hoặc CUR), rồi dùng AI như một "bộ lọc thông minh" để tìm ba nhóm vấn đề phổ biến trước khi con người review sâu:

1. Over-provisioned — tài nguyên được cấp phát lớn hơn nhiều so với mức sử dụng thực tế. Ví dụ RDS db.r6g.2xlarge mà CPU utilization trung bình chỉ 8%, hoặc EC2 Auto Scaling Group có min capacity đặt cao hơn traffic thực tế cần.
2. Orphan resources — tài nguyên vẫn bị tính phí nhưng không còn ai dùng: EBS volume available (unattached) tồn tại hàng tháng, Elastic IP không gắn instance, snapshot cũ hơn retention policy, load balancer trỏ vào target group rỗng, NAT Gateway của một VPC đã ngừng dùng.
3. Thiếu right-sizing / commitment coverage — chạy On-Demand liên tục cho workload ổn định thay vì dùng Savings Plans/Reserved Instances, hoặc thiếu auto-scaling nên phải over-provision theo peak thay vì theo average.

Vai trò của AI trong pipeline này là triage, không phải quyết định. Luồng thực tế trông như sau:

flowchart LR
    A[Billing Export<br/>CUR / Cost Explorer CSV] --> B[Chuẩn hóa dữ liệu<br/>gộp theo Service/Tag/Resource]
    B --> C[AI phân tích<br/>tìm anomaly + xu hướng]
    C --> D[Danh sách đề xuất<br/>ranked theo mức độ nghiêm trọng]
    D --> E{Human review<br/>đối chiếu business context}
    E -->|Đồng ý| F[Áp dụng thay đổi<br/>qua IaC, có rollback]
    E -->|Từ chối / cần thêm info| G[Ghi chú lý do<br/>feedback lại vào lần review sau]

Điểm quan trọng: bước "AI phân tích" chỉ nhận input là số liệu (chi phí, xu hướng, tag), không có ngữ cảnh nghiệp vụ (dịch vụ nào critical, dịch vụ nào chạy batch job cuối tháng, đợt nào sắp có campaign traffic tăng đột biến). Vì vậy bước "Human review" ở giữa không phải là thủ tục hình thức — nó là nơi duy nhất áp domain knowledge vào, và không thể bỏ qua.

Thực hành

Bước 1 — Xuất dữ liệu billing thành bảng chuẩn hóa

Trước khi đưa AI phân tích, cần một bảng chi phí theo service, có xu hướng theo thời gian để AI nhìn ra pattern (tăng dần, tăng đột biến, phẳng). Ví dụ bảng xuất từ AWS Cost Explorer (group by Service, filter theo tag Environment=production):

Bước 2 — Prompt mẫu yêu cầu AI phân tích bảng này

Dùng nguyên văn prompt sau (thay bảng thật của bạn vào phần <<BẢNG DỮ LIỆU>>), gửi cho một LLM có khả năng đọc bảng và suy luận theo domain cloud/FinOps:

Bạn là một Cloud FinOps Engineer có kinh nghiệm với AWS. Tôi sẽ đưa cho bạn
một bảng chi phí cloud theo service, kèm xu hướng 3 tháng gần nhất và ghi chú
kỹ thuật. Nhiệm vụ của bạn:

1. Với MỖI dòng trong bảng, đánh giá xem đây có phải là bất thường (anomaly)
   hay không, dựa trên xu hướng tăng/giảm và ghi chú tag đi kèm.
2. Với mỗi dòng bất thường, phân loại vào đúng MỘT trong ba nhóm:
   - OVER_PROVISIONED (tài nguyên cấp phát lớn hơn nhu cầu thực tế)
   - ORPHAN (tài nguyên không còn được sử dụng nhưng vẫn bị tính phí)
   - MISSING_OPTIMIZATION (thiếu right-sizing, thiếu commitment/reserved
     capacity, thiếu lifecycle policy, hoặc cấu hình mặc định gây lãng phí)
3. Với mỗi dòng bất thường, đề xuất MỘT hành động cụ thể, khả thi, kèm mức độ
   rủi ro khi thực hiện (LOW/MEDIUM/HIGH) và lý do rủi ro đó.
4. KHÔNG đề xuất hành động cho dòng có xu hướng ổn định qua các tháng.
5. Xuất kết quả dưới dạng bảng markdown với các cột:
   Service | Phân loại | Mức độ ưu tiên (P1-P3) | Hành động đề xuất | Rủi ro | Cần xác nhận thêm gì trước khi áp dụng

Ràng buộc quan trọng: bạn KHÔNG biết ngữ cảnh nghiệp vụ (dịch vụ nào đang
chạy batch job quan trọng, dịch vụ nào sắp có traffic tăng do campaign, SLA
cam kết với khách hàng). Vì vậy ở cột cuối cùng, LUÔN liệt kê rõ những câu hỏi
cần hỏi đội vận hành trước khi áp dụng thay đổi — không tự giả định là an toàn.

<<BẢNG DỮ LIỆU>>
[dán bảng Service | Chi phí tháng này | Tháng -1 | Tháng -2 | Tháng -3 | Ghi chú tag]

Bước 3 — Output mẫu AI trả về (minh họa)

Với bảng ở Bước 1, một output hợp lý mà AI có thể trả về:

Đây là dạng output rất hữu ích để bắt đầu cuộc họp review, không phải để copy-paste vào ticket và thực thi ngay. Dòng RDS trong ví dụ trên là minh chứng rõ nhất cho phần Cạm bẫy bên dưới.

Bước 4 — Truy vấn dữ liệu thô nếu cần đào sâu (CUR trên Athena)

Khi cần dữ liệu chi tiết hơn bảng tổng hợp ở trên (ví dụ để xác nhận resource ID cụ thể của EBS volume orphan), một câu Athena SQL điển hình trên AWS Cost and Usage Report:

SELECT
  line_item_resource_id,
  line_item_product_code,
  line_item_usage_type,
  SUM(line_item_unblended_cost) AS total_cost,
  MIN(line_item_usage_start_date) AS first_seen,
  MAX(line_item_usage_start_date) AS last_seen
FROM cur_database.cur_table
WHERE line_item_product_code = 'AmazonEC2'
  AND line_item_usage_type LIKE '%EBS:VolumeUsage%'
  AND line_item_usage_start_date >= date_add('month', -3, current_date)
GROUP BY line_item_resource_id, line_item_product_code, line_item_usage_type
ORDER BY total_cost DESC
LIMIT 50;

Kết quả của query này chính là dữ liệu thô để feed vào prompt ở Bước 2 khi cần phân tích ở resource-level thay vì service-level.

Cạm bẫy thường gặp

AI không biết ràng buộc nghiệp vụ — và sẽ đề xuất sai nếu bạn không kiểm tra. Trong ví dụ trên, dòng RDS được gắn mức rủi ro HIGH và có ghi chú "cần review trước khi thay đổi" — đó là vì prompt đã yêu cầu rõ. Nhưng nếu bạn quên yêu cầu điều đó, hoặc dùng một prompt sơ sài chỉ hỏi "đề xuất cắt giảm chi phí", AI hoàn toàn có thể trả về thẳng "downsize RDS xuống xlarge" mà không cảnh báo gì, trong khi thực tế instance đó đang chạy job đóng sổ kế toán cuối tháng vào đúng khung giờ CPU thấp trong ngày (utilization trung bình thấp không có nghĩa là idle — có thể là spike ngắn nhưng cực kỳ quan trọng). Downsize sai thời điểm này có thể gây timeout hoặc lock contention đúng lúc nghiệp vụ tài chính cần chạy ổn định nhất.

AI dễ nhầm resource "trông giống nhau" nhưng có vai trò khác nhau. Hai NAT Gateway cùng loại, cùng mức chi phí, nhưng một cái phục vụ VPC production, một cái phục vụ VPC staging đã bỏ hoang — nếu tag không rõ ràng hoặc AI chỉ nhìn theo usage type mà không đối chiếu kỹ resource ID/VPC ID, đề xuất "xóa NAT Gateway ít dùng" có thể nhắm nhầm mục tiêu. Luôn yêu cầu AI liệt kê resource ID cụ thể thay vì chỉ nói chung chung theo service.

Đề xuất không tính đến kế hoạch sắp tới. AI chỉ nhìn dữ liệu quá khứ (3 tháng gần nhất), không biết bạn sắp có một đợt scale-up cho campaign marketing tuần sau, hoặc sắp launch feature mới cần thêm capacity. Một RDS "over-provisioned" theo dữ liệu lịch sử có thể đã được provision có chủ đích để chuẩn bị cho load sắp tới. Đây là lý do cột "cần xác nhận thêm gì" trong prompt không phải chi tiết thừa — nó là bước bắt buộc trước khi bất kỳ thay đổi hạ tầng nào được áp dụng, và nên đi qua đúng quy trình IaC (terraform plan → review → apply) chứ không sửa tay trực tiếp trên console.

🧭 Góc nhìn Solutions Architect
Nếu một đề xuất cắt giảm chi phí không kèm theo câu trả lời cho "điều gì sẽ hỏng nếu tôi sai" thì đó chưa phải là đề xuất, mà mới là gợi ý cần điều tra thêm — bạn có đang review case đó ở mức tương xứng không?
Bạn có quy trình định kỳ (hàng tháng/hàng quý) để chạy lại phân tích cost breakdown này, hay nó chỉ được làm khi hóa đơn đã đủ đau để có người hỏi?
Resource "mồ côi" trong bảng của bạn hôm nay xuất hiện từ khâu nào trong vòng đời hạ tầng — thiếu cleanup script sau khi decommission, hay thiếu policy chặn tạo resource ngoài IaC ngay từ đầu?

🔗 Bài viết liên quan

• Bài 12: Microservices & AI — Domain, Service, Interface — kiến trúc microservices càng phân mảnh, cost breakdown theo service càng quan trọng để tránh lãng phí rải rác.
• Bài 18: Scalability Strategy — Sharding & Caching — right-sizing và cost optimization luôn phải cân bằng với chiến lược scale, không thể tách rời.

Bài trước: Microservices & AI · Bài tiếp theo: RAG for Engineering