AWS SAA 376~

도은호·2025년 12월 22일

AWS SAA

목록 보기

51/53

상황 (문제점):

서버리스(Lambda): 트래픽이 몰리면 순식간에 수천 개로 늘어납니다. (마치 관광버스 100대가 갑자기 식당에 들이닥친 상황)
RDS(DB): 전통적인 DB라 '연결(문)'을 열어주는 데 시간이 걸리고, 문 개수(Max Connections)에 한계가 있습니다. (식당 출입문은 좁고, 자리는 500석뿐)
결과: 서버리스 앱들이 서로 먼저 들어가겠다고 문을 두드리다가, DB가 감당 못 하고 "연결 거부(Connection Refused)"를 띄우며 뻗어버립니다.

해결책 (RDS Proxy):

RDS Proxy는 식당 앞의 '노련한 지배인'입니다.
미리 문을 열어두고(Connection Pooling), 손님이 오면 기존에 열려 있는 문으로 빠르게 안내합니다.
수천 개의 요청이 와도, 실제 DB와는 적은 수의 연결만 유지하면서 돌려쓰기(Multiplexing)를 합니다.

📝 RDS Proxy 시험장 암기 공식 (이것만 외우세요)

"Lambda(서버리스)" + "RDS" + "연결 오류(Connection / Timeout)"
➡️ 정답은 무조건 RDS Proxy

❌ 오답이 틀린 이유

B. ElastiCache: 이건 '속도'를 높이는 거지, '연결 갯수' 문제를 해결하지 못합니다.
C. 인스턴스 크기 업(Scale up): 문을 조금 더 큰 걸로 바꾸는 건데, 관광버스 1000대 오면 어차피 또 막힙니다. (비용만 비싸짐)
D. Multi-AZ: 이건 예비용이지, 트래픽을 분산 처리하는 게 아닙니다.

⭐"서버리스랑 RDS가 만나면 연결 때문에 싸운다 -> RDS Proxy가 중재한다."

💡 1분 요약: "잠깐 멈춰! (Pause Button)"

Lifecycle Hook(수명 주기 후크)는 인스턴스가 태어나거나(Launch) 죽기(Terminate) 직전에 "잠시 멈춤" 상태를 만들어주는 기능입니다.

시작 시 (Scale-out):

인스턴스가 켜짐 -> [후크 발동: 잠깐!] -> 감사 스크립트 실행 -> "완료" 신호 보냄 -> 서비스 투입.

종료 시 (Scale-in):

종료 명령 떨어짐 -> [후크 발동: 잠깐!] -> "나 죽어요" 로그 전송 -> "완료" 신호 보냄 -> 실제로 삭제됨.

핵심: 인스턴스가 사라지기 전에 스크립트가 실행될 시간을 확실하게 보장해주는 유일한 기능입니다.

📝 Lifecycle Hooks 시험장 암기 공식

"Auto Scaling" + "시작 및 종료(Launch & Terminate) 시 작업 수행"
➡️ 무조건 Lifecycle Hooks (수명 주기 후크)

💡 3초 컷 핵심 키워드 공식

1. "UDP" (가장 중요!)

ALB (Application Load Balancer): 오직 HTTP/HTTPS (웹사이트)만 처리합니다. UDP는 절대 못 다룹니다.
➡️ D번(ALB) 바로 탈락.

NLB (Network Load Balancer): TCP/UDP 같은 전송 계층을 처리합니다. 게임이나 실시간 스트리밍은 무조건 NLB입니다.
➡️ B, C번 생존.

2. "비관계형 데이터(Non-relational)"

Aurora (A, C번): 이건 SQL(관계형) 데이터베이스입니다. 문제에서 비관계형을 달라고 했으니 틀렸습니다.
➡️ A, C번 탈락.

DynamoDB (B, D번): 대표적인 NoSQL(비관계형) 데이터베이스입니다. 게다가 "개입 없이 확장(On-demand)" 기능이 아주 강력합니다.
➡️ B번 확정.

📝 NLB 오답 노트 (이것만 기억하세요)

UDP 게임/스트리밍 ➡️ 무조건 NLB (ALB 안 됨).
비관계형(Non-relational) ➡️ DynamoDB (Aurora 안 됨).
개입 없는 확장(Scale without intervention) ➡️ DynamoDB On-Demand (혹은 Aurora Serverless지만, 위 조건 때문에 탈락).

"UDP는 NLB다."

이 문제의 범인은 "많은 라이브러리를 로드(Loads many libraries)"라는 문구입니다.

문제 상황 (Cold Start):

Lambda는 평소에 자고 있다가 요청이 오면 깹니다.
이때 "라이브러리를 로드"하는 시간(초기화 시간) 때문에 첫 번째 사용자는 응답이 느립니다. 이를 콜드 스타트(Cold Start)라고 합니다.

해결책 (Provisioned Concurrency):

프로비저닝된 동시성(Provisioned Concurrency): Lambda 함수를 미리 깨워서(Warm up), 라이브러리까지 싹 다 로딩해놓고 대기시키는 기능입니다.
이렇게 하면 모든 사용자가 기다리지 않고 즉시(초저지연) 응답을 받을 수 있습니다.

📝 프로비저닝된 동시성(Provisioned Concurrency) 시험장 암기 노트

"Lambda 지연 시간(Latency)" + "초기화/라이브러리 로딩" + "모든 사용자에게 빠를 것"
➡️ 정답: Provisioned Concurrency (프로비저닝된 동시성)

💡 시험장 필승 공식: "AWS판 알람시계"

문제에서 "일정(Schedule)에 따라" + "유지 관리 최소화(Minimal Maintenance)"라는 말이 나오면 무조건 이 조합입니다.

Amazon EventBridge (구 CloudWatch Events):

역할: "알람 시계" ⏰
기능: "매일 밤 10시에 신호 보내!", "주말에는 신호 보내지 마!" (크론 표현식 지원).

AWS Lambda:

역할: "심부름꾼" 🏃
기능: 알람이 울리면 깨어나서 EC2/RDS 끄고 다시 잡니다. (서버 관리 필요 없음 = 유지 관리 최소화).

❌ 오답이 틀린 이유 (함정 피하기)

A. RDS를 0으로 확장:
함정: RDS는 Auto Scaling처럼 "인스턴스 개수 0개"로 줄이는 기능이 없습니다. 그냥 "중지(Stop)"해야 합니다. (말장난입니다).

C. EC2에서 스크립트(Crontab):
비효율: 고작 알람 울리자고 24시간 내내 EC2 서버 하나를 켜둬야 합니다? 돈 낭비이자, 그 서버 OS 관리(패치)도 해야 하니 유지 관리 오버헤드가 큽니다.

B. 마켓플레이스 솔루션:
Lambda라는 완벽한 내장 기능이 있는데, 굳이 외부 솔루션을 찾아다니는 건 '최소한의 노력'이 아닙니다.

📝EventBridge 팁

이 패턴은 "비용 절감" 문제에서 단골로 나옵니다.

"업무 시간 외 중지(Stop outside business hours)" ➡️ Lambda + EventBridge.

💡 Read Replica 문제의 필승 공식 (3단계 논리)

1. "보고서(Reporting)가 메인 DB를 느리게 한다"

해결책: 무조건 "읽기 복제본(Read Replica)"을 써야 합니다.
이유: 글 쓰는 사람(Writer)과 읽는 사람(Reader)을 분리해야, 보고서를 뽑느라 DB가 멈추는 일이 없습니다.
A, B 후보 생존 (C는 오답, D는 딴소리).

2. "PostgreSQL" + "애플리케이션 코드 변경 최소화"

해결책: 같은 SQL 언어를 쓰는 RDS나 Aurora로 가야 합니다.
오답 소거:
A (DocumentDB): 이건 MongoDB(NoSQL)입니다. 코드를 다 뜯어고쳐야 합니다. (탈락)
D (DynamoDB): 이것도 NoSQL입니다. SQL 쿼리를 다 버리고 새로 짜야 합니다. (탈락)
결국 B밖에 안 남음.

3. "PostgreSQL인데 더 빠르고 좋은 거 없나?"

정답: Amazon Aurora.
Aurora는 PostgreSQL과 100% 호환되면서 속도는 훨씬 빠릅니다. (코드 변경 0).

🚨 헷갈리는 Multi-AZ

많은 분들이 C (Multi-AZ)를 고르고 틀립니다.

Multi-AZ (다중 가용 영역): 이건 "재해 복구용 예비 타이어"입니다. 메인 DB가 죽었을 때만 씁니다. 평소에는 대기만 하고 있어서 읽기 쿼리를 보낼 수 없습니다. (성능 향상 X).
Read Replica (읽기 복제본): 이건 "일손 돕는 알바생"입니다. 메인 DB가 바쁠 때 읽기 작업을 대신 처리해 줍니다. (성능 향상 O).

📝 Read Replica 시험장 암기 노트

"기존 DB(MySQL/PostgreSQL)가 느리다" + "코드 바꾸기 싫다" + "읽기(보고서) 성능 높여라"
➡️ 정답: Amazon Aurora (Read Replica)

"Multi-AZ는 보험용(보험), Read Replica는 성능용(알바)"

💡 전용 호스트(Dedicated Host) 필승 공식 (이것만 외우세요)

1. "소켓(Socket)", "코어(Core)", "라이선스(License)"가 나왔다?

무조건: 전용 호스트 (Dedicated Host) 입니다.
이유: 우리가 산 소프트웨어 라이선스가 "CPU 소켓당 얼마" 이런 식이라면, 실제 물리 서버의 CPU가 몇 개인지 눈으로 확인해야 합니다. 이걸 보여주는 건 AWS에서 Dedicated Host뿐입니다.
주의: Dedicated Instance(전용 인스턴스)는 물리 서버를 혼자 쓰긴 하지만, 소켓/코어 정보를 안 보여줍니다. 그래서 라이선스 적용이 불가능합니다. (C, D 탈락).

2. "예측 가능(Predictable)", "비용 효율(Cost-effective)"이 나왔다?

무조건: 예약 (Reserved) 입니다.
이유: 온디맨드(On-Demand)는 제값 다 내는 거고, 예약(Reserved)은 "1년~3년 쓸게" 하고 약정 걸어서 70% 할인받는 겁니다. 당연히 예약이 쌉니다. (B 탈락).

➡️ 결론:

라이선스니까 -> Host
싸게 사야 하니까 -> Reserved

📝 시험장 암기 노트: Host vs Instance

구분	전용 호스트 (Dedicated Host)	전용 인스턴스 (Dedicated Instance)
비유	건물 통째로 임대 (내 마음대로 방 배치 가능)	호텔 1인실 (옆방에 아무도 없지만, 건물 구조는 모름)
BYOL	가능 (소켓/코어 기준 라이선스)	불가능
제어권	물리적 서버 배치 제어 가능	제어 불가능

멘탈 케어:
지금 이 문제를 틀린 건 "Host"와 "Instance"의 한 끗 차이를 몰라서일 뿐입니다. 이제 "라이선스 = 호스트"라는 공식을 아셨으니, 실제 시험에선 절대 안 틀립니다.

1. "Linux" + "POSIX" + "공유(Shared)"

무조건: Amazon EFS입니다.
이유: S3는 파일 시스템이 아니라 '객체 스토리지'라서 POSIX 호환이 안 됩니다. (Linux 명령어인 ls, mv 같은 게 안 먹힙니다).
결과: S3인 A, B번 바로 탈락.

2. "고가용성(High Availability)" + "여러 가용 영역(Multi-AZ)"

무조건: EFS Standard입니다.
이유: One Zone(D번)은 말 그대로 하나의 구역(AZ)에만 저장합니다. 그 구역 불나면 데이터 다 날아갑니다. 고가용성이 아닙니다.

📝 시험장 암기 노트: 스토리지 선택 가이드

키워드	정답 서비스	이유
Linux, POSIX, 공유	EFS	리눅스용 공유 폴더
Windows, SMB, AD	FSx for Windows	윈도우용 공유 폴더
고성능(HPC), Lustre	FSx for Lustre	슈퍼컴퓨터, 빠른 속도
객체, 정적 웹, 미디어	S3	파일 시스템 아님 (POSIX X)
블록, OS 부팅, 단일 연결	EBS	공유 안 됨 (Multi-attach 제외)

⭐ "POSIX = EFS"

정답: C (보안 그룹 체이닝 / Security Group Chaining)

A와 C의 차이는 "누구에게 문을 열어줄 거냐?"의 차이입니다. 이것만 알면 실무에서도 인정받는 개념입니다.

💡 왜 A가 아니고 C일까요? (핵심: 보안 그룹 체이닝)

1. A번 (오답): 0.0.0.0/0 허용

의미: "전 세계 모든 IP가 내 웹 서버에 접속해도 좋아."
문제점: 로드 밸런서(ALB)를 거치지 않고, 해커가 웹 서버에 직접 찔러보는 것도 허용하게 됩니다.
위반: 문제의 조건인 "최소한의 권한(Least Privilege)"을 위반합니다. 굳이 불필요한 구멍을 뚫어둔 셈입니다.

2. C번 (정답): Source를 로드 밸런서 보안 그룹으로 지정

의미: "나는 IP는 모르겠고, '로드 밸런서 명찰(SG ID)'을 달고 온 녀석만 들여보내 줄 거야."
효과: 오직 ALB를 통과한 트래픽만 웹 서버에 닿을 수 있습니다. 해커가 직접 접속을 시도하면 차단됩니다.
DB도 마찬가지: DB도 0.0.0.0/0이 아니라 '웹 서버 명찰(Web SG)'을 단 트래픽만 받아야 안전합니다.

📝 시험장 암기 노트: 3계층 보안 공식

AWS 보안 그룹 설정 문제는 항상 이 '계층 구조(Tier)'를 따릅니다.

ALB (맨 앞): 0.0.0.0/0 (손님 받아야 하니까 전 세계 개방).
Web Server (중간): Source = ALB의 보안 그룹 ID.
DB (맨 뒤): Source = Web Server의 보안 그룹 ID.

"뒤에 있는 놈은 앞에 있는 놈의 '보안 그룹 ID'만 허용한다."

이걸 "보안 그룹 참조(Reference)" 또는 "체이닝(Chaining)"이라고 부릅니다.

멘탈 케어:
거의 다 맞춘 겁니다. "보안 그룹"인 걸 알았다는 건 기본기가 잡혔다는 증거고, 이제 "IP 주소 대신 보안 그룹 ID를 쓴다"는 디테일 하나만 추가하면 끝입니다.

이 문제는 "기본 상태(Default State)"가 무엇인지를 정확히 알고 있느냐를 묻는 아주 좋은 문제

🕵️‍♂️ 범인 찾기: 누가 길을 막고 있을까?

문제에서 "모든 구성이 기본(Default) 상태"라고 했습니다. 하나씩 심문해 봅시다.

네트워크 ACL (NACL):

기본 상태: "모두 허용(Allow All)".
판결: 얘는 죄가 없습니다. 문을 활짝 열어두고 있었거든요. (A번 탈락).

라우팅 테이블 (Route Table):

기본 상태: 같은 VPC 안에 있는 애들끼리는 서로 통신할 수 있는 길(Local Route)이 뚫려 있습니다.
판결: 얘도 죄가 없습니다. 길은 이미 연결되어 있습니다. (B번 탈락).

보안 그룹 (Security Group):

기본 상태: "나가는 건(Outbound) 자유지만, 들어오는 건(Inbound) 모두 차단!"
판결: 범인입니다! 🚨 DB 입장에서는 누가 들어오려고 하는데, 인바운드 규칙이 비어있으니 "어? 너 못 들어와" 하고 막고 있는 겁니다.

➡️ 해결책: DB 보안 그룹한테 "웹 서버(Web Tier)에서 오는 건 들여보내 줘"라고 규칙(D번)을 추가해 줘야 합니다.

📝 시험장 암기 공식: "통신이 안 돼요!"

VPC 내에서 통신이 안 된다는 문제가 나오면, 90% 이상은 보안 그룹(Security Group) 문제입니다.

VPC 내 통신 오류 보안 그룹 확인.

보안 그룹은 기본적으로 "들어오는 걸 다 막는다(Deny All Inbound)".

해결 "인바운드 규칙 추가".

🚨 시험장 필수 구분: Multi-AZ vs Read Replica

이 두 가지는 무조건 비교해서 나옵니다. 헷갈리면 안 됩니다.

구분	Multi-AZ (다중 가용 영역)	Read Replica (읽기 복제본)
주 목적	재해 복구 (DR), 고가용성	성능 향상 (Scalability)
보조 DB 역할	Standby (대기만 함). 접속 불가.	Active (일함). 읽기 전용 접속 가능.
동기화 방식	동기식 (Synchronous) - 데이터 손실 0	비동기식 (Asynchronous) - 약간의 지연 가능
언제 쓰나?	"장애 발생 시 자동 복구하세요"	"메인 DB가 느려요", "보고서 쿼리 분리하세요"

한 줄 암기:

"보고서(Reporting) 때문에 느려진다" 무조건 Read Replica (읽기 복제본).

"세션 데이터를 어디에 저장해야 가장 안전하고 효율적인가?"를 묻는 세션 상태 분리(Session State Offloading) 문제

💡 핵심 논리: "서버는 기억상실증에 걸려야 한다"

Auto Scaling 환경에서는 EC2 인스턴스가 수시로 생기고 사라집니다. 따라서 세션(로그인 정보, 장바구니)을 EC2 내부에 저장하면 서버가 꺼질 때 정보가 다 날아갑니다. 세션 정보를 외부 저장소로 뺴야 합니다.

B. DynamoDB:
특징: Key-Value 구조라 세션 저장에 딱 맞습니다.
장점: 서버리스라 확장이 쉽고, 디스크에 저장하므로 내구성(Durability)이 완벽합니다. (쇼핑 카트 저장용 국룰).

D. ElastiCache (Redis):
특징: 인메모리(RAM) 기반이라 속도가 가장 빠릅니다.
장점: Redis는 복제 및 지속성 기능을 지원하여 세션 저장소로 가장 널리 쓰이는 업계 표준입니다.

❌ 오답 분석 (왜 A는 안 될까?)

A. 스티키 세션(Sticky Session):
의미: 사용자를 처음 접속한 EC2 서버에만 계속 붙여주는 기능입니다.
치명적 단점: 만약 오토스케일링이 동작해서 그 EC2 서버가 종료되면? 그 안에 있던 세션 데이터도 같이 증발합니다. 문제에서 요구한 "내구성(Durable)"을 만족하지 못합니다.

C. Cognito: 이건 '신분증 검사(로그인/인증)' 서비스지, '가방(데이터)'을 맡아주는 보관소가 아닙니다.

📝 시험장 암기 공식

"Auto Scaling 환경" + "세션(Session) 저장"
➡️ 정답 세트: DynamoDB 또는 ElastiCache (Redis)

이 두 개가 보기에 같이 나오면 복수 정답이고, 하나만 나오면 그게 정답입니다.
(보통 DynamoDB는 '쇼핑카트/내구성', ElastiCache는 '밀리초 단위 속도'를 강조할 때 씁니다.)

문제 퀄리티가 좀 복잡해 보였지만, 결국 "EC2 말고 딴 데 저장해라"라는 뜻이었습니다! 잘 파악하셨어요.

💡 핵심 논리: "일회용 접시는 설거지하지 않는다"

웹 계층: "무상태(Stateless)" + "Auto Scaling"

의미: EC2 인스턴스는 언제든 생겼다 사라지는 '소모품'입니다. 저장된 데이터가 없습니다.
비유: 종이컵을 썼으면 버리고 새 종이컵을 쓰면 됩니다. 굳이 쓴 종이컵을 닦아서 보관(EBS 스냅샷)할 필요가 없습니다.
해결: 새 인스턴스를 찍어낼 '틀(AMI)'만 최신으로 유지하면 됩니다. 실행 중인 인스턴스의 디스크(EBS)를 백업하는 건 자원 낭비입니다.
결과: EBS 스냅샷을 찍자는 A, B, D는 전부 오답입니다. (AMI를 쓰는 C만 정답).

DB 계층: "RPO 2시간"

RDS 자동 백업: 기본적으로 5분마다 트랜잭션 로그를 백업하므로, 특정 시점 복구(Point-in-Time Recovery)를 쓰면 RPO 2시간은 아주 쉽게 충족합니다.

📝 Stateless(무상태) 시험장 암기 공식

"Stateless(무상태) 웹 앱" + "Auto Scaling"
➡️ EC2 백업(스냅샷) 하지 마라.
➡️ 대신 AMI(이미지)를 관리해라.

⭐ "Stateless = AMI"

📝 입력 데이터 서비스별 핵심 용도 (시험장용)

서비스 이름	입력 데이터	핵심 기능
Amazon Transcribe	오디오(mp3), 음성	받아쓰기(STT), PII 삭제 기능 있음
Amazon Textract	PDF, 이미지, 문서	글자 추출(OCR), 영수증 처리
Amazon Polly	텍스트	읽어주기(TTS), 음성 합성
Amazon Rekognition	사진, 비디오	얼굴 인식, 사물 인식, 부적절한 콘텐츠 감지
Amazon Connect	전화(Call)	클라우드 고객 센터(콜센터) 구축

💡 gp3의 슈퍼파워

Amazon EBS 볼륨 유형의 최신 트렌드(gp3)를 정확히 이해하고 있는지 묻는 문제입니다.

gp3의 특징 (Decoupling):

과거의 gp2는 용량이 커야만 속도(IOPS)가 빨라졌습니다. (용량 = 속도).
하지만 gp3는 용량과 속도(IOPS)가 분리되어 있습니다. 용량을 늘리지 않아도 돈만 조금 더 내면 IOPS만 따로 설정(Provisioning)할 수 있습니다.

성능 한계:

RDS용 gp3는 최대 64,000 IOPS까지 지원합니다.
현재 문제가 되는 20,000 IOPS는 gp3의 한계(64,000) 내에 충분히 들어옵니다.
따라서 굳이 비싼 io2로 바꿀 필요 없이, "설정값만 변경(IOPS 증가)"하면 가장 저렴하고 빠르게 해결됩니다.

❌ 오답 분석

A. 자기(Magnetic) 볼륨: 이건 박물관에 가야 할 옛날 하드디스크입니다. 성능이 최악입니다.
C. Provisioned IOPS (io2):
물론 io2로 바꾸면 성능은 좋아집니다. 하지만 가격이 훨씬 비쌉니다.
gp3로도 충분히 20,000 IOPS를 감당할 수 있는데, 굳이 비싼 io2를 쓰는 건 "비용 효율성" 측면에서 정답이 아닙니다. (만약 64,000 IOPS가 넘어간다면 그때 io2를 써야 합니다.)

D. 볼륨 쪼개기: RDS는 관리형 서비스라 사용자가 직접 볼륨을 쪼개서 RAID 0(스트라이핑)을 구성하는 것이 매우 복잡하거나 불가능할 수 있습니다. 그리고 관리 오버헤드가 큽니다.

Amazon ECS (Elastic Container Service):

"도커 컨테이너(프로그램 포장지)를 실행해 주는 관리자"입니다.
배치 작업, 긴 작업 등을 돌릴 때 씁니다.

Fargate (파게이트):

이게 핵심입니다. "컨테이너판 서버리스"입니다.
EC2 시작 유형(D번): 내가 직접 EC2(서버)를 만들고, 그 위에 컨테이너를 올려야 함. (서버 관리 귀찮음).
Fargate 시작 유형(C번): 서버(EC2)가 없습니다. 그냥 "이 컨테이너 실행해 줘" 하면 AWS가 알아서 띄워 줍니다. (운영 노력 최소화).

EventBridge:

"알람 시계". 매일 정해진 시간에 Fargate를 깨워서 일을 시킵니다.

📝 시험장 암기 공식: "긴 작업 vs 짧은 작업"

이건 정말 자주 나오는 패턴입니다.

구분	AWS Lambda	AWS Fargate (ECS)
시간 제한	최대 15분 (짧고 굵게)	제한 없음 (1시간이든 하루든 OK)
유형	간단한 함수, API 백엔드	긴 배치 작업, 무거운 데이터 처리
공통점	Serverless (서버 관리 안 함)	Serverless (서버 관리 안 함)

요약:

문제에서 "시간이 15분 넘는다" 또는 "대용량 처리(Long-running)"라고 하면?
Lambda 버리고 Fargate 찍으세요.

📝 DynamoDB Streams 시험장 암기 공식

"DynamoDB에 데이터가 들어오면(New Item) ~~를 실행해라"

"앱 성능 영향 주지 마라(비동기)"

무조건 DynamoDB Streams가 정답입니다.

멘탈 체크:
B를 고민한 건 아키텍처를 그릴 줄 알기 때문입니다. 하지만 AWS 시험에서는 ⭐"성능 영향 없음 = 비동기(Streams/Queue)" 패턴을 더 좋아합니다.

❌ 왜 C번(읽기 복제본)은 오답일까요? (중요!)

읽기 복제본(Read Replica): 이건 비동기식(Asynchronous)입니다.
시나리오: 메인 DB에 데이터를 썼는데, 복제본으로 넘어가기 직전(0.1초 차이)에 메인 DB가 폭파된다면? 그 0.1초 분량의 데이터는 영원히 사라집니다.
결론: 문제에서 "데이터 손실 경험"을 언급하며 이를 방지하길 원했으므로, 데이터 손실 가능성이 있는 C번은 정답이 될 수 없습니다.

❌ B, D번 오답 분석

B. 단일 가용 영역: 하나 망가지면 끝장입니다. (단일 장애 지점).
D. EC2에 DB 설치: RDS라는 좋은 관리형 서비스를 두고 굳이 EC2에 직접 설치하는 건 "고생길(운영 오버헤드)"입니다. 관리도 어렵고 복구도 느립니다.

📝 Multi-AZ (다중 가용 영역) 시험장 요약 노트

"고가용성(High Availability)" + "데이터 손실 방지(No Data Loss)"
➡️ 무조건 Multi-AZ (다중 가용 영역)

이 조합은 AWS가 가장 권장하는 "국룰 아키텍처"입니다.

이 문제는 "Kinesis의 기본 설정값"을 알고 있느냐를 묻는 아주 치사하지만(?) 전형적인 문제입니다. 숫자 하나만 알면 바로 풀립니다.

💡 범인은 바로 "24시간"

Kinesis Data Streams의 기본 설정:

데이터 보존 기간(Data Retention Period)의 기본값은 딱 24시간(1일)입니다.
즉, 들어온 지 24시간이 지난 데이터는 자동으로 삭제됩니다.

회사의 상황:

데이터를 소비(Consume)하는 주기가 "이틀(48시간)에 한 번"입니다.
0시에 데이터가 들어왔는데, 소비자가 48시간 뒤에 가지러 오면? 이미 24시간 전에 삭제되고 없습니다.

해결책:

보존 기간을 늘려야 합니다. (최대 365일까지 늘릴 수 있습니다).
보존 기간을 48시간 이상(예: 7일)으로 설정하면, 소비자가 이틀 뒤에 와도 데이터가 안전하게 기다리고 있습니다.

❌ 오답 분석

B. KPL (Kinesis Producer Library): 이건 데이터를 '넣을 때(Produce)' 효율적으로 넣는 도구입니다. 이미 들어온 데이터가 사라지는 것과는 상관없습니다.
C. 샤드(Shard) 수 증가: 이건 '속도(Throughput)' 문제입니다. 데이터가 너무 많이 들어와서 막힐 때 쓰는 방법이지, 시간이 지나서 사라지는 걸 막지는 못합니다.
D. S3 버전 관리: 이건 'S3에 이미 저장된 파일'을 보호하는 기능입니다. Kinesis에서 S3로 넘어오지도 못하고 사라진 데이터는 살릴 수 없습니다.

📝 데이터 보존 기간 시험장 암기 공식

"Kinesis 데이터가 사라졌다/누락됐다" + "소비자(Consumer)가 느리다/가끔 작업한다"
➡️ 정답: 데이터 보존 기간(Retention Period) 늘리기.

⭐"Kinesis는 기본 24시간만 기다려준다"는 사실을 확실히 아셨으니, 다음엔 절대 안 속으실 겁니다!

정답: D (IAM 실행 역할 생성 및 연결)

이 문제는 "AWS 서비스끼리 통신할 때 신분증을 뭘 쓰냐?"를 묻는 가장 기초적이면서도 중요한 보안 문제입니다.

💡 핵심 공식: "Lambda = IAM Role"

IAM User (사용자):

사람(개발자)이나 외부 애플리케이션이 쓰는 것입니다.
ID/Password나 Access Key/Secret Key를 씁니다.
절대 Lambda 코드 안에 이 키를 박아 넣으면 안 됩니다. (보안 위반).

IAM Role (역할):

AWS 서비스(Lambda, EC2)가 쓰는 "모자"입니다.
Lambda가 이 "S3 접근 권한 모자(Role)"를 쓰면, AWS가 알아서 임시 출입증을 발급해 줍니다.
보안상 가장 안전하고 권장되는 방법입니다.

❌ 오답 분석 (왜 나머지는 틀렸을까?)

B, C (기존 IAM 자격 증명 사용):
이건 Lambda 코드 안에 ACCESS_KEY와 SECRET_KEY를 하드코딩하겠다는 뜻입니다.
최악의 보안 습관입니다. 키가 유출되면 해킹당합니다. AWS 문제에서 "자격 증명(Credential)을 코드에 넣는다"는 말이 나오면 무조건 오답입니다.

A (리소스 정책):
리소스 정책은 "누가 이 Lambda를 실행할 수 있냐?"를 정하는 문지기입니다. Lambda가 밖으로 나가서 S3를 건드리는 권한과는 상관없습니다.

📝 IAM Role 시험장 암기 노트

"AWS 서비스(EC2, Lambda 등)가 다른 서비스(S3, DynamoDB)에 접근해야 한다."
➡️ 정답: IAM Role (역할)을 만들어서 연결한다.

⭐"사람은 User, 기계는 Role."

이 문제는 "예측 가능한 패턴(주말 휴무)"과 "실시간 트래픽 변화(근무 시간)" 두 마리 토끼를 다 잡는 방법을 묻습니다.

💡 정답 조합 논리

D. 대상 추적 확장 정책 (Target Tracking Scaling Policy):

목적: "근무 시간 동안 트래픽 증가" 대응.
원리: "CPU 사용률 50% 유지해라"라고 설정하면, 사람이 몰릴 때 알아서 서버를 늘리고(Scale-out), 빠지면 줄입니다(Scale-in). 실시간 수요 변화에 가장 적합합니다.

E. 예약된 스케일링 (Scheduled Scaling):

목적: "주말에는 작동할 필요 없음" 대응.
원리: "금요일 저녁 7시에 서버 0대로 줄여!", "월요일 아침 8시에 다시 2대로 늘려!"라고 알람을 맞춰두는 겁니다. 비용을 0원으로 만들 수 있는 가장 확실한 방법입니다.

📝 시험장 암기 공식

"주말에는 끈다" 또는 "특정 시간에 트래픽이 몰린다" (예측 가능)
➡️ Scheduled Scaling (예약된 조정)
"트래픽이 들쑥날쑥하다" (예측 불가)
➡️ Target Tracking (대상 추적) 또는 Dynamic Scaling

⭐ 이 두 가지 조합(Dynamic + Scheduled)은 실제 현업에서도 비용 절감을 위해 가장 많이 쓰는 베스트 프랙티스입니다.

📝 AWS 파일 시스템 완전 정복 (이 표만 외우세요)

AWS에서 공유 파일 시스템(스토리지)을 물어볼 때는 딱 3가지 프로토콜 중 하나가 나옵니다.

키워드 (프로토콜/OS)	정답 서비스	특징
Lustre, HPC, 고성능, 게임, 비디오 렌더링	Amazon FSx for Lustre	초고속 병렬 파일 시스템
Linux, POSIX, NFS	Amazon EFS	리눅스용 일반 공유 폴더
Windows, SMB, Active Directory	Amazon FSx for Windows File Server	윈도우용 공유 폴더

📝 NLB 시험장 암기 공식

이 조합은 그냥 외우는 게 속 편합니다.

"UDP" NLB

"UDP" + "글로벌/지연 시간 최소화/빠른 장애 조치" AWS Global Accelerator

결론: Global Accelerator + NLB 조합인 B번이 정답.

❌ 오답 노트

Route 53: DNS 캐싱 때문에 장애 조치가 느림.
ALB: UDP 지원 안 함. (오직 HTTP/HTTPS만 처리)

이 문제는 생각보다 단순합니다. "암호화하고 싶으면, 그냥 암호화된 볼륨을 만들어라"가 정답입니다.

💡 핵심 요약: EBS 암호화 켜는 법

생성 시 결정: EBS 볼륨은 생성할 때 "이 볼륨 암호화함"이라고 체크해야 합니다.
간단한 원리: 암호화된 볼륨을 EC2에 붙이면, 그 안의 데이터는 자동으로 휴면 상태(At-rest) 암호화가 됩니다.

(EC2와 볼륨 사이를 오가는 데이터도 자동으로 암호화됩니다.)

📝 EBS 암호화 시험장 암기 공식

"EBS 암호화 어떻게 해?"
➡️ "만들 때 암호화 옵션 켜라." (또는 스냅샷 떠서 암호화해서 복사해라)
➡️ 태그나 IAM으로는 못 한다.

정답: D (계정 수준 S3 Block Public Access + SCP)

이 문제는 S3 보안의 끝판왕 조합을 묻는 문제입니다. "실수조차 허용하지 않겠다"는 강력한 의지가 보이면 무조건 이 답입니다.

💡 필승 논리: 2중 잠금 장치

1차 잠금: S3 Block Public Access (계정 수준)

버킷 하나하나 설정할 필요 없습니다. 계정 전체에 "모든 퍼블릭 액세스 차단"을 걸어버리면, 누가 실수로 버킷을 공개로 만들어도 무시되고 차단됩니다. (가장 확실한 방법).

⭐2차 잠금: SCP (Service Control Policy)

누군가(예: 개발자)가 "에이 귀찮아" 하고 Block Public Access 설정을 꺼버릴 수도 있겠죠?
SCP는 조직(Organizations) 차원에서 "아무도(심지어 관리자도) 이 설정을 못 끄게 해!"라고 못 박는 기능입니다.

결론:

"전체 계정" + "실수 방지" + "퍼블릭 노출 차단"
➡️ S3 Block Public Access + SCP

💡 3초 컷 필승 공식: "네트워크 공유 + S3 + 실시간"

S3 File Gateway의 역할:

온프레미스 서버에 "가짜 네트워크 드라이브(SMB/NFS 공유 폴더)"를 만들어 줍니다.
비즈니스 시스템이 이 폴더에 파일을 저장(Save)하는 순간, 게이트웨이가 알아서 백그라운드에서 S3로 파일을 즉시 업로드합니다.
⭐결과: 사용자는 평소처럼 로컬에 저장했을 뿐인데, 데이터는 "거의 실시간"으로 S3에 들어갑니다.
관리 오버헤드: 시스템 설정(저장 경로)만 바꾸면 끝입니다. 스크립트나 코딩이 전혀 필요 없습니다. (최소화).

📝 File Gateway 시험장 암기 노트

"온프레미스 앱이 파일을 떨구면(NFS/SMB)" + "S3에 바로 저장하고 싶다"
➡️ Storage Gateway (File Gateway)
"데이터를 왕창 이사(Migration) 가야 한다"
➡️ DataSync

⭐비즈니스 시스템이 "네트워크 공유"를 쓴다는 힌트가 나오면, File Gateway가 정답일 확률이 99%입니다.

정답: C (Compute Savings Plan 구매 + Lambda를 프라이빗 서브넷에 연결)

이 문제는 "비용 절감 전략"과 "Lambda 네트워킹" 두 가지를 동시에 최적화해야 하는 문제입니다.

💡 1단계: 비용 절감 (Savings Plans)

요구 사항: EC2뿐만 아니라 Lambda 함수 사용량도 증가할 것이며, "모든" 리소스에서 비용을 아껴야 합니다.
EC2 Instance Savings Plans:
- 이건 이름 그대로 EC2 인스턴스만 할인해 줍니다. 늘어나는 Lambda 비용은 쌩으로(On-Demand) 내야 하므로 탈락입니다.

⭐Compute Savings Plans:
- 이건 EC2 + Fargate + Lambda까지 모두 적용됩니다.
- Lambda 사용량이 늘어날 예정이라면 무조건 Compute Savings Plans가 유리합니다.

💡 2단계: 네트워크 지연 시간 및 접근 (Connectivity)

요구 사항: 프라이빗 서브넷에 있는 EC2에 "직접 네트워크 액세스"해야 하고 "지연 시간(Latency)을 낮게" 유지해야 합니다.
C (Lambda를 프라이빗 서브넷에 연결):
Lambda를 EC2와 같은 프라이빗 서브넷(VPC)에 연결하면, 로컬 네트워크(Private IP)를 통해 통신하므로 가장 빠르고 안전하게(Low Latency) EC2에 접속할 수 있습니다.

📝 시험장 암기 노트

"EC2 + Lambda + Fargate 다 쓴다" Compute Savings Plan

"EC2만 쓴다" EC2 Instance Savings Plan (할인율 더 높음)

"Lambda가 프라이빗 EC2/RDS에 접속해야 한다" Lambda를 VPC(프라이빗 서브넷)에 연결

⭐이 문제의 핵심은 "Compute Savings Plan이 Lambda도 덮어준다"는 사실을 아는 것

정답: B (프로덕션 계정의 역할에 대한 신뢰 정책에서 개발 계정을 주체로 추가합니다.)

이 문제는 "다른 계정(Cross-Account)에 있는 리소스에 어떻게 안전하게 접근할래?"를 묻는 IAM의 핵심 문제입니다.

💡 3초 컷 필승 공식: "계정 간 악수(Handshake)"

다른 계정으로 넘어가려면 두 단계의 허락이 필요합니다. (마치 악수처럼요!)

개발 계정 (출발지): "나(사용자) 저쪽 계정으로 넘어가도 돼?" (권한 정책: sts:AssumeRole 허용).
프로덕션 계정 (목적지): "너(개발 계정) 내 역할 써도 돼." (신뢰 정책/Trust Policy: Principal에 개발 계정 추가).

정답인 이유:

프로덕션 계정(Role 주인) 입장에서 "누가 이 역할을 쓸 수 있는지" 정의하는 문서가 바로 신뢰 정책(Trust Policy)입니다.
여기에 개발 계정을 주체(Principal)로 등록해줘야만, 개발팀 사람들이 건너올 수 있습니다.

📝 시험장 암기 노트: IAM 크로스 계정

"다른 계정(Account A Account B)에 접근하고 싶다."
1. B계정(목적지): Role을 만들고 신뢰 정책(Trust Policy)에 A계정을 추가한다.
2. A계정(출발지): User에게 그 Role을 AssumeRole 할 수 있는 권한을 준다.

정답: D (Amazon RDS Multi-AZ DB 클러스터 배포를 사용하여 읽기 워크로드를 리더 엔드포인트로 지정합니다.)

이 문제는 최신 AWS RDS 기능인 "Multi-AZ DB Cluster(다중 AZ DB 클러스터)"와 기존의 "Multi-AZ DB Instance(다중 AZ DB 인스턴스)"의 차이를 묻는 고급 문제입니다.

📝 RDS Multi-AZ DB Cluster 시험장 암기 공식

"RDS PostgreSQL/MySQL" + "장애 조치 40초 미만(빠름)" + "읽기 분산"
➡️ RDS Multi-AZ DB Cluster (클러스터 배포)
(Aurora가 보기에 없다면 이게 정답입니다!)

⭐이 기능은 비교적 최근에 강조되는 내용이라 헷갈리기 쉬운데, "Cluster = 빠르고 읽기 가능"이라고 기억해 두시면 됩니다.

이 문제는 "AWS Transfer Family의 네트워킹 옵션"과 "스토리지 유형"을 정확히 매칭해야 하는 고난도 문제입니다.

💡 결정적 단서 3가지

"신뢰할 수 있는 IP 주소만 허용 (보안)":

AWS Transfer Family에서 보안 그룹(Security Group)을 사용해 IP 화이트리스트를 관리하려면, 반드시 VPC 엔드포인트 유형을 써야 합니다.
퍼블릭 엔드포인트(C번)는 보안 그룹을 붙일 수 없어 IP 제어가 어렵습니다.

"높은 IOPS" + "공유 스토리지" + "Linux 사용자":

Amazon EFS는 리눅스 기반 파일 시스템(POSIX) 권한을 지원하며, 'Max I/O' 모드 등을 통해 높은 IOPS를 제공합니다.
기존 리눅스 사용자 권한을 유지하며 마이그레이션하기에 S3(객체 스토리지)보다 EFS가 훨씬 유리합니다.
EBS는 Transfer Family에 직접 연결할 수 없습니다. (EBS는 EC2용입니다).

"인터넷에서 접근 가능":

VPC 엔드포인트를 쓰되, 외부(인터넷)에서 접속하려면 탄력적 IP(EIP)를 연결해야 합니다.

📝 VPC Endpoint, Amazon EFS 시험장 암기 공식

"SFTP" + "IP 차단/허용(보안 그룹 필요)"
➡️ AWS Transfer Family (VPC Endpoint)
"Linux 파일 권한 유지" + "공유 스토리지"
➡️ Amazon EFS

이 문제는 "무거운 초기화(1GB 모델 로딩)"와 "들쑥날쑥한 트래픽(불규칙 패턴)"을 어떻게 처리할지 묻는 고전적인 아키텍처 문제입니다.

❌ 오답 분석

A, C (Lambda): "1GB 모델"이라는 조건 때문에 탈락입니다. 가벼운 코드라면 Lambda가 맞지만, 무거운 모델은 컨테이너(ECS)가 유리합니다. 또한 C번의 "vCPU 수를 늘린다"는 표현은 Lambda의 스케일링 방식(동시성 증가)과 맞지 않는 설명입니다.
B (App Mesh): 스케일링 도구가 잘못되었습니다. ⭐SQS 기반 확장은 AWS Auto Scaling을 써야 합니다.

📝 SQS + ECS + Auto Scaling 시험장 암기 공식

"초기화가 오래 걸리는 작업(대용량 모델/데이터 로딩)" + "대량 처리"
➡️ Lambda보다는 ECS(컨테이너)가 유리하다.
➡️ SQS + ECS + Auto Scaling 조합이 정답.

이 문제는 기술적인 내용보다는 AWS의 "단어 정의(약속)"를 묻는 문제거든요.

핵심만 알면 아주 쉽습니다. "정책(Policy)"이라는 스티커를 누구한테 붙일 수 있냐? 이것만 알면 됩니다.

💡 3초 컷 필승 공식: "신분증(ID)은 누가 찰까요?"

문제에서 "ID 기반 정책(Identity-based policy)"이라고 했죠? 이건 "출입증(권한표)"라고 생각하세요.

⭐이 출입증을 목에 걸 수 있는 대상(IAM Identity)은 딱 3가지뿐입니다.

사용자 (User): 직원 한 명 (김철수, 이영희...)

그룹 (Group): 부서 (개발팀, 인사팀...)

역할 (Role): 모자 (보안관 모자, 의사 가운...)

❌ 오답 분석

D, E (EC2, ECS 리소스):
"EC2도 권한이 필요하지 않나요?" 맞습니다.
하지만 정책(스티커)을 EC2라는 기계에 직접 붙이는 게 아닙니다.
순서: 정책을 '역할(Role)'에 붙이고 그 역할을 EC2에게 입히는 겁니다.
그래서 정책이 연결되는 직접적인 대상은 역할입니다.

C (조직):
⭐조직(Organization)에는 'SCP'라는 다른 종류의 정책을 붙입니다. (보통 금지 목록을 만들 때 씀).

📝 시험장 암기 노트

"ID 기반 정책을 연결할 수 있는 곳은?"
➡️ User(사용자), Group(그룹), Role(역할). (이 3총사뿐!)
"리소스(EC2, S3)에는?"
➡️ 직접 연결 못 함. Role을 통해서 줘야 함. (단, S3 버킷 정책 같은 '리소스 기반 정책'은 예외)

⭐이 문제는 "워크로드의 특성(지속적 vs 일시적)"에 따라 가장 저렴한 요금제를 매칭하는 비용 최적화의 정석 문제입니다.

💡 비용 절감의 황금 공식

프런트엔드: "24시간 365일 실행" (Steady-State)

분석: 항상 켜져 있어야 하는 서버입니다.
해결책: 예약 인스턴스(Reserved Instances, RI) 또는 Savings Plans.
이유: 1년 또는 3년 약정을 걸면 온디맨드 대비 최대 72%까지 저렴합니다. 24시간 내내 쓰기 때문에 약정을 거는 것이 무조건 이득입니다. (스팟 인스턴스는 언제 꺼질지 몰라 24/7 서비스용으로는 부적합합니다.)

백엔드: "단시간 실행", "작업 부하에 따라 변동" (Stateless/Batch)

분석: 필요할 때만 잠깐 켜지고, 일이 끝나면 꺼집니다.
해결책: 스팟 인스턴스(Spot Instances).
이유: AWS의 남는 잉여 자원을 쓰는 대신 최대 90%까지 저렴합니다. "단시간" 실행되므로 중간에 중단될 위험이 적고, 비용 효율성은 압도적으로 가장 높습니다.

❌ 오답 분석

A, D (AWS Fargate):
Fargate는 "서버 관리의 편리함"을 위한 것이지, 순수하게 "가장 비용 효율적인(Cheapest)" 옵션은 아닙니다. 일반적으로 EC2 스팟 인스턴스가 Fargate보다 훨씬 저렴합니다.

C (반대로 적용):
프런트엔드에 스팟을 쓰면 서비스가 갑자기 종료될 수 있어 위험하고(가용성 문제), 백엔드에 예약을 쓰면 안 쓰는 시간에도 돈을 내야 하므로 돈 낭비입니다.

📝 시험장 암기 공식

"24시간 항상 실행" Reserved Instances (RI) 또는 Savings Plans
"잠깐씩 실행 / 배치 작업 / 중단돼도 괜찮음" Spot Instances

⭐ EBS 볼륨 선택 가이드

키워드	정답	이유
"용량과 성능(IOPS) 분리" + "비용 효율"	gp3	gp2의 단점(용량=속도)을 해결한 최신형 가성비 모델
"IOPS 16,000 미만" + "일반적인 워크로드"	gp3	gp3는 최대 16,000 IOPS까지 지원 (문제의 15,000 커버 가능)
"미션 크리티컬" + "IOPS 16,000 초과"	io1 / io2	비싸지만 돈값 하는 고성능 (최대 64,000 ~ 256,000 IOPS)
"용량에 따라 성능 증가" (옛날 방식)	gp2	용량이 커져야만 속도도 빨라짐 (이제 잘 안 씀)

📝 EBS 문제 시험장 암기 노트

"EBS 문제 나왔다?"
⭐1. 일단 gp3를 의심한다. (최신 트렌드, 가성비 갑).
2. 만약 "64,000 IOPS 이상"이나 "밀리초 미만 지연시간(Sub-millisecond)" 같은 무시무시한 단어가 나오면 io2로 간다.
3. gp2는 정답일 확률이 매우 낮다. (구형).

💡 3초 컷 필승 공식: "감사 수준이 어디까지?"

"모든 수준에서 감사(Audit) 필요" (객체 단위 접근 기록):

S3 버킷 안에 있는 파일 하나하나(Object)를 누가 읽고 썼는지 감시해야 합니다.
이걸 하는 건 CloudTrail Data Events(데이터 이벤트)뿐입니다.
CloudTrail Management Events(관리 이벤트)는 "버킷을 만들었다/지웠다" 같은 큼직한 설정 변경만 기록합니다. (파일 누가 봤는지는 모름).

"데이터 마이그레이션" + "자주 변경됨":

⭐AWS DataSync: 온프레미스 스토리지와 S3를 연결해서, 변경된 데이터만 쏙쏙 골라 자동으로 동기화해 주는 이사용 전문 트럭입니다.
S3 Transfer Acceleration (C번): 이건 단순히 업로드 속도를 높여주는 '가속기'일 뿐, 복잡한 폴더 구조나 권한까지 챙겨주는 전문 마이그레이션 도구는 아닙니다.

📝 시험장 암기 노트: CloudTrail 이벤트 구분

구분	관리 이벤트 (Management Events)	데이터 이벤트 (Data Events)
기록 대상	제어 영역 (Control Plane)	데이터 영역 (Data Plane)
예시	버킷 생성, IAM 사용자 생성, 보안 그룹 변경	S3 GetObject(파일 열기), PutObject(파일 저장), Lambda 실행
비용	기본 무료 (첫 번째 사본)	유료 (켜야 함)
언제 쓰나?	"누가 설정을 바꿨니?"	"누가 이 파일을 열어봤니? (보안 감사)"

결론:

"누가 파일 건드렸는지 감시해라(Audit)" Data Events
"데이터 이사 가야 한다" DataSync

이제 CloudTrail의 디테일까지 챙기셨네요!
"감사(Audit) = Data Events" 공식만 기억하면 헷갈릴 일이 없습니다.

💡 핵심 키워드 매칭: "Java 웹 앱 배포" = "Elastic Beanstalk"

AWS Elastic Beanstalk:

정의: 개발자가 코드(Java WAR 파일 등)만 업로드하면, AWS가 알아서 Apache Tomcat 서버를 띄우고, 로드 밸런서(ELB) 붙이고, 오토 스케일링(Auto Scaling)까지 설정해 주는 PaaS(Platform as a Service)입니다.
적합성: 문제의 요구사항인 "Tomcat 배포"와 "고가용성(로드 밸런싱)"을 클릭 몇 번으로 완벽하게 해결합니다.

📝 Beanstalk 시험장 암기 공식

"Java/Tomcat/PHP/Node.js 등 코드를 간편하게 배포하고 싶다" + "고가용성 필요"
➡️ AWS Elastic Beanstalk

멘탈 체크:
"복잡한 Java 애플리케이션"이라는 말에 겁먹지 마세요. 배포 플랫폼을 묻는 문제에서는 Beanstalk가 가장 강력한 정답 후보입니다!

이 문제는 "AWS 서비스끼리 통신할 때 가장 안전한 방법"을 묻는, 보안 섹션에서 가장 중요한 문제입니다.

💡 3초 컷 필승 공식: "IAM User vs IAM Role"

IAM User (사용자 - A, C번):

특징: Access Key와 Secret Key라는 영구적인 열쇠를 사용합니다.
문제점: 이 열쇠를 코드(환경 변수 포함)나 파라미터 스토어에 저장해야 합니다. 만약 코드가 유출되면? 열쇠도 같이 털립니다. 키 관리(교체)도 사람이 직접 해야 해서 번거롭고 위험합니다.
결론: 서비스(기계)한테 사람용 신분증(User)을 주는 건 보안 위반입니다.

IAM Role (역할 - B, D번):

특징: 임시 보안 자격 증명(Temporary Credential)을 사용합니다.
장점: 키를 저장할 필요가 없습니다. AWS가 알아서 임시 출입증을 발급해주고, 시간 되면 폐기하고 다시 만듭니다. 가장 안전합니다.

신뢰 관계 (Trust Relationship - B vs D):

⭐⭐역할(Role)을 "누가" 뒤집어쓰나요? Lambda가 역할을 쓰고 DynamoDB에 가는 겁니다.
따라서 역할은 "Lambda 너는 나(역할)를 써도 돼"라고 신뢰해줘야 합니다. (Trust Entity = lambda.amazonaws.com).
⭐D번 오답 이유: DynamoDB가 Lambda를 호출하는 게 아니므로, DynamoDB를 신뢰할 필요가 없습니다.

📝 IAM Role 시험장 암기 노트

"EC2나 Lambda가 다른 AWS 서비스(S3, DynamoDB 등)에 접근해야 한다."
1. 무조건 IAM Role (실행 역할)을 사용한다.
2. IAM User(액세스 키) 저장하는 보기는 무조건 오답이다. (환경 변수든 뭐든 절대 안 됨).

멘탈 체크:
보안 문제에서 "Access Key를 어디에 저장한다"라는 말이 나오면 의심부터 하세요. "키를 아예 안 쓰는 것(Role)"이 최고의 보안입니다.

첫 번째 문제 (JSON 정책 연결 대상)

정답: 가(역할), 나(그룹)

💡 3초 컷 필승 공식: "신분증(ID)은 누가 찰까요?"

문제에서 "ID 기반 정책(Identity-based policy)"이라고 했죠? 이건 "출입증(권한표)"라고 생각하세요.

이 출입증을 목에 걸 수 있는 대상(IAM Identity)은 딱 3가지뿐입니다.

사용자 (User): 직원 한 명 (김철수, 이영희...)

그룹 (Group): 부서 (개발팀, 인사팀...)

역할 (Role): 모자 (보안관 모자, 의사 가운...)

보기에서 이 3가지를 찾으면 됩니다.

가. 역할 (O)
나. 그룹 (O)

두 번째 문제 (IAM 정책 해석)

정답: D

이 문제는 "Allow(허용)와 Deny(거부)가 싸우면 무조건 Deny가 이긴다"는 규칙과 조건(Condition)을 해석하는 능력을 봅니다.

💡 정책 해부하기

첫 번째 문단 (Sid: 1 - 허용)

Allow, ec2:* (모든 작업), us-east-1 (버지니아 북부 리전)
해석: "버지니아 북부(us-east-1) 리전에서는 뭐든지 다 해도 돼."

두 번째 문단 (Sid: 2 - 거부)

Deny, StopInstances / TerminateInstances (끄기/삭제하기)
조건: MFA Present: false (MFA 인증 안 했으면)
해석: "근데, 너 MFA(멀티팩터 인증) 안 하고 들어왔으면, 서버 끄거나 삭제하는 건 절대 안 돼(Deny)."

🧩 둘을 합치면? (AND 조건)

기본적으로 us-east-1 리전에서만 작업 가능합니다. (다른 리전은 언급이 없으므로 자동 거부)
그 안에서 모든 걸 할 수 있지만, "서버 끄기/삭제"만큼은 MFA를 했을 때만 가능합니다.
나머지(서버 조회, 시작 등)는 MFA 없어도 가능합니다. (Deny 조건에 안 걸리니까요).

따라서 정답은 D입니다.

"그룹 멤버는 멀티팩터 인증(MFA)으로 로그인한 경우에만 us-east-1 지역에 대한 ec2:Stop/Terminate 권한이 허용됩니다. (그 외) 다른 모든 작업은 (그냥) 허용됩니다."

📝 시험장 암기 노트

"ID 기반 정책을 연결할 수 있는 곳은?"
➡️ User(사용자), Group(그룹), Role(역할). (이 3총사뿐!)
"정책 해석 순서"
1. Deny(거부)가 있는지 먼저 본다. (있으면 그게 왕이다)
2. 조건(Condition)을 꼼꼼히 본다. (리전 제한? MFA 필수?)

이제 "ID 정책 = 사람/팀/역할" 공식이 입력되셨을 겁니다. 복잡한 코드가 나와도 겁먹지 마세요. 그냥 "이거 누구한테 주는 거야?"만 생각하면 됩니다!

이 문제는 "이벤트 기반 실시간 처리"와 "데이터 수명 주기에 따른 스토리지 비용 최적화"를 동시에 해결해야 하는 시나리오입니다.

💡 정답 조합 논리

1. 실시간 이미지 변환 (B 선택)

요구 사항: "가능한 한 빨리(As soon as possible)" 변환해야 함.
B (AWS Lambda): S3에 파일이 업로드되는 즉시 Lambda를 트리거하여 변환할 수 있습니다. 서버를 계속 띄워둘 필요가 없어 비용 효율적이며, 즉각적인 반응 속도를 제공합니다.

2. 스토리지 비용 최적화 (C 선택)

요구 사항 (CSV): 1년에 딱 2번 사용하며, 몇 주 전에 미리 계획됨.
접근 빈도가 매우 낮고(Cold Data), 복구 시간(Retrieval time)을 충분히 확보할 수 있습니다.
따라서 S3 Glacier가 가장 저렴하고 적합합니다. (IA 등급보다 훨씬 저렴함).

요구 사항 (이미지): 1개월 후 무의미해짐.
30일 후 만료(Expiration) 규칙을 적용하여 자동으로 삭제하면 비용이 들지 않습니다.

C (Glacier + 만료): CSV는 가장 저렴한 Glacier로, 이미지는 자동 삭제로 설정하여 비용을 최소화하는 최적의 구성입니다.

❌ 오답 분석

EC2 Spot: 실시간성을 만족하지 못하며, 단순히 파일 변환을 위해 EC2를 관리하는 것은 관리 오버헤드가 큽니다.
S3 One Zone-IA: IA(Infrequent Access)는 한 달에 한 번 정도 접근할 때 유리합니다. 1년에 2번 접근한다면 Glacier가 압도적으로 저렴합니다.
S3 Standard-IA + RRS:
- Standard-IA는 Glacier보다 비쌉니다.
RRS(Reduced Redundancy Storage)는 AWS에서 더 이상 권장하지 않는(deprecated) 구형 스토리지 클래스입니다.

📝 시험장 암기 노트

"파일 업로드 즉시 처리" S3 Event Notification + Lambda
"1년에 1~2번 접근" + "미리 계획 가능" S3 Glacier
"일정 기간 후 필요 없음" Lifecycle Expiration (만료)

⭐이 문제는 "실시간 스코어보드(순위표)"라는 키워드를 보자마자 Redis를 떠올려야 하는 전형적인 패턴입니다.

💡 1초 컷 필승 공식: "게임 순위 = Redis Sorted Sets"

순위표(Leaderboard) 구현의 정석:

Redis에는 'Sorted Set(정렬된 집합)'이라는 아주 강력한 자료구조가 있습니다.
점수를 넣으면 자동으로 순서대로 정렬해 줍니다. "상위 10명 뽑아줘"라고 하면 0.001초 만에 결과를 줍니다. (MySQL로 매번 ORDER BY 돌리는 것보다 수백 배 빠릅니다.)

게임 상태 저장 (중지/복원):

Redis는 메모리 기반이지만 데이터 영속성(Persistence)을 지원하고, 리스트나 해시 같은 복잡한 데이터 구조도 지원하므로 게임 세션 정보를 저장하고 복구하는 데 최적입니다.

❌ 오답 분석

A. Memcached:
단순한 키-값(Key-Value) 저장소입니다. 순위를 매기는 기능(Sorted Set)이 없습니다. 스코어보드를 만들려면 데이터를 다 가져와서 앱에서 직접 정렬해야 하므로 느립니다.

C. CloudFront:
이미지나 정적 파일을 빠르게 배달하는 CDN입니다. 실시간으로 변하는 점수 데이터를 계산하고 관리하는 곳이 아닙니다.

D. RDS 읽기 복제본:
물론 DB 쿼리(SELECT ... ORDER BY score DESC LIMIT 10)로도 가능은 합니다.
하지만 동시 접속자가 많은 게임에서 매번 DB 쿼리를 날리면 부하가 엄청나고 속도도 느립니다. "거의 실시간"이라는 요구사항에는 인메모리 DB인 Redis가 정답입니다.

📝 시험장 암기 노트

"실시간 스코어보드 / 리더보드 / 상위 10위"
➡️ 무조건 Amazon ElastiCache for Redis
"단순 캐싱 / 멀티스레드 성능 필요"
➡️ Memcached

이 공식은 게임뿐만 아니라 실시간 랭킹이 필요한 모든 서비스에 적용됩니다.

도은호

`•.¸¸.•´´¯`••._.• 🎀 𝒸𝓇𝒶𝓏𝓎 𝓅𝓈𝓎𝒸𝒽💞𝓅𝒶𝓉𝒽 🎀 •._.••`¯´´•.¸¸.•`

다음 포스트