[monitoring] CloudWatch
지금 시스템이 괜찮은지, 문제가 생기면 어떻게 알아챌지. 지표와 알람과 로그로 눈과 귀를 다는 법.
One-Line Summary
CloudWatch는 AWS 리소스와 애플리케이션의 지표(Metrics)·로그(Logs)·경보(Alarms) 를 한곳에서 모으고 감시하는 관측성(observability) 서비스다. 시험에서는 성능/운영 지표 모니터링 / 경보로 자동 조치(SNS·Auto Scaling) / 로그 수집·분석 / 메모리·디스크는 에이전트 필요 / "누가 무엇을 했나"인 CloudTrail과의 구분 이 핵심이다.
Why It Exists
수많은 리소스가 잘 돌고 있는지, 언제 문제가 생기는지 사람이 일일이 볼 수 없다. 지표를 모아 임계치를 넘으면 자동으로 알리고 조치하는 체계가 필요하다.
CloudWatch가 이 지표·로그·경보의 중심이다.
EC2/RDS/Lambda/ELB 등 -> 지표를 CloudWatch로 전송
-> Alarm이 임계치 감시 -> SNS 알림 / Auto Scaling 트리거 / 자동화 실행
로그 -> CloudWatch Logs로 수집 -> Logs Insights로 쿼리, Metric Filter로 지표화
시험 감각:
"리소스 성능/상태를 모니터링하고 임계치에서 조치" = CloudWatch.
Abbreviations
| 약어 | 풀네임 | 의미 |
|---|---|---|
Metric | Metric | 시간에 따른 측정값(CPU, 지연시간 등) |
Alarm | CloudWatch Alarm | 지표가 임계치를 넘으면 조치를 트리거 |
Logs | CloudWatch Logs | 로그를 수집·저장·조회하는 기능 |
Agent | CloudWatch Agent | 메모리·디스크·커스텀 지표/로그를 수집하는 에이전트 |
Logs Insights | CloudWatch Logs Insights | 로그를 쿼리로 분석하는 도구 |
구성 요소
| 요소 | 하는 일 |
|---|---|
| Metrics | 리소스 지표 수집·시각화 |
| Alarms | 임계치 초과 시 SNS/Auto Scaling/EC2 액션 트리거 |
| Logs | 로그 수집·보존·조회(보존 기간 설정 가능) |
| Dashboards | 지표를 한 화면에 시각화 |
| Metric Filter | 로그에서 특정 패턴을 지표로 변환(예: ERROR 개수) |
자주 틀리는 두 지점 (빈출)
1) 메모리·디스크 지표는 기본 제공이 아니다
EC2의 CPU·네트워크·디스크 I/O는 기본 수집되지만, 메모리 사용률·디스크 여유 공간(게스트 OS 내부 지표) 은 기본 제공되지 않는다. CloudWatch Agent를 설치해야 수집된다.
시험 감각:
"EC2 메모리 사용률을 모니터링하고 싶다" = CloudWatch Agent 설치.
2) 기본 vs 상세 모니터링
| 구분 | 수집 주기 |
|---|---|
| 기본(Basic) | 5분 간격(무료) |
| 상세(Detailed) | 1분 간격(추가 비용) |
시험 감각:
"1분 단위로 더 촘촘히 모니터링" = Detailed Monitoring.
CloudWatch vs CloudTrail (아주 빈출)
| 구분 | CloudWatch | CloudTrail |
|---|---|---|
| 무엇을 보나 | 성능/운영 지표·로그(무엇이 어떻게 동작하나) | API 호출 기록(누가 무엇을 언제 했나) |
| 대표 용도 | 모니터링·경보·오토스케일링 | 감사(audit)·보안·거버넌스·규정 준수 |
| 예시 질문 | "CPU가 임계치를 넘으면 알림" | "누가 이 S3 버킷을 삭제했나" |
시험 감각:
"누가 무엇을 했는지 감사 추적" = CloudTrail. "성능·상태 모니터링/경보" = CloudWatch.
Common Wrong Directions
| 오답 방향 | 왜 부족한가 |
|---|---|
| "누가 리소스를 바꿨나"를 CloudWatch로 | API 감사 기록은 CloudTrail |
| EC2 메모리/디스크 지표가 기본 있다고 가정 | CloudWatch Agent 필요 |
| 분산 마이크로서비스의 요청 병목 추적을 CloudWatch로 | 요청 추적은 X-Ray |
| 어떤 SQL이 DB 부하를 유발하는지 CloudWatch로 | DB 내부 부하 분석은 Performance Insights |
| 경보를 사람이 보고 수동 확장 | Alarm → Auto Scaling/SNS로 자동 조치 |
Exam Triggers
| 문제에서 이런 표현이 나오면 | 떠올릴 것 |
|---|---|
| "monitor metrics / set alarms / dashboards" | CloudWatch |
| "trigger Auto Scaling / notify via SNS on threshold" | CloudWatch Alarm |
| "collect and query application logs" | CloudWatch Logs (+ Logs Insights) |
| "monitor EC2 memory / disk usage" | CloudWatch Agent |
| "collect metrics every 1 minute" | Detailed Monitoring |
| "who made this API call / audit / compliance" | CloudWatch 아님 → CloudTrail |
| "trace requests across microservices" | CloudWatch 아님 → X-Ray |
Memory Sentence
CloudWatch는 지표·로그·경보의 중심으로, 임계치에서 SNS·Auto Scaling으로 자동 조치한다. 메모리·디스크는 에이전트가 있어야 수집되고, 촘촘한 감시는 Detailed Monitoring. "누가 무엇을 했나"는 CloudTrail, 요청 추적은 X-Ray, DB 부하 SQL은 Performance Insights.
References
댓글
아직 댓글이 없습니다.