제1장: 탄력적 및 고가용성 컴퓨팅 (Compute)

1.1 Amazon EC2: 인스턴스 유형 선택, 구매 옵션(Spot, RI, On-Demand) 공략
1.2 Auto Scaling & ELB: 고가용성 아키텍처 설계, 상태 확인(Health Check)
1.3 서버리스 컴퓨팅 (Lambda): 이벤트 기반 아키텍처, 프로비저닝된 동시성
1.4 컨테이너 서비스: ECS, EKS, AWS Fargate (서버리스 컨테이너)

제2장: 고성능 및 확장 가능 스토리지 (Storage)

2.1 Amazon S3: 스토리지 클래스(Intelligent-Tiering, Glacier), 수명 주기 정책, 복제(CRR/SRR)
2.2 블록 및 파일 스토리지: EBS(GP3, IO2), EFS(리눅스 공유), FSx(Windows, Lustre, ONTAP)
2.3 데이터 전송 및 하이브리드: Storage Gateway, AWS DataSync, Snow Family, Transfer Family

제3장: 데이터베이스 설계 및 최적화 (Database)

3.1 관계형 데이터베이스 (RDS): Multi-AZ vs 읽기 전용 복제본(Read Replica), RDS Proxy
3.2 Amazon Aurora: 글로벌 데이터베이스, Aurora Serverless v2, 복제 지연 해결
3.3 NoSQL 및 캐싱: DynamoDB(TTL, DAX, 글로벌 테이블), ElastiCache(Redis, Memcached)
3.4 분석용 데이터베이스: Amazon Redshift, Athena(S3 쿼리), Glue(ETL)

제4장: 네트워킹 및 콘텐츠 전송 (Networking)

4.1 VPC (Virtual Private Cloud): 서브넷 설계, NAT Gateway vs NAT 인스턴스, 보안 그룹 vs 네트워크 ACL
4.2 하이브리드 연결: Site-to-Site VPN, Direct Connect, Transit Gateway
4.3 엔드포인트: VPC Endpoint (Gateway vs Interface), PrivateLink
4.4 글로벌 서비스: Route 53(라우팅 정책), CloudFront(캐싱), Global Accelerator

제5장: 보안, 거버넌스 및 모니터링 (Security & Monitoring)

5.1 권한 및 계정 관리: IAM Role, AWS Organizations, SCP(서비스 제어 정책)
5.2 데이터 보호: AWS KMS(암호화 키), Secrets Manager, AWS Certificate Manager(ACM)
5.3 위협 탐지 및 감사: CloudTrail, AWS Config, GuardDuty, Amazon Inspector, Amazon Macie
5.4 모니터링: CloudWatch(알람, 로그, 대시보드), EventBridge(이벤트 트리거)

제6장: 애플리케이션 통합 및 메시징 (App Integration)

6.1 메시지 큐 및 알림: Amazon SQS (Standard vs FIFO), Amazon SNS (팬아웃 아키텍처)
6.2 워크플로 자동화: AWS Step Functions, AppFlow
6.3 스트리밍 데이터: Amazon Kinesis(Data Streams, Firehose, Analytics)

제7장: 비용 최적화 및 재해 복구 (Cost & DR)

7.1 비용 관리: AWS 예산(Budgets), Cost Explorer, Savings Plans
7.2 재해 복구(DR) 전략: RPO/RTO 기반 설계 (Pilot Light, Warm Standby, Multi-site)

# 1.1 Amazon EC2 (Elastic Compute Cloud)

📌 핵심 요약

정의: 클라우드에서 가상 서버를 제공하는 서비스.
설계 원칙:
- 운영 오버헤드 최소화 → 서버리스(Lambda/Fargate) 고려.
- 비용 최적화 → 구매 옵션(Spot, Savings Plans) 활용.
- 고가용성 → Multi-AZ 및 Auto Scaling 필수.

💰 1. 구매 옵션 (비용 최적화의 핵심)

시험 문제에서 ‘비용 최소화’ 단어가 나올 때 선택하는 기준입니다.

옵션	특징	정답이 되는 조건	❌ 오답이 되는 조건
On-Demand	약정 없음, 초 단위 과금	단기, 예측 불가능, 중단되면 안 됨	장기 운영 + “비용 절감” 요구 시
Spot Instance	최대 90% 할인, AWS가 회수 가능	상태 비저장(Stateless), 배치 작업, 중단 허용	중단되면 안 되는 DB, 마스터 노드, 결제 처리
Reserved(RI)	1~3년 약정, 높은 할인	꾸준한 사용량(Steady State)	인스턴스 패밀리/리전 변경이 예상될 때
Savings Plans	시간당 일정 금액($) 약정	유연성 필요 (인스턴스 패밀리/지역 변경 가능)	특정 인스턴스를 정확히 지정해야 할 때
Dedicated Host	물리적 서버 전용 점유	라이선스 준수(BYOL), 기업 규정	단순 비용 절감이 목적일 때 (가장 비쌈)

시험 팁 (Q140, Q167 참고)

“중단 가능한 상태 비저장 작업” + “최저 비용” = Spot Instance “1년 이상 꾸준한 활용” + “유연한 인스턴스 변경” = Compute Savings Plans

오답 함정

Spot Instance는 “비용 절감”이라는 키워드만 보고 고르면 틀립니다. “중단되면 안 된다(must not be interrupted)” 조건이 있으면 즉시 제외하세요.

⚡ 2. 인스턴스 패밀리 (상황별 선택)

문제에서 요구하는 워크로드에 따라 앞 글자를 보고 고르세요.

패밀리	최적화 대상	키워드	❌ 오답이 되는 조건
C (Compute)	CPU	배치 처리, 미디어 인코딩, 과학적 모델링	메모리 집약적 DB 워크로드
R / X (Memory)	RAM	SAP, 인메모리 DB, 오픈서치 (Q219)	CPU 집약적 연산만 필요할 때
I / D / H (Storage)	로컬 IOPS	NoSQL DB, 데이터 웨어하우징	데이터 내구성이 중요할 때 (로컬 스토리지는 인스턴스 종료 시 소멸)
T / M (General)	균형	웹 서버, 개발 환경	극단적 성능 요구 시

🕸️ 3. 배치 그룹 (Placement Groups)

인스턴스를 물리적으로 어떻게 배치할 것인가? (Q306, Q712, Q723)

유형	배치 방식	정답 키워드	❌ 오답이 되는 조건
클러스터(Cluster)	단일 AZ, 인스턴스끼리 가깝게	낮은 지연시간, HPC, 높은 처리량	장애 격리가 필요할 때 (단일 AZ라 AZ 장애 시 전체 영향)
분산(Spread)	각 인스턴스 → 서로 다른 랙	개별 인스턴스 장애 격리, 소규모 중요 인스턴스	AZ당 최대 7개 제한 → 대규모 인스턴스 그룹에 부적합
파티션(Partition)	여러 랙을 논리적 파티션으로 분할	HDFS, HBase, Cassandra 대규모 분산	단순 지연 최소화가 목적일 때

🔐 4. EC2 보안 및 권한 (Q17, Q289, Q403)

IAM Role (인스턴스 프로파일): EC2 내부 애플리케이션이 S3나 DynamoDB에 접근할 때 Access Key를 직접 넣지 마세요. 대신 IAM 역할을 인스턴스에 부여하는 것이 가장 안전합니다.
Security Groups: 상태 저장(Stateful). 허용 규칙만 설정 가능.

Access Key 직접 입력은 항상 오답

문제에서 “가장 안전한 방법”을 물으면 Access Key 하드코딩은 무조건 오답입니다. EC2 → IAM Role / Lambda → Execution Role / ECS Task → Task Role

🛠️ 5. 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: 야간 배치 작업의 실행 시간 단축 (Q271, Q680)

문제: 매일 정해진 시간에 실행되는데 확장이 느림.
해결: **예약된 조정(Scheduled Scaling)**을 사용하여 작업 시작 30분 전에 미리 인스턴스를 늘려둠.

✅ 사례 2: 인스턴스 상태 유지 및 빠른 초기화 (Q335, Q594)

문제: 인스턴스 시작 시 데이터를 로드하는 데 시간이 너무 오래 걸림.
해결: 최대 절전 모드(Hibernation) 또는 **EC2 웜 풀(Warm Pools)**을 사용하여 미리 초기화된 인스턴스를 대기시킴.

✅ 사례 3: 하이퍼바이저 수준의 관리 오버헤드 제거 (Q163, Q516)

문제: 인스턴스 관리가 귀찮고 확장성이 중요함.
해결: AWS Fargate (서버리스 컨테이너 컴퓨팅) 사용.

🔀 6. 멀티 서비스 조합 패턴 (고득점 필수)

SAA 고득점 문제는 단일 서비스가 아니라 여러 서비스의 조합을 묻습니다.

패턴 1: 기본 고가용성 웹 아키텍처

[Route 53]
    |
[CloudFront] ← 전 세계 캐싱
    |
[ALB] ← Multi-AZ 분산
 /     \
[EC2-AZ-A]  [EC2-AZ-B]  ← ASG (Auto Scaling Group)
    |             |
      [RDS Multi-AZ]  ← 자동 Failover

키워드 조합: “고가용성” + “장애 허용” + “전 세계 사용자”

패턴 2: 비용 최적화 배치 처리

[EventBridge Schedule]
    |
[SQS Queue] ← 작업 버퍼링
    |
[EC2 Spot Fleet] ← 최대 90% 절감
    |
[S3] ← 결과 저장

키워드 조합: “중단 가능” + “비용 최소화” + “배치 처리”

패턴 3: Spot 혼합 전략 (중단 방지)

[ASG Mixed Policy]
 ├─ On-Demand (기본 용량, 20%)  ← 절대 중단되면 안 되는 최소 용량
 └─ Spot (나머지 80%)           ← 비용 절감

키워드 조합: “비용 절감” + “일부 중단은 허용” + “안정성도 필요”

🔗 연결 문서 (관련 주제)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

사용법: 답을 보지 말고 소리 내어 설명해보세요. 막히는 항목이 취약점입니다.

“비용 절감 + 중단 가능 + 상태 비저장” → 어떤 구매 옵션? 왜?
“비용 절감 + 절대 중단 불가 + 1년 이상” → RI vs Savings Plans 차이는?
HPC 워크로드에서 1ms 미만 지연시간이 필요하다 → 배치 그룹 유형과 이유는?
EC2가 S3 파일을 올려야 할 때 가장 안전한 방법은? Access Key 방식의 문제점은?
특정 시간에만 트래픽이 몰린다 → Target Tracking vs Scheduled Scaling 중 무엇, 왜?

# 1.2 Auto Scaling & ELB (Elastic Load Balancing)

📌 핵심 요약

목적: 트래픽 부하 분산(ELB)과 수요에 따른 자원 조절(ASG)을 통해 고가용성 및 비용 효율성 달성.
설계 원칙:
- 단일 장애 지점(SPOF) 제거 → Multi-AZ 배치.
- 애플리케이션 상태 분리 → Stateless(상태 비저장) 설계 (세션은 ElastiCache에 저장).

⚖️ 1. Elastic Load Balancer (ELB) 유형 비교

문제에서 ‘어떤 로드 밸런서를 쓸 것인가?‘를 결정하는 기준입니다.

유형	계층 (Layer)	정답 키워드	❌ 오답이 되는 조건
ALB (Application)	L7 (HTTP/HTTPS)	경로(/images) 또는 호스트(api.com) 기반 라우팅, 마이크로서비스, ECS	고정 IP 필요 시 / 초당 수백만 TCP 요청 처리 시
NLB (Network)	L4 (TCP/UDP)	초당 수백만 요청, 고정 IP, 낮은 지연시간, 게임/스트리밍 (Q352, Q642)	HTTP 헤더/경로 기반 라우팅 필요 시
GLB (Gateway)	L3 (IP Packets)	타사 가상 방화벽/보안 어플라이언스 검사 (Q19, Q21)	단순 웹 트래픽 분산 시 (오버스펙)

오답 주의 (Q70, Q713)

ALB는 HTTP 오류(5xx)를 감지하고 상세한 상태 확인이 가능하지만, NLB는 기본적으로 TCP 핸드셰이크 성공 여부만 확인합니다.

애플리케이션 지연이 발생하는데 CPU/Memory가 낮다면? → RDS Proxy(Q713)나 연결 풀링 문제일 가능성이 높음.

ALB는 고정 IP를 지원하지 않습니다. 고정 IP가 필요하면 NLB를 사용하거나, ALB 앞에 NLB를 두는 구조를 사용합니다.

📈 2. Auto Scaling Group (ASG) 조정 정책

‘언제 인스턴스를 늘리고 줄일 것인가?‘에 대한 결정입니다.

정책	동작 방식	정답 키워드	❌ 오답이 되는 조건
대상 추적 (Target Tracking)	CPU 등 지표를 목표값으로 유지	”CPU 50% 유지”, 일반적인 확장 (Q130, Q297)	트래픽 패턴이 예측 가능한 경우 (더 나은 옵션 있음)
예약된 조정 (Scheduled)	정해진 시간에 미리 확장	”금요일 세일”, “매일 9시 출근”, 예측 가능 패턴 (Q271, Q333)	패턴이 불규칙하고 예측 불가능할 때
예측 조정 (Predictive)	ML로 과거 패턴 분석 후 선제 확장	”과거 데이터 기반”, “미리 대비” (Q342, Q720)	서비스 초기라 데이터가 없을 때
단계 조정 (Step Scaling)	알람 임계값에 따라 단계별 확장	CloudWatch 알람과 연동, 세밀한 조정 필요 시	단순한 목표값 유지로 충분한 경우

🏗️ 3. 고가용성 설계 전략 (HA)

✅ 세션 관리 (Sticky Sessions vs Stateless)

Sticky Sessions (세션 고정): 특정 사용자를 특정 인스턴스에 계속 연결. 인스턴스 장애 시 데이터 유실 위험.
Stateless (상태 비저장): 세션 정보를 ElastiCache(Redis) 또는 DynamoDB에 저장. 인스턴스가 삭제되어도 사용자 경험 유지. (Q209, Q390)

Sticky Session은 거의 항상 오답

“고가용성” + “세션 유지”가 함께 나오면 Sticky Session이 아니라 ElastiCache에 세션 외부 저장이 정답입니다. Sticky Session은 인스턴스가 죽으면 세션 데이터도 같이 사라지기 때문입니다.

✅ 상태 확인 (Health Checks)

EC2 상태 확인: 인스턴스 활성 여부만 확인.
ELB 상태 확인: 애플리케이션이 실제 응답을 하는지 확인.
팁: ASG가 비정상 인스턴스를 빨리 교체하게 하려면 ELB 상태 확인을 ASG에 연결해야 함. (Q70, Q264)

🛠️ 4. 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: 특정 국가의 접속만 허용하고 싶을 때 (Q170, Q399, Q608)

해결: ALB 앞에 AWS WAF를 두고 지리적 일치(Geo-match) 규칙을 설정하거나, CloudFront의 지리적 제한 기능을 사용.

✅ 사례 2: 트래픽 급증 시 데이터 유실 방지 (Q228, Q404, Q462)

문제: 트래픽이 너무 몰려 서버가 죽거나 DB 쓰기가 실패함.
해결: **SQS(Simple Queue Service)**를 앞에 두어 트래픽을 버퍼링(Buffering)하고, 서버는 큐에서 가져와 처리하도록 설계(Decoupling).

✅ 사례 3: 인터넷 통신 없이 S3/DynamoDB 접근 (Q4, Q91, Q176)

해결: VPC Endpoint (Gateway) 사용. 인터넷 게이트웨이나 NAT 게이트웨이 비용을 아끼고 보안 강화.

🔀 5. 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: 보안 강화 웹 아키텍처

[사용자]
    |
[Route 53] ← 지역별 지연 기반 라우팅
    |
[CloudFront] ← WAF 연동 (지역 차단, SQL Injection 방어)
    |
[ALB] ← HTTPS 리스너, 인증서(ACM)
    |
[EC2 ASG, Multi-AZ]
    |
[RDS Aurora Multi-AZ]

키워드: “전 세계 사용자” + “보안 강화” + “고가용성”

패턴 2: 마이크로서비스 라우팅

[ALB]
 ├─ /api/*     → [ECS Service A] (API 서버)
 ├─ /images/*  → [ECS Service B] (이미지 서버)
 └─ /auth/*    → [ECS Service C] (인증 서버)

키워드: “경로 기반 라우팅” + “마이크로서비스” + “독립 확장”

패턴 3: 트래픽 급증 완충 (Decoupling)

[ALB]
    |
[EC2 ASG] ── 직접 DB 쓰기 대신 ──→ [SQS Queue]
                                          |
                                   [EC2 Worker ASG] ← 속도 제어하며 처리
                                          |
                                       [RDS]

키워드: “DB 과부하 방지” + “트래픽 급증” + “데이터 유실 방지”

🔗 연결 문서 (관련 주제)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

사용법: 답을 보지 말고 소리 내어 설명해보세요. 막히는 항목이 취약점입니다.

초당 수백만 건의 UDP 트래픽 처리 → ALB vs NLB, 이유는?
“고가용성” + “세션 유지”가 필요할 때 → Sticky Session이 오답인 이유와 올바른 설계는?
CPU가 낮은데 응답이 느리다 → 어디를 먼저 의심해야 하는가?
트래픽이 몰리기 30분 전에 미리 서버를 늘려야 한다 → 어떤 ASG 정책, 이유는?
ALB에 고정 IP를 붙여야 한다는 요구사항 → 어떻게 구성하는가?

# 1.3 서버리스 컴퓨팅 (AWS Lambda)

📌 핵심 요약

정의: 서버를 프로비저닝하거나 관리하지 않고도 코드를 실행할 수 있는 이벤트 기반 컴퓨팅 서비스.
설계 원칙:
- 운영 오버헤드 최소화: 인프라 관리 없이 비즈니스 로직에만 집중.
- 결합 해제(Decoupling): SQS, SNS 등과 결합하여 비동기 처리 구현.
- 비용 최적화: 코드가 실행되는 시간(밀리초 단위)에 대해서만 과금.

⚙️ 1. 주요 특징 및 제한 사항

시험에서 Lambda가 정답이 되거나 오답이 되는 기준입니다.

특징	상세 내용	정답 포인트	❌ 오답이 되는 조건
실행 시간	최대 15분	짧은 이벤트 처리	15분 이상 작업 → EC2 또는 AWS Batch (Q369)
임시 저장소	/tmp (512MB ~ 10GB)	대용량 파일 임시 처리 (Q107)	처리 후 데이터를 영구 보존해야 할 때 (S3/EFS 필요)
상태	상태 비저장(Stateless)	단발성 처리 작업	상태를 메모리에 유지해야 하는 장기 프로세스
트리거	S3, SQS, API Gateway, EventBridge	”객체가 업로드되면 자동으로…” (Q18, Q63)	지속적인 폴링이 필요한 경우
동시성	기본 1,000 (리전별 제한)	적정 규모 처리	극도로 높은 동시성이 예측될 때 → 사전 동시성 설정 필요

Lambda가 오답이 되는 대표 시나리오

실행 시간이 15분 초과 → AWS Batch 또는 EC2

지속적인 소켓 연결 유지 필요 → EC2

대용량 메모리(수백 GB) 처리 → EC2 메모리 최적화 인스턴스

GPU 필요 (ML 추론 등) → EC2 GPU 인스턴스 또는 SageMaker

🚀 2. Lambda 성능 및 최적화

지연 시간(Latency)이나 콜드 스타트 문제를 해결하는 방법입니다.

문제	해결책	키워드
콜드 스타트 지연	Provisioned Concurrency	”즉각적인 응답”, “피크 시간 대비” (Q516, Q724)
Java 런타임 초기화 느림	Lambda SnapStart	”Java”, “시작 지연 단축” (Q573)
CPU 부족 (계산 집약)	메모리 할당 증가	메모리 ↑ = CPU ↑ (비례 관계)
함수 실행 15분 초과	AWS Batch / Step Functions	장기 작업, 워크플로 오케스트레이션

🛡️ 3. 보안 및 네트워크 (VPC Access)

Lambda가 다른 서비스나 프라이빗 자원에 접근할 때의 규칙입니다.

실행 역할(Execution Role): Lambda가 S3나 DynamoDB를 읽으려면 반드시 IAM Role이 필요함 (Q403, Q289).
VPC 내부 연결: 프라이빗 서브넷의 RDS 등에 접근하려면 VPC 구성이 필요하며, 보안 그룹 규칙이 올바르게 설정되어야 함 (Q184).
인터넷 연결: VPC 내부에 배치된 Lambda가 외부 인터넷에 나가려면 NAT Gateway가 필수임.

VPC Lambda의 함정

Lambda를 VPC에 배치하면 인터넷 접근이 기본 차단됩니다. S3나 DynamoDB에 프라이빗하게 접근하려면 → VPC Endpoint 사용. 외부 인터넷이 필요하면 → NAT Gateway 필수.

🛠️ 4. 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: 대량의 파일 변환 및 처리 (Q18, Q63, Q110, Q161)

문제: 사용자가 S3에 파일을 올리면 즉시 이미지 크기를 조정하거나 형식을 변환해야 함.
해결: S3 이벤트 알림 + Lambda.
심화: 트래픽이 너무 몰려 처리가 누락된다면? → SQS를 중간에 두어 버퍼링 (Q404, Q195).

✅ 사례 2: 마이크로서비스 간의 비동기 통신 (Q10, Q462, Q672)

문제: 주문 시스템에서 트래픽이 급증할 때 DB 부하를 줄이고 순차적으로 처리하고 싶음.
해결: API Gateway + SQS(FIFO) + Lambda.
이유: SQS가 메시지를 보관해주고, Lambda가 가능한 만큼씩 가져가서 처리함(Throttling 방지).

✅ 사례 3: 운영 오버헤드 감소 (Q316)

문제: EC2에서 주기적으로 스크립트를 돌리는데 비용이 많이 들고 관리가 힘듦.
해결: EventBridge(Schedule) + Lambda.
이유: 서버를 24시간 켜둘 필요 없이 필요할 때만 실행됨.

💡 5. 한 줄 공식 (SAA 득점 키워드)

“운영 오버헤드 최소화” + “이벤트” = Lambda
“실시간 처리” + “서버리스” = Lambda
“지연 시간 최소화(콜드 스타트)” = Provisioned Concurrency
“15분 이상 걸리는 작업” = 오답(Lambda 불가)
“순서 보장 처리” + “Lambda 트리거” = SQS FIFO

🔀 6. 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: 이벤트 기반 파일 처리

[사용자] → S3 업로드
    |
[S3 Event Notification]
    |
[SQS Queue] ← 버퍼링 (트래픽 급증 대비)
    |
[Lambda] ← 이미지 리사이징 / 형식 변환
    |
[S3 Output Bucket] + [DynamoDB] ← 결과 저장 + 메타데이터

키워드: “파일 업로드 시 자동 처리” + “누락 없이” + “서버리스”

패턴 2: API 기반 비동기 주문 처리

[사용자]
    |
[API Gateway] ← REST API, 인증(Cognito/IAM)
    |
[SQS FIFO] ← 순서 보장, 중복 제거
    |
[Lambda] ← 주문 처리 로직 (동시성 제어)
    |
[RDS / DynamoDB] ← 최종 저장
    |
[SNS] ← 처리 완료 알림 (이메일, SMS)

키워드: “순서 보장” + “트래픽 급증 허용” + “서버리스 API”

패턴 3: 서버리스 스케줄 작업

[EventBridge Rule (cron)]
    |
[Lambda] ← 리포트 생성, 데이터 정제
    |
[S3] ← 리포트 저장
    |
[SES / SNS] ← 이메일 발송

키워드: “주기적 작업” + “서버 불필요” + “운영 오버헤드 없음”

🔗 연결 문서 (관련 주제)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

사용법: 답을 보지 말고 소리 내어 설명해보세요. 막히는 항목이 취약점입니다.

Lambda가 S3에 접근 못 한다 → 가장 먼저 확인할 것과 이유는?
주문 정보를 ‘순서대로’ 처리해야 한다 → 어떤 서비스 조합, SQS Standard가 안 되는 이유는?
Lambda를 VPC에 넣었더니 외부 API 호출이 안 된다 → 원인과 해결책은?
Java Lambda가 콜드 스타트 때문에 느리다 → Provisioned Concurrency vs SnapStart 차이는?
처리 시간이 20분인 작업을 Lambda로 할 수 있는가? 대안은 무엇인가?

# 1.4 컨테이너 서비스 (ECS, EKS, Fargate)

📌 핵심 요약

목적: 애플리케이션을 패키징하여 일관된 환경에서 실행 및 확장.
설계 원칙:
- 운영 오버헤드 최소화: 서버 관리 없이 컨테이너만 실행하려면 Fargate 선택.
- 마이크로서비스 분할: 모놀리식 앱을 작게 나누어 독립적으로 배포 (Q143, Q670).
- 이식성(Portability): 오픈 소스 쿠버네티스 표준이 필요하면 EKS 선택.

🏗️ 1. 서비스별 비교 (무엇을 쓸 것인가?)

서비스	특징	정답 키워드	❌ 오답이 되는 조건
Amazon ECS	AWS 전용 컨테이너 오케스트레이션	AWS 서비스 통합, 단순함	기존 K8s 환경을 그대로 이전해야 할 때
Amazon EKS	관리형 Kubernetes	오픈 소스 표준, 기존 K8s 이전 (Q198, Q263)	K8s 경험이 없고 단순함이 우선일 때 (오버스펙)
AWS Fargate	서버리스 컨테이너 실행	서버 관리 없음, 운영 오버헤드 최소화 (Q163, Q516, Q659)	특정 인스턴스 타입 제어가 필요할 때 (GPU 등)
Amazon ECR	컨테이너 이미지 저장소	이미지 저장 및 ECS/EKS 배포 (Q163)	이미지 저장만이 목적이 아닐 때 (실행은 ECS/EKS)

ECS vs EKS 선택 기준

“기존 Kubernetes”, “K8s 표준 도구”, “코드 변경 없이 AWS 이전” → EKS

“AWS 네이티브”, “단순”, “빠른 시작” → ECS

둘 다 + “서버 관리 없음” → 각각 + Fargate

⚡ 2. ECS/EKS의 실행 모델 (Launch Types)

실행 모델	특징	정답 키워드	❌ 오답이 되는 조건
EC2 Launch Type	EC2 인스턴스를 직접 관리	비용 최적화(Reserved EC2), 특수 인스턴스 타입 필요	”인프라 관리 책임을 원하지 않음” 조건 존재 시
Fargate Launch Type	서버 없이 컨테이너 단위 실행	”인프라 프로비저닝 및 관리 최소화” (Q58, Q178)	GPU 인스턴스나 특정 하드웨어 요구사항이 있을 때

💾 3. 컨테이너 스토리지 및 네트워크

요구사항	해결책	❌ 오답 및 이유
여러 컨테이너 인스턴스가 파일 공유	Amazon EFS (Q566, Q691)	EBS는 단일 인스턴스 연결만 가능
단일 컨테이너의 로컬 저장소	EBS	EFS는 NFS 공유 목적, 단일 고성능에는 EBS
마이크로서비스 간 경로/호스트 라우팅	ALB (Q112, Q657)	NLB는 L4 → HTTP 경로 인식 불가
고성능 / 고정 IP 필요	NLB	ALB는 고정 IP 미지원

EBS는 컨테이너 공유 스토리지로 오답

EBS는 단일 EC2 인스턴스에만 연결 가능합니다. 여러 AZ에 걸친 ECS 작업들이 동일 데이터를 읽고 써야 한다면 반드시 EFS를 선택하세요.

🛠️ 4. 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: 모놀리식 애플리케이션의 현대화 (Q670)

문제: 단일 EC2에서 돌아가는 앱이 수정/패치가 어렵고 성능이 떨어짐.
해결: 앱을 마이크로서비스로 분할하고 Amazon ECS + Fargate로 배포.
이유: 운영 부담을 줄이면서 수요에 따라 자동으로 확장(Service Auto Scaling) 가능.

✅ 사례 2: 온프레미스 쿠버네티스 이전 (Q198, Q263)

문제: 기존에 Kubernetes를 쓰고 있고, 코드 변경 없이 AWS로 옮기고 싶음.
해결: Amazon EKS + Fargate (또는 EKS 관리형 노드 그룹).
이유: 표준 K8s API를 그대로 사용하면서 인프라 관리만 AWS에 위임.

✅ 사례 3: 컨테이너의 권한 관리 (Q185)

문제: 컨테이너 내부 앱이 S3에 접근해야 함.
해결: **Task Role(작업 역할)**에 IAM 정책 연결.
오답: EC2 인스턴스 역할(Instance Role)을 사용하면 같은 서버 내 모든 컨테이너가 권한을 공유하게 되어 보안상 위험.

💡 5. 한 줄 공식 (SAA 득점 키워드)

“컨테이너” + “서버 관리 최소화” = Fargate
“Kubernetes(쿠버네티스)” = EKS
“컨테이너 공유 파일 저장소” = EFS (EBS 아님!)
“이미지 저장” = ECR
“컨테이너 S3 접근” = Task Role (Instance Role 아님!)

🔀 6. 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: 서버리스 마이크로서비스 전체 아키텍처

[Route 53]
    |
[ALB]
 ├─ /order/*   → [ECS Task: Order Service, Fargate]
 │                   |
 │              [SQS FIFO] → [ECS Task: Payment Worker]
 │                                   |
 ├─ /user/*    → [ECS Task: User Service, Fargate]   [RDS Aurora]
 │                   |                                     ↑
 └─ /product/* → [ECS Task: Product Service, Fargate]─────┘
                         |
                [ElastiCache Redis] ← 세션/캐시

키워드: “마이크로서비스” + “서버 관리 없음” + “독립 확장”

패턴 2: K8s 온프레미스 → AWS 이전

[기존 온프레미스 K8s]
    |
    | (코드 변경 없이 이전)
    ↓
[Amazon EKS]
 ├─ Managed Node Group (EC2)  ← 기존 워크로드
 └─ Fargate Profile           ← 서버리스 워크로드
         |
    [ECR] ← 이미지 저장
    [EFS] ← 공유 스토리지 (PVC 연동)
    [ALB Ingress Controller] ← 인그레스 처리

키워드: “Kubernetes 그대로” + “코드 변경 없이” + “AWS 이전”

패턴 3: 컨테이너 CI/CD 파이프라인

[CodeCommit / GitHub]
    |
[CodeBuild] ← Docker 이미지 빌드
    |
[ECR] ← 이미지 push
    |
[CodeDeploy / ECS Rolling Update]
    |
[ECS Fargate] ← 새 Task 배포 (Blue/Green 가능)

키워드: “CI/CD” + “컨테이너 배포 자동화”

🔗 연결 문서 (관련 주제)

1.2 Auto Scaling & ELB (컨테이너 부하 분산)
1.3 서버리스 컴퓨팅 (Lambda) (함수 vs 컨테이너 선택)
2.2 공유 파일 스토리지 (EFS, FSx) (데이터 지속성)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

사용법: 답을 보지 말고 소리 내어 설명해보세요. 막히는 항목이 취약점입니다.

서버 패치/용량 관리를 아예 안 하고 싶다 → Fargate를 쓰는 이유를 EC2 Launch Type과 비교해 설명하면?
기존 오픈 소스 K8s 도구를 계속 써야 한다 → ECS가 오답인 이유는?
여러 AZ에 걸쳐 있는 ECS 작업들이 동일 파일에 읽고 써야 한다 → EBS가 오답인 이유와 올바른 선택은?
특정 경로(/api/v1)에 따라 다른 컨테이너로 요청을 보내야 한다 → NLB가 안 되는 이유는?
ECS Task가 S3에 접근해야 할 때 → Instance Role vs Task Role 차이와 Task Role이 맞는 이유는?

# 2.1 Amazon S3 (Simple Storage Service)

📌 핵심 요약

정의: 무제한 확장 가능한 객체 수준(Object-level) 스토리지 서비스.
내구성: 99.999999999% (11 nines).
설계 원칙:
- 비용 최적화: 데이터 접근 빈도에 맞는 스토리지 클래스 선택.
- 자동화: **수명 주기 정책(Lifecycle Policy)**을 통한 자동 계층 이동.
- 데이터 보호: 버전 관리, MFA 삭제, Object Lock 활용.

📦 1. 스토리지 클래스 (비용 최적화의 핵심)

문제에서 “가장 비용 효율적인” 솔루션을 찾을 때 기준이 됩니다.

클래스	특징	용도 (키워드)	❌ 오답이 되는 조건
Standard	높은 가용성, 낮은 지연 시간	자주 액세스하는 데이터	비용 절감 요구 + 액세스 빈도 낮을 때
Intelligent-Tiering	패턴을 알 수 없거나 변경됨	분석, 머신러닝 데이터 (Q22, Q212)	액세스 패턴이 명확할 때 (모니터링 비용 낭비)
Standard-IA	낮은 비용, 액세스 시 요금 발생	가끔 액세스, 즉시 필요 (Q153, Q606)	자주 읽는 데이터 (액세스 비용이 Standard보다 비쌀 수 있음)
One Zone-IA	단일 AZ에 저장 (가용성 낮음)	재생성 가능한 데이터, 비용 절감 우선	원본 데이터, 재생성 불가능한 중요 데이터
Glacier Instant	아카이브급 비용, 밀리초 검색	거의 안 보지만 볼 때 바로 봐야 함 (Q49)	몇 분~시간 지연 허용될 때 (Flexible이 더 저렴)
Glacier Flexible	검색에 1분~12시간 소요	백업 데이터	즉각 검색이 필요할 때
Deep Archive	최저 비용, 12~48시간 소요	수년간 보관, 규정 준수용 (Q23, Q126)	1년 이내 자주 검색이 예상될 때

Glacier 계열 오답 함정

즉시 꺼내야 한다 + “아카이브” → Glacier Instant (Flexible 아님)

액세스 패턴 모름 → Glacier가 아니라 Intelligent-Tiering

One Zone-IA → AZ 장애 시 데이터 유실. “재생성 불가능” 데이터에는 절대 오답

🔄 2. 수명 주기 및 복제 (Lifecycle & Replication)

수명 주기 정책 (Lifecycle Policy):
- 전환(Transition): 생성 후 30일 뒤 Standard-IA로 이동, 1년 뒤 Glacier로 이동 등 (Q167, Q214).
- 만료(Expiration): 일정 기간 후 객체 자동 삭제.
복제 (Replication):
- CRR (Cross-Region): 재해 복구(DR) 또는 지리적 근접성을 위해 다른 리전으로 복제 (B1, Q621).
- SRR (Same-Region): 동일 리전 내 다른 계정으로 데이터 복사.

🔒 3. 데이터 보안 및 규정 준수 (Protection)

“실수나 악의적 의도로부터 데이터를 보호해야 함” 문구 시 검토하세요.

버전 관리(Versioning): 객체의 과거 버전을 보존하여 실수로 덮어쓰거나 삭제한 경우 복구 가능 (Q44, Q89).
MFA 삭제(MFA Delete): 객체를 영구 삭제할 때 인증기(OTP) 번호를 요구 (Q256).
S3 Object Lock (WORM): “수정 및 삭제 불가” 요건 시 필수. (Q85, Q154, Q189)
- 규정 준수 모드(Compliance): 관리자 포함 아무도 삭제 불가.
- 거버넌스 모드(Governance): 특정 권한이 있는 사용자만 삭제 가능.

⚡ 4. 성능 최적화 및 분석

S3 Transfer Acceleration:
- 키워드: “대륙 간 전송”, “글로벌 업로드 속도 향상” (Q1, Q711).
- 엣지 로케이션을 사용하여 업로드 경로를 최적화.
멀티파트 업로드 (Multipart Upload): 대용량 파일(100MB 이상 권장)을 조각내어 병렬로 업로드.
Amazon Athena:
- 키워드: “S3에 저장된 로그를 SQL로 분석” (Q2, Q280, Q708).
- 서버리스 대화형 쿼리 서비스.

🛠️ 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: 500GB 이상의 데이터를 여러 대륙에서 수집 (Q1)

해결: S3 Transfer Acceleration + 멀티파트 업로드.
이유: 고속 인터넷이 있어도 물리적 거리가 멀면 지연이 발생하므로 가속화가 필요함.

✅ 사례 2: 30일 후엔 거의 안 보고, 7년 보관 (Q153, Q666)

해결: Lifecycle 정책을 사용하여 Standard → Standard-IA (30일 후) → Deep Archive (90일+ 후) 이동.

✅ 사례 3: “운영 오버헤드 최소화” 하며 S3 데이터 공유 (Q634, Q718)

해결: 교차 계정 IAM Role 부여 또는 S3 버킷 정책 수정.
오답: 데이터를 다른 버킷으로 복사(Replication)하는 것은 비용과 관리 포인트가 늘어남.

💡 한 줄 공식 (SAA 득점 키워드)

“액세스 패턴을 모름” = Intelligent-Tiering
“데이터를 절대 지우면 안 됨” = Object Lock
“S3에서 바로 SQL 쿼리” = Athena
“글로벌 전송 가속” = Transfer Acceleration

🔀 5. 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: 정적 웹사이트 + 글로벌 가속

[사용자 (전 세계)]
    |
[Route 53] ← 도메인 연결
    |
[CloudFront] ← 엣지 캐싱, HTTPS 강제
    |
[S3 버킷] ← 정적 파일 (HTML, CSS, JS, 이미지)
    |
[S3 Transfer Acceleration] ← 업로드 가속 (콘텐츠 관리자용)

키워드: “정적 웹 호스팅” + “전 세계 저지연” + “서버리스”

패턴 2: 비용 최적화 데이터 수명 주기

[데이터 생성 시] → S3 Standard
    |
[30일 후] → Standard-IA  (Lifecycle 자동 이동)
    |
[90일 후] → Glacier Flexible  (백업용)
    |
[365일 후] → Deep Archive  (규정 준수 장기 보관)

키워드: “비용 최소화” + “자동 계층 이동” + “규정 준수 보관”

패턴 3: 보안 강화 S3 아키텍처

[사용자/앱]
    |
[VPC Endpoint (Gateway)] ← 인터넷 경유 없이 S3 접근
    |
[S3 버킷]
 ├─ 버전 관리 ON
 ├─ Object Lock (WORM) ← 삭제/수정 불가
 ├─ MFA Delete ← 영구 삭제 시 OTP 필요
 └─ [Amazon Macie] ← 민감 데이터(개인정보) 자동 감지

키워드: “데이터 보호” + “규정 준수” + “실수로 삭제 방지”

🔗 연결 문서 (관련 주제)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

사용법: 답을 보지 말고 소리 내어 설명해보세요. 막히는 항목이 취약점입니다.

“액세스 패턴을 모른다” → Intelligent-Tiering이 정답이고 Glacier가 오답인 이유는?
버전 관리가 켜진 버킷에서 파일을 삭제하면 실제로 어떻게 되는가? 완전 삭제하려면?
“데이터를 절대 수정/삭제할 수 없어야 함” → 어떤 기능, Compliance vs Governance 차이는?
30일 후 Standard-IA, 1년 후 Deep Archive로 자동 이동시키려면 → 어떻게 설정하는가?
S3에서 SQL 쿼리를 실행해야 한다 → 어떤 서비스, 서버를 띄울 필요가 없는 이유는?

# 2.2 공유 파일 스토리지 (EFS, FSx, Storage Gateway)

📌 핵심 요약

EBS: 단일 EC2 전용 (블록 스토리지).
EFS: 리눅스 전용 공유 폴더 (NFS 프로토콜).
FSx for Windows: 윈도우 전용 공유 폴더 (SMB, AD 통합).
FSx for Lustre: 고성능 컴퓨팅(HPC), 기계 학습용 초고속 스토리지.
Storage Gateway: 온프레미스와 클라우드를 연결하는 하이브리드 솔루션.

📊 1. 스토리지 서비스 비교 (핵심 가이드)


서비스	프로토콜	대상 OS	특징 (키워드)
------	------	------	------
EBS	Block	관계없음	단일 AZ, 단일 인스턴스 전용
EFS	NFS	Linux	Multi-AZ, 자동 확장 (Q5, Q566)
FSx (Windows)	SMB	Windows	AD 통합, DFS 지원 (Q186, Q260)
FSx (Lustre)	Lustre	관계없음	HPC, 1ms 미만, S3 연동 (Q162, Q299)
FSx (ONTAP)	다중	관계없음	NetApp 이전, NFS/SMB/iSCSI 동시 지원 (Q635)

EFS vs FSx 오답 함정

“Windows” or “SMB” or “Active Directory” → FSx for Windows (EFS 오답)

“Linux” or “NFS” or “여러 EC2 공유” → EFS (FSx 오답)

“HPC” or “초고속 병렬” or “ML 학습” → FSx for Lustre

📂 2. 서비스별 상세 설계 포인트

✅ Amazon EFS (Elastic File System)

키워드: “수천 개의 EC2가 동시 접속”, “리눅스 공유 파일 시스템”, “고가용성”.
장점: 용량을 미리 산정할 필요가 없음(자동 확장).
시험 팁: EBS는 한 AZ 안에서만 붙지만, EFS는 여러 AZ에 걸쳐 공유 가능 (Q5, Q691).

✅ Amazon FSx 시리즈

Windows File Server:
- 키워드: “Windows 호환”, “SMB 전용”, “AD 자격 증명 사용” (Q64, Q186).
Lustre:
- 키워드: “고성능 컴퓨팅(HPC)”, “기계 학습(ML)”, “데이터 분석” (Q646, Q664).
- S3 데이터를 가져와서 빠르게 연산하고 결과를 다시 S3에 저장하는 용도로 자주 나옴.

✅ AWS Storage Gateway (하이브리드 스토리지)

온프레미스 서버가 클라우드 저장소를 로컬 디스크처럼 쓰고 싶을 때 사용합니다.

S3 File Gateway: 온프레미스에서 S3로 파일 저장 (NFS/SMB). (Q6, Q362)
Volume Gateway:
- Cached: 자주 쓰는 것만 로컬 저장, 전체는 S3에. (Q307)
- Stored: 전체를 로컬 저장, 백업만 S3에. (Q293, Q324)
Tape Gateway: 물리적 테이프 백업을 클라우드(VTL)로 대체. (Q546)

🛠️ 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: 여러 리전 간 NFS 파일 공유 및 데이터 이동 (Q304, Q661)

해결: AWS DataSync 사용.
이유: 단순 복사보다 빠르고, 네트워크 대역폭 제어가 가능하며, 동기화가 자동화됨.

✅ 사례 2: “대기 시간 없이” 온프레미스 파일 접근 (Q9, Q324)

문제: 데이터 센터 용량은 부족한데, 속도는 빨라야 함.
해결: Storage Gateway (Volume Gateway - Stored 또는 Cached).
이유: 로컬에 캐시를 두어 사용자에게 로컬급 속도를 제공하면서 실제 데이터는 S3에 보관.

✅ 사례 3: 윈도우 기반 앱의 고가용성 공유 저장소 (Q60, Q186)

해결: FSx for Windows File Server (Multi-AZ 구성).
오답: EFS는 윈도우(SMB)를 네이티브로 지원하지 않음.

💡 한 줄 공식 (SAA 득점 키워드)

“Linux 공유 스토리지” = EFS
“Windows 공유 스토리지 / AD 통합” = FSx for Windows
“HPC / 초고속 병렬 처리” = FSx for Lustre
“온프레미스 테이프 백업 대체” = Tape Gateway
“대량의 파일 마이그레이션(네트워크)” = DataSync

🔀 4. 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: 온프레미스 + 클라우드 하이브리드 파일 시스템

[온프레미스 Windows 서버]
    |
[FSx for Windows (Multi-AZ)] ← SMB, AD 통합
    |
[Active Directory (AWS Managed AD)]
    |
[Storage Gateway (File)] ← 로컬 캐시 제공

키워드: “Windows 앱” + “AD 자격증명 유지” + “클라우드 확장”

패턴 2: ML 학습 파이프라인 + 고성능 스토리지

[S3] ← 원시 학습 데이터 저장
    |
[FSx for Lustre] ← S3 데이터를 초고속으로 마운트 (1ms)
    |
[EC2 P3/P4 (GPU 인스턴스)] ← 모델 학습
    |
[S3] ← 학습 결과 저장

키워드: “기계 학습” + “고성능” + “S3 데이터 연산”

패턴 3: 온프레미스 NAS → AWS 마이그레이션

[온프레미스 NFS 서버]
    |
[AWS DataSync Agent] ← 온프레미스에 설치
    |
[AWS DataSync] ← 증분 복사, 자동 검증
    |
[Amazon EFS] ← 클라우드 공유 파일 시스템 (Linux)
    또는
[FSx for Windows] ← Windows 환경

키워드: “NAS 마이그레이션” + “자동 동기화” + “데이터 무결성”

🔗 연결 문서 (관련 주제)

1.1 Amazon EC2 및 컴퓨팅 (EBS 비교)
2.1 Amazon S3 스토리지 (Storage Gateway의 종착지)
7.2 재해 복구(DR) 전략 (백업 및 복원)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

사용법: 답을 보지 말고 소리 내어 설명해보세요. 막히는 항목이 취약점입니다.

여러 Linux EC2가 같은 파일을 공유해야 한다 → EBS가 오답인 이유와 올바른 선택은?
Windows 서버 + Active Directory 인증 필요 → EFS가 오답인 이유는?
ML 학습 데이터를 S3에서 가져와 초고속으로 처리해야 한다 → 어떤 서비스, 이유는?
온프레미스에서 S3를 네트워크 드라이브처럼 마운트하고 싶다 → 어떤 Gateway 유형?
온프레미스 NFS 데이터를 매일 밤 EFS로 자동 동기화 → Snowball이 오답인 이유와 올바른 선택은?

# 2.3 데이터 전송 및 마이그레이션 (Snow Family, DataSync)

📌 핵심 요약

Snow Family: 네트워크가 느리거나 끊긴 환경에서 물리적 장치를 이용한 오프라인 이전.
DataSync: 인터넷이나 Direct Connect를 이용한 온라인 자동 데이터 전송.
Transfer Family: SFTP/FTP 프로토콜을 사용하여 S3나 EFS로 직접 파일 전송.

📦 1. AWS Snow Family (오프라인 전송)

네트워크 대역폭이 부족하여 온라인 전송에 수개월이 걸릴 때 사용합니다. (Q6, Q331, Q435)

장치명	용량 (최대)	특징 (키워드)	❌ 오답이 되는 조건
Snowcone	8TB ~ 14TB	작고 가벼움, 열악한 환경, IoT (Q125)	수십 TB 이상 대량 이전 시 (Snowball 필요)
Snowball Edge	80TB ~ 100TB	대규모 이전, EC2 실행 가능 (Q6, Q215)	네트워크 상태 양호 + 정기 동기화 필요 시 (DataSync)
Snowmobile	100PB	초대형 데이터센터 이전, 트럭 이동	수 TB 수준의 소규모 이전 시 (오버스펙)

Snowball vs DataSync 선택 기준

네트워크 대역폭 제한 / 수십 TB 이상 / 1회성 이전 → Snowball

네트워크 양호 / 주기적 동기화 / 증분 복사 → DataSync

두 조건이 섞이면: 초기 대량 이전은 Snowball, 이후 동기화는 DataSync

시험 팁: Snowball vs DataSync 선택 기준

“네트워크 대역폭 제한” + “수십 TB 이상” = Snowball

“인터넷 연결 양호” + “주기적인 동기화” = DataSync

🔄 2. AWS DataSync (온라인 전송)

온프레미스 스토리지(NFS, SMB)와 AWS(S3, EFS, FSx) 간의 데이터를 자동으로 복사합니다.

특징:
- 오픈 소스 도구보다 10배 빠름.
- 증분 전송: 변경된 데이터만 골라서 복사 (Q445).
- 예약 기능: 매일 밤 특정 시간에 실행 가능 (Q304, Q528).
- 데이터 무결성: 전송 중 데이터 검증 자동 수행 (Q626).
구성 요소: 온프레미스에 에이전트(Agent) 설치 필수. (Q102, Q694)

📂 3. AWS Transfer Family (파일 관리)

기존에 사용하던 SFTP, FTPS, FTP 워크플로를 변경 없이 AWS로 옮길 때 사용합니다.

용도: 외부 파트너와의 안전한 파일 교환 (Q188, Q334).
장점: 서버리스(관리 오버헤드 없음), 데이터는 자동으로 S3 또는 EFS에 저장됨. (Q421, Q510)
보안: IAM, Route 53, AS2 프로토콜 지원 (Q457).

🛠️ 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: 70TB 비디오 파일을 “최소 대역폭”으로 이전 (Q6, Q215, Q583)

문제: 인터넷 속도는 느린데 데이터 양은 너무 많음.
해결: AWS Snowball Edge.
이유: 온라인으로 보내면 수개월이 걸리지만, Snowball은 장치를 보내고 받는 데 며칠이면 충분함.

✅ 사례 2: 두 리전의 NFS 파일 시스템 간 “주기적” 데이터 복제 (Q304, Q661)

해결: AWS DataSync.
이유: Snowball은 1회성 마이그레이션에 적합하지만, 정기적인 동기화는 DataSync가 정답.

✅ 사례 3: 파트너가 SFTP로 데이터를 올려야 함 (Q188, Q510)

해결: AWS Transfer Family (SFTP).
오답: EC2에 직접 SFTP 서버를 구축하는 것은 “운영 오버헤드 최소화” 요건에 위배됨.

💡 한 줄 공식 (SAA 득점 키워드)

“대역폭 부족 / 오프라인 / 물리적 장치” = Snowball
“네트워크 기반 / 10배 빠른 전송 / 자동 검증” = DataSync
“SFTP / FTP / 기존 워크플로 유지” = Transfer Family
“테이프 백업을 클라우드로” = Tape Gateway (Storage Gateway)

🔀 4. 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: 대규모 1회성 마이그레이션 + 이후 지속 동기화

[온프레미스 데이터센터 (80TB)]
    |
[Snowball Edge] ← 1회성 대량 이전 (트럭으로 AWS 전송)
    |
[S3 버킷] ← 초기 데이터 적재 완료
    |
[DataSync] ← 이후 변경분만 자동 동기화 (증분)

키워드: “초기 대량 이전” + “이후 주기적 동기화” + “네트워크 대역폭 부족”

패턴 2: 외부 파트너 파일 수신 자동화

[외부 파트너]
    |
[AWS Transfer Family (SFTP)] ← 기존 SFTP 워크플로 유지
    |
[S3 버킷] ← 파일 자동 적재
    |
[EventBridge / S3 Event] ← 파일 도착 감지
    |
[Lambda] ← 파일 처리 자동화

키워드: “SFTP/FTP 유지” + “운영 오버헤드 최소화” + “파트너 파일 수신”

패턴 3: 열악한 환경 데이터 수집 (엣지 컴퓨팅)

[공장/선박/오지 현장]
    |
[Snowball Edge] ← EC2 실행, 로컬 데이터 처리
    |
[네트워크 연결 후] → S3로 데이터 업로드
    또는
[Snowcone] ← 소규모, 매우 열악한 환경

키워드: “인터넷 없는 환경” + “엣지 컴퓨팅” + “데이터 수집”

🔗 연결 문서 (관련 주제)

2.1 Amazon S3 스토리지 (전송된 데이터의 목적지)
2.2 공유 파일 스토리지 (EFS, FSx) (전송된 데이터의 목적지)
7.1 비용 최적화 전략 (Snowball vs 전용선 비용 비교)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

사용법: 답을 보지 말고 소리 내어 설명해보세요. 막히는 항목이 취약점입니다.

10PB 데이터를 옮겨야 한다 → Snowball vs Snowmobile 선택 기준은? DataSync가 오답인 이유는?
온프레미스 NAS 변경분만 매일 밤 S3로 백업 → Snowball이 오답인 이유와 올바른 선택은?
외부 업체가 SFTP로 파일을 올려야 한다 → EC2에 SFTP 서버 구축이 오답인 이유는?
인터넷이 없는 공장에서 데이터를 처리하고 나중에 AWS로 올려야 한다 → 어떤 서비스, 왜?
초기 80TB 이전 후, 이후 매일 변경분만 동기화해야 한다 → 두 서비스를 조합하면?

# 3.1 Amazon RDS (관계형 데이터베이스)

📌 핵심 요약

정의: 클라우드에서 관계형 DB(MySQL, PostgreSQL, Oracle 등)를 설정, 운영, 확장해 주는 관리형 서비스.
설계 원칙:
- 고가용성(HA) → Multi-AZ 배치.
- 읽기 성능 향상 → 읽기 전용 복제본(Read Replica).
- 연결 최적화 → RDS Proxy (Lambda 연동 시 필수).

⚖️ 1. Multi-AZ vs 읽기 전용 복제본 (핵심 비교)

이 차이를 아는 것이 RDS 문제 정답의 80%를 결정합니다.


구분	Multi-AZ (다중 AZ)	Read Replica (읽기 복제본)
------	------	------
복제 방식	동기(Synchronous) 복제	비동기(Asynchronous) 복제
주 목적	재해 복구(DR), 고가용성	읽기 성능 확장(Scalability)
동작	장애 시 자동으로 Standby로 전환	읽기 쿼리를 분산 (최대 15개)
특징	Standby DB는 평소에 접근 불가	복제본 DB에 직접 접근/쿼리 가능
지역	단일 리전 내	리전 내 또는 멀티 리전 가능

오답 함정

“읽기 성능 개선” → Multi-AZ 오답. Standby는 읽기 불가, Read Replica 정답

“쓰기 성능 개선” → Read Replica 오답. 쓰기는 오직 Primary만 처리

“DR / 장애 복구” → Read Replica 오답. 자동 Failover는 Multi-AZ만 가능

시험 팁 (Q182, Q193, Q389)

“장애 시 가동 중지 최소화” → Multi-AZ

“보고용 쿼리 때문에 메인 DB가 느림” → Read Replica

🚀 2. RDS Proxy (연결 관리)

서버리스(Lambda) 환경에서 RDS를 쓸 때 단골로 등장하는 정답입니다. (Q175, Q354, Q700, Q713)

문제 상황: Lambda 함수가 너무 많이 호출되어 DB 연결(Connection) 개수가 초과됨.
해결책: RDS Proxy 도입.
효과:
- 연결 풀링(Connection Pooling): 연결을 재사용하여 DB 부하 감소.
- 빠른 장애 조치: 장애 발생 시 DNS 변경 없이 Proxy가 알아서 처리 (장애 조치 시간 최대 66% 단축).

🔒 3. 보안 및 데이터 보호

✅ 데이터 암호화 (Q121)

미사용 데이터 암호화: AWS KMS 사용. 생성 시에만 설정 가능.
기존 DB 암호화 방법:
1. DB 스냅샷 생성
2. 스냅샷 복사 시 ‘암호화’ 선택
3. 암호화된 스냅샷으로 DB 복원 (이 과정에서 새로운 엔드포인트 발생)

✅ RDS Custom (Q133, Q145)

키워드: “OS 수준의 접근 권한 필요”, “특정 타사 애플리케이션 설치”.
내용: RDS의 관리 편의성과 EC2의 OS 접근 권한을 결합한 서비스.

🛠️ 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: 특정 시점으로 데이터 복구 (PITR) (Q365)

문제: 관리자가 실수로 데이터를 지웠을 때, 5분 전 상태로 복구하고 싶음.
해결: **자동 백업(스냅샷)**을 활용하여 35일 보존 기간 내의 특정 초 단위로 복원 가능.

✅ 사례 2: 쓰기 성능 부족 (IOPS 문제) (Q39, Q353)

문제: 데이터 입력(Insert) 속도가 너무 느림.
해결: 스토리지 유형을 **Provisioned IOPS (io2)**로 변경.
오답: Read Replica는 ‘읽기’ 성능만 개선할 뿐, ‘쓰기’ 성능에는 도움이 되지 않음.

✅ 사례 3: 블루/그린 배포 (Q629)

문제: DB 엔진 버전 업데이트 시 가동 중지 시간을 최소화하고 싶음.
해결: RDS Blue/Green Deployments 사용. 스테이징 환경(Green)에서 먼저 테스트 후 전환.

💡 한 줄 공식 (SAA 득점 키워드)

“DB 장애 조치 / 재해 복구” = Multi-AZ
“읽기 부하 분산 / 보고서 전용 DB” = Read Replica
“Lambda + DB 연결 오류” = RDS Proxy
“OS 접근 권한 필요” = RDS Custom
“가장 비용 효율적인 성능 개선” = GP3 스토리지 (IOPS 개별 설정 가능)

🔀 4. 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: 고가용성 LAMP 스택

[ALB]
    |
[EC2 ASG, Multi-AZ]
    |
[RDS Multi-AZ] ← Primary (쓰기)
    |
[RDS Read Replica] ← 보고서/조회 전용 (읽기)
    |
[ElastiCache Redis] ← 자주 조회되는 결과 캐싱

키워드: “DB 쓰기 고가용성” + “읽기 부하 분산” + “응답 속도 개선”

패턴 2: Lambda + RDS 연결 최적화

[API Gateway]
    |
[Lambda (수백 개 동시 실행)]
    |
[RDS Proxy] ← 연결 풀링 (Connection Pooling)
    |
[RDS Aurora Multi-AZ]

키워드: “Lambda + DB 연결 오류” + “Too many connections” + “서버리스 + RDB”

패턴 3: 무중단 DB 버전 업그레이드

[현재 RDS (Blue)]  →  [Read Replica 동기화]
                              |
                    [Green 환경 테스트 완료 후]
                              |
                    [RDS Blue/Green Deployment] → 트래픽 전환

키워드: “가동 중지 없이 업그레이드” + “Blue/Green” + “롤백 가능”

🔗 연결 문서 (관련 주제)

1.3 서버리스 컴퓨팅 (Lambda) (RDS Proxy와의 관계)
3.2 Amazon Aurora (RDS의 상위 호환 선택지)
5.2 AWS KMS & 보안 (DB 암호화)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

사용법: 답을 보지 말고 소리 내어 설명해보세요. 막히는 항목이 취약점입니다.

Multi-AZ의 Standby에 읽기 쿼리를 보낼 수 있는가? 읽기 분산은 어떻게 하는가?
“보고서 쿼리로 메인 DB가 느리다” → Read Replica가 정답인 이유, Multi-AZ가 오답인 이유는?
Lambda가 RDS에 연결할 때 “Too many connections” 오류 → 원인과 해결책은?
기존 암호화되지 않은 RDS를 암호화하려면 → 왜 클릭 한 번으로 안 되는가?
쓰기 성능이 부족하다 → Read Replica가 오답인 이유와 올바른 해결책은?

# 3.2 Amazon Aurora

📌 핵심 요약

정의: 클라우드 전용으로 설계된 고성능 관계형 데이터베이스 (MySQL 및 PostgreSQL 호환).
성능: 표준 MySQL보다 5배, PostgreSQL보다 3배 빠름.
설계 원칙:
- 고가용성: 데이터가 3개 AZ에 걸쳐 6개 복사본으로 자동 저장됨.
- 유연한 확장: Aurora Serverless를 통한 자동 스케일링.
- 글로벌 복제: Global Database를 통한 1초 미만의 리전 간 복제.

💎 1. Aurora의 핵심 기능


기능	특징	시험 포인트 (키워드)
------	------	------
자동 스토리지 확장	10GB → 최대 128TB 자동 증가	용량 산정 불필요 (Q276)
읽기 복제본	최대 15개 지원 (RDS는 5개)	낮은 지연 시간의 읽기 분산
자가 치유 스토리지	디스크 오류 시 데이터 자동 복구	높은 내구성 및 가용성
빠른 장애 조치	보통 30초 이내에 승격 완료	RTO 단축 요구 시 정답 (Q182, Q420)

Aurora vs RDS 선택 함정

“장애 조치 시간 최소화” → Aurora가 RDS보다 빠름 (30초 vs 수 분)

“리전 간 복제 / 글로벌 DR” → Aurora Global Database (일반 RDS Read Replica 오답)

“읽기 복제본 15개” → Aurora만 가능 (RDS는 5개)

🚀 2. Aurora Serverless (v1 & v2)

인프라 관리 없이 데이터베이스 용량을 자동으로 조정하고 싶을 때 사용합니다. (Q79, Q229, Q572)

주요 용도:
- 예측 불가능한 워크로드: 트래픽이 갑자기 튀거나 아예 없을 때.
- 간헐적 워크로드: 하루에 몇 번만 실행되는 배치 작업 (Q574).
v2의 장점: 세밀한 용량 조정(ACU 단위), 고가용성(Multi-AZ) 지원, 읽기 복제본 지원.

🌍 3. Aurora Global Database (멀티 리전)

전 세계적인 서비스 또는 강력한 재해 복구(DR)가 필요할 때 선택합니다. (Q217, Q273, Q343)

동작: 1개의 기본 리전(쓰기 가능) + 최대 5개의 보조 리전(읽기 전용).
지연 시간: 리전 간 복제 지연 시간 1초 미만.
장점: 리전 단위 장애 시 보조 리전을 1분 이내에 읽기/쓰기 가능하도록 승격(DR 성능 극대화).

🛠️ 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: 개발/테스트용 스테이징 DB 빠르게 만들기 (Q93)

해결: Aurora 복제(Cloning) 사용.
이유: 스냅샷 복원보다 훨씬 빠르며, 변경된 데이터에 대해서만 스토리지 비용이 발생함.

✅ 사례 2: 읽기 지연(Replica Lag) 최소화 (Q337, Q697)

문제: RDS Read Replica에서 1초 이상의 지연이 발생함.
해결: Amazon Aurora로 마이그레이션.
이유: Aurora는 공유 스토리지를 사용하므로 복제 지연이 거의 없음(밀리초 단위).

✅ 사례 3: 데이터베이스의 “운영 오버헤드” 최소화 (Q540, Q596)

해결: Aurora Serverless v2.
이유: 인스턴스 크기를 수동으로 맞출 필요가 없으며, 사용한 만큼만 비용을 지불함.

💡 한 줄 공식 (SAA 득점 키워드)

“가장 짧은 장애 조치 시간” = Amazon Aurora
“예측할 수 없는 트래픽 / 비용 최적화” = Aurora Serverless
“리전 간 빠른 재해 복구(DR)” = Aurora Global Database
“로그가 아닌 스토리지 계층 복제” = Aurora (복제 속도가 RDS보다 빠름)

🔀 4. 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: 글로벌 서비스 + 재해 복구 아키텍처

[리전 A: us-east-1] (Primary, 읽기+쓰기)
    |
[Aurora Global Database] ← 1초 미만 복제
    |
[리전 B: ap-northeast-2] (Secondary, 읽기 전용)
    |
    └─ 리전 A 장애 시 → 1분 내 Primary로 승격 (RTO < 1분)

키워드: “글로벌 서비스” + “리전 단위 DR” + “1초 미만 복제”

패턴 2: 예측 불가 트래픽 + 서버리스 DB

[API Gateway]
    |
[Lambda]
    |
[RDS Proxy] ← 연결 관리
    |
[Aurora Serverless v2] ← 트래픽에 따라 자동 스케일
    (0 ACU ~ N ACU, 사용 없으면 pause 가능)

키워드: “트래픽 예측 불가” + “운영 오버헤드 최소화” + “서버리스 SQL”

패턴 3: 개발/스테이징 환경 빠르게 구성

[Aurora Production DB]
    |
[Aurora Clone] ← 스냅샷보다 훨씬 빠름, 변경분만 비용 발생
    |
[Aurora Staging DB] ← 독립적으로 테스트

키워드: “스테이징 환경 빠르게” + “운영 DB와 분리” + “비용 효율”

🔗 연결 문서 (관련 주제)

3.1 Amazon RDS (Aurora와 RDS의 비교)
7.2 재해 복구(DR) 전략 (Global DB 활용)
3.3 Amazon DynamoDB (비관계형과의 선택 기준)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

사용법: 답을 보지 말고 소리 내어 설명해보세요. 막히는 항목이 취약점입니다.

Aurora가 RDS보다 장애 조치가 빠른 이유는? (스토리지 구조 차원에서 설명)
“리전 장애 시 1분 안에 서비스 복구” → 어떤 Aurora 기능, 일반 Read Replica가 오답인 이유는?
“트래픽이 간헐적이고 예측 불가” → Aurora Serverless가 정답인 이유는?
개발 환경 DB를 빠르게 만들어야 한다 → 스냅샷 복원 vs Aurora Clone 차이는?
Aurora 읽기 복제본이 RDS보다 많을 수 있는 이유는? (스토리지 공유 구조)

# 3.3 NoSQL 및 캐싱 (DynamoDB & ElastiCache)

📌 핵심 요약

DynamoDB: 어떤 규모에서도 10밀리초 미만의 성능을 제공하는 서버리스 Key-Value 데이터베이스.
ElastiCache: DB 부하를 줄이고 읽기 성능을 극대화하기 위한 인메모리 캐시 서비스.
설계 원칙:
- 확장성: 스키마가 유연해야 하거나 트래픽이 엄청날 때 선택.
- 운영 효율: 관리할 서버가 없는 서버리스(DynamoDB) 우선 고려.

⚡ 1. Amazon DynamoDB (NoSQL)

✅ 용량 모드 (비용 최적화 포인트)

시험에서 “비용 효율적인 용량 설계”를 물을 때 핵심입니다.


모드	특징	용도 (키워드)
------	------	------
온디맨드 (On-demand)	사용한 만큼만 지불, 용량 산정 불필요	예측 불가능한 트래픽, 갑작스러운 급증 (Q79, Q520)
프로비저닝 (Provisioned)	RCU/WCU 예약, Auto Scaling 지원	예측 가능한 트래픽, 비용 예측이 중요할 때 (Q363)

✅ 핵심 기능 (문제 해결 전략)

DAX (DynamoDB Accelerator):
- 키워드: “읽기 성능 극대화”, “마이크로초(μs) 지연 시간”, “읽기 집중적 워크로드”.
- 애플리케이션 수정 없이 읽기 성능을 10배 이상 향상 (Q177, Q561).
DynamoDB Streams:
- 키워드: “데이터 변경 시 후속 조치”, “Lambda 연동”.
- 항목이 수정/삭제되면 Lambda를 트리거하여 실시간 처리 (Q400, Q490).
글로벌 테이블 (Global Tables):
- 키워드: “멀티 리전 활성-활성(Active-Active)”, “전 세계 사용자 대기 시간 최소화” (Q507).
TTL (Time to Live):
- 키워드: “일정 기간 후 자동 삭제”, “운영 오버헤드 최소화”.
- 추가 비용이나 작업 없이 오래된 데이터 자동 정리 (Q196, Q214).

🧊 2. Amazon ElastiCache (캐싱)

관계형 DB(RDS) 앞에 두어 성능을 높이는 용도로 자주 나옵니다.


엔진	특징	용도 (키워드)
------	------	------
Redis	Multi-AZ, 복제, 복잡한 자료구조 지원	세션 저장소, 순위표(Leaderboard), 고급 캐싱 (Q209, Q431, Q589)
Memcached	단순한 Key-Value, 수평 확장 용이	단순 객체 캐싱, DB 부하 분산

Redis vs Memcached 선택 기준

“세션 저장” or “캐시 서버 장애 대비” or “Multi-AZ” → Redis

“단순 캐싱” or “수평 확장” → Memcached

Redis는 재시작 후에도 데이터 유지 가능 (AOF/RDB), Memcached는 불가

🛠️ 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: 일관되지 않은 읽기 결과 해결 (Q687)

문제: 테이블에 데이터를 썼는데 바로 읽을 때 예전 데이터가 나옴.
해결: 강력한 일관된 읽기(Strongly Consistent Reads) 요청.
이유: 기본값은 최종 일관성(Eventual Consistency)으로, 아주 짧은 순간 데이터가 다를 수 있음.

✅ 사례 2: DB 부하를 줄이면서 성능 개선 (Q386, Q269)

문제: 보고서 쿼리나 잦은 조회로 RDS가 느려짐.
해결: ElastiCache(조회 결과 캐싱) 또는 RDS Read Replica.
차이: 데이터가 자주 바뀌지 않고 조회만 많다면 ElastiCache가 성능상 더 우위.

✅ 사례 3: 수조 개의 객체 관리 및 자동 정리 (Q214, Q373)

문제: 데이터가 매일 엄청나게 쌓이는데 30일 후엔 필요 없음.
해결: DynamoDB TTL.
오답: S3 수명 주기 정책은 ‘파일’ 단위이고, 테이블 내부 데이터 정리는 TTL이 정답.

💡 한 줄 공식 (SAA 득점 키워드)

“밀리초(ms) 지연 시간” = DynamoDB
“마이크로초(μs) 지연 시간” = DynamoDB + DAX 또는 ElastiCache
“세션 데이터 보관” = ElastiCache(Redis) 또는 DynamoDB
“실시간 데이터 변경 감지” = DynamoDB Streams
“서버리스/NoSQL” = DynamoDB

🔀 4. 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: 글로벌 게임 리더보드 + 세션

[게임 서버 (EC2/ECS)]
    |
[ElastiCache Redis]
 ├─ 세션 데이터 저장 (TTL 설정)
 └─ 리더보드 (Sorted Set 자료구조)
    |
[DynamoDB] ← 영구 사용자 데이터 저장
    |
[DynamoDB Global Tables] ← 전 세계 Active-Active

키워드: “전 세계 사용자” + “낮은 지연” + “세션/순위표”

패턴 2: 이벤트 기반 실시간 처리

[사용자 주문/이벤트]
    |
[DynamoDB] ← 주문 저장
    |
[DynamoDB Streams] ← 변경 감지
    |
[Lambda] ← 재고 차감, 알림 발송 등
    |
[SNS] ← 이메일/SMS 알림

키워드: “데이터 변경 시 자동 후속 처리” + “실시간” + “서버리스”

패턴 3: RDS 읽기 부하 + 캐시 계층

[애플리케이션]
    |
[ElastiCache Redis] ← Cache-Aside 패턴
 ├─ 캐시 HIT → 즉시 반환 (DB 쿼리 없음)
 └─ 캐시 MISS → RDS 조회 → 캐시에 저장
    |
[RDS / Aurora] ← 실제 데이터

키워드: “DB 조회 부하” + “응답 속도 개선” + “자주 바뀌지 않는 데이터”

🔗 연결 문서 (관련 주제)

3.2 Amazon Aurora (Aurora Serverless와 비교)
6.1 Amazon SQS 및 메시징 (SQS와 DynamoDB를 결합한 버퍼링 설계)
1.2 Auto Scaling & ELB (상태 비저장 설계를 위한 세션 관리)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

사용법: 답을 보지 말고 소리 내어 설명해보세요. 막히는 항목이 취약점입니다.

트래픽이 100배로 갑자기 튄다 → On-demand가 정답인 이유, Provisioned가 오답인 이유는?
캐시 서버 장애 시 데이터가 유지되어야 한다 → Redis vs Memcached 선택 이유는?
DynamoDB에서 읽기 속도를 마이크로초로 줄이려면 → ElastiCache가 아닌 DAX를 쓰는 이유는?
데이터 변경 시 Lambda를 자동 실행하려면 → 어떤 기능, SQS와의 차이는?
멀티 리전 Active-Active 구성이 필요하다 → Aurora Global DB vs DynamoDB Global Tables 선택 기준은?

# 3.4 데이터 분석 및 ETL (Redshift, Athena, Glue)

📌 핵심 요약

Redshift: 대규모 데이터 웨어하우스(OLAP). 복잡한 쿼리와 고성능 분석에 최적.
Athena: S3에 저장된 데이터를 SQL로 직접 조회하는 서버리스 서비스.
Glue: 데이터 추출, 변환, 로드(ETL) 및 데이터 카탈로그 관리.
QuickSight: 시각화 및 대시보드 생성 서비스.

🔍 1. 분석 서비스 비교 (상황별 선택 기준)


서비스	특징	주요 키워드 및 용도
------	------	------
Amazon Athena	서버리스, S3 직접 쿼리	임시(Ad-hoc) 분석, 로그 분석 (Q2, Q310)
Amazon Redshift	고성능 데이터 웨어하우스	복잡한 SQL, 페타바이트 분석, 지속 리포팅 (Q144)
Redshift Spectrum	Redshift에서 S3 직접 조회	웨어하우스 + S3 원시 데이터 결합 분석
OpenSearch	로그 검색 및 분석 엔진	실시간 로그 분석, 키워드 검색, Kibana (Q117, Q611)

Athena vs Redshift 선택 기준

“임시 쿼리” + “S3” + “서버리스” + “운영 오버헤드 없음” → Athena

“지속적인 분석” + “복잡한 조인” + “페타바이트” → Redshift

“실시간 로그 검색” + “Kibana” + “키워드 검색” → OpenSearch

🛠️ 2. 데이터 준비 및 변환 (ETL - AWS Glue)

✅ Glue의 핵심 기능 (Q103, Q214, Q688)

Glue Crawler: S3나 DB를 스캔하여 데이터 스키마를 자동으로 찾아 Data Catalog에 저장.
Glue ETL 작업: 데이터를 읽기 전용 형식(Parquet)으로 변환하거나 민감 정보를 제거.
Glue DataBrew: 코딩 없이 시각적으로 데이터를 정리 및 정규화(Recipe 활용).
Job Bookmarks: 이전에 처리한 데이터를 기억하여 중복 처리 방지 (Q103).

📊 3. 시각화 및 리포팅 (Amazon QuickSight)

“관리팀에게 보고서를 보여줘야 함” 문구가 나올 때 정답의 핵심입니다.

데이터 소스: S3, RDS, Redshift, Athena 등 다양한 소스 연결 가능.
보안: 특정 사용자/그룹과 대시보드 공유, 열 수준(Column-level) 권한 제한 (Q16, Q341).
특징: 서버리스, 시각화 대시보드 제공.

🛠️ 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: S3에 저장된 JSON 로그 분석 (Q2, Q280, Q708)

문제: 애플리케이션 로그가 S3에 쌓이고 있음. 최소한의 노력으로 분석하고 싶음.
해결: Amazon Athena.
이유: 별도의 인프라 구축 없이 표준 SQL로 S3 파일을 즉시 조회할 수 있기 때문.

✅ 사례 2: 데이터 형식 변환 (CSV → Parquet) (Q214, Q258, Q717)

문제: 분석 성능을 높이기 위해 S3의 CSV 파일을 Parquet으로 바꿔야 함.
해결: AWS Glue.
이유: Glue는 분산 처리를 통해 대량의 파일을 효율적으로 변환하는 관리형 ETL 도구임.

✅ 사례 3: DB의 보고서용 쿼리 부하 해결 (Q144, Q653, Q709)

문제: RDS에서 월별 보고서를 돌릴 때마다 서비스가 느려짐.
해결: 데이터를 S3로 내보내고 Athena로 분석하거나, Redshift로 마이그레이션.
오답: 단순 조회 성능 향상을 위해 인스턴스 크기를 계속 키우는 것은 비용 효율적이지 않음.

💡 한 줄 공식 (SAA 득점 키워드)

“S3 데이터 + SQL로 조회” = Athena
“데이터 형식 변환(ETL)” = Glue
“페타바이트 규모 / 복잡한 분석” = Redshift
“시각화 / 대시보드” = QuickSight
“로그 파일의 실시간 검색” = OpenSearch

🔀 4. 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: 서버리스 데이터 레이크 분석 파이프라인

[RDS / DynamoDB / 애플리케이션 로그]
    |
[Kinesis Data Firehose] ← 실시간 스트리밍 수집
    |
[S3 Data Lake] ← 원시 데이터 저장
    |
[AWS Glue] ← CSV → Parquet 변환 + 스키마 자동 탐색
    |
[Amazon Athena] ← SQL로 임시 분석
    |
[Amazon QuickSight] ← 대시보드 시각화

키워드: “운영 오버헤드 최소화” + “서버리스 분석” + “임시 쿼리”

패턴 2: 대규모 데이터 웨어하우스 구축

[다양한 소스 (RDS, S3, DynamoDB)]
    |
[AWS Glue ETL] ← 데이터 정제, 변환
    |
[Amazon Redshift] ← OLAP 데이터 웨어하우스
    |
[Redshift Spectrum] ← S3 원시 데이터도 함께 조회
    |
[Amazon QuickSight] ← 경영진 대시보드

키워드: “지속적인 복잡한 분석” + “페타바이트” + “비즈니스 인텔리전스”

패턴 3: 실시간 로그 모니터링

[EC2 / Lambda / 애플리케이션]
    |
[CloudWatch Logs]
    |
[Kinesis Data Firehose]
    |
[Amazon OpenSearch Service] ← 실시간 인덱싱
    |
[Kibana 대시보드] ← 실시간 모니터링, 키워드 검색

키워드: “실시간 로그 분석” + “키워드 검색” + “대시보드”

🔗 연결 문서 (관련 주제)

2.1 Amazon S3 스토리지 (데이터 레이크의 기반)
3.1 Amazon RDS (OLTP 데이터 소스)
6.3 스트리밍 데이터 (Kinesis) (분석 전 데이터 수집)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

사용법: 답을 보지 말고 소리 내어 설명해보세요. 막히는 항목이 취약점입니다.

S3에 쌓인 로그를 가장 적은 노력으로 분석 → Athena 정답, Redshift가 오답인 이유는?
Athena 쿼리 비용을 줄이려면 → 어떤 파일 형식과 최적화 방법을 써야 하는가?
일주일에 한 번만 분석한다 → Redshift 클러스터 유지가 비효율적인 이유는?
CSV 파일을 Parquet으로 변환하고 스키마를 자동 관리 → 어떤 서비스, 왜?
“실시간 로그 + 키워드 검색 + 대시보드” → Athena/Redshift가 오답인 이유와 올바른 선택은?

# 4.1 VPC 및 네트워크 기초

📌 핵심 요약

VPC: AWS 계정 전용 가상 네트워크. 리전 단위로 생성.
서브넷(Subnet): VPC 내부의 IP 주소 범위. 가용 영역(AZ) 단위로 생성.
설계 원칙:
- 보안 계층화: 웹 서버는 퍼블릭, DB/App 서버는 프라이빗 서브넷 배치.
- 인터넷 통신 제어: 프라이빗 자원의 외부 통신은 NAT Gateway 활용.
- 최소 권한: 보안 그룹 간의 참조를 통해 통신 범위 제한.

🌐 1. 퍼블릭 vs 프라이빗 서브넷 (구분 기준)


구분	퍼블릭 서브넷 (Public)	프라이빗 서브넷 (Private)	❌ 오답이 되는 조건
라우팅 테이블	인터넷 게이트웨이(IGW)로 가는 경로 있음	IGW 경로 없음 (폐쇄적)	-
인터넷 연결	양방향 통신 (Public IP 필요)	NAT Gateway를 통해서만 외부로 나감	NAT Gateway를 프라이빗 서브넷에 배치 → 오류 발생
주요 자원	ALB, Bastion Host, NAT Gateway	DB 인스턴스, 애플리케이션 서버	DB를 퍼블릭 서브넷에 배치 → 보안 위반

NAT Gateway 위치 혼동 (빈출 오답)

NAT Gateway는 퍼블릭 서브넷에 있어야 합니다.

NAT GW = 퍼블릭 서브넷 배치 + Elastic IP 연결

프라이빗 서브넷 라우팅 테이블 → 0.0.0.0/0 대상을 NAT GW로 지정

IGW ≠ NAT GW: IGW는 VPC에 1개, 양방향 / NAT GW는 단방향(밖으로만)

🛠️ 2. 네트워크 구성 요소 (Connectivity)

Internet Gateway (IGW): VPC와 인터넷 간의 게이트웨이. (양방향)
NAT Gateway: 프라이빗 서브넷의 인스턴스가 인터넷에 접속하게 해줌. (단방향: 안에서 밖으로만)
- 중요: NAT Gateway 자체는 퍼블릭 서브넷에 위치해야 함 (Q101, Q549, Q251).
Bastion Host (배스천 호스트): 프라이빗 서브넷에 있는 서버에 SSH/RDP 접속을 하기 위해 퍼블릭 서브넷에 두는 “점프 서버” (Q73).
Egress-Only Internet Gateway: IPv6 전용 NAT Gateway 역할. (단방향 밖으로만) (Q470)

🛡️ 3. 보안 설정 (Security Groups vs NACLs)


특징	보안 그룹 (Security Groups)	네트워크 ACL (NACLs)
------	------	------
적용 범위	인스턴스(ENI) 단위	서브넷 단위
상태 유지	Stateful (응답 자동 허용)	Stateless (인/아웃바운드 모두 설정 필요)
규칙	허용(Allow) 규칙만 가능	허용 및 거부(Deny) 규칙 가능
기본 동작	아웃바운드 허용, 인바운드 차단	Default: 모두 허용 / Custom: 모두 차단
규칙 평가	모든 규칙 동시 평가	번호 순서대로 평가 (낮을수록 우선)

시험 팁 (Q254, Q388, Q406)

“DB 접근을 웹 서버로만 제한하고 싶다” → DB 보안 그룹의 소스(Source)에 웹 서버 보안 그룹 ID를 입력하세요. (IP 대신 SG ID 참조가 정답!)

🛠️ 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: 프라이빗 서브넷에서 인터넷 업데이트가 필요할 때 (Q101, Q549)

문제: DB 서버가 보안 패치를 위해 인터넷에서 파일을 받아와야 함.
해결: 퍼블릭 서브넷에 NAT Gateway 생성 → 프라이빗 라우팅 테이블에 0.0.0.0/0의 대상을 NAT GW로 설정.
주의: NAT 인스턴스는 관리가 힘들어 오답일 확률이 높음 (운영 오버헤드 최소화 위반).

✅ 사례 2: 특정 IP 주소의 공격 차단 (Q509, Q669, Q683)

문제: 특정 악성 IP에서 대량의 요청이 들어옴.
해결: Network ACL에서 해당 IP를 거부(Deny) 규칙으로 추가.
이유: 보안 그룹은 거부 규칙을 만들 수 없기 때문. (웹 공격은 WAF가 더 적합하지만, IP 차단은 NACL이 빠름)

✅ 사례 3: 인터넷 거치지 않고 S3/DynamoDB 연결 (Q4, Q91, Q176)

해결: VPC Endpoint (Gateway) 사용.
장점: NAT Gateway 비용을 아끼고, 트래픽이 AWS 내부망만 통과하여 보안 강화.

💡 한 줄 공식 (SAA 득점 키워드)

“프라이빗 서버의 인터넷 접속” = NAT Gateway
“특정 IP 주소 차단” = NACL Deny 규칙
“보안 그룹 간 통신” = 보안 그룹 ID 참조
“IPv6 단방향 인터넷 접속” = Egress-Only IGW
“인터넷 없이 S3 접속” = Gateway VPC Endpoint

🚨 4. 네트워킹 고빈도 혼동 포인트 (4.1 전용)

이것만 틀리지 마세요

IGW vs NAT GW 차이

IGW: VPC ↔ 인터넷 (양방향), VPC에 1개 연결

NAT GW: 프라이빗 → 인터넷 (단방향), 퍼블릭 서브넷에 위치

SG vs NACL 차이

특정 IP 차단 → NACL (SG는 Deny 불가)

인스턴스 단위 제어 → SG / 서브넷 단위 제어 → NACL

SG는 Stateful → 인바운드 허용하면 응답 자동 허용

NACL은 Stateless → 인바운드 + 아웃바운드 둘 다 허용해야 함

라우팅 테이블 핵심

퍼블릭 서브넷: 0.0.0.0/0 → IGW

프라이빗 서브넷: 0.0.0.0/0 → NAT GW

S3/DynamoDB: 특정 prefix → Gateway VPC Endpoint

🔀 5. 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: 3-Tier 아키텍처 (표준 VPC 설계)

[인터넷]
    |
[IGW] ← VPC 연결점
    |
퍼블릭 서브넷
 ├─ [ALB] ← 트래픽 분산
 └─ [NAT GW + EIP] ← 프라이빗 → 인터넷
    |
프라이빗 서브넷 (앱 계층)
 └─ [EC2 ASG] ← 0.0.0.0/0 → NAT GW
    |
프라이빗 서브넷 (DB 계층)
 └─ [RDS Multi-AZ] ← 인터넷 연결 없음

키워드: “3계층 아키텍처” + “DB 보안” + “표준 VPC 설계”

패턴 2: 특정 IP 차단 + 보안 그룹 조합

[인터넷]
    |
[NACL] ← 악성 IP 블랙리스트 (Deny 규칙)
    |
[ALB 보안 그룹] ← 80/443만 허용 (Allow만 가능)
    |
[EC2 보안 그룹] ← ALB 보안 그룹 ID만 허용 (IP 대신 SG ID 참조)
    |
[RDS 보안 그룹] ← EC2 보안 그룹 ID만 허용

키워드: “특정 IP 차단” + “최소 권한” + “보안 계층화”

패턴 3: Multi-AZ NAT Gateway (고가용성)

AZ-A                          AZ-B
[NAT GW A]                    [NAT GW B]
    |                              |
[프라이빗 서브넷 A]            [프라이빗 서브넷 B]
라우팅: 0.0.0.0/0 → NAT GW A  라우팅: 0.0.0.0/0 → NAT GW B

키워드: “NAT Gateway 고가용성” + “AZ 장애 허용” + “각 AZ별 NAT GW 필요”

🔗 연결 문서 (관련 주제)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

사용법: 답을 보지 말고 소리 내어 설명해보세요. 막히는 항목이 취약점입니다.

NAT Gateway는 어느 서브넷에 배치해야 하는가? 라우팅 테이블은 어떻게 설정하는가?
특정 악성 IP를 차단해야 한다 → SG가 오답인 이유와 올바른 방법은?
SG가 Stateful이라는 것이 실제로 의미하는 바는? NACL과 비교해 설명하면?
프라이빗 서브넷의 EC2가 yum update를 하려면 → 어떤 구성이 필요한가?
DB 보안 그룹의 인바운드를 “EC2 SG ID”로 설정하는 것과 “EC2의 IP”로 설정하는 것의 차이는?

# 4.2 하이브리드 연결 (Direct Connect & VPN)

📌 핵심 요약

Site-to-Site VPN: 공용 인터넷을 통한 암호화 연결. 빠르고 저렴하지만 성능이 가변적임.
Direct Connect (DX): 전용선을 통한 프라이빗 연결. 높은 보안과 일관된 성능 제공.
Transit Gateway: 수많은 VPC와 온프레미스 네트워크를 연결하는 중앙 허브(Hub).

🔗 1. 연결 방식 비교 (VPN vs DX)

문제에서 요구하는 “성능”과 “예산” 키워드에 따라 선택하세요.


특징	Site-to-Site VPN	Direct Connect (DX)
------	------	------
전송 경로	공용 인터넷 (IPsec 암호화)	전용선 (프라이빗 네트워크)
설정 시간	수분 이내 (매우 빠름)	수주~수개월 (물리적 구축)
성능/지연	인터넷 상태에 따라 가변적	일관되고 예측 가능한 성능
비용	저렴함 (시간당 요금)	비쌈 (포트 + 데이터 전송)
암호화	IPsec으로 기본 암호화	암호화 없음 (추가 설정 필요)

시험 팁 (Q68, Q647)

“가장 가용성이 높은 하이브리드 설계” → Direct Connect + 백업용 VPN 조합이 정답으로 자주 나옵니다. (DX 장애 시 VPN으로 즉각 우회)

🕸️ 2. 중앙 집중형 허브 (Transit Gateway)

복잡한 네트워크 구조를 단순화할 때 사용합니다. (Q504, Q374)

문제 상황: VPC가 10개, 100개로 늘어나면서 VPC Peering으로 연결하기가 너무 복잡함(Full-mesh 지옥).
해결책: Transit Gateway (TGW) 도입.
특징:
- 모든 VPC와 VPN/DX 연결을 TGW 한 곳에 연결 (Hub-and-Spoke).
- 리전 간 TGW 피어링 지원.
- 공유 서비스 VPC 운영 시 효율적.

🛠️ 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: 데이터 보안 및 일관된 성능 요구 (Q43, Q482, Q84)

문제: 민감한 데이터를 매일 수십 TB씩 옮겨야 함. 인터넷 대역폭 간섭을 피하고 싶음.
해결: AWS Direct Connect.
이유: 전용선을 사용하므로 인터넷을 거치지 않아 보안이 뛰어나고 속도가 일정함.

✅ 사례 2: 수백 개의 VPC를 하나로 통합 관리 (Q504, Q587)

문제: 관리해야 할 VPC가 너무 많고, 서로 통신해야 함.
해결: AWS Transit Gateway.
이유: VPC Peering은 1:1 방식이라 수백 개를 연결하기 불가능하지만, TGW는 중앙 집중식 관리가 가능함.

✅ 사례 3: 가장 저렴한 리전 간 백업 연결 (Q558)

해결: Site-to-Site VPN.
이유: Direct Connect는 비용이 많이 들고 구축이 오래 걸림. 비용 최적화가 목적이라면 VPN이 유리.

💡 한 줄 공식 (SAA 득점 키워드)

“일관된 네트워크 성능 / 지연 시간 최소화” = Direct Connect
“빠른 구축 / 인터넷 기반” = Site-to-Site VPN
“수많은 VPC 연결 단순화” = Transit Gateway
“DX 장애 대비 고가용성” = DX + VPN 백업
“IP 주소 겹침 없이 1:1 연결” = VPC Peering

🚨 3. 네트워킹 고빈도 혼동 포인트 (4.2 전용)

이것만 틀리지 마세요

Direct Connect는 기본 암호화 없음

전용선이라도 암호화가 필요하면 VPN over DX 구성 필요

“보안 + 일관된 성능” → DX + Site-to-Site VPN 조합

VPN vs DX 핵심 키워드

“즉시” / “빠른 구축” / “백업” → VPN

“일관된 성능” / “대용량” / “프라이빗 연결” → DX

Transit Gateway가 필요한 시점

VPC Peering은 1:1만 가능 → n개 VPC는 n(n-1)/2개 peering 필요 → 비현실적

VPC가 3개 이상 + 온프레미스 연결 → Transit Gateway

🔀 4. 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: 엔터프라이즈 하이브리드 연결 (고가용성)

[온프레미스 데이터센터]
    |
[Direct Connect] ← 메인 연결 (일관된 성능)
    |
[Direct Connect Gateway] ← 멀티 리전 지원
    |
[AWS VPC (us-east-1, ap-northeast-2)]
    +
[Site-to-Site VPN] ← DX 장애 시 자동 백업

키워드: “고가용성 하이브리드” + “DX 장애 대비” + “일관된 성능”

패턴 2: 멀티 VPC 중앙 허브 (Transit Gateway)

[온프레미스]
    |
[Direct Connect / VPN]
    |
[Transit Gateway] ← 모든 연결의 중앙 허브
 ├─ VPC A (개발)
 ├─ VPC B (운영)
 ├─ VPC C (보안/공유 서비스)
 └─ VPC D (로깅)

키워드: “수십 개 VPC 연결” + “중앙 집중 관리” + “Hub-and-Spoke”

패턴 3: DX + 암호화

[온프레미스]
    |
[Direct Connect] ← 프라이빗 전용선 (암호화 없음!)
    +
[VPN over Direct Connect] ← IPsec 암호화 추가
    |
[AWS VPC]

키워드: “전용선 + 암호화” + “규정 준수” + “보안 강화”

🔗 연결 문서 (관련 주제)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

사용법: 답을 보지 말고 소리 내어 설명해보세요. 막히는 항목이 취약점입니다.

DX를 쓰면 자동으로 암호화가 되는가? “보안 + 일관된 성능”을 모두 충족하려면?
“즉시 연결 필요” → VPN 정답, DX 오답인 이유는?
VPC가 10개이고 모두 연결해야 한다 → VPC Peering이 오답인 이유와 올바른 선택은?
DX 장애 시에도 서비스가 유지되어야 한다 → 어떤 아키텍처를 구성하는가?
Transit Gateway와 VPC Peering 둘 다 VPC를 연결하는데 차이점은?

# 4.3 VPC 엔드포인트 및 PrivateLink

📌 핵심 요약

VPC Endpoint: 인터넷 게이트웨이(IGW)나 NAT 게이트웨이 없이 VPC 내부에서 AWS 서비스와 프라이빗하게 통신하게 해주는 장치.
설계 원칙:
- 비용 절감: NAT 게이트웨이의 데이터 처리 비용을 아끼기 위해 사용.
- 보안 강화: 트래픽이 공용 인터넷을 절대 타지 않음 (AWS 내부망 이용).

🛠️ 1. 엔드포인트 유형 비교 (가장 중요)

시험 문제에서 S3나 DynamoDB가 나오느냐, 그 외 서비스가 나오느냐에 따라 답이 갈립니다.


유형	Gateway Endpoint	Interface Endpoint
------	------	------
대상 서비스	S3, DynamoDB (단 2개)	그 외 거의 모든 서비스 (SQS, SNS 등)
구현 방식	라우팅 테이블에 경로 추가	ENI 생성 + 프라이빗 IP
비용	무료	시간당 + 데이터 처리 비용
보안 설정	엔드포인트 정책	보안 그룹으로 제어
온프레미스 접근	불가 (VPC 내부만)	가능 (DX/VPN 통해 온프레미스에서도 사용)

시험 팁 (Q4, Q100, Q176, Q471)

“프라이빗 서브넷에서 S3에 접근할 때 비용을 최소화하고 싶다” → Gateway Endpoint가 무조건 정답입니다. (인터페이스 엔드포인트도 S3를 지원하지만 비용이 발생하므로 오답 처리됨)

🔗 2. AWS PrivateLink

다른 VPC에 있는 서비스나 타사(SaaS) 서비스를 내 VPC 내부 서비스처럼 쓰고 싶을 때 사용합니다.

문제 상황: 두 회사의 VPC를 연결해야 하는데, IP 주소가 겹쳐서(Overlapping) VPC Peering이 불가능함.
해결책: PrivateLink를 사용하여 특정 서비스만 노출.
특징:
- 트래픽이 인터넷을 통과하지 않음 (Q135).
- 네트워크 구조를 전체 공개하지 않고 **특정 서비스(단일 엔드포인트)**만 공유 가능.
- 고객 VPC에는 Interface Endpoint가 생성됨.

🛠️ 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: S3/DynamoDB 프라이빗 연결 (Q4, Q91, Q115)

문제: EC2가 인터넷 연결 없이 S3 버킷의 로그를 처리해야 함.
해결: Gateway VPC Endpoint 생성 및 라우팅 테이블 연결.
이유: NAT 게이트웨이를 쓰는 것보다 저렴하고 보안상 안전함.

✅ 사례 2: SQS/SNS 등 메시징 서비스 연결 (Q555)

문제: 프라이빗 서브넷의 앱이 SQS 대기열에 메시지를 보내야 함.
해결: Interface VPC Endpoint 사용.
주의: SQS는 Gateway 방식을 지원하지 않음.

✅ 사례 3: 타사 공급업체 서비스와의 안전한 통신 (Q135, Q468)

문제: 외부 파트너사 서비스에 연결해야 하는데, 보안상 우리 VPC에서만 통신을 시작해야 하고 인터넷을 타면 안 됨.
해결: 공급업체에 VPC Endpoint Service(PrivateLink) 생성을 요청하고, 우리 쪽에서 인터페이스 엔드포인트로 연결.

💡 한 줄 공식 (SAA 득점 키워드)

“인터넷을 통하지 않고 / 프라이빗하게” = VPC Endpoint
“S3 또는 DynamoDB” = Gateway Endpoint
“SQS, SNS, Kinesis, 리전별 서비스” = Interface Endpoint
“IP 충돌 / 특정 서비스만 노출” = PrivateLink
“S3 접근 시 비용 최적화” = Gateway Endpoint (Interface는 유료)

🚨 3. 네트워킹 고빈도 혼동 포인트 (4.3 전용)

이것만 틀리지 마세요

Gateway vs Interface 핵심 암기

S3, DynamoDB → Gateway (무료, VPC 내부만)

나머지 전부 → Interface (유료, ENI 기반)

온프레미스에서 프라이빗 S3 접근

Gateway Endpoint는 온프레미스 불가 → Interface Endpoint 필요

DX/VPN 환경에서 S3에 프라이빗 접근 → Interface Endpoint

PrivateLink vs VPC Peering 차이

VPC Peering: 양쪽 VPC 전체 연결, IP 충돌 불가

PrivateLink: 특정 서비스만 노출, IP 충돌 상관없음

🔀 4. 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: 비용 최적화 프라이빗 S3 접근

[프라이빗 서브넷 EC2]
    |
[Gateway VPC Endpoint] ← 무료, 라우팅 테이블만 수정
    |
[S3 버킷] ← 인터넷/NAT GW 비용 없음

vs.

[프라이빗 서브넷 EC2]
    |
[NAT Gateway] ← 유료! GB당 비용 발생
    |
[인터넷] → [S3]  ← 이 방식은 비용 낭비

키워드: “비용 최소화 + S3 접근” → Gateway Endpoint (NAT GW 오답)

패턴 2: 온프레미스 → 프라이빗 S3 (특수 케이스)

[온프레미스 서버]
    |
[Direct Connect / VPN]
    |
[Interface VPC Endpoint (S3)] ← 온프레미스에서 접근 가능
    |
[S3 버킷] ← 인터넷 미경유

키워드: “온프레미스” + “S3 프라이빗 접근” → Interface (Gateway 오답!)

패턴 3: IP 충돌 환경에서 서비스 공유 (PrivateLink)

[공급업체 VPC] (10.0.0.0/16)
 └─ [NLB] → [PrivateLink Endpoint Service]
    |
[고객 VPC] (10.0.0.0/16) ← IP 대역 동일해도 OK
 └─ [Interface Endpoint] ← 특정 서비스만 연결

키워드: “IP 충돌” + “특정 서비스만 공유” + “VPC Peering 불가”

🔗 연결 문서 (관련 주제)

2.1 Amazon S3 스토리지 (VPC Endpoint 정책과 결합)
4.1 VPC 및 네트워크 기초 (NAT Gateway와 비교)
5.1 IAM 및 Organizations (Endpoint Policy 권한 제어)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

사용법: 답을 보지 말고 소리 내어 설명해보세요. 막히는 항목이 취약점입니다.

“비용 최소화 + 프라이빗 서브넷에서 S3 접근” → Interface Endpoint가 오답인 이유는?
Interface Endpoint 생성 시 추가로 해야 하는 보안 설정은? Gateway와의 차이는?
온프레미스 서버에서 S3에 프라이빗하게 접근해야 한다 → 어느 Endpoint 유형, 이유는?
IP 대역이 겹치는 두 VPC를 연결해야 한다 → VPC Peering이 왜 안 되는가? 대안은?
Gateway Endpoint를 만들면 어디를 수정해야 하는가? Interface Endpoint는?

# 4.4 글로벌 서비스 (CloudFront, Route 53, Global Accelerator)

📌 핵심 요약

CloudFront: 전 세계 엣지 로케이션을 통한 콘텐츠 캐싱(CDN). (정적/동적 가속)
Route 53: 다양한 라우팅 정책을 제공하는 가용성 높은 DNS 서비스.
Global Accelerator: AWS 글로벌 네트워크를 사용해 TCP/UDP 트래픽 경로 최적화. (캐싱 없음)

🚀 1. Amazon CloudFront (콘텐츠 전송)

S3나 ALB 앞에 두어 사용자 대기 시간(Latency)을 줄입니다.


기능	상세 내용	시험 포인트 (키워드)
------	------	------
OAC/OAI	S3 접근을 CloudFront로만 제한	”S3 직접 접근 차단”, “보안 강화” (Q131, Q165)
정적/동적 가속	이미지(정적) + API(동적) 모두 가속	전 세계 저지연 (Q166, Q173)
Lambda@Edge	엣지에서 코드 실행	User-Agent 리디렉션, 헤더 수정 (Q291, Q358)
보안 통합	WAF 연동	L7 공격 방어, 지역 차단

🗺️ 2. Amazon Route 53 (DNS & 라우팅)

사용자의 요청을 어디로 보낼지 결정하는 전략입니다. (Q242, Q582, Q545)


라우팅 정책	특징	시험 상황 (Use Case)
------	------	------
지연 시간 (Latency)	가장 빠른 응답 리전으로 이동	전 세계 사용자에게 최상의 성능
지리적 위치 (Geolocation)	사용자의 국가/대륙 기준 분기	콘텐츠 라이선스 제한, 언어별 페이지
장애 조치 (Failover)	Active → Passive 자동 전환	재해 복구(DR), 정적 오류 페이지 (Q545)
다중값 (Multivalue)	여러 정상 IP 무작위 반환	단순 로드 밸런싱 효과 (Q242)
가중치 (Weighted)	비율(8:2)로 트래픽 분산	카나리아 배포, 새 버전 테스트

Latency vs Geolocation 혼동 (빈출 오답)

“전 세계에서 가장 빠르게” → Latency (지리적 위치와 무관, 실제 응답속도 기준)

“특정 국가 사용자는 특정 리전으로” → Geolocation (법적 규제, 언어 분기)

한국 사용자가 도쿄보다 버지니아가 빠를 수 있다 → Latency 정책은 실제 속도 측정 기반

⚡ 3. Global Accelerator vs CloudFront

둘 다 글로벌 서비스이지만 용도가 완전히 다릅니다. 이 구분이 시험의 빈출 오답 포인트입니다.


비교 항목	CloudFront	Global Accelerator
------	------	------
핵심 기술	캐싱 (Caching)	애니캐스트 (Anycast IP)
주요 대상	HTTP/HTTPS (웹 콘텐츠)	TCP/UDP (게임, VoIP, 비HTTP)
IP 주소	도메인 기반 (IP 가변적)	2개의 고정 공인 IP 제공
캐싱	있음 (정적/동적 콘텐츠)	없음 (경로 최적화만)
비용	캐싱으로 오리진 비용 절감	가속 비용 추가 발생

시험 팁 (Q352, Q647)

“UDP 프로토콜” + “고정 IP 필요” + “리전 간 빠른 장애 조치” → Global Accelerator가 정답.

🛠️ 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: 하이브리드 DNS 환경 구축 (Q622, Q689)

문제: VPC 내부에서 온프레미스 도메인을 조회하거나, 반대의 경우가 필요함.
해결: Route 53 Resolver (Inbound / Outbound Endpoints).
이유: 단순 Route 53은 VPC 외부의 프라이빗 도메인을 해석할 수 없기 때문.

✅ 사례 2: S3 보안 및 캐싱 (Q131, Q180)

문제: S3 정적 웹사이트를 운영하는데, 사용자가 S3 URL로 직접 들어오는 것을 막고 싶음.
해결: CloudFront 배포 생성 시 OAC(Origin Access Control) 설정 + S3 버킷 정책에서 CloudFront만 허용.

✅ 사례 3: 글로벌 게임 서버 지연 시간 단축 (Q352, Q642)

문제: 초당 수백만 건의 UDP 요청을 전 세계 리전으로 저지연 전송해야 함.
해결: Global Accelerator + NLB(Network Load Balancer).
이유: ALB/CloudFront는 UDP를 지원하지 않거나 가속 효율이 떨어짐.

💡 한 줄 공식 (SAA 득점 키워드)

“정적 콘텐츠 가속 / 비용 절감” = CloudFront
“UDP 가속 / 고정 IP” = Global Accelerator
“리전 장애 시 S3 오류 페이지 이동” = Route 53 Failover
“특정 국가 접근 제한” = Route 53 Geolocation 또는 CloudFront Geo Restriction
“서버리스 DNS 확인기” = Route 53 Resolver

🚨 4. 네트워킹 고빈도 혼동 포인트 (4.4 전용)

이것만 틀리지 마세요

CloudFront vs Global Accelerator 핵심 차이

CloudFront: 캐싱 O, HTTP/HTTPS, 비용 절감

Global Accelerator: 캐싱 X, TCP/UDP, 고정 IP 2개

“UDP” / “고정 IP” / “비HTTP” → Global Accelerator

“콘텐츠 캐싱” / “비용 절감” → CloudFront

Route 53 라우팅 정책 혼동

Latency ≠ Geolocation (가장 많이 혼동)

Latency: 실제 응답속도 기준 (국적 무관)

Geolocation: 사용자 국가/대륙 기준 (속도 무관)

Failover: Active 1개만, DR 목적

Weighted: 비율 분산, 카나리아 배포

OAC vs 퍼블릭 S3

S3를 직접 공개하면 CloudFront 우회 가능 → OAC로 CloudFront만 허용 필수

🔀 5. 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: 글로벌 정적 웹사이트 (최적 비용 + 보안)

[Route 53] ← Latency 기반 라우팅
    |
[CloudFront] ← 엣지 캐싱 + WAF
    |
[S3 + OAC] ← S3 직접 접근 차단
    ※ CloudFront만 S3 접근 가능

키워드: “전 세계 빠른 정적 사이트” + “S3 보안” + “비용 최적화”

패턴 2: 글로벌 게임/VoIP (UDP + 고정 IP)

[전 세계 클라이언트]
    |
[Global Accelerator] ← 애니캐스트, 고정 IP 2개
    |
[NLB] ← TCP/UDP 처리
    |
[EC2 게임 서버, Multi-Region]
    ├─ us-east-1
    └─ ap-northeast-2

키워드: “UDP” + “고정 IP” + “리전 간 빠른 전환”

패턴 3: 다중 리전 DR + Route 53 Failover

[Route 53 Failover 정책]
 ├─ Primary: ALB (us-east-1) ← 헬스체크
 └─ Secondary: S3 정적 오류 페이지 ← Primary 다운 시 자동 전환

키워드: “재해 복구” + “가동 중지 최소화” + “정적 오류 페이지”

🔗 연결 문서 (관련 주제)

2.1 Amazon S3 스토리지 (CloudFront의 오리진)
4.1 VPC 및 네트워크 기초 (VPC와 글로벌 네트워크 연결)
7.2 재해 복구(DR) 전략 (Failover 정책 활용)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

사용법: 답을 보지 말고 소리 내어 설명해보세요. 막히는 항목이 취약점입니다.

“UDP + 고정 IP + 리전 간 빠른 전환” → CloudFront가 오답인 이유와 올바른 선택은?
“전 세계 사용자에게 최상의 성능” → Geolocation이 오답인 이유와 올바른 선택은?
“특정 국가 사용자는 특정 리전으로” → Latency가 오답인 이유는?
S3 정적 사이트를 CloudFront 뒤에 배치했는데 직접 S3 URL 접근이 가능하다 → 어떻게 막는가?
CloudFront는 동적 콘텐츠(API)도 가속할 수 있는가? 어떻게 가능한가?

# 5.1 권한 및 계정 관리 (IAM & AWS Organizations)

📌 핵심 요약

IAM: AWS 리소스에 대한 접근 권한을 관리하는 서비스. (최소 권한의 원칙)
AWS Organizations: 여러 AWS 계정을 중앙에서 통합 관리. (계정 그룹화 및 통합 빌링)
SCP (Service Control Policy): 조직의 하위 계정이 사용할 수 있는 최대 권한을 제한하는 ‘가드레일’.

🏢 1. AWS Organizations & SCP

다중 계정 환경에서 보안 정책을 강제할 때 정답의 핵심입니다.

기능	상세 내용	시험 포인트 (키워드)	❌ 오답이 되는 조건
OU (조직 단위)	부서/환경별 계정 그룹화	계정 그룹화 관리 (Q560)	-
SCP	해당 계정의 최대 한도 설정	”가드레일”, “전사 금지” (Q168, Q433)	개별 사용자 권한 부여 목적 (SCP는 제한, IAM Policy가 실제 허용)
통합 빌링	하위 계정 비용 일괄 결제	비용 절감 및 관리 편의성	-
공유 예약	RI/Savings Plans 할인 조직 내 공유	비용 최적화 (Q467, Q543)	-

SCP의 특징 (중요)

SCP는 권한을 허용하는 것이 아니라 제한하는 것입니다. (Allow 정책이 있어도 SCP에서 Deny하면 실행 불가)

**관리 계정(Management Account)**의 루트 사용자에게는 적용되지 않습니다.

🔐 2. IAM (Identity and Access Management)

리소스 수준의 세밀한 권한 관리 전략입니다.

최소 권한의 원칙 (Least Privilege):
- 사용자에게 꼭 필요한 권한만 부여. (Q476)
- IAM Role을 사용하여 서비스(EC2, Lambda)에 권한 부여. (Q17, Q289)
교차 계정 액세스 (Cross-Account Access):
- 해결책: 신뢰 계정에서 IAM Role 생성 → 대상 계정에서 AssumeRole 허용. (Q418, Q521)
- 이유: Access Key를 공유하는 것은 절대 금지(보안 위반).
IAM Identity Center (기존 AWS SSO):
- 키워드: “중앙 집중식 로그인”, “Active Directory 연동”, “Single Sign-On”.
- 한 번의 로그인으로 수백 개의 계정에 각기 다른 역할로 접근 가능. (Q28, Q484)

🛠️ 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: 우리 조직(Organization) 멤버만 S3 접근 허용 (Q3)

문제: 프로젝트 보고서가 담긴 S3 버킷을 다른 회사 사람은 못 보게 막고 싶음.
해결: S3 버킷 정책에 aws:PrincipalOrgID 조건 키를 추가.
이유: 개별 계정 ID를 일일이 등록하는 것은 운영 오버헤드가 크기 때문.

✅ 사례 2: 특정 리전에서만 자원 생성 가능하게 강제 (Q151, Q419)

문제: 개발자들이 허용되지 않은 해외 리전에 인스턴스를 만드는 것을 막아야 함.
해결: SCP를 생성하여 Condition: {“StringNotEquals”: {“aws:RequestedRegion”: [“ap-northeast-2”]}} 와 같이 설정 후 Root OU에 연결.

✅ 사례 3: 결제 정보 접근 차단 (Q488)

문제: 하위 계정의 루트 사용자를 포함하여 아무도 결제 정보를 볼 수 없게 해야 함.
해결: SCP를 사용하여 빌링(Billing) 서비스 접근을 명시적으로 차단(Deny).

💡 한 줄 공식 (SAA 득점 키워드)

“다중 계정 / 중앙 집중 관리” = AWS Organizations
“특정 서비스 전사적 금지” = SCP
“Access Key 노출 없이 서비스 권한 부여” = IAM Role (Instance Profile)
“외부 사용자(AD)의 AWS 접근” = SAML 2.0 연동 또는 IAM Identity Center
“조직 내 모든 리소스에 태그 강제” = Tag Policies (Organizations)

🔀 4. 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: 다중 계정 보안 거버넌스

[AWS Organizations]
 └─ Root
     ├─ OU: 운영 계정
     │   └─ SCP: "us-east-1, ap-northeast-2만 허용"
     ├─ OU: 개발 계정
     │   └─ SCP: "비용 임계값 초과 서비스 금지"
     └─ 관리 계정 (SCP 미적용)
         └─ CloudTrail 조직 추적 ← 전 계정 로그 중앙화

키워드: “전사 정책 강제” + “리전 제한” + “중앙 로그 수집”

패턴 2: 교차 계정 안전한 리소스 공유

[계정 A: 운영] ──AssumeRole──→ [계정 B: S3 데이터 저장소]
    |                                    |
[IAM Role (계정 A에서 생성)]       [버킷 정책: PrincipalOrgID 조건]
    ↑                                    |
Access Key 없이 안전한 접근 가능     조직 외부 계정 자동 차단

키워드: “교차 계정 접근” + “Access Key 없음” + “조직 내부만 허용”

패턴 3: 중앙 집중식 SSO (Identity Center)

[온프레미스 Active Directory]
    |
[IAM Identity Center] ← SAML 2.0 연동
    |
[단일 로그인 포털]
 ├─ 계정 A: DevOps 역할 ← 개발팀
 ├─ 계정 B: ReadOnly 역할 ← 감사팀
 └─ 계정 C: Admin 역할 ← 보안팀

키워드: “Single Sign-On” + “AD 연동” + “중앙 집중식 로그인”

🔗 연결 문서 (관련 주제)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

사용법: 답을 보지 말고 소리 내어 설명해보세요. 막히는 항목이 취약점입니다.

SCP가 Deny해도 관리 계정(Management Account)의 루트는 무시할 수 있는가? 하위 계정 루트는?
SCP로 S3 허용 → IAM Policy로 S3 Deny → 실제 접근 가능한가? 우선순위 설명은?
EC2 앱이 S3에 접근할 때 Access Key 사용이 오답인 이유와 올바른 방법은?
“특정 리전에서만 자원 생성 가능” → IAM Policy vs SCP 중 어떤 걸 써야 하는가, 이유는?
조직 내 계정만 S3 버킷에 접근하도록 하려면 → 버킷 정책에 어떤 조건 키를 쓰는가?

# 5.2 데이터 보호 (KMS, Secrets Manager, ACM)

📌 핵심 요약

AWS KMS: 데이터 암호화 키(CMK)를 생성하고 관리. (S3, EBS, RDS 연동)
AWS Secrets Manager: DB 비밀번호, API 키 저장 및 자동 교체(Rotation) 기능 제공.
SSM Parameter Store: 구성 데이터 및 암호 저장 (교체 기능 없음, 비용 저렴).
AWS ACM: SSL/TLS 인증서 발급 및 자동 갱신 관리.

🔑 1. AWS KMS (Key Management Service)

“데이터 암호화”와 “키 관리” 요구 사항이 나올 때 정답의 중심입니다.

구분	특징	시험 포인트 (키워드)	❌ 오답이 되는 조건
AWS 관리형 키	AWS 서비스 자동 생성	무료, 자동 교체, 사용자 제어 불가	교체 주기 직접 제어 필요 시
고객 관리형 키(CMK)	사용자가 생성 및 제어	교체 주기 설정, 권한 제어 (Q106, Q116)	단순 암호화로 충분한 경우 (비용 발생)
다중 리전 키	여러 리전에서 동일 키 사용	리전 간 DR, 데이터 이동 (Q36, Q37)	단일 리전에만 국한된 경우
SSE-S3	S3 자체 관리 키	최소 설정, 무료	키 접근 감사 로그 필요 시 (SSE-KMS 필요)
SSE-KMS	KMS CMK 사용	키 접근 추적, CloudTrail 통합	비용 최소화가 최우선일 때
SSE-C	고객이 직접 키 제공	완전한 키 통제 필요 시	키 관리 오버헤드 없애고 싶을 때

KMS 키 교체 (Rotation)

자동 교체: 매년 새 암호화 자료를 생성. 기존 데이터는 이전 키로 계속 복호화 가능.

수동 교체: 사용자가 직접 새 키를 만들고 애플리케이션 코드를 수정해야 함 (운영 오버헤드 높음).

🔐 2. 자격 증명 관리 (Secrets Manager vs Parameter Store)

“비밀번호를 어디에 저장할 것인가?”를 묻는 단골 문제입니다.

기능	AWS Secrets Manager	SSM Parameter Store	❌ 오답이 되는 조건
주요 특징	비밀번호 자동 교체(Rotation)	계층적 구성 데이터 관리	”자동 교체” 요구 → Parameter Store 오답
DB 연동	RDS, Redshift 강력 통합	코드/설정 데이터 분리	-
비용	유료 (보안 비밀당 요금)	무료 (표준 파라미터)	“비용 최소화 + 단순 설정” → Secrets Manager 오답
선택 기준	”보안 암호 주기적 교체” (Q11, Q61, Q86)	“단순 설정 데이터 저장” (Q12, Q179)	-

Secrets Manager vs Parameter Store 혼동

“자동 교체(Rotation)” 키워드 → 무조건 Secrets Manager

Parameter Store로 자동 교체하려면 Lambda를 직접 만들어야 함 → “운영 오버헤드 최소화” 위반

단순 환경 변수, API 엔드포인트 저장 → Parameter Store (비용 절감)

🌐 3. 인증서 관리 (AWS Certificate Manager - ACM)

HTTPS 통신을 위한 인증서 설계 전략입니다.

자동 갱신: ACM에서 발급한 공인 인증서는 자동으로 갱신됨 (운영 오버헤드 최소화). (Q577)
CloudFront와 ACM: CloudFront에 인증서를 적용하려면 반드시 us-east-1(버지니아 북부) 리전의 ACM에서 인증서를 발급받거나 가져와야 함. (Q62, Q722)
사설 CA: 기업 내부 네트워크용 인증서가 필요할 때 사용.

🛠️ 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: DB 자격 증명의 보안 강화 및 교체 (Q11, Q61, Q86)

문제: 애플리케이션 코드에 DB 비번이 하드코딩되어 있음. 정기적으로 비번을 바꿔야 함.
해결: AWS Secrets Manager에 저장하고 자동 교체(Rotation) 활성화.
이유: Parameter Store는 자동 교체 기능이 없어 Lambda를 직접 짜야 하므로 오버헤드가 큼.

✅ 사례 2: 암호화된 S3 객체의 리전 간 복제 (Q36, Q438)

문제: A 리전의 KMS로 암호화된 파일을 B 리전으로 복제하고 싶음.
해결: **KMS 다중 리전 키(Multi-region Key)**를 사용하거나, 대상 리전의 키로 재암호화 권한을 부여.
팁: KMS 키는 리전별 서비스이므로, 원칙적으로 다른 리전에서 복호화가 안 됨을 기억할 것.

✅ 사례 3: 규정에 따른 “삭제 불가” 스토리지 (Q85, Q154, Q189)

해결: S3 Object Lock (규정 준수 모드).
오답: KMS 암호화는 ‘읽기’를 막는 것이지 ‘삭제’를 막는 기능이 아님.

💡 한 줄 공식 (SAA 득점 키워드)

“보안 암호 자동 교체” = Secrets Manager
“SSL/TLS 자동 갱신” = ACM
“키 관리 운영 오버헤드 최소화” = AWS KMS
“코드와 설정의 분리” = Parameter Store
“CloudFront용 HTTPS” = ACM (in us-east-1)

🔀 4. 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: DB 자격 증명 보안 강화

[애플리케이션 (EC2/Lambda)]
    |
[Secrets Manager] ← DB 비밀번호 저장 + 자동 교체
    |  (코드에 하드코딩 없음)
[RDS] ← 비밀번호 자동 변경 (Lambda Rotation)
    |
[CloudTrail] ← "누가 비밀번호를 조회했나" 감사

키워드: “DB 비밀번호 자동 교체” + “하드코딩 제거” + “감사 추적”

패턴 2: 암호화된 S3 데이터 리전 간 복제

[S3 리전 A (SSE-KMS, CMK A)]
    |
[S3 CRR (Cross-Region Replication)]
    |
[S3 리전 B]
    ↑
[KMS Multi-Region Key] ← A와 B에서 같은 키 사용
    또는
[리전 B의 CMK B로 재암호화] ← 다른 키 사용 가능

키워드: “암호화된 S3 복제” + “리전 간 DR” + “키 권한 설정”

패턴 3: HTTPS 인프라 자동화

[ACM (us-east-1)] ← CloudFront용 인증서 (반드시 us-east-1)
    |
[CloudFront] ← HTTPS 적용
    |
[ACM (각 리전)] ← ALB용 인증서
    |
[ALB] ← HTTPS 리스너
    |
[EC2]

키워드: “자동 갱신 인증서” + “CloudFront는 반드시 us-east-1 ACM”

🔗 연결 문서 (관련 주제)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

사용법: 답을 보지 말고 소리 내어 설명해보세요. 막히는 항목이 취약점입니다.

“DB 비밀번호를 주기적으로 교체해야 한다” → Parameter Store가 오답인 이유는?
SSE-S3 vs SSE-KMS vs SSE-C의 차이를 키 관리 주체 기준으로 설명하면?
기존 암호화되지 않은 RDS를 KMS로 암호화하는 절차는 왜 복잡한가?
CloudFront에 적용할 ACM 인증서는 반드시 어느 리전에서 발급해야 하는가? 이유는?
암호화된 S3 파일을 다른 리전으로 복제할 때 주의해야 할 KMS 관련 사항은?

# 5.3 위협 탐지 및 보안 감사

📌 핵심 요약

CloudTrail: API 호출 기록 (누가, 언제, 어디서 무엇을 했나).
AWS Config: 리소스 설정 변경 이력 및 규정 준수 여부 확인.
GuardDuty: 지능형 위협 탐지 (악성 IP, 비정상적 활동).
Amazon Inspector: 소프트웨어 취약점 스캔 (EC2, 컨테이너, Lambda).
Amazon Macie: S3 내 민감 데이터(PII) 식별 및 보호.

🔍 1. 서비스별 핵심 용도 비교 (SAA 빈출)


서비스	분석 대상	주요 키워드 및 정답 힌트
------	------	------
CloudTrail	API 호출	”감사(Audit)”, “사용자 추적”, “삭제한 사람 찾기” (Q395)
AWS Config	리소스 구성	”설정 변경 추적”, “규정 준수 확인”, “가드레일” (Q26, Q31)
GuardDuty	로그 (VPC, DNS, S3)	“악의적 활동”, “암호화폐 채굴”, “침입 탐지” (Q15, Q616)
Inspector	EC2, ECR, Lambda	”취약점 스캔”, “CVE 확인”, “네트워크 노출” (Q315, Q329)
Macie	S3 객체 내용	”개인 식별 정보(PII)”, “민감 데이터” (Q46, Q533)

가장 많이 혼동하는 조합

“S3 파일에 개인정보(주민번호, 카드번호) 있는지 탐지” → Macie (GuardDuty/Inspector 오답)

“누가 S3 버킷을 퍼블릭으로 바꿨나” → CloudTrail (API 기록) + Config (설정 변경 이력)

“EC2에 악성 프로세스가 돌고 있나” → GuardDuty (Inspector는 취약점 스캔, 실행 중 감지 아님)

🛠️ 2. 상세 설계 포인트

✅ 감사 및 규정 준수 (CloudTrail vs Config)

CloudTrail: “누가 인스턴스를 종료했는가?” 같은 행위를 기록합니다. (Q395)
- 팁: 모든 리전의 로그를 한 번에 기록하려면 ‘조직 추적’을 활성화하세요.
AWS Config: “보안 그룹이 언제 0.0.0.0/0으로 변경되었는가?” 같은 상태를 기록합니다. (Q318)
- 팁: 특정 태그가 없는 리소스를 자동으로 찾아낼 때 사용합니다. (Q512)

✅ 보안 취약점 점검 (Inspector vs GuardDuty)

Amazon Inspector: 인스턴스 내부의 OS 패치 미비나 취약한 소프트웨어 버전을 찾습니다. (Q329)
Amazon GuardDuty: 인스턴스 외부와의 통신 패턴을 분석하여 해킹 징후를 찾습니다. (Q616)

🛠️ 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: S3 내 개인정보(PII) 유출 방지 (Q46, Q533)

문제: 사용자가 실수로 주민번호나 카드번호가 담긴 파일을 S3에 올림. 이를 자동 감지하고 싶음.
해결: Amazon Macie.
오답: GuardDuty나 Inspector는 파일 ‘내용’을 들여다보고 개인정보를 찾는 기능이 없습니다.

✅ 사례 2: 리소스 구성 변경 알림 (Q26, Q34)

문제: S3 버킷의 설정이 무단으로 변경되는지 실시간 모니터링하고 싶음.
해결: AWS Config (적절한 규칙 설정).
이유: 구성(Configuration)의 변화를 추적하는 전용 서비스이기 때문입니다.

✅ 사례 3: 악성 활동의 중앙 집중식 보고 (Q616)

문제: AWS 계정 전반에서 발생하는 의심스러운 활동을 한 곳에서 보고 싶음.
해결: Amazon GuardDuty + AWS Security Hub.

💡 한 줄 공식 (SAA 득점 키워드)

“누가 삭제했나?” = CloudTrail
“설정이 변경되었나?” = AWS Config
“개인정보(PII) 찾기” = Amazon Macie
“소프트웨어 취약점 / CVE” = Amazon Inspector
“비정상적 로그인 / 해킹 징후” = Amazon GuardDuty

🔀 3. 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: 보안 이벤트 탐지 → 자동 대응

[GuardDuty] ← 악성 IP 탐지, 비정상 API 호출 감지
    |
[EventBridge] ← 위협 심각도 기준 라우팅
    |
 ├─ [SNS → 보안팀 이메일] ← 즉각 알림
 └─ [Lambda] ← 해당 EC2 격리 (SG 변경)
         |
    [AWS Security Hub] ← 전체 보안 상태 대시보드

키워드: “자동 위협 대응” + “보안 자동화” + “중앙 대시보드”

패턴 2: 규정 준수 감사 파이프라인

[AWS Config] ← 리소스 구성 변경 실시간 감지
    |
[Config Rules] ← "SG에 0.0.0.0/0 허용 시 Non-Compliant"
    |
[EventBridge] ← 위반 발생 시 트리거
    |
[Lambda] ← 자동 수정 (SG 규칙 제거)
    +
[CloudTrail] ← "누가 변경했나" 행위자 추적
    +
[Amazon Macie] ← S3 내 PII 자동 감지 및 경고

키워드: “규정 준수 자동화” + “위반 자동 수정” + “감사 추적”

패턴 3: S3 민감 데이터 보호

[S3 버킷] ← 사용자가 파일 업로드
    |
[Amazon Macie] ← PII(개인정보) 자동 스캔
    |
[EventBridge] ← PII 탐지 시 이벤트 발생
    |
[SNS] ← 보안팀 알림
    +
[Lambda] ← 해당 객체에 태그 추가 또는 이동

키워드: “PII 자동 탐지” + “S3 데이터 보호” + “운영 오버헤드 없음”

🔗 연결 문서 (관련 주제)

5.1 IAM 및 Organizations (조직 단위 보안 강화)
2.1 Amazon S3 스토리지 (Macie의 주 점검 대상)
5.4 모니터링 및 로깅 (CloudWatch 연동)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

사용법: 답을 보지 말고 소리 내어 설명해보세요. 막히는 항목이 취약점입니다.

“S3 파일에 주민번호가 있는지 확인” → GuardDuty/Inspector가 오답인 이유와 올바른 서비스는?
“누가 S3 버킷을 퍼블릭으로 변경했나” → CloudTrail vs Config 각각 뭘 알 수 있는가?
“EC2 OS의 패치 미적용 취약점 스캔” → GuardDuty가 오답인 이유는?
GuardDuty가 위협을 탐지했을 때 자동으로 EC2를 격리하려면 → 어떤 서비스 조합이 필요한가?
CloudTrail과 AWS Config 둘 다 설정 변경을 기록하는데 차이점은?

# 5.4 모니터링 및 로깅 (CloudWatch & EventBridge)

📌 핵심 요약

CloudWatch: AWS 자원의 지표(Metrics), 로그(Logs), 알람(Alarms)을 수집하고 시각화.
EventBridge: 시스템 상태 변화(이벤트)를 감지하여 다른 서비스(Lambda 등)를 실행하는 이벤트 버스.
설계 원칙:
- 자동화: 사람이 개입하지 않고 알람이나 이벤트에 따라 시스템이 스스로 복구되도록 설계.
- 가시성: 인스턴스 내부(Memory/Disk)까지 모니터링하려면 전용 Agent 설치 필수.

📊 1. Amazon CloudWatch (가시성 확보)

✅ 지표 및 알람 (Metrics & Alarms)

기본 지표: CPU, 네트워크, 디스크 I/O (하이퍼바이저가 보이는 것).
사용자 지정 지표(CloudWatch Agent):
- 키워드: “메모리(Memory) 사용율”, “디스크 공간(Disk Space)”, “프로세스 수준 모니터링” (Q219, Q241).
- 중요: 기본 CloudWatch는 RAM 사용량을 알 수 없습니다. 반드시 Agent를 설치해야 합니다.

✅ CloudWatch Logs

용도: 애플리케이션 로그, VPC Flow Logs, Lambda 로그 수집.
분석: Logs Insights를 사용하여 쿼리로 로그 분석. (Q117, Q130)
보관: 비용 절감을 위해 오래된 로그는 S3/Glacier로 내보내기(Export).

⚡ 2. Amazon EventBridge (자동화의 핵심)

“특정 상태가 되면 자동으로 ~를 해라”는 요구 사항의 1순위 정답입니다.

이벤트 기반 실행: “EC2 상태가 변경되면 Lambda 실행”, “인증서 만료 30일 전 알림 전송” (Q206, Q569, Q82).
예약된 작업 (Scheduled Tasks):
- 키워드: “매일 아침 9시”, “10분마다 실행” (Q397, Q517).
- 서버리스 Cron 작업(Lambda와 조합)에 사용.
SaaS 통합: Zendesk, Shopify 등 타사 서비스 이벤트를 수신하여 AWS에서 처리.

🛠️ 3. 네트워크 및 스토리지 모니터링

VPC Flow Logs: VPC 내의 IP 트래픽 정보를 캡처. 네트워크 연결성 문제 해결(Security Group/NACL 문제 확인). (Q232, Q250)
S3 Storage Lens: 조직 전체의 S3 사용량, 비용 최적화, 불완전한 멀티파트 업로드 탐지. (Q309, Q628)

🛠️ 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: 애플리케이션 지연 시 메모리 확인 (Q219, Q241)

문제: 사용자가 지연을 보고하는데 기본 CPU 지표는 정상임.
해결: CloudWatch Agent를 배포하여 사용자 지정 메모리 지표 수집.
이유: 메모리 부족(OOM)은 기본 지표로 확인할 수 없기 때문.

✅ 사례 2: 비정상 인스턴스 자동 교체 (Q264, Q297)

문제: 특정 인스턴스에서 시간 초과가 발생하는데 수동 대응이 힘듦.
해결: ELB 상태 확인 결과에 따라 Auto Scaling이 인스턴스를 교체하도록 설정.

✅ 사례 3: 로그 데이터를 거의 실시간 분석 (Q117, Q130)

문제: 모든 로그를 OpenSearch나 Athena로 즉시 보내야 함.
해결: **CloudWatch Logs 구독 필터(Subscription Filters)**를 생성하여 Kinesis 또는 Lambda로 전달.

💡 한 줄 공식 (SAA 득점 키워드)

“메모리 / 디스크 사용량” = CloudWatch Agent
“상태 변화에 따른 자동 대응” = EventBridge
“주기적인 작업 실행” = EventBridge Schedule
“IP 트래픽 분석 / 접속 거부 확인” = VPC Flow Logs
“조직 내 S3 버킷 통계 분석” = S3 Storage Lens

🔀 4. 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: 인스턴스 이상 감지 → 자동 복구

[EC2 인스턴스]
    |
[CloudWatch Agent] ← 메모리/디스크 사용량 수집 (기본 지표로는 불가)
    |
[CloudWatch Alarm] ← 임계값 초과 시
    |
 ├─ [SNS → 운영팀 알림]
 ├─ [EC2 Recover Action] ← 하드웨어 장애 시 자동 재부팅
 └─ [Auto Scaling] ← 비정상 인스턴스 교체

키워드: “메모리 모니터링” + “자동 복구” + “운영 오버헤드 없음”

패턴 2: 서버리스 이벤트 자동화 (EventBridge)

[다양한 이벤트 소스]
 ├─ EC2 상태 변경 (stopped, terminated)
 ├─ S3 객체 업로드
 ├─ CloudTrail API 호출 감지
 └─ 예약된 시간 (Cron)
         |
    [EventBridge] ← 라우팅 규칙
         |
     ├─ [Lambda] ← 비즈니스 로직 실행
     ├─ [SNS] ← 알림 발송
     └─ [SQS] ← 비동기 처리 큐

키워드: “특정 상태 시 자동 처리” + “서버리스 자동화” + “이벤트 기반”

패턴 3: 중앙 집중 로그 분석 파이프라인

[EC2, Lambda, VPC Flow Logs, CloudTrail]
    |
[CloudWatch Logs] ← 모든 로그 수집
    |
[Subscription Filter] ← 실시간 스트리밍
    |
[Kinesis Data Firehose]
    |
 ├─ [S3] ← 장기 보관 (Glacier로 수명주기)
 └─ [OpenSearch] ← 실시간 검색/대시보드

키워드: “중앙 로그 수집” + “실시간 분석” + “장기 보관”

🔗 연결 문서 (관련 주제)

1.3 서버리스 컴퓨팅 (Lambda) (EventBridge의 주 대상)
5.3 위협 탐지 및 보안 감사 (GuardDuty, Macie 알람 연동)
4.1 VPC 및 네트워크 기초 (Flow Logs 분석)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

사용법: 답을 보지 말고 소리 내어 설명해보세요. 막히는 항목이 취약점입니다.

“메모리 사용률이 높아서 애플리케이션이 느리다” → 기본 CloudWatch로 확인 불가한 이유와 해결책은?
“EC2가 종료되면 자동으로 Slack 알림을 보내고 싶다” → 어떤 서비스 조합, 이유는?
CloudWatch Alarm vs EventBridge의 차이는? 각각 어떤 상황에 쓰는가?
“로그를 실시간으로 OpenSearch로 보내야 한다” → 어떤 설정이 필요한가?
VPC Flow Logs가 필요한 대표적인 시나리오는? CloudTrail과 어떻게 다른가?

# 6.1 메시지 큐 및 알림 (Amazon SQS & SNS)

📌 핵심 요약

목적: 시스템 구성 요소 간의 의존성을 제거하여 확장성과 내결함성을 높임.
SQS: Pull 방식의 메시지 큐. 소비자(Consumer)가 준비됐을 때 메시지를 가져감.
SNS: Push 방식의 알림 서비스. 메시지가 오면 즉시 구독자들에게 뿌림.
설계 원칙:
- 급격한 트래픽 증가 대비 → SQS로 버퍼링.
- 하나의 이벤트를 여러 곳에 전달 → SNS 팬아웃 아키텍처.

📥 1. Amazon SQS (Simple Queue Service)

✅ 대기열 유형 비교 (가장 중요)

문제에서 “순서”와 “중복” 키워드에 따라 선택하세요.


특징	표준 대기열 (Standard)	FIFO 대기열
------	------	------
순서 보장	최선 노력, 보장 안 함	정확히 FIFO 순서 보장
전달 횟수	최소 1회 (중복 가능)	정확히 1회 (Exactly-once)
처리량	무제한	초당 300~3,000건 (제한적)
용도	일반 작업 부하 분산	결제, 주문 처리 (Q10, Q149, Q181)

✅ 핵심 메커니즘 (트러블슈팅 포인트)

가시성 제한 시간 (Visibility Timeout):
- 문제: 소비자가 메시지를 처리 중인데 다른 소비자가 또 가져가서 중복 처리됨. (Q98, Q67, Q611)
- 해결: 가시성 제한 시간을 늘려서 처리 중에는 다른 사람이 못 보게 함.
배달 못한 편지 대기열 (DLQ): 처리에 실패한 메시지를 따로 모아두는 곳. 분석 및 재처리용. (Q164, Q489)
롱 폴링 (Long Polling): 빈 큐를 계속 찌르는 대신 메시지가 올 때까지 기다림 → 비용 절감.

✅ 주요 특징

Pub/Sub 모델: 발행자(Publisher)가 주제(Topic)에 메시지를 보내면, 다수의 구독자(Subscriber)가 수신.
구독 대상: Lambda, SQS, 이메일, HTTP 엔드포인트, 모바일 푸시.
메시지 필터링: 구독자가 특정 조건의 메시지만 받도록 설정 가능 (Q311).

✅ SNS + SQS 팬아웃 (Fan-out) 패턴

구조: 하나의 SNS 주제에 여러 개의 SQS 큐를 구독시킴.
장점: 메시지가 발생하면 주문 DB 저장용 SQS, 배송 시스템용 SQS, 분석용 SQS에 동시에 전달됨. (Q7, Q108)

🛠️ 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: 주문이 접수된 순서대로 처리되어야 함 (Q10, Q149)

해결: SQS FIFO 대기열.
키워드: “정확히 한 번(Exactly-once)”, “순차 처리”.

✅ 사례 2: 소비자 앱이 실패해도 데이터 유실이 없어야 함 (Q195, Q228, Q404)

문제: 트래픽이 몰려 DB 쓰기가 실패하거나 서버가 다운됨.
해결: SQS를 도입하여 데이터를 큐에 임시 보관(버퍼링).
이유: 서버가 복구된 후 큐에서 다시 가져오면 되기 때문 (내결함성).

✅ 사례 3: 네트워크 문제로 데이터 수집이 가끔 실패함 (Q148, Q45)

해결: SNS 주제에 SQS를 구독시키고 Lambda가 SQS를 읽게 함.
이유: SNS 단독 사용 시 구독자가 다운되면 메시지가 유실될 수 있지만, SQS를 끼우면 메시지가 보존됨.

💡 한 줄 공식 (SAA 득점 키워드)

“결합 해제(Decouple) / 비동기” = SQS
“순서 보장 / 중복 제거” = SQS FIFO
“동시 처리 / 다수 타겟 전달” = SNS + SQS 팬아웃
“메시지 중복 처리 발생(오류)” = Visibility Timeout 부족
“비용 효율적인 큐 폴링” = Long Polling

🚨 3. 혼동 포인트 (6.1 전용)

이것만 틀리지 마세요

SQS vs SNS 핵심 차이

SQS: Pull 방식, 소비자가 준비됐을 때 가져감 (메시지 보존)

SNS: Push 방식, 즉시 모든 구독자에게 뿌림 (메시지 보존 없음)

SNS 단독 사용 시 구독자 다운 → 메시지 유실 → SNS + SQS 조합으로 해결

Standard vs FIFO 선택 기준

“순서 중요” / “중복 제거 필요” / “결제·주문” → FIFO

“최대 처리량” / “순서 무관” → Standard

Visibility Timeout 이해

메시지를 가져간 소비자가 처리 중일 때 다른 소비자가 같은 메시지를 못 가져가게 하는 시간

처리 시간이 Timeout보다 길면 → 다른 소비자가 가져감 → 중복 처리 발생

🔀 4. 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: SNS + SQS 팬아웃 (Fan-out)

[주문 이벤트 발생]
    |
[SNS Topic] ← Pub/Sub 중앙 허브
 ├─ [SQS A] → [Lambda: DB 저장]
 ├─ [SQS B] → [Lambda: 배송 시스템]
 └─ [SQS C] → [Lambda: 분석/통계]

키워드: “하나의 이벤트를 여러 시스템에 동시 전달” + “각각 독립적으로 처리”

패턴 2: SQS 버퍼링으로 트래픽 급증 흡수

[갑작스러운 트래픽 급증]
    |
[ALB] → [EC2 ASG (웹 서버)]
    |
[SQS Queue] ← 처리를 큐에 위임 (DB 직접 쓰기 금지)
    |
[EC2 Worker / Lambda] ← 속도 제어하며 안전하게 처리
    |
[RDS / DynamoDB]

키워드: “DB 과부하 방지” + “데이터 유실 없음” + “Decoupling”

패턴 3: 주문 처리 순서 보장 + 실패 처리

[주문 API]
    |
[SQS FIFO] ← 순서 보장 + 중복 제거
    |
[Lambda] ← 처리 (실패 시 재시도)
    |
[DLQ (Dead Letter Queue)] ← 반복 실패 메시지 격리
    |
[CloudWatch Alarm] ← DLQ 메시지 발생 시 알림

키워드: “순서 보장 + 실패 메시지 격리” + “정확히 한 번 처리”

🔗 연결 문서 (관련 주제)

1.3 서버리스 컴퓨팅 (Lambda) (SQS/SNS의 주요 소비자)
3.3 NoSQL 및 캐싱 (DynamoDB) (SQS 처리 결과를 저장하는 곳)
6.3 스트리밍 데이터 (Kinesis) (실시간 대용량 데이터와의 차이점)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

사용법: 답을 보지 말고 소리 내어 설명해보세요. 막히는 항목이 취약점입니다.

SNS 단독 사용 시 구독자 서버가 다운되면 메시지는 어떻게 되는가? 어떻게 해결하는가?
“주문을 순서대로 처리하고 중복도 없어야 한다” → Standard가 오답인 이유는?
Visibility Timeout이 부족하면 어떤 문제가 생기는가? 어떻게 설정해야 하는가?
“하나의 이벤트를 여러 시스템이 동시에 받아 처리” → 어떤 아키텍처 패턴인가?
SQS vs SNS 중 메시지를 보존하는 서비스는? 이 차이가 설계에서 왜 중요한가?

# 6.2 워크플로 및 서비스 통합 (Step Functions & AppFlow)

📌 핵심 요약

AWS Step Functions: 여러 AWS 서비스를 단계별로 연결하는 시각적 워크플로 서비스 (상태 머신).
Amazon AppFlow: **SaaS(Salesforce, Slack 등)**와 AWS 서비스 간의 데이터를 코딩 없이 전송.
Amazon MQ: 레거시 메시징 프로토콜(ActiveMQ, RabbitMQ)을 AWS에서 그대로 사용하고 싶을 때 선택.

🔄 1. AWS Step Functions (오케스트레이션)

단순한 1:1 트리거를 넘어, 복잡한 로직이 필요할 때 정답입니다.


기능	상세 내용	시험 포인트 (키워드)
------	------	------
상태 관리	각 단계 성공/실패 기억 + 재시도	분산 애플리케이션 조율 (Q366, Q375)
수동 승인	중간에 사람이 승인해야 다음 단계 진행	”인적 검토(Manual Approval)” 필요 시
병렬 처리	여러 작업 동시 실행 + 결과 취합	데이터 처리 가속 (Q603)
장기 실행	최대 1년까지 워크플로 유지	Lambda 15분 한계 극복

시험 팁 (Q375, Q670)

“여러 Lambda 함수를 순서대로 실행” + “오류 처리 및 재시도 로직 필요” = Step Functions

☁️ 2. Amazon AppFlow (SaaS 통합)

연결 대상: Salesforce, SAP, Zendesk ↔ Amazon S3, Redshift
특징: 코딩이 필요 없는 관리형 서비스 (Q460). PrivateLink를 통한 안전한 전송.

🐇 3. Amazon MQ (레거시 마이그레이션)

대상 프로토콜: JMS, AMQP, MQTT, STOMP
선택 기준: 기존 앱이 ActiveMQ나 RabbitMQ를 사용 중인 경우 (Q111, Q138)
고가용성: Active/Standby 모드 지원

🛠️ 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: 분산 시스템의 비즈니스 로직 조율 (Q366, Q375)

해결: AWS Step Functions
이유: 각 단계가 독립된 서비스로 구성 → 중앙 통제실 필요

✅ 사례 2: Salesforce 데이터를 S3로 (Q460)

해결: Amazon AppFlow
이유: 직접 API 연동 대비 운영 오버헤드 적음

✅ 사례 3: 온프레미스 RabbitMQ → AWS 마이그레이션 (Q111, Q138)

해결: Amazon MQ
오답: SQS는 RabbitMQ와 API가 달라 코드 수정 대대적으로 필요

💡 한 줄 공식 (SAA 득점 키워드)

“복잡한 워크로드 / 상태 관리” = Step Functions
“SaaS 데이터 연동 / No-code” = AppFlow
“레거시 프로토콜(RabbitMQ/ActiveMQ) 유지” = Amazon MQ
“병렬 처리 / 분산 모드” = Step Functions Map State (Q603)

🔀 6.2 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: 서버리스 주문 처리 워크플로

API Gateway
     │
     ▼
Step Functions
  ├── Step 1: Lambda (결제 처리) ──실패──► DLQ
  ├── Step 2: Lambda (재고 차감)
  ├── Step 3: Lambda (배송 요청)
  └── Step 4: Manual Approval (사람 검토)

키워드: “복잡한 순서” + “오류 처리” + “인적 검토”

패턴 2: SaaS 데이터 통합 파이프라인

Salesforce / SAP
      │ (코딩 없이)
      ▼
  AppFlow
      │
  S3 ──► Glue ETL ──► Redshift

키워드: “SaaS 연동” + “No-code” + “운영 오버헤드 최소화”

패턴 3: 레거시 메시지 브로커 마이그레이션

온프레미스 (RabbitMQ)
      │ 코드 변경 없이
      ▼
Amazon MQ (Active/Standby)
      │ 점진적 마이그레이션
      ▼
Amazon SQS (AWS 네이티브)

키워드: “기존 코드 유지” + “레거시 호환성”

🔗 연결 문서 (관련 주제)

1.3 서버리스 컴퓨팅 (Lambda) (Step Functions의 작업 단위)
6.1 Amazon SQS 및 메시징 (SQS와 MQ의 차이점 이해)
5.4 모니터링 및 로깅 (EventBridge와 통합)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

사용법: 답을 보지 말고 소리 내어 설명해보세요. 막히는 항목이 취약점입니다.

Lambda 15분 제한을 초과하는 복잡한 비즈니스 로직을 어떻게 처리하는가?
Step Functions에서 “인적 검토(Manual Approval)“가 필요한 시나리오를 설명하라.
AppFlow가 필요한 상황은? 직접 API 코딩 대비 장점은?
Amazon MQ를 SQS 대신 선택하는 유일한 이유는 무엇인가?
Step Functions의 Map State는 어떤 문제를 해결하는가?

# 6.3 스트리밍 데이터 (Amazon Kinesis)

📌 핵심 요약

목적: 대규모 스트리밍 데이터를 실시간으로 수집, 처리 및 분석.
KDS (Data Streams): 실시간 수집 및 처리. 낮은 지연 시간(밀리초). 샤드(Shard) 단위 수동 확장.
KDF (Data Firehose): 스트리밍 데이터를 분석 시스템(S3, Redshift 등)에 로드(전송). 자동 확장.
KDA (Data Analytics): 스트리밍 데이터에 SQL 쿼리를 날려 실시간 분석.

⚡ 1. Kinesis 서비스별 비교 (가장 중요)

기능	Kinesis Data Streams (KDS)	Kinesis Data Firehose (KDF)	❌ 오답이 되는 조건
성격	데이터 수집 및 실시간 처리	데이터 전송 및 로드 (ETL)	“실시간 처리” 문제에 KDF 선택 (KDF는 최소 60초 지연)
지연 시간	실시간 (밀리초)	근실시간 (최소 60초 버퍼)	“밀리초 응답” 필요한데 KDF 선택
데이터 보존	24시간 ~ 365일 (재생 가능)	보존 기능 없음 (전송용 파이프)	“데이터 재생(Replay)” 필요한데 KDF 선택
확장성	샤드 수동 관리 (Provisioned)	완전 관리형 (자동 확장)	운영 오버헤드 최소화 문제에 KDS 선택
최종 목적지	사용자 지정 앱, Lambda, KDA	S3, Redshift, OpenSearch, HTTP	S3 저장 목적에 KDS 직접 연결 시도

시험 팁 (Q33, Q77, Q226)

“데이터를 변환해서 S3/Redshift에 바로 저장해야 함” → KDF

“데이터를 수집한 후 여러 애플리케이션이 동시에 읽어야 함” → KDS

🆚 2. SQS vs Kinesis (헷갈림 주의)


비교 항목	Amazon SQS	Amazon Kinesis (KDS)
------	------	------
모델	Pull (메시지 가져가면 삭제)	스트림 (여러 소비자 반복 읽기)
순서	FIFO 설정 시에만 보장	파티션 키별 항상 순서 보장
Replay	불가 (소비 후 삭제)	가능 (보존 기간 내 재처리)
용도	서비스 결합 해제, 작업 큐	빅데이터 수집, 클릭스트림, 로그 집계
처리량	무제한 (Standard)	샤드 수에 따라 결정

SQS vs Kinesis 핵심 선택 기준

“여러 소비자가 같은 데이터를 각자 읽어야 함” → Kinesis (SQS는 한 소비자가 가져가면 삭제)

“데이터 재처리/재생이 필요” → Kinesis (SQS는 Replay 불가)

“서비스 간 결합 해제, 작업 큐” → SQS

“초당 GB 이상 대용량 스트림” → Kinesis

🛠️ 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: 대규모 클릭스트림 데이터 분석 (Q59, Q267, Q501)

문제: 하루 30TB 이상의 데이터를 수집하고 실시간 분석 후 Redshift에 저장해야 함.
해결: Kinesis Data Streams(수집) → Kinesis Data Analytics(분석) → Kinesis Data Firehose(로드) → Redshift.
이유: Kinesis 패밀리는 대용량 스트림 데이터를 가장 운영 오버헤드 적게 처리하는 표준 아키텍처임.

✅ 사례 2: S3에 데이터가 누락되는 문제 해결 (Q402)

문제: KDS로 받은 데이터를 S3에 쓰는데 일부 데이터가 없음. (격일로 분석함)
해결: KDS의 데이터 보존 기간(Retention Period)을 늘림.
이유: 기본 보존 기간은 24시간임. 소비자가 하루 이상 늦게 읽으면 데이터가 사라짐.

✅ 사례 3: IoT 장치의 상태 알림 수집 (Q40, Q257)

문제: 수천 개의 에지 장치에서 발생하는 경고를 수집하여 14일간 보관하고 분석하고 싶음.
해결: Kinesis Data Firehose → Amazon S3.
이유: 실시간성이 아주 높지 않아도 되고(Near real-time), 관리가 편한(관리형) 전송로가 필요하기 때문.

💡 한 줄 공식 (SAA 득점 키워드)

“실시간 스트리밍 / 로그 집계” = Kinesis Data Streams
“S3, Redshift로 자동 전송(로드)” = Kinesis Data Firehose
“움직이는 데이터에 SQL 쿼리” = Kinesis Data Analytics
“초당 기가바이트 / 수백만 건 수집” = Kinesis
“데이터를 여러 번 읽어야 함(Replay)” = Kinesis (SQS는 불가능)

🔀 4. 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: 실시간 클릭스트림 분석 파이프라인

[웹/앱 사용자 클릭 이벤트] (초당 수십만 건)
    |
[Kinesis Data Streams] ← 실시간 수집, 밀리초 지연
    |
 ├─ [Kinesis Data Analytics] ← SQL로 실시간 이상 탐지
 └─ [Kinesis Data Firehose]
         |
     ├─ [S3] ← 원시 데이터 장기 보관
     └─ [Redshift] ← 집계 분석

키워드: “실시간 대용량” + “여러 소비자” + “분석 후 저장”

패턴 2: IoT 데이터 수집 → 자동 알림

[IoT 장치 수천 개] → [Kinesis Data Firehose]
    |
[S3] ← 14일 보관
    |
[Lambda (S3 Event)] ← 임계값 초과 탐지
    |
[SNS] ← 운영팀 즉시 알림

키워드: “IoT 대량 수집” + “관리형 전송” + “자동 알림”

패턴 3: SQS vs Kinesis 비교 아키텍처

SQS 적합:
[주문 이벤트] → [SQS] → [Lambda A (처리 후 삭제)]
  ↑ 메시지를 한 번만 처리하면 됨, 결합 해제 목적

Kinesis 적합:
[로그 스트림] → [KDS] → [Lambda A (실시간 분석)]
                      → [Lambda B (이상 탐지)]
                      → [Lambda C (저장)]
  ↑ 여러 소비자가 같은 데이터를 각자 읽어야 함

키워드: “여러 소비자 동시 읽기” + “Replay” → Kinesis / “작업 큐” → SQS

🔗 연결 문서 (관련 주제)

2.1 Amazon S3 스토리지 (KDF의 저장소)
3.4 분석 및 ETL (Redshift, Glue) (Kinesis 분석 후 저장소)
6.1 Amazon SQS 및 메시징 (메시징 vs 스트리밍 비교)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

사용법: 답을 보지 말고 소리 내어 설명해보세요. 막히는 항목이 취약점입니다.

“여러 앱이 같은 데이터를 각자 읽어야 한다” → SQS가 오답인 이유와 올바른 선택은?
KDS vs KDF 선택 기준을 지연시간과 관리 난이도 기준으로 설명하면?
“데이터를 어제 처리 못했는데 다시 읽어야 한다(Replay)” → SQS가 불가한 이유는?
KDF에서 JSON → Parquet으로 변환하려면 → 어떻게 설정하는가?
Kinesis와 SQS 둘 다 데이터를 전달하는데 근본적인 모델 차이는?

# 7.1 비용 최적화 및 관리 도구

📌 핵심 요약

Cost Explorer: 과거 지출 분석 및 향후 12개월 지출 예측. (시각화 중심)
AWS Budgets: 특정 임계값을 넘으면 알림(Alarm) 전송 및 자동 작업 수행. (한도 설정 중심)
Savings Plans: 일정 금액($/시간) 약정을 통한 EC2, Fargate, Lambda 할인. (유연성 높음)
Cost Anomaly Detection: 머신러닝을 통한 비정상적인 비용 급증 감지.

📊 1. 비용 분석 및 모니터링 도구 비교

도구	주요 용도	시험 포인트 (키워드)	❌ 오답이 되는 조건
Cost Explorer	과거 데이터 분석, 필터링 조회	”지난 2개월 비용 비교”, “인스턴스 유형별 분석” (Q24, Q525)	“알림 설정” 문제인데 Cost Explorer 선택
AWS Budgets	예산 초과 방지 알림 + 자동 조치	”임계값 도달 시 알림”, “리소스 생성 차단” (Q238, Q455)	단순 분석 목적인데 Budgets 선택
Anomaly Detection	예측 못한 비용 급증 감지	”비정상적인 지출 식별”, “ML 기반 감지” (Q705)	정기 예산 한도 설정에 Anomaly Detection 선택
Cost & Usage Report	가장 상세한 원시 데이터 제공	”S3로 데이터 내보내기”, “Athena 상세 쿼리” (Q264)	시각적 분석에 CUR 선택 (CUR은 원시 데이터용)

💰 2. 할인 모델 (Commitment 기반)

Savings Plans (세이빙 플랜):
- Compute Savings Plans: 가장 유연함. EC2(패밀리 상관없음), Fargate, Lambda에 모두 적용. (Q552)
- EC2 Instance Savings Plans: 특정 리전 내 특정 패밀리만 해당하지만 할인율이 더 높음.
Reserved Instances (RI - 예약 인스턴스):
- 표준 RI: 수정 불가, 할인율 높음.
- 전환형 RI: 인스턴스 속성 변경 가능.
할인 공유 (Discount Sharing):
- AWS Organizations의 **통합 빌링(Consolidated Billing)**을 사용하면 한 계정의 할인을 조직 내 다른 계정이 공유 가능. (Q467, Q543)

🛠️ 3. 비용 최적화 전략

S3 비용 절감: 접근 빈도에 따라 S3 Lifecycle 정책으로 계층 이동. (Q23, Q126)
EC2 비용 절감:
- 중단 가능 업무 → Spot Instance
- 꾸준한 업무 → Savings Plans
- 업무 시간 외 중지 → Instance Scheduler (Q546, Q597)
태그 활용: **비용 할당 태그(Cost Allocation Tags)**로 부서별/프로젝트별 비용 추적. (Q455, Q559)

🛠️ 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: 지난 2개월간 특정 인스턴스 비용 분석 (Q24)

해결: Cost Explorer의 세분화된 필터링 기능.
이유: 시각적 그래프 + 인스턴스 유형별 분석 가능.

✅ 사례 2: 예산 초과 시 추가 리소스 생성 차단 (Q455, Q238)

해결: AWS Budgets + Actions.
이유: 임계값 도달 시 IAM 정책 수정 또는 인스턴스 중지 자동화.

✅ 사례 3: 조직 내 전체 계정 할인 혜택 극대화 (Q543, Q467)

해결: 관리 계정에서 할인 공유(Discount Sharing) 활성화.

💡 한 줄 공식 (SAA 득점 키워드)

“과거 지출 시각화 / 분석” = Cost Explorer
“임계값 알림 / 자동 조치” = AWS Budgets
“비정상적 급증 감지” = Cost Anomaly Detection
“가장 유연한 컴퓨팅 할인” = Compute Savings Plans
“부서별 비용 추적” = Cost Allocation Tags

🔀 7.1 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: 비용 이상 감지 → 자동 알림 파이프라인

Cost Anomaly Detection
(ML 기반 이상 감지)
        │
        ▼
   SNS Topic
   ┌────┴────┐
   ▼         ▼
이메일 알림   Slack Webhook

키워드: “비용 급증 자동 감지” + “운영 오버헤드 최소화”

패턴 2: AWS Budgets Actions (예산 초과 시 자동 차단)

AWS Budgets (임계값 80% 도달)
        │
        ▼
 Budgets Actions
  ┌─────┴─────┐
  ▼           ▼
IAM Policy  EC2 중지
(권한 제한)   (비용 차단)

키워드: “임계값 초과 시 자동 조치” + “리소스 생성 차단”

패턴 3: 통합 빌링 + Compute Savings Plans 공유

AWS Organizations 관리 계정
  ├── 개발 계정
  ├── 스테이징 계정
  └── 프로덕션 계정
         │
Compute Savings Plans (관리 계정 구매)
→ 자동으로 조직 전체 계정에 할인 적용

키워드: “여러 계정 통합 비용 관리” + “할인 공유” + “통합 빌링”

🔗 연결 문서 (관련 주제)

5.1 IAM 및 Organizations (통합 빌링 관리)
1.1 Amazon EC2 (Spot, RI 구매 옵션)
7.2 재해 복구(DR) 전략 (비용 vs 복구 속도 트레이드오프)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

사용법: 답을 보지 말고 소리 내어 설명해보세요. 막히는 항목이 취약점입니다.

Cost Explorer와 AWS Budgets의 차이를 설명하라. 각각 언제 쓰는가?
Compute Savings Plans와 EC2 Instance Savings Plans의 차이는?
AWS Organizations 통합 빌링에서 Savings Plans 할인이 공유되는 방식을 설명하라.
Cost Anomaly Detection은 어떤 문제를 해결하는가? AWS Budgets와의 차이는?
부서별 비용을 추적하려면 어떤 AWS 기능을 활용해야 하는가?

# 7.2 재해 복구(DR) 및 백업 전략

📌 핵심 요약

RPO (Recovery Point Objective): 데이터 손실 허용 시간. (예: 15분 전 데이터까지 복구 가능)
RTO (Recovery Time Objective): 서비스 중단 허용 시간. (예: 장애 발생 후 1시간 내 복구 완료)
설계 원칙: RTO/RPO가 짧을수록 비용이 기하급수적으로 증가함. 문제에서 제시한 ‘최소 비용’ 혹은 ‘최저 지연 시간’ 키워드에 따라 전략 선택.

🛠️ 1. 재해 복구(DR) 4대 전략 비교

시험 문제에서 요구하는 “가동 중지 시간”과 “예산”에 따라 정답이 갈립니다.

전략	설명	비용	RTO/RPO	핵심 키워드	❌ 오답이 되는 조건
Backup & Restore	데이터를 S3 등에 백업하고 필요 시 복원	최저	시간 단위	”비용 최적화”, “긴 가동 중지 허용"	"수분 내 복구” 요구인데 선택
Pilot Light	DB만 실시간 복제, 앱 서버는 꺼둠	낮음	수분 단위	”핵심 자원만 가동”, “CloudFormation”	Warm Standby와 혼동 (앱 서버 미가동이 차이)
Warm Standby	전체 시스템을 최소 사양으로 항상 가동	중간	초~분 단위	”축소된 용량(Scaled-down)” (Q273)	“즉시 복구(제로 다운타임)” 요구인데 선택
Multi-site	두 리전에서 100% 용량으로 동시 가동	최고	즉시	”제로 다운타임”, “실시간 서비스”	비용 최소화 문제인데 선택

💾 2. 데이터베이스 및 저장소 DR

✅ Amazon Aurora Global Database (Q217, Q273, Q343)

특징: 리전 간 복제 지연 1초 미만.
RTO/RPO: SAA 시험에서 가장 빠른 DR 성능을 요구할 때 정답.
동작: 장애 시 보조 리전을 읽기/쓰기가 가능한 기본 리전으로 즉시 승격.

✅ S3 교차 리전 복제 (CRR) (Q1, Q621)

용도: 규정 준수 또는 지리적 근접성을 위해 다른 리전으로 데이터 자동 복제.
설계: 원본 버킷과 대상 버킷 모두 버전 관리(Versioning) 활성화 필수.

✅ AWS Backup (Q178, Q312, Q508, Q279)

용도: RDS, EBS, EFS, DynamoDB 등의 백업을 중앙에서 자동화.
보안: AWS Backup Vault Lock을 사용하여 백업 삭제 방지 (규정 준수).

🛠️ 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: 최소한의 리소스로 4시간 내 복구 (Q274, Q305)

문제: 평소에는 돈을 안 쓰고 싶지만, 장애 나면 4시간 안에 살려내야 함.
해결: AMI 복제 + CloudFormation.
이유: 평소에는 서버를 켜두지 않아 비용이 거의 안 들고, 장애 시 템플릿(IaC)으로 빠르게 인프라를 생성할 수 있음.

✅ 사례 2: 30분 미만의 다운타임 허용 (Q217)

문제: 서비스가 중요하지만 24시간 두 곳을 다 켜두기엔 비쌈.
해결: Aurora 글로벌 데이터베이스 + Route 53 장애 조치(Failover).
이유: 데이터는 실시간 복제하고, 장애 시에만 보조 리전을 승격시켜 가동.

✅ 사례 3: 정적 오류 페이지 노출 (Q545)

문제: 메인 서버가 죽었을 때 사용자에게 S3에 저장된 점검 페이지를 보여주고 싶음.
해결: Route 53 장애 조치 라우팅(Failover) 정책 설정.
구성: Primary(ALB) / Secondary(S3 Static Website).

💡 한 줄 공식 (SAA 득점 키워드)

“가장 짧은 RTO/RPO” = Aurora Global Database
“최소 비용의 백업” = S3 Glacier Deep Archive
“백업 삭제 방지 (WORM)” = AWS Backup Vault Lock 또는 S3 Object Lock
“인프라 복제 자동화” = AWS CloudFormation
“리전 간 자동 장애 조치” = Route 53 Failover Routing

🚨 7.2 혼동 포인트 (DR 전략 전용)

이것만 틀리지 마세요

Pilot Light vs Warm Standby: Pilot Light = DB만 켜둠, 앱은 꺼둠. Warm Standby = 전체 시스템 최소 사양으로 켜둠

RPO vs RTO: RPO = 데이터 손실 허용량. RTO = 복구 시간 목표. “데이터 손실 최소화” = RPO↓, “빠른 복구” = RTO↓

Aurora Global vs Multi-AZ: Aurora Global = 리전 간 복제 (DR). Multi-AZ = 단일 리전 고가용성

“가장 저렴한 DR”: Backup & Restore. Pilot Light는 DB 복제 비용 발생

S3 CRR 조건: 교차 리전 복제 시 양쪽 버킷 모두 버전 관리 활성화 필수

🔀 7.2 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: Pilot Light DR 아키텍처

[운영 리전 - ap-northeast-2]    [DR 리전 - us-east-1]
  ALB + EC2 (Active)               EC2 (꺼짐)
       │                                │
       ▼                                ▼
  RDS Primary ──── 실시간 복제 ──► RDS Replica
                                   (장애 시 승격)
  Route 53 Failover
  ├── Primary: 운영 리전 ALB
  └── Secondary: DR 리전 ALB (장애 시 자동 전환)

키워드: “핵심 자원만 상시 가동” + “낮은 비용” + “수분 내 복구”

패턴 2: Aurora Global Database (제로 RPO 목표)

[기본 리전]                    [보조 리전]
Aurora Primary ──(1초 미만)──► Aurora Secondary
(읽기/쓰기)                    (읽기 전용)
     │
     └── 장애 발생 시 ──────────► 보조 리전 승격
                        Route 53 Failover 자동 전환

키워드: “RPO 1초 미만” + “글로벌 서비스” + “리전 장애 대비”

패턴 3: Warm Standby + Auto Scaling 확장

[운영 리전]                    [DR 리전]
EC2 ASG (Full 용량)            EC2 ASG (최소 1대)
     │                              │
ALB (Active)                   ALB (Standby)
     │                              │
RDS Primary ───── 복제 ──────► RDS Read Replica
Route 53 Health Check
├── 정상: 운영 리전 라우팅
└── 장애: DR ASG 확장 → 트래픽 전환

키워드: “축소된 용량 상시 운영” + “빠른 확장” + “초~분 단위 RTO”

🔗 연결 문서 (관련 주제)

2.1 Amazon S3 스토리지 (Backup & Restore의 기본 저장소)
4.1 VPC 및 네트워킹 기초 (DR 리전 간 네트워크 구성)
4.4 DNS 및 글로벌 라우팅 (Route 53) (Failover 라우팅 정책)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

사용법: 답을 보지 말고 소리 내어 설명해보세요. 막히는 항목이 취약점입니다.

DR 4대 전략을 비용 순서로 나열하고 각각의 RTO/RPO 특성을 설명하라.
Pilot Light와 Warm Standby의 결정적 차이는 무엇인가?
RPO와 RTO의 차이를 실제 시나리오를 들어 설명하라.
Aurora Global Database를 쓸 때와 Multi-AZ를 쓸 때의 차이는?
Route 53 Failover 라우팅에서 Primary/Secondary에 각각 무엇을 놓는가?

Quartz 4

탐색기

📂 AWS Certified Solutions Architect - Associate (SAA-C03) 통합 목차

제1장: 탄력적 및 고가용성 컴퓨팅 (Compute)

제2장: 고성능 및 확장 가능 스토리지 (Storage)

제3장: 데이터베이스 설계 및 최적화 (Database)

제4장: 네트워킹 및 콘텐츠 전송 (Networking)

제5장: 보안, 거버넌스 및 모니터링 (Security & Monitoring)

제6장: 애플리케이션 통합 및 메시징 (App Integration)

제7장: 비용 최적화 및 재해 복구 (Cost & DR)

# 1.1 Amazon EC2 (Elastic Compute Cloud)

📌 핵심 요약

💰 1. 구매 옵션 (비용 최적화의 핵심)

⚡ 2. 인스턴스 패밀리 (상황별 선택)

🕸️ 3. 배치 그룹 (Placement Groups)

🔐 4. EC2 보안 및 권한 (Q17, Q289, Q403)

🛠️ 5. 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: 야간 배치 작업의 실행 시간 단축 (Q271, Q680)

✅ 사례 2: 인스턴스 상태 유지 및 빠른 초기화 (Q335, Q594)

✅ 사례 3: 하이퍼바이저 수준의 관리 오버헤드 제거 (Q163, Q516)

🔀 6. 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: 기본 고가용성 웹 아키텍처

패턴 2: 비용 최적화 배치 처리

패턴 3: Spot 혼합 전략 (중단 방지)

🔗 연결 문서 (관련 주제)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

# 1.2 Auto Scaling & ELB (Elastic Load Balancing)

📌 핵심 요약

⚖️ 1. Elastic Load Balancer (ELB) 유형 비교

📈 2. Auto Scaling Group (ASG) 조정 정책

🏗️ 3. 고가용성 설계 전략 (HA)

✅ 세션 관리 (Sticky Sessions vs Stateless)

✅ 상태 확인 (Health Checks)

🛠️ 4. 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: 특정 국가의 접속만 허용하고 싶을 때 (Q170, Q399, Q608)

✅ 사례 2: 트래픽 급증 시 데이터 유실 방지 (Q228, Q404, Q462)

✅ 사례 3: 인터넷 통신 없이 S3/DynamoDB 접근 (Q4, Q91, Q176)

🔀 5. 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: 보안 강화 웹 아키텍처

패턴 2: 마이크로서비스 라우팅

패턴 3: 트래픽 급증 완충 (Decoupling)

🔗 연결 문서 (관련 주제)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

# 1.3 서버리스 컴퓨팅 (AWS Lambda)

📌 핵심 요약

⚙️ 1. 주요 특징 및 제한 사항

🚀 2. Lambda 성능 및 최적화

🛡️ 3. 보안 및 네트워크 (VPC Access)

🛠️ 4. 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: 대량의 파일 변환 및 처리 (Q18, Q63, Q110, Q161)

✅ 사례 2: 마이크로서비스 간의 비동기 통신 (Q10, Q462, Q672)

✅ 사례 3: 운영 오버헤드 감소 (Q316)

💡 5. 한 줄 공식 (SAA 득점 키워드)

🔀 6. 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: 이벤트 기반 파일 처리

패턴 2: API 기반 비동기 주문 처리

패턴 3: 서버리스 스케줄 작업

🔗 연결 문서 (관련 주제)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

# 1.4 컨테이너 서비스 (ECS, EKS, Fargate)

📌 핵심 요약

🏗️ 1. 서비스별 비교 (무엇을 쓸 것인가?)

⚡ 2. ECS/EKS의 실행 모델 (Launch Types)

💾 3. 컨테이너 스토리지 및 네트워크

🛠️ 4. 문제 분석으로 본 설계 로직 (오답 노트용)

✅ 사례 1: 모놀리식 애플리케이션의 현대화 (Q670)

✅ 사례 2: 온프레미스 쿠버네티스 이전 (Q198, Q263)

✅ 사례 3: 컨테이너의 권한 관리 (Q185)

💡 5. 한 줄 공식 (SAA 득점 키워드)

🔀 6. 멀티 서비스 조합 패턴 (고득점 필수)

패턴 1: 서버리스 마이크로서비스 전체 아키텍처

패턴 2: K8s 온프레미스 → AWS 이전

패턴 3: 컨테이너 CI/CD 파이프라인

🔗 연결 문서 (관련 주제)

✍️ 스스로 질문해보기 (답 말로 설명해보기)

# 2.1 Amazon S3 (Simple Storage Service)

📌 핵심 요약

📦 1. 스토리지 클래스 (비용 최적화의 핵심)

🔄 2. 수명 주기 및 복제 (Lifecycle & Replication)

🔒 3. 데이터 보안 및 규정 준수 (Protection)