[SAA-C03] 문제 유형 51-60정리

Q51)

수십기가~수백테라 출력파일 생성

데이터는 '표준 파일 시스템' 구조로 저장

자동 확장 솔루션

고가용성, 최소 운영 오버헤드

 

표준 파일 시스템 구조

(// OS가 인식하는 일반적인 파일 시스템)

 

EFS는 리눅스가 그냥 하드디스크처럼 쓰면서,

여러 서버가 동시에 공유할 수 있는 네트워크 파일 시스템

 

즉, 온프레 NAS처럼 동작

-> POSIX 파일 시스템

(리눅스/유닉스에서 사용하는 “일반적인 파일 시스템 규칙")

// 경로, 명령어, 파일권한 등

-> NFS (Network File System) 기반
(네트워크를 통해 파일 시스템을 공유하는 방식)

 

// NAS(Network Attached Storage)

-> 회사에서 다 같이 쓰는 공유 폴더 전용 저장 장비

 

 

#시험 포인트

확장 가능한 공유 파일 시스템- > EFS

---

Q52)

S3에 회계기록 저장

1년 즉시 액세스, 추가 9년 보관

10년 동안 기록 삭제 불가

최대 복원력으로 저장

(-> S3는 기본적으로 Multi-AZ 저장)

 

S3 버킷 생성 (Object Lock 활성화)
Object Lock – Compliance 모드 10년 설정
Lifecycle 정책으로 1년 후 Glacier Deep Archive 전환

 

S3 Object Lock
-> S3 객체를 일정 기간 동안 삭제하거나 수정하지 못하도록 잠그는 기능

(회계기록, 금융데이터, 의료기록, 법적 보존 요구사항 등 실수로도 삭제하면 안 되는 자료)

-> WORM 모델 (Write Once Read Many)

// 한 번 쓰면 읽기만 가능, 수정/삭제 불가

 

Compliance 모드
-> 누구도 삭제 불가 (루트 포함)
Governance 모드
-> 권한 있으면 삭제 가능

 

#시험 포인트

관리자도 삭제 못 하게 하려면 Object Lock Compliance

---

 

Q53)

Windows 워크로드

Windows 파일 공유(SMB)

EC2 두 대 동기화

고가용성 필요(액세스 방식 보존)

 

EC2 A (Windows 파일 서버)
EC2 B (Windows 파일 서버)
-> 두 서버가 서로 데이터 동기화

 

문제점

수동 동기화 구조

(// A와 B가 서로 파일 복사

// 동기화 지연 및 충돌 발생 가능)

고가용성 X

(// EC2 A 장애 발생 시, 수동복구 필요

// B가 최신 데이터 아닐 수도 있음)

-> 운영 오버헤드가 큼

즉, 서버 두 개를 억지로 고가용성처럼 운영 중

 

FSx for Windows

-> Windows 네이티브 SMB 파일 시스템을 관리형으로 제공

// 기존 SMB 경로 유지 필요, Multi-AZ 고가용성

// 쉬운설명 : AWS가 대신 운영해주는 기업용 NAS 장비

 

#시험 포인트

Windows SMB 파일 공유 + 고가용성 필요 → FSx for Windows

---

Q54)

여러 서브넷 포함

EC2 + RDS 사용하는 앱 호스팅

2개의 가용영역, 6개 서브넷 구성

프라이빗 서브넷 EC2만 RDS DB 접근

다른 곳은 접근 불가

 

특정 EC2 그룹만 DB 접근 가능해야함

-> 보안 그룹 참조(Security Group referencing)

// 한 보안 그룹이 다른 보안 그룹을 소스로 지정하는 방식

 

ex. 프라이빗 EC2에 SG-A 할당RDS에 SG-B 할당

보안그룹 B 규칙에 : 'Source : SG-A' 설정

-> 의미 :  SG-A를 가진 인스턴스만 RDS 접근 가능

 

참고.

NACL(Network Access Control List)

-> 서브넷 단위로 트래픽을 제어하는 네트워크 방화벽

// 서브넷 단위(인스턴스 단위로 세밀한 제어 어려움 -> 오답) 

// 상태 비저장(Stateless) -> 요청, 응답 따로 허용해야함

// 허용, 거부 가능

 

#시험 포인트

EC2 → RDS 접근 제어는 보안 그룹 참조

인스턴스 단위 접근 제어는 NACL이 아니라 Security Group

---

Q55)

회사 도메인(Route 53) 사용

백엔드 API는 Amazon API Gateway 사용

(외부 서비스들이 이 API 호출)
타사 서비스에서 HTTPS 사용

(외부서비스가 안전하게 호출해야함)

API 주소를 회사 도메인으로 사용

 

-> API Gateway + 회사 도메인 + HTTPS 연결 (요구)

(API를 HTTPS로 제공해야 함)

 

SSL/TLS 인증서

→ HTTPS 통신을 위해 서버 신원 확인 + 데이터 암호화

 

Regional API Gateway Endpoint

→ 특정 리전에 있는 API Gateway에 커스텀 도메인 연결 가능

 

ACM (AWS Certificate Manager)

-> HTTPS 사용을 위해 도메인 SSL/TLS 인증서 관리

 

Custom Domain Name in API Gateway

→ 기본 URL 대신 https://api.company.com 같은 회사 도메인 사용 

 

Route 53 // 회사 도메인을 API Gateway endpoint로 라우팅

Route 53 Alias Record

-> AWS 리소스로 직접 연결하이는 DNS 레코드

 

동작 흐름.

API Gateway Regional Endpoint 생성 ->

ACM에 도메인 인증서 업로드 (같은 Region) ->

API Gateway Custom Domain + 인증서 연결 ->

Route 53 Alias Record → API Gateway

 

 

#시험 포인트

API Gateway에 회사 도메인 + HTTPS

= Custom Domain + ACM Certificate + Route 53 Alias

---

Q56)

사용자가 이미지 업로드(소셜 미디어)

이미지에 부적절한 콘텐츠 포함 여부 확인 필요

개발 노력 최소화

 

Amazon Rekognition

→ 이미지 분석 AI 서비스

-> 동작 흐름

1. 사용자 이미지 업로드

2. Rekognition Moderation API 분석

3. 부적절 콘텐츠 감지

4. Low confidence → 사람이 검토

 

 

#시험 포인트

이미지 부적절 콘텐츠 감지 -> Amazon Rekognition

---

Q57)

컨테이너 기반 애플리케이션 실행

확장성  + 가용성 필요

인프라 관리에 대한 책임 원치 않음

->  앱 유지보수만 집중

 

컨테이너 (Container)

→ 애플리케이션을 실행에 필요한 모든 것과 함께 패키징한 실행 단위

(= 앱 실행에 필요한 거 전부 담은 박스)

AWS Fargate

→ 서버 관리 없이 컨테이너 실행
(서버/인프라 관리는 AWS, 개발자는 컨테이너만 배포)

 

Amazon Elastic Container Service (ECS)

→ 컨테이너를 자동으로 배포, 관리, 운영하는 서비스
(오케스트레이션 서비스)

동작 구조

1. 컨테이너 이미지를 ECS에 배포

2. ECS + Fargate 실행

3. AWS가 서버 프로비저닝 / 스케일링 관리

 

 

#시험 포인트

컨테이너 실행 but 서버 관리 원하지 않음

-> ECS + Fargate (서버리스 컨테이너)

---

Q58)

글로벌 300개 이상 웹사이트 및 앱 호스팅

클릭스트림 데이터 매일 30TB 이상

-> 대량 실시간 수집 및 분석 필요

 

Amazon Kinesis Data Streams

→ 대량 실시간 데이터 수집

Amazon Kinesis Data Firehose

→ 스트림 데이터를 저장소로 자동 전송

Amazon S3

→ 데이터 레이크 저장

Amazon Redshift

→ 대규모 데이터를 빠르게 분석하는 데이터 웨어하우스

#시험 포인트

대량 실시간 데이터 분석 아키텍처

//  Kinesis Streams → Firehose → S3 → Redshift

---

Q59)

웹사이트가 ALB(Application Load Balancer) 뒤에 있음

HTTP/HTTPS 둘 다 사용 가능

모든 요청을 HTTPS로 강제

 

HTTP → HTTPS Redirect

→ HTTP 요청이 들어오면 자동으로 HTTPS로 이동

 

Application Load Balancer Listener

→ 로드밸런서가 요청을 받는 포트와 프로토콜
(클라이언트 요청을 처음 받는 입구)

 

Listener Rule

→ 요청을 어디로 보낼지 결정하는 규칙

 

ALB Listener Rule 설정

HTTP 요청 수신 -> HTTPS로 Redirect

HTTP 접속 http://example.com

-> 자동 변경 -> https://example.com

 

 

#시험 포인트

HTTP → HTTPS 강제

= ALB Listener Redirect Rule

---

Q60)

웹 애플리케이션이 Amazon EC2에서 실행

DB는 Amazon RDS 사용

DB 비밀번호 하드코딩 금지

자동 비밀번호 Rotation 필요(자동 교체)

최소 운영 오버헤드

 

하드코딩 (Hardcoding)

→ 비밀번호나 설정 값을 코드 안에 직접 넣는 것

(코드 유출 시 비번도 같이 유출. 변경 시 코드 수정+ 재배포 필요)

 

AWS Secrets Manager

→ 애플리케이션 비밀번호 / API 키 / DB 자격증명 관리 서비스

-> Secret 저장, Automatic Rotation,IAM 접근 제어(Role 통해 Secret 조회)

 

흐름.

RDS credentials -> Secrets Manager 저장

-> Automatic Rotation 활성화 -> EC2 IAM Role -> 애플리케이션이 Secret 조회

 

 

#시험 포인트

DB credential(자격증명) 관리 + 자동 rotation

-> Secrets Manager