COSS 교과목/클라우드활용

10주차 - CloudWatch, CloudTrail, Amazon SNS

지호0312 2026. 6. 9. 01:20

 

 

- CloudWatch
Amazon CloudWatch는 AWS 리소스와 애플리케이션을 실시간으로 모니터링하는 서비스로, 지표 수집, 로그 분석, 알람 설정을 통해 시스템 상태를 가시화해준다.
AWS에서 EC2, RDS, Lambda, S3 등 수많은 서비스가 동시에 돌아가는데 이걸 일일이 수동으로 확인하는 건 불가능함
=> CloudWatch 를 통해 지표를 자동으로 수집하고 한 곳에서 모니터링


- 지표(Metric)
시간 단위로 수집되는 수치형 값
예: CPU 사용률(%), 메모리 사용량(MB), 디스크 쓰기 횟수 등
EC2 인스턴스를 띄우면 별도 설정 없이도 기본 지표가 CloudWatch로 자동 전송됨
개발자가 커스텀 지표를 직접 올릴 수도 있음 (로그인 시도 횟수, 주문 처리 건수, 결제 실패율 등)

속성 설명
Namespace 지표의 소속 서비스 (예: AWS/EC2)
Dimension 리소스 식별자 (예: InstanceId → 특정 인스턴스만 조회)
Statistic 평균, 합계, 최대값 등
Period 수집 주기 (기본 5분, 상세 모니터링 활성화 시 1분)


대시보드(Dashboard)를 사용하면 CPU, 메모리, 네트워크 지표를 한 화면에 모아서 볼 수 있다.
커스텀 지표도 대시보드에 함께 올릴 수 있어서, 비즈니스 상태와 시스템 상태를 동시에 확인 가능하다.

- 로그(Log)
CloudWatch Logs는 EC2, Lambda, API Gateway 같은 서비스의 로그를 저장함
애플리케이션에서 발생한 이벤트나 시스템 오류 로그가 중앙에 모이는 구조

Logs Insights 기능을 쓰면 SQL처럼 쿼리해서 로그를 분석할 수 있다
예: 지난 1시간 동안 status=500인 에러가 몇 번 발생했는지, 특정 IP에서 접속이 있었는지 등을 조건 검색 가능하다.
마이크로서비스 아키텍처에서 각 서비스 로그가 개별 컨테이너에 흩어져 있어도, AWS 위에서 구동하면 CloudWatch로 중앙에 다 모이기 때문에 한 곳에서 분석할 수 있다.

- 알람(Alarm)
지정한 지표가 임계값을 넘으면 자동으로 경고 또는 작업을 실행하는 기능

알람 구성 요소:
- 지표 + 조건(임계값): 예) CPU > 80%
- 작업: SNS 발송, Auto Scaling 동작, EC2 재시작, Lambda 함수 호출 등

알람 상태는 정상 / 데이터부족 / 경고 세 가지임
처음 만들면 데이터부족 상태에서 시작하고, 지표가 수집되면 정상 또는 경고로 바뀜
예시 시나리오: EC2 CPU 사용률 90% 이상 5분 지속 → 경고 이메일 발송

- CloudTrail

AWS CloudTrail은 AWS 계정 내에서 발생한 모든 API 호출을 기록하는 서비스로, 
누가, 언제, 어떤 작업을 했는지 추적한다.
콘솔 클릭, CLI 명령어, SDK API 호출, 서비스 간 내부 호출까지 전부 기록된다.

기록된 로그는 CloudTrail 콘솔, S3, CloudWatch Logs, Athena 등으로 분석 가능하다.

CloudTrail 목적:
- 보안 감사(Security Auditing): 누가 뭘 했는지 확인
- 운영 문제 진단(Troubleshooting): 서비스 장애 원인 추적
- 규정 준수(Compliance): ISO, HIPAA 등 국제 규정 요구사항 충족
- 포렌식 분석(Forensics): 해킹 사고 발생 시 원인 분석

작동 원리:
사용자/서비스가 API 호출 → CloudTrail이 이벤트 감지·기록 → S3, CloudWatch Logs, EventBridge에 저장/전달

- CloudTrail 이벤트 유형

유형 설명 예시
관리 이벤트 (Management) 리소스 생성/삭제/권한 변경 RunInstances, CreateUser
데이터 이벤트 (Data) 리소스 안의 데이터 접근 활동 GetObject(S3), Invoke(Lambda)
인사이트 이벤트 (Insights) 비정상 행동 탐지 이상 호출 횟수 증가, 반복 실패 요청


관리 이벤트는 기본 활성화(무료)
데이터/인사이트 이벤트는 명시적으로 설정해야 하고 추가 과금 필요


- CloudWatch vs CloudTrail

항목 CloudTrail CloudWatch
목적 행위 추적 (누가 무엇을 했는가) 상태 모니터링 (무엇이 일어났는가)
데이터 API 호출 로그 지표(Metrics), 로그(Logs)
예시 EC2 생성, IAM 권한 변경 EC2 CPU 사용률, 로그 이벤트
사용 주체 보안, 감사, 규정 준수 운영, 모니터링, 자동 대응
연계 서비스 Athena, S3, EventBridge SNS, Lambda, Alarm 등


비유하면 CloudTrail은 CCTV(누가 언제 어떤 행동을 했는지 기록), CloudWatch는 센서와 알람 시스템(상태를 감지하고 경고)임
둘을 함께 사용하면 실시간 모니터링과 이력 분석을 동시에 할 수 있다.

- Amazon SNS / SQS


Amazon SNS(Simple Notification Service)는 AWS에서 제공하는 알림 메시징 서비스
이벤트 발생 시 이메일, SMS, 모바일 푸시, HTTP(S) 엔드포인트 등으로 메시지를 Push 방식으로 전송
Publisher가 SNS Topic에 메시지를 보내면, 그 Topic을 구독한 모든 구독자에게 메시지가 전달됨 (1:N 구조)
사용 예시: CloudWatch 경보 발생 → SNS를 통해 운영자에게 이메일 알림

Amazon SQS(Simple Queue Service)는 완전 관리형 메시지 대기열 서비스임
소비자가 Queue에서 메시지를 가져가는 Polling 방식이고, 1:1 구조임

항목 Amazon SNS Amazon SQS
메시지 지속성 없음 (못 받으면 사라짐) 있음 (소비자가 가져갈 때까지 유지)
전송 메커니즘 Push (수동적으로 받음) Polling (능동적으로 가져감)
생산자/소비자 게시(Publisher) / 구독(Subscriber) 생산자 / 소비자
전달 방식 1:N 1:1


SNS + SQS 팬아웃 아키텍처: SNS Topic의 구독자로 SQS를 등록하면, 같은 메시지를 여러 Queue에 전달할 수 있음
SQS를 중간에 두면 소비자가 처리 준비가 됐을 때 메시지를 가져가므로 메시지 유실 위험이 줄어듦
트래픽 폭증 시에도 앞단 서버는 요청을 Queue에 넣고 바로 응답하고, 뒷단 서버가 Queue에서 꺼내 처리하는 구조로 유연하게 대응 가능함
처리 중 오류가 반복되면 Dead Letter Queue로 옮겨져서 관리자가 오류를 따로 확인할 수 있음

- 실습: CloudWatch 알람 + SNS 연동

DynamoDB 테이블의 쓰기 용량(ConsumedWriteCapacityUnits) 지표에 알람을 걸고, 임계값 초과 시 SNS로 이메일 알림을 보내는 실습임

① SNS Topic 생성
- SNS 콘솔 접속 → 주제(Topic) 생성 → 유형: 표준, 이름: mytopic

주제 생성
표준 - mytopic - 주제 생성



② Topic 구독 생성
- 생성한 Topic에서 구독 생성 클릭 → 프로토콜: 이메일 → 본인 이메일 입력
- 이메일로 온 확인 메일에서 Confirm Subscription 클릭

구독 생성
메일로 구독 확인





③ DynamoDB 테이블 생성
- DynamoDB 콘솔 접속 → 테이블 생성 → 테이블 이름: board, 파티션 키: boardId

파티션 키로 boardid 만들고 생성

 




④ CloudWatch 알람 생성
- CloudWatch 콘솔 → 경보 → 경보 생성 클릭
- 지표 선택: DynamoDB → 테이블 지표 → board 테이블의 ConsumedWriteCapacityUnits 선택
- 임계값: 0보다 클 때 (바로 테스트하기 위해 0으로 설정)
- 알림 수단: 기존 SNS Topic(mytopic) 선택
- 알람 이름: my-board-write-capacity-alarm

지표 선택 클릭
DynamoDB 선택
DynamoDB > 테이블 지표 > ConsumeWriteCapacityUnits (쓰기 용량) 선택
바로 알림을 받아보기 위해 임계치 0으로 설정
아까 만들어 둔 mytopic 알림 추가


⑤ 알람 테스트
- DynamoDB → board 테이블 → 항목 생성으로 데이터 3건 저장 (boardId: 1, 2, 3)
- 쓰기 용량이 0을 초과하면서 알람 상태가 "경보"로 전환됨
- 등록한 이메일로 경보 알림 메일이 수신됨

항목 생성 버튼으로 생성할 수 있다.
새로고침해 보면 경보 상태로 바뀌어 있다.
이메일로도 알림이 온 것을 확인할 수 있다.