Mục tiêu bài học
Thiết lập visibility và cảnh báo trước khi chi phí trở thành bất ngờ cuối tháng.
Bài giảng chi tiết
Bài toán thực tế
Một account học tập có chi phí tăng nhưng team không biết service/project nào gây ra, và chỉ phát hiện khi nhận hóa đơn. Cần tách visibility, allocation và alert thay vì kỳ vọng budget tự dọn resource.
Đừng học nội dung này như một danh sách tên dịch vụ. Hãy đi theo chuỗi: requirement → khái niệm → quyết định → bằng chứng. Một câu trả lời tốt phải nói được vì sao lựa chọn phù hợp, phương án gần nhất bị loại ở đâu, và kiểm tra nào chứng minh lựa chọn đó hoạt động.
Khái niệm được giải thích theo scenario
- Cost Explorer phân tích cost/usage theo thời gian, service, account, tag và filter.
- AWS Budgets theo dõi actual/forecast và gửi alert; alert không tự động xóa resource.
- Cost allocation tags cần enable và dùng nhất quán; dữ liệu cost có độ trễ.
- Organizations/consolidated billing gom hóa đơn nhưng không thay thế ownership và budget control.
Ví dụ khi gặp một scenario mới, hãy thay các từ khóa trong đề bằng một hệ thống cụ thể: ai là người dùng, dữ liệu đi qua đâu, thành phần nào có thể lỗi, quyền nào cần có và điều gì phải được quan sát. Cách làm này giúp phân biệt các đáp án gần đúng thay vì chọn theo trí nhớ tên service.
flowchart LR
A[Scenario / requirement] --> B[Concept and boundary]
B --> C[Service or control choice]
C --> D[Evidence and trade-off]
D --> E[Failure variant]
Khái niệm cốt lõi
Cost Explorer phân tích cost/usage theo thời gian và filter. AWS Budgets đặt ngưỡng actual/forecast và gửi alert; alert không tự xóa mọi resource. Cost allocation tags giúp phân bổ theo team/project khi enable và dùng nhất quán. Consolidated billing gom hóa đơn trong Organizations.
Ví dụ giảng viên: phân loại một quyết định cloud
Cost control có ba lớp: visibility (Cost Explorer biết tiền đi đâu), allocation (tags/account/project biết ai sở hữu) và action (budget alert dẫn tới owner/runbook). Budget không phải circuit breaker; sau alert vẫn cần xác định resource, kiểm tra workload và quyết định stop/right-size/escalate.
Failure drill: tag bị thiếu, cost data trễ, forecast chưa vượt nhưng usage tăng đột biến, hoặc alert gửi tới mailbox không có owner. Viết thời gian phản ứng và evidence cần lưu cho mỗi trường hợp.
Thực hành có kiểm soát
Xác nhận Billing contact, tạo budget nhỏ cho account học tập và cấu hình email alert. Kiểm tra tag strategy trước khi tạo resource. Không đưa email thật hoặc số tiền thật vào source code.
Expected state và recovery
Trước khi thực hành, ghi rõ target/account/region, trạng thái hiện tại và output mong đợi. Sau thao tác, kiểm chứng bằng trạng thái thực tế hoặc command phù hợp; nếu kết quả sai, giữ lại evidence, quay về thay đổi nhỏ nhất và cleanup đúng owner. Không coi exit code 0 hoặc thông báo “success” là bằng chứng duy nhất.
- Phân biệt câu hỏi phân tích spend với câu hỏi cảnh báo forecast.
- Thiết kế được tag strategy có owner/project/environment.
- Giải thích budget alert không phải auto-remediation.
- Nêu action sau alert: identify, stop/delete, right-size hoặc escalate.
Bẫy đề thi và cách tự kiểm tra
“Analyze spend” → Cost Explorer. “Alert when forecast exceeds” → Budgets. Tags có độ trễ và phải được kích hoạt cho cost allocation.