[SAA-C03] 문제 유형 131-140 정리

Q131)

초기 S3 버킷→ 분석 S3 버킷으로 자동 복사
파일이 들어오면 자동 처리
복사된 데이터에 대해:
Lambda에서 패턴 일치 코드 실행
SageMaker Pipelines로 전달
최소한의 운영 오버헤드

1. S3 버킷 간 복제 (Replication)
완전 관리형

코드 불필요
대용량 파일에도 적합
운영 오버헤드 최소

2. 분석 버킷 → EventBridge로 이벤트 전송
(복잡한 워크플로우에는 EventBridge가 정답)

3. EventBridge Rule에서:
Lambda 트리거
SageMaker Pipeline 트리거

S3 버킷 간 복제 (S3 Replication)
-> 한 S3 버킷의 객체를 자동으로 다른 버킷으로 복사하는 완전관리형 기능
(코드 작성 없이 설정만으로 동작)

SRR (Same-Region Replication) // 같은 리전 내 버킷 간 복제
CRR (Cross-Region Replication) // 다른 리전 간 복제

흐름.
1. 누군가 초기 S3 버킷에 파일 업로드
2. S3가 자동으로 감지
3. 복제 규칙에 따라 분석 S3 버킷으로 자동 복사
4. 복사 완료 후 분석 버킷에서 이벤트 발생 가능

SageMaker Pipeline
-> ML 워크플로우를 자동화하는 서비스
// 데이터 전처리 → 학습 → 평가 → 배포
이 전체 과정을 자동으로 연결해주는 ML 파이프라인 엔진


#시험 포인트
버킷 간 자동 복사는 Lambda가 아니라 S3 Replication, 
다중 후속 처리 트리거는 EventBridge를 사용

---

Q132)

데이터 수집 / EC2  
-> 사용량 예측 불가, 언제든지 중단 가능
프론트엔드 / Fargate
-> 사용량 예측 가능
API 계층 / Lambda
-> 사용량 예측 가능

데이터 수집 계층 – EC2
// 사용량 예측 불가, 언제든지 중단 가능
-> Spot Instance
// 중단 가능 워크로드에 적합
// 예측 불가능한 사용량에도 적합

프런트엔드+API 계층 - Fargate, Lambda
// 사용량 예측 가능
-> Compute Savings Plan
(EC2, Fargate, Lambda 모두 적용)

참고. EC2 Instance SP는 EC2만


#시험 포인트
중단 가능 EC2 = Spot,
Fargate/Lambda 포함 = Compute Savings Plan

---

Q133)

전 세계 사용자
가능한 한 빠르게 제공
정적 + 동적 콘텐츠 혼합
HTTPS
ALB 뒤 EC2 API 서버

-> 단일 리전 + CloudFront + ALB를 오리진으로 정적/동적 모두 제공

CloudFront는 전 세계 엣지 로케이션 보유
정적 콘텐츠 → 엣지 캐싱
동적 콘텐츠 → 엣지에서 TCP 연결 재사용
AWS 글로벌 백본 통해 원본(ALB)까지 전달
동적 콘텐츠도 가속 가능 (Dynamic Content Acceleration)
(전 세계 사용자 지연 최소화에 가장 적합)

CloudFront 엣지 → ALB 구간은
공용 인터넷이 아니라
AWS 전용 글로벌 네트워크(백본) 사용

(참고. Route53은 DNS 레벨 라우팅)


#시험 포인트
전 세계 사용자 + 정적/동적 혼합 + 최소 지연
→ CloudFront를 ALB 앞에 둔다

---

Q134)

UDP 기반 트래픽 -> ALB 불가
가장 가까운 엣지 로케이션 -> 글로벌 가속 필요
고정 IP 주소 제공 -> Anycast Static IP 필요
낮은 지연 시간 -> AWS 글로벌 네트워크 사용

// CloudFront는 UDP 지원 안 함
→ HTTP / HTTPS 전용

// ALB는 UDP 지원 안 함
→ Layer 7 (HTTP/HTTPS)

// UDP 지원하는 것은?
Network Load Balancer (L4)

고정 IP + 엣지 라우팅 = AWS Global Accelerator

Global Accelerator
// Anycast 고정 IP 제공, UDP 지원
가장 가까운 엣지로 라우팅,
AWS 글로벌 백본 사용, NLB 지원


#시험 포인트
UDP + 고정 IP + 엣지 라우팅 = Global Accelerator + NLB

---

Q135)

기존 코드 최대한 유지 -> 리팩토링 최소화
더 작은 애플리케이션으로 분리 -> 마이크로서비스
팀별로 각각 관리 -> 서비스 단위 배포
확장성, 운영 오버헤드 최소화

코드를 최대한 유지
→ Lambda로 옮기면 대규모 리팩토링 필요
→ 서버리스 구조로 완전 변경해야 함(EC2관리 X)

더 작은 애플리케이션으로 분리
→ 컨테이너 기반 마이크로서비스

운영 오버헤드 최소화 -> 서버리스

Amazon ECS
컨테이너화 → 기존 코드 거의 그대로 유지
애플리케이션을 서비스 단위로 분리 가능
팀별 서비스 관리 가능
확장성 뛰어남
Fargate 사용 시 서버 관리 불필요

모놀리식(Monolithic) 애플리케이션
-> 모든 기능이 하나로 붙어 있는 구조(덩어리)


#시험 포인트
모놀리식 → 마이크로서비스 전환 + 코드 유지 + 운영 최소화
-> 컨테이너(ECS)

---

Q136)

운영 DB: Amazon Aurora
전자상거래 앱 (실시간 트랜잭션 처리)
월별 대규모 보고서 실행 시
ReadIOPS 급증
CPUUtilization 급증
-> 앱 성능 저하 발생

전자상거래 애플리케이션은 OLTP (트랜잭션 처리)
월별 보고서는 대량 읽기 작업 (OLAP 성격)
->문제:  운영 트랜잭션과 분석 쿼리가 같은 DB를 공유

해결: Aurora 읽기 전용 복제본으로 보고서 실행

Aurora Read Replica
// 읽기 전용, 
동일 데이터 읽기 트래픽 분산, 
비교적 저렴, 간단히 추가 가능

(보고서 작업을 복제본으로 보내면)
-> 운영 DB CPU 감소
-> ReadIOPS 분산
-> 애플리케이션 성능 회복
-> 비용 효율적 


#시험 포인트
운영 DB 성능 저하 + 보고서 작업 → Read Replica로 읽기 분리

---

Q137)

[ 단일 EC2 ]
 ├ PHP 웹서버
 ├ 분석 애플리케이션
 └ MySQL DB

문제:
단일 장애 지점 (SPOF)
확장 불가
바쁜 시간에 5xx 에러
수직 확장만 가능

요구사항.
원활한 확장 / 비용 효율적
5xx 오류 해결 / 확장 가능한 구조

DB → Aurora MySQL (관리형, 확장성 좋음)
Launch Template -> AMI 생성
Auto Scaling Group
Spot 사용 -> 비용절감 
(but 아마존이 사용 많을 때 종료한다면? 안 좋은 선택)
ALB 연결


#시험 포인트
애플리케이션 원활하게 확장 -> Auto Scaling

---

Q138)

ALB 뒤 EC2 온디맨드 인스턴스 그룹
상태 비저장 웹 애플리케이션을 실행 
매일 8시간 동안 애플리케이션 사용량이 많음
응용 프로그램 사용량은 보통이고 밤새 안정적
주말에는 애플리케이션 사용량이 적습니다
// 비용 최소화?

 

매일 8시간 → 사용량 많음
나머지 평일 → 보통
주말 → 낮음
(예측 가능한 사용 패턴)

 

사용량이 많은 시간을 예상할 수 있는 상황

-> 예약 인스턴스가 적절
상태 비저장 애플리케이션 

-> 추가 용량에 대해서는 스팟 인스턴스를 사용(비용 절감)

 

예약 인스턴스(Reserved Instances)
-> 1년 또는 3년 약정 기반의 상시 할인


#시험 포인트
예측 가능한 최소 사용량 = RI 또는 Savings Plan*
일시적 증가 = Spot

---

Q139)

10년 보관
최근 1개월은 자주 조회
1개월 이후는 거의 조회 안 함
매월 10TB 이상 생성 (대용량)
가장 비용 효율적이어야 함

S3 저장 → Lifecycle 정책 

→ 1개월 후 Glacier Deep Archive 이동

S3는 대용량 로그 저장에 적합
Lifecycle 정책은 자동 이동
Glacier Deep Archive는 최저 비용
운영 오버헤드 최소

CloudWatch Logs
-> AWS 로그 저장소 + 실시간 분석 도구
(목적 : 실시간 모니터링 // 저장 비용 S3보다 훨씬 비쌈)


#시험 포인트
장기 로그 보관 + 거의 접근 안 함
-> S3 + Lifecycle + Glacier Deep Archive

---

Q140)

SNS → Lambda → 데이터 처리
네트워크 문제 발생
Lambda 실행 때때로 실패
수동 재처리 안 하면 데이터 유실

//모든 알림이 최종적으로 처리되어야 함
= 메시지 유실 절대 안 됨
-> SNS → SQS → Lambda (거의공식)

SQS는 메시지를 안전하게 저장
Lambda 실패해도 메시지 유지
재시도 가능, DLQ 구성 가능

DLQ (Dead Letter Queue, 죽은 편지 대기열)
// 정상 처리에 실패한 메시지를 따로 모아두는 대기열
// 메시지 유실 방지 + 장애 분석 = DLQ


#시험 포인트
메시지 유실 방지 = SNS 앞에 SQS 버퍼

---

(~Q148)