Monitoring, Audit & Performance

1. Ba dịch vụ, ba câu hỏi khác nhau

Khi hệ thống của bạn chạy trên AWS, có ba câu hỏi rất khác nhau mà bạn sẽ phải trả lời: “hệ thống đang chạy nhanh chậm thế nào?”, “ai đã gọi lệnh gì?”, và “cấu hình đã thay đổi ra sao và có đúng chuẩn không?”. Mỗi câu hỏi thuộc về một dịch vụ riêng:

Amazon CloudWatch — giám sát hiệu năng: metrics, logs, dashboard, alarm.
AWS CloudTrail — ghi lại lịch sử API call trong account, phục vụ governance, compliance và audit.
AWS Config — ghi lại thay đổi cấu hình của resource và đánh giá chúng theo các rule compliance.

Đề thi SAA-C03 rất thích đặt ba dịch vụ này cạnh nhau trong bốn phương án, nên phân biệt được chúng là phần quan trọng nhất của chương.

2. CloudWatch Metrics

CloudWatch cung cấp metrics cho mọi dịch vụ trong AWS. Một metric là một biến số được theo dõi, ví dụ CPUUtilization (mức dùng CPU) hay NetworkIn (lưu lượng mạng vào). Các metric được tổ chức thành namespace để không bị lẫn giữa các dịch vụ.

Dimension là một thuộc tính của metric (instance id, environment…) — tối đa 30 dimension cho mỗi metric.
Mỗi metric đều có timestamp.
Bạn có thể tạo CloudWatch dashboard từ các metric.
Bạn có thể tạo CloudWatch Custom Metrics — ví dụ để theo dõi RAM, thứ mà AWS không cung cấp sẵn.

CloudWatch Metric Streams

Metric Streams liên tục đẩy (stream) metric của CloudWatch tới một đích do bạn chọn, với độ trễ thấp và giao hàng gần real-time (near-real-time).

Đích có thể là Amazon Kinesis Data Firehose — và từ Firehose đi tiếp tới các đích của nó: Amazon S3 (rồi truy vấn bằng Athena), Amazon Redshift, Amazon OpenSearch.
Hoặc tới nhà cung cấp dịch vụ thứ ba: Datadog, Dynatrace, New Relic, Splunk, Sumo Logic…
Có tùy chọn filter để chỉ stream một tập con metric thay vì tất cả.

3. CloudWatch Logs

CloudWatch Logs là nơi tập trung log. Cấu trúc gồm hai tầng:

Log group — tên tùy ý, thường đại diện cho một ứng dụng.
Log stream — các instance trong ứng dụng đó, hoặc từng file log, từng container.

Bạn định nghĩa được log expiration policy (chính sách hết hạn log): không bao giờ hết hạn, hoặc từ 1 ngày tới 10 năm. Log được mã hóa mặc định, và bạn có thể bật mã hóa dựa trên KMS với khóa của riêng mình.

CloudWatch Logs gửi log đi được tới: Amazon S3 (dạng export), Kinesis Data Streams, Kinesis Data Firehose, AWS Lambda, và OpenSearch.

Log vào CloudWatch từ đâu

SDK, CloudWatch Logs Agent, CloudWatch Unified Agent.
Elastic Beanstalk — thu log từ ứng dụng.
ECS — thu log từ container.
AWS Lambda — thu log của function.
VPC Flow Logs — log riêng của VPC.
API Gateway.
CloudTrail — theo filter bạn đặt.
Route 53 — log các truy vấn DNS.

4. CloudWatch Logs Insights

CloudWatch Logs Insights dùng để tìm kiếm và phân tích dữ liệu log đang nằm trong CloudWatch Logs — ví dụ tìm một địa chỉ IP cụ thể trong log, hoặc đếm số lần xuất hiện chữ ERROR.

Có một ngôn ngữ query chuyên dụng riêng.
Tự động phát hiện (discover) các field từ dịch vụ AWS và từ log event dạng JSON.
Cho phép lấy đúng field cần, filter theo điều kiện, tính thống kê tổng hợp (aggregate statistics), sắp xếp event, giới hạn số event trả về…
Query lưu lại được và gắn vào CloudWatch Dashboard.
Query được nhiều Log Group ở nhiều AWS account khác nhau.

5. Đưa log ra ngoài: Export vs Subscriptions

Hai cách đưa log ra khỏi CloudWatch Logs, khác nhau về độ trễ — và đây là một cặp rất hay bị hỏi.

S3 Export

Dữ liệu log có thể mất tới 12 giờ mới sẵn sàng để export.
API để gọi là CreateExportTask.
Không phải near-real-time hay real-time — nếu cần nhanh thì dùng Logs Subscriptions.

Logs Subscriptions

CloudWatch Logs Subscriptions cho bạn log event real-time để xử lý và phân tích:

Gửi tới Kinesis Data Streams, Kinesis Data Firehose, hoặc Lambda.
Subscription Filter quyết định log nào được chuyển tới đích.
Theo diagram của slide: qua Kinesis Data Streams là đường real-time (từ đó đi tiếp tới Kinesis Data Firehose, Kinesis Data Analytics, EC2, Lambda…), còn qua Kinesis Data Firehose là đường near real-time (đi tới OpenSearch Service, Amazon S3…).

Gom log nhiều account, nhiều region

Slide mô tả một kiến trúc gom log tập trung: mỗi account/region (ví dụ ACCOUNT A – REGION 1, ACCOUNT B – REGION 2, ACCOUNT B – REGION 3) đặt một Subscription Filter trên CloudWatch Logs của mình, tất cả đẩy vào một Kinesis Data Streams chung, rồi từ đó qua Kinesis Data Firehose xuống Amazon S3 theo kiểu near real-time.

Để làm được xuyên account, Subscriptions hỗ trợ Cross-Account Subscription — gửi log event tới resource ở một AWS account khác (đích là KDS hoặc KDF). Cơ chế theo diagram:

Account gửi (ví dụ 111111111111) có CloudWatch Logs + Subscription Filter, trỏ tới một Subscription Destination.
Account nhận (ví dụ 999999999999) có Kinesis Data Streams (ví dụ RecipientStream) và một Destination Access Policy.
Một IAM Role cross-account được account gửi assume, và policy cho phép PutRecord vào stream của account nhận.

6. Log của EC2 và các Agent

Mặc định, không có log nào từ máy EC2 của bạn tự đi vào CloudWatch. Bạn phải chạy một CloudWatch agent trên EC2 để đẩy những file log mà bạn muốn lên, và phải đảm bảo quyền IAM đúng. Agent này cũng cài được trên server on-premises.

Có hai phiên bản agent, dành cho máy chủ ảo (EC2 instance, server on-premises…):

Agent	Khả năng
CloudWatch Logs Agent	Phiên bản cũ. Chỉ gửi được tới CloudWatch Logs
CloudWatch Unified Agent	Thu thêm metric ở tầng hệ thống (RAM, process…), thu log gửi lên CloudWatch Logs, và cấu hình tập trung được qua SSM Parameter Store

Metric mà Unified Agent thu được

Các metric sau được thu trực tiếp trên Linux server / EC2 instance của bạn:

CPU — active, guest, idle, system, user, steal.
Disk metrics — free, used, total; và Disk IO — writes, reads, bytes, iops.
RAM — free, inactive, used, total, cached.
Netstat — số kết nối TCP và UDP, số packet mạng, số byte.
Processes — total, dead, blocked, idle, running, sleep.
Swap Space — free, used, used %.

7. CloudWatch Alarms

Alarm dùng để kích hoạt thông báo cho bất kỳ metric nào, với nhiều tùy chọn tính toán (sampling, %, max, min…).

Ba trạng thái của alarm:

OK — trong ngưỡng bình thường.
INSUFFICIENT_DATA — không đủ dữ liệu để đánh giá.
ALARM — đã vượt ngưỡng.

Period là độ dài khoảng thời gian (tính bằng giây) để đánh giá metric. Với high resolution custom metrics, period có thể là 10 giây, 30 giây, hoặc bội số của 60 giây.

Alarm làm được gì (Alarm Targets)

Stop, Terminate, Reboot, hoặc Recover một EC2 Instance.
Kích hoạt một Auto Scaling Action.
Gửi thông báo tới SNS — từ SNS thì bạn làm được gần như mọi thứ.

Composite Alarms

Một CloudWatch Alarm thường chỉ theo dõi một metric duy nhất. Composite Alarm thì theo dõi trạng thái của nhiều alarm khác, kết hợp bằng điều kiện AND và OR. Lợi ích là giảm “alarm noise” (tiếng ồn báo động) — thay vì bị bắn 10 thông báo rời rạc, bạn chỉ nhận một cảnh báo khi đúng tổ hợp điều kiện xảy ra. Ví dụ trong slide: CW Alarm A theo dõi CPU, CW Alarm B theo dõi IOPS của một EC2 instance; chỉ khi cả hai vào trạng thái ALARM thì Composite Alarm mới bắn tới Amazon SNS.

EC2 Instance Recovery

Một ứng dụng rất cụ thể của alarm. EC2 có ba loại Status Check:

Instance status — kiểm tra bản thân máy ảo EC2.
System status — kiểm tra phần cứng vật lý bên dưới.
Attached EBS status — kiểm tra các volume EBS đang gắn vào.

Bạn tạo một CloudWatch Alarm trên metric StatusCheckFailed_System để tự động thực hiện EC2 Instance Recovery, đồng thời gửi cảnh báo qua SNS Topic. Điểm quan trọng: sau khi recovery, instance giữ nguyên Private IP, Public IP, Elastic IP, metadata và placement group.

Vài điều nên biết

Alarm tạo được dựa trên CloudWatch Logs Metrics Filters — tức là từ một mẫu xuất hiện trong log (ví dụ ERROR) sinh ra metric, rồi từ metric đó dựng alarm rồi bắn SNS.
Để test alarm và notification, bạn ép trạng thái alarm sang ALARM bằng CLI:

aws cloudwatch set-alarm-state --alarm-name "myalarm" --state-value ALARM --state-reason "testing purposes"

8. Amazon EventBridge

Amazon EventBridge (tên cũ là CloudWatch Events) là dịch vụ định tuyến sự kiện. Nó hoạt động theo hai kiểu trigger:

Schedule — cron job, tức script chạy theo lịch. Ví dụ: mỗi giờ chạy một script trên Lambda function.
Event Pattern — rule phản ứng khi một dịch vụ làm điều gì đó. Ví dụ: có sự kiện IAM Root User Sign in thì gửi SNS Topic kèm email thông báo.

Từ đó nó kích hoạt Lambda function, gửi message SQS/SNS…

Rule: nguồn và đích

Slide liệt kê rất rõ hai đầu của một EventBridge rule. Nguồn (source) ví dụ:

EC2 Instance (ví dụ Start Instance), CodeBuild (ví dụ build lỗi), S3 Event (ví dụ upload object), Trusted Advisor (ví dụ có finding mới), CloudTrail (bất kỳ API call nào), và Schedule or Cron (ví dụ mỗi 4 giờ).

Event đi qua EventBridge dưới dạng JSON, có thể được filter (không bắt buộc):

{
  "version": "0",
  "id": "6a7e8feb-b491",
  "detail-type": "EC2 Instance State-change Notification"
}

Đích (destination) được nhóm theo mục đích:

Nhóm	Đích
Compute	Lambda, AWS Batch, ECS Task
Integration	SQS, SNS, Kinesis Data Streams
Orchestration	Step Functions, CodePipeline, CodeBuild
Maintenance	SSM, EC2 Actions

Event bus, archive và replay

Event bus có thể được truy cập từ các AWS account khác thông qua Resource-based Policies.
Bạn có thể archive event (tất cả hoặc theo filter) gửi vào một event bus — lưu vĩnh viễn hoặc theo một khoảng thời gian đặt trước.
Và có khả năng replay các event đã archive.

Có ba loại bus: Default Event Bus (nhận event từ các dịch vụ AWS), Partner Event Bus (nhận từ các đối tác SaaS của AWS), và Custom Event Bus (nhận từ ứng dụng của bạn).

Schema Registry

EventBridge có thể phân tích các event trong bus của bạn và suy ra schema của chúng. Schema Registry cho phép sinh code cho ứng dụng, để ứng dụng biết trước dữ liệu trong event bus có cấu trúc thế nào. Schema có thể được version hóa.

Resource-based Policy

Dùng để quản lý quyền cho một Event Bus cụ thể — ví dụ cho phép hoặc chặn event đến từ một AWS account hay một AWS region khác. Use case tiêu biểu: gom toàn bộ event của cả AWS Organization về một AWS account hoặc một region duy nhất. Trong diagram, account 123456789012 gọi PutEvents vào central-event-bus của account 111122223333, và bus đó kích hoạt một Lambda function.

9. Bốn loại CloudWatch Insights

CloudWatch có một họ tính năng “Insights” phục vụ observability, rất dễ lẫn tên với nhau.

Container Insights

Thu thập, tổng hợp và tóm tắt metric và log từ container. Hỗ trợ container chạy trên:

Amazon Elastic Container Service (Amazon ECS).
Amazon Elastic Kubernetes Services (Amazon EKS).
Các nền tảng Kubernetes trên EC2.
Fargate (cho cả ECS và EKS).

Riêng với Amazon EKS và Kubernetes, CloudWatch Insights dùng một bản container hóa của CloudWatch Agent để tự phát hiện các container.

Lambda Insights

Giải pháp monitoring và troubleshooting cho ứng dụng serverless chạy trên AWS Lambda:

Thu thập, tổng hợp và tóm tắt metric ở tầng hệ thống: CPU time, memory, disk, network.
Thu thập thông tin chẩn đoán như cold start và việc Lambda worker shutdown.
Được cung cấp dưới dạng một Lambda Layer.

Contributor Insights

Phân tích dữ liệu log và tạo ra time series thể hiện dữ liệu theo contributor (tác nhân đóng góp):

Xem metric về top-N contributor, tổng số contributor duy nhất và mức sử dụng của họ.
Giúp tìm ra “top talker” và hiểu ai/cái gì đang ảnh hưởng tới hiệu năng hệ thống.
Hoạt động với mọi log do AWS sinh ra (VPC, DNS…).
Ví dụ: tìm host xấu, xác định người dùng mạng nặng nhất, hoặc tìm URL sinh ra nhiều lỗi nhất.
Bạn tự viết rule từ đầu, hoặc dùng sample rule AWS đã tạo sẵn (chúng khai thác CloudWatch Logs của bạn). CloudWatch còn có built-in rule để phân tích metric từ các dịch vụ AWS khác.

Diagram minh họa: VPC Flow Logs → CloudWatch Logs → Contributor Insights → danh sách Top-10 IP addresses.

Application Insights

Cung cấp dashboard tự động chỉ ra các vấn đề tiềm tàng của ứng dụng đang được giám sát, giúp khoanh vùng sự cố đang diễn ra.

Ứng dụng phải chạy trên Amazon EC2 Instance với một số công nghệ nhất định: Java, .NET, Microsoft IIS Web Server, database…
Có thể kèm các resource AWS khác: Amazon EBS, RDS, ELB, ASG, Lambda, SQS, DynamoDB, S3 bucket, ECS, EKS, SNS, API Gateway…
Được SageMaker hỗ trợ bên dưới.
Tăng khả năng nhìn thấy sức khỏe ứng dụng, giảm thời gian troubleshoot và sửa lỗi.
Finding và alert được gửi tới Amazon EventBridge và SSM OpsCenter.

10. AWS CloudTrail

AWS CloudTrail cung cấp governance, compliance và audit cho AWS Account của bạn, và được bật mặc định. Nó cho bạn lịch sử các event / API call thực hiện trong account, bất kể đến từ đâu: Console, SDK, CLI, hay chính các dịch vụ AWS.

Log của CloudTrail có thể đưa vào CloudWatch Logs hoặc S3.
Một trail áp dụng cho tất cả Region (mặc định) hoặc chỉ một Region.
Theo diagram: IAM User & IAM Role tác động qua SDK / CLI / Console, CloudTrail ghi lại, và bạn kiểm tra & audit qua CloudTrail Console, đồng thời log chảy sang CloudWatch Logs và S3 Bucket.

Các loại CloudTrail Event

Management Events — các thao tác thực hiện lên resource trong account:

Ví dụ: cấu hình bảo mật (AttachRolePolicy của IAM), cấu hình rule định tuyến dữ liệu (CreateSubnet của Amazon EC2), thiết lập logging (CreateTrail của AWS CloudTrail).
Mặc định trail được cấu hình để log management event.
Tách được Read Events (không làm thay đổi resource) khỏi Write Events (có thể làm thay đổi resource).

Data Events — các thao tác lên chính dữ liệu:

Mặc định data event KHÔNG được log, vì đây là các thao tác khối lượng rất lớn.
Hoạt động ở cấp object của Amazon S3 (GetObject, DeleteObject, PutObject) — cũng tách được Read và Write.
Hoạt động thực thi function của AWS Lambda (API Invoke).

CloudTrail Insights Events — xem ngay mục dưới.

CloudTrail Insights

Bật CloudTrail Insights để phát hiện hoạt động bất thường trong account:

Provisioning resource sai/không chính xác.
Chạm ngưỡng service limit.
Bùng nổ (bursts) các hành động AWS IAM.
Khoảng trống (gaps) trong các hoạt động bảo trì định kỳ.

Cách hoạt động: CloudTrail Insights phân tích các management event bình thường để tạo baseline, sau đó liên tục phân tích write event để phát hiện mẫu bất thường. Khi có anomaly: nó hiện trong CloudTrail console, event được gửi vào Amazon S3, và một EventBridge event được sinh ra để bạn tự động hóa xử lý.

Thời gian lưu event

Event được lưu 90 ngày trong CloudTrail.
Muốn giữ lâu hơn, hãy log chúng vào S3 rồi dùng Athena để phân tích — áp dụng cho cả Data Events, Management Events và Insights Events.

EventBridge + CloudTrail

Vì CloudTrail ghi mọi API call và EventBridge có thể lấy CloudTrail làm nguồn, hai dịch vụ này ghép thành một cơ chế chặn/đánh chặn API call rất mạnh. Ba ví dụ trong slide:

Người dùng gọi DeleteTable trên DynamoDB → CloudTrail ghi lại → EventBridge sinh event → SNS gửi cảnh báo.
Người dùng gọi AssumeRole trên một IAM Role → CloudTrail → EventBridge → SNS.
Người dùng sửa inbound rule của một Security Group (AuthorizeSecurityGroupIngress trên EC2) → CloudTrail → EventBridge → SNS.

11. AWS Config

AWS Config giúp bạn audit và ghi lại compliance của các resource AWS, cũng như ghi lại cấu hình và các thay đổi theo thời gian. Những câu hỏi mà AWS Config trả lời được:

Có security group nào cho phép SSH không giới hạn (unrestricted SSH access) không?
Các bucket của tôi có bucket nào đang public không?
Cấu hình ALB của tôi đã thay đổi thế nào theo thời gian?

Các điểm vận hành cần nhớ:

Nhận được alert (SNS notification) cho bất kỳ thay đổi nào.
AWS Config là dịch vụ theo từng region (per-region), nhưng có thể tổng hợp (aggregate) xuyên region và xuyên account.
Có thể lưu dữ liệu cấu hình vào S3 rồi phân tích bằng Athena.

Config Rules

Dùng AWS managed config rules — hơn 75 rule sẵn có.
Hoặc viết custom config rule — bắt buộc phải định nghĩa trong AWS Lambda. Ví dụ: đánh giá xem mỗi đĩa EBS có phải loại gp2; đánh giá xem mỗi EC2 instance có phải t2.micro.
Rule được đánh giá / kích hoạt: theo từng lần thay đổi cấu hình, và/hoặc theo khoảng thời gian định kỳ.
Quan trọng: AWS Config Rules không ngăn hành động xảy ra — không có cơ chế deny.
Giá: không có free tier; $0.003 cho mỗi configuration item được ghi trên mỗi region, và $0.001 cho mỗi lần đánh giá config rule trên mỗi region.

Xem theo từng resource

Với một resource cụ thể, AWS Config cho bạn xem theo thời gian: compliance của resource đó, cấu hình của nó, và cả các CloudTrail API call liên quan tới nó.

Remediations — tự động sửa

Bạn có thể tự động hóa việc sửa các resource không tuân thủ (non-compliant) bằng SSM Automation Documents:

Dùng AWS-Managed Automation Document có sẵn, hoặc tự tạo custom Automation Document.
Mẹo trong slide: custom Automation Document có thể gọi một Lambda function.
Đặt được Remediation Retries nếu resource vẫn non-compliant sau khi auto-remediation chạy.

Ví dụ trong diagram: một IAM Access Key đã hết hạn bị đánh dấu NON_COMPLIANT; AWS Config kích hoạt Auto-Remediation Action là SSM Document AWSConfigRemediation-RevokeUnusedIAMUserCredentials với Retries: 5, và key bị vô hiệu hóa.

Notifications

Hai đường thông báo:

Dùng EventBridge để kích hoạt thông báo khi resource AWS ở trạng thái NON_COMPLIANT — từ EventBridge đi tới Lambda, SNS, SQS…
Hoặc gửi trực tiếp thay đổi cấu hình và trạng thái compliance tới SNS. Đường này gửi tất cả event, nên nếu chỉ muốn một phần thì dùng SNS Filtering hoặc filter ở phía client.

12. Phân biệt CloudWatch vs CloudTrail vs Config

Đây là slide quan trọng nhất của chương — hãy nhớ đúng ba vai trò:

Dịch vụ	Vai trò
CloudWatch	Giám sát hiệu năng (metric, CPU, network…) & dashboard · Event & alerting · Gom và phân tích log
CloudTrail	Ghi lại API call do mọi người thực hiện trong account · Định nghĩa được trail cho resource cụ thể · Là Global Service
Config	Ghi lại thay đổi cấu hình · Đánh giá resource theo rule compliance · Cho timeline của thay đổi và compliance

Ví dụ cùng một resource: Elastic Load Balancer

Slide kết chương bằng cách soi cùng một ELB qua ba dịch vụ, và đây chính là cách đề thi hay hỏi:

CloudWatch — theo dõi metric số kết nối đến (Incoming connections); trực quan hóa tỉ lệ % các error code theo thời gian; dựng dashboard để nắm hiệu năng của load balancer.
Config — theo dõi các security group rule của Load Balancer; theo dõi thay đổi cấu hình của Load Balancer; đảm bảo Load Balancer luôn có SSL certificate được gán (compliance).
CloudTrail — theo dõi ai đã thay đổi Load Balancer, thông qua các API call.

Tóm tắt nhanh

Chủ đề	Cần nhớ
CloudWatch Metrics	Mọi dịch vụ đều có metric; tối đa 30 dimension mỗi metric; Custom Metrics cho những thứ AWS không cấp sẵn, ví dụ RAM
Metric Streams	Đẩy metric near real-time tới các đích của Kinesis Data Firehose hoặc nhà cung cấp thứ ba, có filter tùy chọn
CloudWatch Logs	Log group (ứng dụng) chứa log stream (instance / file / container); mã hóa mặc định, tùy chọn KMS; hạn lưu 1 ngày – 10 năm
Logs Insights	Query engine với ngôn ngữ riêng trên log đã lưu; nhiều log group, nhiều account; không phải real-time
Export vs Subscriptions	`CreateExportTask` sang S3 mất tới 12 giờ; cần real-time thì dùng subscription tới KDS, KDF hoặc Lambda
Agent	Logs Agent bản cũ chỉ gửi log; Unified Agent thêm metric RAM, disk, netstat, process và cấu hình tập trung qua SSM Parameter Store
Alarm	Ba trạng thái `OK` / `INSUFFICIENT_DATA` / `ALARM`; đích là EC2 action, Auto Scaling action và SNS; Composite Alarm ghép nhiều alarm bằng AND/OR
EC2 Instance Recovery	Alarm trên `StatusCheckFailed_System`; recovery giữ nguyên Private IP, Public IP, Elastic IP, metadata và placement group
EventBridge	Schedule (cron) hoặc event pattern; archive + replay event; Resource-based Policy trên bus để gom event cả Organization; Schema Registry suy ra và version hóa schema
Họ Insights	Container (ECS/EKS/Fargate) · Lambda (một Lambda Layer) · Contributor (top-N từ CloudWatch Logs) · Application (dashboard tự động, chạy bằng SageMaker)
CloudTrail	Bật mặc định, global; Management Events log mặc định, Data Events thì không; event lưu 90 ngày, muốn lâu hơn thì đẩy sang S3 + Athena; Insights phát hiện write activity bất thường
AWS Config	Per-region nhưng aggregate được; hơn 75 managed rule, custom rule viết bằng Lambda; không chặn được hành động; remediation qua SSM Automation Document
Chọn dịch vụ	Hiệu năng → CloudWatch · ai làm gì → CloudTrail · cấu hình thay đổi và có đúng chuẩn không → Config