AWS Certified CloudOps Engineer - Associate (SOA-C03) #3 Domain 1-2 모니터링: CloudWatch Logs,Logs Insights,에이전트

2026년 5월 28일 목요일

5 분 소요

#2에서 지표로 “무슨 일이 일어났는지"를 정리했습니다. 지표는 숫자라 빠르게 추세를 보지만, 왜 그 일이 일어났는지는 알려주지 않습니다. 그 답은 로그에 있습니다. 이 글은 CloudWatch Logs의 구조와, 로그를 수집,분석,전달하는 운영 흐름을 정리하겠습니다.

로그의 구조: 로그 그룹과 로그 스트림 #

CloudWatch Logs는 두 단계로 로그를 정리합니다.

개념	설명	예시
Log Group	같은 종류 로그의 묶음. 보존,권한,암호화의 단위	`/aws/lambda/my-func`, `/var/log/nginx`
Log Stream	한 소스(인스턴스,컨테이너,함수 호출)의 로그 흐름	인스턴스 ID별 스트림

설정의 단위는 로그 그룹입니다. 보존 기간, KMS 암호화, 접근 권한을 로그 그룹에 겁니다. 로그 스트림은 그 안에서 소스별로 나뉘는 실제 줄들입니다.

보존 기간과 비용 #

로그 그룹의 기본 보존은 무기한입니다. 즉 설정을 안 하면 로그가 영원히 쌓여 저장 비용이 계속 늘어납니다. 운영에서는 로그 그룹마다 보존 기간(예: 30일, 90일)을 정하는 것이 기본입니다. 장기 보관이 필요하면 S3로 내보내 더 싼 스토리지 클래스에 두는 것이 정석입니다.

“로그 비용이 계속 증가한다"는 시나리오의 1차 답은 보존 기간 설정, 장기 보관은 S3 export + 라이프사이클입니다.

CloudWatch Agent: 로그와 OS 지표 수집 #

EC2나 온프레미스 서버의 로그 파일과 OS 지표는 기본으로 CloudWatch에 들어오지 않습니다. CloudWatch Agent를 설치해야 합니다.

로그 수집: /var/log/... 같은 파일을 지정한 로그 그룹으로 전송
OS 지표 수집: #2에서 본 메모리,디스크 사용률을 사용자 지정 지표로 게시
설정: 에이전트 설정 파일(JSON). Systems Manager Parameter Store에 설정을 저장해 여러 인스턴스에 일관 배포하는 것이 권장 패턴
권한: 인스턴스에 CloudWatchAgentServerPolicy가 붙은 IAM Role 필요

시험에서 “여러 EC2에 동일한 에이전트 설정을 일관되게 배포하라"는 답은 보통 SSM Parameter Store에 설정 저장 + SSM으로 에이전트 배포입니다.

지표 필터(Metric Filter): 로그에서 지표 뽑기 #

로그는 텍스트지만, 그 안에서 특정 패턴의 등장 횟수를 지표로 변환할 수 있습니다. 이것이 지표 필터입니다.

예를 들어 애플리케이션 로그에서 ERROR 문자열을 세어 ErrorCount 지표를 만들고, 그 지표에 알람을 겁니다.

필터 패턴: "ERROR"
→ 지표: MyApp/ErrorCount
→ 알람: 5분간 ERROR 10건 초과 시 SNS 알림

핵심은 로그 자체에는 알람을 걸 수 없다는 점입니다. 로그를 지표로 바꾼 다음 그 지표에 알람을 거는 순서입니다. “로그에 특정 메시지가 나타나면 알림"이라는 요구의 표준 구현이 지표 필터 + 알람입니다.

Logs Insights: 로그 쿼리 #

Logs Insights는 대량의 로그를 SQL과 유사한 쿼리로 분석하는 도구입니다.

fields @timestamp, @message
| filter @message like /ERROR/
| stats count(*) by bin(5m)
| sort @timestamp desc

지표 필터가 “미리 정한 패턴을 상시 집계"한다면, Logs Insights는 사후에 즉석으로 파고드는 도구입니다. “장애가 난 시간대의 로그를 분석해 원인을 찾아라"는 트러블슈팅 시나리오의 답이 Logs Insights입니다. 여러 로그 그룹을 한 번에 쿼리할 수 있습니다.

구독 필터(Subscription Filter): 로그 실시간 전달 #

로그가 들어오는 즉시 다른 대상으로 흘려보내는 구성입니다. 대상은 다음이 될 수 있습니다.

대상	용도
Lambda	로그를 실시간 가공,알림,전달
Kinesis Data Streams	대용량 로그를 스트림으로 처리
Kinesis Data Firehose	S3,OpenSearch 등으로 적재
OpenSearch	로그 검색,시각화(Kibana)

“로그를 실시간으로 분석 시스템에 보내라"거나 “여러 계정의 로그를 한 곳으로 모아라"는 요구의 답이 구독 필터입니다. 교차 계정 로그 수집도 구독 필터로 구성합니다.

로그 보안: 암호화와 접근 #

암호화: 로그 그룹에 KMS 키를 연결해 저장 시 암호화. 민감 로그의 컴플라이언스 요구를 충족
접근 제어: 로그 그룹에 대한 읽기,쓰기 권한을 IAM으로 통제
CloudTrail과의 관계: API 호출 기록인 CloudTrail 로그도 CloudWatch Logs로 보내 지표 필터,알람을 걸 수 있음. 예를 들어 “루트 계정 로그인 시 알림"은 CloudTrail → CloudWatch Logs → 지표 필터 → 알람으로 구현

시험 출제 패턴 #

로그 비용이 계속 증가 → 로그 그룹 보존 기간 설정, 장기 보관은 S3 export
여러 EC2에 에이전트 설정 일관 배포 → SSM Parameter Store + SSM 배포
로그에 특정 메시지가 나오면 알림 → 지표 필터 + 알람
장애 시간대 로그를 사후 분석 → Logs Insights
로그를 실시간 다른 시스템으로 전달 → 구독 필터(Lambda,Kinesis,OpenSearch)
루트 로그인,권한 변경 같은 API 이벤트 감시 → CloudTrail → CloudWatch Logs → 지표 필터

자주 만나는 함정 #

1) 로그에 직접 알람을 건다고 생각 #

CloudWatch 알람은 지표에만 걸립니다. 로그는 지표 필터로 지표화한 뒤에야 알람 대상이 됩니다.

2) 에이전트 없이 로그가 수집된다고 오해 #

Lambda,ECS 같은 관리형 서비스는 로그를 자동으로 보내지만, EC2,온프레미스의 파일 로그는 CloudWatch Agent가 있어야 들어옵니다.

3) 기본 보존이 짧다고 가정 #

기본 보존은 짧은 게 아니라 무기한입니다. 비용 관리를 위해 명시적으로 줄여야 합니다.

4) Logs Insights를 상시 집계로 쓰려 함 #

Logs Insights는 즉석 쿼리 도구입니다. 상시 모니터링과 알람은 지표 필터로 지표를 만들어 거는 쪽이 맞습니다.

정리 #

이번 글에서 잡은 것:

로그는 로그 그룹(설정 단위)과 로그 스트림(소스별)으로 구성. 보존,암호화,권한은 로그 그룹에
기본 보존은 무기한 → 비용 관리 위해 보존 기간 설정, 장기 보관은 S3 export
CloudWatch Agent로 EC2 파일 로그와 메모리,디스크 지표 수집. 설정은 SSM Parameter Store로 일관 배포
지표 필터로 로그를 지표화해 알람. 로그 자체에는 알람을 못 걺
Logs Insights는 사후 즉석 쿼리(트러블슈팅), 구독 필터는 실시간 전달(Lambda,Kinesis,OpenSearch)
CloudTrail 로그를 CloudWatch Logs로 보내 API 이벤트 알람 구성

다음: Domain 1-3 자동 복구와 성능 최적화 #

지표와 로그로 감지까지 정리했으니, 다음은 감지 이후의 자동 대응입니다.

#4 Domain 1-3 모니터링: 자동 복구와 성능 최적화에서는 EventBridge로 이벤트에 반응하는 법, Systems Manager Automation으로 복구를 자동화하는 법, EC2 자동 복구와 Auto Scaling의 자가 치유, 그리고 Compute Optimizer,CloudWatch로 성능을 진단하고 최적화하는 흐름까지 정리하겠습니다.