[SAA-C03] 문제 유형 61-70정리

Q61)

공개 웹 애플리케이션

ALB(애플리케이션 로드밸런서) 뒤에서 실행

외부 CA(인증기관) 발급 인증서 사용

매년 교체 필요

 

외부 CA 인증서 발급

-> ACM에 가져오기(import)

-> ALB에 적용

-> EventBridge로 만료 알림

-> 수동교체

// AWS 발급 인증서는 자동 갱신 되지만

Import한 인증서는 자동갱신 안 됨

 

ALB에 적용한다 ->

ALB가 HTTPS 트래픽을 처리하도록 인증서를 연결한다

(로드밸런서는 트래픽을 여러 인스턴스로 분산하는 서비스니깐)

 

#시험 포인트

외부 CA 인증서, ALB 적용, 자동갱신 불가

-> ACM Import + 수동 교체

 

---

Q62)

70만 사용자

평균 5MB PDF 파일 -> JPG 변환

원본 + 변환본 보관

빠르게 증가할 수요를 비용효율적으로

 

파일저장 -> S3

업로드시 자동변환 -> 이벤트 트리거

수요급증 대응 -> 자동확장

 

Lambda

-> S3 PUT 이벤트로 자동 실행
-> 서버 관리 필요 없음
-> 자동 확장, 사용량 기반 비용

 

S3 PUT
-> S3에 파일을 “저장”하는 것

S3 PUT 이벤트 -> 업로드 될 때 발생

-> 이 이벤트로 Lambda 실행

 

 

#시험 포인트

파일 업로드 후 자동 처리 → S3 이벤트 + Lambda

---

Q63)

5TB 이상 Windows 파일 서버

매일 상호작용

AWS로 이전 중

온프레 + AWS 둘 다 접근

최소 지연

기존 파일 액세스 패턴 유지

VPN 연결 사용

 

Windows 파일 서버

-> SMB 기반

-> FSx for Windows 필요

기존 파일 액세스 패턴 유지
Windows 파일 서버 -> AD 기반 권한 사용
-> FSx도 AD 통합 가능 (변경 최소)

AD(Active Directory) -> 회사 로그인 시스템

AD통합
-> 기존 회사 사용자 계정과 권한을 그대로 사용하는 것

// FSx for Windows

→ 관리형 SMB 파일 시스템, AD 통합

 

// FSx File Gateway (온프레에 설치하는 중간 캐시 서버)

-> 파일서버는 계속 왕복통신 발생(파일 열때,읽을때,저장,확인 등등)

-> 지연(latency) 누적됨 -> FSx File Gateway 로컬캐시!

-> 온프레에서 SMB로 접근, 캐싱제공, 낮은 지연

 

 

#시험 포인트

SMB + AD 유지 + 온프레 캐시 필요 → FSx + File Gateway

---

Q64)

병원 RESTful API 배포

(RESTful API -> HTTP 방식으로 자원을 다루는 표준적인 웹 API)
PDF/JPEG 형식의 보고서 업로드

PHI(Protected Health Information) 식별

Lambda 코드 수정(처리 로직 필요)

최소 운영 오버헤드(관리형 AI 서비스)

 

PDF/JPEG -> 이미지 또는 문서파일

텍스트 먼저 추출해야함 -> Textract

 

PHI 식별 (의료기록, 환자이름, 진단코드 등)

-> 의료 특화 서비스 -> Comprehend Medical

 

Textract
-> PDF / 이미지에서 텍스트를 추출하는 서비스
Comprehend Medical

-> 의료 문서에서 PHI, 진단, 약물 등을 식별하는 AI 서비스

 

최소 운영 오버헤드 // 의료 규정 복잡(직접구현X)

 

흐름 : PDF/JPEG 업로드 -> Lambda -> Textract -> Comprehend Medical
(Lambda는 Textract와 Comprehend Medical을 순서대로 호출하는 중간 실행 로직)

 

 

#시험 포인트

의료 문서 PHI 탐지는 Textract + Comprehend Medical

---

Q65)

5MB 파일 다수

4년간 보관 필수

처음 30일은 자주 접근

이후부터 거의 접근 안함

but 즉시 액세스 항상 필요

비용 효율 필요

 

즉시 액세스 항상 필요

-> Glacier X

-> Deep Archive X

 

30일 이후 접근 거의 안함

-> Infrequent Access(IA) 적합

 

4년 후 삭제 -> Lifecycle

 

Standard‑IA가 최적

(드물게 접근, 즉시 조회 가능)

 

Day 0~30일 → S3 Standard
Day 3~4년 → S3 Standard‑IA
4년 후 → 삭제

 

 

#시험 포인트

자주 쓰다 드물게 쓰면서 접근 필요하면

Standard → Standard‑IA

---

Q66)

여러 EC2

SQS 메시지 처리

RDS에 기록

가끔 중복 레코드 발생

SQS에는 중복 메시지 X

 

SQS에 중복 메시지 없다

-> 중복 전송 아님

-> 같은 메시지가 두 번 처리됨

 

SQS 기본 동작

메시지 수신 -> 메시지 보이지 않음(visibility timeout 시작)

-> 처리 -> 처리완료 후 DeleteMessage 호출

 

문제 // 메시지 처리 시간 김, visibility timeout이 짧음,

처리 끝나기 전 timeout 만료, 메시지가 다시 대기열 나타남

-> RDS 중복 레코드 발생

 

(가시성 제한 시간 만료 전에 메시지에 대한 DeleteMessage

작업을 호출하지 않으면 메시지가 다른 소비자에 표시됨.

한번만 수신해야 하는 경우 가시성 제한 시간 내에 메시지 삭제)

 

해결 // ChangeMessageVisibility API로:
처리 시간 > visibility timeout 되게 설정

 

Visibility Timeout
-> 메시지를 받은 후 다른 소비자가 못 보게 숨겨두는 시간

ChangeMessageVisibility API
> 메시지가 다시 보이기 전까지의 시간을 늘리거나 줄이는 API

 

 

#시험 포인트

중복 처리 문제는 Visibility Timeout 문제

---

Q67)

온프레 인프라를 AWS로 확장

일관되게 짧은 지연시간과 고가용성 연결

비용 최소화

기본연결 실패 시 더 느린 트래픽 OK

 

-> 기본은 빠르고 안정적이나 장애 시 느려도 허용

 

Direct Connect (DX)
온프레 ↔ AWS 전용 회선 연결
(낮은 지연, 안정적, 인터넷 미사용)

VPN
-> 인터넷 기반 암호화 터널
(저렴, 빠른 구축 / 지연 불안정,인터넷 영향 받음)

 

Direct Connect + VPN 백업
(하이브리드 연결 설계 패턴)
-> 기본은 빠르게, 장애 시 저렴한 백업
(실무 : AWS Site To Site VPN으로 구현하는 것이 비용 효율적)

 

 

#시험 포인트

하이브리드 고성능은 DX, 백업은 VPN.

---

Q68)

ALB 뒤 EC2

Auto Scailing 그룹

Aurora PostgreSQL DB -> 단일 AZ

다운타임/데이터 손실 최소

최소 운영 노력

 

현재 DB가 단일 AZ

AZ(Availablity Zone)

-> 서로 물리적으로 분리된 데이터센터

 

DB가 단일 AZ면, AZ 장애 시 전체 서비스가 멈춤

SPOF (Single Point of Failure)
-> 하나가 고장 나면 전체 시스템이 멈추는 구성 요소

 

다운타임 최소화 ->  Multi-AZ

// 자동으로 다른 AZ의 DB로 전환 (Failover)

 

Auto Scaling은 애플리케이션 계층의 고가용성,
Multi‑AZ는 데이터베이스 계층의 고가용성

-> 고가용성(HA)은 계층별로 확보해야 한다

(전체 체인이 끊기지 않게)

 

 

#시험 포인트

Single-AZ DB는 SPOF -> Multi‑AZ로 전환

---

Q69) 배경지식 : Layer 7계층

HTTP 애플리케이션
NLB 사용
HTTP 오류 감지 못함
EC2 수동 재시작 필요
코드 작성 없이 해결

 

NLB가 HTTP 오류 감지 못함

-> NLB는 L4(TCP/UDP) 레벨(네트워크)

-> 포트 열렸는지만 확인

-> 애플리케이션 상태는 모름(다른 계층)

 

ALB는 L7(HTTP/HTTPS)

특정 URL로 헬스 체크 가능

HTTP 상태 코드 확인 가능

 

 

#시험 포인트

HTTP 오류 감지는 ALB, NLB는 L4

---

Q70) 

데이터 손상 시

RPO = 15분

RTO = 1시간

DynamoDB 사용

 

 RPO (Recovery Point Objective)
-> 얼마나 최근 데이터까지 복구해야 하는가?
ex. RPO = 15분
→ 최대 15분 전 상태까지 복구 가능해야 함

RTO (Recovery Time Objective)
-> 복구 완료까지 걸리는 시간
ex. RTO = 1시간
→ 1시간 내 복구 완료해야 함

DynamoDB PITR (Point‑in‑Time Recovery/지정시간복구)

-> 최근 35일 내 원하는 시점으로 복구할 수 있는 지속적 백업 기능

(초 단위 복구 가능 /  RPO ≈ 0 // 거의 실시간 백업, 데이터 손실 거의 없음)

 

RPO ≈ 0 + PITR 보통 1시간 이내 복구 가능

-> RPO, RTO 요구 충족

#시험 포인트

DynamoDB 15분 RPO → PITR