[SAA-C03] 문제 유형 151-160 정리

Q151)

HPC (고성능 컴퓨팅)
Linux 기반
수백 개 Spot 인스턴스
수천 개 파일 생성
온프레미스 데이터 클라우드로 복사
장기 영구 저장 필요
고성능 파일 시스템 필요
모든 EC2가 동시에 읽기/쓰기 가능

//  고성능 파일 시스템, 병렬 처리, 장기 저장 통합

 

Amazon FSx for Lustre 
->  오픈 소스 Lustre를 기반으로 하는 완전 관리형 고성능 병렬 파일 시스템
(병렬 파일 시스템 = 수백 대가 동시에 읽고 씀)
//특징 : 초고속 처리, 병렬 파일 시스템, Linux 최적화,
S3 통합, 짧은 워크로드 적합(Spot 인스턴스)

S3 통합 
// 온프레미스 데이터를 복사
// 장기 영구 저장 필요


#시험 포인트
HPC + Linux + 병렬 파일 시스템 + S3 통합
= FSx for Lustre

---

Q152)

컨테이너화된 애플리케이션
AWS로 이전
배포 직후 수천 명 사용자
고가용성
자동 확장 필요
운영 오버헤드 최소화

// 컨테이너, 대규모 확장, 운영 최소화

AWS Fargate
Fargate는 사용자 애플리케이션을 위한 서버리스 환경
// 사용자는 서버 구성 및 관리 대신 애플리케이션 구축에 집중할 수 있음
// 또한 리소스 관리를 자동화하여 
사용자가 수요에 따라 애플리케이션을 쉽게 확장할 수 있음

// Fargate는 ECS(또는 EKS)를 실행하는 방식(Launch Type) 중 하나

ECS = 컨테이너 관리 서비스

ECS 실행 방식
EC2 Launch Type -> EC2 위에서 컨테이너 실행
Fargate Launch Type -> 서버 없이 컨테이너 실행


#시험 포인트
컨테이너 + 운영 최소화 → ECS + Fargate

---

Q153)

Sender → 메시지 전송

Processor → 메시지 처리

시간당 1,000개 (많지 않음)

처리에 최대 2일 소요 가능

실패 메시지는 보존 필요

다른 메시지 처리에 영향 없어야 함

운영 효율성 최고

 

// 최대 2일 처리, 실패 메시지 보존, 

나머지 메시지 영향 없고, 운영 최소화

 

-> 비동기 큐 시스템 필요
메시지 보존
실패 메시지 격리 (DLQ)
완전 관리형

 

 

=>  SQS

완전 관리형

최대 14일 메시지 보존

처리 지연 허용

Visibility Timeout 설정 가능

DLQ 지원(Dead Letter Queue)

실패 메시지 격리 가능

다른 메시지 영향 없음

 

 

#시험 포인트

실패 메시지 보존 + 비동기 처리

= SQS + DLQ

---

Q154)

S3에 정적 웹사이트 저장

CloudFront 사용

모든 트래픽은 반드시 AWS WAF 검사

보안 정책 준수

 

//사용자가 S3로 직접 접근하면 안 됨

반드시 CloudFront → WAF → S3 경로만 허용

 

-> CloudFront에 WAF 연결

OAI로 S3 접근 제한

 

OAI (Origin Access Identity)

-> CloudFront만 S3에 접근하도록 허용하는 기능

 

사용자 -> CloudFront + WAF -> S3 (OAI로 보호됨)

 

//모든 요청 WAF 검사

S3 직접 접근 차단

보안 정책 준수   

 

 

#시험 포인트

S3 정적 사이트 + CloudFront + 보안
= OAI + WAF

---

Q155) Q166 패스 : 정적 HTML 페이지 + 전세계 사용자 -> CloudFront

EC2 Fleet에서 실행

SQS 메시지 병렬 처리

트래픽 예측 불가 (간헐적)

다운타임 없이 지속 처리

가장 비용 효율적

 

// 트래픽 불규칙, 항상 처리 가능, 비용 최소화

 

 

정답이 C(RI + Spot)랑 D(RI + On-Demand)랑 갈림.

 

continually process messages without any downtime

MOST cost‑effectively

1. 다운타임 없음
2. 가장 비용 효율적

C: RI + Spot

RI → 항상 최소 용량 유지

Spot → 추가 용량 확장 

Spot 중단 가능

비용 매우 저렴

 

D: RI + On-Demand

RI → 항상 최소 용량 유지 

On-Demand → 추가 용량 

중단 없음 

비용 Spot보다 높음

 

“continually process messages without downtime”

 

// 시스템 전체가 멈추면 안 됨

// 보통 개별 인스턴스가 종료되면 안 된다는 의미 X

 

// SQS 기반, 메시지 재처리 가능, 병렬 처리
// 다운타임 없이 “계속 처리”

→ Baseline RI가 있기 때문에
Spot은 안전하게 사용 가능

+ MOST cost-effective

-> 정답은 C


#시험 포인트

SQS + Stateless + Cost 최적화 → RI + Spot

---

Q156)

여러 AWS 계정 존재

AWS Organizations에 속함

특정 서비스/액션 접근 제한

확장 가능해야 함

단일 중앙 관리 지점 필요

 

// 모든 계정에 적용

중앙에서 관리, 확장 가능

 

Service Control Policy (SCP)

-> 여러 계정에 권한을 중앙에서 제한할 때 사용

 

// Organizations 단위 적용

루트 OU에 적용 가능

모든 계정에 상속

특정 서비스/액션 deny 가능

중앙 관리

 

OU = Organizational Unit (조직 단위)

(여러 AWS 계정을 묶는 폴더)

 

 

#시험 포인트

여러 계정 중앙 통제 = SCP

---

Q157) Q169 패스 : DDoS 공격 방어 -> AWS Shield Advanced

특정 국가에서만 접근 허용

웹 애플리케이션

ALB 뒤 EC2

 

// 특정 국가만 허용

-> Geo restriction 기능

 

=> AWS WAF on ALB

 

AWS WAF 기능:

-> Geo match 조건 지원

// 특정 국가 허용/차단 가능

// ALB에 직접 연결 가능

// 중앙 관리 가능

 

Geo restriction은:

-> CloudFront

-> WAF

두 군데에서 가능

하지만 문제는 ALB 뒤 웹 앱이므로
→ WAF on ALB

 

 

#시험 포인트

국가 제한 = AWS WAF Geo Match

---

Q158) Q171 패스 : API 제공 + 확장 가능, 탄력적 -> API Gateway + Lambda

CloudFront 사용

HTTPS 이미 사용 중

추가 보안 계층 필요

사용자 제출 데이터가 민감함

애플리케이션 스택 전체에서 보호 필요

특정 애플리케이션만 접근 가능

 

//애플리케이션 스택 전체에서 보호 필요

-> 단순 HTTPS 이상의 보호를 의미

 

-> Field-Level Encryption

특정 HTTP 필드(예: form 필드) 암호화

CloudFront 엣지에서 암호화

백엔드의 특정 애플리케이션만 복호화 가능

애플리케이션 스택 전체에서 보호

 

[ 사용자 → CloudFront(필드 암호화) → ALB → 백엔드 ]

// 중간 어디에도 평문 노출 없음

 

 

#시험 포인트

HTTPS 외 추가 보안 + 민감 필드 보호

= CloudFront Field-Level Encryption

---

Q159) Q173 패스 : S3, 많은 비디오와 이미지, 전 세계 수백만 사용자 -> CloudFront CDN

ALB -> Auto Scaling Group -> 6개 EC2 인스턴스(단일 가용 영역)

모든 인스턴스가 하나의 AZ에 있음

해당 AZ 장애 발생 시 → 전체 서비스 다운

// 단일 장애 지점 (Single Point of Failure)

 

//어플리케이션 수정 없이, 인프라만 변경, 고가용성 달성

-> Multi-AZ 배포

 

2개의 가용 영역 각각에서 3개 인스턴스

   

 ALB (Multi-AZ)

           ↓

 AZ-1 → 3 EC2

 AZ-2 → 3 EC2

(ASG는 기본적으로 Multi-AZ 지원)

 

한 AZ 장애 나도 나머지 3개 살아있음

// ALB가 자동 라우팅

// 앱 수정 필요 없음

 

#시험 포인트

고가용성 = Multi-AZ

---

Q160)
[ API Gateway → Lambda → Aurora PostgreSQL ]

갑작스러운 주문 폭증

일부 고객 타임아웃 발생

DB CPU & Memory 높음

원인: 너무 많은 open connections

// Lambda 동시 실행 증가 → DB 연결 수 폭증 → DB 과부하 → 타임아웃

 

// 타임아웃 방지, DB 과부하 해결
애플리케이션 변경 최소

-> RDS Proxy

//  Connection Pooling 제공
Lambda와 통합 최적화
DB 연결 재사용
DB 연결 수 감소
코드 변경 최소 (endpoint만 변경)

 

 Ex. Lambda 1,000개 실행

-> 실제 DB 연결은 예: 50개만 유지
(Proxy가 연결 풀링 관리)

// DB CPU/Memory 감소
// 타임아웃 해결, 최소 변경 

 

 

#시험 포인트

Lambda + RDS 연결 폭증 문제
= RDS Proxy

---

(~Q175)