CloudWatch란 — 운영 상태를 수집하고 판단하는 중심 서비스
운영에서는 “서버가 살아 있는가?”만 보면 부족합니다. CPU와 메모리가 어떻게 변하는지, 요청이 느려지는지, 5XX 오류가 늘어나는지, 로그에 어떤 예외가 쌓이는지를 함께 봐야 합니다. CloudWatch는 이런 운영 신호를 지표와 로그로 모으고, 조건을 만족하면 경보와 자동 작업으로 연결할 수 있습니다.
| 구성 요소 | 무엇을 보는가 | 대표 활용 |
|---|---|---|
| Metrics | 시간에 따라 변하는 숫자 데이터 | CPU, 요청 수, 지연시간, DB 연결 수 |
| Logs | 애플리케이션·OS·서비스 로그 | 예외 원인, 요청 흐름, 장애 분석 |
| Alarms | 지표 또는 로그 조건의 상태 | SNS 알림, Auto Scaling, 운영 대응 |
| Dashboards | 여러 지표·경보를 한 화면에 시각화 | 서비스 상태판, 운영 관제 |
Metrics — 기본 제공 지표와 세부 모니터링을 구분하자
많은 AWS 서비스는 기본적인 CloudWatch 지표를 자동으로 게시합니다. 다만 서비스마다 제공 지표와 게시 주기가 다르고, 세부 모니터링이나 커스텀 지표는 별도 과금이 발생할 수 있으므로 “CloudWatch 지표는 전부 무료”라고 이해하면 안 됩니다.
| 대상 | 대표 지표 | 운영 포인트 |
|---|---|---|
| EC2 | CPUUtilization, NetworkIn/Out, StatusCheckFailed | 기본 모니터링은 대부분 5분 간격, 세부 모니터링은 1분 간격 |
| ALB | RequestCount, TargetResponseTime, HTTPCode_Target_5XX_Count | 트래픽·지연·백엔드 오류를 함께 확인 |
| RDS | CPUUtilization, DatabaseConnections, FreeStorageSpace | CPU 하나가 아니라 연결·스토리지와 같이 판단 |
| Lambda | Invocations, Errors, Duration, Throttles | 오류율·지연·Throttle을 같이 확인 |
EC2 기본 모니터링의 일반 지표는 5분 간격이고, 세부 모니터링을 활성화하면 1분 간격으로 게시됩니다. 5분 지표를 두고 1분 단위 판단을 기대하면 원하는 경보 동작이 나오지 않습니다.
CPU만 보면 놓치는 장애
CPU가 낮아도 메모리 부족, 디스크 부족, 애플리케이션 Thread 고갈로 장애가 날 수 있습니다.
CPU가 정상이어도 연결 수 증가, 여유 스토리지 감소, 지연 증가가 장애 신호일 수 있습니다.
CloudWatch Agent — OS 내부 지표와 애플리케이션 로그 수집
EC2 기본 지표는 하이퍼바이저 관점의 정보를 중심으로 제공하므로 인스턴스 내부의 메모리 사용률 같은 지표는 기본 EC2 지표에 포함되지 않습니다. CloudWatch Agent를 설치하면 EC2와 온프레미스 서버에서 메모리·디스크 같은 시스템 지표와 파일 로그를 추가로 수집할 수 있습니다.
| 수집 대상 | 기본 EC2 지표 | CloudWatch Agent |
|---|---|---|
| CPU / Network | 주요 지표 제공 | 필요 시 추가 수집 |
| 메모리 사용률 | 미제공 | 수집 가능 |
| 디스크 사용률 | 파일시스템 사용률은 미제공 | 수집 가능 |
| 애플리케이션 로그 파일 | 미제공 | 수집 가능 |
어떤 지표와 로그를 몇 초·몇 분 간격으로 수집할지, 어떤 Log Group에 저장할지, 보존 기간을 얼마로 둘지 먼저 정해야 불필요한 데이터와 비용을 줄일 수 있습니다.
CloudWatch Logs — 로그를 중앙화하고 보존 기간을 관리한다
서버 로컬 파일에만 로그를 남기면 인스턴스 교체나 장애 시 분석이 어려워집니다. CloudWatch Logs로 중앙화하면 여러 서버의 로그를 Log Group과 Log Stream으로 모으고 검색할 수 있습니다.
| 개념 | 설명 | 예시 |
|---|---|---|
| Log Group | 같은 용도의 로그를 묶는 최상위 단위 | /production/app |
| Log Stream | 한 Log Group 안의 개별 로그 흐름 | EC2 Instance ID별 Stream |
| Retention | 로그를 보관하는 기간 | 서비스·보안 정책에 맞게 지정 |
| Subscription | 로그를 다른 처리 대상으로 전달 | 실시간 분석·후속 처리 |
로그 수집량·저장량·분석 쿼리는 비용에 영향을 줍니다. 운영·보안·법적 요구에 필요한 기간을 정하고, 장기 보존이 필요하면 목적에 맞는 저장 전략을 별도로 설계합니다.
Logs Insights로 장애 범위를 좁히기
Logs Insights는 CloudWatch Logs의 로그를 쿼리해 특정 시간대의 ERROR, 요청 ID, 응답시간 패턴 등을 빠르게 찾을 수 있게 해줍니다. 장애 대응에서는 먼저 시간 범위를 좁히고, 오류 메시지나 Trace ID 같은 필드로 필터링하는 습관이 중요합니다.
Alarms — 임계값보다 중요한 것은 평가 방식
CloudWatch Alarm은 단순히 “CPU가 70%를 넘으면 알림”만 설정하는 기능이 아닙니다. Period, Evaluation Periods, Datapoints to Alarm, Missing Data 처리 방식을 함께 정해야 실제 운영 의도와 맞게 동작합니다.
예를 들어 Period 1분, Evaluation Periods 5, Datapoints to Alarm 3, Threshold CPU 70%라면 “최근 5개의 1분 데이터 중 3개 이상이 CPU 70%를 넘으면 ALARM”이라고 이해하면 됩니다.
즉 Period = 한 칸의 길이, Evaluation Periods = 몇 칸을 볼지, Datapoints to Alarm = 그중 몇 칸이 나빠야 경보인지입니다.
| 설정 | 의미 | 주의 |
|---|---|---|
| Period | 한 데이터 포인트를 집계하는 시간 | 원본 지표 해상도 이상으로 설정 |
| Threshold | 정상/비정상을 가르는 기준 | 서비스 특성과 정상 Baseline 필요 |
| Evaluation Periods | 최근 몇 개 기간을 평가할지 | 너무 짧으면 순간 Spike에 민감 |
| Datapoints to Alarm | N개 중 M개가 위반하면 ALARM | M-out-of-N으로 노이즈 조절 |
| Missing Data | 데이터가 없을 때의 취급 방식 | 서비스 특성에 맞게 선택 |
SNS로 알림만 보내고 끝내지 말고, 경보 이름·대상·우선순위·담당자·초기 확인 항목을 운영 Runbook과 연결하면 대응 속도가 크게 좋아집니다.
Composite Alarm으로 알람 폭주 줄이기
여러 Metric Alarm의 상태를 Boolean 규칙으로 묶는 Composite Alarm을 사용하면 개별 경보가 동시에 울릴 때 운영자에게 중복 알림이 쏟아지는 문제를 줄일 수 있습니다. 단, Composite Alarm은 SNS 같은 알림 작업에는 사용할 수 있지만 EC2 또는 Auto Scaling 작업을 직접 수행하는 용도와는 구분해야 합니다.
Dashboard — 서비스 관점으로 묶어서 본다
대시보드는 리소스 종류별이 아니라 서비스 흐름별로 구성하는 편이 운영에 유리합니다. 예를 들어 웹 서비스라면 CloudFront → ALB → EC2 → RDS의 핵심 지표를 같은 화면에 배치하면 어느 계층에서 병목이 시작됐는지 빠르게 비교할 수 있습니다.
오류율, 응답시간, 요청 수처럼 사용자가 직접 느끼는 신호를 상단에 둡니다.
CPU, Memory, Connection, Storage처럼 원인을 설명할 자원 지표를 함께 둡니다.
CloudTrail — 모니터링과 감사 로그를 구분하자
CloudWatch와 CloudTrail은 이름이 비슷하지만 목적이 다릅니다. CloudWatch는 성능·상태·애플리케이션 로그를 관찰하는 데 중심을 두고, CloudTrail은 AWS 계정에서 사용자·Role·AWS 서비스가 수행한 활동을 이벤트로 기록해 운영·보안·감사에 활용합니다.
| 구분 | CloudWatch | CloudTrail |
|---|---|---|
| 핵심 목적 | 상태·성능·로그 관찰 | AWS 활동·API 이벤트 감사 |
| 대표 데이터 | Metrics, Logs, Alarm State | Management Event, Data Event 등 |
| 대표 질문 | “왜 느리고 왜 오류가 나는가?” | “누가 언제 어떤 AWS 작업을 했는가?” |
| 장기 보존 | Log Group 보존 정책 등으로 설계 | Trail 또는 CloudTrail Lake로 설계 |
계정 생성 시 별도 Trail 없이도 Event history를 사용할 수 있지만, 90일을 넘는 지속적인 기록이나 Data Event 등이 필요하면 Trail 또는 CloudTrail Lake를 별도로 설계해야 합니다.
조직의 정보보호 정책, 대상 시스템, 필요한 이벤트 종류, 보존 기간, 접근통제와 무결성 요구를 기준으로 Trail·S3·CloudWatch Logs·CloudTrail Lake 등의 조합을 정해야 합니다. AWS는 계정 전반의 활동을 포착하기 위해 Multi-Region Trail을 권장합니다.
운영 Runbook — 경보가 울렸을 때의 확인 순서
좋은 모니터링은 Dashboard가 예쁜 것이 아니라 장애 시 확인 순서가 명확한 것입니다. 아래 순서를 기본 골격으로 두고 서비스 특성에 맞게 세분화합니다.
| 순서 | 확인 | 목적 |
|---|---|---|
| 1 | 영향 범위와 시작 시각 | 전체 장애인지 일부 요청인지 분리 |
| 2 | 사용자 체감 지표 | 5XX, Latency, Request 변화 확인 |
| 3 | 인프라 지표 | ALB, EC2, RDS 병목 위치 확인 |
| 4 | 애플리케이션 로그 | 예외·Timeout·Connection 오류 확인 |
| 5 | CloudTrail | 직전 배포·설정·권한 변경 등 AWS 작업 확인 |
| 6 | 복구 후 지표 확인 | 정상화 여부와 재발 가능성 확인 |