AWS SAA 해설 20251219

도은호·2025년 12월 19일

AWS SAA

목록 보기

47/53

1. Amazon ElastiCache (Redis vs Memcached)

AWS 시험에서 매우 자주 출제되는 비교 개념

기능	Redis (정답)	Memcached
주요 특징	복잡한 자료구조 지원 (Sorted Sets, Lists 등)	단순한 Key-Value 구조
고가용성	지원함 (복제, Multi-AZ, 자동 장애 조치)	지원 안 함 (노드 장애 시 데이터 손실)
데이터 지속성	지원함 (백업 및 복원 가능)	지원 안 함 (메모리에만 저장)
사용 사례	리더보드, 채팅, 지리 공간 데이터, 고가용성 캐싱	단순하고 빠른 데이터 캐싱, 멀티스레드 아키텍처

2. 캐싱 전략 (Caching Strategy)

Lazy Loading (지연 로딩): 애플리케이션이 데이터를 요청할 때 먼저 캐시를 확인합니다. 캐시에 없으면(Miss) DB에서 가져와 캐시에 저장하고 반환합니다.
Write-Through (쓰기 주도): 데이터를 DB에 쓸 때 캐시에도 동시에 씁니다. 데이터 일관성이 높지만 쓰기 성능에 영향을 줄 수 있습니다.

3. RDS 읽기 복제본 (Read Replica)

원본 DB(Primary)의 데이터를 비동기적으로 복제하여 읽기 전용 DB를 만듭니다.
목적: 단일 DB 인스턴스의 읽기 용량 한계를 극복하고 트래픽을 분산하기 위함입니다. (캐싱과는 목적이 다소 다릅니다.)

문제의 핵심 요구사항은

DB를 반드시 EC2에 설치/운영해야 함 (RDS 같은 매니지드 DB 사용 불가)
고가용성(HA) 이면서 중단 이벤트 시 자동 장애 조치(Failover) 가 되어야 함

따라서 가장 정석적인 해법은 같은 리전 내 서로 다른 AZ에 DB EC2를 2대 구성하고,

DB 복제(Primary → Standby) 를 걸어두고
클러스터/페일오버 메커니즘(예: VIP/ENI 이동, 헬스체크 기반 전환) 으로 장애 시 자동 전환하는 패턴

1) Multi-AZ(고가용성) vs Multi-Region(DR)

Multi-AZ: 같은 리전, 다른 AZ. 짧은 RTO, 운영 단순, 일반적인 HA 정답 패턴.
Multi-Region: 리전 단위 재해 대비. DR 성격, 비용/복잡도 상승.

2) “DB를 EC2에서 운영해야 할 때”의 HA 패턴

Primary/Standby 2대(서로 다른 AZ)
DB Replication 구성(예: MySQL/PostgreSQL 복제 등)
Failover 방식(시험 키워드로 이해)
- 애플리케이션이 바라보는 접점을 EIP/ENI/VIP 이동 등으로 전환
- 또는 애플리케이션 레벨에서 엔드포인트 변경/재시도 설계

3) EC2 Auto Recovery의 한계

“인스턴스/호스트 장애” 대응에는 유효할 수 있으나
DB 이중화/복제/클러스터 기반 자동 Failover를 대체하지 못함 (특히 AZ 장애)

핵심 이유: 지금 구조는 “클라이언트 요청 → EC2 처리 → RDS 저장”이 동기(synchronous)·직접 연결이라, EC2/애플리케이션/네트워크에 장애가 나면 요청(주문)이 유실되거나 처리 중단되어 사용자가 재처리(재주문/재전송)를 하게 됩니다.
요구사항은 “시스템 중단이 있어도 자동으로 주문을 처리할 수 있는 복원력(Resilient)”이므로, 주문을 먼저 ‘내구성 있는 저장소(Queue)’에 적재하고, 이후 백엔드가 꺼졌다 켜져도 다시 소비(처리)하는 비동기 구조가 정답

주문을 Amazon SQS 대기열에 넣고(내구성/저장),
Auto Scaling 그룹의 EC2 워커들이 큐에서 메시지를 소비해 처리,
장애 시에도 메시지는 큐에 남아 있다가 워커가 복구되면 자동 재처리
가 가능해 요구사항에 정확히 부합합니다.

1) Decoupling(디커플링)과 비동기 처리

프론트(주문 접수)와 백엔드(처리)를 분리하면,
- 백엔드 장애/배포/스파이크에도 주문은 큐에 안전하게 적재
- 백엔드는 살아날 때 밀린 주문을 자동 처리

2) SQS 핵심 키워드

At-least-once 전달(표준 SQS 기본): 중복 처리 가능 → Idempotency(멱등성) 설계 필요
Visibility Timeout: 워커가 메시지를 가져가 처리 중일 때 다른 워커가 못 보게 숨김
DLQ(Dead-Letter Queue): 반복 실패 메시지 격리(독성 메시지 처리)
FIFO 큐(필요 시): 순서 보장, 중복 최소화(처리량/제약 고려)

3) EC2 Auto Scaling + SQS 연동 운영 포인트

큐 길이(ApproximateNumberOfMessagesVisible) 기반으로 워커를 스케일 아웃/인
Long Polling으로 불필요한 빈 폴링 감소
처리 완료 후에만 DeleteMessage(삭제)하여 유실 방지

4) “주문” 워크로드에서 특히 중요한 설계

중복 주문 방지: 주문 ID(또는 idempotency key)로 DB에 유니크 제약/처리 상태 관리
DB 트랜잭션: “처리 완료”와 “메시지 삭제” 순서/원자성 고려(일반적으로 DB 커밋 → 메시지 삭제)

핵심 요약

요구 사항: AWS 마이그레이션 시 개발 변경 최소화 + 고가용성(HA) 보장.
현재 환경: Windows Server (.NET) + Oracle Database.

선택지 분석

B. AWS Elastic Beanstalk에서 .NET 플랫폼 사용 (다중 AZ)

이유 (애플리케이션 계층):
변경 최소화: Elastic Beanstalk는 .NET on Windows를 지원하므로 기존 코드를 그대로 '리호스팅(Rehost)'하기 가장 적합함.
고가용성: 다중 AZ(가용 영역) 배포 설정을 통해 간단하게 HA 구성 가능.

E. Amazon RDS for Oracle로 마이그레이션 (다중 AZ)

이유 (데이터베이스 계층):
변경 최소화: 온프레미스 Oracle에서 RDS Oracle로 이동하는 것은 동일한 DB 엔진을 사용하는 것이므로, 애플리케이션의 쿼리나 로직을 수정할 필요가 거의 없음 (연결 문자열 변경 정도).
고가용성: RDS의 Multi-AZ 옵션을 켜는 것만으로 자동 동기식 복제와 장애 조치가 제공됨.

📚 관련 핵심 용어 및 개념 정리

1. 클라우드 마이그레이션 전략 (The 6 R's)

Rehost (리호스팅 - Lift and Shift): 애플리케이션 코드를 수정하지 않고 그대로 클라우드 인프라(EC2, Beanstalk 등)로 옮기는 방식. 가장 빠르고 개발 공수가 적음. (본문 정답 B)
Replatform (리플랫폼): 핵심 코드는 유지하되, 클라우드 최적화를 위해 관리형 서비스(RDS 등)로 일부 플랫폼만 교체하는 방식. (본문 정답 E)
Refactor (리팩터링): 클라우드 네이티브 기능(Serverless, Microservices)을 활용하기 위해 아키텍처와 코드를 대대적으로 수정하는 방식. (본문 오답 A - 개발 변경 최소화 요건 불충족)

2. 데이터베이스 마이그레이션 유형

동종(Homogeneous) 마이그레이션: 소스와 타겟의 DB 엔진이 같은 경우 (예: Oracle → RDS for Oracle). 스키마 변경이 필요 없어 애플리케이션 수정이 최소화됨.
이종(Heterogeneous) 마이그레이션: 소스와 타겟의 DB 엔진이 다른 경우 (예: Oracle → DynamoDB). AWS Schema Conversion Tool(SCT)을 이용한 스키마 변환과 애플리케이션 코드 수정이 필수적

여러 화자 인식 + 대본(Transcript) 생성: Amazon Transcribe
- Transcribe는 음성 파일을 텍스트로 필사하고, 화자 분리(speaker diarization) 로 여러 화자를 구분할 수 있습니다.
대본 파일을 “쿼리”해서 패턴 분석: Amazon Athena
- Athena는 S3에 저장된 파일(JSON/CSV/Parquet 등) 을 SQL로 바로 조회할 수 있어 “대본 파일을 쿼리” 요구에 정합합니다.

보기 B가 유일하게 “다중 화자 인식(Transcribe)”과 “쿼리 기반 분석(Athena)”을 직접적으로 만족합니다.

1. AI/ML 서비스 구분 (빈출 유형)

AWS 시험에서 목적에 맞는 AI 서비스를 고르는 문제는 키워드 매칭이 중요합니다.

서비스명	주요 기능 및 키워드
Amazon Transcribe	음성 → 텍스트 (STT), 화자 식별, 자막 생성, 의료/콜센터 특화
Amazon Polly	텍스트 → 음성 (TTS), 낭독, 실시간 음성 생성
Amazon Translate	언어 번역, 다국어 지원
Amazon Rekognition	이미지/비디오 분석, 얼굴 인식, 사물 감지, 콘텐츠 조정
Amazon Textract	문서(PDF, 이미지) → 텍스트/데이터 추출 (OCR), 영수증 처리
Amazon Comprehend	자연어 처리(NLP), 감성 분석(긍정/부정), 키워드 추출

2. 데이터 분석 서비스

Amazon Athena: S3에 있는 파일(CSV, JSON, Parquet 등)을 DB에 로드하지 않고 Serverless로 바로 SQL 조회 가능. 로그 분석이나 비정형 데이터 조회에 주로 사용.
Amazon Redshift: 대규모 데이터 웨어하우스(DW). 복잡한 분석과 리포팅을 위해 데이터를 적재(ETL)하여 사용. (단순 파일 조회용으로는 Athena가 더 가볍고 적합)

요구 사항: Amazon Cognito로 이미 사용자를 관리 중 + API Gateway 접근 제어(Authorization) 필요 + 개발 노력 및 운영 오버헤드 최소화.
해결책 (Native Integration):
- Cognito User Pool Authorizer: API Gateway는 Amazon Cognito와 기본적으로 통합되어 있음.
- 별도의 코드 작성(Lambda) 없이, API Gateway 설정에서 Cognito 사용자 풀을 'Authorizer(권한 부여자)'로 지정하기만 하면 됨.
- 클라이언트가 보낸 JWT 토큰(ID Token/Access Token)의 유효성을 API Gateway가 자동으로 검증함.

1. API Gateway의 주요 인증/인가 방식 3가지 (빈출 비교)

방식	설명	사용 사례
Cognito User Pool Authorizer (정답)	Cognito 사용자 풀의 토큰(JWT)을 API Gateway가 직접 검증. 코드 작성 불필요.	모바일/웹 앱 사용자가 Cognito로 로그인하는 경우 가장 간단하고 표준적인 방법.
Lambda Authorizer (Custom)	사용자가 작성한 Lambda 함수를 통해 인증 수행. (Bearer Token 등 파싱)	서드파티 인증(Oauth, SAML)을 사용하거나 복잡한 커스텀 인증 로직이 필요한 경우.
IAM Authorization	AWS IAM 권한(SigV4 서명)을 통해 접근 제어.	내부 마이크로서비스 간 통신이나, AWS 자격 증명을 가진 클라이언트의 접근 제어.

2. API Key의 용도

목적: 보안(인증)보다는 식별 및 제어 목적이 강함.
기능: 특정 클라이언트(앱)의 호출 빈도 제한(Rate Limiting), 쿼터 할당, 사용량 모니터링.
주의: API Key만으로 보안 인증을 구성하는 것은 안전하지 않음.

1) API Gateway 인증/인가 옵션 비교

Cognito User Pool Authorizer: JWT 검증을 API Gateway가 관리형으로 수행 (이번 문제 정답)
Lambda Authorizer: 커스텀 로직(세밀한 정책 가능) 대신 개발/운영 부담 증가
IAM Authorization (SigV4): AWS 자격 증명 기반 호출에 적합(서버/서비스 간)

2) Cognito 토큰 흐름

로그인 → JWT 발급 → API 호출 시 Authorization 헤더에 Bearer 토큰 → API Gateway가 검증

3) “Access control”의 의미

최소 요구: “로그인한 사용자만 호출 가능” 수준이면 Cognito Authorizer로 충분
역할 기반/세분화된 권한(RBAC/ABAC)이 필요하면:
- Cognito 그룹/클레임을 활용하거나
- 필요 시 Lambda Authorizer로 확장(단, 오버헤드 증가)

핵심 요약

요구 사항: 마케팅 커뮤니케이션 + SMS 발송 + 사용자 답장(양방향 SMS) 처리 + 데이터 장기 보관 및 분석.
해결책 (Amazon Pinpoint):
- 마케팅 특화: Amazon Pinpoint는 이메일, SMS, 푸시 알림 등을 통합 관리하는 마케팅 커뮤니케이션 서비스임.
- 양방향 SMS (Two-Way SMS): Pinpoint는 기본적으로 사용자의 SMS 답장을 수신하고 처리하는 기능을 지원함.
- 데이터 분석 및 보관: Pinpoint의 이벤트 데이터(메시지 전송 성공, 실패, 사용자 응답 등)를 Kinesis Data Streams 또는 Kinesis Data Firehose로 스트리밍하여 S3, Redshift 등에 저장하고 분석할 수 있음.

오답 노트

A (Amazon Connect): 클라우드 고객 센터(콜센터) 서비스임. 마케팅 SMS 캠페인 용도가 아님.
C (Amazon SQS): 애플리케이션 간의 메시지 대기열(Queue) 서비스. SQS 자체는 외부 사용자에게 SMS를 발송하는 기능이 없음.
D (Amazon SNS): 주제(Topic) 기반의 게시/구독 서비스. SMS 발송은 가능하지만, 마케팅 캠페인 관리(여정 구축)나 양방향 대화 흐름 처리는 Pinpoint가 훨씬 적합하고 강력함. (SNS는 주로 시스템 알림이나 단방향 A2P 메시징에 초점).

구분	Amazon Pinpoint (정답)	Amazon SNS
주요 목적	마케팅, 사용자 참여 유도, 캠페인 관리	시스템 알림, 트랜잭션 메시지, 애플리케이션 통합
대상	특정 사용자 세그먼트(타겟팅)	주제(Topic) 구독자
양방향 SMS	기본 지원 (답장에 따른 자동 응답/트리거 설정 용이)	지원은 하나 설정이 복잡하고 마케팅 로직 구현에 한계가 있음
분석 기능	캠페인 성과, 사용자 행동 분석 등 상세 제공	배달 성공/실패 여부 등 기본적인 로그 위주

2. Amazon Kinesis (데이터 스트리밍)

대용량의 실시간 데이터를 수집, 처리, 분석하는 서비스.
Pinpoint + Kinesis 조합: 마케팅 이벤트 로그(누가 언제 클릭했는지, 답장했는지 등)를 실시간으로 수집하여 외부 저장소(S3 등)로 보내 영구 보관하는 표준 아키텍처 패턴.

핵심 요약

요구 사항 분석:

데이터 암호화: S3 저장 시 암호화 필요.
연간 자동 순환 (Annually Rotate): 암호화 키가 매년(1년 주기) 자동으로 바뀌어야 함.
최소 운영 오버헤드: 수동 작업을 최소화.

해결책 (KMS Customer Managed Key + Auto Rotation):
- 고객 관리형 키 (Customer Managed Key): 사용자가 직접 생성하는 KMS 키입니다.
- 자동 로테이션: 이 옵션을 활성화하면 AWS가 정확히 1년(365일) 마다 자동으로 키 자료(Backing Key)를 순환시킵니다.
- 오버헤드: 키 생성 시 체크박스 하나만 켜면 되므로 운영 부담이 거의 없습니다.

오답 노트

A (SSE-S3): S3 관리형 키는 AWS가 내부적으로 키를 관리하고 순환하지만, 그 주기가 "매년"이라고 명시적으로 보장되거나 사용자가 제어할 수 있는 규정 준수 옵션이 아닙니다. (참고: AWS 관리형 KMS 키(aws/s3)는 3년마다 순환됩니다).
C (수동 순환): "매년 수동으로 순환"해야 하므로 운영 오버헤드가 큽니다. 실수로 누락할 위험도 있습니다.
D (키 가져오기 - Import Key Material): 외부에서 키 자료를 가져온(Imported) KMS 키는 자동 로테이션 기능을 지원하지 않습니다. 사용자가 수동으로 새 키 자료를 다시 가져와야 하므로 오버헤드가 가장 큽니다.

AWS KMS 키 로테이션 주기 (빈출 암기 포인트)

시험에서 "자동 로테이션"과 "기간"이 나오면 아래 규칙을 적용해야 합니다.

키 유형	로테이션 주기	자동 로테이션 지원 여부
AWS 관리형 키 (AWS Managed Key)	3년 (1095일)	O (기본값, 끄기 불가)
고객 관리형 키 (Customer Managed Key)	1년 (365일)	O (선택 사항, 활성화 필요)
가져온 키 자료 (Imported Key Material)	-	X (지원 안 함, 수동 관리 필수)

참고: 문제에서 "매년(Annually)"이라는 단어가 나오면 고객 관리형 키(Customer Managed Key)를 선택해야 합니다. AWS 관리형 키는 3년 주기이기 때문입니다.

핵심 요약

요구 사항: 정적 웹사이트(Static Website) 호스팅 + 가장 비용 효율적(Cheapest) + 복원력(Resilience).
해결책 (S3 + CloudFront + OAI):
- S3 (Storage): 정적 파일(HTML, CSS, JS) 호스팅에 가장 저렴하고 내구성(11 9s)이 뛰어난 서버리스 솔루션.
- OAI (Origin Access Identity): S3 버킷을 비공개(Private)로 유지하면서, CloudFront를 통해서만 접근 가능하도록 보안 강화.
- AWS CLI: 별도의 비용이 드는 SFTP 서비스 대신, 무료 도구인 CLI로 파일 업로드 수행.

오답 노트

A (Lightsail), B (EC2 + ALB): 서버(컴퓨팅 인스턴스)를 사용하는 방식. S3에 비해 비용이 훨씬 비싸고, OS 패치 등 관리 오버헤드가 발생함. 단순 정적 파일 호스팅에는 과도한 스펙.
D (AWS Transfer for SFTP):
비용 문제: AWS Transfer Family는 시간당 요금(약 $0.30/시간, 월 $200 이상)이 발생하므로 "드물게 업데이트"하는 용도로는 비용 효율성이 매우 떨어짐.
구성: CloudFront 뒤에 오리진을 둘 때는 퍼블릭 버킷보다는 OAI/OAC를 통한 프라이빗 버킷 구성이 보안상 권장됨.

1. CloudFront와 S3 보안 (OAI vs OAC)

OAI (Origin Access Identity): CloudFront가 비공개 S3 버킷의 객체를 가져올 수 있도록 허용하는 가상 사용자 ID. (레거시 방식)
OAC (Origin Access Control): OAI의 개선된 버전. 보안이 강화되었으며 S3 외의 다른 오리진(Lambda 등)도 지원함. (최신 권장 방식이나, 시험에는 아직 OAI가 주로 출제됨)
목적: 사용자가 S3 URL로 직접 접속하는 것을 막고, 반드시 CloudFront(CDN)를 거치도록 강제함.

2. 정적 웹사이트 호스팅 아키텍처 비교

방식	특징	비용	복원력
S3 단독 (Static Website Hosting)	설정이 가장 간단함. HTTP만 지원(HTTPS 불가).	매우 저렴	높음 (Multi-AZ)
S3 + CloudFront (정답)	HTTPS 지원, 전 세계 엣지 캐싱으로 속도 빠름, OAI/OAC로 보안 강화.	저렴 (데이터 전송료 절감)	매우 높음
EC2 / Lightsail	서버 관리 필요. 동적 콘텐츠 처리에 적합.	비쌈 (서버 비용)	구성에 따라 다름

3. AWS Transfer Family

S3나 EFS로 파일을 전송할 때 SFTP, FTPS, FTP 프로토콜을 사용할 수 있게 해주는 완전 관리형 서비스.
주의: 서버를 직접 구축하는 것보다 관리는 편하지만, 고정 비용(시간당 요금)이 꽤 비싸므로 단순 파일 업로드 용도로는 신중히 선택해야 함.

정답

CreateImage API 호출에 대한 Amazon EventBridge(Amazon CloudWatch Events) 규칙을 만듭니다. CreateImage API 호출이 감지되면 알림을 보내도록 대상을 Amazon Simple Notibcation Service(Amazon SNS) 토픽으로 구성합니다.

핵심 요약

요구 사항: CreateImage API 호출 감지 + 알림 발송 + 최소한의 운영 오버헤드.
해결책 (EventBridge + SNS):
- Serverless & No Code: Amazon EventBridge(구 CloudWatch Events)는 AWS 서비스의 API 호출(CloudTrail 기반)을 실시간 스트림으로 받아 처리합니다.
- 패턴 매칭: 규칙(Rule)을 생성하여 source: "aws.ec2", detail-type: "AWS API Call via CloudTrail", eventName: "CreateImage"로 설정하면 해당 API 호출만 정확히 필터링할 수 있습니다.
- 직접 통합: 별도의 컴퓨팅 리소스(Lambda 등) 없이, 이벤트의 대상을 바로 SNS 토픽으로 지정하여 알림을 보낼 수 있어 운영 오버헤드가 가장 적습니다.

오답 노트

A (CloudTrail -> Lambda): Lambda 함수 코드를 작성하고 관리해야 하므로 운영 오버헤드가 발생합니다. 또한 CloudTrail 로그가 S3에 전달되는 데는 약간의 지연(최대 15분)이 발생할 수 있어 EventBridge보다 실시간성이 떨어집니다.
B (Athena): Athena는 저장된 로그를 분석(SQL 쿼리)하는 도구입니다. 실시간 알림 시스템이 아니며, 쿼리를 실행하는 주체나 스케줄러가 추가로 필요합니다.
D (SQS + Lambda): 큐(Queue)와 컴퓨팅(Lambda)을 조합하는 것은 아키텍처가 불필요하게 복잡합니다. 단순 알림에는 과도한 엔지니어링입니다.

1. Amazon EventBridge (vs CloudWatch Events)

정의: 애플리케이션, AWS 서비스, 타사 SaaS 애플리케이션의 데이터를 사용하여 애플리케이션을 쉽게 연결할 수 있는 서버리스 이벤트 버스 서비스. (CloudWatch Events의 업그레이드 버전).
주요 패턴:
이벤트 패턴(Event Pattern): 특정 서비스의 상태 변경이나 API 호출을 감지 (예: EC2 상태가 Running으로 변경, S3 버킷 생성 등).
일정(Schedule): Cron 작업처럼 주기적으로 트리거 실행.

시험 팁: "AWS API 호출에 반응하여 무언가를 실행한다" + "최소 오버헤드" = EventBridge가 정답일 확률이 매우 높습니다.

2. AWS CloudTrail과의 관계

EventBridge가 API 호출을 감지하려면 CloudTrail이 활성화되어 있어야 합니다. (대부분 기본 활성화).
EventBridge 규칙에서 detail-type: "AWS API Call via CloudTrail"을 사용하여 특정 API(여기서는 CreateImage)를 트리거로 잡습니다.

정답:

Amazon Simple Queue Service(Amazon SQS) 대기열과 Lambda를 사용하여 DynamoDB에 대한 쓰기를 버퍼링합니다.

핵심 요약

문제 상황:
- 비동기 API 구조 (API Gateway → Lambda → DynamoDB).
- 문제: DynamoDB 프로비저닝 용량을 최대로 늘렸음에도 쓰기 용량 부족으로 인한 스로틀링(Throttling) 발생 → 요청 손실.

해결책 (Queue-Based Load Leveling):
- SQS 버퍼링: 요청을 데이터베이스에 바로 쓰지 않고 SQS 대기열에 먼저 저장. SQS는 거의 무제한의 처리량을 받아줄 수 있어 요청 손실 방지.
- 속도 조절: Lambda가 SQS에서 메시지를 가져와 DynamoDB에 쓸 때, DB가 처리할 수 있는 속도(Provisioned Throughput)에 맞춰 천천히 처리하도록 제어 가능.
- 비동기 처리: 문제에서 이미 "비동기 API"라고 명시했으므로, 즉각적인 응답이 필요 없기 때문에 큐를 도입하기에 가장 적합한 시나리오.

Queue-Based Load Leveling (대기열 기반 부하 평준화)

개념: 소스(요청자)와 타겟(DB) 사이의 처리 속도 차이가 클 때, 중간에 큐(Queue)를 두어 완충 지대 역할을 하게 하는 아키텍처 패턴.
장점:

데이터 유실 방지: 급격한 트래픽 스파이크(Spike)가 와도 큐에 안전하게 저장됨.
비용 효율성: 피크 트래픽에 맞춰 DB 용량을 무리하게 늘릴 필요 없이, 평균 처리량에 맞춰 설계 가능.

적용 사례: 비동기 작업 처리, 배치 프로세싱, 이메일 발송 등.

정답: B (가장 적절한 솔루션)

EC2 인스턴스가 있는 가용성 영역에서 Amazon S3에 대한 게이트웨이 VPC 엔드포인트를 만듭니다. (중략) S3 버킷에 리소스 정책을 연결하여 EC2 인스턴스의 IAM 역할만 액세스할 수 있도록 합니다.

주의: 문제의 선택지 B 설명 중 "엔드포인트에 보안 그룹을 연결"한다는 내용은 기술적으로 부정확합니다(게이트웨이 엔드포인트는 보안 그룹이 아닌 라우팅 테이블을 사용). 하지만 EC2에서 S3로의 비공개 연결을 위한 표준 아키텍처는 게이트웨이 엔드포인트이므로 AWS 시험 맥락상 B가 정답입니다.

핵심 요약

요구 사항 분석:

EC2 → S3 데이터 이동: 내부 트래픽.
공개 인터넷 차단: IGW(인터넷 게이트웨이)나 NAT를 타지 않아야 함.
특정 EC2만 접근: IAM 역할 기반의 접근 제어 필요.

해결책 (Gateway VPC Endpoint):
- Private Connection: Amazon S3와 DynamoDB는 게이트웨이(Gateway) VPC 엔드포인트를 사용하여 VPC 내부에서 인터넷을 거치지 않고 직접 연결하는 것이 표준입니다. (무료이며, 지연 시간이 가장 낮음).
- 접근 제어: S3 버킷 정책(Resource Policy)에서 aws:PrincipalArn 조건을 사용하여 특정 IAM 역할을 가진 EC2만 업로드하도록 제한할 수 있습니다.
- 라우팅: 게이트웨이 엔드포인트는 VPC의 라우팅 테이블(Route Table)에 S3의 접두사 목록(Prefix List, 예: pl-xxxxxxxx)을 타겟으로 추가하여 작동합니다.

VPC Endpoint 유형 비교 (S3 기준)

유형	게이트웨이 엔드포인트 (Gateway)	인터페이스 엔드포인트 (Interface)
지원 서비스	S3, DynamoDB (단 2개)	그 외 대부분의 AWS 서비스 (S3도 지원함)
작동 방식	라우팅 테이블 (Route Table)의 경로 변경	ENI (Elastic Network Interface) 생성 및 Private IP 할당
보안 제어	엔드포인트 정책 (Endpoint Policy)	보안 그룹 (Security Group) 및 엔드포인트 정책
비용	무료	시간당 요금 + 데이터 처리 비용 발생
주요 용도	AWS 내부 (EC2 → S3) 트래픽 처리	온프레미스 또는 다른 리전에서 S3 접근 시

시험 팁: 문제에서 "S3" 또는 "DynamoDB"의 프라이빗 액세스를 묻는다면 90% 이상 게이트웨이 엔드포인트가 정답입니다.

정답: A

Amazon ElastiCache를 사용하여 세션 데이터를 관리하고 저장합니다.

핵심 요약

요구 사항 분석:

잦은 확장/축소 (Auto Scaling): EC2 인스턴스가 수시로 생성되고 삭제됨.
분산 세션 관리: 어떤 인스턴스가 요청을 처리하든 사용자 세션이 유지되어야 함.
코드 변경 가능: 애플리케이션 로직 수정 허용.

해결책 (External Session Store):
- Stateless 아키텍처: Auto Scaling 환경에서는 인스턴스가 언제든 사라질 수 있으므로, 세션 데이터를 로컬 메모리가 아닌 외부 저장소에 저장해야 함.
- Amazon ElastiCache (Redis/Memcached): 인메모리 데이터 스토어로, 밀리초 미만의 지연 시간으로 세션 데이터를 읽고 쓸 수 있어 분산 세션 저장소로 가장 적합함. 모든 EC2 인스턴스가 동일한 ElastiCache 클러스터를 바라보게 하여 세션 공유.

세션 관리 전략 비교 (Stateful vs Stateless)

방식	Sticky Session (세션 고정)	Distributed Session Store (분산 세션)
저장 위치	각 EC2 인스턴스의 로컬 메모리/디스크	Amazon ElastiCache 또는 DynamoDB
동작 원리	ALB가 쿠키를 이용해 트래픽을 특정 인스턴스에 고정	모든 인스턴스가 공통된 외부 DB에서 세션을 조회
장점	구현이 매우 쉬움 (코드 변경 불필요)	고가용성, 인스턴스 장애/확장 시 데이터 유실 없음
단점	인스턴스 종료 시 로그아웃(세션 유실) 발생, 부하 불균형 가능성	별도 저장소 비용 발생, 애플리케이션 코드 수정 필요
적합한 환경	소규모, 고정된 서버 환경	Auto Scaling, 대규모 분산 환경 (Cloud Native)

정답: D

두 개의 Amazon Simple Queue Service(Amazon SQS) 대기열을 제공합니다. ... 인스턴스당 백로그 계산을 기반으로 메트릭을 만듭니다. 이 메트릭을 기반으로 Auto Scaling 그룹을 확장합니다.

핵심 요약

문제 상황:

속도 불일치: 주문 수집(빠름) vs 주문 이행(느림).
데이터 손실 방지: 확장/축소 시 주문이 유실되면 안 됨.
최적화: 피크 타임에 맞춰 확장하되, 비용 효율적이어야 함.

해결책 (Decoupling & Target Tracking):
- SQS (Decoupling): '빠른 수집'과 '느린 이행' 사이에 SQS 대기열을 두어 버퍼 역할을 수행. EC2가 다운되거나 확장이 늦어져도 메시지(주문)는 큐에 안전하게 저장됨 (데이터 손실 방지).
- Backlog per Instance (인스턴스당 백로그): 단순히 큐의 길이(전체 메시지 수)만으로 확장하면, 이미 인스턴스가 많은 경우에도 불필요하게 더 확장할 수 있음. "대기열의 메시지 수 / 현재 실행 중인 인스턴스 수" (인스턴스당 처리해야 할 잔여 작업량)를 사용자 지정 지표로 계산하여, 이 값이 일정 수준(예: 인스턴스당 5개)을 유지하도록 대상 추적 조정(Target Tracking Scaling)을 설정하는 것이 가장 자원 효율적임.

오답 노트

A (CPU 기반 & 피크 용량 고정):
작업자(Worker) 프로세스는 CPU 사용량과 실제 처리 대기량(주문 수)이 비례하지 않을 수 있음.
"최소 용량을 피크 값에 맞춤"은 트래픽이 적을 때도 리소스를 낭비하므로 비용 최적화(Optimization) 요건에 위배됨 (Over-provisioning).

B (SNS로 새 그룹 생성):
트래픽이 늘어난다고 해서 새로운 Auto Scaling 그룹을 동적으로 생성하는 것은 잘못된 아키텍처 패턴임. 기존 그룹의 크기(Capacity)를 늘려야 함.

C (단순 대기열 알림):
SQS 자체가 "확장 알림"을 직접 보내는 기능은 없음 (CloudWatch 경보를 통해야 함).
단순 큐 길이 기반 확장은 인스턴스 수 변화에 따른 부하 변화를 정밀하게 반영하지 못해 '인스턴스당 백로그' 방식보다 효율성이 떨어짐.

1. Backlog Per Instance (인스턴스당 백로그)

개념: SQS 기반 오토 스케일링의 Golden Metric.
공식: ApproximateNumberOfMessagesVisible (대기 중인 메시지 수) / InServiceInstances (실행 중인 인스턴스 수)
이유: 전체 메시지가 1,000개일 때, 인스턴스가 1개라면 과부하 상태지만, 인스턴스가 1,000개라면 여유로운 상태임. 따라서 절대적인 메시지 수보다 '인스턴스 하나가 짊어진 짐의 무게'를 기준으로 확장해야 정확함.

2. 결합 해제 (Decoupling)

정의: 시스템의 구성 요소가 서로 독립적으로 실행되도록 분리하는 것.
SQS의 역할: 생산자(주문 수집)가 소비자(주문 이행)의 처리 속도나 상태를 신경 쓰지 않고 큐에 데이터를 넣기만 하면 됨. 소비자가 느려지거나 멈춰도 큐에 데이터가 쌓일 뿐 전체 시스템 중단이나 데이터 손실로 이어지지 않음.

정답: D

AWS 리소스 그룹 태그 편집기로 쿼리를 실행하여 애플리케이션 태그가 있는 전역 리소스를 보고합니다.

핵심 요약

요구 사항: 여러 리전(Region)과 여러 서비스(EC2, Lambda 등)에 흩어져 있는 리소스들을 특정 태그(application)를 기준으로 한 번에 찾아내야 함.
해결책 (Resource Groups Tag Editor):
전역 검색: 태그 편집기(Tag Editor)는 모든 AWS 리전과 모든 리소스 유형을 대상으로 태그 기반 검색 쿼리를 실행할 수 있는 중앙 집중식 도구임.
가장 빠른 방법: 별도의 스크립트 작성(CLI)이나 로그 분석(CloudTrail) 없이, 콘솔에서 클릭 몇 번으로 즉시 인벤토리 파악 가능.

오답 노트

A (CloudTrail): API 호출 기록(누가 언제 무엇을 했는지)을 저장하는 곳임. 현재 존재하는 리소스의 상태나 태그 목록을 조회하는 용도가 아님.
B (AWS CLI): 스크립트를 짜서 모든 리전(us-east-1, ap-northeast-2 등)과 모든 서비스(ec2, rds, lambda 등)를 일일이 루프 돌며 쿼리해야 하므로 시간이 오래 걸리고 비효율적임.
C (CloudWatch Logs Insights): 로그 데이터(텍스트)를 검색하는 도구임. 리소스의 메타데이터(태그)를 조회하는 기능은 아님.

AWS Resource Groups & Tag Editor

AWS Resource Groups: 태그를 기반으로 관련 리소스(예: Project=Alpha인 EC2, S3, RDS)를 하나의 그룹으로 묶어 모니터링하거나 자동화 작업을 수행할 수 있게 해주는 서비스.
Tag Editor (태그 편집기):
기능: 리소스 검색 및 대량 태그 수정.
특징: 한 번의 쿼리로 여러 리전의 리소스를 동시에 찾을 수 있음. 마이그레이션 대상 식별이나 비용 할당 태그 관리 시 필수 도구.

태그(Tag) 전략의 중요성

비용 할당(Cost Allocation): 비용 탐색기(Cost Explorer)에서 태그별(예: 부서별, 앱별)로 비용을 청구하기 위해 필수.
자동화: 특정 태그가 있는 인스턴스만 백업하거나 종료하는 자동화 스크립트의 타겟팅 기준으로 사용.
접근 제어(ABAC): IAM 정책에서 태그 조건(Condition: StringEquals: aws:RequestTag/Team)을 사용하여 리소스 접근 권한을 제어.

정답: A

S3 지능형 계층화 (S3 Intelligent-Tiering)

핵심 요약

요구 사항 분석:

가변적인 액세스 패턴: 데이터가 얼마나 자주 조회될지 예측할 수 없으며 패턴이 빠르게 변함.
즉시 사용 가능: 밀리초(ms) 단위의 지연 시간 필요 (Glacier Deep Archive 등 불가).
비용 효율성: 검색 속도 저하 없이 비용을 최적화해야 함.

해결책 (S3 Intelligent-Tiering):
자동 계층 이동: 데이터 액세스 패턴을 모니터링하여, 30일 동안 액세스가 없으면 저렴한 '비정기 액세스(Infrequent Access)' 계층으로, 다시 액세스되면 '빈번한 액세스(Frequent Access)' 계층으로 데이터를 자동으로 이동시킴.
검색 비용 없음: Standard-IA나 Glacier와 달리 데이터 검색(Retrieval) 비용이 발생하지 않아, 액세스 패턴이 불확실할 때 비용 폭탄을 피할 수 있는 유일한 클래스.
성능: S3 Standard와 동일한 밀리초 단위의 낮은 지연 시간 제공.

오답 노트

B (S3 Glacier Instant Retrieval):
저장 비용은 매우 싸지만, 데이터를 읽을 때 검색 비용이 비쌈. 액세스 패턴이 '가변적'이므로 자주 읽게 되면 비용이 오히려 증가함. (분기에 한 번 정도 읽는 데이터에 적합).

C (S3 표준):
가장 일반적이지만 저장 비용이 가장 비쌈. 3개월 동안 데이터가 방치될 경우 비용 효율적이지 않음.

D (S3 표준-IA):
저장 비용은 Standard보다 싸지만, 검색 비용이 발생함. 데이터에 자주 액세스하게 되면 Standard보다 총비용이 더 비싸질 수 있어, 패턴이 불확실할 때는 부적합함.

S3 스토리지 클래스 선택 가이드 (빈출 패턴)

클래스	키워드/특징	적합한 상황
S3 Standard	빈번한 액세스, 낮은 지연 시간	핫 데이터, 패턴 예측 불가하지만 자주 쓰임
S3 Intelligent-Tiering	가변적/알 수 없는 액세스 패턴, 모니터링 비용 발생(객체당)	데이터 수명 주기 동안 얼마나 쓰일지 모를 때 (정답)
S3 Standard-IA	자주 액세스 안 함(한 달에 1번 이하), 즉시 액세스 필요	백업, 오래된 로그, 패턴이 명확히 '드묾'
S3 Glacier Instant Retrieval	거의 액세스 안 함(분기에 1번), 즉시 액세스 필요	의료 영상, 뉴스 아카이브 (저장비 최저, 검색비 높음)
S3 Glacier Flexible/Deep	아카이빙, 검색 시간 수 분~수 시간 소요	규정 준수용 장기 보관, 테이프 백업 대체

팁: 문제에서 "액세스 패턴을 알 수 없다(Unknown)" 또는 "가변적이다(Variable/Changing)"라는 말이 나오면 무조건 Intelligent-Tiering이 정답입니다.

정답: A

AWS WAF 규칙을 구성하고 이를 ALB와 연결합니다.

핵심 요약

요구 사항 분석:

보호 대상: ALB(Application Load Balancer) 뒤에 있는 모바일 앱 백엔드.
공격 유형: XSS(크로스 사이트 스크립팅), SQL Injection 등 애플리케이션 계층(L7) 공격 차단 필요.
제약 사항: 최소한의 인프라/운영 인력 + 서버 관리 책임 감소(Managed Service 선호).

해결책 (AWS WAF):
- 목적 적합성: AWS WAF(Web Application Firewall)는 웹 애플리케이션 보안에 특화된 서비스로, SQL 주입이나 XSS 같은 일반적인 웹 취약점 공격 패턴을 탐지하고 차단합니다.
- 운영 효율성: ALB, API Gateway, CloudFront 등과 직접 연결되는 완전 관리형 서비스이므로, 별도의 보안 서버(EC2)를 구축하거나 관리할 필요가 없어 "서버 관리 책임"을 줄여줍니다.

AWS 보안 서비스 3대장 구분 (빈출 유형)

서비스	방어 계층	주요 방어 대상 (키워드)
AWS WAF (정답)	Layer 7 (애플리케이션)	SQL Injection, XSS, 악성 봇, 특정 IP/국가 차단, HTTP 헤더/바디 검사
AWS Shield	Layer 3/4 (네트워크/전송)	DDoS 공격 (UDP Reflection, SYN Flood 등 대량 트래픽 공격)
AWS Network Firewall	Layer 3~7 (VPC 경계)	VPC 전체의 트래픽 제어, IPS/IDS, URL 필터링 (주로 서브넷/VPC 단위 보호)

시험 팁: 문제에서 "SQL Injection"이나 "XSS(Cross-Site Scripting)" 단어가 보이면 AWS WAF가 정답일 확률이 99%입니다.

정답: B

AWS Glue 크롤러를 만들어 데이터를 검색합니다. AWS Glue 추출, 변환 및 로드(ETL) 작업을 만들어 데이터를 변환합니다. 출력 단계에서 변환된 데이터 버킷을 지정합니다.

핵심 요약

요구 사항 분석:

데이터 변환: 매일 수백 개의 .csv 파일을 Apache Parquet 형식으로 변환.
대상: S3에서 S3로 이동.
최소한의 개발 노력(Least Development Effort): 인프라 관리나 복잡한 코딩을 피해야 함.

해결책 (AWS Glue):
완전 관리형 ETL: AWS Glue는 데이터 추출, 변환, 적재(ETL)를 위한 완전 관리형 서비스임.
자동화 & 편의성: Glue 크롤러(Crawler)로 CSV 스키마를 자동 감지하고, Glue Studio 또는 자동 생성된 스크립트를 통해 클릭 몇 번으로 포맷 변환(CSV → Parquet) 로직을 구현할 수 있음. 개발자가 직접 변환 코드를 처음부터 짤 필요가 없어 개발 노력이 가장 적음.

오답 노트

A (Amazon EMR): Hadoop/Spark 클러스터를 직접 프로비저닝하고 관리해야 하며, Spark 애플리케이션 코드도 직접 작성해야 함. 운영 및 개발 오버헤드가 큼.
C (AWS Batch): 배치 컴퓨팅 작업을 위한 서비스로, 데이터 변환 로직(스크립트 또는 컨테이너)을 직접 구현해야 함. 단순 포맷 변환을 위해 구성하기에는 번거로움.
D (AWS Lambda): 코드를 작성하여 변환할 수 있지만, 메모리 제한이나 실행 시간제한(15분)을 고려해야 하며, 파일 포맷 변환 라이브러리(Pandas, PyArrow 등)를 포함한 배포 패키지를 직접 관리해야 하므로 Glue보다 개발 노력이 더 들어감.

1. AWS Glue vs Amazon EMR (빈출 비교)

서비스	AWS Glue (정답)	Amazon EMR
유형	Serverless 완전 관리형 ETL 서비스	관리형 Hadoop/Spark 클러스터 서비스
주요 용도	데이터 준비, 카탈로그 생성, 간단한 ETL 작업	대규모 데이터 처리, 머신러닝, 복잡한 커스텀 로직
관리 포인트	거의 없음 (작업 정의만 하면 됨)	클러스터 구성, 튜닝, 인스턴스 유형 관리 필요
비용 모델	작업 실행 시간(DPU) 기준 과금	EC2 인스턴스 실행 시간 기준 과금

2. Apache Parquet

정의: 하둡 에코시스템에서 많이 사용되는 열 지향(Columnar) 스토리지 포맷.
장점:
압축 효율: 같은 데이터라도 CSV나 JSON보다 용량이 훨씬 작음 (비용 절감).
쿼리 성능: Athena, Redshift Spectrum 등으로 분석 시 필요한 열(Column)만 읽을 수 있어 스캔 속도가 빠르고 비용이 적게 듦.

AWS 패턴: S3에 원본(CSV/JSON) 저장 → Glue로 Parquet 변환 → Athena/Redshift로 분석하는 것이 정석 아키텍처.

정답: B

S3 버킷에 대한 기본 암호화 설정을 켭니다. S3 인벤토리 기능을 사용하여 암호화되지 않은 객체를 나열하는 .csv 파일을 만듭니다. 복사 명령을 사용하여 해당 객체를 암호화하는 S3 배치 작업(S3 Batch Operations)을 실행합니다.

핵심 요약

요구 사항 분석:

미래의 객체: 앞으로 업로드될 파일도 자동 암호화.
기존의 객체: 이미 저장된 수백만 개의 파일도 암호화.
최소한의 노력: 수동 작업이나 복잡한 스크립트 작성 최소화.

해결책 (S3 Batch Operations):
- 기본 암호화(Default Encryption): 버킷 설정을 켜면 새로 업로드되는 모든 객체는 자동으로 암호화됨. (하지만 기존 객체는 변하지 않음).
- 기존 객체 암호화 방법: 기존 객체에 암호화를 적용하려면 해당 객체를 다시 써야(Re-write) 함. 가장 쉬운 방법은 자기 자신에게 복사(Copy) 하는 것.
- 대량 처리: 수백만 개의 객체를 일일이 복사하는 것은 불가능하므로, S3 Batch Operations를 사용하여 S3 인벤토리(목록)를 기반으로 일괄 복사 작업을 실행하는 것이 가장 효율적임.

오답 노트

A (다운로드/업로드): 수백만 개의 객체를 로컬로 다운로드했다가 다시 올리는 것은 시간과 데이터 전송 비용이 막대하며 비효율적임.
C (설정 변경만 수행): S3 버킷의 기본 암호화 설정을 변경해도 기존에 저장된 객체에는 소급 적용되지 않음. (새로 올리는 것만 적용됨).
D (콘솔 수동 작업): AWS 관리 콘솔(웹 UI)은 한 번에 표시하거나 선택할 수 있는 객체 수에 제한(Pagination)이 있어, 수백만 개를 클릭으로 처리하는 것은 불가능함.

📚 관련 핵심 용어 및 개념 정리

1. S3 Batch Operations (S3 배치 작업)

정의: S3에 저장된 수십억 개의 객체에 대해 일괄적인 작업을 수행할 수 있는 관리형 기능.
주요 기능:
객체 복사 (Copy) - 암호화 적용, 스토리지 클래스 변경, 메타데이터 수정 등에 사용.
AWS Lambda 함수 실행
객체 태그(Tag) 교체
객체 잠금(Object Lock) 보존 설정

작동 방식: S3 Inventory 리포트(CSV)를 입력으로 받아, 지정된 작업을 병렬로 처리함.

2. S3 암호화 소급 적용 (Retroactive Encryption)

중요 포인트: S3 버킷의 "기본 암호화(Default Encryption)" 설정을 켜더라도, 이미 존재하는 객체들은 암호화되지 않은 상태로 유지됨.
해결책: 기존 객체를 암호화하려면 Copy-in-place (소스와 타겟을 같게 하여 복사) 작업을 수행해야 함. 이때 새로운 버킷 설정(암호화)이 적용됨.

정답: A

필요한 인프라 요소가 있는 애플리케이션을 배포합니다. Amazon Route 53을 사용하여 액티브-패시브 장애 조치를 구성합니다. 두 번째 AWS 리전에 Aurora 복제본을 만듭니다.

핵심 요약

요구 사항 분석:

RTO/RPO 30분: 데이터 손실과 복구 시간이 30분 이내여야 함 (비교적 빠른 복구 필요).
평상시 부하 없음: 장애가 없을 때는 2차 리전이 트래픽을 처리하지 않음 (Active-Passive).
데이터베이스: Amazon Aurora 사용.

해결책 (Pilot Light / Warm Standby 패턴):
Active-Passive 구성: Route 53의 장애 조치(Failover) 라우팅 정책을 사용하여 평소에는 기본 리전으로만 트래픽을 보내고, 장애 시에만 보조 리전으로 전환함.
Aurora 복제본(Read Replica): 타 리전에 Aurora 읽기 복제본(또는 Global Database)을 생성해 두면, 데이터가 실시간에 가깝게 복제됨(RPO < 30분 충족). 장애 시 이 복제본을 기본 인스턴스로 승격(Promote)하면 수 분 내에 복구 가능(RTO < 30분 충족).
인프라 배포: 최소한의 인프라(로드 밸런서, 0으로 설정된 ASG 등)를 미리 배포해 두고, 장애 발생 시 신속하게 확장(Scale-out)하는 방식이 적합함.

오답 노트

B, C (Active-Active):
문제에서 "기본 인프라가 정상일 때 부하를 처리할 필요가 없다"고 했으므로, 두 리전이 동시에 트래픽을 받는 Active-Active 구성은 요구 사항에 맞지 않음. (비용 낭비).
C의 경우 "스냅샷 복원"은 데이터 크기에 따라 30분을 초과할 위험이 높음.

D (Backup & Restore):
백업에서 인프라를 새로 만들고 데이터를 복원하는 방식은 가장 저렴하지만 가장 느린(Backup and Restore) 전략임. 30분 이내 복구(RTO)를 장담하기 어려움.

1. AWS 재해 복구(DR) 전략 4단계 (비용 vs 복구 시간)

전략	설명	RTO/RPO	비용
Backup and Restore	데이터만 백업해 두고, 장애 시 인프라 생성 및 데이터 복원.	수 시간 ~ 수일	가장 낮음
Pilot Light (정답 유사)	DB는 복제해 두고, 웹 서버 등은 꺼두거나 최소로 유지. 장애 시 켬.	수십 분 (예: 30분)	낮음
Warm Standby	축소된 버전의 인프라를 항상 켜둠. 장애 시 스케일 업.	수 분	중간
Multi-Site Active/Active	두 리전 모두 트래픽 처리. 즉시 전환.	거의 0 (실시간)	가장 높음

2. Amazon Aurora Global Database

특징: 단일 Aurora DB를 여러 리전에 걸쳐 복제.
성능: 일반적으로 1초 미만의 복제 지연 시간(Lag).
DR: 리전 전체 장애 시, 보조 리전의 DB를 1분 이내에 읽기/쓰기 가능한 마스터로 승격 가능. (RPO/RTO 요건 충족에 최적).

핵심 해설

요구 사항 분석:

웹 서버 액세스: 포트 443(HTTPS)을 통해 외부(0.0.0.0/0)에서 EC2로 들어오는 트래픽을 허용해야 함.
보안 그룹(Security Group) 설정: 인스턴스 레벨의 방화벽.
네트워크 ACL(NACL) 설정: 서브넷 레벨의 방화벽. 현재 "모든 트래픽 차단" 상태이므로 명시적 허용 필요.

해결책 (Stateful vs Stateless):
- A (보안 그룹): 보안 그룹은 상태 저장(Stateful)이므로, 인바운드 규칙(Port 443)만 허용하면 응답 트래픽(Outbound)은 자동으로 허용됨.
- E (NACL): NACL은 상태 비저장(Stateless)이므로, 들어오는 요청(Inbound 443)과 나가는 응답(Outbound Ephemeral Ports)을 각각 명시적으로 허용해야 함. 클라이언트가 요청을 보낼 때 사용하는 임시 포트 대역(32768-65535)을 아웃바운드로 열어줘야 통신이 성립됨.

오답 노트

B (보안 그룹 아웃바운드): 웹 서버가 외부로 요청을 시작할 때 필요한 규칙임. 외부에서 웹 서버로 들어오는 트래픽과는 무관함.
C (NACL 인바운드만): 응답 트래픽이 나가는 규칙이 없어 연결이 성립되지 않음(Stateless).
D (NACL 443 양방향): 아웃바운드 443은 웹 서버가 외부의 443 포트로 접속할 때 쓰임. 클라이언트에게 응답을 보낼 때는 클라이언트의 임시 포트(Ephemeral Port)로 보내야 하므로 443이 아닌 고대역 포트를 열어야 함.

보안 그룹(Security Group) vs 네트워크 ACL(NACL)

특징	보안 그룹 (Security Group)	네트워크 ACL (NACL)
적용 범위	인스턴스(ENI) 레벨	서브넷(Subnet) 레벨
상태(State)	Stateful (상태 저장): 들어온 트래픽의 응답은 자동 허용	Stateless (상태 비저장): 들어오는 것과 나가는 것을 각각 설정해야 함
규칙 유형	허용(Allow)만 가능	허용(Allow) 및 거부(Deny) 모두 가능
순서	모든 규칙이 평가됨	규칙 번호 순서대로 평가됨
임시 포트(Ephemeral Port)	고려할 필요 없음 (자동 처리)	아웃바운드 규칙에 반드시 추가해야 함 (1024-65535 등)

정답: D

CloudFormation 템플릿을 수정합니다. EC2 인스턴스를 R5 EC2 인스턴스로 바꿉니다. EC2 인스턴스에 Amazon CloudWatch 에이전트를 배포하여 향후 용량 계획을 위한 사용자 지정 애플리케이션 지연 메트릭을 생성합니다.

핵심 요약

문제 분석:

메모리 내 작업(In-memory operations): 애플리케이션 성능의 병목이 RAM(메모리)일 가능성이 높음.
M5 사용 중: 현재 범용(General Purpose) 인스턴스 사용 중. 메모리 집약적 작업에는 부적합할 수 있음.
운영 효율성: 수동 개입 없이 인프라를 코드(IaC)로 관리해야 함.

해결책 (R5 + CloudWatch Agent):
- R5 인스턴스 교체: R5 패밀리는 Memory Optimized(메모리 최적화) 인스턴스임. 동일 vCPU 대비 M5보다 약 2배 더 많은 메모리를 제공하여 메모리 부족으로 인한 지연(Latency) 문제를 해결하는 데 최적임.
- CloudWatch Agent: EC2의 기본 메트릭(CPU, 네트워크 등)에는 메모리 사용량이나 애플리케이션 지연 시간이 포함되지 않음. 이를 수집하려면 반드시 인스턴스 내부에 에이전트(Agent)를 설치하여 사용자 지정 지표(Custom Metrics)로 전송해야 함.
- CloudFormation: 콘솔에서 직접 수정하지 않고 템플릿을 수정하여 배포함으로써 구성 드리프트(Drift) 방지 및 재사용성 확보.

1. EC2 인스턴스 패밀리 명명법 (빈출)

패밀리	유형	주요 용도	암기 팁
M (M5, M6g)	General Purpose (범용)	웹 서버, 중소형 DB, 일반적인 워크로드	Main / Middle
R (R5, R6g)	Memory Optimized (메모리 최적화)	인메모리 DB(Redis), 빅데이터 분석, 고성능 DB	RAM
C (C5, C6g)	Compute Optimized (컴퓨팅 최적화)	과학 모델링, 배치 처리, 고성능 웹 서버	CPU / Compute
T (T3, T4g)	Burstable (버스트 가능)	개발 환경, 트래픽이 간헐적인 웹 서버	Tiny / Turbo

2. CloudWatch EC2 메트릭 (Default vs Custom)

기본 제공(Built-in): CPU 사용률, 디스크 I/O(읽기/쓰기), 네트워크 입출력, 상태 검사(Status Check). -> 하이퍼바이저가 밖에서 볼 수 있는 정보들.
사용자 지정(Custom) - 에이전트 필요: 메모리 사용률(RAM), 디스크 여유 공간(Disk Space), 스왑 사용량, 애플리케이션 로그/지연 시간. -> OS 내부에서만 알 수 있는 정보들.

정답: B

AWS Lambda 함수

핵심 요약

요구 사항 분석:

매우 가변적인 트래픽: 요청이 전혀 없는 유휴 시간(수 시간)이 존재함.
빠른 처리: 비동기지만 수 초 내 완료 필요.
최저 비용: 유휴 리소스에 대한 비용 낭비 제거 필요.

해결책 (Serverless):
- Scale-to-Zero (0으로 확장): AWS Lambda는 요청이 들어올 때만 실행되고, 요청이 없으면 비용이 0원임. (EC2나 컨테이너는 대기 상태에서도 비용 발생).
- 이벤트 기반: API Gateway와 기본 통합되어 요청 발생 시 즉시 코드를 실행함.
- 비용 효율성: "단 하나의 요청도 수신하지 않는 시간" 동안 과금되지 않는 유일한 옵션이므로 가장 경제적임.

오답 노트

A (AWS Glue): 데이터 분석 및 ETL(추출, 변환, 적재) 작업용 서비스. API 요청에 대한 실시간/준실시간 응답용으로는 시작 속도가 느리고 비용 구조가 맞지 않음.
C, D (EKS/ECS on EC2):
컨테이너 오케스트레이션 서비스.
요청이 없어도 서비스를 유지하려면 최소한의 인프라(EC2 인스턴스 또는 Control Plane)가 실행되어야 하므로 고정 비용이 발생함.
"수 시간 동안 요청이 없는" 패턴에서는 Lambda보다 비용이 비쌈.

Serverless Computing (서버리스 컴퓨팅)

정의: 서버를 직접 관리하거나 프로비저닝하지 않고 코드를 실행하는 클라우드 모델.
대표 서비스: AWS Lambda.
장점:
비용: 사용한 시간(ms 단위)과 요청 수만큼만 지불. (유휴 비용 없음).
확장성: 트래픽에 따라 자동 확장/축소.
관리: OS 패치, 서버 관리 불필요.

적합한 사용 사례: 가변적인 트래픽, 간헐적인 작업(Cron), 실시간 파일 처리, 마이크로서비스 백엔드.

정답: A

회사 계정에서 IAM 역할을 만들어 공급업체의 IAM 역할에 대한 액세스를 위임합니다. 공급업체가 요구하는 권한에 대한 적절한 IAM 정책을 역할에 첨부합니다.

핵심 요약

요구 사항: 외부 공급업체(다른 AWS 계정)의 자동화 도구가 우리 회사의 AWS 계정 리소스에 접근해야 함.
해결책 (Cross-Account Access with IAM Role):
- 보안 모범 사례: 외부 사용자에게 장기 자격 증명(IAM 사용자 ID/PW)을 공유하는 대신, IAM 역할(Role)을 사용하여 임시 권한을 부여해야 함.
- 위임(Delegation): 회사 계정(Resource Owner)에서 역할을 생성하고, 신뢰 정책(Trust Policy)에 공급업체 계정 ID(Principal)를 추가하여 "이 계정이 역할을 맡을(Assume) 수 있음"을 허용함.
- 공급업체 측: 공급업체의 도구는 sts:AssumeRole API를 호출하여 회사 계정의 역할로 전환, 임시 보안 토큰을 받아 작업을 수행함.

오답 노트

B (IAM 사용자 생성):
장기 자격 증명(Access Key/Secret Key)을 발급하여 외부 업체에 전달해야 하므로 보안 위험이 큼(키 유출, 회전 관리 어려움). 자동화 도구에는 역할 기반 인증이 적합함.

C (IAM 그룹에 타 계정 사용자 추가):
기술적 불가: IAM 그룹에는 해당 계정 내의 IAM 사용자만 포함될 수 있음. 다른 AWS 계정의 사용자를 내 계정의 그룹에 넣는 것은 불가능함.

D (ID 공급자 생성):
IAM 콘솔의 'ID 공급자(Identity Provider)'는 주로 SAML 2.0(기업 AD)이나 OIDC(구글, 페이스북 등) 페더레이션을 위한 기능임. AWS 계정 간의 접근 권한 부여는 ID 공급자가 아니라 IAM 역할의 신뢰 관계로 처리함.

1. IAM Role (역할) vs IAM User (사용자)

구분	IAM User (사용자)	IAM Role (역할)
자격 증명	장기 (비밀번호, 액세스 키)	임시 (STS 토큰, 짧은 만료 시간)
주체	특정 사람이나 애플리케이션 (영구적)	누구나(신뢰된 주체) 맡을 수 있는 모자(Hat)와 같음
사용 사례	계정 내의 관리자, 개발자 등	다른 계정 접근(Cross-Account), EC2/Lambda 서비스 권한, ID 페더레이션

2. AWS STS (Security Token Service)

AssumeRole: 역할을 맡아(Assume) 임시 자격 증명을 받아오는 API 작업.
Cross-Account Access 절차:

계정 A (회사): 역할 생성 + 신뢰 정책에 '계정 B' 등록.
계정 B (공급업체): 자사 사용자/도구에 '계정 A의 역할을 맡을(AssumeRole) 권한' 부여.
동작: 계정 B의 도구가 sts:AssumeRole 호출 -> 계정 A의 임시 키 발급 -> 작업 수행.

핵심 요약

요구 사항: EKS(프라이빗 서브넷)에서 DynamoDB로 데이터 쓰기 + 인터넷 노출 차단 + 보안 권한 부여.
해결책 (IRSA + VPC Endpoint):

A (IAM Roles for Service Accounts - IRSA): EKS 파드(Pod)가 AWS 서비스(DynamoDB)에 접근하려면 권한이 필요합니다. 보안상 가장 안전한 방법은 액세스 키를 코드에 넣거나 노드에 권한을 주는 것이 아니라, 특정 파드에만 IAM 역할을 연결하는 IRSA 기능을 사용하는 것입니다.
D (VPC Endpoint): 프라이빗 서브넷에 있는 애플리케이션이 인터넷 게이트웨이(IGW)나 NAT 게이트웨이를 거치지 않고 DynamoDB에 비공개로 접속하려면 DynamoDB용 게이트웨이 VPC 엔드포인트를 생성해야 합니다. 이를 통해 트래픽이 AWS 내부 네트워크에 머무르게 됩니다.

오답 노트

B (IAM 사용자 연결): IAM 사용자를 파드에 직접 연결하는 개념은 없습니다. 장기 자격 증명(User)보다는 임시 자격 증명(Role)을 사용하는 것이 원칙입니다.
C (네트워크 ACL): ACL 설정만으로는 프라이빗 연결이 성립되지 않습니다. VPC 엔드포인트가 있어야 라우팅이 내부로 처리됩니다.
E (액세스 키 하드코딩): 코드 내에 액세스 키(Access Key/Secret Key)를 포함하는 것은 보안상 절대 금지되는 최악의 안티 패턴입니다. 키 유출 위험이 매우 큽니다.

1. IAM Roles for Service Accounts (IRSA)

개념: Kubernetes의 서비스 계정(Service Account)에 AWS IAM 역할(Role)을 1:1로 매핑해주는 기능.
장점:
최소 권한 원칙: 파드 단위로 세밀한 권한 제어가 가능 (노드 전체에 권한을 주는 것보다 안전).
자격 증명 격리: 한 파드의 권한을 다른 파드가 사용할 수 없음.
편의성: AWS SDK가 자동으로 토큰을 인식하여 인증 처리.

2. DynamoDB용 VPC 엔드포인트 (Gateway Type)

유형: 게이트웨이(Gateway) 엔드포인트. (인터페이스 엔드포인트가 아님).
특징:
VPC 라우팅 테이블(Route Table)에 DynamoDB 접두사 목록(Prefix List)에 대한 경로를 추가하여 동작.
무료로 제공됨.
인터넷을 통하지 않고 AWS 내부 백본망을 통해 통신하여 보안과 네트워크 성능을 모두 향상시킴.

핵심 요약

요구 사항 분석:

고가용성(HA) 및 내결함성(Fault Tolerance): 인프라가 장애를 견뎌야 함.
무작위 트래픽 분산: 실행 중인 모든 인스턴스에 트래픽이 랜덤하게 도달해야 함.
로드 밸런서 언급 없음: 선택지에 ELB가 없으므로 DNS(Route 53) 수준의 부하 분산을 구현해야 함.

해결책 (Route 53 + Balanced Multi-AZ):
C (Multi-value Answer Routing): Route 53 다중 값 답변 라우팅은 DNS 쿼리에 대해 최대 8개의 정상 상태(Healthy) IP 주소를 무작위 순서로 반환합니다. 클라이언트 측 로드 밸런싱을 유도하여 트래픽을 분산시키며, 상태 확인(Health Check)을 통해 비정상 인스턴스를 제외하므로 고가용성 요건에 부합합니다.
E (Balanced Multi-AZ): 서로 다른 가용 영역(AZ)에 인스턴스를 균등하게 배치(2개 + 2개)하는 것이 내결함성에 가장 유리합니다. 한 AZ가 완전히 중단되더라도 나머지 AZ에서 50%의 용량을 유지할 수 있어 안정적입니다.

오답 노트

Failover: 액티브-패시브(Active-Passive) 구성으로, 주 서버 장애 시에만 예비 서버로 트래픽을 보냅니다. "모든 인스턴스에 무작위 분산"이라는 요건에 맞지 않습니다.
Weighted: 가중치 기반 라우팅은 특정 비율(예: 80:20)로 트래픽을 나눌 때 사용합니다. (물론 50:50으로 설정할 수도 있지만, 상태 확인과 다중 IP 반환을 기본 특징으로 하는 Multi-value가 이 시나리오에 더 적합합니다).
Unbalanced: 2개/1개 구성은 불균형합니다. 2개가 있는 AZ가 죽으면 전체 용량의 67%가 손실되므로 내결함성 측면에서 E보다 취약합니다.

Route 53 라우팅 정책 비교 (빈출)

정책	설명	사용 사례
Simple (단순)	하나의 도메인에 하나 이상의 IP 매핑. 라운드 로빈 방식.	단일 리소스 또는 헬스 체크가 필요 없는 간단한 분산.
Failover (장애 조치)	주(Primary)와 보조(Secondary) 리소스 구성.	DR(재해 복구), 액티브-패시브 구성.
Geolocation (지리적 위치)	사용자 위치(국가, 대륙)에 기반해 가장 가까운 리소스로 라우팅.	지역별 콘텐츠 제공, 지연 시간 최소화.
Latency (지연 시간)	네트워크 지연 시간이 가장 짧은 리전으로 라우팅.	글로벌 서비스의 성능 최적화.
Multi-value Answer (다중 값 답변) (정답)	여러 리소스의 IP를 무작위로 반환 + 상태 확인(Health Check).	ELB 없이 DNS 수준에서 트래픽을 분산하고 가용성을 높일 때.

문제 225
미디어 회사가 온프레미스에서 사용자 활동 데이터를 수집하고 분석합니다. 이 회사는 이 기능을 AWS로 마이그레이션하려고 합니다. 사용자 활동 데이 터 저장소는 계속 성장하고 페타바이트 크기가 될 것입니다. 이 회사는 SQL을 사용하여 기존 데이터와 새 데이터의 주문형 분석을 용이하게 하는 고가용 성 데이터 수집 솔루션을 구축해야 합니다. 어떤 솔루션이 최소한의 운영 오버헤드로 이러한 요구 사항을 충족할까요?

A. 활동 데이터를 Amazon Kinesis 데이터 스트림으로 보냅니다. 스트림을 구성하여 데이터를 Amazon S3 버킷으로 전달합니다.

B. 활동 데이터를 Amazon Kinesis Data Firehose 전달 스트림으로 전송합니다. 스트림을 구성하여 데이터를 Amazon Redshift 클러스터로 전달합 니다.

C. Amazon S3 버킷에 활동 데이터를 넣습니다. 데이터가 S3 버킷에 도착하면 데이터에 AWS Lambda 함수를 실행하도록 Amazon S3를 구성합니
다.

D. 여러 가용성 영역에 걸쳐 분산된 Amazon EC2 인스턴스에서 수집 서비스를 만듭니다. Amazon RDS Multi-AZ 데이터베이스로 데이터를 전달하 도록 서비스를 구성합니다.

가장 적절한 솔루션은 A입니다. (다만, 실제 시험 문제의 정확한 원문이나 최신 경향에서는 Kinesis Data Firehose를 사용하여 S3로 전송하고 Amazon Athena로 분석하는 구성이 가장 모범적인 답안입니다. 주어진 보기 중에서는 S3 데이터 레이크 구성을 의미하는 A가 가장 근접합니다.)

하지만, 주어진 보기의 B도 고려해볼 수 있습니다. 일반적으로 Kinesis Data Firehose -> Amazon Redshift 패턴이 많이 나오지만, "페타바이트 규모"와 "운영 오버헤드 최소화", "주문형(On-demand) 분석"이라는 키워드는 S3 + Athena 조합(데이터 레이크)을 강력하게 시사합니다. Redshift 클러스터에 페타바이트 데이터를 직접 적재하는 것은 비용과 관리 측면에서 오버헤드가 매우 큽니다.

따라서 AWS 아키텍처 모범 사례상 S3에 데이터를 저장(Ingestion)해두고, 필요할 때 SQL 엔진(Athena 등)을 붙이는 것이 정답에 해당합니다. 보기 A가 "Kinesis Data Streams"라고 되어 있지만, 문맥상 S3로 데이터를 모으는 파이프라인을 의미하므로 S3 기반 데이터 레이크를 구축하는 A가 정답이 됩니다. (일부 덤프에서는 이 보기가 "Kinesis Data Firehose를 사용하여 S3로 전송"으로 나오기도 합니다. 만약 A가 Kinesis Data Streams이고 B가 Kinesis Data Firehose라면, 데이터 저장소의 적합성(S3 vs Redshift)을 우선 판단 기준으로 삼아야 합니다. 페타바이트급 데이터는 S3가 맞습니다.)

만약 문제의 의도가 "SQL 분석을 위한 완전한 구성"을 묻는 것이고, S3만으로는 SQL이 안 된다고 판단한다면 B가 될 수도 있으나, "페타바이트" 제약 때문에 A (S3 저장 + Athena/Redshift Spectrum 사용 암시)가 훨씬 타당합니다.

핵심 요약

요구 사항 분석:

데이터 규모: 페타바이트 (계속 증가) -> Amazon S3가 필수 (Redshift나 RDS는 비용/관리 부담).
분석 방식: SQL을 사용한 주문형(On-demand) 분석 -> Amazon Athena (또는 Redshift Spectrum).
데이터 수집: 고가용성 -> Kinesis.
운영 오버헤드 최소화: 서버리스/관리형 서비스 선호.

해결책 (Data Lake Architecture):
- 수집 (Ingestion): Amazon Kinesis (Streams 또는 Firehose)를 사용하여 데이터를 안정적으로 수집합니다.
- 저장 (Storage): Amazon S3에 원본 데이터를 저장합니다. S3는 무제한 확장이 가능하고 내구성이 뛰어나며 페타바이트급 데이터에 가장 비용 효율적입니다.
- 분석 (Analysis): (보기에 명시되진 않았지만) S3에 저장된 데이터에 대해 Amazon Athena를 사용하면 서버 관리 없이 표준 SQL로 즉시 분석할 수 있습니다. 이것이 "최소한의 운영 오버헤드"로 "SQL 분석"을 하는 표준 패턴입니다.

오답 노트

B (Kinesis Data Firehose -> Redshift):
Firehose는 훌륭한 수집 도구이지만, 목적지가 Redshift 클러스터인 것이 문제입니다.
페타바이트 규모의 데이터를 Redshift 로컬 스토리지에 모두 적재하려면 막대한 비용이 들고 클러스터 관리(Resizing, Vacuum 등) 오버헤드가 발생합니다. "최소한의 운영 오버헤드" 요건에 맞지 않습니다.

C (S3 -> Lambda):
Lambda는 데이터 수집/처리용이지 SQL 분석 도구가 아닙니다. 데이터가 들어올 때마다 Lambda를 실행하는 것은 대규모 데이터 처리에 비효율적일 수 있습니다.

D (EC2 -> RDS):
EC2를 직접 관리해야 하므로 오버헤드가 크고, RDS(관계형 데이터베이스)는 페타바이트 규모의 비정형/반정형 활동 데이터를 저장하고 분석하기에 적합하지 않습니다.

1. 데이터 레이크(Data Lake) 아키텍처 (S3 + Athena)

구성: Kinesis Data Firehose (수집) -> Amazon S3 (저장) -> Amazon Athena (분석).
특징:
Serverless: 서버 관리 불필요.
Decoupled: 저장(S3)과 연산(Athena)이 분리되어 있어 비용 효율적임.
SQL: Athena는 S3 데이터를 대상으로 표준 SQL 쿼리를 실행함.

⚡시험 팁: "S3에 있는 대용량 데이터", "서버리스 SQL", "로그 분석", "최소 오버헤드"가 나오면 Athena가 정답입니다.

2. Amazon Redshift vs Amazon Athena

구분	Amazon Athena	Amazon Redshift
유형	서버리스 쿼리 서비스	데이터 웨어하우스 (클러스터 기반)
데이터 위치	S3 (외부 테이블)	Redshift 내부 스토리지 (또는 Spectrum으로 S3 조회)
적합한 용도	주문형(On-demand) 쿼리, 로그 분석, 비정기적 분석	복잡한 조인, 고성능 BI, 정형 데이터의 지속적 분석
비용	스캔한 데이터 양($/TB)	노드 시간당 요금 (상시 비용 발생)

핵심 요약

요구 사항 분석:

대규모 확장: 수천 개에서 수백만 개로 늘어나는 원격 장치 트래픽 처리.
RESTful 서비스 대체: EC2 기반의 수집 서버를 더 확장성 있는 구조로 변경 필요.
운영 오버헤드 최소화: 서버 관리(EC2 패치, 오토 스케일링 관리 등)를 줄여야 함 → 서버리스(Serverless) 및 완전 관리형(Managed) 서비스 선호.

해결책 (Serverless Data Ingestion & ETL):
- Ingestion 계층 - API Gateway + Kinesis:
  - Amazon API Gateway: 수백만 개의 장치에서 오는 RESTful 요청을 서버 관리 없이 받아낼 수 있는 가장 확장성 높은 진입점입니다.
  - Amazon Kinesis Data Streams & Firehose: 대량의 실시간 데이터를 안정적으로 버퍼링하고 S3로 자동 적재(Delivery)해주는 관리형 서비스입니다. 이를 통해 EC2 없이 데이터를 수집/저장할 수 있습니다.
- Processing 계층 - AWS Glue:
  - S3에 저장된 원시 데이터(Raw Data)를 변환(Transform)하기 위해 서버(EC2)를 띄우는 대신, 완전 관리형 ETL 서비스인 AWS Glue를 사용하면 운영 부담을 최소화하면서 대용량 데이터를 처리할 수 있습니다.

오답 노트

B (Route 53), C (EC2 추가), D (SQS + EC2):
모두 EC2 인스턴스를 기반으로 하는 솔루션입니다.
장치 수가 '수백만 개'로 늘어날 때 EC2 인스턴스 군(Fleet)을 관리하고 확장(Auto Scaling)하는 것은 관리형 서비스(Kinesis, Glue)에 비해 운영 오버헤드가 훨씬 큽니다.
특히 D의 SQS는 확장성은 좋지만, 데이터를 처리하는 주체(Consumer)로 여전히 EC2를 관리해야 한다는 점이 단점입니다.

1. 대규모 데이터 수집 파이프라인 (Modern Data Architecture)

기존: Device -> EC2 (수집/처리/저장) -> DB/S3
단점: EC2가 병목이 되며, 트래픽 폭주 시 서버 관리가 힘듦.

개선 (정답): Device -> API Gateway -> Kinesis (버퍼링) -> Kinesis Firehose (S3 적재) -> S3 -> Glue (변환) -> Analytics
장점: 각 단계가 독립적으로 확장되며 서버 관리가 필요 없음.

2. Amazon Kinesis 서비스 구분

Kinesis Data Streams: 데이터를 실시간으로 수집하고 처리하기 위한 파이프(버퍼). 데이터를 저장하고 소비자가 읽어갈 수 있게 함.
Kinesis Data Firehose: 스트림의 데이터를 S3, Redshift, OpenSearch 등으로 로드(전송)하는 데 특화된 서비스. (간단한 Lambda 변환도 지원).

3. AWS Glue

정의: 완전 관리형 추출, 변환, 로드(ETL) 서비스.
특징: 서버를 프로비저닝할 필요 없이, 데이터 카탈로그를 생성하고 데이터를 정리/변환하여 분석 준비를 마치는 작업을 자동화함. S3에 쌓인 데이터 레이크 처리에 최적.

정답: B

S3 수명 주기 정책을 구성하여 현재 버전뿐만 아니라 이전 버전도 삭제합니다.

핵심 요약

문제 원인 분석:

S3 버전 관리(Versioning) 활성화: 버킷에 버전 관리가 켜져 있으면, 객체를 '삭제'하더라도 영구 제거되지 않고 '삭제 마커(Delete Marker)'가 추가되며 기존 데이터는 '이전 버전(Non-current Version)'으로 보관됨.
현재 정책의 한계: "3년 후 현재 객체 삭제" 설정만 되어 있음. 이 경우 3년이 지난 로그는 삭제 마커가 붙고 이전 버전으로 쌓이게 됨. 따라서 객체 수(이전 버전 포함)는 줄어들지 않고 계속 증가함.

해결책 (Lifecycle for Non-current Versions):
- 비용 효율성: S3 수명 주기 규칙(Lifecycle Rule)은 별도의 컴퓨팅 비용 없이 스토리지 자체 기능으로 정리해주는 가장 저렴한 방법.
- 이전 버전 정리: 수명 주기 정책 설정에서 '이전 버전의 영구 삭제(Permanently delete noncurrent versions of objects)' 옵션을 추가해야 함. 이를 통해 삭제 마커가 붙거나 덮어씌워진 지 3년이 지난 구버전 파일들을 실제로 제거하여 스토리지 공간을 확보해야 함.

오답 노트

A (CloudTrail 설정): CloudTrail은 로그 생성 및 전달만 담당하며, 저장된 S3 객체의 만료나 삭제를 관리하는 기능은 없음. 이는 전적으로 S3 설정 영역임.
C (Lambda 함수): 수백만/수억 개의 객체를 리스트(List)하고 삭제(Delete)하는 API 호출 비용과 Lambda 실행 비용이 발생함. S3 내장 기능인 수명 주기 정책(무료)보다 훨씬 비효율적임.
D (객체 소유권 변경): 객체 소유권(Object Ownership) 설정은 권한 문제(Access Denied)를 해결하기 위한 것일 뿐, 객체의 삭제나 스토리지 용량 증가 문제와는 무관함.

S3 버전 관리와 수명 주기(Lifecycle)

S3 Versioning (버전 관리): 실수로 인한 삭제나 덮어쓰기를 복구하기 위해 동일 객체의 여러 버전을 저장하는 기능.
Delete Marker (삭제 마커): 버전 관리가 켜진 버킷에서 DELETE 요청을 보내면 데이터가 바로 지워지는 대신, 최신 버전에 '삭제 마커'가 생성됨. (데이터는 이전 버전으로 숨겨짐).
Lifecycle Actions (수명 주기 작업):
Expiration (만료): 현재 버전을 삭제(삭제 마커 생성)하는 작업.
NoncurrentVersionExpiration (이전 버전 만료): 이전 버전(덮어씌워지거나 삭제된 버전)을 영구적으로 삭제하는 작업. 버전 관리 버킷에서는 이 설정이 필수적임.

⚡시험 팁: "S3 버전 관리가 켜져 있는데 용량이 안 줄어든다"는 문제가 나오면 100% "이전 버전(Non-current versions)에 대한 수명 주기 정책 부재"가 원인임.

정답: C

두 개의 NAT 인스턴스를 제거하고 다른 가용성 영역에 있는 두 개의 NAT 게이트웨이로 교체합니다.

핵심 요약

요구 사항 분석:

트래픽 지원 우려: 기존 NAT 인스턴스의 대역폭 한계(병목 현상) 해결 필요.
고가용성(HA) 및 내결함성: 특정 가용 영역(AZ) 장애 시에도 인터넷 연결 유지 필요.
자동 확장: 트래픽 증가에 따라 자동으로 처리량 확장 필요.

해결책 (Multi-AZ NAT Gateway):
- NAT 게이트웨이(Managed Service): AWS에서 관리하는 서비스로, 트래픽 양에 따라 대역폭이 자동으로 확장됩니다(최대 100Gbps). NAT 인스턴스처럼 별도의 인스턴스 타입 관리나 병목 현상 걱정이 없습니다.
- 다중 AZ 배치: NAT 게이트웨이는 단일 AZ에 종속되는 서비스입니다. 내결함성을 확보하려면 각 가용 영역(AZ)마다 별도의 NAT 게이트웨이를 생성하여 해당 구역의 프라이빗 서브넷이 같은 구역의 NAT 게이트웨이를 사용하도록 구성해야 합니다. 이렇게 하면 하나의 AZ가 다운되어도 다른 AZ의 인터넷 연결에는 영향을 주지 않습니다.

오답 노트

A (동일 AZ에 배치): 두 개의 NAT 게이트웨이를 같은 가용 영역에 두면, 해당 AZ에 장애가 발생했을 때 전체 시스템의 인터넷 연결이 끊기게 되므로 내결함성 요건을 충족하지 못합니다.
B (NAT 인스턴스 + Auto Scaling): NAT 인스턴스는 대역폭 제한이 있고 관리가 필요한 레거시(Legacy) 방식입니다. Auto Scaling을 구성하더라도 NAT 게이트웨이만큼의 처리량과 관리 편의성을 제공하지 못하며, 스크립트 등을 통해 라우팅 테이블을 동적으로 수정해야 하는 등 구성이 매우 복잡합니다.
D (스팟 인스턴스): 스팟 인스턴스는 AWS의 필요에 따라 언제든지 중단될 수 있습니다. 안정적인 네트워크 연결이 필수인 NAT 장비로 스팟 인스턴스를 사용하는 것은 부적절합니다.

NAT Gateway vs NAT Instance

특징	NAT Gateway (정답)	NAT Instance
관리 주체	AWS 완전 관리형 (패치, 관리 불필요)	사용자 (OS 패치, 인스턴스 관리 필요)
확장성	트래픽에 따라 자동 확장 (최대 100Gbps)	인스턴스 유형(Type)에 따라 대역폭 고정
고가용성	AZ 내에서 자동 HA 지원 (AZ 장애 대비는 Multi-AZ 배치 필요)	스크립트나 Auto Scaling으로 직접 구현해야 함 (복잡)
비용	사용 시간 + 데이터 처리량당 과금	인스턴스 사용 시간당 과금

⚡아키텍처 팁: "고가용성", "관리 오버헤드 최소화", "자동 확장"이 나오면 무조건 NAT 인스턴스를 버리고 NAT 게이트웨이를 Multi-AZ로 구성하는 것이 정답입니다.

정답: C

Amazon CloudWatch Logs에 VPC 흐름 로그(VPC Flow Logs)를 게시합니다. 필요한 메트릭 필터를 만듭니다. 알람이 ALARM 상태일 때 알림 작업이 있는 Amazon CloudWatch 메트릭 알람을 만듭니다.

핵심 요약

요구 사항: 격리된 VPC 환경에서 특정 포트(RDP: 3389, SSH: 22)로의 네트워크 액세스(트래픽)가 발생하면 운영 팀에 알림.
해결책 (VPC Flow Logs + CloudWatch):
- VPC Flow Logs: VPC의 네트워크 인터페이스에서 송수신되는 IP 트래픽 정보를 캡처합니다. 여기에는 소스/대상 IP, 포트 번호, 프로토콜, 작업(ACCEPT/REJECT) 등이 포함됩니다.
- CloudWatch Metric Filter: 로그 데이터에서 특정 패턴(예: DestPort=22 또는 DestPort=3389 AND Action=ACCEPT)을 찾아 이를 숫자로 된 지표(Metric)로 변환합니다.
- CloudWatch Alarm & SNS: 해당 지표가 기준치를 넘으면(즉, 접속이 발생하면) 경보를 울리고 SNS를 통해 팀에게 이메일/SMS 알림을 보냅니다.

오답 노트

A (Application Insights): 애플리케이션의 오류나 성능 저하를 모니터링하는 도구입니다. 네트워크 포트 접근 제어나 보안 감사용으로는 적합하지 않습니다.
B (SSM IAM 역할): 이는 SSH/RDP 포트를 열지 않고 인스턴스에 접속하기 위한(Session Manager) 설정입니다. 문제에서 요구하는 "액세스가 설정되었을 때 알림을 보내는" 감시 기능과는 무관합니다.
D (EventBridge 상태 변경): "EC2 Instance State-change Notification"은 인스턴스가 running, stopped, terminated 등으로 변하는 상태만 감지합니다. 내부 네트워크 트래픽이나 포트 접속 여부는 알 수 없습니다.

VPC Flow Logs (VPC 흐름 로그)

정의: VPC 내의 네트워크 인터페이스를 오가는 IP 트래픽에 대한 정보를 캡처하는 기능.
사용 사례:
- 보안 그룹 규칙이 제대로 작동하는지 확인.
- 인스턴스로 들어오는 트래픽 모니터링 (누가 SSH/RDP를 시도했는지).
- 네트워크 문제 해결.
저장소: CloudWatch Logs 또는 Amazon S3에 저장 가능.

CloudWatch Logs Metric Filter (메트릭 필터)

기능: 로그 데이터(텍스트)를 검색하여 특정 단어나 패턴이 등장하는 횟수를 CloudWatch 지표(숫자)로 변환.
예시: 로그에서 "Error"라는 단어가 몇 번 나왔는지, 또는 "Port 22" 접속이 몇 번 있었는지 카운트하여 알람 생성에 활용.

A. 루트 사용자가 강력한 비밀번호를 사용하는지 확인하세요.
B. 루트 사용자에 대해 다중 요소 인증(MFA)을 활성화합니다.

핵심 요약

루트 사용자(Root User) 보안: AWS 계정 생성 시 만들어지는 루트 사용자는 모든 권한을 가지고 있어 제어가 불가능하므로 보안이 최우선입니다.
필수 조치 2가지:

강력한 암호: 무차별 대입 공격 등을 방지하기 위해 복잡하고 긴 비밀번호 설정.
MFA 활성화: 비밀번호가 유출되더라도 OTP(One Time Password) 장치 없이는 로그인할 수 없도록 2단계 인증을 반드시 설정해야 합니다.

오답 노트

C (액세스 키 저장): 루트 사용자의 액세스 키는 생성하지 않는 것이 모범 사례입니다. 만약 존재한다면 삭제해야 합니다. 절대 저장해서는 안 됩니다.
D (그룹 추가): 루트 사용자는 IAM 사용자(User)가 아니므로 IAM 그룹에 추가할 수 없습니다. 루트 사용자는 이미 모든 권한을 갖고 있습니다.
E (인라인 정책): 루트 사용자의 권한은 IAM 정책으로 제한하거나 수정할 수 없습니다. (SCP로 계정 전체 제한은 가능하지만, 루트 사용자에게 직접 정책을 연결할 수는 없음).

AWS 루트 사용자 모범 사례 (Best Practices)

MFA 활성화: 하드웨어 또는 가상 MFA 디바이스 등록.
액세스 키 삭제: 프로그래밍 방식의 액세스(CLI/SDK)에 루트 계정을 사용하지 말 것.
사용 자제: 계정 설정을 마치면 즉시 로그아웃하고, 일상적인 작업은 IAM 관리자(Administrator) 사용자를 생성하여 사용해야 함. "루트 계정을 금고에 잠가두라"는 것이 원칙.
연락처 정보 최신화: 보안 문제 발생 시 연락받을 수 있도록 이메일/전화번호 유지.

AWS Key Management Service(AWS KMS)를 사용하여 EBS 볼륨과 Aurora 데이터베이스 저장소를 휴면 상태로 암호화합니다. AWS Certificate Manager(ACM) 인증서를 ALB에 연결하여 전송 중인 데이터를 암호화합니다.

핵심 요약

요구 사항 분석:

저장 시 암호화 (Data at Rest): EBS 볼륨(EC2 스토리지)과 Aurora 데이터베이스.
전송 시 암호화 (Data in Transit): 클라이언트와 서버(ALB) 간의 통신.

해결책 (KMS + ACM):
- 저장 시 암호화 (KMS): AWS 스토리지 서비스(EBS, Aurora, RDS, S3 등)의 데이터 암호화는 AWS KMS(Key Management Service) 키를 사용하는 것이 표준입니다. EBS 볼륨 생성 시와 Aurora 클러스터 생성 시 KMS 키를 선택하여 간단히 암호화를 활성화할 수 있습니다.
- 전송 시 암호화 (ACM): 웹 트래픽(HTTPS)을 암호화하려면 SSL/TLS 인증서가 필요합니다. AWS Certificate Manager(ACM)는 공인 인증서를 무료로 발급하고 관리(자동 갱신)해주며, 이를 ALB(Application Load Balancer)에 연결하여 HTTPS 리스너를 구성하는 것이 정석입니다.

1. AWS 암호화 서비스 구분 (빈출)

서비스	AWS KMS (Key Management Service)	AWS ACM (Certificate Manager)
주 목적	데이터 암호화 키 관리	SSL/TLS 인증서 관리
대상	저장 데이터 (Data at Rest): EBS, RDS, S3, DynamoDB 등	전송 데이터 (Data in Transit): ALB, CloudFront, API Gateway
작동 방식	데이터를 암호화/복호화하는 대칭/비대칭 키 생성 및 제어	도메인 인증서를 발급하여 HTTPS 통신 보안 제공

2. 저장 데이터 암호화 (Encryption at Rest)

EBS, RDS, Aurora 등은 리소스를 생성할 때 암호화를 활성화해야 합니다. (생성 후에는 스냅샷 복사 등을 통해서만 적용 가능).
이때 사용되는 암호화 키(Customer Master Key)는 KMS에서 관리됩니다.

정답: C

메모리 최적화 복제 인스턴스를 사용하여 AWS Database Migration Service(AWS DMS)와 함께 AWS Schema Conversion Tool을 사용합니다. 전체 로드 플러스 변경 데이터 캡처(CDC) 복제 작업과 테이블 매핑을 만들어 모든 테이블을 선택합니다.

핵심 요약

요구 사항 분석:

이종 마이그레이션: Oracle → Aurora PostgreSQL (엔진이 다름).
단계적 마이그레이션 & 동기화: 애플리케이션이 하나씩 이동하는 몇 달 동안 데이터가 계속 동기화(CDC)되어야 함.
높은 부하: 읽기/쓰기가 많음 → 성능 최적화 필요.

해결책 (SCT + DMS Memory Optimized):
- AWS SCT (Schema Conversion Tool): 데이터베이스 엔진이 다르므로(Heterogeneous), Oracle의 스키마(테이블, 뷰, 함수 등)를 PostgreSQL 호환 형식으로 변환하려면 SCT가 필수입니다.
- DMS Full Load + CDC: 초기 데이터를 옮기는 '전체 로드'와 마이그레이션 기간 동안 변경 사항을 실시간으로 복제하는 'CDC(변경 데이터 캡처)'를 함께 구성해야 합니다.
- 메모리 최적화 인스턴스 (Memory Optimized): DMS는 트랜잭션 로그를 버퍼링하고 변환하는 과정에서 메모리를 많이 사용합니다. 문제에서 "읽기와 쓰기가 많다"고 했으므로, 처리량을 감당하기 위해 dms.r5와 같은 메모리 최적화 인스턴스 유형을 사용하는 것이 권장됩니다.
- 모든 테이블 선택: 여러 애플리케이션이 "동일한 테이블"에 쓴다고 했으므로, 일부(가장 큰 테이블)가 아닌 모든 테이블을 매핑해야 정합성이 유지됩니다.

오답 노트

A, B (AWS DataSync):
- DataSync는 NFS, SMB, EFS, S3 간의 파일(File) 데이터를 이동하는 서비스입니다. 실행 중인 데이터베이스(Oracle)를 마이그레이션하거나 실시간 트랜잭션을 동기화하는 데는 사용할 수 없습니다.

D (컴퓨팅 최적화 & 가장 큰 테이블):
- 테이블 선택 오류: "가장 큰 테이블"만 선택하면 나머지 테이블을 사용하는 애플리케이션은 오류가 발생합니다. 모든 테이블을 복제해야 합니다.
- 인스턴스 유형: DMS의 고부하 작업(특히 대용량 트랜잭션이나 LOB 처리)에서는 일반적으로 컴퓨팅(C타입)보다 메모리(R타입) 리소스가 병목 해결에 더 중요합니다.

1. AWS DMS (Database Migration Service)

기능: 관계형 데이터베이스, 데이터 웨어하우스, NoSQL 데이터베이스 등을 마이그레이션하는 서비스.
마이그레이션 유형:
Full Load (전체 로드): 현재 데이터를 한 번에 덤프.
CDC (Change Data Capture): 마이그레이션 중 발생하는 변경 사항(INSERT, UPDATE, DELETE)을 실시간으로 캡처하여 적용. (다운타임 최소화 및 지속적 동기화의 핵심)
Full Load + CDC: 초기 데이터 이동 후 계속 동기화 유지. (정답 패턴)

2. AWS SCT (Schema Conversion Tool)

용도: 소스 DB(Oracle, MS SQL 등)와 타겟 DB(Aurora, RDS MySQL/PostgreSQL)의 엔진이 다를 때, 스키마와 코드(PL/SQL 등)를 자동으로 변환해주는 도구.
순서: SCT로 스키마 변환 및 적용 → DMS로 데이터 이동.

3. DMS 복제 인스턴스 유형 선택

T2/T3 (범용/버스트): 개발/테스트 또는 매우 작은 워크로드.
C4/C5 (컴퓨팅 최적화): CPU 연산이 많은 작업 (이종 마이그레이션에서 변환 작업이 극도로 많을 때 사용되기도 함).
R4/R5 (메모리 최적화): 높은 트랜잭션 처리량, 대용량 메모리 내 버퍼링이 필요한 프로덕션 마이그레이션. (고부하 환경의 표준 권장 사항)

프런트엔드 계층과 애플리케이션 계층에 로드 밸런싱된 Multi-AZ AWS Elastic Beanstalk 환경을 사용합니다. 데이터베이스를 Amazon RDS Multi-AZ DB 인스턴스로 이동합니다. Amazon S3를 사용하여 사용자의 이미지를 저장하고 제공합니다.

핵심 요약

요구 사항 분석:

3계층 애플리케이션: Frontend + App + DB (MySQL).
확장성(Scalable) 및 고가용성(HA): 단일 장애 지점(Single Point of Failure) 제거 및 자동 확장 필요.
최소한의 변경(Minimal Changes): 코드를 완전히 다시 짜거나 아키텍처를 뒤엎는 방식(예: 서버리스 전환)은 피해야 함.
이미지 공유: 대용량 미디어 파일 처리 필요.

해결책 (Elastic Beanstalk + RDS + S3):
- Elastic Beanstalk: 기존 애플리케이션 코드(Java, PHP, Python 등)를 그대로 가져가면서 로드 밸런싱(ELB)과 Auto Scaling 환경을 자동으로 구축해줍니다. EC2를 직접 관리하는 것보다 운영이 쉬우며 코드를 수정할 필요가 거의 없습니다.
- RDS Multi-AZ: 자체 관리형 MySQL(EC2)을 관리형 서비스인 RDS로 옮기는 것은 '리프트 앤 시프트(Lift and Shift)'의 정석입니다. Multi-AZ를 켜면 동기식 복제를 통해 고가용성을 즉시 확보할 수 있습니다.
- Amazon S3: 이미지와 같은 정적 자산(Static Assets)은 웹 서버나 DB에 저장하는 것보다 S3에 저장하는 것이 확장성과 비용 면에서 가장 효율적입니다.

1. AWS Elastic Beanstalk

정의: 애플리케이션 코드를 업로드하기만 하면 배포, 로드 밸런싱, Auto Scaling, 상태 모니터링을 자동으로 처리해주는 PaaS(Platform as a Service).
장점: 인프라 설정에 시간을 쏟지 않고 코드 개발에 집중 가능. 기존 레거시 앱을 클라우드 네이티브 환경(Auto Scaling 등)으로 가장 쉽게 옮기는 방법 중 하나.

2. 정적 자산 분리 (Offloading Static Content)

개념: 이미지, CSS, JS, 동영상 파일 등은 웹 서버(EC2)나 DB에서 직접 제공하지 않고 별도의 스토리지(S3)나 CDN(CloudFront)을 통해 제공하는 패턴.
이유:
웹 서버의 CPU/메모리 부하 감소.
스토리지 비용 절감.
전송 속도 향상.

정답: A

VPC-A와 VPC-B 사이에 VPC 피어링 연결을 설정합니다.

핵심 요약

요구 사항 분석:

VPC 간 연결: 서로 다른 AWS 계정의 VPC-A(EC2)와 VPC-B(EC2) 간 통신.
단일 장애 지점(SPOF) 없음: 고가용성 보장 필요.
대역폭 문제 없음: 병목 현상 없는 고성능 네트워크 필요.

해결책 (VPC Peering):
- 직접 연결: VPC 피어링은 AWS 백본 네트워크를 통해 두 VPC를 마치 같은 네트워크에 있는 것처럼 연결하는 네트워킹 기능임.
- 교차 계정 지원: 서로 다른 AWS 계정 간의 연결을 완벽하게 지원함.
- 성능: 게이트웨이나 VPN 장비 같은 물리적 병목 지점이 없으며(No SPOF), 인스턴스의 네트워크 성능만큼 최대 대역폭을 사용할 수 있음.

오답 노트

B (게이트웨이 엔드포인트): 이는 Amazon S3 및 DynamoDB에 비공개로 액세스하기 위한 기술임. EC2 인스턴스 간 통신에는 사용할 수 없음.
C (가상 사설 게이트웨이 - VGW): 주로 온프레미스와의 VPN 연결이나 Direct Connect에 사용됨. 두 VPC를 직접 연결하는 데는 적합하지 않으며, VPN을 구성할 경우 대역폭 제한이 발생함.
D (개인 가상 인터페이스 - Private VIF): AWS Direct Connect 연결을 위한 구성 요소임. 온프레미스 데이터 센터와 AWS를 연결할 때 사용하며, VPC 간 연결 기술이 아님.

VPC Peering (VPC 피어링)

정의: 두 VPC 간의 비공개 IPv4/IPv6 트래픽 라우팅을 가능하게 하는 네트워킹 연결.
제약 사항:
- CIDR 블록(IP 대역)이 겹치면(Overlap) 연결 불가.
- 전이적 라우팅(Transitive Peering) 미지원 (A↔B, B↔C 연결 시 A↔C 자동 연결 안 됨).
비용: 동일 리전 내 데이터 전송은 무료(가용 영역 간 전송 비용은 발생), 타 리전 간 연결(Inter-Region)은 표준 데이터 전송 요금 발생.

정답: C

AWS Budgets를 사용하여 각 계정에 대한 비용 예산을 만듭니다. 기간을 월로 설정합니다. 범위를 EC2 인스턴스로 설정합니다. 예산에 대한 알림 임계값을 설정합니다. 임계값을 초과하면 알림을 받도록 Amazon Simple Notification Service(Amazon SNS) 토픽을 구성합니다.

핵심 요약

요구 사항 분석:

대상: 엔지니어별 개별 AWS 계정.
조건: 특정 월의 EC2 사용량이 임계값을 초과하는 즉시.
목표: 비용 효율적인 알림 수신.

해결책 (AWS Budgets):
- 목적 적합성: AWS Budgets는 비용이나 사용량이 설정한 한도를 넘거나(또는 넘을 것으로 예상될 때) 알림을 보내는 데 특화된 서비스입니다.
- 필터링: 예산 범위를 '서비스: EC2'로 특정하여 EC2 비용만 모니터링할 수 있습니다.
- 비용 효율성: AWS Budgets는 계정당 처음 2개의 예산은 무료이며, 이후에도 매우 저렴합니다. 별도의 인프라를 구축할 필요가 없어 가장 경제적입니다.
- 알림: Amazon SNS와 연동하여 이메일, SMS 등으로 즉시 경고를 보낼 수 있습니다.

오답 노트

A, B (Cost Explorer):
- Cost Explorer(비용 탐색기)는 비용 데이터를 시각화하고 분석하는 도구입니다. 보고서 기능은 있지만, "실시간 임계값 트리거" 및 "SES를 통한 자동 알림" 기능은 기본적으로 제공하지 않습니다. 이 기능은 AWS Budgets의 역할입니다.

D (CUR + Athena + EventBridge):
- 비용 및 사용 보고서(CUR)를 S3에 쌓고 Athena로 쿼리하는 방식은 매우 강력한 분석 도구이지만, 단순 알림을 위해 구축하기에는 구성이 너무 복잡하고(Over-engineering) S3 저장 비용 및 Athena 쿼리 비용이 발생하여 비용 효율적이지 않습니다.

AWS Budgets (AWS 예산)

기능: 사용자가 정의한 예산 한도를 설정하고, 비용이나 사용량이 이 한도를 초과할 때(실제 발생 기준) 또는 초과할 것으로 예상될 때(예측 기준) 알림을 발송.
유형: 비용 예산, 사용량 예산(RI/Savings Plans 사용률 등), 예약 인스턴스 예산.
알림 채널: 이메일, Amazon SNS(SMS/Slack 연동), AWS Chatbot.

함수에 대한 Lambda 함수 URL을 만듭니다. 인증 유형으로 AWS_IAM을 지정합니다.

핵심 요약

요구 사항 분석:

HTTPS 엔드포인트: 클라이언트가 웹을 통해 접근 가능해야 함.
IAM 인증: AWS_IAM 방식을 통해 호출 권한을 제어해야 함.
단일 Lambda 함수: 마이크로서비스 로직이 하나의 함수에 있음.
운영 효율성(Operationally Efficient): 구성 및 관리 오버헤드가 가장 적어야 함.

해결책 (Lambda Function URL):
- Lambda 함수 URL: 별도의 게이트웨이 서비스(API Gateway, ALB)를 프로비저닝하거나 구성할 필요 없이, Lambda 함수에 직접 HTTPS 엔드포인트를 부여하는 기능입니다.
- 기본 지원: 설정에서 인증 유형(Auth Type)을 AWS_IAM으로 선택하기만 하면 요구 사항을 완벽하게 충족합니다.
- 효율성: API Gateway를 생성하고 메서드, 통합, 배포 단계를 거치는 것보다 훨씬 간단하며 추가 비용이나 관리 포인트가 없어 가장 효율적입니다.

오답 노트

A (API Gateway):
- 가장 일반적인 방식이며 요구 사항을 모두 충족합니다. 하지만 API Gateway 리소스를 생성하고, 메서드를 구성하고, 배포하는 과정이 함수 URL보다 복잡합니다. "가장 운영적으로 효율적인" 방법을 묻는 문제에서는 인프라 구성이 더 적은 B가 정답입니다. (만약 고급 라우팅이나 사용량 제한 등이 필요했다면 A가 정답일 수 있습니다.)

C (CloudFront + Lambda@Edge):
- 구성이 매우 복잡하며, Lambda@Edge는 주로 콘텐츠 전송 로직(헤더 수정 등)에 사용됩니다. IAM 인증을 직접 구현하거나 통합하는 것은 기본 기능이 아니며 운영 오버헤드가 큽니다.

D (CloudFront Functions):
- CloudFront Functions는 JavaScript만 지원하므로 Go 1.x 런타임을 사용할 수 없습니다. 또한 AWS_IAM 인증을 기본적으로 지원하지 않습니다.

Lambda Function URLs (Lambda 함수 URL)

정의: Lambda 함수를 위한 전용 HTTP(S) 엔드포인트.
특징:
간편함: API Gateway 없이 함수 생성 시 체크박스 하나로 URL 생성 가능.
인증 유형:
NONE: 누구나 접근 가능 (퍼블릭).
AWS_IAM: IAM 권한이 있는 사용자/역할만 호출 가능.

사용 사례: 단일 함수 마이크로서비스, 웹훅(Webhook) 수신, 간단한 양식 처리.

API Gateway와의 차이:
함수 URL은 타임아웃(최대 15분)이 길고 비용이 저렴(추가 비용 없음).
API Gateway는 요청 검증, 속도 제한(Throttling), WAF 연동, 사용자 지정 도메인 등 고급 기능 제공.

데이터 웨어하우스와 동일한 AWS 지역에 시각화 도구를 호스팅하고 동일한 지역의 위치에서 Direct Connect 연결을 통해 액세스합니다.

핵심 요약

비용 발생 원인 분석 (Data Transfer Egress):

쿼리 결과: 50MB (대용량)
웹 페이지(UI): 500KB (소용량)
핵심 전략: AWS 외부로 나가는 데이터 양을 최소화해야 함.

해결책 비교:
- 온프레미스 호스팅 (A, C): 50MB의 대용량 쿼리 결과가 매번 AWS에서 외부(온프레미스)로 전송됨. 데이터 전송 비용이 매우 높음.
- AWS 호스팅 (B, D): 시각화 도구가 AWS 내부에 있으므로, 50MB 데이터는 AWS 내부 네트워크에서 이동(동일 리전일 경우 무료 또는 매우 저렴). 외부 사용자에게는 500KB의 화면 데이터만 전송하면 됨.
- 인터넷 vs Direct Connect (B vs D): 500KB 데이터를 전송할 때, 일반 인터넷 요금보다 Direct Connect의 데이터 전송 요금이 더 저렴함.

결론: 대용량 데이터 트래픽(50MB)을 AWS 내부에 가두고, 소용량 트래픽(500KB)만 가장 저렴한 경로(Direct Connect)로 전송하는 D가 최적의 솔루션임.

오답 노트

A, C (온프레미스 호스팅): 시각화 도구가 온프레미스에 있으면 쿼리할 때마다 50MB의 데이터가 외부로 나가게 되어 막대한 이탈 비용(Egress Cost) 발생.
B (AWS 호스팅 + 인터넷): D와 마찬가지로 50MB 트래픽은 절약되지만, 500KB 데이터를 보낼 때 Direct Connect보다 비싼 인터넷 망 요금을 지불해야 하므로 D보다 비용 효율성이 떨어짐.

도은호

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

다음 포스트

AWS SAA 해설 20251219

AWS SAA

1. Amazon ElastiCache (Redis vs Memcached)

2. 캐싱 전략 (Caching Strategy)

3. RDS 읽기 복제본 (Read Replica)

1) Multi-AZ(고가용성) vs Multi-Region(DR)

2) “DB를 EC2에서 운영해야 할 때”의 HA 패턴

3) EC2 Auto Recovery의 한계

1) Decoupling(디커플링)과 비동기 처리

2) SQS 핵심 키워드

3) EC2 Auto Scaling + SQS 연동 운영 포인트

4) “주문” 워크로드에서 특히 중요한 설계

핵심 요약

선택지 분석

B. AWS Elastic Beanstalk에서 .NET 플랫폼 사용 (다중 AZ)

E. Amazon RDS for Oracle로 마이그레이션 (다중 AZ)

📚 관련 핵심 용어 및 개념 정리

1. 클라우드 마이그레이션 전략 (The 6 R's)

2. 데이터베이스 마이그레이션 유형

1. AI/ML 서비스 구분 (빈출 유형)

2. 데이터 분석 서비스

1. API Gateway의 주요 인증/인가 방식 3가지 (빈출 비교)

2. API Key의 용도

1) API Gateway 인증/인가 옵션 비교

2) Cognito 토큰 흐름

3) “Access control”의 의미

핵심 요약

오답 노트

1. Amazon Pinpoint vs Amazon SNS (SMS 관련)

2. Amazon Kinesis (데이터 스트리밍)

핵심 요약

오답 노트

AWS KMS 키 로테이션 주기 (빈출 암기 포인트)

핵심 요약

오답 노트

1. CloudFront와 S3 보안 (OAI vs OAC)

2. 정적 웹사이트 호스팅 아키텍처 비교

3. AWS Transfer Family

정답

핵심 요약

오답 노트

1. Amazon EventBridge (vs CloudWatch Events)

2. AWS CloudTrail과의 관계

정답:

핵심 요약

Queue-Based Load Leveling (대기열 기반 부하 평준화)

정답: B (가장 적절한 솔루션)

핵심 요약

VPC Endpoint 유형 비교 (S3 기준)

정답: A

핵심 요약

세션 관리 전략 비교 (Stateful vs Stateless)

정답: D

핵심 요약

오답 노트

1. Backlog Per Instance (인스턴스당 백로그)

2. 결합 해제 (Decoupling)

정답: D

핵심 요약

오답 노트

AWS Resource Groups & Tag Editor

태그(Tag) 전략의 중요성

정답: A

핵심 요약

오답 노트

S3 스토리지 클래스 선택 가이드 (빈출 패턴)

정답: A

핵심 요약

AWS 보안 서비스 3대장 구분 (빈출 유형)

정답: B

핵심 요약

오답 노트

1. AWS Glue vs Amazon EMR (빈출 비교)

2. Apache Parquet

정답: B

핵심 요약

오답 노트

📚 관련 핵심 용어 및 개념 정리

1. S3 Batch Operations (S3 배치 작업)

2. S3 암호화 소급 적용 (Retroactive Encryption)