Mục tiêu bài học
Phân biệt “hệ thống đang thế nào?” với “ai đã gọi API nào?”.
Bài giảng chi tiết
Bài toán thực tế
Một incident report cần trả lời hai câu hỏi khác nhau: hệ thống có đang quá tải không và ai đã xóa security group rule. Dùng một dashboard cho cả hai sẽ bỏ sót audit identity hoặc operational signal.
Đừ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
- CloudWatch thu thập metrics/logs/events, tạo alarm và hỗ trợ phản ứng vận hành.
- CloudTrail ghi API activity cùng identity, event name, time và source context phục vụ audit.
- Metric trả lời “hệ thống đang thế nào”; audit event trả lời “ai đã gọi API nào”.
- Retention, delivery và cost của logs cần được thiết kế, không bật vô hạn mặc định.
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
CloudWatch thu thập metrics, logs và events; alarm có thể thông báo hoặc trigger action. CloudTrail ghi API activity và management events phục vụ audit/điều tra. CloudTrail không phải dashboard CPU; CloudWatch không thay audit log identity.
Ví dụ giảng viên: phân loại một quyết định cloud
CloudWatch và CloudTrail trả lời hai loại câu hỏi khác nhau. CloudWatch cho biết runtime signal như CPU, latency, error rate, log pattern và alarm state. CloudTrail cho biết API actor, action, resource, timestamp và context. Incident tốt thường nối cả hai: metric báo sự cố, CloudTrail cho biết thay đổi nào xảy ra trước đó.
Failure drill: alarm không có owner/action, CloudTrail event thiếu retention, log chứa secret, metric không có dimension đúng và alert quá nhiễu. Viết runbook gồm signal, threshold, first command, escalation và cleanup/cost review.
Thực hành có kiểm soát
Tìm một CloudTrail event và đọc userIdentity, eventName, sourceIPAddress, eventTime. Tìm metric/alarm của workload có sẵn và ghi câu hỏi mỗi nguồn trả lời. Không bật log retention dài hạn mà chưa tính chi phí.
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.
- Xác định đúng service cho CPU threshold và API identity.
- Đọc được các field chính của CloudTrail event.
- Phân biệt log/metric/alarm với audit event.
- Nêu retention/cost implication trước khi bật log dài hạn.
Bẫy đề thi và cách tự kiểm tra
“Ai đã gọi DeleteBucket?” → CloudTrail. “CPU vượt threshold?” → CloudWatch alarm. Production thường cần cả hai.