CloudWatch는 건강검진 체크표, CloudTrail은 출입 일지, Config는 설정 변경 이력, X-Ray는 택배 송장 추적 — 비유로 풀어가며 CloudWatch Metrics·Logs·Alarms·Insights 4종, CloudTrail 이벤트 3유형, AWS Config 자동 수정, X-Ray·GuardDuty·Inspector·Macie까지 시험 함정 위주로 친절하게 정리한 SAA-C03 9편.
이 글은 AWS Certified Solutions Architect Associate(SAA-C03) 스터디 노트 시리즈의 아홉 번째 편입니다. 이번 단원은 처음 보면 막막해요. CloudWatch · CloudTrail · Config · X-Ray 네 가지가 한꺼번에 쏟아져 나오는데, 이름만 봐선 뭐가 뭔지 구분이 안 갑니다. "다 그냥 로그 보는 거 아닌가?" 싶거든요. 이 단원의 주인공은 단연 CloudWatch라서, 이 글도 CloudWatch 중심으로 풀어 가면서 나머지 셋과의 차이를 짚어 갑니다.
그런데 막상 시험을 풀어 보면 네 서비스의 역할이 칼같이 갈려 있어요. 한 시나리오에 한 답이 정답이라, 첫 단계는 "이게 뭐 하는 서비스인가"를 한 줄로 또렷하게 잡고 가는 거예요. CloudWatch는 건강검진 체크표, CloudTrail은 사옥 출입 일지, Config는 설정 변경 이력 장부, X-Ray는 택배 송장 추적 — 이 네 가지 비유만 머리에 들어와도 시나리오 문제의 절반은 풀립니다. 본격 정리에 들어가기 전, CloudWatch 사용자 가이드를 한 번 곁에 두시면 흐름 잡기에 좋아요.
네 서비스의 역할 — 한 줄 매칭이 전부의 시작
가장 먼저 잡아야 할 게 이 표예요. 시험에서 마주치는 거의 모든 모니터링 시나리오는 이 네 줄의 변형입니다.
| 핵심 질문 | 담당 서비스 | 회사 비유 |
|---|---|---|
| 리소스 성능·상태가 어떠한가? (CPU·메모리·에러 로그) | Amazon CloudWatch | 건강검진 체크표 |
| 누가 API를 호출해 변경을 가했는가? | AWS CloudTrail | 사옥 출입 일지 |
| 리소스 설정이 규정에 맞게 되어 있는가? | AWS Config | 설정 변경 이력 장부 |
| 분산 앱의 요청 흐름을 추적하고 싶다 | AWS X-Ray | 택배 송장 추적 |
이 매칭만 잡으면 "누가 변경했는지 알고 싶다" → CloudTrail, "규정 위반 리소스를 찾아라" → Config, 식으로 자동으로 답이 떠올라요. 이제 각 서비스를 천천히 풀어 봅니다.
CloudWatch Metrics — 지표를 담는 그릇과 라벨
CloudWatch의 출발점은 지표(Metric) 예요. 시간에 따라 변하는 숫자죠. CPU 사용률, 네트워크 I/O 바이트, S3 객체 수 같은 것들. 정리하는 데 필요한 두 개념만 잡으면 됩니다.
- 네임스페이스(Namespace) — 지표를 담는 컨테이너. 서비스마다 하나씩(예:
AWS/EC2,AWS/S3). "마케팅팀 캐비닛" 같은 큰 박스 - 차원(Dimension) — 그 안에서 지표를 필터링하는 라벨. 이름·값 쌍(예:
InstanceId=i-12345678)
여기서 시험 함정 — 지표 하나당 차원은 최대 30개까지. "30"만 기억하면 됩니다.
모니터링 해상도 — 얼마나 촘촘하게 잴까
지표를 기록하는 간격이에요. 시험에 자주 나오니 숫자만 외워둡시다.
- 기본 모니터링(Basic) — 5분 간격, 무료
- 세부 모니터링(Detailed) — 1분 간격, 추가 비용
- 고해상도 사용자 지정 지표 — 10초·30초 단위까지 가능
비유로는 — 일반 직원은 분기마다 건강검진(기본), 임원은 매달(세부), 중환자실 환자는 10초마다 활력 징후 체크(고해상도). 시험에서 "1초 단위 모니터링" 보기는 함정 — 1초는 안 됩니다.
Custom Metric — EC2 메모리는 기본이 아닙니다
> EC2의 메모리(RAM) 사용량과 디스크 여유 공간은 AWS 기본 지표에 포함되지 않습니다.
OS 안쪽 정보는 하이퍼바이저가 못 봐서 그래요. 받으려면 CloudWatch Unified Agent를 EC2 안에 설치해 OS에서 측정한 값을 Custom Metric으로 보내야 합니다. "EC2 메모리 사용률에 알람을 걸려면?" 시나리오의 정답은 거의 100% Unified Agent + Custom Metric이에요. "기본 모니터링에 메모리 지표가 있다" 보기는 무조건 오답.
Metric Streams — 지표를 외부로 거의 실시간 송출
CloudWatch Metric Streams 는 지표를 거의 실시간으로 외부로 흘려보내는 기능입니다. 통로는 Amazon Kinesis Data Firehose — Firehose → S3(Athena) / Redshift / OpenSearch / Datadog · Splunk · New Relic 같은 서드파티. "지표를 Datadog로 보내려면?" 시나리오의 답이 Metric Streams + Firehose.
CloudWatch Logs — 그룹·스트림·이벤트의 3층 구조
지표가 숫자라면 Logs 는 텍스트 로그를 담는 곳이에요. 3층 구조입니다.
- 로그 그룹(Log Group) — 애플리케이션 단위. "캠페인A 폴더 박스"
- 로그 스트림(Log Stream) — 그룹 안의 개별 소스(인스턴스, 컨테이너). "박스 안 직원별 일지"
- 로그 이벤트(Log Event) — 한 줄짜리 로그 메시지
보존 정책 — 기본 무기한, 1일 ~ 10년(120개월) 범위에서 설정. 만료 시 자동 삭제. 기본 암호화 + AWS KMS 추가 암호화 가능.
수집 소스 — EC2·온프레미스는 Unified Agent 설치(옛 Logs Agent는 deprecated). AWS 서비스 기본 연동 — Elastic Beanstalk · ECS · Lambda · VPC Flow Logs · API Gateway · CloudTrail · Route 53.
S3로 내보내기 — 시험 단골 함정
CloudWatch Logs를 S3로 배치 내보내기 할 때 쓰는 API가 CreateExportTask 인데, 큰 함정이 있어요.
> CreateExportTask는 실시간이 아닙니다. 완료까지 최대 12시간 걸려요.
"로그를 S3로 실시간으로 보내야 한다" 시나리오의 답은 절대 CreateExportTask가 아니에요. 답은 구독 필터(Subscription Filter) 입니다. 로그 이벤트를 실시간으로 스트리밍 — 지원 대상은 Kinesis Data Streams · Kinesis Data Firehose · Lambda · OpenSearch. 그리고 자주 나오는 숫자 — 로그 그룹당 구독 필터 최대 2개.
교차 계정 로그 집계 — 4단계
- 발신자 계정에서 구독 필터 생성
- 수신자 계정에 대상(Destination) 생성 (Kinesis Data Stream 등과 연결)
- 대상 액세스 정책(Destination Access Policy) 연결
- 수신자 계정에 Kinesis 전송 권한의 IAM 역할 생성
Metric Filter — 로그에서 숫자 만들기
Metric Filter 는 로그에서 키워드(ERROR, Exception)를 찾아 CloudWatch Custom Metric으로 변환해 주는 기능이에요. 이 지표에 알람을 걸면 "에러가 5분에 10번 이상이면 SNS 알림" 같은 자동화가 됩니다.
Logs Insights vs Live Tail — 과거 분석 vs 실시간
이 둘이 헷갈리는데, 짝을 지어 외우면 한 번에 끝나요.
Logs Insights 는 과거에 쌓인 로그를 SQL 비슷한 전용 쿼리 언어로 분석하는 도구예요. 실시간 엔진이 아닙니다. 대신 여러 계정·여러 로그 그룹을 동시에 쿼리할 수 있고, 결과를 시각화해서 CloudWatch 대시보드에 추가할 수 있어요. 자주 나오는 사용 사례 — "Lambda 지연 시간 통계", "VPC Flow Logs에서 상위 10개 소스 IP 추출" 같은 것들.
Live Tail 은 반대로 실시간 스트리밍입니다. 리눅스의 tail -f 명령처럼 로그가 들어오는 즉시 화면에 흘려 보여 줘요. 배포 직후 디버깅, 장애 발생 순간 추적 같은 데 씁니다. 매일 무료 시간이 일정량 주어지고 그 후엔 분당 요금이라, 세션을 안 닫고 두면 요금이 쌓입니다. 이건 시험보단 실무 함정.
> 한 줄 암기 — Insights = 과거 분석, Live Tail = 실시간.
Unified Agent — 옛 Logs Agent와의 차이
EC2나 온프레미스에 깔아서 로그·지표를 보내는 에이전트가 두 가지 있어요. 시험에 둘 중 하나 고르라면 무조건 Unified Agent가 답입니다. 표로 정리하면:
| 구분 | CloudWatch Logs Agent (구버전) | CloudWatch Unified Agent (신버전) |
|---|---|---|
| 기능 | 로그(Logs)만 전송 | 로그(Logs) + 시스템 지표(Metrics) 모두 수집 |
| 구성 관리 | 개별 설정 필요 | SSM Parameter Store 로 중앙 집중식 관리 |
| 하이브리드 지원 | 지원 | 지원 (온프레미스 서버 포함) |
그리고 Unified Agent가 EC2 기본 지표에 없는 OS 내부 지표를 어떤 것까지 수집해 주는지 — 시험에 자주 나옵니다. 외워둘 가치가 있어요.
- 메모리(RAM) — Free, Used, Cached
- 디스크 — 여유 공간, 사용량, IOPS
- CPU 세분화 — Active, Guest, Idle, System, User, Steal
- 네트워크 — TCP/UDP 연결 수, 패킷 수
- 프로세스 — 실행 중·대기 중·종료 프로세스 수
- 스왑(Swap) — 여유, 사용량
CloudWatch Alarms — 임계치 넘으면 행동까지
지표를 보고만 있으면 의미가 없어요. 임계치를 넘으면 자동으로 뭔가 해 줘야죠. 그게 알람(Alarm) 입니다.
알람은 항상 세 가지 상태 중 하나예요.
- OK — 정상, 임계값 안에 있음
- ALARM — 임계값 초과, 경보 발생
- INSUFFICIENT_DATA — 데이터가 부족해 판단 불가 (방금 만들었거나 지표가 안 들어올 때)
평가 기간은 Period × Datapoints로 계산해요. 예를 들어 Period=5분, Datapoints=3/3이면 총 15분 동안 조건이 유지돼야 알람이 울립니다. 기본은 60초 이상이고, 고해상도 Custom Metric은 10초·30초 단위 알람도 가능해요.
알람이 울리면 어떤 행동을 시킬 수 있냐 — 세 가지 액션이 있어요. 이걸 외워두면 됩니다.
- EC2 인스턴스 작업 — Stop · Terminate · Reboot · Recover(복구)
- Auto Scaling 작업 — Scale-out / Scale-in
- Amazon SNS 알림 — 이메일·SMS, Lambda 트리거 가능
EC2 Recover — 시험 단골
여기서 시험 함정이 하나 있어요. EC2 Recover 는 인스턴스의 시스템·하드웨어 상태 검사가 실패하면 자동으로 새 호스트로 옮겨 인스턴스를 살리는 기능인데, 복구 후에 유지되는 게 정해져 있어요.
> Recover 후 동일하게 유지되는 것 — 동일한 프라이빗/퍼블릭/탄력적 IP(Elastic IP) · 동일한 메타데이터 · 동일한 배치 그룹.
시험에 "EC2 Recover 후 IP가 바뀐다"는 보기가 나오면 무조건 오답이에요. IP는 그대로 유지됩니다.
Composite Alarm — 알람 노이즈 줄이기
알람을 막 만들다 보면 너무 자주 울려서 정작 진짜 문제일 때 무시하게 되는 함정이 있어요. 그래서 복합 경보(Composite Alarm) 가 있어요. 여러 알람을 AND/OR 논리로 묶어서 — 예를 들어 "CPU > 90% AND 네트워크 I/O < 10MB" 일 때만 진짜로 울리게 합니다. 노이즈가 확 줄어들어요.
알람 테스트 — set-alarm-state
알람 만들고 "잘 동작하나" 테스트하고 싶을 때 — 진짜로 CPU를 100%로 만들 필요는 없어요. CLI 명령어 한 줄로 강제 변경할 수 있습니다.
aws cloudwatch set-alarm-state --alarm-name MyAlarm --state-value ALARM --state-reason "test"이걸 묻는 시험 문제도 가끔 있어요. "알람을 실제 지표 없이 테스트하려면?" 답은 set-alarm-state CLI.
CloudWatch Dashboards — 한 화면에 다 모으기
여러 지표를 한 화면에 그래프·숫자·파이 차트로 모아두는 게 Dashboard 예요. 여기서 시험 한 줄 — 여러 리전의 지표를 하나의 대시보드에서 동시에 볼 수 있습니다(글로벌 대시보드). 데이터를 CSV로 내보낼 수도 있고요.
EventBridge — 이벤트 버스 (옛 CloudWatch Events)
이름이 좀 헷갈리는데 — CloudWatch Events 가 이름 바뀌어 Amazon EventBridge 가 됐어요. 같은 서비스입니다. 역할은 — AWS 서비스나 외부 SaaS 앱에서 발생하는 이벤트를 다른 서비스로 전달하는 서버리스 이벤트 버스예요.
이벤트는 모두 JSON 문서 형태입니다. 트리거 방식은 두 가지.
- 일정(Schedule) 기반 — Cron 표현식으로 특정 시간마다 실행 (예: 매일 자정에 Lambda 트리거)
- 이벤트 패턴 기반 — 특정 서비스의 작업·상태 변화에 반응 (예: IAM 루트 사용자 로그인 감지, S3 업로드, EC2 상태 변경)
이벤트 버스 3종류 — 시험 단골
| 종류 | 설명 |
|---|---|
| 기본 이벤트 버스 (Default) | AWS 서비스에서 발생하는 이벤트 기본 수신 |
| 파트너 이벤트 버스 (Partner) | Zendesk, Datadog, Auth0 등 외부 SaaS 파트너 이벤트 수신 |
| 사용자 지정 이벤트 버스 (Custom) | 자체 애플리케이션 이벤트 전송용 |
여기서 시험 키워드 매칭 — "Auth0·Zendesk·Datadog 같은 SaaS 파트너 이벤트를 AWS에서 받고 싶다" 면 답은 파트너 이벤트 버스예요. 외워두세요.
대상(Target)은 정말 많은데 자주 나오는 것만 — Lambda · EC2 작업 · ECS 태스크 · Batch · SNS · SQS · Kinesis Data Streams · SSM Automation · CodePipeline · CodeBuild · Step Functions, 그리고 시험 단골 API Destinations(외부 HTTP/REST API 엔드포인트로 직접 이벤트 송출).
고급 기능 세 가지도 시험에 나옵니다.
- Archive & Replay — 이벤트 보관 후 과거 이벤트 재실행. 버그 수정 후 재처리에 유용
- Schema Registry — 이벤트 구조를 자동 추론, 코드 생성 지원
- 리소스 기반 정책 — 여러 계정의 이벤트를 하나의 중앙 이벤트 버스로 집계
CloudTrail + EventBridge + SNS 패턴 — 정말 자주 나옵니다
이 조합이 시험에 정말 단골이에요.
특정 API 호출 발생
→ CloudTrail 기록
→ EventBridge가 이벤트 패턴 매칭
→ SNS → 이메일/SMS 알림자주 나오는 시나리오 — DynamoDB 테이블 삭제 시 알림, IAM 역할 수임 시 알림, 보안 그룹 인바운드 규칙 변경 시 알림. 이런 "특정 API 호출 시 즉시 알림" 시나리오는 무조건 이 3종 세트가 답입니다.
CloudWatch Network Monitor & Synthetics
Network Monitor 는 AWS↔온프레미스 같은 하이브리드 네트워크 성능 모니터링 도구예요. 키워드 세 개만 외워둡시다.
- 에이전트리스 — 별도 에이전트 설치 불필요
- 측정 지표 — 패킷 손실 · 지연 시간(Latency) · 지터(Jitter)
- 프로토콜 — IPv4 환경에서 ICMP 또는 TCP
시험에 "Direct Connect/VPN 구간의 패킷 손실을 에이전트 없이 측정" 시나리오가 나오면 답은 Network Monitor.
Synthetics Canary 는 다른 방향이에요. 사용자 트래픽이 없을 때도 — 새벽 같은 시간 — API·URL·웹사이트 엔드포인트의 가용성과 지연을 주기적으로 테스트해 주는 봇이에요. Node.js나 Python 스크립트로 사용자 행동을 시뮬레이션합니다. "광부의 카나리아" 비유 그대로 — 진짜 사용자가 문제를 발견하기 전에 카나리아가 먼저 죽어서 알려준다는 의미예요.
CloudWatch Insights 4종 — 헷갈리니까 표로
이름이 다 비슷해서 헷갈리는 4종이에요. 시험에 키워드만 매칭되면 풀립니다.
| 서비스 | 대상 환경 | 핵심 키워드 |
|---|---|---|
| Container Insights | ECS, EKS, Fargate | 컨테이너화된 CloudWatch Agent |
| Lambda Insights | AWS Lambda | 콜드 스타트 추적, Lambda Layer로 제공 |
| Contributor Insights | 로그 데이터 (VPC Flow Logs 등) | Top Talkers, 상위 N개 IP·에러 URL |
| Application Insights | 다중 리소스 앱 (EC2+RDS+ELB) | SageMaker(ML) 자동 감지, SSM OpsCenter 연동 |
> 키워드 매칭 — 컨테이너 = Container, 콜드 스타트·Layer = Lambda, Top-N·상위 IP = Contributor, ML·OpsCenter = Application.
여기까지가 CloudWatch입니다. 이제 두 번째 — CloudTrail 갑니다.
CloudTrail — 누가 API 호출했는지 출입 일지
CloudWatch가 "건강 상태"라면 CloudTrail은 "출입 일지"예요. 누가 / 언제 / 어디서 / 무엇을 했는지 AWS 계정 안의 모든 API 호출을 기록해 줍니다.
여기서 외워둘 사실 — CloudTrail은 계정 생성 시 기본 활성화돼 있어요. 따로 켜지 않아도 이미 동작 중입니다. 추적 대상은 AWS Management Console · SDK · CLI · 다른 AWS 서비스의 호출까지 다 포함이에요.
Event History — 90일 무료
CloudTrail 콘솔에 들어가면 최근 90일간의 관리 이벤트를 무료로 볼 수 있어요. 여기까지가 기본. 그 이상 보존하고 싶으면?
> Trail을 생성해서 S3 또는 CloudWatch Logs로 보내야 합니다.
90일 이상 장기 보존 시나리오의 정답은 무조건 "Trail 생성 + S3"예요. S3에 쌓인 CloudTrail 로그를 분석할 때는 Amazon Athena로 SQL 쿼리하는 게 가장 일반적입니다.
Trails — 단일 또는 모든 리전
Trail은 단일 리전으로 만들 수도 있고, 모든 리전(Multi-Region) 으로 만들 수도 있어요. 보통 모든 리전 옵션을 켜두는 게 표준이고, 이러면 어느 리전에서 일어난 API 호출이든 한 S3 버킷으로 모아 볼 수 있습니다.
CloudTrail 이벤트 3유형 — 시험 단골 중에 단골
이 표는 거의 통째로 외우는 게 좋아요. 시험에 정말 자주 나옵니다.
| 이벤트 유형 | 설명 | 기본 활성화 | 비용 | 예시 |
|---|---|---|---|---|
| 관리 이벤트 (Management Events) | AWS 리소스에 대한 작업 (제어 영역). Read/Write 분리 가능 | O | 무료 | IAM 정책 연결, EC2 인스턴스 목록 조회, DynamoDB 테이블 삭제 |
| 데이터 이벤트 (Data Events) | 리소스 내부의 대용량 작업 (데이터 영역) | X | 유료 | S3 GetObject/PutObject/DeleteObject, Lambda Invoke |
| 인사이트 이벤트 (Insights Events) | 비정상적이거나 특이한 API 활동 감지 | X | 유료 | 리소스 프로비저닝 급증, 비정상적인 IAM 활동 패턴 |
여기서 시험 함정이 하나 — 데이터 이벤트는 기본 비활성화입니다. S3 객체 수준의 GetObject/PutObject 같은 활동을 추적하려면 별도로 켜야 해요. 비용이 비싸기 때문에 기본은 꺼져 있습니다. "S3 객체 다운로드 추적이 안 된다, 왜?" 시나리오의 정답이 거의 항상 이거예요.
CloudTrail Insights — 비정상 활동 감지
CloudTrail Insights 는 정상적인 관리 활동의 기준선(Baseline)을 학습한 뒤, 평소와 다른 특이한 패턴이 나타나면 인사이트 이벤트를 만들어 주는 기능이에요. 회사로 치면 "평소엔 김대리가 9시에 출근하는데 새벽 3시에 들어왔다" 같은 이상 패턴을 자동으로 잡아내는 거예요.
생성된 인사이트 이벤트는 CloudTrail 콘솔·S3·Amazon EventBridge 로 전송할 수 있어서, 자동화 워크플로우로 연결하기 좋아요. 시험 키워드 — "비정상 API 활동 감지" 또는 "이상 현상 감지" → CloudTrail Insights.
CloudTrail Lake — 관리형 데이터 레이크
CloudTrail Lake 는 좀 새로운 기능이에요. CloudTrail 이벤트를 관리형 데이터 레이크로 구축해 줘서, Athena 없이도 SQL 기반 쿼리가 가능해집니다. 이벤트 데이터를 최대 7년까지 보존할 수 있어요. 시험에 "장기 보존 + 직접 SQL 쿼리" 시나리오의 정답이 자주 이쪽입니다.
AWS Config — 설정 변경 이력 장부
CloudWatch가 성능, CloudTrail이 출입 일지라면, Config 는 "설정 변경 이력 장부"예요. AWS 리소스의 구성(Configuration)을 시간 순으로 기록해 두고, 그게 규정에 맞는지 평가해 주는 서비스입니다.
회사로 치면 — "회의실 A는 작년 1월에 4인용으로 설치, 6월에 6인용으로 변경, 12월에 8인용으로 확장" 같은 시설 변경 이력을 차곡차곡 적어두는 장부 + "회의실은 모두 8인 이상이어야 함" 같은 규정에 맞는지 검사하는 도구예요.
핵심 사실들 — 시험 함정 포함
- 시간에 따른 변화 추적 — 리소스의 과거 상태를 시간 순으로 확인 가능 (롤백 정보 제공)
- 리전별 서비스(Regional) — 모든 리전에서 쓰려면 각 리전마다 따로 구성해야 합니다. 시험 함정이에요. "한 번 설정으로 모든 리전 자동 적용"은 오답.
- 저장 — Amazon S3 버킷, 알림 — SNS 토픽, 분석 — Athena
- 권한은 서비스 연결 역할(Service-Linked Role)이 자동으로 만들어 줘요
규정 준수 규칙(Rules)
규칙은 두 종류예요.
- AWS 관리형 규칙(Managed Rules) — AWS가 미리 만들어 둔 75개 이상의 규칙. 예 —
restricted-ssh(포트 22 개방 금지),approved-amis(승인된 AMI 사용 여부) - 사용자 지정 규칙(Custom Rules) — AWS Lambda 함수로 직접 규칙 코드를 작성
평가 트리거는 두 방식이에요.
- 이벤트 기반(Event-driven) — 리소스 구성이 변경될 때마다 즉시 평가
- 주기적(Periodic) — 정해진 시간 간격으로 평가 (예: 2시간마다)
평가 결과는 Compliant(준수) / Non-compliant(비준수) 둘 중 하나로 나옵니다.
Config의 가장 중요한 함정 — 차단 못 합니다
여기가 시험에 정말 자주 나오는 함정이에요. 한 줄로 박아두고 갑니다.
> Config는 규정 위반을 "탐지·평가"만 합니다. 사용자의 작업을 "사전에 차단"하지 못해요.
비유하자면 — 건물 안전 점검관은 "이 회의실은 소방법 위반"이라고 보고서를 쓸 수는 있지만, 직원이 그 회의실로 들어가는 걸 막을 권한은 없는 거예요. 차단은 보안실(IAM/SCP)의 역할입니다.
시험에 "Config로 보안 그룹의 포트 22 개방을 차단하려면" 같은 보기가 나오면 무조건 오답이에요. 차단은 IAM 또는 SCP가 합니다.
Config + SSM Automation Remediation — 자동 수정
차단은 못 해도 사후 자동 수정은 할 수 있어요. 비준수 리소스를 발견하면 AWS Systems Manager(SSM) 자동화 문서를 실행해서 고쳐 주는 거예요. 흐름은:
보안 그룹 변경 (포트 22 개방)
→ AWS Config 규칙 평가 → Non-compliant
→ Config Remediation 자동 트리거
→ SSM Automation Document 실행 (포트 22 규칙 삭제)
→ SNS 알림여기 숫자 함정 하나 — 자동 수정은 실패 시 최대 5번까지 재시도합니다. 복잡한 사용자 정의 작업이면 Lambda 함수를 호출하는 SSM Automation Document를 만들어 연결하면 돼요.
Config Aggregator — 멀티 계정·멀티 리전
여러 AWS 계정과 여러 리전의 Config 데이터를 단일 뷰로 모아 보는 게 Config Aggregator 예요. AWS Organizations와 연동하면 조직 전체의 규정 준수 상태를 한눈에 볼 수 있습니다.
Config + CloudTrail — 함께 봐야 완전한 감사
Config는 "무엇이 변경되었는가"를 추적해요. CloudTrail은 "누가/언제 API를 호출했는가"를 추적하고요. 이 둘을 함께 보면 — "어제 오후 3시에 김대리가 보안 그룹 sg-xxx의 포트 22를 열었다" 같은 완전한 감사 체계가 됩니다. 시험에서 "변경 내용과 변경한 사람을 함께 추적" 시나리오가 나오면 둘 다 정답이에요.
X-Ray — 분산 앱 요청 흐름 추적
마이크로서비스로 시스템을 짜면 한 요청이 여러 서비스를 거쳐 처리돼요. API Gateway → Lambda → DynamoDB → S3 같은 식으로요. 이때 "어디서 시간이 걸렸나, 어디서 에러가 났나"를 시각적으로 추적해 주는 게 AWS X-Ray 입니다. 회사로 치면 — 택배가 회사로 오는 동안 어느 물류센터에서 얼마나 머물렀는지 송장을 따라가며 보는 것에 가까워요.
주요 개념 5가지
| 개념 | 설명 |
|---|---|
| Segment | 단일 서비스가 처리한 작업 단위 |
| Subsegment | Segment 내에서 더 세분화된 작업 (예: DB 쿼리, HTTP 요청) |
| Annotations | 필터링/인덱싱에 사용되는 키-값 쌍 (검색 가능) |
| Metadata | 추가 정보 저장용 키-값 쌍 (검색 불가) |
| Trace | 여러 Segment를 묶은 요청 전체의 추적 단위 |
여기서 시험 함정이 하나 — Annotations는 검색 가능, Metadata는 검색 불가입니다. "검색 필터로 추적 데이터를 찾고 싶다"면 Annotations를 써야 해요.
X-Ray Daemon
EC2나 온프레미스 서버에서 X-Ray로 데이터를 보내려면 X-Ray Daemon 이 필요해요. UDP 포트 2000으로 트레이스 데이터를 받아서 X-Ray API로 전송하는 프록시 프로세스예요. ECS 환경에서는 사이드카(Sidecar) 컨테이너로 같이 띄웁니다.
Sampling Rules
모든 요청을 다 추적하면 비용·오버헤드가 너무 커요. 그래서 Sampling Rules 로 추적 비율을 조절합니다. 기본은 매초 첫 번째 요청 + 이후 5%예요. 사용자 지정 규칙으로 비율을 더 늘리거나 줄일 수 있고요.
Health Dashboard·Inspector·GuardDuty·Macie
이 네 가지는 묶어서 한 번에 정리합니다. 키워드 매칭만 되면 시험에서 풀려요.
AWS Health Dashboard — 두 종류
| 종류 | 설명 |
|---|---|
| Service Health Dashboard | 모든 리전·서비스에 걸친 AWS 서비스 전반의 공개 상태 정보 |
| Your Account Health Dashboard (구: Personal Health Dashboard) | 내 계정에 영향을 미치는 개인화된 서비스 이벤트·알림 |
Your Account Health Dashboard는 EventBridge와 통합해서 자동 대응이 가능해요. 시험 키워드 — "내 계정에만 해당하는 알림" → Your Account Health Dashboard.
Amazon Inspector — 취약점 자동 스캔
Inspector 는 EC2·ECR 컨테이너 이미지·Lambda 함수의 소프트웨어 취약점을 자동 스캔해 주는 서비스예요. CVE(공통 취약점 및 노출) 기반으로 보고하고, 보안 점수와 우선순위까지 매겨 줍니다. 결과는 AWS Security Hub 와 Amazon EventBridge 로 전송돼요.
시험 키워드 — "EC2/ECR/Lambda CVE 스캔" → Inspector.
Amazon GuardDuty — 지능형 위협 탐지
GuardDuty 는 좀 다른 방향이에요. 머신러닝 기반의 이상 감지로 악의적 활동·비정상 행동을 식별합니다. 데이터 소스를 외워두면 시험에 큰 도움이 돼요.
- CloudTrail 이벤트 로그 — 비정상적인 API 호출
- VPC Flow Logs — 비정상적인 네트워크 트래픽
- DNS Logs — 악성 도메인 조회
- Kubernetes Audit Logs — EKS 보안
별도 에이전트 설치가 필요 없고, 위협 발견 시 EventBridge로 자동 대응이 가능해요. 시험 키워드 — "ML 기반 위협 탐지", "비정상 활동·악의적 활동 식별" → GuardDuty.
Inspector vs GuardDuty — 헷갈리지 않게
| 구분 | Inspector | GuardDuty |
|---|---|---|
| 무엇을 본다 | 소프트웨어 취약점(CVE) | 위협(비정상 활동) |
| 대상 | EC2·ECR·Lambda | 계정·워크로드 전반 |
| 데이터 소스 | 패키지 스캔 | CloudTrail·VPC Flow·DNS·EKS Audit |
| ML 사용 | X | O |
> 한 줄 암기 — Inspector = 취약점 스캔(CVE), GuardDuty = ML 위협 탐지.
CloudWatch vs CloudTrail vs Config — 한눈에
이 비교표는 통째로 머리에 박아두는 게 좋아요. 시험에서 정말 자주 헷갈립니다.
| 구분 | Amazon CloudWatch | AWS CloudTrail | AWS Config |
|---|---|---|---|
| 핵심 질문 | 리소스 성능/상태가 어떠한가? | 누가 API를 호출했는가? | 리소스 설정이 규정에 맞는가? |
| 목적 | 성능 모니터링, 로깅, 알람 | API 호출 감사, 거버넌스 | 구성 변경 추적, 규정 준수 평가 |
| 저장 위치 | CloudWatch Logs, S3 | S3, CloudWatch Logs | S3 |
| 기본 보존 | Log Group 보존 정책 (1일~10년) | 콘솔 이벤트 기록 90일 무료 | S3에 무제한 보존 가능 |
| 주요 기능 | Metrics, Logs, Alarms, Dashboards, EventBridge | Event History, Trails, Insights, Lake | Rules, Remediation, Aggregator |
| 알림 | SNS via Alarms | EventBridge → SNS | EventBridge, SNS |
| 사전 차단 | 불가 | 불가 | 불가 (IAM/SCP가 담당) |
| ELB 사례 | 수신 연결 수, 에러 코드 모니터링 | 누가 설정을 변경했는지 추적 | SSL 인증서 규정 준수 여부 평가 |
ELB 사례 행이 정말 깔끔해요. 같은 ELB에 대해서도 — CloudWatch는 "지금 연결이 몇 개?", CloudTrail은 "이 ELB 설정을 누가 바꿨지?", Config는 "이 ELB가 SSL 인증서 규정에 맞나?" — 이렇게 세 서비스가 다른 질문에 답합니다.
자주 등장하는 아키텍처 패턴 모음
시험에 자주 나오는 패턴을 그림으로 머리에 새겨두면 시나리오 문제가 빨라져요.
패턴 1 — 실시간 API 호출 알림
API 호출 발생
→ CloudTrail 기록
→ Amazon EventBridge (특정 API 이벤트 패턴 감지)
→ Amazon SNS → 이메일 알림DynamoDB 테이블 삭제·IAM AssumeRole·보안 그룹 변경 시 즉각 알림.
패턴 2 — 실시간 로그 스트리밍 to S3
Lambda / EC2 로그
→ CloudWatch Logs
→ 구독 필터 (Subscription Filter)
→ Kinesis Data Firehose
→ S3 버킷 (거의 실시간)CreateExportTask가 아니라 구독 필터 + Firehose가 답이에요.
패턴 3 — Config 비준수 자동 수정
보안 그룹 변경 (포트 22 개방)
→ AWS Config 규칙 평가 → Non-compliant
→ Config Remediation
→ SSM Automation Document 실행 (해당 보안 그룹 규칙 삭제)
→ SNS 알림패턴 4 — 멀티 계정 로그 중앙 집계
여러 발신자 계정 → CloudWatch Logs 구독 필터
→ 수신자 계정의 Kinesis Data Stream (대상 액세스 정책)
→ 중앙 S3 / OpenSearch패턴 5 — CloudTrail 장기 보존 및 분석
CloudTrail 이벤트
→ S3 버킷 (장기 보존)
→ Amazon Athena (서버리스 SQL 쿼리)또는 CloudTrail Lake를 쓰면 Athena 없이도 SQL 쿼리가 됩니다.
패턴 6 — 경보 기반 EC2 자동화
CloudWatch Alarm (CPU > 90% AND 네트워크 낮음)
→ Composite Alarm
→ EC2 Action: Reboot / Recover / Terminate
또는 SNS → Lambda → 사용자 지정 작업시험 직전 한 번 더 — 자주 헷갈리는 함정 모음
여기까지가 모니터링·감사 영역의 핵심입니다. 시험 직전에 다시 펼쳐 볼 압축 노트예요. 이 부분만 시험 전날 한 번 더 읽으면 거의 다 떠오릅니다.
한 줄 매칭 + CloudWatch 영역
- 네 서비스 매칭 — 성능·상태 = CloudWatch / 누가 API = CloudTrail / 규정 준수 = Config / 분산 추적 = X-Ray
- 지표당 차원 최대 30개
- 모니터링 해상도 — 기본 5분 / 세부 1분 / Custom 고해상도 10·30초
- EC2 메모리·디스크 여유 공간 = 기본 지표에 없음 → Unified Agent + Custom Metric
- CloudWatch Logs 보존 1일~10년
CreateExportTask= 실시간 X, 최대 12시간 소요 / 실시간 = 구독 필터- 로그 그룹당 구독 필터 최대 2개
- 구독 필터 지원 대상 — Kinesis Data Streams · Firehose · Lambda · OpenSearch
- Logs Insights = 과거 분석, Live Tail = 실시간
- Unified Agent OS 내부 지표 — 메모리·디스크·CPU 세분화·네트워크·프로세스·Swap
- Alarm 상태 3종 — OK / ALARM / INSUFFICIENT_DATA
- EC2 Recover 후 동일 IP·메타데이터·배치 그룹 유지
- Composite Alarm = AND/OR로 노이즈 감소
aws cloudwatch set-alarm-state= 알람 강제 테스트- EventBridge 파트너 버스 = Zendesk·Datadog·Auth0 SaaS
- EventBridge API Destinations = 외부 HTTP/REST 엔드포인트
CloudTrail · Config — 감사 영역
- CloudTrail 기본 활성화 + 콘솔 이벤트 기록 90일 무료
- 90일 이상 = Trail 생성 → S3 / 분석 = Athena
- CloudTrail 이벤트 — 관리(O·무료) / 데이터(X·유료, S3 객체·Lambda Invoke) / 인사이트(X·유료, 비정상 감지)
- CloudTrail Lake = 관리형 데이터 레이크, 최대 7년, SQL 직접
- Config = 평가만, 차단 X (차단은 IAM/SCP)
- Config = 리전별 서비스 (모든 리전에서 쓰려면 각각 구성)
- Config 자동 수정 = SSM Automation Document, 최대 5번 재시도
- Config Aggregator = 여러 계정·리전 단일 뷰, Organizations 연동
X-Ray·보안·헬스 + 단골 패턴
- X-Ray — Annotations(검색 O) / Metadata(검색 X), Daemon UDP 2000, ECS는 사이드카
- X-Ray Sampling 기본 = 매초 첫 요청 + 이후 5%
- Network Monitor — 에이전트리스, 패킷 손실·지연·지터, ICMP/TCP IPv4
- Synthetics Canary = Node.js·Python 스크립트, 사용자 행동 시뮬레이션
- CloudWatch Insights 4종 — Container(컨테이너), Lambda(콜드 스타트·Layer), Contributor(Top-N), Application(SageMaker·OpsCenter)
- Inspector = EC2·ECR·Lambda CVE 스캔
- GuardDuty = ML 위협 탐지, 데이터 = CloudTrail·VPC Flow·DNS·EKS Audit
- Health Dashboard — Service(공개) / Your Account(개인화·EventBridge 연동)
- CloudWatch + CloudTrail + EventBridge + SNS 패턴이 시험 단골
마무리 한 줄
여기까지가 SAA-C03 모니터링·감사 영역의 전부예요. 노트로 보면 길어 보이지만, 사실 핵심은 맨 처음의 "네 서비스 한 줄 매칭"이에요. 그것만 단단히 잡고, 각 서비스의 시험 함정 몇 개를 챙기면 됩니다. 표를 손으로 한 번 다시 그려보면 머리에 더 잘 박힙니다. 추가로 CloudTrail 사용자 가이드도 한 번씩 들춰보면 도움이 됩니다.
다음 글(10편)에서는 Athena·Glue·Redshift·EMR·Kinesis·SageMaker·Rekognition 같은 데이터 분석·머신러닝 서비스를 정리할게요. CloudWatch까지 익힌 다음에 데이터 영역으로 넘어가면, 시험에서 출제되는 시나리오의 구조가 한결 더 또렷하게 보이기 시작합니다.
시리즈 다른 편
같은 시리즈의 다른 글들도 같은 친절 톤으로 묶어 정리되어 있어요.