- 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


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


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


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






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





'COSS 교과목 > 클라우드활용' 카테고리의 다른 글
| 12주차 - 고가용성 및 장애 복구 설계 (0) | 2026.06.12 |
|---|---|
| 11주차 - AWS Organizations (0) | 2026.06.10 |
| 9주차 - AWS Well-Architected Framework (0) | 2026.06.07 |
| 7주차 - AWS 보안 서비스 (WAF, GuardDuty) (0) | 2026.06.07 |
| 6주차 - S3/VPC (0) | 2026.06.04 |