모의고사 3

DataSync와 S3 Transfer Acceleration은 데이터를 이동하는 데 도움이 되지만, S3FS가 S3를 HPC 워크로드용 네이티브 POSIX 병렬 파일 시스템으로 만들어 주지는 않습니다. 주의: S3와 가속이 언급되어 그럴듯하지만, 요구 사항은 전송 최적화가 아니라 마운트되는 병렬 파일 시스템입니다.

Volume Gateway는 하이브리드 스토리지 패턴을 위한 iSCSI 블록 볼륨을 제공하며, 다수의 HPC 클라이언트를 위한 공유 POSIX 병렬 파일 시스템을 제공하지 않습니다. 주의: 고성능 병렬 액세스라는 표현이 유혹적이지만, iSCSI 볼륨은 Lustre 방식의 공유 병렬 스토리지가 아닙니다.

EFS는 NFS 기반의 관리형 POSIX 호환 파일 시스템이지만, Lustre 클라이언트와 극저지연 병렬 I/O에 최적화된 HPC 병렬 파일 시스템은 아닙니다. 주의: Max I/O는 EFS 확장성을 높이지만, 문제는 병렬 파일 시스템 클라이언트와 HPC 성능을 요구합니다.

gp2는 IOPS를 독립적으로 설정할 수 없습니다. 12,000 기준 IOPS에 도달하려면 매우 큰 볼륨이 필요하고 용량 낭비가 생길 가능성이 큽니다. 주의: 범용이라는 이름은 맞아 보이지만, gp2는 성능이 크기에 묶이는 이전 모델입니다.

io2는 IOPS 요구 사항을 충족하고 성능을 분리할 수 있지만, 더 높은 수준의 프로비저닝 IOPS 워크로드용이므로 여기서 가장 비용 효율적인 답은 아닙니다. 주의: 높은 IOPS 숫자가 io2를 떠올리게 하지만, 시나리오는 비용 최적화를 강조합니다.

io1도 IOPS를 독립적으로 프로비저닝할 수 있지만, 이 유형의 비용 최적화 트랜스코딩 스토리지에는 보통 gp3보다 비쌉니다. 주의: 튜닝 요구 사항은 충족하지만, 가장 비용 효율적이라는 요구 사항을 놓칩니다.

EFS의 저장 시/전송 중 암호화와 보안 그룹은 네트워크 가로채기와 저장 매체 노출을 막는 데 도움이 됩니다. 그러나 파일 시스템을 마운트하거나 접근 권한이 있는 인스턴스를 관리할 수 있는 권한 있는 사용자가 평문 파일을 읽는 것을 막지는 못합니다. 주의: EFS 암호화와 보안 그룹은 강한 보호처럼 보이지만, 이 문제는 권한 있는 데이터베이스 또는 시스템 운영자에게도 평문을 숨기는지를 묻고 있습니다.

DynamoDB의 SSE-KMS는 저장 시 데이터를 암호화하지만, 권한 있는 읽기 요청에는 DynamoDB가 데이터를 복호화해 반환합니다. 따라서 테이블이나 읽기 권한을 가진 역할이 평문을 가져올 수 있으므로 관리자/운영자에게도 기밀을 유지해야 한다는 요구 사항을 일반적으로 충족하지 못합니다. 주의: 고객 관리형 키를 사용하는 서버 측 암호화는 관련 있어 보이지만, 핵심은 권한 있는 접근에서도 평문을 노출하지 않는 클라이언트 측 암호화입니다.

FSx for Lustre는 HPC, ML, 미디어 처리 같은 고성능 파일 시스템 워크로드에 적합하며 환자 기록과 처방 데이터를 저장하고 질의하는 일반적인 선택지가 아닙니다. 암호화와 AD 통합은 저장 시 보호와 인증을 다루지만, 파일 시스템 접근 권한을 가진 권한 있는 관리자가 평문을 읽는 것을 본질적으로 막지는 못합니다. 주의: 암호화와 Active Directory 통합이 보안 요구 사항처럼 보이지만, 이 문제는 권한 있는 운영자에게도 민감 필드를 숨기는 설계를 묻고 있습니다.

S3와 Athena는 분석 스캔에 적합하며, 애플리케이션에서 낮은 지연 시간으로 다중 홉 관계를 순회하는 용도가 아닙니다. 주의: Athena는 대규모 데이터를 쿼리할 수 있지만, 그래프 데이터에 반복 self-join을 수행하면 느리고 스캔 비용이 큽니다.

MySQL도 연결을 모델링할 수 있지만, 수백만 개의 프로필과 엣지에서 깊이가 늘어날수록 재귀 조인은 복잡하고 느려집니다. 주의: 관계형 테이블에 데이터를 저장할 수는 있지만, 그래프 순회 전용으로 설계된 것은 아닙니다.

DynamoDB는 각 홉마다 애플리케이션 측 반복 쿼리가 필요하며, 임의의 그래프 경로를 네이티브로 최적화하지 않습니다. 주의: 키-값 액세스는 확장성이 뛰어나지만, 이 쿼리 패턴은 관계 순회입니다.

Route 53 지리적 위치 라우팅은 DNS 기반이며 리졸버와 TTL의 영향을 받으므로 밀리초 수준의 라우팅 변경이나 빠른 장애 조치를 보장할 수 없습니다. ALB는 계층 7 HTTP/HTTPS/gRPC용이며 UDP를 지원하지 않습니다. Lambda도 특수 Linux의 C++ 엔진과 지속적인 초저지연 UDP 거래 워크로드에 맞지 않습니다. 주의: 지리적 위치 DNS와 Lambda는 글로벌 관리형처럼 보이지만 UDP와 사용자 지정 OS 지연 시간 요구를 충족하지 못합니다.

CloudFront는 HTTP(S) 콘텐츠 전송용이며 사용자 지정 거래 프로토콜의 범용 UDP 진입점으로 동작하지 않습니다. NLB는 UDP를 지원하지만 CloudFront가 임의 UDP를 NLB 오리진으로 기본 전달할 수는 없습니다. Fargate도 OS/커널 사용자 지정이 제한됩니다. 주의: NLB가 포함되어 있지만 CloudFront와 Fargate는 임의 UDP 및 특수 Linux에 맞지 않습니다.

API Gateway 리전 엔드포인트와 ALB는 HTTP 중심 서비스이며 UDP 트래픽을 지원하지 않습니다. 백엔드가 ECS에서 실행되더라도 프런트 도어가 프로토콜 요구 사항을 충족하지 못합니다. API Gateway는 추가 요청 처리 오버헤드도 발생시킵니다. 주의: API Gateway/ECS는 확장 가능해 보이지만 API Gateway와 ALB는 HTTP 지향이며 UDP와 정적 anycast 요구 사항을 놓칩니다.

Amazon MQ와 Multi-AZ 애플리케이션 계층은 좋지만, MySQL을 EC2 Auto Scaling에 두는 것은 데이터베이스 복제나 장애 조치를 제공하지 않습니다. 주의: Auto Scaling은 고가용성처럼 들리지만, 상태 저장 데이터베이스의 일관성을 보장하지 않습니다.

MySQL에 RDS Multi-AZ를 쓰는 것은 맞지만, RabbitMQ를 EC2에서 직접 관리하면 브로커 운영 오버헤드가 여전히 높습니다. 주의: Multi-AZ EC2 용량은 도움이 되지만 RabbitMQ 클러스터링과 장애 조치 관리는 여전히 필요합니다.

RabbitMQ와 MySQL을 모두 자체 관리 상태 저장 EC2 시스템으로 남기므로, 최소 운영 오버헤드 요구 사항과 맞지 않습니다. 주의: Auto Scaling group을 더 만든다고 관리형 복제와 장애 조치를 대체할 수는 없습니다.

Lambda 필터링은 API Gateway와 Lambda가 이미 호출된 뒤에 실행되므로 공격 트래픽이 여전히 비용을 유발하고 동시성을 소진할 수 있습니다. 주의: 논리적으로 요청을 거부할 수는 있지만 요청 경로에서 너무 늦습니다.

프라이빗 API Gateway 엔드포인트와 VPC 피어링은 통신사 네트워크 전반에 퍼져 있는 공개 모바일 사용자에게 실용적이지 않습니다. 주의: 프라이빗 네트워킹은 안전해 보이지만 정상 모바일 접근을 깨뜨립니다.

사용자별 IAM role assumption은 운영 부담이 크고 대량 봇 트래픽을 직접 막지 못합니다. 모바일 API는 일반적으로 앱/사용자 인증과 API 계층 보호를 사용합니다. 주의: 임시 자격 증명은 안전하게 들리지만, 공개 모바일 API의 남용 방지 제어로는 맞지 않습니다.

ElastiCache는 읽기에는 유용하지만, 일관되게 시스템 오브 레코드에 기록되어야 하는 내구성 있는 구매 쓰기에는 적합하지 않습니다. 주의: 캐싱은 비용 효율적으로 들리지만, 구매 쓰기를 캐시 항목처럼 안전하게 취급할 수는 없습니다.

끝없는 Lambda 재시도는 부하와 비용을 증폭시키고 데이터베이스 포화 상황을 악화시킬 수 있습니다. 주의: 재시도는 복원력 있어 보이지만, 피크 부하에서 무제한 재시도는 안티패턴입니다.

API Gateway 사용량 계획은 클라이언트를 제한할 수 있지만, 모든 유효한 구매 수요를 처리하거나 부하 평준화로 Aurora를 보호하지는 않습니다. 주의: 스로틀링은 압박을 낮추지만, 비즈니스에 중요한 플래시 세일 거래를 거부할 수 있습니다.

단일 AZ Elastic Beanstalk 환경은 여전히 AZ 수준 위험이 있으며 데이터베이스 계층을 분리하거나 강화하지 못합니다. 주의: Beanstalk는 관리형이지만 단일 AZ와 세션 고정 설계는 복원력 목표를 충족하지 못합니다.

S3와 CloudFront는 좋지만, RDS read replica는 기본 데이터베이스의 RDS Multi-AZ 자동 장애 조치와 동일하지 않습니다. 주의: 서버리스 API는 현대적으로 보이지만 데이터베이스 HA 요구 사항이 완전히 충족되지 않습니다.

여러 AZ의 EC2와 로드 밸런서는 컴퓨팅 가용성을 개선하지만, 정적 콘텐츠를 EC2에 남겨 두고 관리형 장애 조치가 아닌 백업만 있는 RDS 인스턴스를 사용합니다. 주의: 점진적인 단순 마이그레이션처럼 보이지만 운영 부담과 데이터베이스 위험이 너무 많이 남습니다.