기본 지표와 알람은 "이미 일어난 문제"를 알려준다. CPU가 90%를 찍었을 때 알람이 울리지만, 그땐 사용자가 이미 느려진 서비스를 경험한 뒤다. 모니터링의 다음 단계는 두 방향으로 진화한다. 하나는 더 깊게 — 가상 머신 단위가 아니라 컨테이너 하나하나, 애플리케이션 SLO 수준까지 내려가는 것이고, 다른 하나는 더 앞서 — 문제가 사용자에게 닿기 전에 합성 트래픽으로 먼저 감지하고, 정적 임계값 대신 ML이 학습한 정상 범위로 미묘한 이상을 잡아내는 것이다. CloudWatch의 고급 기능들 — Container Insights, Synthetics, Anomaly Detection, Dashboards — 은 정확히 이 "더 깊게, 더 앞서"라는 두 축 위에 있다.
DVA-C02 시험에서 이 영역은 "기본 CloudWatch로는 부족한 상황"의 답으로 나온다. ECS/EKS 컨테이너 모니터링, 엔드포인트 가용성의 능동적 확인, ML 기반 자동 임계값, 다중 계정 통합 뷰가 출제 포인트다. 이번 글은 컨테이너 모니터링이 왜 EC2 모니터링과 다른지, 합성 모니터링이 어떤 모니터링 철학의 전환인지, 그리고 Anomaly Detection이 통계적으로 무엇을 하는지를 깊이 들여다본다.
EC2 한 대를 모니터링하는 건 비교적 단순하다 — 인스턴스 하나에 지표가 붙는다