모니터링 & 운영 자동화

CloudWatch 관측과 CloudTrail 감사를 운영 자동화 대응으로 연결하는 흐름

운영 중인 서비스에서 지표·로그·추적은 서로 다른 질문에 답한다. CloudWatch는 상태와 로그를 관찰하고, CloudTrail은 누가 어떤 API 작업을 했는지 남기며, X-Ray는 요청 흐름을 추적한다. 이 신호를 Systems Manager나 EventBridge와 연결하면 반복 작업을 자동화할 수 있다.

1. CloudWatch

핵심 구성 요소

CloudWatch
  ├── Metrics    — 수치 지표 (CPU, 네트워크, 커스텀)
  ├── Logs       — 로그 수집, 저장, 검색
  ├── Alarms     — 지표 기반 경보 → 액션
  ├── Dashboards — 시각화
  └── Events     — (현재는 EventBridge로 통합)

CloudWatch Metrics

AWS 서비스는 기본 지표를 자동으로 CloudWatch에 전송한다.

EC2 기본 지표 (5분 간격)

  • CPU 사용률, 네트워크 인/아웃, 디스크 읽기/쓰기, 상태 체크

EC2에서 기본 제공하지 않는 지표 → CloudWatch Agent 필요

  • 메모리 사용률
  • 디스크 사용률(%)
  • 프로세스 수

SAP 핵심: 메모리, 디스크 사용률은 기본 지표가 아님 → CloudWatch Agent 설치 + 커스텀 지표

상세 모니터링 (Detailed Monitoring)

  • 기본: 5분 간격
  • 상세 모니터링 활성화: 1분 간격 (추가 비용)
  • Auto Scaling + 빠른 반응이 필요하면 상세 모니터링 활성화

커스텀 지표

  • PutMetricData API로 애플리케이션 지표 전송
  • 표준 해상도: 1분 / 고해상도: 1초 단위

CloudWatch Logs

로그 수집 경로

EC2 애플리케이션 → CloudWatch Agent → Log Group → Log Stream
Lambda           → 자동 전송
ECS/EKS          → awslogs 드라이버
API Gateway      → 활성화 후 전송
VPC Flow Logs    → CloudWatch Logs or S3

주요 개념

개념 설명
Log Group 로그의 논리적 컨테이너 (보존 기간 설정)
Log Stream 단일 소스의 로그 시퀀스
Metric Filter 로그에서 패턴 검색 → 커스텀 지표 생성
Insights SQL 유사 쿼리로 로그 분석
Subscription Filter 실시간 로그를 Lambda/Kinesis/Firehose로 전달

Metric Filter 활용 예시

로그에서 "ERROR" 패턴 검색
  → 카운트 지표 생성
    → CloudWatch Alarm
      → SNS 알림

로그 보존 및 내보내기

  • 기본 보존: 무제한 (비용 발생)
  • 보존 기간 설정: 1일 ~ 10년
  • S3로 내보내기: 배치 처리 (실시간 아님)
  • 실시간 S3 전달: Subscription Filter → Kinesis Firehose → S3

CloudWatch Alarms

경보 상태:

  • OK: 정상 범위
  • ALARM: 임계값 초과
  • INSUFFICIENT_DATA: 데이터 부족

경보 액션

액션 내용
SNS 알림 이메일, SMS, Lambda 트리거
EC2 액션 인스턴스 중지, 재시작, 종료, 복구
Auto Scaling 스케일 아웃/인
Systems Manager OpsItem 생성

복합 경보 (Composite Alarm)

  • 여러 경보를 AND/OR 조합
  • 알람 노이즈 감소 (개별 경보가 아닌 조합 조건에서만 알림)
경보 A (CPU > 90%) AND 경보 B (네트워크 > 1GB)
  → 복합 경보 트리거 → SNS

CloudWatch Synthetics

  • 카나리아(Canary) 스크립트로 엔드포인트 주기적 테스트
  • 실제 사용자처럼 URL 접속, API 호출, UI 클릭 시뮬레이션
  • 장애를 사용자보다 먼저 탐지

2. CloudTrail

핵심 개념

CloudTrail은 AWS 계정의 모든 API 호출 기록을 남긴다. "누가, 언제, 어디서, 무엇을 했는가"에 대한 감사 로그다.

사용자/서비스 → API 호출 → CloudTrail → S3 (장기 보존)
                                      → CloudWatch Logs (실시간 분석)

이벤트 유형

유형 내용 기본 기록
Management Events 리소스 생성·수정·삭제 (Control Plane) O (무료)
Data Events S3 객체 읽기/쓰기, Lambda 실행 X (별도 활성화, 비용)
Insights Events 비정상적인 API 활동 패턴 탐지 X (별도 활성화)

Trail 유형

  • 단일 리전 Trail: 한 리전만 기록
  • 멀티 리전 Trail: 모든 리전 기록 (권장)
  • Organization Trail: 전체 계정 통합 기록

CloudTrail Insights

  • 비정상적인 API 호출량 자동 탐지
  • 예: 특정 시간대에 갑자기 EC2 인스턴스를 대량 생성

CloudTrail 로그는 기본 90일 보존. 장기 보관은 S3 + Glacier 수명 주기 정책 적용

3. X-Ray

핵심 개념

X-Ray는 분산 시스템의 요청 흐름을 추적한다. 마이크로서비스 환경에서 어느 서비스가 병목인지, 오류가 어디서 발생했는지 시각화한다.

사용자 요청
  → API Gateway (50ms)
    → Lambda (200ms)
      → DynamoDB (30ms)
      → S3 (15ms)
    → 외부 API (500ms) ← 병목!

X-Ray 구성 요소

개념 설명
Trace 요청 전체 경로 (End-to-End)
Segment 각 서비스의 처리 구간
Subsegment Segment 내 세부 작업
Sampling 모든 요청이 아닌 일부만 추적 (비용 절감)
Service Map 서비스 간 의존관계 시각화

X-Ray 활성화 방법

  • EC2: X-Ray 데몬 설치 + SDK 코드 삽입
  • Lambda: 활성 추적(Active Tracing) 설정만으로 자동
  • ECS: 사이드카 컨테이너로 X-Ray 데몬 실행

4. Systems Manager (SSM)

핵심 개념

SSM은 EC2 인스턴스(및 온프레미스 서버)를 에이전트 기반으로 중앙 관리한다. SSH 접속 없이 명령 실행, 패치, 설정 관리가 가능하다.

SSM Agent (EC2에 설치)
  ↑↓ HTTPS (포트 443)
AWS Systems Manager

EC2에 퍼블릭 IP, 인터넷 게이트웨이 없어도 SSM으로 관리 가능 (프라이빗 서브넷 → VPC Endpoint for SSM)

주요 기능

Session Manager

  • SSH, 키페어 없이 EC2에 브라우저/CLI로 접속
  • 모든 세션 기록 → S3 또는 CloudWatch Logs
  • 보안 그룹 인바운드 22번 포트 불필요

SAP 핵심: 배스천 호스트 없이 프라이빗 EC2 접근 = Session Manager

Run Command

  • 여러 EC2에 동시에 셸 명령/스크립트 실행
  • 태그, 인스턴스 ID, OU 기반 타겟 지정
  • 실행 결과 CloudWatch Logs로 전송

Patch Manager

  • OS 패치 자동 적용 (Patch Baseline 정의)
  • 유지보수 창(Maintenance Window)에 맞춰 스케줄 실행
  • 패치 준수율 리포트 자동 생성

Parameter Store

  • 09편에서 다룬 설정값·비밀 저장소
  • SSM과 통합되어 Run Command, Lambda 등에서 직접 참조 가능

Inventory

  • EC2에 설치된 소프트웨어, 네트워크 설정, OS 정보 자동 수집
  • AWS Config와 연동해 변경 이력 추적

State Manager

  • EC2의 원하는 상태(Desired State) 정의 → 주기적으로 적용
  • 예: 특정 소프트웨어 항상 설치 유지

Automation

  • 반복적인 운영 작업을 Runbook(문서)으로 자동화
  • EC2 AMI 생성, RDS 스냅샷, 패치 → 사람 개입 없이 자동 실행

5. EventBridge (구 CloudWatch Events)

핵심 개념

EventBridge는 AWS 서비스, SaaS, 커스텀 앱의 이벤트를 받아 자동으로 처리하는 이벤트 버스다.

이벤트 소스 (Producer)
  → EventBridge 버스
    → 규칙(Rule) 매칭
      → 타겟(Target) 실행

이벤트 소스

  • AWS 서비스: EC2 상태 변경, S3 업로드, GuardDuty 위협, CodePipeline 완료 등
  • SaaS: Datadog, PagerDuty, Zendesk 등
  • 커스텀: PutEvents API로 직접 전송

타겟 (50+개 지원)

  • Lambda, SQS, SNS, Step Functions
  • EC2 Run Command, SSM Automation
  • Kinesis, Firehose, API Gateway
  • 다른 계정/리전의 EventBridge 버스

이벤트 버스 유형

유형 설명
Default Bus AWS 서비스 이벤트 자동 수신
Custom Bus 커스텀 앱, SaaS 이벤트
Partner Bus SaaS 파트너 전용

멀티 계정 이벤트 집계

각 계정 EventBridge
  → 중앙 계정 EventBridge (Cross-Account)
    → Lambda, SQS 처리

스케줄 기반 자동화

cron(0 2 * * ? *)  → 매일 새벽 2시
rate(5 minutes)    → 5분마다
  • Lambda 정기 실행 (CloudWatch Events 대체)
  • ECS Task 스케줄 실행
  • SSM Automation Runbook 주기 실행

주요 자동화 패턴

패턴 1: EC2 자동 중지

EventBridge 스케줄 (평일 오후 7시)
  → Lambda
    → EC2 StopInstances API

패턴 2: GuardDuty 위협 자동 대응

GuardDuty Findings
  → EventBridge 규칙
    → Lambda (EC2 보안 그룹 격리 + 스냅샷 + SNS 알림)

패턴 3: S3 업로드 자동 처리

S3 ObjectCreated 이벤트
  → EventBridge
    → Lambda (이미지 리사이즈) + SQS (처리 대기열)

패턴 4: Config 규칙 위반 자동 수정

AWS Config 규칙 위반
  → EventBridge
    → SSM Automation (자동 수정 Runbook)

6. 운영 자동화 아키텍처 패턴

패턴 1: 장애 자동 감지 및 복구

CloudWatch Alarm (CPU > 90%, 5분 지속)
  → SNS (운영팀 알림)
  → EC2 Auto Scaling (스케일 아웃)
  → Systems Manager OpsCenter (인시던트 생성)

패턴 2: 보안 이벤트 자동 대응

GuardDuty (비정상 API 호출 탐지)
  → EventBridge
    → Lambda
      ├── IAM 키 비활성화
      ├── EC2 격리 (보안 그룹 변경)
      └── SNS (보안팀 즉시 알림)

패턴 3: 멀티 계정 중앙 모니터링

각 계정 CloudWatch Logs
  → Subscription Filter
    → Kinesis Firehose
      → S3 (중앙 계정, 로그 아카이브)
        → Athena 분석

각 계정 CloudTrail
  → 중앙 계정 S3 (Organization Trail)

패턴 4: 서버리스 운영 자동화

EventBridge 스케줄
  → Step Functions (복잡한 워크플로우)
    ├── Lambda: 현재 상태 조회
    ├── Lambda: 처리 실행
    ├── Wait: 완료 대기
    └── Lambda: 결과 알림

패턴 5: 비용 최적화 자동화

Cost Explorer 이상 지출 탐지
  → SNS 알림
  → Lambda (태그 없는 리소스 목록 수집)
    → SES (비용 보고서 이메일)

EventBridge 스케줄 (주말)
  → Lambda → EC2 개발 인스턴스 자동 중지

7. 서비스 간 비교 정리

로그 vs 지표 vs 이벤트

구분 서비스 특성
지표 CloudWatch Metrics 수치, 시계열, 경보
로그 CloudWatch Logs 텍스트, 검색, 필터
감사 CloudTrail API 호출 이력
추적 X-Ray 요청 흐름, 지연 분석
이벤트 EventBridge 자동화 트리거

알림 서비스 비교

서비스 특성 사용 시나리오
SNS Pub/Sub, 팬아웃 다수 구독자에게 알림
SQS 큐, 비동기 처리 처리 실패 재시도, 디커플링
EventBridge 이벤트 라우팅 복잡한 조건 기반 자동화
SES 이메일 전송 보고서, 트랜잭션 메일

8. 핵심 암기 포인트

키워드 선택
메모리·디스크 사용률 모니터링 CloudWatch Agent 설치
1분 미만 지표 수집 고해상도 커스텀 지표
로그에서 에러 카운트 → 경보 Metric Filter + Alarm
실시간 로그 → S3 Subscription Filter → Firehose
API 호출 감사 로그 CloudTrail
마이크로서비스 병목 분석 X-Ray
SSH 없이 EC2 접속 Session Manager
배스천 호스트 대체 Session Manager
OS 패치 자동화 SSM Patch Manager
이벤트 기반 자동화 EventBridge
정기 작업 스케줄 EventBridge 스케줄 (cron/rate)
복잡한 자동화 워크플로우 Step Functions
전체 계정 API 로그 수집 CloudTrail Organization Trail
알람 노이즈 감소 Composite Alarm

핵심 내용을 다시 정리하면

  • CloudWatch: 지표(Agent로 메모리/디스크), 로그(Metric Filter로 경보), 경보(SNS·ASG 연동)
  • CloudTrail: 모든 API 호출 감사, Organization Trail로 전체 계정 통합
  • X-Ray: 분산 추적, 서비스 맵으로 병목·오류 시각화
  • Systems Manager: SSH 없는 EC2 관리 (Session Manager), 패치, 자동화
  • EventBridge: 이벤트 기반 자동화 허브, 스케줄 + 규칙 매칭 + 50+ 타겟

이어 읽기: 11. 이벤트 처리로 보는 서버리스 아키텍처