CloudWatch Basics

분류: Layer 6 - 운영 심화: 관측성 & 복원력

1. 한 줄 정의

CloudWatch는 AWS 리소스와 애플리케이션의 로그, 지표(Metric), 알림(Alarm)을 한 곳에서 모니터링하는 서비스이다.

2. 왜 중요한가

서비스가 정상인지, 느려지고 있는지, 장애가 발생했는지를 알려면 모니터링이 필요하다. CloudWatch는 AWS의 기본 모니터링 도구이고, 대부분의 AWS 서비스가 자동으로 CloudWatch에 지표를 보낸다. 장애 대응의 시작점.

프론트엔드 개발자 관점에서: 브라우저 DevTools의 Performance 탭에서 보던 FCP·LCP 같은 지표, Network 탭의 요청 응답 시간과 에러 코드 — 이것들은 클라이언트 관점의 관측 도구다. CloudWatch Metrics는 그 동일한 관심사를 서버 관점에서 다룬다. “API 응답이 느리다”는 브라우저 Network 탭의 신호가, 서버에서는 CloudWatch의 ECS CPU 급증 또는 Lambda Duration 증가 메트릭으로 이어진다. 브라우저 콘솔에서 에러를 찾던 습관이 서버에서는 CloudWatch Log Insights 쿼리로 이어지는 것과 같다.

3. 핵심 개념

CloudWatch가 동작하는 방식 (전체 흐름)

비유: CloudWatch는 “병원 차트 시스템”과 같다. 환자(AWS 서비스)마다 혈압/체온 같은 수치(Metrics)가 지속적으로 기록되고, 의사(운영자)는 차트를 보다가 수치가 이상하면 알림(Alarm)을 받는다. 특이한 증상은 기록지(Logs)에 남아 나중에 검색할 수 있다.

원리: CloudWatch는 내부적으로 시계열 데이터베이스(time-series repository) 구조다.

데이터 수집: EC2, ECS, Lambda 등 AWS 서비스가 자동으로 지표를 CloudWatch API에 PutMetricData로 푸시한다. 애플리케이션도 SDK로 직접 지표를 보낼 수 있다.
저장: 지표 데이터는 리전별로 분리 저장되며, 최대 15개월 보관된다. 고해상도(1초 단위)부터 1분, 5분 단위까지 집계 저장.
알림 평가: Alarm은 지정된 평가 주기마다 해당 지표의 통계값(Average, Max 등)을 임계값과 비교해 상태를 전환한다.
로그 처리: 로그는 Log Group → Log Stream 계층으로 저장되고, Metric Filter를 걸면 로그에서 숫자 지표를 추출해 알림으로 연결할 수 있다.

왜 이렇게 설계되었는가 — 설계 철학

CloudWatch가 리전별로 데이터를 분리 저장하는 이유는 AWS의 핵심 원칙인 “장애 격리(Failure Isolation)” 때문이다. 한 리전이 장애를 겪어도 다른 리전의 모니터링 데이터가 영향받지 않는다. 또한 지표 집계 방식(1초→1분→5분→1시간)은 “최신 데이터는 세밀하게, 오래된 데이터는 효율적으로”라는 비용 최적화 원칙에 따른 것이다.

고카디널리티 차원의 함정 (비용 폭탄 원인)

CloudWatch의 가장 흔한 비용 실수는 고카디널리티 차원이다. 예를 들어 userId를 차원(Dimension)으로 사용하면, 사용자 10만 명 = 커스텀 지표 10만 개 = 월 $30,000 청구가 된다. AWS는 차원이 다르면 별도 지표로 처리하기 때문이다.

✅ 안전한 차원 예시: Environment(production/staging), Region, ServiceName
❌ 위험한 차원 예시: userId, orderId, requestId (카디널리티가 무한히 커짐)

비용 비교:
- 커스텀 지표 1,000개: ~$3/월
- 커스텀 지표 100,000개 (userId 차원): ~$3,000/월

📖 더 보기: How Amazon CloudWatch works — 위 수집→저장→알림 흐름의 공식 아키텍처 다이어그램 확인 가능

Metrics (지표)

수치화된 데이터. CPU 사용률, 메모리 사용량, 요청 수, 에러 수 등.

AWS 서비스가 자동으로 보내는 기본 지표 (EC2 CPU, RDS 연결수 등)
커스텀 지표도 직접 보낼 수 있음
각 지표는 네임스페이스(Namespace) + 차원(Dimension) 조합으로 식별된다 예: AWS/EC2 네임스페이스의 CPUUtilization 지표를 InstanceId=i-xxxx 차원으로 조회

커스텀 지표 전송 예시 (AWS SDK v3 + Node.js)

import {
  CloudWatchClient,
  PutMetricDataCommand,
} from "@aws-sdk/client-cloudwatch";

const client = new CloudWatchClient({ region: "ap-northeast-2" });

// 주문 처리 성공 건수를 커스텀 지표로 전송
const command = new PutMetricDataCommand({
  Namespace: "MyApp/Orders",
  MetricData: [
    {
      MetricName: "OrderSuccess",
      Dimensions: [{ Name: "Environment", Value: "production" }],
      Value: 1,
      Unit: "Count",
    },
  ],
});

await client.send(command);
// 성공 시 응답: { $metadata: { httpStatusCode: 200, ... } }

Logs (로그)

애플리케이션/서비스가 출력하는 텍스트 로그. Log Group(그룹) > Log Stream(스트림) 구조.

Log Group: 서비스/애플리케이션 단위 (예: /ecs/my-api)
Log Stream: 개별 컨테이너 인스턴스/태스크 단위

ECS Fargate에서 CloudWatch 로그 설정 예시:

// ECS Task Definition의 logConfiguration 부분
{
  "logConfiguration": {
    "logDriver": "awslogs",
    "options": {
      "awslogs-group": "/ecs/my-api",
      "awslogs-region": "ap-northeast-2",
      "awslogs-stream-prefix": "ecs"
    }
  }
}

콘솔에서 확인: CloudWatch → Log groups → /ecs/my-api → 특정 스트림 클릭

Log Insights 기본 쿼리

# 최근 에러 로그 검색
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 20

# 특정 키워드(요청 ID 등) 추적
fields @timestamp, @message
| filter @message like /payment-failed/
| sort @timestamp desc

# 시간대별 에러 발생 건수 집계
filter @message like /ERROR/
| stats count(*) as errorCount by bin(1h)
| sort @timestamp desc

예상 출력 (Log Insights 결과 테이블)

@timestamp               @message
2026-03-28 14:23:01.123  ERROR [OrderService] Failed to process order id=9821 ...
2026-03-28 14:20:44.891  ERROR [PaymentService] Timeout after 5000ms ...
2026-03-28 14:18:12.003  ERROR [OrderService] DB connection refused ...

콘솔 경로: CloudWatch → Log Insights → Log Group 선택 → 쿼리 입력 → Run query

📖 더 보기: CloudWatch Logs Insights 쿼리 예제 모음 — 위 쿼리 문법을 실제 사례별(에러 집계, 상위 N건 추출 등)로 확인 가능

Alarms (알림)

지표가 특정 조건을 넘으면 알림. “CPU 사용률이 80% 넘으면 Slack에 알림” 같은 설정.

알람 상태 전환 흐름:

[OK] ──→ (임계값 초과) ──→ [ALARM] ──→ SNS Topic ──→ Slack/이메일
  ↑                                                         │
  └─────────── (임계값 복구) ─────────────────────────────────┘

상태: OK → ALARM → INSUFFICIENT_DATA
SNS(알림 서비스)와 연결해서 이메일, Slack 등으로 전달
주의: 알람은 상태가 전환될 때만 발동한다. 이미 ALARM 상태라면 임계값을 계속 초과해도 재발동하지 않음
⚠️ INSUFFICIENT_DATA 주의: 많은 개발자가 이 상태를 “문제없음”으로 오해하는데, 실제로는 “지표 데이터가 부족해서 평가 불가” 상태다. 지표 수집 자체가 끊겼거나 ECS 태스크가 중단됐을 때 발생. 알람 설정에서 Treat missing data as breaching으로 설정하면 지표 유실 시 자동으로 ALARM 전환된다

알람 생성 예시 (ECS 서비스 CPU 80% 초과 시 알림)

콘솔 경로: CloudWatch → Alarms → Create alarm → Select metric → ECS → ClusterName/ServiceName → CPUUtilization

조건 설정:
- Threshold type: Static
- Whenever CPUUtilization is: Greater than 80
- Period: 5 minutes
- Evaluation period: 2 (2번 연속 초과 시 알람)
- Missing data treatment: Treat missing data as missing

Dashboard

여러 지표를 한 화면에 모아서 보는 대시보드. 팀별/서비스별로 만들어서 한눈에 파악.

Container Insights — ECS/Fargate 전용 심화 모니터링

ECS Fargate를 운영하는 경우, 기본 CloudWatch 지표만으로는 컨테이너 수준의 세부 정보를 볼 수 없다. Container Insights를 활성화하면 클러스터 → 서비스 → 태스크 → 컨테이너 각 레벨별 지표를 수집할 수 있다.

Container Insights가 추가로 제공하는 지표:

지표	설명
`CpuUtilized`	각 태스크/컨테이너별 CPU 사용 코어 수
`MemoryUtilized`	메모리 실제 사용량 (MB)
`NetworkRxBytes` / `NetworkTxBytes`	네트워크 수신/송신 바이트
`EphemeralStorageUtilized`	임시 스토리지 사용량 (Fargate 1.4.0+)
`RunningTaskCount`	실행 중인 태스크 수

Container Insights 활성화 방법:

# AWS CLI로 ECS 클러스터에 Container Insights 활성화
aws ecs update-cluster-settings \
  --cluster my-cluster \
  --settings name=containerInsights,value=enabled \
  --region ap-northeast-2

# 확인: 콘솔 경로
# CloudWatch → Container Insights → ECS Clusters → my-cluster

Fargate는 별도 에이전트 설치 없이 클러스터 설정 변경만으로 Container Insights가 동작한다.

📖 더 보기: Amazon ECS Container Insights metrics - AWS 공식 문서 — Fargate/EC2별 수집 가능한 전체 지표 목록과 활성화 방법 상세 설명 (입문)

Metric Filter — 로그에서 지표 추출

로그에 특정 패턴이 나타날 때 숫자 지표로 변환하는 기능. 예를 들어 로그에서 “ERROR” 키워드가 나올 때마다 카운트를 증가시켜서 알람을 연결할 수 있다.

활용 흐름:
로그 스트림 → Metric Filter (패턴 매칭) → CloudWatch Metric → Alarm → SNS

예시:
- 로그에 "payment_failed" 패턴 감지 → PaymentFailureCount 지표 +1
- PaymentFailureCount > 5 (1분 내) → ALARM → Slack 알림

콘솔 경로: CloudWatch → Log groups → /ecs/my-api → Metric filters → Create metric filter

실전 아키텍처 패턴

패턴 1: 비즈니스 중요도 기반 계층화 로그 보존 전략

비용과 운영 효율을 동시에 잡는 보존 정책. 실무에서 이 전략으로 CloudWatch 로깅 비용을 최대 30% 절감할 수 있다.

계층별 보존 기간 설정 예시:
┌──────────────────────────────────────────┐
│ /prod/payment-service  (결제 에러)  90일  │ ← 컴플라이언스, 장기 감사 필요
│ /prod/order-service    (일반 에러)  30일  │ ← 장애 분석 충분
│ /prod/api-gateway      (액세스 로그) 7일  │ ← 단기 트래픽 분석
│ /staging/all-services  (디버그)     1일   │ ← 개발 목적만
└──────────────────────────────────────────┘

AWS CLI로 Log Group Retention 설정:
aws logs put-retention-policy \
  --log-group-name /prod/payment-service \
  --retention-in-days 90 \
  --region ap-northeast-2

패턴 2: 통합 알람 대시보드 구성

팀 서비스의 모든 핵심 지표를 한 화면에 모은 대시보드. CloudWatch 대시보드는 여러 리전, 여러 서비스 지표를 한 화면에 배치할 수 있다.

권장 대시보드 구성:
행 1: API 상태      → ALB RequestCount, ErrorRate, TargetResponseTime
행 2: 인프라 상태   → ECS CPUUtilization, MemoryUtilization, RunningTaskCount
행 3: 비즈니스 지표 → 주문 생성 수, 결제 성공/실패 수 (커스텀 메트릭)
행 4: 큐 상태       → SQS ApproximateNumberOfMessagesVisible, DLQ 메시지 수

패턴 3: Detailed Monitoring으로 세밀한 모니터링

기본 EC2/ECS 지표는 5분 간격으로 수집된다. 프로덕션 서비스의 경우 Detailed Monitoring을 활성화해 1분 간격으로 전환하면 장애 감지 속도를 높일 수 있다. (소폭 추가 비용 발생)

# EC2 인스턴스에 Detailed Monitoring 활성화
aws ec2 monitor-instances \
  --instance-ids i-xxxxxxxxxxxxxxxxx \
  --region ap-northeast-2
# 응답: {"InstanceMonitorings": [{"InstanceId": "i-xxx", "Monitoring": {"State": "pending"}}]}

4. 실무에서 어디에 쓰이나

서비스 상태 모니터링 (CPU, 메모리, 에러율)
장애 감지 및 알림 (Alarm → Slack/이메일)
로그 검색/분석 (에러 원인 추적)
성능 추이 분석 (시간에 따른 변화)

5. 현재 내 업무와 연결점

장애 발생 시 CloudWatch Logs에서 에러 로그 검색
알림 설정/관리 (팀 서비스의 모니터링 기준)
배포 후 서비스 상태 확인 (지표 변화 관찰)
성능 이슈 분석 시 지표 기반 판단

6. 자주 헷갈리는 개념 비교

개념 A	개념 B	차이점
Metrics	Logs	Metrics는 숫자(지표), Logs는 텍스트(기록)
CloudWatch	Datadog/Grafana	CloudWatch는 AWS 네이티브, Datadog/Grafana는 서드파티 모니터링 도구
Log Group	Log Stream	Log Group은 서비스 단위, Log Stream은 인스턴스/컨테이너 단위
Alarm	Event	Alarm은 지표 기반 알림, EventBridge Event는 상태 변화 기반 트리거
Container Insights	기본 ECS 지표	Container Insights는 컨테이너/태스크 단위 세부 지표, 기본은 클러스터 단위만
기본 모니터링	Detailed Monitoring	기본은 5분 간격, Detailed는 1분 간격 (추가 비용 소폭 발생)

6.5. 트러블슈팅

🔧 Alarm이 ALARM 상태인데 알림이 오지 않는다

증상: CloudWatch 콘솔에서 Alarm 상태가 빨간색(ALARM)인데 Slack/이메일 알림이 오지 않음 원인: SNS Topic 구독이 Pending confirmation 상태임. 이메일 구독은 확인 링크를 클릭해야 활성화됨 해결:

SNS → Topics → 해당 토픽 → Subscriptions 확인
Status가 PendingConfirmation이면 이메일 받은 편지함에서 확인 메일 찾기
“Confirm subscription” 링크 클릭 후 Status가 Confirmed로 바뀌는지 확인

🔧 알람이 임계값을 넘었는데도 ALARM으로 전환되지 않는다

증상: CPU가 90%임에도 알람이 계속 OK 상태 원인: 평가 주기 설정 문제. Evaluation periods: 3, Datapoints to alarm: 3으로 설정하면 3번 연속 초과해야 알람이 발동함. 또는 지표 단위(Unit)가 알람 설정과 불일치하는 경우 해결:

알람 상세 페이지에서 “Conditions” 섹션의 Evaluation periods 값 확인
즉각 반응이 필요하면 Datapoints to alarm: 1 out of 1로 변경
지표의 Unit과 알람 설정의 Unit이 일치하는지 확인 (Percent vs None)

🔧 Log Insights 쿼리 결과가 비어있다

증상: 분명히 에러가 발생했는데 Log Insights에서 검색 결과가 0건 원인 1: 시간 범위 설정 오류 — 기본 1시간 범위를 사용하는데 에러는 그 전에 발생함 원인 2: Log Group을 잘못 선택함 — ECS 서비스가 여러 개일 때 다른 서비스의 Log Group을 선택 원인 3: 로그가 CloudWatch로 전송되지 않음 — ECS Task의 logConfiguration이 없거나 IAM 권한 부족 해결:

우선 시간 범위를 “Last 3 days”로 넓혀서 재검색
오른쪽 상단 Log Group 선택란에서 /ecs/my-api 형태로 정확한 그룹 확인
IAM Role에 logs:CreateLogStream, logs:PutLogEvents 권한이 있는지 확인

🔧 Container Insights 지표가 보이지 않는다

증상: ECS 클러스터가 정상 동작 중인데 Container Insights 콘솔에 지표가 없음 원인: Container Insights가 클러스터에 활성화되어 있지 않거나, ECS Task Role에 CloudWatch 권한이 없음 해결:

클러스터 설정 확인: ECS → Clusters → 클러스터 클릭 → Settings → containerInsights: enabled 여부 확인
비활성 상태면 AWS CLI 또는 콘솔에서 활성화: ECS → Clusters → Update cluster → Container Insights → Enable
Task Execution Role에 CloudWatchAgentServerPolicy 정책 추가 여부 확인

🔧 CloudWatch 비용이 예상보다 너무 많이 나온다

증상: 월말 AWS 청구서에서 CloudWatch 항목이 예상의 5~10배 원인 1: Log Group의 Retention 정책이 설정되지 않아 모든 로그가 무기한 보관됨 원인 2: 고해상도 커스텀 지표(1초 단위)를 대량으로 전송하는 경우 원인 3: Log Insights 쿼리를 자동화 스크립트로 자주 실행하는 경우 (스캔한 데이터 양 기준 과금) 원인 4: 삭제된 EC2/ECS/RDS 리소스에 연결된 알람이 그대로 남아 “Zombie Alarm” 상태로 과금 지속 (Standard Alarm: $0.10/월, High-Resolution Alarm: $0.30/월) 해결:

모든 Log Group에 Retention 기간 설정:

# 모든 Log Group 목록 조회 후 Retention 일괄 설정
aws logs describe-log-groups --query 'logGroups[?retentionInDays==`null`].logGroupName' \
  --output text --region ap-northeast-2
# 보존 기간이 없는 그룹들을 확인 후 put-retention-policy 적용

커스텀 지표는 표준 해상도(60초)로 시작하고, 필요한 경우에만 고해상도 사용
Log Insights 대신 반복 쿼리가 필요하면 Metric Filter로 전환해 비용 절감

Zombie Alarm 정리: INSUFFICIENT_DATA 상태로 오래 방치된 알람 목록 확인 후 삭제

# INSUFFICIENT_DATA 상태 알람 목록 조회
aws cloudwatch describe-alarms \
  --state-value INSUFFICIENT_DATA \
  --query 'MetricAlarms[*].AlarmName' \
  --output text --region ap-northeast-2

🔧 High-Resolution Alarm이 예상보다 훨씬 비싸게 청구된다

증상: 알람 수가 많지 않은데 CloudWatch Alarms 청구가 예상보다 3배 이상 높음 원인: High-Resolution Alarm(10초 단위)은 Standard Alarm보다 3배 비싸다. 팀 전체가 기본 설정 없이 알람을 만들다 보면 의도치 않게 High-Resolution으로 생성되는 경우가 있음 해결:

현재 High-Resolution Alarm 목록 확인:

aws cloudwatch describe-alarms \
  --query 'MetricAlarms[?Period<60].{Name:AlarmName, Period:Period}' \
  --output table --region ap-northeast-2

실제로 10초 이하 감지가 필요한 알람인지 재검토 (보통 1분 감지로 충분)
Composite Alarm을 도입해 알람 총 수를 줄임 → 비용 절감 + 오탐 감소

🔧 Metric Filter를 만들었는데 지표가 생성되지 않는다

증상: CloudWatch Logs에 로그가 들어오고 있는데, Metric Filter를 설정했음에도 지표 값이 0이거나 아예 없음 원인 1: Metric Filter 패턴이 실제 로그 형식과 다름. JSON 구조 로그의 경우 { $.level = "ERROR" } 형식으로 작성해야 함 원인 2: Metric Filter는 생성 이후에 들어온 로그에만 적용됨. 과거 로그에 소급 적용되지 않음 원인 3: Log Group을 잘못 지정함. Metric Filter는 특정 Log Group에 종속됨 해결:

CloudWatch → Log groups → /ecs/my-api → Metric filters → 해당 필터 → Test pattern 기능으로 샘플 로그를 붙여넣어 패턴 일치 여부 먼저 검증

JSON 로그 필터 패턴 형식 확인:

# 일반 텍스트 로그 패턴
ERROR

# JSON 구조 로그 패턴 (JSON 필드 기준)
{ $.level = "ERROR" }
{ $.statusCode >= 500 }
{ $.message = "payment_failed" }

Metric Filter 생성 후 테스트 로그를 직접 발행해 즉시 지표 생성 여부 확인:

aws logs put-log-events \
  --log-group-name /ecs/my-api \
  --log-stream-name test-stream \
  --log-events "[{\"timestamp\":$(date +%s000),\"message\":\"{\\\"level\\\":\\\"ERROR\\\",\\\"message\\\":\\\"test_error\\\"}\"}]" \
  --region ap-northeast-2

🔧 ECS 태스크가 종료됐는데 알람이 울리지 않는다

증상: ECS 태스크가 전부 STOPPED됐는데 CloudWatch Alarm에서 감지되지 않음 원인: 태스크가 종료되면 해당 컨테이너의 지표 데이터도 전송이 멈춘다. CloudWatch는 “데이터가 없음”을 장애로 처리하지 않고 INSUFFICIENT_DATA 상태로 전환한다. 기본 설정은 누락 데이터를 “정상”으로 처리함 해결:

알람 설정에서 “Treat missing data as” 옵션을 breaching으로 변경:

aws cloudwatch put-metric-alarm \
  --alarm-name "ecs-task-running" \
  --metric-name RunningTaskCount \
  --namespace ECS/ContainerInsights \
  --statistic Average \
  --period 60 \
  --threshold 1 \
  --comparison-operator LessThanThreshold \
  --treat-missing-data breaching \
  --region ap-northeast-2

또는 EventBridge 규칙으로 ECS 태스크 상태 변경을 직접 감지:
```
{
  "source": ["aws.ecs"],
  "detail-type": ["ECS Task State Change"],
  "detail": { "lastStatus": ["STOPPED"], "desiredStatus": ["RUNNING"] }
}
```
→ 태스크가 의도치 않게 STOPPED될 때 즉시 SNS로 알림 전송

7. 체크리스트

CloudWatch의 Metrics, Logs, Alarms를 각각 설명할 수 있다
CloudWatch Logs에서 특정 에러를 검색할 수 있다
Alarm이 어떻게 동작하는지 설명할 수 있다
팀 서비스의 핵심 모니터링 지표가 뭔지 안다
Container Insights와 기본 지표의 차이를 설명할 수 있다
Log Group의 Retention 설정이 왜 비용에 영향을 주는지 설명할 수 있다

8. 추가 학습 키워드

CloudWatch Log Insights, Metric Filter, Composite Alarm, Anomaly Detection, X-Ray, Container Insights, Cross-Account Observability, Detailed Monitoring

8.5. 추천 리소스

📖 How Amazon CloudWatch works - AWS 공식 문서 — CloudWatch 내부 아키텍처(데이터 수집→저장→알람 흐름) 공식 설명 (입문)
📖 CloudWatch Logs Insights 쿼리 예제 - AWS 공식 문서 — 실무에서 바로 쓸 수 있는 쿼리 패턴 모음 (입문)
📖 Amazon ECS Container Insights metrics - AWS 공식 문서 — Fargate/EC2별 Container Insights 지표 목록과 활성화 방법 (입문)
📖 CloudWatch Alarm 트러블슈팅 - AWS re:Post — 알람이 안 울리는 원인과 해결법 정리 (중급)
📖 Amazon CloudWatch Logs Best Practices - Coders.dev — 비용 최적화, 보안, 운영 효율을 위한 CloudWatch Logs 실전 모범 사례 (중급)

9. 내가 직접 확인해볼 것

AWS CloudWatch 콘솔에서 팀 서비스의 Log Group 확인 경로: CloudWatch → Log groups → /ecs/<서비스명>
Log Insights에서 간단한 쿼리로 에러 로그 검색
```
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 20
```
예상 출력: 타임스탬프와 에러 메시지가 담긴 테이블 (결과 없으면 시간 범위 확장)
현재 설정된 Alarm 목록 확인 (어떤 조건에 알림이 가는지) 경로: CloudWatch → Alarms → All alarms 확인 항목: 알람 이름, 지표, 임계값, 연결된 SNS Topic
Dashboard가 있다면 어떤 지표를 보고 있는지 확인 경로: CloudWatch → Dashboards
Container Insights 활성화 여부 확인 경로: CloudWatch → Container Insights → ECS Clusters 예상 출력: 활성화된 경우 클러스터별 CPU/메모리 그래프 표시. 없으면 활성화 검토
모든 Log Group에 Retention 기간이 설정되어 있는지 확인 경로: CloudWatch → Log groups → Retention 컬럼 확인 확인: “Never expire”로 표시된 그룹이 있으면 비용 낭비 중 → 적절한 기간 설정

10. 5줄 요약

CloudWatch는 AWS의 기본 모니터링 서비스로 Metrics, Logs, Alarms를 제공한다
Metrics는 숫자 지표, Logs는 텍스트 로그, Alarms는 조건 기반 알림이다
장애 대응의 시작은 CloudWatch Logs에서 에러 로그를 검색하는 것이다
Container Insights로 ECS Fargate의 컨테이너 단위 세부 지표를 수집할 수 있다
AWS 모니터링의 출발점이며, 더 고도화하면 Datadog/Grafana로 확장한다

11. 실전 장애 대응 시나리오 (On-Call Runbook)

on-call 시 CloudWatch를 빠르게 활용하는 체크리스트

시나리오 A: “서비스가 느리다”는 제보를 받았을 때

1단계: ALB 지표 확인 (2분)
  경로: CloudWatch → Metrics → ApplicationELB → Per AppELB Metrics
  확인: TargetResponseTime (응답시간), RequestCount (요청 수)
  → p99 응답시간이 평소보다 3배 이상이면 실제 문제

2단계: 병목 서비스 찾기 (3분)
  경로: CloudWatch → Container Insights → ECS Clusters
  확인: 각 서비스의 CPUUtilization, MemoryUtilized
  → CPU 90% 이상: 스케일아웃 필요 또는 무한루프 의심
  → Memory 급증: 메모리 누수 또는 대용량 데이터 처리 의심

3단계: 로그에서 원인 확인 (3분)
  경로: CloudWatch → Log Insights
  쿼리:
    filter @timestamp >= 1h ago
    | filter level = "ERROR" or level = "WARN"
    | stats count(*) as cnt by message
    | sort cnt desc | limit 10
  → 가장 많이 나오는 에러/경고 메시지가 원인 후보

4단계: 조치 후 지표 모니터링
  → 조치 직후 TargetResponseTime 그래프를 실시간으로 관찰
  → 5분 이내 개선되지 않으면 추가 원인 탐색

시나리오 B: “알람이 너무 자주 울린다” (Alert Fatigue 해소)

문제: CloudWatch Alarm이 하루에 수십 번 울려서 실제 장애를 놓치게 됨

점검 체크리스트:
1. 알람 임계값이 실제 서비스 특성과 맞는지 확인
   → CPU가 정상적으로 60~70% 유지되는 서비스에 50% 임계값이 있으면 잦은 오탐
   → 해결: 임계값을 p99 기준으로 재설정

2. Evaluation Period 설정 확인
   → Datapoints to alarm: 1 out of 1 → 즉각 반응 (노이즈 많음)
   → 개선: 3 out of 5 (5분 중 3분 초과 시 알람) → 일시적 스파이크 무시

3. Composite Alarm 도입
   → CPU 알람 AND 에러율 알람 → "두 조건 동시 충족 시에만" 알람
   경로: CloudWatch → Alarms → Create alarm → Composite alarm
   → 단독 지표보다 훨씬 정확한 실제 장애 감지

4. Anomaly Detection 기반 알람으로 전환
   → 고정 임계값 대신 ML 기반 정상 범위 자동 계산
   → 평일/주말, 낮/밤 트래픽 패턴 차이를 자동으로 학습

시나리오 C: “배포 후 서비스 상태가 이상한지 확인할 때”

배포 완료 직후 확인 루틴 (5분):

1. ECS 태스크 상태 확인
   경로: ECS → Clusters → 서비스 → Tasks
   확인: RUNNING 태스크 수가 목표치와 일치하는가

2. ALB 헬스체크 상태
   경로: EC2 → Target Groups → 해당 TG → Targets
   확인: ALL healthy가 아닌 인스턴스가 있으면 즉시 조사

3. 에러율 기준선과 비교
   경로: CloudWatch → 서비스 대시보드
   배포 전 5xx 에러율 vs 배포 후 5xx 에러율 비교
   → 1% 이상 증가면 롤백 검토

4. 응답시간 비교
   배포 전 p99 vs 배포 후 p99
   → 20% 이상 증가면 코드 변경 확인 (N+1 쿼리, 새 외부 API 호출 등)

2025년 최신 동향

Composite Alarm 표준화

2024~2025년 프로덕션에서 Composite Alarm(복합 알람) 사용이 표준화됐다. 단일 지표로는 오탐이 많기 때문에 여러 지표를 조합한 복합 조건으로 실제 장애만 감지하는 방식이 권장된다.

예시: "결제 서비스 실제 장애" 복합 알람
= (에러율 > 1%) AND (응답시간 p99 > 2000ms)
→ 둘 중 하나만 일시적으로 올라가는 경우는 알람 미발생
→ 두 조건이 동시에 충족될 때만 실제 장애로 판단

AWS Incident Manager 주의사항

AWS Systems Manager Incident Manager는 2025년 11월 7일부터 신규 고객 가입이 종료됐다. 현재 사용 중이 아니라면 Amazon CloudWatch + EventBridge 조합으로 자동화 대응 플로우를 구성하는 것이 권장 방향이다.

Cross-Account Observability

AWS Organizations를 사용하는 경우, CloudWatch Cross-Account Observability를 통해 여러 계정의 지표와 로그를 하나의 모니터링 계정에서 통합 조회할 수 있다. 멀티 계정 환경(개발/스테이징/프로덕션 계정 분리)에서 유용한 기능으로 2024년 GA됐다.

📖 더 보기: Use Amazon EventBridge rules to run AWS Systems Manager automation in response to CloudWatch alarms — CloudWatch Alarm 발생 시 EventBridge로 자동화 대응 플로우 구성하는 방법 (중급)