[SAA-C03] 문제 유형 121-130 정리

Q121)

컨테이너에서 애플리케이션 실행
Stateless
중단 허용
비용 최소
운영 오버헤드 최소

중단을 허용할 수 있음 = 스팟 인스턴스. 
컨테이너에서 애플리케이션 실행 = ECS, EKS 

EKS -> Kubernetes를 AWS에서 운영해주는 서비스
Kubernetes // 컨테이너를 실행할 서버(노드)가 필요
Managed Node Group 
-> AWS가 대신 관리해주는 Kubernetes 노드 그룹
// AWS가 EC2 생성, Auto Scaling 설정 자동,
노드 교체 자동, 패치 자동, Kubernetes 버전 맞춰줌
-> 운영 최소


#시험 포인트
컨테이너 환경 + 운영 최소 → 관리형 Kubernetes(EKS)
단, ECS + Fargate 있으면 그게 더 운영 최소

---

Q122)

온프레 다중 계층
컨테이너화됨
PostgreSQL 사용
인프라/용량 계획 오버헤드 큼
성장 제한

// 서버 관리 + DB 관리 오버헤드 제거

* ECS + Fargate로 마이그레이션
// 컨테이너 그대로, 서버관리 없음, 
// Auto Scailing 자동

* PostgreSQL → Amazon Aurora
// Amazon Aurora
-> AWS가 직접 만든 “더 빠르고 확장성 좋은” MySQL / PostgreSQL
// 패치 자동, 백업 자동, 장애 자동 Failover, 스토리지 자동 확장

 

#시험 포인트
인프라 오버헤드 제거, 컨테이너, DB 운영 부담
-> Fargate + Aurora

---

Q123)

EC2 여러 AZ
ALB 뒤
Auto Scaling 그룹
CPU 40%가 최적
모든 인스턴스에서 유지

// 특정 지표(40% CPU)를 일정하게 유지해야 함

Target Tracking Policy
-> 특정 지표 목표값 설정 가능
// 자동으로 확장/축소
// 가장 간단하고 자동화된 방식

ex. CPU 40% 타겟 설정
CPU > 40% → 인스턴스 추가
CPU < 40% → 인스턴스 감소


#시험 포인트
CPU사용률에 따라 Auto Scaling 
-> Target Tracking Policy

---

Q124)

S3를 파일 저장소로 사용
CloudFront 통해서만 제공
S3 URL 직접 접근 차단

// S3를 Public으로 열면 안 됨
CloudFront만 접근 가능해야 함

OAI (Origin Access Identity)
-> CloudFront 전용 식별자
-> S3에 직접 접근할 수 있는 권한을 가짐
// 사용자들은 S3 직접 접근 불가

흐름.
1. OAI 생성
2. CloudFront에 OAI 연결

3. S3 버킷 정책에서 OAI만 읽기 허용
→ S3 URL 직접 접근 차단


#시험 포인트
S3를 CloudFront만 접근하게 하려면 OAI

---

Q125)

다운로드 가능한 과거 보고서
전 세계 사용자
확장 필요
비용 효율
인프라 최소
가장 빠른 응답

// 정적 파일, 글로벌 배포, 서버관리 최소

보고서 // 정적 파일
// 변경 자주 안 됨, 대용량 가능
-> S3가 가장 저렴하고 확장성 좋음

CloudFront 
// 전 세계 엣지 로케이션
// 가장 가까운 곳에서 응답(캐싱)
// 대규모 트래픽 처리


#시험 포인트
정적 글로벌 배포는 S3 + CloudFront

---

Q126)

Oracle DB 온프레
최신 버전 업그레이드
재해 복구(Disaster Recovery) 필요
운영 오버헤드 최소
기본 OS 접근 유지 필요

// OS 접근 유지, DR 필요, 운영 최소

RDS Custom for Oracle
-> AWS가 DB 관리
-> OS 레벨 접근 가능 (일반 RDS는 불가)
-> 최신 버전 지원
-> DR용 Read Replica 생성 가능
-> 관리형이므로 운영 부담 감소


#시험 포인트
기본 운영 체제에 대한 액세스 유지 -> Amazon RDS

---

Q127)

서버리스 솔루션
S3에 데이터 저장
데이터 분석 필요
데이터 암호화 필요
다른 리전으로 복제
최소 운영 오버헤드

SSE‑S3
-> S3가 자체 관리 키로 객체를 서버 측에서 자동 암호화하는 방식

단순 암호화 -> SSE‑S3
키 사용 감사 / 세밀한 제어 -> SSE‑KMS
동일키 교차 리전 사용 -> Multi‑Region KMS

기존 S3 버킷 사용
-> SSE‑S3 사용 (완전관리형, 설정 간단)
// 데이터 쿼리는 Athena

 

#시험 포인트
요구한 만큼만 보안 적용, 과한 설계는 오답

---

Q128)

외부 공급자 VPC에서 호스팅
비공개 연결
대상 서비스로만 제한
회사 VPC에서만 시작

// 인터넷 안 씀

특정 서비스만 접근

회사 -> 공급자 단방향

 

AWS PrivateLink
-> VPC 내부에서 비공개 연결
// 특정 서비스만 노출
// 인터넷 사용 안 함
// 서비스 단위 접근

 

구조.
회사 VPC → Interface Endpoint → 공급자 서비스

(공급자가 서비스에 대한 VPC 엔드포인트 생성, PrivateLink로 연결)

 

 

#시험 포인트

서비스 단위 비공개 연결은 PrivateLink

---

Q129)

온프레 PostgreSQL
Aurora PostgreSQL
온프레 DB 온라인 상태 유지
마이그레이션 중에도 액세스 가능
동기화 상태 유지

// 다운타임 없이 마이그레이션
지속적 동기화 필요

// 온프레 DB → Aurora로 마이그레이션
서비스는 계속 운영해야 함 (무중단)

-> DMS는 기존 데이터는 Full Load로 복사하고,

이후 변경은 CDC로 계속 동기화

AWS DMS (Database Migration Service)
-> 데이터베이스를 최소 다운타임으로 다른 데이터베이스로 마이그레이션하는 관리형 서비스
// 초기 데이터 로드(기존에 쌓여 있는 DB 전체를 통째로 복사)
// 지속적 변경 복제 (Change Data Capture)
// 온라인 마이그레이션 지원

 

#시험 포인트

온라인 유지, 지속 동기화, DB 마이그레이션
-> DMS + CDC

---

Q130)

RabbitMQ (EC2, 단일 AZ) -> App EC2 (단일 AZ) -> PostgreSQL (EC2, 단일 AZ)

최소 운영 오버헤드로 최고의 가용성 제공

 

문제점

// 전부 단일 AZ , EC2 직접 운영, 메시지 브로커 직접 관리, DB 직접 관리 
// RabbitMQ → EC2 직접 운영, PostgreSQL → EC2 직접 운영

 

RabbitMQ → Amazon MQ (Active/Standby, Multi‑AZ)
// 관리형, Multi‑AZ 자동 Failover
// 운영 부담 감소

 

애플리케이션 EC2 → Multi‑AZ Auto Scaling
// 여러 AZ에 분산
// 인스턴스 장애 자동 복구

 

PostgreSQL → RDS Multi‑AZ
// 관리형 DB, 자동 Failover
// 백업/패치 자동

 

 

#시험 포인트
EC2에서 직접 운영 중인 메시징/DB를 관리형 + Multi‑AZ로 전환하면 가용성 + 운영 최소 달성

---

(~Q138)