시험 전 빠른 복습: 요구사항에서 서비스 후보 좁히기

이 글은 앞선 주제의 세부 설명을 반복하지 않고, 문제에서 조건을 읽고 후보를 좁히는 순서를 모아 둔 복습 자료다. 먼저 우선순위와 제약을 표시하고, 비슷한 서비스의 책임 경계를 확인한 뒤 남은 선택지를 비교한다. 숫자와 서비스 기능은 바뀔 수 있으므로 실제 시험 전에는 공식 문서를 다시 확인한다.

1. SAP 시험 접근 전략

문제 읽기 순서

1. 요구사항 키워드 파악
   → "비용 효율적", "최소 운영 부담", "다운타임 없음", "실시간"

2. 제약 조건 확인
   → "기존 코드 변경 없이", "온프레미스 유지", "규정 준수 필요"

3. 오답 소거
   → 요구사항과 명백히 맞지 않는 선택지 먼저 제거

4. 남은 선택지 중 "가장 적합한" 것 선택
   → SAP는 "틀린 것"이 아닌 "가장 좋은 것"을 묻는 경우가 많음

자주 나오는 키워드 → 서비스 매핑

2. 시나리오별 선택 기준

시나리오: 마이그레이션

[온프레미스 서버 → AWS, 빠른 이전]
→ AWS Transform MGN (블록 레벨 복제, 컷오버 목표는 테스트로 검증)

[온프레미스 DB → 다른 DB 엔진]
→ AWS SCT (스키마 변환) + DMS (데이터 이전)

[온라인 전송 시간이 길고 물리 반입 가능]
→ AWS Data Transfer Terminal (시설 위치·계정 지원 요건 확인)

[파트너사 SFTP 유지하며 S3 저장]
→ Transfer Family

[온프레미스 파일 서버 → S3 주기 동기화]
→ DataSync

시나리오: 고가용성

[단일 AZ 장애 대비]
→ Multi-AZ (RDS, ALB, Auto Scaling 다중 AZ)

[리전 장애 대비, 분 단위 복구]
→ Pilot Light 또는 Warm Standby + Route 53 장애 조치

[리전 장애 대비, 초 단위 복구]
→ Multi-Site Active-Active + Aurora Global DB + DynamoDB 글로벌 테이블

[RDS 리전 수준 DR]
→ Aurora Global Database (리전 간 비동기 복제, 목표 RTO·실제 복제 지연 검증)

시나리오: 비용 최적화

[예측 가능한 24/7 워크로드]
→ 1년 Savings Plans 또는 Standard RI

[중단 허용 배치 작업]
→ 스팟 인스턴스 (최대 90% 절감)

[개발 환경 비용]
→ EventBridge 스케줄 → Lambda → 업무 외 시간 자동 중지

[S3 오래된 데이터 비용]
→ 수명 주기 정책 → Glacier Deep Archive

[CloudFront 없이 S3에서 직접 서비스]
→ CloudFront 추가 (아웃바운드 비용 절감 + 성능 향상)

시나리오: 보안

[미사용 자격 증명 감지]
→ IAM Access Analyzer, Trusted Advisor

[비정상 API 호출 탐지]
→ GuardDuty + CloudTrail Insights

[S3 개인정보(PII) 탐지]
→ Amazon Macie

[EC2 취약점 스캔]
→ Amazon Inspector

[DDoS 방어]
→ Shield Standard (자동) / Shield Advanced (고급, WAF 포함)

[SQL 인젝션, XSS 방어]
→ WAF (ALB, CloudFront, API Gateway에 연결)

[키 관리, 암호화]
→ KMS (AWS 관리형 키 또는 고객 관리형 키)

[DB 암호, API 키 저장]
→ Secrets Manager (자동 교체 지원)

시나리오: 서버리스 설계

[이벤트 → 여러 시스템 동시 처리]
→ SNS 팬아웃 → 각 SQS → Lambda

[순서 보장 + 중복 방지 큐]
→ SQS FIFO

[15분 초과 작업 또는 복잡한 분기·병렬]
→ Step Functions

[실시간 스트림 데이터 집계]
→ Kinesis Data Streams → Managed Service for Apache Flink

[API 비용 최소화 + Lambda 연동]
→ API Gateway HTTP API (필요 기능을 충족하는지 확인한 뒤 요금 비교)

시나리오: 네트워크

[여러 VPC + 온프레미스 중앙 연결]
→ Transit Gateway

[두 VPC만 연결, 간단]
→ VPC 피어링

[온프레미스 안정적 대용량 연결]
→ Direct Connect

[DX 장애 대비 백업]
→ Site-to-Site VPN (자동 페일오버)

[EC2 → S3 전송 비용 제거]
→ S3 Gateway VPC Endpoint

[글로벌 사용자 TCP/UDP 성능]
→ Global Accelerator (Anycast IP, 엣지에서 AWS 백본으로)

[글로벌 HTTP 콘텐츠 배포]
→ CloudFront (캐싱, 엣지 서버)

3. 함정 패턴 (오답 유발 포인트)

함정 1: RDS Multi-AZ vs 읽기 복제본 혼동

Multi-AZ:
  → 목적: 고가용성 (자동 페일오버)
  → 스탠바이는 읽기 불가 (MySQL, PostgreSQL Multi-AZ 인스턴스)
  → 동기 복제 → RPO ≈ 0

읽기 복제본:
  → 목적: 읽기 성능 향상 (읽기 쿼리 분산)
  → 비동기 복제 → 약간의 지연
  → 크로스 리전 가능 → DR 목적으로도 사용
  → 수동 승격 필요

함정: "읽기 부하 분산"에 Multi-AZ 선택 → 틀림
함정: "장애 조치"에 읽기 복제본 선택 → 불완전 (수동 승격 필요)

함정 2: S3 이벤트 알림의 팬아웃 한계

각 S3 이벤트 알림 설정 → 목적지 하나 지정
  (Lambda, SQS, SNS 등 중 하나)

여러 시스템에 동시 전달 필요:
  S3 → SNS → (SQS A, SQS B, Lambda C) 팬아웃

여러 소비자에게 한 이벤트를 팬아웃:
  S3 → SNS → 각 구독자, 또는 S3 → EventBridge → 규칙별 대상

같은 버킷에 여러 알림 설정을 둘 수 있지만, 이벤트 종류와 필터가 겹치는 구성에는 제약이 있다.

함정 3: CloudFront vs Global Accelerator

CloudFront:
  → HTTP/HTTPS 콘텐츠 캐싱
  → 정적 파일, 동적 페이지 가속
  → 엣지에서 콘텐츠 서빙 (캐시 히트 시 오리진 미접촉)

Global Accelerator:
  → TCP/UDP 모든 트래픽 (HTTP 외 포함)
  → 캐싱 없음
  → Anycast IP로 가장 가까운 엣지 → AWS 백본 경유 → 오리진
  → 고정 IP 제공 (IP 화이트리스트 필요 시)
  → 게임, IoT, VoIP에 적합

함정: "글로벌 HTTP API 성능"에 Global Accelerator → CloudFront가 더 적합한 경우 많음
함정: "고정 IP 필요" → CloudFront는 고정 IP 없음 → Global Accelerator

함정 4: SQS vs SNS vs EventBridge

SQS:
  → 소비자가 폴링, 1개 소비자가 메시지 처리
  → 보존 (최대 14일), 재처리 가능
  → 디커플링, 작업 큐

SNS:
  → 즉시 푸시, 다수 구독자 동시 전달
  → 보존 없음 (실패 시 소멸)
  → 팬아웃

EventBridge:
  → 이벤트 소스에서 자동 수신 (AWS 서비스 이벤트)
  → 규칙 기반 라우팅, 50+ 타겟
  → 스케줄 가능 (cron)
  → SaaS 이벤트 연동

함정: "여러 구독자 동시 알림" → SNS (SQS 아님)
함정: "AWS 서비스 이벤트에 자동 반응" → EventBridge (SNS 아님)
함정: "메시지 보존·재처리" → SQS (SNS 아님)

함정 5: Kinesis Streams vs SQS

Kinesis Streams:
  → 다수 소비자가 동일 데이터 동시 읽기 가능
  → 보존 기간 내 재처리 가능
  → 순서 보장 (샤드 내)
  → 실시간 로그, IoT, 클릭스트림

SQS:
  → 메시지 하나를 하나의 소비자만 처리
  → 처리 후 삭제 (재처리 불가, DLQ 제외)
  → 처리량 무제한

함정: "여러 애플리케이션이 동일 스트림 읽기" → Kinesis (SQS 아님)
함정: "무제한 처리량 작업 큐" → SQS (Kinesis 샤드 한계보다 유연)

함정 6: SCP가 관리 계정에 적용되지 않음

SCP는 멤버 계정에만 적용됨
관리 계정(Management Account)은 SCP의 영향을 받지 않음

함정: "관리 계정도 SCP로 제한 가능" → 틀림
정답: 관리 계정은 최소한의 작업만 수행, 실제 워크로드는 멤버 계정에서

함정 7: CloudTrail vs Config 목적 혼동

CloudTrail: "누가 무엇을 했는가" (API 호출 감사)
Config:     "리소스가 어떤 상태인가" (설정 규정 준수)

함정: "보안 그룹이 언제 변경됐는지" → CloudTrail (Config는 현재 상태)
함정: "보안 그룹이 규정을 준수하는지" → Config (CloudTrail은 이력)
두 서비스는 보완 관계: Config로 위반 탐지 → CloudTrail로 변경자 추적

함정 8: Lambda 동시성 한도와 스로틀링

계정 기본 동시성: 1,000 (리전별)

Reserved Concurrency 설정 시:
  → 해당 함수의 최대 동시성 예약
  → 다른 함수는 남은 동시성 공유
  → Reserved = 0이면 함수 완전 비활성화

함정: Reserved Concurrency가 Cold Start를 방지 → 틀림
      (Cold Start 방지는 Provisioned Concurrency)

함정: 동시성 1,000 초과 → 오류 없이 처리 → 틀림
      (429 TooManyRequests, SQS 트리거는 재처리)

함정 9: NAT Gateway vs NAT 인스턴스

NAT Gateway:
  → AWS 완전 관리형, 고가용성 자동
  → AZ별 배치 (고가용성 위해 각 AZ에 하나씩)
  → 대역폭 자동 확장

NAT 인스턴스:
  → EC2로 직접 운영, 단일 장애점
  → 보안 그룹 직접 관리 가능
  → 포트 포워딩 가능 (NAT Gateway 불가)
  → 더 낮은 비용 (소규모)

함정: "고가용성 NAT" → 각 AZ에 NAT Gateway (단일 NAT Gateway는 AZ 장애에 취약)

함정 10: Aurora vs RDS 선택

Aurora가 유리한 경우:
  → MySQL/PostgreSQL 호환 필요
  → 고성능 (RDS MySQL 대비 5배)
  → 멀티 리전 DR (Aurora Global DB)
  → 서버리스 (Aurora Serverless v2)
  → 스토리지 자동 확장 (128TB까지)

RDS가 유리한 경우:
  → Oracle, SQL Server, MariaDB 필요
  → 특정 엔진 버전 필요
  → Aurora 미지원 리전

함정: "비용 절감" → Aurora가 반드시 저렴하지 않음 (RDS MySQL이 더 저렴할 수 있음)
함정: "Oracle → Aurora 마이그레이션" → SCT 필요 (이기종 변환)

4. 헷갈리는 서비스 비교 치트시트

스토리지 비교

DB 비교

컴퓨팅 비교

메시징 비교

네트워크 비교

5. 자주 헷갈리는 숫자 암기

아래 값은 빠른 복습용이다. 기본값과 서비스 한도는 기능·리전·계정에 따라 달라질 수 있으므로 실제 설계 전에는 공식 문서와 Service Quotas를 확인한다.

6. 시험 직전 체크리스트

반드시 구분해야 할 서비스 쌍

• RDS Multi-AZ (고가용성)와 읽기 복제본 (읽기 확장)
• SQS (큐)와 SNS (팬아웃), EventBridge (이벤트 라우팅)
• CloudFront (HTTP 콘텐츠 전달)와 Global Accelerator (네트워크 경로 최적화)
• CloudTrail (API 감사)과 Config (리소스 구성·준수 평가)
• Kinesis Data Streams (재처리 가능한 스트림)과 SQS (작업 큐)
• DMS (데이터베이스 이전)와 AWS Transform MGN (서버 이전)
• DataSync (온라인 데이터 이동)와 Data Transfer Terminal (물리 시설 전송)
• Storage Gateway (지속적 하이브리드 접근)와 DataSync (파일 이동·동기화)
• Pilot Light (핵심 구성 대기)와 Warm Standby (축소된 전체 스택)
• Reserved Concurrency (동시성 상한·예약)와 Provisioned Concurrency (사전 초기화)
• SCP (계정 권한 상한)와 IAM 정책 (주체 권한 부여)
• Shield Standard (기본 보호)와 Shield Advanced (추가 보호·요금)
• Secrets Manager (비밀 관리)와 SSM Parameter Store (파라미터 저장)
• EFS (공유 파일 시스템)와 EBS (블록 스토리지)
• Aurora (지원 엔진과 고가용성 옵션 확인)와 RDS (관리형 관계형 DB)

설계 원칙 핵심 3줄

느슨한 결합 (Loose Coupling): SQS·SNS로 서비스 간 직접 의존 제거
수평 확장 (Scale Out): 단일 대형 서버 대신 여러 소형 서버 + Auto Scaling
장애 설계 (Design for Failure): 모든 컴포넌트가 장애날 수 있다고 가정하고 설계

7. 마무리

20편에 걸쳐 AWS SAP 시험의 전 영역을 다뤘다.

01. 글로벌 인프라
02. IAM & 보안
03. VPC 네트워킹
04. EC2 & 스토리지
05. 고가용성 & Auto Scaling
06. 데이터베이스
07. S3 & 스토리지 서비스
08. 고급 네트워킹
09. 보안 서비스 심화
10. 모니터링 & 운영 자동화
11. 서버리스 아키텍처
12. 컨테이너 서비스
13. 마이그레이션 & 전송
14. 하이브리드 아키텍처
15. 재해 복구 & 비즈니스 연속성
16. 비용 최적화
17. 멀티 계정 & 조직 관리
18. 분석 서비스
19. Well-Architected Framework
20. 시험 단골 시나리오 & 치트시트

서비스 이름을 외우는 것만으로는 제약 조건이 겹친 문제를 풀기 어렵다. 데이터 위치, 복구 목표, 운영 부담, 비용을 먼저 표시한 뒤 각 선택지가 그 조건을 어떻게 만족하는지 비교한다. 최신 기능과 한도는 공식 문서에서 다시 확인한다.

공식 문서로 최신 내용 확인하기

• S3 event notification destinations
• Choose between API Gateway REST and HTTP APIs
• AWS Transform MGN release notes
• AWS Snowball Edge availability change