CloudWatch 완벽 가이드: 메트릭, 경보, 로그 모니터링
Amazon CloudWatch의 메트릭, 경보, 로그, 대시보드를 활용하여 AWS 인프라를 모니터링하는 방법을 알아봅니다.
관련 시험 도메인
- Domain 2: Design Resilient Architectures
핵심 요약 (BLUF)
Amazon CloudWatch는 AWS 리소스의 메트릭을 수집하고, 경보를 설정하고, 로그를 중앙 관리하는 모니터링 서비스입니다. EC2 기본 모니터링은 5분, 상세 모니터링은 1분 간격이며, 메모리/디스크 메트릭은 CloudWatch 에이전트가 필요합니다.
시험 팁
시험 핵심: "성능 모니터링 = CloudWatch", "API 감사 = CloudTrail", "구성 변경 추적 = AWS Config". EC2 메모리/디스크는 기본 메트릭에 포함되지 않음!
CloudWatch 핵심 구성 요소
[Amazon CloudWatch]
│
├── 메트릭 (Metrics)
│ ├── AWS 서비스 기본 메트릭
│ └── 커스텀 메트릭
│
├── 경보 (Alarms)
│ ├── 메트릭 경보
│ └── 복합 경보
│
├── 로그 (Logs)
│ ├── 로그 그룹 / 로그 스트림
│ └── Logs Insights (쿼리)
│
├── 대시보드 (Dashboards)
│
└── Events / EventBridge
메트릭 (Metrics)
EC2 기본 메트릭
| 메트릭 | 설명 | 기본 제공 |
|---|---|---|
| CPUUtilization | CPU 사용률 | ✅ |
| NetworkIn/Out | 네트워크 트래픽 | ✅ |
| DiskReadOps/WriteOps | 디스크 I/O 작업 수 | ✅ |
| StatusCheckFailed | 상태 검사 실패 | ✅ |
| MemoryUtilization | 메모리 사용률 | ❌ 에이전트 필요 |
| DiskSpaceUtilization | 디스크 사용량 | ❌ 에이전트 필요 |
시험 팁
시험 빈출: EC2의 메모리 사용률과 디스크 공간은 기본 메트릭에 포함되지 않습니다. CloudWatch 에이전트를 설치하여 커스텀 메트릭으로 수집해야 합니다.
기본 모니터링 vs 상세 모니터링
| 항목 | 기본 모니터링 | 상세 모니터링 |
|---|---|---|
| 수집 간격 | 5분 | 1분 |
| 비용 | 무료 | 유료 |
| 활성화 | 기본 | 수동 활성화 |
| 사용 사례 | 일반 모니터링 | Auto Scaling 빠른 반응 |
커스텀 메트릭
CloudWatch 에이전트 또는 API로 커스텀 메트릭 전송:
aws cloudwatch put-metric-data \
--namespace "MyApp" \
--metric-name "ActiveUsers" \
--value 150 \
--unit Count
→ 해상도: 표준 (60초) 또는 고해상도 (1초)
→ 고해상도 메트릭은 추가 비용 발생
주요 서비스별 메트릭
| 서비스 | 주요 메트릭 |
|---|---|
| EC2 | CPUUtilization, StatusCheck, NetworkIn/Out |
| RDS | CPUUtilization, FreeableMemory, ReadIOPS |
| ELB | RequestCount, HealthyHostCount, Latency |
| Lambda | Invocations, Duration, Errors, Throttles |
| S3 | BucketSizeBytes, NumberOfObjects |
| SQS | ApproximateNumberOfMessages, ApproximateAgeOfOldestMessage |
경보 (Alarms)
경보 상태
3가지 상태:
┌─────────┐ ┌─────────┐ ┌──────────────────┐
│ OK │ → │ ALARM │ → │ INSUFFICIENT_DATA │
│ (정상) │ │ (경보) │ │ (데이터 부족) │
└─────────┘ └─────────┘ └──────────────────┘
경보 작업
| 작업 | 설명 |
|---|---|
| SNS 알림 | 이메일, SMS, Lambda 트리거 |
| Auto Scaling | 스케일 아웃/인 트리거 |
| EC2 작업 | 인스턴스 중지, 종료, 재부팅, 복구 |
경보 설정 예시:
메트릭: CPUUtilization
조건: 5분 동안 평균 > 80%
작업:
ALARM → SNS 알림 + Auto Scaling 스케일 아웃
OK → SNS 알림 (정상 복구 알림)
복합 경보 (Composite Alarm)
여러 경보를 AND/OR로 결합:
복합 경보: "서비스 장애"
= CPU 경보 (ALARM)
AND 에러율 경보 (ALARM)
AND 지연 시간 경보 (ALARM)
→ 3가지 모두 ALARM일 때만 알림
→ 경보 소음(alarm noise) 감소
로그 (CloudWatch Logs)
구조
CloudWatch Logs 계층:
┌─────────────────────────┐
│ 로그 그룹 (Log Group) │ ← /aws/lambda/my-function
│ ┌───────────────────┐ │
│ │ 로그 스트림 1 │ │ ← 인스턴스/컨테이너별
│ │ 로그 스트림 2 │ │
│ │ 로그 스트림 3 │ │
│ └───────────────────┘ │
│ 보존 기간: 1일 ~ 영구 │
└─────────────────────────┘
로그 소스
| 소스 | 설정 방법 |
|---|---|
| EC2 | CloudWatch 에이전트 설치 |
| Lambda | 자동 (IAM 권한만 필요) |
| ECS/Fargate | awslogs 로그 드라이버 |
| API Gateway | 스테이지 설정에서 활성화 |
| CloudTrail | CloudWatch Logs 통합 |
| Route 53 | DNS 쿼리 로그 |
| VPC Flow Logs | VPC 설정에서 활성화 |
Logs Insights
CloudWatch Logs Insights 쿼리 예시:
# 최근 1시간 에러 로그 조회
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 20
# Lambda 함수 p99 지연 시간
filter @type = "REPORT"
| stats percentile(@duration, 99) as p99
by bin(1h)
로그 내보내기
CloudWatch Logs → S3: 배치 내보내기 (실시간 ❌)
CloudWatch Logs → Kinesis Data Firehose: 실시간 스트리밍 ✅
CloudWatch Logs → Lambda: 실시간 처리
CloudWatch Logs → OpenSearch: 실시간 분석
시험 팁
실시간 로그 내보내기: S3 내보내기는 배치(최대 12시간 지연). 실시간이 필요하면 Kinesis Data Firehose 구독 필터를 사용하세요.
CloudWatch 에이전트
CloudWatch 에이전트가 필요한 경우:
- EC2 메모리, 디스크 메트릭 수집
- EC2 내부 로그 파일을 CloudWatch Logs로 전송
- 온프레미스 서버 모니터링
설치 흐름:
[EC2/온프레미스] → CloudWatch 에이전트 설치
→ IAM 역할 (EC2) 또는 자격 증명 (온프레미스)
→ 메트릭 + 로그 → CloudWatch
CloudWatch vs CloudTrail vs AWS Config
| 항목 | CloudWatch | CloudTrail | AWS Config |
|---|---|---|---|
| 목적 | 성능 모니터링 | API 감사 로깅 | 구성 변경 추적 |
| 질문 | "성능이 어때?" | "누가 했어?" | "뭐가 바뀌었어?" |
| 데이터 | 메트릭, 로그 | API 호출 기록 | 리소스 구성 이력 |
| 예시 | CPU 80% 초과 알림 | EC2 종료한 사람 추적 | SG 규칙 변경 감지 |
| 보존 | 메트릭 15개월 | 이벤트 90일 (S3 무제한) | 구성 이력 무제한 |
SAA-C03 시험 출제 포인트
- ✅ 메모리/디스크 메트릭: "EC2 메모리 모니터링 = CloudWatch 에이전트 필요"
- ✅ 상세 모니터링: "1분 간격 = 상세 모니터링 활성화"
- ✅ 경보 작업: "CPU 높을 때 자동 스케일링 = CloudWatch 경보 + Auto Scaling"
- ✅ 로그 실시간 내보내기: "S3는 배치, 실시간 = Kinesis Data Firehose"
- ✅ vs CloudTrail: "성능 = CloudWatch, 감사 = CloudTrail"
시험 팁
시험 문제 예시: "EC2 인스턴스의 메모리 사용률이 90%를 초과하면 자동으로 알림을 받으려면?" → 정답: CloudWatch 에이전트 설치 → 메모리 커스텀 메트릭 → CloudWatch 경보 → SNS 알림
자주 묻는 질문 (FAQ)
Q: CloudWatch는 무료인가요?
기본 모니터링(5분 간격)과 10개 메트릭 경보, 10개 커스텀 메트릭은 프리 티어에 포함됩니다. 상세 모니터링, 추가 경보, 대시보드, Logs Insights 쿼리 등은 과금됩니다.
Q: 메트릭 데이터는 얼마나 보관되나요?
해상도에 따라 다릅니다. 고해상도(1초)는 3시간, 60초 데이터는 15일, 5분 데이터는 63일, 1시간 데이터는 15개월 보관됩니다.
Q: 온프레미스 서버도 모니터링할 수 있나요?
네. CloudWatch 에이전트를 온프레미스 서버에 설치하고 IAM 자격 증명을 구성하면 메트릭과 로그를 CloudWatch로 전송할 수 있습니다.
Q: CloudWatch 경보가 INSUFFICIENT_DATA 상태인 이유는?
경보가 막 생성되었거나, 메트릭 데이터가 누락되었거나, 메트릭 네임스페이스가 잘못된 경우에 이 상태가 됩니다. 누락 데이터 처리 설정(missing data treatment)을 확인하세요.
Q: CloudWatch Logs와 S3 중 로그를 어디에 저장해야 하나요?
실시간 모니터링과 Logs Insights 쿼리가 필요하면 CloudWatch Logs, 장기 보관과 비용 절감이 목적이면 S3가 적합합니다. 보통 둘 다 사용합니다.