AWS SAA-C03 Dump 251-300
Answer: B
요구사항
EC2가 새 VPC의 프라이빗 서브넷에 있음
해당 서브넷에는 아웃바운드 인터넷이 없음
EC2는 외부 공급업체에서 월별 보안 업데이트를 받아야 함 → 아웃바운드 인터넷 필요
B. 퍼블릭 서브넷의 NAT 게이트웨이 + 프라이빗 서브넷 기본 경로
1. 아웃바운드 전용 인터넷
프라이빗 서브넷의 EC2는 퍼블릭 IP가 없어 IGW를 기본 경로로 쓰면 응답이 돌아오지 않습니다.
NAT 게이트웨이가 출발지 IP를 NAT의 퍼블릭 IP로 바꿔 보내므로, 응답이 NAT로 돌아온 뒤 다시 EC2로 전달됩니다. → 아웃바운드만 필요할 때 적합합니다.
2. NAT 게이트웨이는 퍼블릭 서브넷에
NAT 게이트웨이는 인터넷으로 나가야 하므로 퍼블릭 서브넷(0.0.0.0/0 → IGW가 있는 서브넷)에 두는 것이 맞습니다.
B는 “NAT 게이트웨이를 퍼블릭 서브넷에 배치”라고 명시하고 있어 올바릅니다.
3. 프라이빗 서브넷 라우팅
프라이빗 서브넷의 기본 경로(0.0.0.0/0) 를 NAT 게이트웨이로 두면,
EC2 → NAT 게이트웨이 → IGW → 인터넷(외부 공급업체)으로 보안 업데이트 다운로드가 가능합니다.
4. 관리형 서비스
NAT 게이트웨이는 AWS 관리형이라 가용성·패치 부담이 적고, 솔루션 설계자가 “구성만 하면 되는” 방식과 잘 맞습니다.
[프라이빗 서브넷] [퍼블릭 서브넷]
EC2 (보안 업데이트 필요) → NAT 게이트웨이 → IGW → 인터넷(외부 공급업체)
↑ ↑
0.0.0.0/0 → NAT GW 0.0.0.0/0 → IGW(인터넷 게이트웨이)
Answer: A
요구사항
- 고객 사례 파일 저장
- 핵심 자산으로 중요
- 파일 수가 시간이 지남에 따라 증가
- 여러 EC2 애플리케이션 서버에서 동시에 접근 가능해야 함
- 중복성(고가용성) 이 내장되어야 함
A. Amazon EFS
1. 여러 서버에서 동시 접근
Amazon EFS는 NFS 기반 공유 파일 시스템입니다.
여러 EC2 인스턴스가 동일한 EFS를 마운트해 동시에 같은 파일을 읽고 쓸 수 있습니다.
“여러 애플리케이션 서버에서 동시에 액세스” 요구사항을 충족합니다.
2. 시간에 따른 용량 증가
EFS는 파일/용량이 늘어나도 자동으로 확장되며, 용량을 미리 프로비저닝할 필요가 없습니다.
“파일 수가 시간이 지남에 따라 증가”에 적합합니다.
3. 내장된 중복성
EFS는 다중 AZ에 데이터를 저장하며, 표준 모드에서는 자동 복제로 내구성과 가용성을 제공합니다.
“중복성이 내장되어 있어야 한다”는 조건을 만족합니다.
4. 중요 자산 저장
내구성·암호화·접근 제어가 지원되어 핵심 회사 자산 저장에 적합합니다.
Answer: C
A. Policy 1은 iam:Get*, iam:List*만 허용. iam:DeleteUser 등 삭제는 허용 없음 → implicit deny.
B. Policy 1에서 ds:*로 Directory Service 전체 허용. Policy 2에서 ds:Delete* 명시적 Deny → Deny 우선.
C. Policy 1에서 ec2:*로 모든 EC2 작업 허용. ec2:TerminateInstances(인스턴스 삭제) 포함. Policy 2는 ds:Delete*만 Deny.
D. Policy 1은 logs:Get*, logs:Describe*만 허용. logs:Delete* 등 로그 삭제는 허용 없음 → implicit deny.
Answer: B
요구사항
- 3계층 앱을 VPC로 마이그레이션
- 문제: 계층 간 EC2 보안 그룹 인바운드/아웃바운드에 최소 권한 원칙이 적용되지 않음
- 목표: 이 문제를 해결할 수 있는 보안 그룹 규칙 설계
B. 보안 그룹 ID 사용
1. 최소 권한
보안 그룹 ID를 소스/대상으로 쓰면, “해당 보안 그룹이 붙은 인스턴스”만 통신할 수 있습니다.
예: 앱 계층 SG는 웹 계층 SG(sg-xxx) 에서만 8080 허용 → 웹 계층 인스턴스만 접근 가능.
VPC/서브넷 전체가 아니라 역할(계층) 단위로만 열어주는 것이므로 최소 권한에 맞습니다.
2. 계층 간 통신에 적합
웹 → 앱 → DB처럼 특정 계층 SG ↔ 특정 계층 SG만 허용하는 패턴이 됩니다.
인스턴스가 바뀌어도 같은 SG를 쓰면 규칙 수정 없이 그대로 적용됩니다.
3. 문제 해결
지금은 CIDR 등으로 “넓게” 열려 있어 최소 권한이 안 되어 있는 상태로 보는 것이 자연스럽고,
소스/대상을 보안 그룹 ID로 바꾸면 “해당 계층만” 통신하도록 좁혀서 문제를 해결할 수 있습니다.
Answer : D
요구사항
전자상거래 체크아웃 워크플로우: DB에 주문 저장 + 결제 서비스 호출
문제 1: 체크아웃 중 타임아웃 발생
문제 2: 사용자가 다시 제출하면 같은 거래에 대해 주문이 여러 개 생성됨
목표: 여러 주문 생성 방지를 위해 워크플로우 리팩터링
D. DB + SQS FIFO + 처리 후 삭제
1. 여러 주문 방지
SQS FIFO는 메시지 중복 제거(Content-based deduplication) 또는 MessageDeduplicationId를 지원합니다.
같은 체크아웃(같은 주문/세션)을 다시 보낼 때 동일한 Deduplication ID를 쓰면, 5분 창 안에는 한 번만 전달됩니다.
결제 서비스는 한 주문당 한 번만 처리하게 되어, “동일한 원하는 거래에 대해 여러 고유 주문”이 생기는 것을 막을 수 있습니다.
2. 타임아웃 완화
웹 앱은 주문을 DB에 저장하고 SQS FIFO에 메시지(주문 번호) 만 보낸 뒤 곧바로 응답하면 됩니다.
결제 처리 같은 무거운 작업은 큐에서 메시지를 꺼내 처리하는 서비스가 비동기로 수행하므로, 체크아웃 응답이 빨라져 타임아웃 가능성이 줄어듭니다.
3. 처리 후 삭제
결제 서비스가 메시지를 조회 → 주문 처리(결제 호출) → 큐에서 삭제하면, 재시도·중복 전달 시에도 “이미 처리된 주문”은 큐에서 제거된 상태라 중복 결제 처리를 줄일 수 있습니다.
FIFO + 삭제로 한 메시지당 한 번만 처리하는 패턴을 만들 수 있습니다.
4. 순서 보장
FIFO 큐이므로 주문 순서가 유지되어, 결제·재고 등 다운스트림 처리에 유리합니다.
Answer: B, D
S3를 저장소로 쓰는 문서 검토 애플리케이션
요구사항
- 우발적인 문서 삭제 방지
- 문서의 모든 버전을 사용할 수 있도록 보장
- 사용자는 문서 다운로드·수정·업로드 가능해야 함
B. 버킷에서 버전 관리 활성화
1. 모든 버전 보존
S3 버전 관리를 켜면 객체를 덮어써도 이전 버전이 모두 보존됩니다.
“문서의 모든 버전을 사용할 수 있도록 보장” 요구사항을 충족합니다.
2. 우발적 삭제 완화
버전 관리가 켜져 있으면 “삭제”는 삭제 마커만 추가하고, 이전 버전은 그대로 남습니다.
실수로 삭제해도 이전 버전으로 복구할 수 있어 우발적 삭제를 완화합니다.
D. 버킷에서 MFA 삭제 활성화
1. 우발적·무단 삭제 방지
MFA 삭제를 켜면, 객체 버전을 영구 삭제하거나 버전 관리 상태를 바꾸려면 MFA 인증이 필요합니다.
MFA 없이는 영구 삭제가 불가능해 우발적·무단 문서 삭제를 방지하는 데 직접 기여합니다.
2. B와의 역할 분담
B(버전 관리): 모든 버전 보존 + 삭제 시에도 이전 버전 복구 가능.
D(MFA 삭제): 영구 삭제 자체를 MFA로 제한해, “실수로/누군가가 삭제”하는 상황을 줄임.
Answer: A
요구사항
- AWS 계정 전체의 EC2 Auto Scaling 이벤트/상태를 보고
- 서버리스로 EC2 Auto Scaling 상태 데이터를 S3에 저장
- S3 데이터로 대시보드에 거의 실시간 업데이트
- EC2 인스턴스 시작 속도에 영향 없어야 함
A. CloudWatch 메트릭 스트림 → Firehose → S3
1. 인스턴스 시작 속도에 영향 없음
CloudWatch 메트릭 스트림은 Auto Scaling이 발생할 때 CloudWatch가 메트릭을 스트리밍하는 방식입니다.
인스턴스 부팅/스크립트와 무관하게 동작하므로, 인스턴스 시작 시간에 전혀 관여하지 않습니다.
2. 서버리스
CloudWatch 메트릭 스트림 + Kinesis Data Firehose + S3만 사용합니다.
EC2, EMR, Lambda 등 추가 서버/함수 없이 구성 가능합니다.
Auto Scaling 상태 데이터 → S3
Auto Scaling 관련 CloudWatch 메트릭(예: GroupDesiredCapacity, GroupInServiceInstances 등)을 메트릭 스트림으로 Firehose에 보내고, Firehose가 S3에 저장하도록 하면 됩니다.
이 데이터로 “Auto Scaling 상태/변화”를 대시보드에 반영할 수 있습니다.
3. 거의 실시간
메트릭 스트림은 지속적으로 전달되고, Firehose 버퍼링 후 S3에 적재되므로 거의 실시간에 가깝게 대시보드 업데이트가 가능합니다
EMR은 EC2 클러스터를 쓰는 서비스라 서버리스가 아님 (B)
“일정에 따라” Lambda를 호출하는 방식은 주기적 폴링입니다 (C)
부트스트랩으로 에이전트를 설치·실행하면 부팅 시간이 늘어남 (D)
[EC2 Auto Scaling] → [CloudWatch 메트릭]
↓
[CloudWatch 메트릭 스트림]
↓
[Kinesis Data Firehose]
↓
[Amazon S3]
↓
[대시보드 (거의 실시간)]
Answer: D
매시간 수백 개의 1GB CSV 파일이 S3에 업로드됨
요구사항: 업로드될 때마다 Apache Parquet로 변환 후 S3에 출력
목표: 최소한의 운영 오버헤드로 구현
1. 1GB 파일 처리
AWS Glue ETL은 서버리스 Spark 기반으로, S3에서 대용량 파일을 읽어 Parquet로 변환·저장할 수 있습니다.
Lambda는 파일을 처리하지 않고 Glue 작업만 호출하므로, 1GB 제한·타임아웃 문제가 없습니다.
2. 업로드 시 트리거
S3 PUT 이벤트로 Lambda 실행 → Lambda가 Glue ETL 작업 시작 (업로드된 객체 경로 전달).
“파일이 업로드될 때마다” 변환하는 요구사항을 만족합니다.
3. 운영 오버헤드 최소
Glue: 서버리스 ETL, 클러스터/패치 관리 불필요.
Lambda: 트리거만 담당, 짧은 실행으로 유지.
EMR 등 클러스터를 직접 운영할 필요가 없습니다.
4. 역할 분담
Lambda: S3 이벤트 수신 → Glue 작업 시작 (버킷/키 등 전달).
Glue: S3 CSV 읽기 → Parquet 변환 → S3에 출력.
Answer: A
Amazon RDS에서 실행되는 모든 DB에 대한 데이터 보존 정책 도입
요구사항
- 최소 2년간 일일 백업 유지
- 백업이 일관적이고 복원 가능해야 함
A. AWS Backup 백업 볼트 + 일일 계획 + 2년 만료
1. 2년 보존
AWS Backup 백업 계획에서 만료 규칙을 “생성 후 2년”으로 설정하면, 해당 기간 동안 백업을 보관할 수 있습니다.
RDS 자동 백업만 쓰면 최대 35일이라 2년을 못 채우지만, AWS Backup으로 보관 기간을 2년으로 맞출 수 있습니다.
2. 일일 백업
백업 계획에 일일 스케줄을 넣으면, 모든 할당된 RDS DB 인스턴스에 대해 매일 백업이 생성됩니다.
3. 일관성·복원 가능
AWS Backup의 RDS 백업은 RDS 스냅샷 기반으로, 일관된 시점 백업이며, 복원 시 그 시점으로 복구할 수 있어 “일관되고 복원 가능” 요구사항을 충족합니다.
4. 모든 DB 적용
한 백업 계획에 모든 RDS DB 인스턴스를 할당하면, “모든 데이터베이스에 대해” 정책을 한 번에 적용할 수 있습니다.
5. 관리형
백업 볼트·계획·만료는 AWS가 관리하므로, 운영 부담이 적습니다
Answer: D
요구사항
Windows Server SMB 파일 공유를 AWS로 이전
온프레미스 자체 관리형 Active Directory가 파일·폴더 접근 제어
Amazon FSx for Windows File Server 사용 예정
요구사항: 온프레미스 AD 그룹이 AWS 이전 후에도 FSx SMB 공유·폴더·파일 접근을 제한하는지 확인
FSx for Windows File Server 파일 시스템은 이미 생성된 상태
D. 파일 시스템을 Active Directory에 연결
1. FSx for Windows File Server의 접근 제어
FSx for Windows File Server는 SMB를 쓰며, Microsoft Active Directory에 조인해 AD 사용자·그룹으로 인증·권한을 적용합니다.
공유·폴더·파일 수준 권한은 Windows ACL(NTFS/공유 권한) 과 AD 그룹으로 제어합니다.
2.온프레미스 AD 그룹으로 제한하려면
온프레미스 AD 그룹이 FSx에서도 그대로 쓰이려면, FSx 파일 시스템을 해당 Active Directory에 연결(조인) 해야 합니다.
조인 후에는 같은 AD 그룹을 FSx 공유·폴더·파일의 ACL에 지정해, 온프레미스와 동일한 방식으로 접근을 제한할 수 있습니다.
3. “액세스를 제한한다”의 의미
“파일 시스템을 Active Directory에 연결하여 액세스를 제한한다” = AD에 조인한 뒤, AD 그룹 기반 ACL로 SMB 액세스를 제한하는 구성을 의미합니다.
이렇게 해야 “온프레미스 Active Directory 그룹이 AWS로 이동한 후에도 FSx SMB 규정 준수 공유·폴더·파일에 대한 액세스를 제한한다”는 요구사항을 충족합니다.
4. 실제 구성
FSx 생성/설정 시 Self-managed Active Directory (온프레미스 AD)를 지정하고, 네트워크(예: VPN/Direct Connect)와 AD Connector 또는 트러스트 등으로 FSx가 온프레미스 AD에 연결되도록 구성합니다.
그 결과 “파일 시스템을 Active Directory에 연결”한 상태가 되고, D의 설명과 일치합니다.
A. AD Connector로 AD에 연결하는 부분은 맞을 수 있으나, “AD 그룹을 IAM 그룹에 매핑해 액세스 제한”은 FSx SMB 접근 제어 방식이 아님. FSx SMB 권한은 AD 사용자·그룹과 Windows ACL로만 제어되며, IAM 그룹은 FSx 파일/폴더 접근에 사용되지 않습니다.
B. 태그는 리소스 분류·정책용이며, FSx SMB 공유·폴더·파일 수준 접근 제어에는 쓰이지 않습니다. “AD 그룹을 IAM 그룹에 매핑” 역시 FSx SMB 모델과 맞지 않습니다.
C. IAM 서비스 연결 역할은 FSx 리소스 관리(API 호출)용입니다. SMB로 파일·폴더에 접근하는 사용자의 권한은 AD로만 제어되므로, IAM 역할로 “공유·폴더·파일 액세스 제한”을 구현하는 방식이 아닙니다.
Answer:
전 세계 소매 웹사이트, ELB 뒤 여러 EC2, 다중 AZ Auto Scaling
요구사항: 고객이 접속하는 장치에 따라 다른 버전의 콘텐츠 제공
A. Amazon CloudFront를 여러 버전의 콘텐츠를 캐시하도록 구성
1. 전 세계 배포
CloudFront는 엣지 로케이션에서 콘텐츠를 캐시·전송하므로, 전 세계 고객에게 낮은 지연으로 제공할 수 있습니다.
2. 여러 버전 캐시
캐시 동작(Cache Behavior) 을 여러 개 두거나, Lambda@Edge와 함께 사용해 장치별(모바일/데스크톱) 로 다른 경로·오리진을 쓰면, 여러 버전의 콘텐츠를 캐시하고 전달할 수 있습니다.
3. 역할
ELB·EC2 앞에 CloudFront를 두어, “장치에 따른 다른 콘텐츠”를 캐시·전달하는 계층을 만드는 작업입니다.
C. User-Agent 헤더를 기반으로 사용자에게 특정 객체를 보내도록 Lambda@Edge 함수 구성
1. 장치 구분
User-Agent 헤더에는 브라우저·OS·장치 종류(모바일/데스크톱 등) 정보가 들어 있어, 장치에 따라 다른 콘텐츠를 보낼 때 사용합니다.
2. Lambda@Edge
CloudFront 뷰어 요청 또는 오리진 요청에서 실행되며, 요청 헤더(User-Agent 등) 를 읽을 수 있습니다.
이 헤더를 보고 요청 URI 변경(예: /mobile/, /desktop/) 또는 다른 오리진/캐시 동작으로 보내서, 특정 객체(장치별 버전) 를 사용자에게 보내도록 할 수 있습니다.
3. 요구사항 충족
“장치에 따라 다양한 버전의 콘텐츠 제공”을 User-Agent 기반으로 특정 객체 전달하는 방식으로 구현하는 작업입니다.
Answer: C
캐시 VPC: ElastiCache 클러스터
앱 VPC: 웹 애플리케이션 EC2
동일 리전(us-east-1)
요구사항: 앱 VPC의 EC2가 캐시 VPC의 ElastiCache에 접근
목표: 가장 비용 효율적인 방법
A. VPC 피어링 + 라우팅 + ElastiCache 보안 그룹
1. 비용 효율
VPC 피어링은 같은 리전에서 두 VPC를 직접 연결합니다.
같은 리전 피어링 트래픽은 데이터 전송 비용이 없거나 매우 낮습니다.
Transit VPC처럼 별도 VPC·가상 라우터(EC2)가 필요 없어 가장 비용 효율적입니다.
2. 연결성
두 VPC에 피어링 연결용 라우팅만 추가하면 됩니다.
앱 VPC → 캐시 VPC CIDR → 피어링 연결
캐시 VPC → 앱 VPC CIDR → 피어링 연결
3. 보안 그룹
ElastiCache에는 보안 그룹이 붙습니다.
ElastiCache 보안 그룹에서 애플리케이션(EC2) 보안 그룹에서 오는 인바운드를 허용하면, 앱 EC2만 캐시에 접근할 수 있습니다.
“애플리케이션의 보안 그룹에서 인바운드 연결을 허용하도록 ElastiCache 클러스터의 보안 그룹에 규칙 구성”이 맞는 설명입니다.
C. 피어링 연결에는 보안 그룹이 없습니다. 보안 그룹은 ENI가 있는 리소스(EC2, ElastiCache, RDS 등)에만 붙습니다. “피어링 연결의 보안 그룹”은 잘못된 표현이며, 실제로는 ElastiCache 보안 그룹에서 앱 보안 그룹을 허용해야 합니다.
Answer: A, D
여러 마이크로서비스로 구성된 애플리케이션
컨테이너로 AWS에 배포
요구사항
- 유지보수·확장에 드는 지속적인 노력 최소화
- 추가 인프라를 관리할 수 없음 (서버/클러스터 직접 관리 불가)
A. Amazon ECS 클러스터 배포
1. ECS 클러스터
Amazon ECS는 AWS가 제공하는 관리형 컨테이너 오케스트레이션입니다.
클러스터는 태스크/서비스를 묶는 논리 단위이며, Fargate만 쓰면 EC2를 둘 필요가 없습니다.
“추가 인프라를 관리할 수 없음” 조건을 지키려면, 이 클러스터 위에 Fargate 기반 서비스(D) 를 두는 구성이 맞습니다.
2. 역할
컨테이너를 돌리기 위한 첫 단계로 ECS 클러스터를 배포하는 작업입니다.
D. Fargate 시작 유형으로 ECS 서비스 배포, 원하는 태스크 수 ≥ 2
1. 인프라 관리 불필요
Fargate는 서버리스 컨테이너 실행 방식입니다.
EC2를 프로비저닝·패치·스케일할 필요가 없고, CPU/메모리만 지정하면 AWS가 실행 환경을 관리합니다.
“추가 인프라를 관리할 수 없음”, “유지보수·확장 노력 최소화” 요구사항을 직접 충족합니다.
2. 고가용성
원하는 태스크 수를 2 이상으로 두면, 마이크로서비스가 최소 2개 인스턴스로 돌아가 가용성을 확보할 수 있습니다.
Answer: D
Route 53이 트래픽을 보내는 EC2 10대 이상의 웹 애플리케이션
문제: 접속 시 타임아웃 발생
원인: DNS 쿼리 결과에 비정상(unhealthy) 인스턴스 IP가 포함됨 → 해당 IP로 접속하면 타임아웃
목표: 이 타임아웃을 없애는 구성
D. ALB + 상태 확인, Route 53 → ALB
1. 비정상 인스턴스 IP가 DNS에 노출되지 않음
Route 53은 ALB 한 개만 가리키도록 합니다 (A 레코드 Alias 또는 CNAME).
클라이언트는 항상 ALB의 IP/호스트명만 받고, 개별 EC2 IP는 DNS에 나오지 않습니다.
2. 상태 확인으로 정상 인스턴스만 사용
Application Load Balancer(ALB) 가 대상 그룹 상태 확인으로 EC2 상태를 검사합니다.
트래픽은 정상(healthy) 인스턴스로만 전달되므로, 비정상 인스턴스로 연결되어 생기던 타임아웃을 제거할 수 있습니다.
3. 운영 부담 적음
EC2가 늘어나거나 줄어들어도 대상 그룹에만 등록/해제하면 되고, Route 53 레코드는 그대로입니다.
인스턴스마다 Route 53 레코드를 만들거나 수정할 필요가 없습니다.
4. 일반적인 웹 구성
Route 53 → ALB → EC2 + ALB 상태 확인은 AWS에서 권장하는 표준 패턴입니다.
B. 장애 조치(Failover) 라우팅은 주/보조 한 쌍(예: 1차/2차 리전)용입니다. EC2 10대 이상을 각각 장애 조치 레코드로 두는 구성이 아니며, “여러 인스턴스 중 정상인 것만 쓰기”에는 적합하지 않습니다.
Answer: C
요구사항
- 웹·앱·DB 3계층 고가용성 애플리케이션
- HTTPS 콘텐츠는 가능한 한 에지에 가깝게, 전송 시간 최소화
가장 안전한 솔루션 선택
C. 프라이빗 EC2 + 퍼블릭 ALB + CloudFront 오리진 = ALB
1. 에지에서 HTTPS, 전송 시간 최소화
Amazon CloudFront를 쓰면 콘텐츠가 엣지 로케이션에서 캐시·전송됩니다.
사용자와 가까운 엣지에서 HTTPS로 제공되므로 전송 구간·지연이 줄어듭니다.
오리진을 퍼블릭 ALB 한 개로 두면, CloudFront는 ALB로만 가져오고, ALB가 백엔드 상태를 관리합니다.
2. 가장 안전한 구성
EC2(웹/앱) 를 프라이빗 서브넷에 두면, 인터넷에서 직접 EC2에 접근할 수 없습니다.
인터넷에 노출되는 것은 퍼블릭 ALB와 CloudFront뿐이며, ALB가 상태 확인으로 정상 EC2로만 트래픽을 보냅니다.
“가장 안전한 솔루션” 요구사항을 만족합니다.
3. 고가용성
여러 EC2 + ALB(다중 AZ) + CloudFront로 고가용성 구조를 만들 수 있습니다.
4.오리진으로 ALB 사용
CloudFront 오리진을 ALB로 두면, 단일 엔드포인트에 헬스 체크가 적용되어, 비정상 EC2로 트래픽이 가지 않습니다.
오리진을 여러 EC2로 두는 것보다 운영과 안정성 측면에서 유리합니다
[사용자] → HTTPS → [CloudFront] (에지, 캐시)
↓
[퍼블릭 ALB] (퍼블릭 서브넷)
↓
[EC2 웹/앱] (프라이빗 서브넷) → [DB]
Answer: A
인기 게임 플랫폼, AWS에서 실행
대기 시간에 민감 (경험·공정성에 영향)
모든 AWS 리전에 배포
ALB 뒤 Auto Scaling 그룹의 EC2에서 실행
요구사항
- 애플리케이션 상태 모니터링
- 트래픽을 정상 엔드포인트로만 보내는 리디렉션(라우팅) 메커니즘
A. AWS Global Accelerator + ALB 엔드포인트
1. 정상 엔드포인트로만 트래픽 전달
AWS Global Accelerator는 엔드포인트 상태 확인을 수행합니다.
각 리전의 ALB를 리전 엔드포인트로 등록하면, 비정상(unhealthy) 엔드포인트에는 트래픽을 보내지 않고, 정상 엔드포인트로만 트래픽을 보냅니다.
“트래픽을 정상 엔드포인트로 리디렉션하는 메커니즘” 요구사항을 충족합니다.
2. 애플리케이션 상태 모니터링
Global Accelerator가 엔드포인트(ALB) 헬스 체크를 하므로, 엔드포인트 단위로 애플리케이션(ALB 뒤 서비스) 상태를 모니터링하는 역할을 합니다.
3. 대기 시간 최소화
Global Accelerator는 고정 Anycast IP와 AWS 글로벌 네트워크를 사용해, 사용자를 가깝고 정상인 엔드포인트로 라우팅합니다.
여러 리전에 배포된 게임에 적합한 저지연·다중 리전 트래픽 분배가 가능합니다.
4. 구성
액셀러레이터 생성 → 리스너 추가(애플리케이션이 사용하는 포트) → 각 리전의 ALB를 리전 엔드포인트로 추가.
클라이언트는 Global Accelerator의 고정 IP로 접속하고, Accelerator가 정상 ALB 중 하나로 트래픽을 보냅니다.
Answer: D
백만 명 사용자의 모바일 앱
요구사항
- 거의 실시간 데이터 사용량 분석
- 거의 실시간으로 데이터 암호화 후 Apache Parquet로 중앙(S3) 에 저장해 추가 처리
목표: 최소한의 운영 오버헤드
D. Kinesis Data Firehose + S3 + Kinesis Data Analytics
1. 암호화 + Parquet + S3 (중앙 저장)
Amazon Kinesis Data Firehose는 스트리밍 데이터를 받아 S3에 적재할 수 있습니다.
Firehose에서 형식 변환(Parquet) 과 암호화(S3 SSE 등) 를 설정할 수 있어, “실시간에 가깝게 암호화하고 Parquet으로 중앙(S3)에 저장” 요구사항을 충족합니다.
2. 거의 실시간 분석
Amazon Kinesis Data Analytics는 스트리밍 데이터를 실시간에 가깝게 분석합니다.
Firehose(또는 동일 소스를 공유하는 스트림)를 소스로 쓰면, 데이터 사용량 분석을 거의 실시간으로 할 수 있습니다.
3. 최소한의 운영 오버헤드
Firehose: 서버리스, 프로비저닝·패치 불필요.
Data Analytics: 서버리스, 클러스터 관리 없음.
EMR·Lambda 파이프라인 없이도 구성 가능해, “최소한의 운영 오버헤드”에 맞습니다.
4. D만의 조합
Firehose → S3(Parquet, 암호화) + Data Analytics → 분석.
EMR(C)은 제외되어 운영 부담이 적고, Data Streams + Lambda 등 복잡한 조합(A, B)도 필요 없습니다.
Answer: B
점수 표시 웹 앱: EC2 + ALB, RDS for MySQL
문제: DB 읽기 성능으로 긴 지연·중단 발생
요구사항: 애플리케이션 아키텍처 변경을 최소화하면서 사용자 경험 개선
B. RDS Proxy
1. 아키텍처 변경 최소화
RDS Proxy는 애플리케이션과 RDS 사이에만 둡니다.
연결 문자열만 RDS 엔드포인트 → RDS Proxy 엔드포인트로 바꾸면 됩니다.
애플리케이션 코드·로직 변경 없이, DB 연결 경로만 Proxy로 바꾸는 수준이라 “아키텍처 변경 최소화”에 맞습니다.
2. 읽기 성능·지연·중단 완화
커넥션 풀링: 많은 앱 연결을 소수의 DB 연결로 묶어, 커넥션 생성/해제 비용과 DB 부담을 줄입니다.
커넥션 고갈로 인한 지연·타임아웃·중단을 줄이는 데 도움이 됩니다.
RDS 장애 조치 시 연결 재시도·세션 유지를 Proxy가 처리해, 사용자 경험을 개선할 수 있습니다.
3. 다른 선택지와 비교
A (ElastiCache): 캐시를 쓰려면 앱에서 “캐시 조회 → 미스 시 DB 조회 → 캐시 갱신” 로직을 넣어야 해서 코드·아키텍처 변경이 큼.
C (Lambda): EC2 → Lambda 전환은 배포·아키텍처 전반을 바꾸는 큰 변경.
D (DynamoDB): RDB → NoSQL, 스키마·쿼리·API가 달라 앱 대규모 수정 필요.
Answer: C
RDS 기반 전자상거래 웹 애플리케이션
문제: 성능 저하
원인: 비즈니스 분석가가 실행하는 읽기 전용 SQL 쿼리 증가
요구사항: 기존 웹 애플리케이션 변경을 최소화하면서 해결
C. 읽기 복제본 생성 후 분석가가 복제본에서 쿼리
1. 애플리케이션 변경 최소화
RDS 읽기 복제본은 기본(primary) DB와 동일한 스키마·SQL을 사용합니다.
웹 앱: 그대로 기본 DB만 사용 (코드·연결 변경 없음).
비즈니스 분석가: 쿼리 도구의 연결 대상만 기본 DB → 읽기 복제본 엔드포인트로 바꾸면 됩니다.
추가 ETL, 데이터 모델·DB 변경, 앱 코드 수정이 필요 없어 “최소한의 변경”에 맞습니다.
2. 성능 문제 해결
읽기 전용 쿼리가 기본 DB에 몰리면 웹 트랜잭션과 리소스를 나눠 써서 성능이 떨어집니다.
읽기 복제본을 두고 분석가 쿼리를 복제본으로 보내면, 기본 DB 부하는 줄고 웹 앱 성능이 개선됩니다.
3. 운영·구성 단순
RDS 콘솔/CLI에서 읽기 복제본 생성만 하면 되고, 별도 클러스터·ETL 파이프라인을 만들 필요가 없습니다.
Answer: A
중앙 AWS 계정, 여러 S3 버킷에 로그 데이터 저장
요구사항
- S3에 업로드되기 전에 저장 데이터(미사용/휴지 데이터)가 암호화되었는지 확인
- 전송 중에도 암호화되어야 함
A. 클라이언트 측 암호화
1. “업로드되기 전에” 암호화
클라이언트 측 암호화는 데이터를 S3로 보내기 전에 클라이언트에서 암호화합니다.
S3에 도달하는 시점에는 이미 암호화된 형태이므로, “S3 버킷에 업로드되기 전에 미사용(휴지) 데이터가 암호화되었는지 확인” 요구사항을 직접 충족합니다.
2. 전송 중 암호화
클라이언트가 암호화한 뒤 HTTPS(TLS) 로 전송하면, 전송 구간에서도 암호화됩니다.
“전송 중에 암호화” 요구사항을 만족합니다.
3. 저장 시(At rest) 암호화
S3에 저장되는 객체 자체가 이미 암호화된 상태이므로, 저장 시 암호화도 충족합니다.
A. 데이터가 S3에 도달한 뒤 S3가 암호화합니다. 업로드되는 페이로드는 암호화 전 상태로 전송됩니다.
Answer: C
야간 배치 작업이 매일 오전 1시에 시작
문제: 원하는 EC2 용량에 도달하기까지 1시간이 걸려, 그동안 자동 확장에만 시간이 소요됨
요구사항
- 원하는 EC2 용량에 빠르게 도달 (배치 시작 시점에 준비)
- 배치 완료 후 Auto Scaling 그룹 축소 가능
비용 효율적인 방식
C. 예약된 확장
1. 원하는 용량에 빠르게 도달
예약된 확장(Scheduled scaling) 으로 배치 시작 전(예: 오전 0시 50분)에 원하는 용량(desired capacity) 으로 스케일 아웃하도록 설정할 수 있습니다.
배치가 오전 1시에 시작할 때는 이미 원하는 EC2 수가 준비되어 있어, “1시간 동안 확장되는” 지연이 사라집니다.
2. 배치 후 축소
배치가 끝나는 시각에 맞춰 예약된 축소를 넣거나(예: 오전 6시에 desired capacity를 최소로 설정), 기존 메트릭 기반 축소 정책을 그대로 두면 됩니다.
“배치 완료 후 ASG가 축소될 수 있는” 요구사항을 충족합니다.
3. 비용 효율
필요한 시간대에만 용량을 올리고, 나머지 시간에는 최소 용량으로 유지할 수 있어 비용 효율적입니다.
최소 용량을 늘리는 방식(A)보다 불필요한 24시간 가동을 피할 수 있습니다.
4. 예측 가능한 부하에 적합
“매일 밤 같은 시간, 같은 최대 용량”처럼 패턴이 고정되어 있으므로, 예약된 확장이 가장 잘 맞습니다.
Answer: B
ALB 뒤 EC2에서 동적 웹사이트 제공
다국어 지원, 전 세계 고객 대상
현재: us-west-1 한 리전만 사용 → 다른 지역 사용자 지연 큼
요구사항
- 위치와 관계없이 빠르고 효율적으로 요청 처리
- 여러 리전에 아키텍처를 다시 만들지 않음 (us-west-1만 유지)
B. CloudFront + ALB 오리진 + Accept-Language 캐시
1. 아키텍처 재생성 없음
Amazon CloudFront만 앞에 두고, 오리진은 기존 ALB(us-west-1) 로 유지합니다.
EC2·ALB를 다른 리전에 복제하지 않고 한 리전(us-west-1) 만 사용합니다.
“여러 지역에 걸쳐 기존 아키텍처를 다시 생성하지 않는다”는 조건을 만족합니다.
2. 전 세계 사용자 지연 감소
사용자는 가장 가까운 CloudFront 엣지에 연결합니다.
캐시 적중 시: 엣지에서 바로 응답 → 지연 감소.
캐시 미스(동적 요청) 시: 엣지 → us-west-1 ALB로 전달되지만, 사용자–엣지 구간이 짧아져 전체 체감 지연이 줄어듭니다.
3. 다국어 지원
캐시 동작에서 Accept-Language 를 캐시 키에 포함하면, 언어별로 다른 객체가 엣지에 캐시됩니다.
“여러 언어 지원”하면서 “빠르고 효율적으로” 제공할 수 있습니다.
4. 동적 웹사이트 유지
오리진이 ALB + EC2이므로 동적 콘텐츠는 그대로 처리하고, 캐시 가능한 부분만 CloudFront에서 처리하는 구조를 유지할 수 있습니다.
Answer: B
단일 리전에서 워크로드 실행 중인 전자상거래
다른 AWS 리전을 포함하는 재해 복구(DR) 전략 필요
요구사항
- 대기 시간 최소화하면서 DR 리전 DB를 최신 상태로 유지
- DR 리전의 나머지 인프라는 감소된 용량으로 운영, 필요 시 확장 가능
- 가장 낮은 RTO(복구 시간 목표)
B. Aurora 글로벌 DB + 웜 스탠바이
1.. 다른 리전 포함 (크로스 리전 DR)
Amazon Aurora 글로벌 데이터베이스는 다른 AWS 리전에 보조(secondary) 클러스터를 두고 지속 복제합니다.
RDS Multi-AZ(C, D)는 한 리전 내 다중 AZ만 제공하므로, 리전 전체 장애 시 DR이 되지 않습니다. “다른 AWS 리전을 포함”하려면 Aurora 글로벌 DB가 필요합니다.
2. 대기 시간 최소화 + DR DB 최신 유지
Aurora 글로벌 DB는 보통 1초 미만의 복제 지연으로 DR 리전 DB를 최신에 가깝게 유지합니다.
“대기 시간을 최소화하면서 DR 지역에서 데이터베이스를 최신 상태로 유지” 요구사항을 충족합니다.
3. 가장 낮은 RTO
웜 스탠바이: DR 리전에 이미 동작 중인 인프라(DB 보조 클러스터, 축소된 앱 등)를 두고, 장애 시 DB 승격(promotion) + 스케일 업으로 전환합니다.
파일럿 라이트(A): DR 리전에 최소 구성만 두고, 장애 시 리소스 기동·배포가 필요해 RTO가 더 김.
따라서 같은 Aurora 글로벌 DB를 쓸 때 웜 스탠바이(B) 가 RTO가 더 낮습니다.
4. DR 리전: 감소된 용량 + 필요 시 확장
웜 스탠바이에서는 DR 리전을 평소에는 축소된 용량으로 운영하고, 장애 시 스케일 업하도록 설계할 수 있어, “감소된 용량으로 실행, 필요 시 확장” 요구사항과 맞습니다.
C와 같이 RDS Multi-AZ는 단일 리전이므로 크로스 리전 DR이 아니며, “다른 AWS 리전을 포함” 조건을 만족하지 못합니다.
Answer: B
Amazon EC2에서 애플리케이션 실행
재해 복구(DR) 솔루션 필요
요구사항
- RTO(복구 시간 목표) 4시간 미만
- 정상 운영 중에는 가능한 한 적은 AWS 리소스 사용
- 운영상 가장 효율적인 방식으로 구현
B. AMI + 보조 리전 복사 + CloudFormation
1. 정상 시 리소스 최소화
AMI로 EC2를 백업하고, 그 AMI만 보조 AWS 리전에 복사해 두는 파일럿 라이트 방식입니다.
정상 시에는 보조 리전에 실행 중인 EC2가 없고, AMI(및 필요 시 복사 자동화)만 있으면 되어 리소스 사용을 최소화할 수 있습니다.
2. RTO 4시간 미만
장애 시 AWS CloudFormation으로 보조 리전에 스택(EC2, VPC, 보안 그룹 등) 을 한 번에 배포할 수 있습니다.
AMI ID를 파라미터로 넘기면, 복제해 둔 AMI로 EC2를 기동하는 구조로 복구 시간을 단축할 수 있어 RTO 4시간 미만을 만족할 수 있습니다.
3. 운영 효율
CloudFormation은 인프라를 코드(IaC) 로 관리하므로,
반복 배포·롤백이 쉽고
사용자 지정 스크립트 유지보수가 필요 없으며
표준화된 DR 절차를 유지하기 쉽습니다.
따라서 “운영상 가장 효율적인 방식” 요구사항에 맞습니다.
4. 크로스 리전 DR
AMI를 보조 리전에 복사해 두므로, 리전 장애 시에도 다른 리전에서 복구할 수 있습니다.
Answer: C
ALB 뒤 EC2에서 내부 브라우저 앱 실행
Auto Scaling: 근무 시간 최대 20대, 밤에는 2대로 축소
문제: 하루가 시작될 때 매우 느리다는 불만 (오전 중반부터는 괜찮음)
요구사항: 직원 불만 해소 + 비용 최소화
원인 :
밤에는 2대만 떠 있음.
출근 시간에 트래픽이 한꺼번에 늘어나면, ASG가 CPU 등 메트릭에 반응해 2 → 20대로 늘어나는 데 시간이 걸림.
그동안 2대만 트래픽을 받아서 출근 직후에 느리게 느껴짐. 오전 중반쯤 20대에 도달하면 정상.
C. 대상 추적 + 낮은 CPU 임계값 + 짧은 휴지 기간
1. 직원 불만 완화
대상 추적(Target tracking) 에서 CPU 목표를 더 낮게(예: 70% → 40%) 두면, CPU가 더 일찍 올라가는 시점에 스케일 아웃이 시작됩니다.
휴지 기간(cooldown)을 줄이면 스케일 아웃이 더 자주 일어나서, 트래픽 증가에 더 빨리 반응합니다.
그래서 출근 시간에 2대만 있는 구간이 짧아지고, “하루 시작할 때 느리다”는 현상이 줄어듭니다.
2. 비용 최소화
예약 확장(A, D) 처럼 “사무실 열기 전에 20대로 미리 올려 둠”이 아니라, 실제 부하에 맞춰 스케일 아웃만 더 빨리 하도록 바꾸는 방식입니다.
필요할 때만 더 빨리 늘리므로, 불필요한 선제 확장을 피해 비용을 최소화할 수 있습니다.
3. 운영 효율
대상 추적은 “목표 CPU 한 개”만 설정하면 되고, 예약 작업처럼 출근/퇴근 시각을 관리할 필요가 없습니다.
부하 패턴이 바뀌어도 자동으로 적절한 인스턴스 수를 유지하기 쉽습니다.
4. B(단계 조정)와의 차이
단계 조정은 구간별 임계값·증가량을 여러 개 튜닝해야 해서 운영이 더 복잡합니다.
“출근 시간에 더 빨리 늘리기 + 비용 최소”에는 대상 추적(C) 이 더 단순하고 적합합니다.
Answer: A, D
다중 계층 앱: Auto Scaling 그룹의 EC2 + RDS for Oracle(PL/SQL 사용)
문제 1: 트래픽 증가로 EC2 과부하
문제 2: RDS 스토리지 부족
현재 ASG: 조정 지표 없음, 최소 정상 인스턴스 수만 설정
요구사항: 트래픽이 꾸준히 늘어나는 동안 시스템이 자동으로 확장되도록
A. RDS for Oracle 인스턴스에서 스토리지 Auto Scaling 구성
1. RDS 스토리지 부족 대응
RDS Storage Auto Scaling을 켜면, 사용량이 설정한 수준(예: 사용 가능 공간 부족)에 도달할 때 스토리지를 자동으로 늘립니다.
“RDS 인스턴스의 스토리지가 부족해진다”는 문제를 자동 확장으로 해결할 수 있습니다.
2. 자동 확장
스토리지가 부족할 때 수동 증설 없이 용량이 늘어나므로, “시스템이 자동으로 확장될 수 있도록” 요구사항을 충족합니다.
D. 평균 CPU를 조정 지표로 사용하도록 Auto Scaling 그룹 구성 ✓
1. EC2 과부하 대응
현재 ASG에는 조정 지표가 없어 부하가 늘어도 인스턴스 수가 늘지 않습니다.
평균 CPU를 조정 지표(예: 대상 추적 스케일링의 목표 CPU)로 두면, CPU가 높을 때 EC2 인스턴스 수가 자동으로 증가합니다.
2. 트래픽 증가에 맞춘 확장
트래픽이 “꾸준하지만 예측하기 어렵게” 늘어나도, CPU가 올라가는 시점에 자동으로 스케일 아웃되므로 “증가된 트래픽에 대해 시스템이 자동으로 확장”되게 할 수 있습니다.
3. 역할 분담
A: RDS 스토리지 자동 확장
D: EC2(ASG) 자동 확장 (CPU 기반)
Answer: D
비디오 게시·트랜스코딩 온라인 서비스
현재: Amazon EFS Standard에 비디오 저장, 여러 EC2가 공유 접근해 처리
문제: 인기 증가로 스토리지 비용이 과도하게 높음
가장 비용 효율적인 스토리지 솔루션
D. S3 저장 + EBS에서 임시 처리
1. 스토리지 비용 절감
Amazon S3는 대용량 객체 저장에 EFS Standard보다 훨씬 저렴합니다.
비디오는 용량이 크고, 장기 보관 시 S3 Standard 또는 S3 IA 등으로 저비용 보관할 수 있어, “스토리지 비용이 너무 비싸다”는 문제를 직접 줄입니다.
2. 처리 워크플로
저장: 비디오는 S3에 보관 (대량·저비용).
처리: 트랜스코딩 시에만 S3에서 EC2에 연결된 EBS로 임시로 복사해 사용.
처리 후 결과를 S3에 저장하고, EBS의 임시 파일은 삭제하거나 덮어쓰면 EBS는 작업 중인 파일만 유지하게 됩니다.
EBS는 처리 중인 용량만 쓰므로, 전체 비디오를 EFS/EBS에 상주시키는 것보다 비용이 적습니다.
3. EFS 대비
EFS는 GB당 요금이 S3보다 높고, 대용량 비디오 라이브러리에는 비용이 많이 듭니다.
S3(대량) + EBS(임시 처리용) 조합이 가장 비용 효율적입니다.
4. 다중 EC2 처리
각 EC2가 S3에서 자신이 처리할 비디오만 EBS로 가져와 트랜스코딩하면 되므로, 여러 인스턴스가 동시에 처리하는 구조와 잘 맞습니다.
Answer: B, E
계층적 구조로 직원 데이터를 저장하는 애플리케이션
요구사항
- 트래픽이 많은 쿼리에 최소 지연 응답
- 민감한 데이터 보호
- 직원 데이터에 재무 정보가 있으면 월별 이메일 수신
B. Amazon DynamoDB로 직원 데이터를 계층에 저장, 매월 S3로 내보내기
1. 최소 지연 + 많은 쿼리
DynamoDB는 밀리초 단위 지연, 높은 처리량으로 “트래픽이 많은 쿼리에 대한 최소 대기 시간” 요구에 적합합니다.
2. 계층적 구조
중첩 속성(문서 형태)이나 PK/SK 설계(예: PK=조직, SK=직원#ID)로 계층적 직원 데이터를 저장할 수 있습니다.
3. 민감 데이터 보호
암호화(저장 시), IAM, VPC 엔드포인트 등으로 민감한 데이터 보호가 가능합니다.
4. 매월 S3 내보내기
매월 DynamoDB → S3 내보내기를 하면, 백업·아카이브와 함께 Macie 등으로 S3 데이터 검사(재무 정보 등)를 할 수 있어 E와 연결됩니다.
E. Amazon Macie 구성 + EventBridge + SNS로 월별 이메일 알림
1. 재무 정보 탐지
Amazon Macie는 S3 등에 있는 민감·재무 정보(PII, 금융 데이터)를 자동 탐지·분류합니다.
B에서 매월 S3로 내보낸 직원 데이터를 Macie가 검사할 수 있습니다.
2. 월별 이메일
Macie 탐지 결과를 EventBridge로 받고, Amazon SNS 구독으로 이메일을 보내면 “재무 정보가 있을 때 월별 이메일” 요구를 충족합니다.
EventBridge 규칙에서 Macie 이벤트를 필터해 월별 실행 또는 특정 발견 시 SNS로 보내도록 구성할 수 있습니다.
Answer: A
Amazon DynamoDB 테이블 기반 애플리케이션
요구사항
- 매월 데이터베이스 백업
- 백업이 6개월 동안 사용 가능해야 함
- 백업을 7년 동안 유지해야 함
A. AWS Backup 계획 + 수명 주기 + 7년 보존
1. 매월 백업
AWS Backup 백업 계획에서 매월 1일에 DynamoDB 테이블 백업을 실행하도록 스케줄을 설정할 수 있습니다.
“매월 데이터베이스 백업” 요구사항을 충족합니다.
2. 6개월 동안 사용 가능
수명 주기 정책으로 6개월 후 백업을 콜드 스토리지로 전환하도록 설정할 수 있습니다.
6개월 이내 백업은 워밍/표준 구간에 두어 빠르게 사용 가능하게 하고, 6개월 이후는 비용 절감을 위해 콜드로 이동하는 방식으로 “6개월 동안 사용 가능”을 만족할 수 있습니다.
3. 7년 유지
보존 기간(retention) 을 7년으로 설정하면, 해당 기간 동안 백업이 유지됩니다.
“7년 동안 유지” 요구사항을 충족합니다.
4. 관리형 서비스
AWS Backup이 DynamoDB 백업·수명 주기·보존을 관리하므로, 별도 스크립트·CLI 자동화 없이 규정 준수를 구현할 수 있습니다.
Answer: B
요구사항
- 로그에 대한 고급 분석
- 시각화 구축
B. Athena + QuickSight
1. 고급 분석
Amazon Athena는 S3에 있는 데이터를 표준 SQL로 쿼리합니다.
CloudFront 로그가 S3에 있으므로, 테이블 스키마를 정의한 뒤 Athena에서 표준 SQL로 집계·필터·조인 등 고급 분석을 할 수 있습니다.
2. 시각화
Amazon QuickSight는 AWS의 BI·시각화 서비스입니다.
Athena를 데이터 소스로 연결하고, 쿼리 결과나 데이터셋을 이용해 대시보드·차트·보고서를 만들 수 있어 “시각화 구축” 요구사항을 충족합니다.
3. 연동
Athena ↔ QuickSight 연동이 지원되므로, Athena로 분석한 결과를 QuickSight에서 바로 시각화하는 흐름이 자연스럽습니다.
AWS Glue는 ETL·데이터 카탈로그·Spark 작업용입니다. (데이터를 모아서 → 정리해서 → 다른 곳에서 쓰기 좋게 만들어주는 자동화 서비스)
ETL = Extract(가져오기) → Transform(가공) → Load(저장)
Spark = 대용량 데이터 처리 엔진 (수십 GB ~ TB 데이터도 빠르게)
Parquet는 “분석용으로 최적화된 컬럼 기반 데이터 파일 형식”
원본 데이터 (CSV / JSON / 로그)
↓
Glue ETL
↓
Parquet 변환
↓
Athena / Redshift 쿼리
Answer: A
요구사항
Amazon RDS for PostgreSQL 로 웹 서버 플릿 운영
규정 준수: 모든 프로덕션 DB에 RPO(복구 지점 목표) 1초 미만 적용
RPO: 허용 가능한 데이터 손실을 시간으로 나타낸 값. RPO < 1초 = 최대 약 1초 분량의 데이터만 잃어도 되는 수준 → 동기 복제 또는 거의 동기 수준 필요
A. Multi-AZ
1. RPO 1초 미만 충족
RDS Multi-AZ는 동기 복제(Synchronous replication) 를 사용합니다.
트랜잭션이 스탠바이에 동기적으로 기록된 뒤 커밋이 완료되므로, 장애 시 커밋된 데이터는 스탠바이에 이미 반영되어 있습니다.
따라서 데이터 손실이 거의 없어 RPO가 1초 미만(실질적으로 0에 가깝게) 으로 유지됩니다.
2. 프로덕션 표준에 적합
Multi-AZ는 프로덕션 DB의 고가용성·낮은 RPO 요구에 맞는 AWS 권장 구성입니다.
3. 구성
DB 인스턴스에 Multi-AZ 배포만 활성화하면 됩니다.
Answer: B
EC2: VPC 프라이빗 서브넷, 웹 애플리케이션
ALB: 퍼블릭 서브넷, 웹 트래픽을 EC2로 전달
요구사항
- ALB → EC2 인바운드 트래픽만 허용(제한)
- 프라이빗 서브넷 내·외부의 다른 소스에서는 EC2 접근 차단
B. EC2 보안 그룹: ALB 보안 그룹만 허용
1. ALB → EC2만 허용
EC2 보안 그룹 인바운드 규칙에 소스 = ALB 보안 그룹으로 두고, 애플리케이션 포트(예: 80, 443)만 열면 됩니다.
ALB에 붙은 보안 그룹을 가진 리소스(ALB)에서 오는 트래픽만 EC2에 도달하므로, “ALB에서 EC2로의 인바운드 트래픽을 제한”하는 요구를 충족합니다.
2. 다른 소스 접근 차단
다른 보안 그룹(다른 EC2, Lambda 등), 프라이빗 서브넷 내 다른 인스턴스, 인터넷 등은 EC2 인바운드 규칙에 없으므로 기본적으로 거부됩니다.
“EC2의 프라이빗 서브넷 내부 또는 외부의 다른 소스로부터의 액세스를 방지” 요구를 충족합니다.
3. 최소 권한
EC2는 ALB 보안 그룹에서 오는 트래픽만 허용하는 최소 권한 구성이 됩니다.
Answer: D
요구사항
시뮬레이션 앱: Linux, 5분마다 NFS 공유에 중간 데이터 출력
시각화 앱: Windows 데스크톱, SMB 파일 시스템 필요, 시뮬레이션 출력 표시
현재 문제: NFS·SMB 두 파일 시스템을 동기화해 유지 → 데이터 중복·비효율
애플리케이션 코드 변경 없이 AWS로 마이그레이션
D. Linux EC2 + Windows EC2 + FSx for NetApp ONTAP
1. 코드 변경 없음
시뮬레이션: Linux EC2에서 기존처럼 NFS로 파일에 쓰면 됨.
시각화: Windows EC2에서 기존처럼 SMB로 파일을 읽으면 됨.
NFS/SMB 접근 방식 그대로 유지하므로 코드 변경이 필요 없습니다.
2. 단일 파일 시스템으로 중복 제거
Amazon FSx for NetApp ONTAP은 한 볼륨에서 NFS와 SMB를 동시에 제공하는 멀티 프로토콜 파일 시스템입니다.
Linux는 NFS로, Windows는 SMB로 같은 FSx 볼륨에 접근하므로, “두 개의 동기화된 파일 시스템”이 필요 없고 데이터 중복· 동기화 비효율이 사라집니다.
3. 워크플로 유지
시뮬레이션이 NFS에 5분마다 쓰면, 같은 볼륨을 SMB로 마운트한 Windows에서 바로 읽어 시각화할 수 있습니다.
별도 동기화·큐·스크립트 없이 파일 공유만으로 요구사항을 충족합니다.
4. 구성
시뮬레이션 → Linux EC2 (NFS 마운트)
시각화 → Windows EC2 (SMB 마운트)
공통 스토리지 → FSx for NetApp ONTAP (NFS + SMB)
Answer: B
예산 계획용으로 경영진이 사용자별로 나열된 AWS 청구 항목 보고서 필요
데이터는 부서 예산 작성에 사용
요구사항: 이 보고서를 얻는 가장 효율적인 방법
B. Cost Explorer에서 보고서 생성 후 다운로드
1. 사용자별 청구 데이터
AWS Cost Explorer는 비용·사용량을 차원별(서비스, 링크된 계정, 비용 할당 태그 등)로 조회·그룹화할 수 있습니다.
비용 할당 태그에 “사용자”(또는 부서/프로젝트)를 붙여 두면, 사용자별로 비용을 나눠 볼 수 있어 “사용자별로 나열된 청구 항목” 보고서에 맞습니다.
2. 가장 효율적인 방법
추가 설정 없이 Cost Explorer만으로 기간·그룹(사용자 태그 등)을 선택하고 보고서 뷰를 만든 뒤 CSV 등으로 다운로드할 수 있습니다.
CUR → S3 → Athena처럼 데이터 파이프라인을 만들 필요가 없어 “가장 효율적인 방법” 요구사항을 충족합니다.
3. 부서 예산 활용
다운로드한 CSV/보고서를 그대로 부서 예산·엑셀·재무 도구에 넣어 사용할 수 있습니다.
Answer: B
Amazon S3로 정적 웹사이트 호스팅
연락처 양식 추가: 이름, 이메일, 전화번호, 메시지 입력 → 서버 측 처리 필요
트래픽: 월 100회 미만 방문 예상
요구사항: 가장 비용 효율적인 방법으로 구현
B. API Gateway + Lambda + SES
1. 비용 효율
API Gateway + Lambda + SES는 서버리스라 요청이 있을 때만 과금됩니다.
월 100회 미만이면 Lambda·API Gateway 무료 티어로 대부분 커버되고, SES도 소량 사용으로 비용이 거의 들지 않아 가장 비용 효율적입니다.
2. 서버 측 처리
API Gateway: 연락처 양식 제출(POST) 용 HTTP 엔드포인트 제공.
Lambda: 요청 본문(이름, 이메일, 전화번호, 메시지) 수신 → 검증·가공 → SES로 이메일 발송.
SES: 회사 메일 등으로 연락처 내용 전달.
정적 사이트(S3)는 그대로 두고, 양식 제출만 API로 처리하는 구조라 “동적 서버 측 구성 요소” 요구를 충족합니다.
3. 정적 호스팅 유지
웹 페이지·정적 자원은 S3에 그대로 두고, JavaScript로 양식 제출만 API Gateway URL로 보내면 됩니다.
S3 정적 호스팅을 바꾸거나 서버를 추가로 운영할 필요가 없습니다.
4. 항상 켜진 서버 없음
EC2, Lightsail, ECS처럼 24시간 동작 인스턴스가 없어 저트래픽 구간에서 유휴 비용이 없습니다.
Answer: C
CloudFront + S3로 정적 웹사이트 호스팅 (DB 백엔드 사용)
문제: Git 리포지토리 업데이트가 웹사이트에 반영되지 않음
확인 결과: Webhook·CI/CD 파이프라인 정상, 배포 성공 메시지 확인 → S3에는 새 콘텐츠가 배포된 상태
요구사항: 웹사이트에 업데이트가 보이도록 할 방법
C. CloudFront 캐시 무효화
1. 캐시 무효화
CloudFront 캐시 무효화(Invalidation) 를 실행하면, 지정한 경로(예: /* 또는 변경된 경로)의 객체가 캐시에서 제거되거나 만료 처리됨.
이후 사용자 요청 시 CloudFront가 S3에서 최신 객체를 다시 가져와서 제공함.
2. 업데이트 노출
캐시 무효화 후에는 새로 배포된 콘텐츠가 웹사이트에 표시되므로, “웹 사이트에 업데이트를 표시” 요구사항을 충족함.
3. CI/CD와 연동
배포 파이프라인 마지막 단계에서
AWS CLI create-invalidation
또는 CodePipeline/CodeBuild에서 invalidation API 호출
으로 배포 성공 시마다 캐시 무효화를 자동 실행하도록 구성할 수 있음.
4. 다른 선택지와의 관계
ALB 추가(A), ElastiCache 추가(B), ACM 인증서(D)는 캐시된 이전 콘텐츠 문제를 해결하지 못함.
해결책은 CloudFront가 캐시한 객체를 버리게 하는 것이므로 C(캐시 무효화) 가 정답임.
Answer: B
Windows 기반 3계층 앱: 애플리케이션·비즈니스·DB(SQL Server) 를 온프레미스 → AWS로 마이그레이션
요구사항
- SQL Server 특정 기능 사용 (기본 백업, 데이터 품질 서비스 등)
- 계층 간 파일 공유 (처리용)
- 아키텍처 설계 방법 선택
B. EC2 3계층 + FSx for Windows File Server
1. SQL Server 특정 기능
세 계층 모두 EC2에 두면 DB 계층은 EC2 위의 Microsoft SQL Server로 구성할 수 있습니다.
EC2 + SQL Server는 전체 SQL Server 기능(백업, 에이전트, 데이터 품질 서비스 등)을 제한 없이 사용할 수 있어, “SQL Server의 특정 기능” 요구를 충족합니다.
2. 계층 간 파일 공유
Amazon FSx for Windows File Server는 Windows 네이티브 SMB 파일 공유를 제공합니다.
애플리케이션·비즈니스 계층 EC2와 SQL Server가 있는 EC2가 같은 FSx 파일 시스템을 SMB로 마운트해 파일을 공유할 수 있습니다.
Windows 앱이 기대하는 SMB 공유 방식과 맞고, “계층 간에 처리를 위해 파일을 공유” 요구를 충족합니다.
3. Windows 환경
앱·비즈니스·DB가 모두 Windows 기반이므로, SMB(FSx for Windows File Server) 가 NFS(EFS)나 단일 인스턴스용 EBS보다 적합합니다.
4. A와의 차이
“Amazon FSx File Gateway”는 제품명이 맞지 않습니다. Storage Gateway File Gateway는 S3를 파일로 노출하는 하이브리드용이고, EC2 간 공유 파일에는 FSx for Windows File Server가 맞습니다. 따라서 B가 올바른 선택입니다.
C. RDS for SQL Server는 일부 SQL Server 기능(에이전트 작업, 특정 백업/데이터 품질 도구 등)에 제한이 있을 수 있어 “특정 기능” 요구를 완전히 충족하지 못할 수 있습니다. EFS는 NFS 기반이라 Windows·SMB 환경에는 FSx for Windows File Server보다 부적합합니다.
Answer: C
요구사항
Linux 기반 웹 서버 그룹을 AWS로 마이그레이션
웹 서버가 일부 콘텐츠를 위해 공유 파일 저장소의 파일에 접근해야 함
애플리케이션을 변경하면 안 됨 (기존 파일 경로/파일 I/O 방식 유지)
C. Amazon EFS
1. 애플리케이션 변경 없음
Amazon EFS는 NFS 프로토콜로 제공되는 공유 파일 시스템입니다.
Linux 웹 서버에서 마운트(예: /mnt/shared)하면 기존 파일 경로(예: /mnt/shared/content/file.html)로 open/read/write 하는 방식 그대로 사용할 수 있습니다.
S3 API·SDK로 바꾸거나 HTTP로 가져오는 식의 코드 변경이 필요 없어 “애플리케이션을 변경해서는 안 됨” 요구를 충족합니다.
2. 공유 파일 저장소
여러 웹 서버가 동일한 EFS 파일 시스템을 마운트하면, 같은 파일 집합에 모두 접근할 수 있습니다.
“공유 파일 저장소의 파일에 액세스” 요구를 충족합니다.
3. Linux 환경
EFS는 Linux NFS 클라이언트로 마운트하는 방식이라, Linux 웹 서버 그룹에 적합합니다.
4. D(EBS)와의 차이
EBS 볼륨은 한 EC2 인스턴스에만 연결됩니다. 여러 웹 서버가 같은 EBS 볼륨을 동시에 마운트하는 일반적인 공유 파일 시스템 구성은 불가능합니다.
“모든 웹 서버에 EBS 볼륨을 마운트”하는 것은 기술적으로 불가능하므로 D는 부적절합니다.
A, B 기존 “파일 경로로 읽기/쓰기”, "공유 파일 저장소" 방식을 유지하려면 앱 코드를 S3 API, 앱 로직을 바꿔야 해
Answer: B
Lambda 함수가 같은 AWS 계정의 S3 버킷에 읽기가 필요
요구사항: 이 요구를 가장 안전한 방식으로 충족
B. Lambda IAM 역할 + 해당 S3 버킷 읽기 정책
1. 자격 증명을 코드에 넣지 않음
Lambda에 IAM 실행 역할을 붙이면, Lambda가 실행될 때 역할을 가정(assume) 해서 S3에 접근합니다.
액세스 키·비밀 키를 코드에 넣을 필요가 없어 유출·로그·저장소 노출 위험이 없습니다.
2. 최소 권한
역할에 IAM 정책으로 해당 S3 버킷에 대한 읽기(s3:GetObject 등) 만 부여할 수 있습니다.
“해당 버킷에 대한 읽기”만 주고, 쓰기·삭제·다른 버킷은 주지 않는 최소 권한을 지킬 수 있어 “가장 안전한 방식”에 맞습니다.
3. 권장 패턴
Lambda → 실행 역할 → 역할 정책(S3 특정 버킷 읽기) 구성은 AWS가 권장하는 표준·안전한 패턴입니다.
4. A(버킷 정책)와의 차이
버킷 정책으로 “Lambda 역할에 읽기 허용”을 줄 수도 있으나, 권한을 주는 쪽은 보통 리소스를 쓰는 주체(Lambda)의 IAM 역할에 두는 것이 일반적입니다.
“가장 안전한 방식”으로 Lambda 쪽 역할에 최소 읽기 권한을 부여하는 B가 정답입니다.
IAM 역할을 쓰는 것은 좋으나, 계정의 모든 S3 버킷에 읽기를 주면 최소 권한 위반입니다.
Answer: C
여러 EC2에서 웹 애플리케이션 호스팅
Auto Scaling 그룹으로 사용자 수요에 따라 확장
요구사항: 장기 약정 없이 비용 절감을 최대한 하고 싶음
C. 온디맨드 + 스팟 혼합
1. 장기 약정 없음
온디맨드와 스팟 모두 약정 없이 사용하는 종량제 요금입니다.
“장기적인 약정 없이” 조건을 만족합니다.
2. 비용 절감
스팟 인스턴스는 온디맨드 대비 최대 약 90% 할인된 가격으로 사용할 수 있어, 같은 워크로드에 온디맨드만 쓰는 것보다 비용을 줄일 수 있습니다.
Auto Scaling 그룹에서 혼합 인스턴스 정책으로, 기본/최소 용량은 온디맨드, 추가 확장분은 스팟으로 두면 비용 절감과 가용성을 함께 맞출 수 있습니다.
3. 웹 애플리케이션에 적합
웹 앱은 여러 인스턴스로 분산되므로, 스팟이 중단되어도 ASG가 다른 인스턴스(온디맨드 또는 새 스팟) 로 대체할 수 있어, “장기 약정 없이 비용 최적화”에 잘 맞습니다.
4. D(예약 인스턴스)가 안 되는 이유
예약 인스턴스(RI) 는 1년 또는 3년 약정이 필요합니다.
“장기적인 약정 없이”라는 요구와 직접적으로 충돌하므로 D는 부적절합니다.
Answer: A, B
요구사항
CloudFront로 S3에 있는 비디오 스트리밍 (공개 스트리밍용)
요구사항: 접근 권한이 있는 사용자만 S3 비디오에 접근하도록 보호
제약
일부 사용자는 쿠키를 지원하지 않는 사용자 지정 HTTP 클라이언트 사용
일부 사용자는 하드코딩된 URL을 바꿀 수 없음
목표: 위 요구사항을 만족하면서 사용자에게 미치는 영향을 최소화
A. 서명된 쿠키
1. 쿠키를 지원하는 클라이언트
CloudFront 서명된 쿠키를 쓰면, 인증된 사용자에게 쿠키를 발급하고, 이후 요청 시 같은 쿠키로 여러 객체(비디오)에 접근할 수 있습니다.
URL을 바꿀 필요가 없고, 쿠키만 지원하면 되므로 “쿠키 지원 클라이언트”에는 영향을 최소화할 수 있습니다.
2. 역할
쿠키를 지원하는 사용자/클라이언트에는 서명된 쿠키(A) 로 접근 제어를 제공하는 방식이 적합합니다.
B. 서명된 URL
1. 쿠키를 지원하지 않는 클라이언트
CloudFront 서명된 URL은 URL 자체에 서명·만료가 들어가므로, 쿠키 없이 URL만으로 접근 제어가 가능합니다.
“쿠키를 지원하지 않는 사용자 지정 HTTP 클라이언트”에는 서명된 URL(B) 이 필요합니다.
2. 하드코딩된 URL을 바꿀 수 없는 경우
URL을 바꿀 수 없다면 같은 URL을 오래 쓸 수 있도록 만료 기간이 긴 서명된 URL을 한 번 발급해 주면 됩니다.
해당 사용자는 한 번 받은 URL을 하드코딩해 두고 쓰면 되므로, “URL을 변경할 수 없음” 제약을 최소 영향으로 만족시킬 수 있습니다.
3. 접근 제어
서명된 URL·서명된 쿠키 모두 권한이 있는 사용자에게만 유효한 URL/쿠키를 발급하는 방식으로 “접근 권한이 있는 사용자만 보호된 콘텐츠 접근” 요구를 충족합니다.
Answer: A, B
여러 소스에서 실시간 스트리밍 데이터 수집
S3에 쓰기 전에 데이터 변환 필요
변환된 데이터를 SQL로 쿼리할 수 있어야 함
A. Kinesis Data Streams → Data Analytics → Firehose → S3 → Athena
1. 실시간 스트리밍
Amazon Kinesis Data Streams로 여러 소스의 실시간 스트리밍 데이터를 수집합니다.
2. S3 쓰기 전 변환
Amazon Kinesis Data Analytics로 스트림 데이터를 변환(예: SQL 기반 또는 Flink)하고, 그 결과를 Kinesis Data Firehose로 보냅니다.
Firehose가 변환된 데이터를 S3에 적재합니다. → “S3에 쓰기 전에 변환” 요구 충족.
3. SQL 쿼리
Amazon Athena로 S3에 쌓인 변환된 데이터를 표준 SQL로 쿼리할 수 있습니다.
4. 흐름
소스 → Data Streams → Data Analytics(변환) → Firehose → S3 → Athena(SQL)
→ 요구사항을 모두 만족하므로 정답(A) 입니다.
B. Amazon MSK → AWS Glue → S3 → Athena
1. 실시간 스트리밍
Amazon MSK(Managed Streaming for Apache Kafka)로 여러 소스의 실시간 스트리밍 데이터를 수집합니다.
2. S3 쓰기 전 변환
AWS Glue로 MSK(또는 중간 스토리지)에서 데이터를 읽어 변환(ETL) 한 뒤 S3에 씁니다.
Glue Streaming ETL로 Kafka/MSK → 변환 → S3 파이프라인 구성 가능. → “S3에 쓰기 전에 변환” 요구 충족.
3. SQL 쿼리
Amazon Athena로 S3에 있는 변환된 데이터를 표준 SQL로 쿼리할 수 있습니다.
4. 흐름
소스 → MSK → Glue(변환, S3 기록) → S3 → Athena(SQL)
→ 요구사항을 모두 만족하므로 정답(B) 입니다.
Answer: D
수명이 다한 온프레미스 볼륨 백업 솔루션을 대체
AWS를 새 백업 솔루션의 일부로 사용
요구사항
- AWS로 백업되는 동안 모든 데이터에 대한 로컬 액세스 유지
- AWS에 백업된 데이터가 자동으로·안전하게 전송되기
D. Storage Gateway – 저장된 볼륨
1. 모든 데이터에 대한 로컬 액세스
저장된 볼륨(Stored Volume) 모드에서는 주 데이터가 온프레미스 스토리지에 저장됩니다.
게이트웨이 스토리지 볼륨이 온프레미스 디스크에 매핑되고, 해당 볼륨을 마운트해 사용하므로 전체 데이터를 로컬에서 그대로 접근할 수 있습니다.
“백업되는 동안 모든 데이터에 대한 로컬 액세스 유지” 요구를 충족합니다.
2. 자동·안전한 AWS 백업
Storage Gateway가 주기적으로 온프레미스 볼륨의 스냅샷을 생성하고, 자동으로 AWS(S3에 EBS 스냅샷 형태)로 전송합니다.
전송은 HTTPS 등 암호화 채널로 이루어져 안전하게 백업됩니다.
“AWS에 백업된 데이터가 자동으로 안전하게 전송” 요구를 충족합니다.
3. 지속적인 백업 솔루션
수명이 다한 기존 볼륨 백업을 대체하는 지속적인 백업 구조로 사용할 수 있습니다.
4. C(캐시된 볼륨)와의 차이
캐시된 볼륨은 주 데이터가 S3에 있고, 자주 쓰는 부분만 로컬에 캐시됩니다.
“모든 데이터에 대한 로컬 액세스”를 보장하려면 저장된 볼륨(D) 이 적합합니다.
Answer: B
B. S3용 VPC 게이트웨이 엔드포인트
1. 인터넷 미경유
VPC 게이트웨이 엔드포인트를 S3용으로 만들면, VPC 라우팅 테이블에 S3 접두사 목록에 대한 경로가 엔드포인트로 설정됩니다.
EC2 → S3 요청은 VPC 내부 → AWS 백본으로만 전달되고, 인터넷 구간을 지나지 않습니다.
따라서 “트래픽이 인터넷을 통과하면 안 된다”는 요구사항을 정확히 충족합니다.
2. 구성
VPC에서 S3용 게이트웨이 엔드포인트 생성 → 해당 VPC/서브넷의 라우팅 테이블에 S3 접두사 목록을 엔드포인트로 연결.
EC2는 코드·설정 변경 없이 기존 S3 엔드포인트(예: s3.region.amazonaws.com)로 요청하면, 자동으로 VPC 엔드포인트 경로로 나갑니다.
3. 비용·운영
S3 게이트웨이 엔드포인트는 데이터 처리 비용 없음, NAT Gateway처럼 별도 NAT 비용도 없습니다.
Answer: B
요구사항
- 테라바이트 규모 고객 데이터를 AWS에 저장, PII 포함
- 3개 애플리케이션이 데이터 사용
- 1개: PII를 그대로 처리해야 함
- 2개: PII가 제거된 데이터만 처리해야 함
최소한의 운영 오버헤드로 위 조건 충족
B. S3 + S3 Object Lambda
1. 단일 데이터 소스
원본 데이터(PII 포함) 는 Amazon S3 버킷 한 곳에만 저장합니다.
복제·동기화할 저장소를 여러 개 둘 필요가 없어 운영이 단순합니다.
2. 요청 시 변환
S3 Object Lambda는 객체를 요청할 때 Lambda로 넘겨 변환한 결과를 반환합니다.
앱 1: PII가 필요한 경우 → Object Lambda 미사용 또는 “그대로 반환”하는 접근 경로(예: 일반 버킷/접근점)로 접근.
앱 2, 3: PII 제거가 필요한 경우 → Object Lambda 액세스 포인트로 접근하면, Lambda가 PII를 제거(마스킹/삭제) 한 뒤 반환합니다.
“다른 두 애플리케이션이 데이터를 처리하기 전에 PII를 제거” 요구를 접근 경로만 다르게 해서 충족합니다.
3. 운영 오버헤드 최소
저장소는 S3 한 버킷만 관리하고, 변환 로직은 Object Lambda용 Lambda 함수 하나만 작성·유지하면 됩니다.
3개 버킷/테이블·ETL·동기화 파이프라인을 만들 필요가 없어 “최소한의 운영 오버헤드”에 맞습니다.
4.데이터 중복 없음
원본은 S3 한 곳에만 두고, PII 제거 버전은 요청 시마다 Object Lambda로 생성하므로 저장 공간 중복이 없습니다.
Answer: D
1. VPC 피어링에서 CIDR 조건
피어링된 두 VPC의 CIDR는 겹치면 안 됩니다.
겹치면 피어링을 만들 수 없거나 라우팅 충돌이 납니다.
개발 VPC CIDR: 192.168.0.0/24
→ 사용 주소 범위: 192.168.0.0 ~ 192.168.0.255
따라서 새 VPC는 192.168.0.0/24와 겹치지 않는, 그리고 VPC로 허용되는 크기의 CIDR를 가져야 합니다.
A. 32는 호스트 1개(1 IP)만 의미합니다. AWS VPC의 CIDR는 /28 ~ /16만 허용되므로 /32는 VPC CIDR로 사용 불가 → 오답.
B. 개발 VPC와 동일한 대역이라 완전히 겹칩니다. 피어링 조건 위반 → 오답.
C. A와 같이 /32라 VPC CIDR로 불가. 겹침 여부와 관계없이 형식 자체가 잘못됨 → 오답.
D. 10.0.1.0 ~ 10.0.1.255로, 192.168.0.0/24와 겹치지 않고, /24는 VPC 허용 범위이며, 제시된 보기 중 유일하게 “유효한 새 VPC CIDR” → 정답
Answer: B
자동 확장: 수동 개입 없이 인스턴스 수가 자동으로 늘었다 줄었다 해야 함
비용 최적화: 평소 CPU 10% 미만일 때는 인스턴스를 줄여 비용 절감
급증 대응: CPU가 65%까지 올라갈 때는 인스턴스를 늘려 CPU 여유 확보
B. EC2 Auto Scaling 그룹 + 기존 ALB/대상 그룹 + 대상 추적 조정 정책(목표 CPU 50%), Min 2 / Desired 3 / Max 6
1. 대상 추적 조정 정책(Target Tracking)
목표: ASG 평균 CPU 50%
CPU가 50%보다 높으면(예: 65% 급증) → 인스턴스 추가
CPU가 50%보다 낮으면(예: 10% 미만) → 인스턴스 감소
→ “급증 시 CPU 확보” + “평소 비용 절감” 둘 다 만족합니다.
2. 완전 자동화
CloudWatch 메트릭만으로 자동 스케일 인/아웃. Lambda, SNS 알림 후 수동 조작 불필요.
3. 기존 아키텍처 활용
기존 ALB와 대상 그룹을 그대로 사용하고, 그 앞에 Auto Scaling 그룹을 두는 일반적인 패턴입니다.
Min 2 / Max 6
최소 2대로 가용성 유지, 최대 6대로 급증 시 상한을 두어 비용을 제어합니다.
Answer: C
현재: EC2와 RDS가 한 가용 영역(AZ) 에만 있어 운영 검토 미통과
목표: 두 번째 AZ를 사용해 애플리케이션 가용성 향상
즉, EC2와 DB 모두 AZ 장애에 대비한 고가용성이 필요합니다.
서브넷과 가용 영역
AWS에서 서브넷은 반드시 하나의 가용 영역에만 속합니다.
“두 가용 영역에 걸쳐 확장되는 서브넷”은 존재하지 않는 구성입니다.
따라서 “두 AZ에 걸치는 서브넷”을 전제로 한 B, D는 잘못된 설명입니다.
C. 각 가용 영역에서 서브넷 프로비저닝 두 AZ에 EC2 배포(ASG), RDS 다중 AZ 배포, 장애 시 자동 장애 조치(failover)
1. 각 가용 영역에서 서브넷 프로비저닝
AZ당 서브넷을 두는 것이 AWS의 올바른 모델입니다.
2. 두 AZ에 EC2 배포(ASG)
ALB가 두 AZ의 서브넷을 사용하고, ASG가 두 AZ에 인스턴스를 분산하면
한 AZ 장애 시에도 다른 AZ의 EC2가 트래픽을 처리할 수 있어 EC2 계층 가용성이 올라갑니다.
3. RDS 다중 AZ 배포
주 DB 인스턴스와 다른 AZ의 대기(standby) 복제본 유지
장애 시 자동 장애 조치(failover)
“두 번째 가용 영역을 사용”하고 “애플리케이션 가용성 향상” 요구사항을 DB 측에서 충족합니다.
A는 EC2는 두 AZ에 두지만, DB는 “각 네트워크에 대한 연결”만 언급해 RDS Multi-AZ 설정을 하지 않으므로 DB 고가용성이 보장되지 않습니다.
Answer: B
요구사항
HPC/분석용 고처리량·저지연 병렬 파일 시스템이 필요합니다.
1. FSx for Lustre + 영구 SSD
Lustre: HPC/ML용 병렬 파일 시스템으로, 수백~수천 EC2의 동시 접근에 맞게 설계됨.
영구 SSD: 저지연·고처리량 지속 워크로드에 적합 → 1ms 미만 지연, 6GB/s 이상 처리량 요구사항 충족.
2. S3 + Lustre S3 연동
원시 데이터는 S3에 두고, Lustre에서 S3 import/export로 고성능 계층만 사용하는 일반적인 패턴.
8TB 규모도 S3·Lustre 조합으로 처리 가능.
3. HDD(C)가 안 되는 이유
Lustre HDD(Scratch)는 비용 절감·버스트용이며, 지연이 SSD보다 큼 → “1ms 미만” 조건을 보장하기 어렵습니다.
4. ONTAP(A, D)가 안 되는 이유
NFS/SMB 공유, 범용 파일 스토리지용.
수백 대 EC2가 6GB/s를 낼 수준의 병렬 처리량과 극저지연은 Lustre SSD가 더 적합합니다.
Answer: C
요구사항
24/7 고정 워크로드이므로 예약 인스턴스(RI) 가 비용 효율적이고, DB는 스토리지가 자동으로 늘어나는 관리형 DB가 적합합니다.
1. 24/7 워크로드 → 예약 인스턴스
사용량이 예측 가능하고 지속적이므로 EC2 예약 인스턴스와 Aurora 예약 인스턴스로 온디맨드 대비 큰 할인을 받는 것이 가장 비용 효율적입니다.
애플리케이션 계층: EC2 예약
레거시 앱을 그대로 EC2에서 실행하면서, 24/7 기준으로는 예약이 온디맨드보다 저렴합니다.
2. DB 계층: Aurora 예약
“데이터베이스 스토리지가 시간이 지남에 따라 계속 증가” → Aurora는 스토리지를 자동으로 늘리므로 이 요구사항에 맞습니다.
Aurora 예약 인스턴스를 쓰면 DB 계층도 최대한 비용 절감할 수 있습니다.
3. A가 안 되는 이유
스팟: 중단 가능성이 있어 24/7 중요 비즈니스 앱에는 적합하지 않습니다.
S3: 객체 스토리지로, 레거시 앱의 관계형 DB 스토리지를 S3로 대체하는 구성은 일반적이지 않고, 문제에서 말하는 “데이터베이스 스토리지”와도 다릅니다.
4. B, D가 “가장 비용 효율”이 아닌 이유
B: DB를 온디맨드로 쓰면 예약보다 비용이 높습니다.
D: 앱 계층을 온디맨드로 쓰면 예약보다 비용이 높습니다.
→ 앱과 DB 모두 예약인 C가 가장 비용 효율적입니다
'자격증' 카테고리의 다른 글
| AWS SAA-C03 Dump 351-400 (0) | 2026.02.01 |
|---|---|
| AWS SAA-C03 Dump 301-350 (1) | 2026.02.01 |
| AWS SAA-C03 Dump 201-250 (0) | 2026.01.30 |
| AWS SAA-C03 Dump 151-200 (1) | 2026.01.30 |
| AWS SAA-C03 Dump 101-150 (0) | 2026.01.29 |
