Amazon CloudWatch
CloudWatch 핵심 구성 요소
•
Metrics → 수치 데이터 (CPU, 메모리, 요청 수)
•
Logs → 텍스트 로그 데이터
•
Alarms → 임계값 초과 시 자동 조치
•
Dashboards → 단일 뷰로 시각화
CloudWatch Metrics
•
기본 모니터링 (무료)
◦
EC2 → 5분 간격 (CPU, 네트워크, 디스크 I/O)
◦
단, 메모리/디스크 사용률은 기본 제공 
→ CloudWatch Agent 설치 필요
•
상세 모니터링 (유료)
◦
EC2 → 1분 간격
◦
Auto Scaling 빠른 반응에 필요
•
커스텀 메트릭
◦
PutMetricData API로 직접 발행
◦
Standard: 1분 단위
◦
High Resolution: 1초 단위 (추가 비용)
EC2 메모리 사용률 모니터링 → 기본 제공 → CloudWatch Agent 필수 설치
→ CloudWatch Agent 필수 설치시험에 자주 나오는 함정
CloudWatch Logs
•
구조
◦
Log Group → 로그 컨테이너 (서비스 단위)
└── Log Stream → 실제 로그 흐름 (인스턴스 단위)
•
보존 기간: 기본 무기한 → 비용 절감 위해 반드시 설정 (1일 ~ 10년 설정 가능)
•
Logs Insights:
◦
CloudWatch Logs를 SQL 유사 쿼리로 분석
◦
예: 특정 에러 로그 집계, 요청 지연 분포 분석
•
Metric Filter:
◦
로그에서 패턴 감지 → 커스텀 메트릭 생성
◦
예: “ERROR” 키워드 감지 → 에러 카운트 메트릭 → Alarm
CloudWatch Alarms
•
Alarm 상태
◦
OK → 임계값 이하 정상
◦
ALARM → 임계값 초과
◦
INSUFFICIENT_DATA → 데이터 부족 (시작 직후)
•
Alarm 액션
◦
SNS 알림 (이메일/슬랙)
◦
Auto Scaling 트리거
◦
EC2 액션 (중지/재시작/종료/복구)
◦
Systems Manager OpsCenter 생성
•
Composite Alarm
◦
여러 Alarm을 AND/OR 조건으로 결합
◦
예: CPU > 80% AND Mem > 70% → 알람
→ 개별 알람 노이즈 감소
→ 더 정확한 장애 탐지
여러 조건을 동시에 만족할 때만 알람 → Composite Alarm
CloudWatch Anomaly Detection
•
ML 기반 정상 패턴 자동 학습
→ 예상 범위 벗어난 값 탐지
→ 고점 임계값 설정이 어려운 지표에 유용 (트래픽이 시간대 별로 크게 다를 때)
AWS X-Ray
X-Ray = 분산 추적 서비스
마이크로서비스 아키텍처에서 요청이 여러 서비스를 거칠 때
각 서비스의 지연 시간, 에러, 병목 지점을 시각화
•
예: API GW → Lambda A → DynamoDB → Lambda B → RDS → 외부 API
◦
X-Ray 없이: 어디서 느린지 모름
◦
X-Ray 있음: Lambda B → RDS 구간이 850m로 병목
X-Ray 핵심 개념
•
Trace
◦
하나의 요청이 전체 시스템을 통과하는 여정
◦
여러 Segment로 구성
•
Segment
◦
각 서비스(Lambda, EC2, RDS 등)의 처리 단위
◦
시작 시간, 종료 시간, 에러 여부 포함
•
Subsegment
◦
Segment 내 세부 작업
◦
예: Lambda 내 DynamoDB 호출, 외부 API ghcnf
•
Service Map
◦
서비스 간 관계와 지연 시간을 시각화한 그래프
◦
병목 지점, 에러 발생 서비스 즉시 식별 가능
X-Ray 적용 방법
•
EC2 / ECS
1.
X-Ray SDK로 코드 계측 (Instrumentation)
2.
X-Ray Daemon 설치 (UDP 2000 포트로 데이터 수집)
•
Lambda
1.
Lambda 콘솔에서 Active Tracing 활성화
2.
X-Ray SDK로 커스텀 Segment 추가 가능
→ Daemon 설치 불피요 (Lambda가 자동 관리)
Sampling Rule
모든 요청을 추적하면 비용 급증
•
기본: 첫 요청/초 + 추가 5% 샘플링
•
커스텀 규칙으로 중요 경로 100% 추적 가능
마이크로서비스 어디서 지연 발생하는지 파악 → X-Ray
Lambda 추적 → Active Tracing 활성화
EC2에서 X-Ray 사용 → X-Ray Daemon 설치 필수
AWS Config
Config 핵심 기능
Config = 리소스 구성 이력 + 구정 준수 감사
•
리소스 구성 이력 추적: “이 보안 그룹이 언제 변경됐나?”
•
Config Rules로 규정 준수 평가: “모든 S3 버킷이 암호화되어 있는가?”
•
자동 수정 (Auto Remediation): “비준수 리소스 자동으로 수정”
Config Rules 유형
•
AWS 관리형 규칙 (Managed Rules)
◦
사전 정의된 규칙 (~300개)
◦
예시
▪
s3-bucket-public-read-prohibited
▪
ec2-instance-no-public-ip
▪
root-account-mfa-enabled
•
커스텀 규칙
◦
Lambda 함수로 직접 구현
◦
기업 고유 정책 적용
•
평가 트리거
◦
Configuration Change → 리소스 변경 시 즉시 평가
◦
Periodic → 주기적으로 평가 (1h/3h/6h/12h/24h)
Config + AutoRemediation
비준수 리소스 발견
│
▼
Config Rule → NON_COMPLIANT 표시
│
▼
Auto Remediation 트리거
│
├── SSM Automation Document 실행
│ 예: S3 퍼블릭 접근 자동 차단
│ 보안 그룹 위반 규칙 자동 삭제
└── Lambda 함수 실행
Retry 설정:
자동 수정 실패 시 재시도 횟수 지정
Plain Text
복사
Config Conformance Pack
여러 Config Rules + 수정 작업을 하나의 패키지로 관리
•
사용 사례:
◦
CIS AWS Foundations Benchmark
◦
PCI DSS 규정 준수 팩
◦
HIPAA 규정 준수 팩
•
Organizations 연동
◦
Management Account에서 전체 계정에 일괄 배포
→ StackSets와 유사한 방식
리소스 변경 이력 추적 → Config
비준수 리소스 자동 수정 → Config + Auto Remediation (SSM)
전체 계정에 규정 준수 정책 배포 → Config Conformance Pack
CloudTrail vs Config
CloudTrail → API 호출 이력 (누가 뭘 했나)
Config → 리소스 구성 이력 (무엇이 어떻게 바뀌었나)
AWS CloudTrail
CloudTrail 이벤트
•
Management Events (기본 활성화, 무료)
◦
AWS 리소스에 대한 관리 작업
◦
예: EC2 인스턴스 생성/삭제, IAM 정책 변경
→ “누가 뭘 만들고 삭제했나”
•
Data Events (별도 활성화, 유료)
◦
리소스 내 데이터 작업
◦
예: S3 GetObject/PutObjet, Lambda 함수 실행
→ “어떤 파일을 읽고 썼나”
•
Insights Events (별도 활성화, 유료)
◦
비정상적인 API 호출 패턴 자동 탐지
→ 갑작스러운 대량 EC2 생성 탐지
→ 비정상 IAM 활동 감지
CloudTrail + EventBridge 자동화 패턴
CloudTrail API 이벤트
│
▼
EventBridge Rule (패턴 매칭)
│
├── "루트 계정 로그인 감지" → SNS → 보안팀 이메일
├── "IAM 정책 변경 감지" → Lambda → Slack 알림
└── "보안 그룹 변경 감지" → Lambda → 자동 롤백
Plain Text
복사
특정 API 호출 시 자동 알림/조치 → CloudTrail + EventBridge + Lambda/SNS
Systems Manager 운영 자동화
핵심 기능
•
Session Manager → SSH 없이 EC2 접속
•
Parameter Store → 설정값 저장
•
Patch Manager → OS 패치 자동화
•
Run Command → 다수 인스턴스 명령 일괄 실행
Systems Manager Automation
복잡한 운영 작업을 단계별 자동화
•
Automation Document (Runbook)
◦
AWS 사전 정의 Runbook (~700개)
◦
예시
▪
AWS-RestartEC2Instance
▪
AWS-CreateSnapshot
▪
AWS-UpdateLinuxAmi
•
활용 패턴
◦
Config Auto Remediation → SSM Automation 실행
◦
EventBridge → SSM Automation tlfgod
◦
수동 승인 단계 포함 가능 (Approval Step)
•
예시 워크플로우
◦
Config: 비암호화 EBS 볼륨 탐지
◦
Auto Remediation → SSM Automation 실행
◦
SSM: 스냅샷 생성 → 암호화된 볼륨 생성 → 교체
Maintenance Window
정기 유지보수 작업 스케줄링
•
예시: 매주 일요일 02:00 ~ 04:00
→ Patch Manager 실행
→ 재시작이 필요한 패치 적용
→ 서비스 영향 최소화 시간대 선택
AWS Health Dashboard
•
AWS Personal Health Dashboard
◦
내 계정에 영향을 주는 AWS 서비스 이벤트 알림
◦
예: “ap-northeast-2 EC2에 영향을 주는 이슈 발생”
•
활용 패턴:
◦
EventBridge → AWS Health 이벤트 감지
→ Lambda → 자동 Failover 트리거
→ SNS → 운영팀 알림
•
AWS Service Health Dashboard
◦
전체 AWS 서비스 상태 (공개)
→ 내 계정 특정 이슈는 Personal Health Dashboard
Summary
개념 | 한 줄 요약 |
EC2 메모리 메트릭 | 기본 제공 → CloudWatch Agent 설치 필수 |
Composite Alarm | 여러 알람 AND/OR 조건 결합 → 노이즈 감소 |
CloudWatch Anomaly Detection | ML 기반 정상 패턴 학습, 고정 임계값 불필요 |
X-Ray Trace | 하나의 요청이 전체 시스템 통과하는 여정 |
X-Ray Service Map | 서비스 간 의존성·지연 시각화 |
X-Ray Daemon | EC2/ECS에서 필수 설치. Lambda는 자동 |
Config vs CloudTrail | Config=구성 변경 이력, CloudTrail=API 호출 이력 |
Config Auto Remediation | 비준수 → SSM Automation 자동 실행 |
Config Conformance Pack | 여러 Rules 패키지, 전체 계정 일괄 배포 |
CloudTrail Insights | 비정상 API 호출 패턴 자동 탐지 |
SSM Automation | 복잡한 운영 작업 단계별 자동화 Runbook |
EventBridge + CloudTrail | 특정 API 호출 감지 → 자동 조치 |