CloudWatch 기반 분석

Table of contents

1. 1. CloudWatch MCP (Model Context Protocol) 기반 분석
   1. 1.1. LAB 개요
   2. 1.2. 시나리오 1: 메트릭 기반 성능 진단
      1. ✅ 실습 목표
      2. 기대 응답
   3. 1.3. 시나리오 2: 로그 기반 이상 탐지
      1. ✅ 실습 목표 CloudWatch Logs Insight를 활용하여 시스템 로그에서 에러 및 패턴을 자동 분석합니다.
      2. 🔍 기대 응답
   4. 1.4. 시나리오 3: 알람 현황 및 히스토리 분석
      1. ✅ 실습 목표
      2. 🔍 기대 응답
   5. 1.5. 시나리오 4: 종합 성능 점검
      1. ✅ 실습 목표
   6. 1.6. 시나리오 5: 용량 계획 자동화
      1. ✅ 실습 목표
   7. 1.7. 시나리오 6: 보안 로그 기반 이상 탐지
      1. ✅ 실습 목표
      2. CloudWatch 로그를 통한 로그인 실패 및 비정상 트래픽 분석합니다.
   8. ✅ 종합 프롬프트 템플릿 예시.
   9. 📘 참고 자료

---

1. CloudWatch MCP (Model Context Protocol) 기반 분석

1.1. LAB 개요

이 랩에서는 Kiro CLI와 CloudWatch MCP 서버를 활용하여 운영 환경의 상태를 분석하고, 실시간 모니터링, 로그 분석, 알람 확인 및 비용 최적화까지 수행하는 과정을 실습합니다.

✅ 목표: AI 기반 분석을 통한 CloudWatch 활용 자동화 이해 및 실무 적용 능력 강화

---

1.2. 시나리오 1: 메트릭 기반 성능 진단

✅ 실습 목표

EC2 인스턴스의 CPU 및 메모리 메트릭을 조회하고, 성능 저하 원인을 분석합니다.

💬 프롬프트 예시:

DMZVPC-Private-A-10.11.20.101 인스턴스의 최근 1시간 CPU 사용률을 조회하고, 
현재 계정의 모든 EC2 인스턴스를 포함한 시각적으로 개선된 CloudWatch 대시보드를 생성하고,
CloudWatch MCP 서버를 활용하여 더 효율적으로 작업해줘.

출력결과 예시: Cloudwatch 대시보드

## 주의사항 및 베스트 프랙티스

### 🔒 보안 고려사항
1. IAM 권한 최소화: CloudWatch 읽기 권한만 부여
2. VPC 보안: 프라이빗 서브넷 인스턴스 접근 제한
3. 모니터링 데이터 암호화: CloudWatch Logs 암호화 활성화

### 💰 비용 최적화
1. 메트릭 보존 기간: 불필요한 장기 보존 방지
2. 상세 모니터링: 필요한 인스턴스만 활성화
3. 알람 최적화: 중복 알람 제거

### 📈 성능 최적화
1. 대시보드 로딩: 위젯 수 제한 (20개 이하 권장)
2. 메트릭 집계: 적절한 Period 설정 (300초 권장)
3. 자동 새로고침: 5분 간격 설정

## 다음 단계

1. 알람 설정: CPU 사용률 80% 이상 시 SNS 알림
2. 로그 통합: CloudWatch Logs와 메트릭 연동
3. 자동화: Lambda를 통한 대시보드 자동 업데이트
4. 비용 모니터링: AWS Cost Explorer 연동
5. 커스텀 메트릭: 애플리케이션별 메트릭 추가

✅ 대시보드가 성공적으로 생성되었습니다! 
AWS 콘솔에서 "EC2-Comprehensive-Monitoring" 대시보드를 확인하실 수 있습니다.

기대 응답

• MCP 도구 사용: get_metric_data
• 시각화된 CPU 사용률 및 분석 요약
• 비용 최적화를 위한 인스턴스 리사이징 제안

---

1.3. 시나리오 2: 로그 기반 이상 탐지

✅ 실습 목표 CloudWatch Logs Insight를 활용하여 시스템 로그에서 에러 및 패턴을 자동 분석합니다.

💬 프롬프트 예시:

/aws/ec2/system-logs 로그 그룹에서 최근 2시간 동안 ERROR가 포함된 로그를 찾아줘.
CloudWatch MCP 서버를 활용하여 더 효율적으로 작업해줘.

출력예시:

# 🚨 CloudWatch Logs ERROR 분석 리포트

## 📊 검색 요약

**검색 시간**: 2025-07-22 13:53 KST  
**검색 범위**: 최근 2시간 (11:53 ~ 13:53 UTC)  
**리전**: ap-northeast-2  
**검색 키워드**: ERROR, Error, error  

## 🎯 주요 발견사항

### ✅ 검색 결과 요약
| 로그 그룹 | ERROR 로그 수 | 상태 |
|-----------|---------------|------|
| `/aws/eks/eksworkshop/cluster` | **43개** | 🚨 **주의 필요** |
| `/aws/lambda/DMZVPC-retrieve-vpceid` | 0개 | ✅ 정상 |
| `/aws/lambda/cfn-EksWorkshopC9BootstrapInstanceLambdaFunction-gDaUjqLVmAJN` | 0개 | ✅ 정상 |
| `/DMZVPC/FWIN/alert` | 0개 | ✅ 정상 |
| `/DMZVPC/FWOUT/alert` | 0개 | ✅ 정상 |

## 🔍 상세 분석

### 🚨 EKS 클러스터 연결 오류 (43개 ERROR)

**문제 유형**: gRPC 연결 실패  
**영향 범위**: EKS 클러스터 내부 통신  
**심각도**: ⚠️ 중간 (Warning 레벨)
이하생략....

🔍 기대 응답

• MCP 도구 사용: execute_log_insights_query
• 시간대별 에러 수, 에러 유형 분포, 관련 리소스 식별
• 원인 패턴 분석 및 조치 제안

---

1.4. 시나리오 3: 알람 현황 및 히스토리 분석

✅ 실습 목표

활성 알람 목록 조회 및 특정 알람의 이력 분석

💬 프롬프트 예시:

현재 ALARM 상태인 모든 알람을 조회해줘
High-CPU-Usage 알람의 최근 24시간 히스토리를 분석해줘.

출력예시:

## 주요 발견사항 및 권장사항

### 🎯 현재 상황 요약
1. ALARM 상태 알람: 현재 0개 (모든 시스템 정상)
2. 총 알람 수: 4개 (High-CPU-Usage, Low-CPU-Usage, Status-Check-Failed, High-Network-In)
3. 정상 상태: 1개 (High-CPU-Usage)
4. 데이터 부족: 3개 (초기 생성으로 데이터 수집 중)

### 📈 High-CPU-Usage 알람 분석
• **상태 변화**: INSUFFICIENT_DATA → OK (22초 만에 정상 전환)
• **현재 CPU 사용률**: ~1% (매우 안정적)
• **임계값**: 80% (적절한 설정)
• **응답성**: 매우 빠름 (22초)

### 🔧 즉시 권장사항
1. SNS 통합: 실시간 알림을 위한 이메일/SMS 설정
2. 15분 후 재확인: 데이터 부족 알람들의 상태 변화 모니터링
3. 대시보드 통합: 기존 EC2 대시보드에 알람 상태 위젯 추가

### 💡 장기 개선사항
1. 추가 메트릭: 메모리, 디스크 사용률 모니터링
2. 자동화: cron을 통한 정기 점검 및 리포트
3. 임계값 최적화: 과거 데이터 기반 동적 임계값 설정

✅ 결론: 현재 모든 시스템이 정상 상태로 운영되고 있으며, 알람 시스템이 올바르게 작동하고 있습니다. 추가 데이터 수집 완료 후 전체 모니터링 시스템이 완전히 활성화될 예정입니다.

🔍 기대 응답

• 활성 알람 수 및 상태 정리
• 알람 발생 추이, 원인 변화 분석

---

1.5. 시나리오 4: 종합 성능 점검

✅ 실습 목표

지정된 인스턴스에 대해 메트릭 + 로그 + 알람 데이터를 종합 분석합니다.

💬 프롬프트 예시:

DMZVPC-Private-A-10.11.20.101에 대해서 다음을 분석해주세요:
1. 최근 4시간 동안의 CPU, 메모리, 네트워크, 디스크 사용률
2. 같은 시간대의 에러 로그 패턴

출력예시:

## 🎯 종합 분석 결과

### 📊 시스템 리소스 사용률 (최근 4시간)

#### 1. CPU 사용률 - 매우 안정적 ✅
• **평균**: 0.99% (거의 유휴 상태)
• **최대**: 1.11% (13:50 UTC)
• **변동폭**: 0.17% (매우 안정적)
• **상태**: 정상, 추가 워크로드 처리 여유 충분

#### 2. 네트워크 사용률 - 정상 범위 ✅
• **Network In**: 평균 8.7KB/5분 (약 29 bytes/초)
• **Network Out**: 평균 38.1KB/5분 (약 127 bytes/초)
• **총 트래픽**: 4시간 동안 약 11.3MB
• **패턴**: 안정적, 간헐적 스파이크 (12:05, 13:05, 13:35 UTC)

#### 3. 디스크 I/O - 거의 없음 ✅
• **읽기 작업**: 0 IOPS (모든 시간대)
• **쓰기 작업**: 데이터 수집 중
• **상태**: 매우 안정적, 디스크 부하 없음

#### 4. 메모리 사용률 - 모니터링 필요 ⚠️
• **현재 상태**: 기본 CloudWatch에서 수집되지 않음
• **권장사항**: CloudWatch Agent 설치 필요

### 🚨 에러 로그 패턴 분석 (최근 4시간)

#### 주요 발견사항
• **총 에러 로그**: 85개 (EKS 클러스터 관련)
• **주요 패턴**: gRPC 인증 실패 (70%), 네트워크 연결 종료 (30%)
• **영향 범위**: EKS API Server ↔ etcd 클러스터 통신
• **심각도**: 중간 (서비스 중단 없음, 모니터링 필요)

---

1.6. 시나리오 5: 용량 계획 자동화

✅ 실습 목표

최근 30일 데이터를 기반으로 EC2 용량 계획 수립합니다.

💬 프롬프트 예시:

다음 조건으로 용량 계획을 수립해주세요:
- 대상: ap-northeast-2 리전의 모든 EC2 인스턴스
- 기간: 최근 30일간 데이터
- 분석 항목: CPU, 메모리, 네트워크 사용률 트렌드
- 결과: 리소스 부족 예상 시점과 스케일링 권장사항

출력예시:

## 용량 계획 분석 결과

### 현재 리소스 사용률 패턴

CPU 사용률 분석:
• **t3.small 인스턴스**: 평균 1.1-1.4%, 최대 30% (부팅 시)
• **m6i.xlarge (EKS)**: 평균 0.78-0.99%, 최대 12.6% (부팅 시)
• **매우 낮은 CPU 사용률**로 과도한 프로비저닝 상태

네트워크 사용률:
• 평균 8-9KB/시간 (매우 낮음)
• 부팅 시 최대 314MB (초기 설정 트래픽)
• 정상 운영 시 최대 21KB/시간

### 용량 계획 권장사항

1. 즉시 최적화 가능 영역:
bash
# 현재 과도한 프로비저닝 상태
- t3.small (24개): CPU 사용률 1-2% → t3.nano 또는 t3.micro로 다운사이징 가능
- 예상 비용 절감: 약 40-60%


2. EKS 클러스터 최적화:
bash
# EKS 워커 노드 (8개 m6i.xlarge)
- 현재 CPU 사용률: 0.8% 미만
- 권장: Cluster Autoscaler 활성화 + Spot 인스턴스 활용
- 최소 2-3개 노드로 축소 가능


3. 리소스 부족 예측 시점:
bash
# 현재 사용률 기준 예측
- CPU: 현재 사용률이 매우 낮아 단기간 내 부족 가능성 없음
- 네트워크: 대역폭 여유 충분
- 메모리: 별도 분석 필요 (CloudWatch Agent 설치 권장)


## 주의사항 및 베스트 프랙티스

즉시 조치 필요:
• 인스턴스 타입 다운사이징 전 메모리 사용률 확인 필수
• 애플리케이션 성능 테스트 후 단계적 적용
• CloudWatch 상세 모니터링 활성화

모니터링 강화:
• CloudWatch Agent 설치로 메모리, 디스크 사용률 수집
• 커스텀 메트릭으로 애플리케이션 레벨 모니터링
• 알람 설정으로 임계치 도달 시 자동 알림

## 다음 단계

1. 메모리 사용률 분석을 위한 CloudWatch Agent 설치
2. 단계적 인스턴스 타입 최적화 실행
3. EKS 클러스터 오토스케일링 설정
4. 비용 최적화 효과 측정 및 모니터링

현재 인프라는 상당한 비용 최적화 여지가 있으며, 리소스 부족보다는 과도한 프로비저닝이 주요 이슈입니다.

---

1.7. 시나리오 6: 보안 로그 기반 이상 탐지

✅ 실습 목표

CloudWatch 로그를 통한 로그인 실패 및 비정상 트래픽 분석합니다.

💬 프롬프트 예시:

보안 상태를 종합적으로 분석해주세요:
1. 최근 24시간 로그인 실패 시도 패턴
2. 권한 관련 에러 발생 현황
3. 비정상적인 네트워크 활동 탐지
4. 보안 점수 산정 및 개선 방안
보안 상태를 종합적으로 분석할 수 있는 CloudWatch 대시보드를 뷰티파이해서 생성해 주세요.

출력예시:

## 종합 보안 상태 분석 결과

### 1. 최근 24시간 로그인 실패 시도 패턴

✅ 양호한 상태
• 콘솔 로그인 실패 이벤트: 0건
• 인증 관련 이상 활동: 탐지되지 않음
• 모든 AssumeRole 이벤트는 정상적인 AWS 서비스 간 통신

주요 발견사항:
• EKS 서비스 역할 승계: 정상적인 클러스터 운영 활동
• EC2 인스턴스 역할 승계: SSM 및 노드 관리를 위한 정상 활동
• Network Firewall 서비스 역할: 보안 정책 적용을 위한 정상 동작

### 2. 권한 관련 에러 발생 현황

✅ 매우 양호한 상태
• AccessDenied 이벤트: 0건
• 권한 거부 관련 보안 이슈: 없음
• IAM 역할 및 정책 설정: 적절히 구성됨

### 3. 비정상적인 네트워크 활동 탐지

⚠️ 주의 필요

보안 그룹 분석 결과:
bash
# 높은 위험도 설정 발견
- SSH (22번 포트): 0.0.0.0/0 오픈 (12개 보안 그룹)
- HTTP (80번 포트): 0.0.0.0/0 오픈 (10개 보안 그룹)
- HTTPS (443번 포트): 0.0.0.0/0 오픈 (10개 보안 그룹)
- VSCode 서버 (8888번 포트): 0.0.0.0/0 오픈 (1개 보안 그룹)


네트워크 모니터링 상태:
• VPC Flow Logs: 비활성화 (보안 모니터링 취약)
• 네트워크 트래픽 분석: 제한적

### 4. 보안 점수 산정

전체 보안 점수: 65/100

점수 세부 내역:
• **인증 보안 (25/25점)**: 로그인 실패 없음, 정상적인 역할 승계
• **권한 관리 (20/20점)**: 권한 거부 이벤트 없음, IAM 정책 적절
• **네트워크 보안 (15/35점)**: 과도한 포트 오픈, Flow Logs 미설정
• **모니터링 (5/20점)**: 기본 CloudTrail만 활성화, 상세 로깅 부족

### 5. 보안 개선 방안
이하 생략

---

✅ 종합 프롬프트 템플릿 예시.

💬 프롬프트 예시:

오늘의 시스템 상태를 점검해주세요:
- 시간 범위: 오늘 00:00 ~ 현재
- 점검 항목: 활성 알람, 주요 메트릭 이상치, 에러 로그
- 결과 형식: 요약 + 상세 분석 + 권장 조치사항

💬 프롬프트 예시:

[시간]에 발생한 장애를 분석해주세요:
1. 장애 시점 전후 30분간 모든 메트릭 변화
2. 관련 에러 로그와 패턴 분석
3. 알람 발생 순서와 연관성
4. 근본 원인과 재발 방지 방안

💬 프롬프트 예시:

[인스턴스 ID]의 성능을 벤치마킹해주세요:
- 비교 기준: 지난주 같은 시간대
- 메트릭: CPU, 메모리, 네트워크, 디스크 I/O
- 분석: 성능 변화 추이와 원인 분석

---

📘 참고 자료

• Amazon CloudWatch 공식 문서
• Amazon Q Developer CLI 가이드
• CloudWatch MCP GitHub 프로젝트

---