Giám sát hệ thống trên AWS

1. CloudWatch Metrics

Khi vận hành hệ thống trên cloud, bạn cần biết “sức khỏe” của từng thành phần đang như thế nào: CPU có đang quá tải không, dung lượng ổ đĩa còn bao nhiêu, ứng dụng có đang trả lời chậm không… Đó chính là vai trò của Amazon CloudWatch — dịch vụ giám sát trung tâm của AWS, cung cấp số liệu (metric) cho HẦU HẾT các dịch vụ AWS mà bạn đang sử dụng.

Một metric (số liệu/chỉ số) là một biến số mà bạn muốn theo dõi theo thời gian — ví dụ CPUUtilization (mức sử dụng CPU), NetworkIn (lưu lượng mạng đi vào)… Mỗi metric đều có một dấu thời gian (timestamp) gắn liền với từng giá trị đo được, cho phép bạn vẽ biểu đồ biến động của nó theo thời gian.

CloudWatch cho phép bạn tạo dashboard (bảng điều khiển trực quan) để hiển thị nhiều metric cùng lúc trên một màn hình duy nhất — ví dụ một dashboard hiển thị biểu đồ chi phí (billing metric) đang tăng theo thời gian trong tháng.

Một số nhóm metric quan trọng cần nhớ:

• EC2 instance: CPU Utilization (mức sử dụng CPU), Status Checks (kiểm tra tình trạng instance), Network (lưu lượng mạng vào/ra). Lưu ý: CloudWatch KHÔNG tự động theo dõi RAM (bộ nhớ) của EC2 — đây là điểm dễ gây nhầm lẫn. Muốn giám sát RAM, bạn phải tự cài agent và gửi custom metric.
• Tần suất đo mặc định: mỗi 5 phút một lần. Nếu cần độ chi tiết cao hơn, có thể bật Detailed Monitoring (tốn thêm phí — biểu tượng “$$$”) để đo mỗi 1 phút một lần.
• EBS volume: Disk Read/Writes (số lượt đọc/ghi đĩa).
• S3 bucket: BucketSizeBytes (dung lượng bucket), NumberOfObjects (số lượng object), AllRequests (tổng số request).
• Billing: Total Estimated Charge (tổng chi phí ước tính) — lưu ý metric này chỉ khả dụng tại Region us-east-1.
• Service Limits: theo dõi mức độ bạn đang sử dụng gần đến ngưỡng giới hạn (quota) của API một dịch vụ nào đó.
• Custom metrics: bạn có thể tự định nghĩa và đẩy (push) số liệu riêng của mình lên CloudWatch — ví dụ số lượng đơn hàng xử lý mỗi phút trong ứng dụng của bạn.

Lưu ý khi thi

Đề thi rất hay “gài” chi tiết: CloudWatch mặc định KHÔNG giám sát RAM/memory usage của EC2 instance, chỉ có CPU, Network, Status Checks. Muốn có metric RAM, disk space bên trong OS, log ứng dụng… bạn PHẢI tự cài CloudWatch Agent.

2. CloudWatch Alarms

Có metric là chưa đủ — bạn cần một cơ chế để hệ thống TỰ ĐỘNG phản ứng khi có điều gì bất thường xảy ra, mà không cần con người phải ngồi canh màn hình 24/7. Đó là vai trò của CloudWatch Alarms (cảnh báo).

Một Alarm được gắn với một metric cụ thể, và bạn định nghĩa một ngưỡng (threshold) — ví dụ “CPU Utilization vượt quá 80% trong 5 phút liên tục”. Khi điều kiện này xảy ra, Alarm sẽ kích hoạt một hành động (action). Các hành động phổ biến gồm:

• Auto Scaling action: tự động tăng hoặc giảm số lượng (“desired count”) EC2 instance trong một Auto Scaling Group.
• EC2 action: tự động stop (tắt), terminate (xóa), reboot (khởi động lại), hoặc recover (khôi phục) một EC2 instance.
• SNS notification: gửi thông báo vào một SNS topic — ví dụ để gửi email/SMS cảnh báo cho quản trị viên (đây chính là điểm liên kết trực tiếp với Amazon SNS mà bạn đã học ở chương trước).

Khi cấu hình Alarm, bạn có nhiều lựa chọn về cách tính toán giá trị để so sánh với ngưỡng — ví dụ dùng giá trị trung bình (average), phần trăm (percentage), giá trị lớn nhất (max), nhỏ nhất (min)… và bạn cũng chọn được khoảng thời gian (period) để đánh giá điều kiện của alarm (ví dụ đánh giá mỗi 1 phút, 5 phút…).

Một alarm luôn ở một trong ba trạng thái (Alarm States):

• OK: giá trị metric đang nằm trong ngưỡng bình thường.
• ALARM: giá trị metric đã vượt ngưỡng đã đặt, cảnh báo đang được kích hoạt.
• INSUFFICIENT_DATA: chưa có đủ dữ liệu để xác định trạng thái (ví dụ metric mới bắt đầu được thu thập).

Ví dụ thực tế

Bạn có thể tạo một “billing alarm” (cảnh báo chi phí) trên metric Total Estimated Charge — ví dụ đặt ngưỡng 50 USD. Khi tổng chi phí AWS trong tháng vượt qua 50 USD, Alarm chuyển sang trạng thái ALARM và tự động gửi một thông báo qua SNS đến email của bạn, giúp bạn phát hiện sớm việc chi tiêu vượt dự kiến trước khi hóa đơn cuối tháng “gây bất ngờ”.

Lưu ý khi thi

Billing alarm chỉ có thể được tạo dựa trên metric Total Estimated Charge tại Region us-east-1, và bạn phải bật tùy chọn “Receive Billing Alerts” trong Billing Preferences trước khi có thể tạo alarm này.

3. CloudWatch Logs

Ngoài các số liệu (metric) và cảnh báo (alarm), CloudWatch còn có một thành phần quan trọng khác: CloudWatch Logs — nơi tập trung lưu trữ log (nhật ký hoạt động) từ nhiều nguồn khác nhau trong hệ thống AWS của bạn, giúp bạn không phải “chạy vào từng server” để xem log riêng lẻ.

CloudWatch Logs có thể thu thập log từ nhiều nguồn, bao gồm:

• Elastic Beanstalk: tự động thu thập log từ ứng dụng được triển khai qua Elastic Beanstalk.
• ECS (Elastic Container Service): thu thập log từ các container đang chạy.
• AWS Lambda: thu thập log từ các function serverless.
• CloudTrail: dựa theo bộ lọc (filter) mà bạn định nghĩa, có thể đưa các sự kiện CloudTrail vào CloudWatch Logs để dễ tìm kiếm và cảnh báo.
• CloudWatch Logs Agent: chạy trên EC2 instance hoặc server on-premises để đẩy log từ máy chủ đó lên CloudWatch.
• Route 53: ghi log các truy vấn DNS (log DNS queries).

CloudWatch Logs cho phép giám sát log theo thời gian thực (real-time monitoring), và bạn có thể điều chỉnh (adjustable) thời gian lưu trữ (retention) của log — ví dụ giữ log 30 ngày, 90 ngày, 1 năm, hoặc vĩnh viễn, tùy theo nhu cầu vận hành và tuân thủ (compliance) của tổ chức.

CloudWatch Logs cho EC2

Một điểm rất quan trọng và thường bị hiểu nhầm: theo mặc định (by default), KHÔNG có bất kỳ log nào từ một EC2 instance được tự động gửi lên CloudWatch Logs. Việc thu thập metric CPU/Network là tự động, nhưng thu thập log file bên trong instance thì KHÔNG tự động.

Để đưa log từ EC2 vào CloudWatch, bạn cần:

• Tự cài đặt và chạy CloudWatch Agent trên EC2 instance đó.
• Cấu hình agent để chỉ định chính xác những file log nào cần được đẩy lên.
• Đảm bảo instance có quyền IAM phù hợp (thường là một IAM Role gắn vào EC2 instance) để agent có thể gửi dữ liệu log lên CloudWatch Logs.

Điều thú vị là CloudWatch Log Agent không chỉ dùng được cho EC2 — nó còn có thể được cài đặt trên các server chạy on-premises (tại trung tâm dữ liệu riêng của doanh nghiệp), giúp bạn tập trung log của cả hệ thống hybrid (vừa cloud vừa on-premises) vào một nơi duy nhất.

Lưu ý khi thi

Nhớ kỹ: EC2 metrics cơ bản (CPU, Network, Status Check) tự động có sẵn trong CloudWatch, nhưng log file bên trong EC2 KHÔNG tự động xuất hiện — phải cài CloudWatch Agent và cấp quyền IAM Role tương ứng.

4. Amazon EventBridge

Amazon EventBridge (trước đây gọi là CloudWatch Events) là dịch vụ giúp bạn xây dựng các “luật” (rule) để hệ thống tự động phản ứng khi có một sự kiện nào đó xảy ra, hoặc chạy theo một lịch trình định sẵn. Có hai kiểu kích hoạt (trigger) chính:

• Schedule (Lịch trình): giống như cron job — chạy một script/hành động theo lịch định kỳ, ví dụ “mỗi giờ một lần” hoặc “mỗi 4 giờ”.
• Event Pattern (Mẫu sự kiện): định nghĩa luật để phản ứng ngay khi một dịch vụ AWS nào đó thực hiện một hành động cụ thể — ví dụ ngay khi có ai đăng nhập bằng tài khoản Root.

Khi luật được kích hoạt, EventBridge có thể gọi (trigger) một AWS Lambda function, hoặc gửi message vào SQS/SNS để các hệ thống khác xử lý tiếp.

Ví dụ minh họa:

• Sự kiện “IAM Root User Sign in” (tài khoản Root đăng nhập) → EventBridge phát hiện → gửi vào SNS Topic → SNS gửi Email cảnh báo ngay cho quản trị viên bảo mật.
• Lịch trình “Mỗi giờ” → EventBridge tự động kích hoạt một Lambda function chạy một đoạn script định kỳ (ví dụ dọn dẹp dữ liệu cũ).

EventBridge Rules

EventBridge có thể lắng nghe sự kiện từ rất nhiều nguồn (source), ví dụ:

• EC2 Instance (ví dụ: instance vừa được khởi động - Start Instance).
• CodeBuild (ví dụ: một lượt build bị lỗi).
• S3 (ví dụ: có object mới được upload).
• Trusted Advisor (ví dụ: có phát hiện/khuyến nghị mới - new Finding).
• CloudTrail (bất kỳ lệnh gọi API nào).
• Schedule/Cron (ví dụ mỗi 4 giờ).

Và có thể gửi đến rất nhiều loại đích (destination) khác nhau, chia theo nhóm:

Nhóm	Ví dụ đích (destination)
Compute	Lambda, AWS Batch, ECS Task
Integration	SQS, SNS, Kinesis Data Streams
Orchestration	Step Functions, CodePipeline, CodeBuild
Maintenance	Systems Manager (SSM), EC2 Actions

Tính năng nâng cao

• Schema Registry: cho phép mô hình hóa (model) cấu trúc (schema) của các sự kiện, giúp lập trình viên biết chính xác định dạng dữ liệu của một event.
• Archive & Replay: có thể lưu trữ (archive) toàn bộ hoặc một phần (theo filter) các sự kiện đã gửi tới một event bus — lưu vô thời hạn hoặc theo một khoảng thời gian nhất định — và sau đó có khả năng “phát lại” (replay) các sự kiện đã lưu trữ, rất hữu ích khi cần debug lại một sự cố đã xảy ra trong quá khứ.
• Các loại Event Bus:
  • Default Event Bus: nhận sự kiện từ các dịch vụ AWS.
  • Partner Event Bus: nhận sự kiện từ các đối tác SaaS của AWS.
  • Custom Event Bus: dành cho các ứng dụng tự viết (custom app) của riêng bạn.

Lưu ý khi thi

Phân biệt rõ: CloudWatch Alarms phản ứng dựa trên NGƯỠNG của một METRIC; EventBridge phản ứng dựa trên SỰ KIỆN cụ thể (một hành động API nào đó xảy ra) hoặc LỊCH TRÌNH. Đừng nhầm lẫn hai khái niệm này khi đề thi mô tả tình huống.

5. AWS CloudTrail

AWS CloudTrail là dịch vụ cung cấp khả năng quản trị (governance), tuân thủ (compliance) và kiểm toán (audit) cho toàn bộ tài khoản AWS của bạn. Nói một cách đơn giản: CloudTrail giống như một “camera giám sát” ghi lại MỌI hành động đã được thực hiện trong tài khoản AWS — ai đã làm gì, từ đâu, vào lúc nào.

Điểm cực kỳ quan trọng: CloudTrail được bật (enabled) theo mặc định ngay khi bạn tạo tài khoản AWS — bạn không cần phải tự kích hoạt nó.

CloudTrail ghi lại lịch sử của các sự kiện/lệnh gọi API (event/API calls) được thực hiện trong tài khoản AWS của bạn, thông qua bất kỳ phương thức nào:

• AWS Management Console (giao diện web).
• AWS SDK (thư viện lập trình).
• AWS CLI (command line).
• Các dịch vụ AWS khác gọi lẫn nhau.

Bạn có thể đưa log từ CloudTrail vào CloudWatch Logs hoặc lưu trữ vào Amazon S3 để phân tích hoặc lưu trữ lâu dài. Một “trail” (đường mòn ghi log) có thể được áp dụng cho All Regions (mọi vùng — đây là lựa chọn mặc định) hoặc chỉ một Region cụ thể.

Sơ đồ hoạt động tổng quát: các hành động được thực hiện qua SDK/CLI/Console bởi IAM User & IAM Role → được CloudTrail ghi nhận → hiển thị trên CloudTrail Console để bạn kiểm tra (inspect) và kiểm toán (audit) → đồng thời log có thể chảy tiếp vào CloudWatch Logs hoặc lưu vào S3 Bucket.

Ngoài bản thân CloudTrail, còn một tính năng đi kèm cần nhớ tên: CloudTrail Insights — phân tích tự động các sự kiện CloudTrail của bạn để phát hiện hoạt động bất thường (ví dụ số lệnh gọi API tăng vọt so với mức bình thường). Bạn không phải tự dò từng dòng log, Insights tự chỉ ra chỗ lệch chuẩn.

Lưu ý khi thi

Đây là một trong những câu “must-know” của đề thi:

nếu có một tài nguyên (resource) bị xóa một cách bất thường trong tài khoản AWS, việc đầu tiên cần làm là kiểm tra CloudTrail

để biết ai/cái gì đã gọi API xóa tài nguyên đó, vào lúc nào, từ địa chỉ IP hoặc IAM identity nào.

Ví dụ thực tế

Một buổi sáng, một EC2 instance quan trọng của công ty bất ngờ biến mất. Quản trị viên vào CloudTrail, tìm kiếm sự kiện “TerminateInstances” trong vài giờ gần nhất, và phát hiện ra chính xác IAM User nào đã gọi API này, vào lúc nào, từ địa chỉ IP nào — từ đó xác định được đây là lỗi do một script tự động cấu hình sai, không phải bị tấn công.

6. AWS X-Ray

Hãy nghĩ về cách gỡ lỗi (debug) ứng dụng theo kiểu truyền thống: kiểm thử (test) ở máy local, thêm các dòng log (log statement) rải rác khắp code, rồi triển khai (deploy) lại lên production để xem có sửa được lỗi chưa. Cách này có nhiều vấn đề:

• Định dạng log (log format) khác nhau giữa các ứng dụng khác nhau, khiến việc phân tích log rất khó khăn và tốn thời gian.
• Với một ứng dụng nguyên khối (monolith) duy nhất, việc debug còn “dễ” vì mọi thứ nằm trong một chỗ. Nhưng với kiến trúc microservice — hàng chục dịch vụ nhỏ gọi qua lại lẫn nhau — việc debug trở nên RẤT khó, vì lỗi có thể xuất phát từ bất kỳ đâu trong chuỗi các lệnh gọi.
• Bạn không có một “cái nhìn tổng thể” (common view) về toàn bộ kiến trúc và luồng xử lý của một request khi nó đi qua nhiều dịch vụ khác nhau.

AWS X-Ray ra đời để giải quyết chính xác vấn đề này — nó cung cấp khả năng phân tích trực quan (visual analysis) cho ứng dụng của bạn, vẽ ra sơ đồ (map) thể hiện một request đã “đi qua” những dịch vụ nào, mất bao lâu ở mỗi bước, và ở đâu xảy ra lỗi.

Các lợi ích cụ thể mà X-Ray mang lại:

• Tìm ra các điểm nghẽn hiệu năng (troubleshooting performance bottlenecks).
• Hiểu rõ các mối quan hệ phụ thuộc (dependencies) giữa các service trong kiến trúc microservice.
• Xác định chính xác dịch vụ nào đang gặp vấn đề (pinpoint service issues).
• Xem lại hành vi của từng request cụ thể (review request behavior).
• Tìm ra lỗi (error) và ngoại lệ (exception) trong hệ thống.
• Kiểm tra xem hệ thống có đang đáp ứng đúng SLA (Service Level Agreement) về thời gian phản hồi hay không.
• Phát hiện những nơi request bị giới hạn tốc độ (throttled).
• Xác định những người dùng cụ thể nào đang bị ảnh hưởng bởi sự cố.

Ví dụ thực tế

Một ứng dụng thương mại điện tử gồm 6 microservice (giỏ hàng, thanh toán, kho hàng, giao hàng…). Khách hàng phàn nàn thanh toán chậm. Nhờ AWS X-Ray, kỹ sư có thể xem “bản đồ” toàn bộ request đi qua các service, và phát hiện ngay rằng riêng bước gọi đến Fraud Service đang mất 4 giây — trong khi các bước khác chỉ mất vài chục milli-giây — từ đó khoanh vùng chính xác nơi cần tối ưu, thay vì phải dò từng service một cách mù quáng.

Lưu ý khi thi

Từ khóa nhận diện X-Ray: “trace requests”, “microservices”, “distributed application”, “pinpoint bottleneck”. Đây là công cụ TRUY VẾT LUỒNG XỬ LÝ của một request, khác hẳn với CloudTrail (truy vết API CALL của người dùng/IAM identity) và CloudWatch (theo dõi METRIC/LOG).

7. Amazon CodeGuru

Amazon CodeGuru là dịch vụ sử dụng Machine Learning (ML) để tự động rà soát code (automated code reviews) và đưa ra khuyến nghị về hiệu năng ứng dụng (application performance recommendations). CodeGuru có hai thành phần chính, phục vụ hai giai đoạn khác nhau trong vòng đời phát triển phần mềm:

Thành phần	Giai đoạn sử dụng	Chức năng chính
CodeGuru Reviewer	Trong quá trình phát triển (development), lúc Build & Test	Rà soát code tĩnh (static code analysis), đưa ra khuyến nghị có thể hành động ngay (actionable recommendations)
CodeGuru Profiler	Khi ứng dụng đang chạy thật (runtime, production)	Cho thấy hiệu năng thực tế và đề xuất cải thiện chi phí/tốc độ

Luồng làm việc tổng quát: Coding (viết code) → Build & Test (CodeGuru Reviewer tham gia rà soát code, đưa ra khuyến nghị ngay tại bước này) → Deploy (triển khai) → Measure (CodeGuru Profiler tham gia đo lường, tìm cơ hội cải thiện hiệu năng và chi phí khi ứng dụng đã chạy thật trong production).

CodeGuru Reviewer

Giúp phát hiện các vấn đề nghiêm trọng trong code như: lỗ hổng bảo mật (security vulnerabilities), các lỗi khó phát hiện (hard-to-find bugs). Ví dụ các loại vấn đề nó có thể tìm ra: không tuân thủ các “coding best practices” phổ biến, rò rỉ tài nguyên (resource leaks — ví dụ quên đóng kết nối database), các lỗ hổng an ninh, thiếu kiểm tra đầu vào (input validation).

CodeGuru Reviewer sử dụng Machine Learning và automated reasoning (suy luận tự động), được huấn luyện dựa trên hàng triệu lượt rà soát code thực tế từ hàng nghìn repository mã nguồn mở và các repository nội bộ của Amazon — tức là nó mang theo “kinh nghiệm” tích lũy được từ rất nhiều dự án thực tế. Hiện tại CodeGuru Reviewer hỗ trợ ngôn ngữ Java và Python, và có thể tích hợp trực tiếp với GitHub, Bitbucket, và AWS CodeCommit.

CodeGuru Profiler

Giúp bạn hiểu hành vi thực tế (runtime behavior) của ứng dụng khi nó đang chạy trong môi trường thật. Ví dụ, CodeGuru Profiler có thể phát hiện ra rằng ứng dụng của bạn đang tiêu tốn CPU một cách bất thường chỉ vì một đoạn code ghi log (logging routine) không hiệu quả.

Các tính năng chính của CodeGuru Profiler:

• Xác định và loại bỏ các điểm code kém hiệu quả (code inefficiencies).
• Cải thiện hiệu năng ứng dụng (ví dụ giảm mức sử dụng CPU).
• Giảm chi phí tính toán (decrease compute costs).
• Cung cấp bản tổng hợp heap (heap summary) để xác định object nào đang chiếm nhiều bộ nhớ nhất.
• Có khả năng phát hiện bất thường (Anomaly Detection).
• Hỗ trợ cả ứng dụng chạy trên AWS và chạy on-premises.
• Gây rất ít ảnh hưởng (minimal overhead) đến hiệu năng của ứng dụng đang giám sát.

Lưu ý khi thi

Ghi nhớ đơn giản:

Reviewer = rà soát CODE lúc PHÁT TRIỂN

(trước khi chạy);

Profiler = theo dõi HIỆU NĂNG lúc ỨNG DỤNG ĐANG CHẠY THẬT

(production). Đừng nhầm hai thành phần này với nhau.

8. AWS Health Dashboard

AWS Health Dashboard thực chất gồm hai trang/khái niệm khác nhau, dễ gây nhầm lẫn nếu không phân biệt rõ:

Health Dashboard – Service History

Đây là trang hiển thị tình trạng hoạt động (health) của TẤT CẢ các dịch vụ AWS, ở TẤT CẢ các Region — tức là một cái nhìn tổng quan chung cho toàn bộ nền tảng AWS, không riêng cho tài khoản của bạn. Trang này:

• Hiển thị thông tin lịch sử (historical information) cho từng ngày.
• Có sẵn một RSS feed mà bạn có thể đăng ký theo dõi để nhận thông báo khi có sự cố dịch vụ.

Health Dashboard – Your Account

Trong khi Service Health Dashboard cho biết tình trạng chung của cả nền tảng AWS, Account Health Dashboard lại cung cấp góc nhìn CÁ NHÂN HÓA (personalized view) — nó cho bạn biết chính xác các tài nguyên (resources) trong tài khoản CỦA BẠN đang bị ảnh hưởng như thế nào bởi các sự cố/sự kiện của AWS.

Các đặc điểm của Account Health Dashboard:

• Cung cấp cảnh báo (alerts) và hướng dẫn khắc phục (remediation guidance) khi AWS đang gặp sự cố có thể ảnh hưởng đến bạn.
• Hiển thị thông tin liên quan và kịp thời (relevant/timely info) để giúp bạn quản lý các sự cố đang diễn ra.
• Cung cấp thông báo chủ động (proactive notification) cho các hoạt động đã được lên lịch (scheduled activities) — ví dụ AWS thông báo trước về việc bảo trì (maintenance) sắp diễn ra ảnh hưởng đến một EC2 instance của bạn.
• Có thể tổng hợp (aggregate) dữ liệu từ toàn bộ một AWS Organization (nhiều tài khoản AWS được quản lý tập trung).
• Đây là một dịch vụ toàn cục (global service).

Tiêu chí	Service Health Dashboard	Account (Personal) Health Dashboard
Phạm vi	Toàn bộ AWS, tất cả khách hàng	Riêng tài khoản/Organization của bạn
Nội dung	Tình trạng chung các dịch vụ, mọi Region	Sự kiện AWS ảnh hưởng trực tiếp đến resource của bạn
Tính chủ động	Không cá nhân hóa	Cảnh báo, khắc phục, thông báo bảo trì chủ động

Lưu ý khi thi

Câu hỏi hay hỏi phân biệt hai dashboard này: nếu đề bài nói về “tình trạng chung của AWS trên toàn thế giới” → Service Health Dashboard; nếu nói về “AWS thông báo riêng cho tài khoản của tôi rằng resource X sẽ bị ảnh hưởng” → Account (Personal) Health Dashboard.

9. CloudWatch vs CloudTrail vs X-Ray

Đây là một trong những nhóm câu hỏi dễ gây nhầm lẫn nhất trong đề thi CLF-C02, vì cả ba dịch vụ đều liên quan đến “giám sát” nhưng lại trả lời ba câu hỏi hoàn toàn khác nhau. Hãy dùng phép ví von sau để nhớ: nếu hệ thống AWS của bạn là một cơ thể sống, thì:

• CloudWatch giống như máy đo huyết áp, nhịp tim, nhiệt độ — nó trả lời câu hỏi “Hệ thống đang hoạt động (performance) như thế nào?” (CPU bao nhiêu %, có bao nhiêu request/giây, log ứng dụng ghi gì…).
• CloudTrail giống như sổ ghi chép mọi hành động của từng người trong nhà — nó trả lời câu hỏi “AI đã làm gì, khi nào?” (ai gọi API nào, xóa cái gì, sửa cấu hình gì).
• X-Ray giống như máy chụp X-quang theo dõi đường đi của một viên thuốc trong cơ thể — nó trả lời câu hỏi “MỘT request cụ thể đã đi qua đường nào, mất bao lâu ở mỗi trạm?” trong một kiến trúc nhiều service.

Dịch vụ	Trả lời câu hỏi	Đối tượng theo dõi
CloudWatch	Hiệu năng, tài nguyên đang thế nào?	Metric, Log, Alarm, Event của dịch vụ AWS
CloudTrail	Ai đã gọi API gì, khi nào?	Lịch sử hành động/API call trong tài khoản
X-Ray	Một request đi qua service nào, chậm ở đâu?	Luồng xử lý (trace) của từng request trong ứng dụng phân tán

Ví dụ thực tế

Một website bị chậm bất thường vào buổi trưa. Bạn dùng

CloudWatch

để thấy CPU của EC2 đang tăng cao; dùng

X-Ray

để phát hiện chính bước gọi tới một API bên thứ ba đang mất 3 giây; và dùng

CloudTrail

để kiểm tra xem có ai vừa thay đổi cấu hình Security Group hay Auto Scaling Group trước khi sự cố xảy ra không. Ba công cụ bổ trợ cho nhau để có cái nhìn đầy đủ về sự cố.

Tổng kết chương

• CloudWatch Metrics: theo dõi số liệu hiệu năng của dịch vụ AWS và chi phí; EC2 mặc định không có metric RAM.
• CloudWatch Alarms: tự động hành động (Auto Scaling, EC2 action, SNS) khi metric vượt ngưỡng; có 3 trạng thái OK / ALARM / INSUFFICIENT_DATA.
• CloudWatch Logs: thu thập log tập trung từ Lambda, ECS, Elastic Beanstalk, Route 53…; log EC2 cần tự cài Agent, không tự động.
• Amazon EventBridge: phản ứng theo lịch trình (schedule/cron) hoặc theo sự kiện (event pattern), kích hoạt Lambda, SQS, SNS, Step Functions…
• AWS CloudTrail: kiểm toán mọi API call trong tài khoản, bật sẵn theo mặc định; là công cụ đầu tiên cần tra khi có resource bị xóa bất thường. CloudTrail Insights phân tích tự động các sự kiện đó để phát hiện hoạt động bất thường.
• AWS X-Ray: trực quan hóa và truy vết luồng xử lý request qua các microservice, tìm bottleneck, lỗi, và SLA.
• Amazon CodeGuru: Reviewer rà soát code lúc phát triển (Java/Python); Profiler theo dõi hiệu năng runtime trong production.
• AWS Health Dashboard: Service Health Dashboard cho tình trạng chung AWS; Account Health Dashboard cá nhân hóa theo tài khoản/Organization của bạn.