모의고사 4

CloudFront는 읽기 캐시와 지연 시간 개선에는 유용하지만 다중 리전 쓰기나 객체 복제를 제공하지 않습니다. Global Accelerator도 S3 데이터에 대한 액티브-액티브 쓰기와 단일 S3 데이터 엔드포인트를 해결하지 못합니다. 주의: 라우팅 개선처럼 보이지만 핵심은 양방향 데이터 복제와 단일 S3 액세스 엔드포인트입니다.

단방향 CRR은 원본에서 새 버킷으로만 복제합니다. ap-southeast-2에서 쓴 객체가 us-east-1로 돌아가지 않아 두 리전 쓰기와 데이터 정합 요구 사항을 충족하지 못합니다. 주의: 읽기용 보조 복제에는 맞지만 액티브-액티브 데이터 액세스 요구에는 부족합니다.

S3 게이트웨이 엔드포인트는 VPC에서 S3로 가는 리전 내 프라이빗 경로를 제공할 뿐, 글로벌 엔드포인트나 다중 리전 쓰기, 데이터 복제를 제공하지 않습니다. Intelligent-Tiering은 비용 최적화 기능입니다. 주의: 프라이빗 연결과 스토리지 클래스 최적화는 이 문제의 리전 간 데이터 모델을 해결하지 못합니다.

Lambda 메모리를 늘리면 함수 실행 시간은 줄 수 있지만 데이터베이스 연결 한도나 연결 폭주를 직접 해결하지 못합니다. 각 쿼리 후 DB 연결을 닫으면 인증/TLS 설정 등 연결 생성/해제 반복이 늘어 Lambda와 RDS 사이 경로에서는 오히려 역효과가 날 수 있습니다. 500개 연결이 버스트 중 고갈되는 문제를 안정적으로 막지 못합니다. 주의: 겉보기에는 관련 AWS 서비스나 일부 증상을 다루는 것처럼 보이지만, 문제의 결정적인 제약을 해결하지 못합니다.

ElastiCache for Redis는 반복 읽기 결과를 캐시할 때 유용합니다. 그러나 이 워크로드는 등록을 위한 트랜잭션 읽기와 쓰기로 설명되어 있고, 증상은 거의 최대치에 도달한 DB 연결과 높은 CPU입니다. 캐시는 Lambda가 만드는 동시 DB 연결 수를 줄이지 못하며 쓰기 중심 또는 강한 일관성이 필요한 트랜잭션 경로에도 도움이 제한적입니다. 주의: 겉보기에는 관련 AWS 서비스나 일부 증상을 다루는 것처럼 보이지만, 문제의 결정적인 제약을 해결하지 못합니다.

Lambda 핸들러 외부에서 DB 클라이언트를 초기화하고 연결을 재사용하는 것은 좋은 Lambda 최적화지만, 하나의 웜 실행 환경 안에서만 효과가 있습니다. 동시성이 3,200까지 튀면 Lambda는 많은 병렬 환경을 만들고 각 환경이 하나 이상의 연결을 가질 수 있어 500개 RDS 연결 한도를 여전히 압도할 수 있습니다. 주의: 겉보기에는 관련 AWS 서비스나 일부 증상을 다루는 것처럼 보이지만, 문제의 결정적인 제약을 해결하지 못합니다.

Amazon FSx for Windows File Server는 SMB 파일 시스템과 DataSync 마이그레이션에는 적합하지만, 요구 사항은 공유 스토리지를 Amazon S3로 옮기는 것입니다. FSx는 S3를 주 백엔드로 사용하지 않으므로 핵심 저장 위치 요구 사항을 충족하지 못합니다. 주의: 그럴듯해 보이지만 문제의 결정적 제약을 충족하지 못합니다.

S3로 직접 복사하면 내구성과 비용 목표에는 도움이 되지만, 애플리케이션은 4개월 동안 네이티브 S3 API를 사용할 수 없고 SMB 액세스를 계속해야 합니다. S3 자체는 Windows 클라이언트용 SMB 엔드포인트를 제공하지 않습니다. 주의: 그럴듯해 보이지만 문제의 결정적 제약을 충족하지 못합니다.

AWS SMS로 파일 서버를 EC2로 옮기는 것은 S3 백엔드 SMB 인터페이스를 제공하는 방법이 아닙니다. 또한 AWS에서 파일 서버를 운영하게 되어 명시된 제약을 위반합니다. 주의: 그럴듯해 보이지만 문제의 결정적 제약을 충족하지 못합니다.

CloudFront 서비스 IP 범위 허용 목록에 의존하므로 문제에서 명시적으로 금지한 조건을 위반합니다. 또한 ALB를 프라이빗 서브넷으로 옮기면 CloudFront가 오리진에 도달하는 경로를 다시 설계해야 합니다. 주의: WAF와 CloudFront IP 범위가 그럴듯하지만, 요구 사항은 정적 IP 목록 없는 애플리케이션 계층 오리진 인증입니다.

Systems Manager Parameter Store는 임의 시크릿 문자열에 대해 Secrets Manager와 같은 자동 교체 기능을 제공하지 않습니다. ALB 리스너 규칙은 주로 라우팅용이며, 비밀 헤더 기반 차단을 위한 명시적 보안 강제에는 AWS WAF가 더 적합합니다. 주의: Parameter Store와 CloudFront 헤더가 보이지만, 자동 시크릿 교체와 강력한 오리진 차단 요구를 제대로 충족하지 못합니다.

Shield Advanced는 DDoS 보호와 가시성을 제공하지만 오리진 인증을 해결하지 않습니다. 또한 CloudFront IP 범위를 네트워크 계층에서 허용하는 방식이므로 정적 IP 허용 목록 금지 조건을 위반합니다. 주의: Shield Advanced가 보안 서비스라서 그럴듯하지만, 필요한 것은 WAF 헤더 일치 같은 애플리케이션 계층 검증입니다.

File Gateway와 NFS 접근은 맞지만 S3 Standard-IA는 밀리초 검색용 계층이라, 72시간 복구가 허용되는 장기 백업에는 Deep Archive보다 비용이 높습니다. 주의: 그럴듯하지만 시나리오의 결정적 제약을 충족하지 못합니다.

Volume Gateway는 iSCSI 블록 볼륨을 제공하므로 NFS 파일 공유 접근을 유지한다는 요구 사항을 충족하지 못합니다. 주의: 그럴듯하지만 시나리오의 결정적 제약을 충족하지 못합니다.

Tape Gateway는 VTL 기반 백업 소프트웨어 통합용이며 NFSv3 파일 접근을 유지하지 않습니다. 또한 Standard-IA는 장기 아카이브 비용 최적화에 적합하지 않습니다. 주의: 그럴듯하지만 시나리오의 결정적 제약을 충족하지 못합니다.

Redshift Spectrum은 S3를 쿼리할 수 있지만 일반적으로 Redshift 웨어하우스나 Redshift Serverless 계층을 추가합니다. 5시간짜리 평일 창과 6명 사용자에는 Athena보다 비용과 관리 부담이 큽니다. 주의: S3를 사용하지만 이 워크로드에 필요 없는 웨어하우스 패턴을 더합니다.

S3의 EMRFS는 저장소와 컴퓨팅을 분리하지만 Presto on EMR은 여전히 클러스터 프로비저닝, 확장, 패치, 시작/중지 조율이 필요합니다. 주의: HDFS 의존성은 줄이지만 EMR 컴퓨팅 운영 모델은 남아 있습니다.

Redshift는 지속적인 웨어하우스 운영과 적재 모델이 필요해 간헐적 Parquet 쿼리에는 Athena보다 비용과 운영 부담이 큽니다. 주의: SQL 분석 플랫폼이지만 짧고 낮은 동시성의 쿼리 창에는 과합니다.

Network Load Balancer는 L4 서비스를 노출할 수 있지만 투명한 inline inspection/service insertion 용도가 아닙니다. Route table이 검사 다음 홉으로 트래픽을 보내는 GWLB/GWLBe 모델을 제공하지 않습니다. 주의: 익숙한 로드 밸런싱 또는 배포 도구처럼 보이지만 투명한 GWLB/GWLBe service insertion 모델을 놓칩니다.

Launch Wizard는 초기 배포를 도울 수 있지만 여러 계정에 걸친 투명한 inline inspection 아키텍처를 자체적으로 제공하지 않습니다. 핵심은 GWLB/GWLBe 기반 트래픽 조향과 자동 확장입니다. 주의: 익숙한 로드 밸런싱 또는 배포 도구처럼 보이지만 투명한 GWLB/GWLBe service insertion 모델을 놓칩니다.

GWLB 엔드포인트 서비스를 소비하는 엔드포인트는 중앙 보안 VPC가 아니라 소비자 VPC인 멤버 계정에 생성해야 합니다. 보안 계정에 만든 VPC 엔드포인트는 멤버 VPC 라우팅 테이블의 로컬 대상이 될 수 없습니다. 주의: 익숙한 로드 밸런싱 또는 배포 도구처럼 보이지만 투명한 GWLB/GWLBe service insertion 모델을 놓칩니다.

애플리케이션 이중 쓰기와 새로운 Route 53 URL은 코드 변경 없음 요구 사항을 위반하며, 가중치 기반 라우팅은 트래픽 분산일 뿐 결정적 읽기 장애 조치가 아닙니다. 주의: 두 버킷을 사용하지만 장애 조치와 일관성을 애플리케이션 경로로 밀어 넣습니다.

CloudFront 오리진 장애 조치는 유용하지만 Lambda 복사는 높은 요청량의 객체 워크로드에서 재시도, 확장, 순서, 실패 처리를 직접 구현해야 하는 사용자 지정 복제입니다. 주의: 이벤트 기반 복사는 유연해 보일 수 있지만 S3 CRR보다 운영 부담이 크고 AWS 기본 기능이 아닙니다.

CRR은 복제를 해결하지만, 장애 중 애플리케이션을 수동으로 업데이트하는 방식은 자동 장애 조치와 애플리케이션 변경 없음 요구 사항을 충족하지 못합니다. 주의: 데이터 복사 측면만 해결합니다.

PrivateLink 엔드포인트 서비스는 리전 간 기존 NLB를 직접 엔드포인트 서비스로 사용할 수 없습니다. eu-central-1에서 소비자가 연결하려면 그 리전의 NLB가 필요합니다. 주의: 서비스 이름은 그럴듯하지만 지문의 결정적인 제약 조건을 충족하지 못합니다.

ALB target group은 같은 VPC/리전 경계와 대상 유형 제약 때문에 이 문제의 교차 리전 원격 EC2 대상을 해결하는 올바른 방식이 아닙니다. 불필요한 ALB도 추가됩니다. 주의: 서비스 이름은 그럴듯하지만 지문의 결정적인 제약 조건을 충족하지 못합니다.

AWS RAM으로 EC2 인스턴스를 다른 리전에 공유해 instance target group에 등록하는 모델은 지원되는 접근 방식이 아닙니다. PrivateLink 노출에는 NLB와 적절한 target group이 필요합니다. 주의: 서비스 이름은 그럴듯하지만 지문의 결정적인 제약 조건을 충족하지 못합니다.