Khi chạy workload trên EC2, CloudWatch mặc định chỉ cho mình một phần nhỏ bức tranh vận hành: CPU, network, disk I/O và status check. Nhưng trong thực tế DevOps/SRE, chỉ vậy là chưa đủ. Mình thường cần biết thêm memory đang dùng bao nhiêu, disk root còn trống không, process Nginx có còn chạy không, access log/error log có lỗi gì không, và khi vượt ngưỡng thì hệ thống có gửi cảnh báo hay không.

Bài lab này thực hành xây dựng một pipeline observability đơn giản nhưng thực tế cho EC2 theo hướng AWS-native bằng CloudWatch Agent.

Mình triển khai theo hai tình huống:

Case 1: EC2 đã có sẵn, đang chạy Nginx, nhưng chưa có CloudWatch Agent.
Case 2: Tạo EC2 mới từ đầu và bootstrap CloudWatch Agent bằng User Data.

Điểm quan trọng của bài không chỉ là "cài agent", mà là đi hết flow:

EC2
→ CloudWatch Agent
→ CloudWatch Metrics
→ CloudWatch Logs
→ CloudWatch Dashboard
→ CloudWatch Alarm
→ Amazon SNS
→ Email Notification

---

Vì sao cần CloudWatch Agent?

EC2 basic monitoring mặc định chỉ quan sát instance từ bên ngoài, chủ yếu thông qua hypervisor. Vì vậy CloudWatch có thể thấy các metric như CPU, network, disk I/O và status check.

Tuy nhiên, các thông tin nằm bên trong operating system như memory đang dùng bao nhiêu, filesystem còn trống bao nhiêu, application log ghi gì, hoặc process Nginx còn chạy hay không thì CloudWatch không tự thấy được nếu chỉ dùng basic monitoring.

CloudWatch Agent giải quyết khoảng trống đó bằng cách chạy bên trong EC2 instance. Agent đọc metrics và logs từ hệ điều hành, sau đó gửi dữ liệu về CloudWatch Metrics và CloudWatch Logs.

Nói ngắn gọn:

EC2 basic monitoring
→ nhìn từ bên ngoài instance

CloudWatch Agent
→ nhìn được bên trong operating system

Đây là lý do các dữ liệu như memory usage, disk usage, application logs và process status cần CloudWatch Agent.

---

Kiến trúc tổng quan

Trong kiến trúc này, EC2 chạy workload Nginx và CloudWatch Agent. Agent chạy bên trong instance, đọc metrics ở cấp operating system, đọc log file của Nginx, sau đó gửi dữ liệu về CloudWatch.

Luồng chính:

User / Local terminal
→ AWS Systems Manager Session Manager
→ EC2 instance
→ CloudWatch Agent
→ CloudWatch Metrics / CloudWatch Logs
→ Dashboard / Alarm
→ SNS Email Notification

Mình không dùng SSH trong bài lab này. EC2 được truy cập bằng AWS Systems Manager Session Manager, giúp không cần mở port 22, không cần key pair, và quản lý quyền truy cập thông qua IAM.

---

Repository structure

Phần evidence, architecture và script nên được tách riêng để dễ review:

cloudwatch-agent-ec2-observability/
├── architecture/
│   └── high-level-architecture.jpg
│
├── evidence/
│   ├── Case 1 - Existing EC2 Running.jpg
│   ├── Case 1 - IAM Role Attached.jpg
│   ├── Case 1 - SSM Managed Node.jpg
│   ├── Case 1 - CloudWatch Agent Installed.jpg
│   ├── Case 1 - Agent Running.jpg
│   ├── Case 1 - CWAgent Metrics.jpg
│   ├── Case 1 - CloudWatch Logs.jpg
│   ├── Case 1 - CloudWatch Alarm.jpg
│   ├── Case 1 - SNS Email Confirmed.jpg
│   ├── Case 1 - CloudWatch Dashboard.jpg
│   ├── Case 2 - New EC2 Running.jpg
│   ├── Case 2 - Agent Running.jpg
│   ├── Case 2 - Key CWAgent Metrics.jpg
│   ├── Case 2 - CloudWatch Log Groups.jpg
│   └── Case 2 - CloudWatch Dashboard.jpg
│
├── scripts/
│   ├── case1-cloudwatch-agent-config.json
│   ├── case2-user-data.sh
│   └── cleanup.sh
│
├── 01-cloudwatch-agent-lab-evidence.md
└── 01-aws-native-observability-for-ec2-with-cloudwatch-agent.md

File blog này chỉ giải thích flow và kết quả chính. Phần config dài của CloudWatch Agent và User Data được đặt trong thư mục scripts/ để dễ tái sử dụng.

---

Các AWS service sử dụng

Service	Vai trò
Amazon EC2	Máy chủ chạy workload Nginx
CloudWatch Agent	Thu thập metrics và logs từ bên trong EC2
CloudWatch Metrics	Lưu memory, disk, CPU và process metrics
CloudWatch Logs	Lưu Nginx access/error logs và system logs
CloudWatch Dashboard	Visualize các metrics quan trọng
CloudWatch Alarm	Cảnh báo khi metric vượt ngưỡng
Amazon SNS	Gửi email notification khi alarm được trigger
IAM Role	Cấp quyền cho EC2 gửi data lên CloudWatch
AWS Systems Manager	Truy cập EC2 bằng Session Manager thay vì SSH

---

Chi phí và Log Retention

CloudWatch Agent có thể phát sinh chi phí tùy theo số lượng custom metrics, số lượng log events, thời gian lưu logs và tần suất thu thập metrics.

Trong bài lab này, các metric như memory, disk và Nginx process count được gửi vào namespace CWAgent. Đây là custom metrics, vì vậy chi phí sẽ phụ thuộc vào số lượng metric, số lượng dimension và thời gian lưu trữ/quan sát.

Mình đặt metrics_collection_interval là 60 giây để cân bằng giữa độ chi tiết và chi phí:

metrics_collection_interval: 60

Nếu giảm interval xuống 10 giây, dữ liệu sẽ chi tiết hơn nhưng số lượng datapoint tăng lên, từ đó có thể làm tăng chi phí CloudWatch. Vì vậy trong lab hoặc môi trường nhỏ, 60 giây là lựa chọn hợp lý hơn.

Với CloudWatch Logs, nếu không cấu hình retention, log group có thể giữ log vô thời hạn. Vì vậy sau khi log group được tạo, nên đặt retention policy để tránh lưu log không cần thiết.

Ví dụ đặt retention 7 ngày cho Case 1:

aws logs put-retention-policy \
  --log-group-name "/ec2/cloudwatch-agent/case1/nginx/access" \
  --retention-in-days 7 \
  --region us-east-1

aws logs put-retention-policy \
  --log-group-name "/ec2/cloudwatch-agent/case1/nginx/error" \
  --retention-in-days 7 \
  --region us-east-1

Ví dụ đặt retention 7 ngày cho Case 2:

aws logs put-retention-policy \
  --log-group-name "/ec2/cloudwatch-agent/case2/nginx/access" \
  --retention-in-days 7 \
  --region us-east-1

aws logs put-retention-policy \
  --log-group-name "/ec2/cloudwatch-agent/case2/nginx/error" \
  --retention-in-days 7 \
  --region us-east-1

Trong production, retention nên được chọn theo nhu cầu audit, compliance và chi phí, ví dụ 7 ngày, 14 ngày, 30 ngày hoặc lâu hơn.

---

Chuẩn bị IAM Role cho EC2

CloudWatch Agent cần quyền để gửi metrics và logs về CloudWatch. EC2 cũng cần quyền để làm việc với Systems Manager Session Manager.

Mình tạo IAM Role cho EC2:

ec2-cloudwatch-agent-role

Attach hai managed policies:

CloudWatchAgentServerPolicy
AmazonSSMManagedInstanceCore

Ý nghĩa:

CloudWatchAgentServerPolicy
→ Cho phép CloudWatch Agent gửi metrics/logs lên CloudWatch.

AmazonSSMManagedInstanceCore
→ Cho phép EC2 xuất hiện trong Systems Manager và truy cập bằng Session Manager.

Evidence:

---

Kết nối vào EC2 bằng Session Manager

Thay vì SSH, mình dùng AWS CLI từ máy local để kết nối vào EC2:

aws ssm start-session \
  --target <id-instance-ec2-của-bạn> \
  --region us-east-1

Ví dụ:

aws ssm start-session \
  --target i-xxxxxxxxxxxxxxxxx \
  --region us-east-1

Sau khi vào được EC2, chuyển sang quyền root để thao tác trong lab:

sudo su -
whoami

Kiểm tra OS và hostname:

hostname
cat /etc/os-release

Cách này giúp bài lab không cần mở SSH port 22 ra Internet.

---

Case 1: Cài CloudWatch Agent trên EC2 đã có sẵn

Bối cảnh

Ở case đầu tiên, mình giả định đã có một EC2 đang chạy workload Nginx. Instance này chưa từng cài CloudWatch Agent. Đây là tình huống khá thực tế: hệ thống đã chạy rồi, sau đó team DevOps/SRE muốn bổ sung observability mà không rebuild instance.

Flow thực hiện:

Existing EC2
→ Attach IAM Role
→ Kiểm tra SSM Managed Node
→ Kiểm tra Nginx đang chạy
→ Xác nhận CloudWatch Agent chưa cài
→ Cài CloudWatch Agent
→ Tạo CloudWatch Agent config
→ Start CloudWatch Agent
→ Kiểm tra Metrics và Logs
→ Tạo Alarm, SNS và Dashboard

Kiểm tra EC2 hiện tại

Instance dùng trong Case 1:

Instance name: cwagent-existing-ec2
Instance ID: i-004d22f414fe421f0
AMI: Amazon Linux 2023
Instance type: t3.micro
VPC: CW-Agent-Ec2-vpc
Subnet: Public subnet us-east-1a
IAM Role: ec2-cloudwatch-agent-role

Evidence:

EC2 cũng đã xuất hiện trong AWS Systems Manager Managed Nodes với trạng thái Online.

Kiểm tra workload và trạng thái ban đầu

Sau khi kết nối vào EC2 bằng Session Manager, mình kiểm tra:

whoami
hostname
cat /etc/os-release
systemctl status nginx
rpm -qa | grep amazon-cloudwatch-agent

Kết quả:

User hiện tại: root
OS: Amazon Linux 2023
Nginx: active running
CloudWatch Agent: chưa được cài đặt

Evidence:

Điều này xác nhận đúng bối cảnh: EC2 đã có workload nhưng chưa có CloudWatch Agent.

Cài CloudWatch Agent

Cài package CloudWatch Agent trên Amazon Linux 2023:

sudo dnf install -y amazon-cloudwatch-agent

Kiểm tra package:

rpm -qa | grep amazon-cloudwatch-agent
ls -l /opt/aws/amazon-cloudwatch-agent/

Evidence:

Tạo CloudWatch Agent config

File config được đặt tại:

/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json

Full config được lưu trong repo tại: Case 1 - File Agent Config

Config này thu thập:

Metrics:
- mem_used_percent
- disk_used_percent
- cpu usage metrics
- Nginx process count qua procstat

Logs:
- /var/log/nginx/access.log
- /var/log/nginx/error.log

Phần quan trọng nhất của config là procstat và logs. procstat giúp CloudWatch Agent theo dõi process Nginx, còn phần logs giúp agent đọc log file trên EC2 và gửi lên CloudWatch Logs.

Ví dụ phần procstat:

{
  "procstat": [
    {
      "exe": "nginx",
      "measurement": [
        "pid_count",
        "cpu_usage",
        "memory_rss"
      ],
      "metrics_collection_interval": 60
    }
  ]
}

Ví dụ phần log collection cho Nginx access log:

{
  "file_path": "/var/log/nginx/access.log",
  "log_group_name": "/ec2/cloudwatch-agent/case1/nginx/access",
  "log_stream_name": "{instance_id}-access",
  "timezone": "UTC"
}

Mình không inline toàn bộ JSON config để bài viết gọn hơn, nhưng vẫn đưa các phần cốt lõi vào bài để người đọc hiểu agent đang collect gì. Full config nằm trong thư mục scripts/ để có thể copy và chạy lại.

Evidence:

Start CloudWatch Agent

Start agent với config vừa tạo:

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config \
  -m ec2 \
  -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json \
  -s

Kiểm tra trạng thái:

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a status
sudo systemctl status amazon-cloudwatch-agent

Kết quả mong đợi:

{
  "status": "running",
  "configstatus": "configured",
  "version": "1.300067.1"
}

Evidence:

---

Kiểm tra CloudWatch Metrics

Sau khi agent chạy, vào CloudWatch Metrics và tìm namespace:

CWAgent

Các metric chính được kiểm tra:

mem_used_percent
disk_used_percent
procstat_lookup_pid_count

Ý nghĩa:

mem_used_percent
→ phần trăm memory đang sử dụng.

disk_used_percent
→ phần trăm disk đã dùng ở filesystem `/`.

procstat_lookup_pid_count
→ số lượng process Nginx được CloudWatch Agent tìm thấy.

Vì sao Nginx Process Count có thể lớn hơn 1?

Metric procstat_lookup_pid_count cho biết số process Nginx mà CloudWatch Agent tìm thấy.

Với Nginx, giá trị này thường lớn hơn 1 vì Nginx thường chạy theo mô hình:

1 master process
+ N worker processes

Ví dụ nếu dashboard hiển thị:

Nginx Process Count = 3

Điều đó có thể hiểu là Nginx đang có 1 master process và 2 worker processes. Vì vậy giá trị 3 không phải lỗi, mà là trạng thái bình thường khi Nginx đang chạy nhiều worker.

Evidence:

---

Kiểm tra CloudWatch Logs

CloudWatch Agent cũng gửi Nginx logs lên CloudWatch Logs.

Log groups chính:

/ec2/cloudwatch-agent/case1/nginx/access
/ec2/cloudwatch-agent/case1/nginx/error

Nginx access log có request GET / HTTP/1.1, chứng minh log file trên EC2 đã được agent đọc và gửi lên CloudWatch Logs.

Evidence:

---

Tạo CloudWatch Alarm và SNS Email

Sau khi có metric memory, mình tạo CloudWatch Alarm trên metric:

Metric: mem_used_percent
Namespace: CWAgent
Condition: Greater than threshold
Action: Send notification to SNS topic

Trong lab, threshold được đặt thấp để dễ trigger alarm và lấy evidence. Với môi trường production, threshold nên đặt theo baseline thực tế, ví dụ khoảng 80% hoặc 85%.

Ngoài threshold, khi cấu hình alarm cần chú ý thêm các tham số sau:

Thuộc tính	Ý nghĩa
Period	Khoảng thời gian gom dữ liệu cho mỗi datapoint
Evaluation periods	Số datapoint được dùng để đánh giá alarm
Datapoints to alarm	Số datapoint cần vượt ngưỡng để chuyển sang ALARM
TreatMissingData	Cách xử lý khi metric không gửi dữ liệu

Nếu dùng cấu hình 1 out of 1 datapoint, alarm phản ứng nhanh nhưng dễ bị false alarm khi có spike ngắn.

Trong production, nên dùng nhiều evaluation periods hơn, ví dụ:

Period: 5 minutes
Evaluation periods: 3
Datapoints to alarm: 2 out of 3

Cấu hình này giúp giảm false alarm do spike tạm thời.

TreatMissingData cũng rất quan trọng. Nếu CloudWatch Agent ngừng gửi metric, alarm có thể chuyển sang hoặc bị kẹt ở trạng thái INSUFFICIENT_DATA, tùy cách cấu hình. Đây là một tình huống vận hành thực tế cần tính đến khi thiết kế monitoring.

Evidence alarm:

Sau đó tạo SNS topic và email subscription để nhận cảnh báo.

Evidence SNS:

Khi alarm chuyển trạng thái, email notification được gửi về mailbox. Đây là phần chứng minh alerting flow hoạt động end-to-end:

CloudWatch Metric
→ CloudWatch Alarm
→ SNS Topic
→ Email Notification

---

Tạo CloudWatch Dashboard

Dashboard giúp visualize các metrics quan trọng của EC2.

Dashboard name:

cwagent-existing-ec2-dashboard

Metrics hiển thị:

Memory Used Percent
Nginx Process Count
Disk Used Percent

Evidence:

Kết quả Case 1:

[✓] EC2 existing đang chạy workload Nginx
[✓] CloudWatch Agent được cài thủ công
[✓] Agent gửi metrics lên CloudWatch Metrics
[✓] Agent gửi logs lên CloudWatch Logs
[✓] Alarm được tạo và trigger
[✓] SNS gửi email notification
[✓] Dashboard hiển thị key metrics

---

Case 2: Bootstrap CloudWatch Agent khi tạo EC2 mới

Bối cảnh

Ở Case 2, mình không cài agent thủ công sau khi EC2 chạy nữa. Thay vào đó, mình dùng User Data để tự động:

Cài Nginx
→ Start Nginx
→ Cài CloudWatch Agent
→ Ghi CloudWatch Agent config
→ Start CloudWatch Agent
→ Tạo request test bằng curl localhost

Flow:

Launch new EC2
→ Attach IAM Role
→ User Data installs Nginx
→ User Data installs CloudWatch Agent
→ User Data writes config
→ User Data starts CloudWatch Agent
→ Verify Logs, Metrics and Dashboard

Chuẩn bị User Data

User Data script được lưu trong repo tại: Case 2 - User Data

Script này sẽ được copy vào phần:

EC2 Launch Instance
→ Advanced details
→ User data

User Data là phần cốt lõi của Case 2 vì nó giúp EC2 mới tự bootstrap observability ngay khi launch, thay vì phải SSH/SSM vào máy rồi cài thủ công.

Ý tưởng chính của User Data:

dnf update
→ install nginx
→ install amazon-cloudwatch-agent
→ enable/start nginx
→ write CloudWatch Agent config
→ start CloudWatch Agent
→ verify status

Một phần quan trọng của User Data:

#!/bin/bash
set -euxo pipefail

dnf update -y
dnf install -y nginx amazon-cloudwatch-agent

systemctl enable nginx
systemctl start nginx

echo "Bootstrap EC2 for CloudWatch Agent lab" > /usr/share/nginx/html/index.html

curl http://localhost || true
curl http://localhost || true
curl http://localhost || true

Đoạn trên đảm bảo EC2 mới được cài Nginx, start service và tự tạo một vài request test để sinh Nginx access log.

Phần tiếp theo trong User Data là ghi CloudWatch Agent config vào đúng đường dẫn trên EC2:

cat > /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json <<'EOF'
{
  "agent": {
    "metrics_collection_interval": 60,
    "run_as_user": "root"
  },
  "metrics": {
    "namespace": "CWAgent",
    "append_dimensions": {
      "InstanceId": "${aws:InstanceId}"
    }
  }
}
EOF

Trong file đầy đủ, phần config còn có thêm mem, disk, cpu, procstat và log collection cho Nginx/system logs. Mình chỉ inline một đoạn ngắn để người đọc hiểu User Data đang làm gì, còn full script được lưu trong thư mục scripts/.

Cuối cùng, User Data start CloudWatch Agent bằng lệnh:

/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config \
  -m ec2 \
  -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json \
  -s

systemctl enable amazon-cloudwatch-agent
systemctl restart amazon-cloudwatch-agent

Lệnh này giúp CloudWatch Agent đọc config vừa tạo và bắt đầu gửi metrics/logs lên CloudWatch ngay sau khi EC2 boot xong.

---

Launch EC2 mới

Instance dùng trong Case 2:

Instance name: cwagent-bootstrap-ec2
Instance ID: i-0dd7183a3899a9462
AMI: Amazon Linux 2023
Instance type: t3.micro
VPC: CW-Agent-Ec2-vpc
Subnet: Public subnet us-east-1a
IAM Role: ec2-cloudwatch-agent-role

Evidence:

Kiểm tra CloudWatch Agent

Sau khi EC2 boot xong, mình kết nối vào instance bằng Session Manager và kiểm tra agent:

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a status
sudo systemctl status amazon-cloudwatch-agent

Evidence:

Điều này chứng minh User Data đã tự động cài và start CloudWatch Agent khi EC2 được launch.

---

Kiểm tra CloudWatch Logs

Case 2 tạo các log groups riêng:

/ec2/cloudwatch-agent/case2/nginx/access
/ec2/cloudwatch-agent/case2/nginx/error
/ec2/cloudwatch-agent/case2/system/cloud-init
/ec2/cloudwatch-agent/case2/system/dnf

Nginx access log có request từ curl http://localhost, còn Nginx error log có startup logs của Nginx. Đây là chứng minh cho việc User Data đã chạy thành công và agent đã gửi logs lên CloudWatch.

Evidence:

---

Kiểm tra CloudWatch Metrics

Trong namespace CWAgent, mình kiểm tra ba metrics chính của instance Case 2:

mem_used_percent
disk_used_percent
procstat_lookup_pid_count

Evidence:

Kết quả này chứng minh EC2 mới được bootstrap bằng User Data đã tự động gửi metrics lên CloudWatch.

---

Tạo Dashboard cho Case 2

Dashboard name:

cwagent-bootstrap-ec2-dashboard

Widget hiển thị:

Memory Used Percent
Nginx Process Count
Disk Used Percent

Evidence:

Kết quả Case 2:

[✓] EC2 mới được tạo từ đầu
[✓] User Data chạy thành công
[✓] Nginx được cài và start tự động
[✓] CloudWatch Agent được cài và start tự động
[✓] Logs được gửi lên CloudWatch Logs
[✓] Metrics được gửi lên CloudWatch Metrics
[✓] Dashboard visualize được key metrics

---

So sánh hai cách triển khai

Tiêu chí	Case 1: Existing EC2	Case 2: New EC2 from scratch
Tình huống	EC2 đã có sẵn	EC2 tạo mới
Cách cài agent	Cài thủ công sau khi EC2 đang chạy	Cài tự động bằng User Data
Mục tiêu	Retrofit observability	Bootstrap observability
Phù hợp khi	Server đã chạy trong dev/prod	Muốn server mới có monitoring ngay từ đầu
Evidence chính	Agent running, metrics, logs, alarm, SNS, dashboard	User Data, agent running, logs, metrics, dashboard

Case 1 phù hợp khi mình đã có hệ thống chạy sẵn và muốn thêm observability mà không thay đổi cách launch instance.

Case 2 phù hợp khi mình muốn chuẩn hóa việc tạo EC2 mới: instance vừa boot lên là đã có Nginx, CloudWatch Agent, logs, metrics và dashboard-ready.

---

Bài học rút ra

CloudWatch Agent là phần rất quan trọng nếu muốn quan sát EC2 sâu hơn basic monitoring.

Không có CloudWatch Agent, mình chủ yếu thấy các metric bên ngoài instance như CPU, network, disk I/O và status check. Có CloudWatch Agent, mình lấy thêm được:

Memory usage
Disk usage theo filesystem
Application logs
System logs
Process status
Custom metrics trong namespace CWAgent

Một điểm quan trọng nữa là IAM Role nên được dùng thay vì access key. EC2 có role phù hợp thì CloudWatch Agent tự dùng quyền đó để gửi metrics/logs lên CloudWatch.

Bài lab cũng cho thấy Session Manager là lựa chọn tốt hơn SSH trong môi trường lab hoặc production cơ bản, vì không cần mở port 22 ra Internet.

---

Cleanup

Sau khi hoàn thành lab, cần cleanup để tránh phát sinh chi phí. Ngoài việc xóa EC2, dashboard, alarm và SNS, cần chú ý cả CloudWatch Log Groups vì log group có thể giữ log lâu dài nếu không đặt retention policy.

Terminate EC2 Case 1 nếu chỉ dùng cho lab
Terminate EC2 Case 2
Delete CloudWatch Dashboards
Delete CloudWatch Alarms
Delete SNS Topic
Delete CloudWatch Log Groups nếu không cần giữ
Delete IAM Role nếu chỉ dùng cho lab

---

Kết luận

Bài lab này xây dựng một observability pipeline AWS-native cho EC2 bằng CloudWatch Agent. Qua hai case, mình kiểm chứng được cả hai hướng triển khai:

Existing EC2
→ cài CloudWatch Agent thủ công
→ thêm observability cho workload đang chạy

New EC2
→ bootstrap bằng User Data
→ có observability ngay từ lúc launch

Khi kết hợp CloudWatch Agent với CloudWatch Metrics, CloudWatch Logs, Dashboard, Alarm và SNS, mình có thể tạo một hệ thống monitoring đơn giản, dễ hiểu, đủ thực tế cho môi trường DevOps cơ bản và có thể mở rộng tiếp cho các workload lớn hơn.