AWS Certified Solutions Architect - Professional (SAP-C02)

CloudFront는 캐시를 통해 읽기 지연 시간을 줄일 수 있지만, multi-Region 쓰기 솔루션이 아니며 Region 간 object를 replication하지도 않습니다. Global Accelerator는 regional endpoint로의 라우팅을 개선하지만, S3는 GA로 프런트하여 active-active 쓰기와 단일 S3 데이터 endpoint를 제공하는 방식으로 사용되지 않습니다. 또한 이 옵션은 단일 bucket을 유지하므로 ap-southeast-2의 쓰기는 여전히 us-east-1로 이동해야 하여 지연 시간이 증가합니다.

단방향 CRR은 원본 bucket에서 새 bucket으로만 replication합니다. ap-southeast-2의 애플리케이션이 로컬 bucket에 쓰면 해당 object는 us-east-1로 다시 replication되지 않아, 두 Region에서의 쓰기를 지원하면서 데이터셋을 정렬 상태로 유지해야 한다는 요구 사항을 위반합니다. 또한 단일 글로벌 액세스 endpoint가 없으므로 애플리케이션에 Region별 bucket 로직이 필요합니다.

S3 gateway endpoint는 VPC에서 해당 Region 내 S3로의 private connectivity를 제공할 뿐입니다. 글로벌 endpoint를 만들지 않으며, multi-Region 쓰기를 활성화하지도 않고, 데이터를 replication하지도 않습니다. S3 Intelligent-Tiering은 비용 및 액세스 패턴을 위한 storage class 최적화로, cross-Region 지연 시간 감소나 active-active multi-Region 데이터 액세스와는 무관합니다.

오답입니다. Standard Reserved Instances는 EC2에만 적용되며, 특정 instance 속성에 묶이기 때문에 Savings Plans보다 훨씬 더 경직적이고 Lambda나 Fargate 사용량에는 도움이 되지 않습니다. 추가된 Compute Savings Plan이 serverless 서비스를 커버하긴 하지만, 이 답변은 최신의 혼합 compute 환경에 대해 더 확장 가능한 organization-wide Savings Plans 전략을 사용하기보다 기존 RI 구매 방식과 혼합하고 있습니다. 따라서 현대적인 multi-account, multi-service compute 포트폴리오 전반에서 절감을 극대화하기 위한 최적의 전체 구매 모델은 아닙니다.

오답입니다. 1-year 기간과 No Upfront 결제는 3-year commitment보다 할인 폭이 작으며, 이는 문제에서 제시한 36개월의 안정적인 사용 패턴과 맞지 않습니다. 또한 각 member account에서 별도로 구매하면 commitment가 분산되어 organization 전체에서의 discount sharing 효과가 줄어들 수 있습니다. 추가로, 이 옵션은 Compute Savings Plans만 사용하므로, 대규모의 안정적인 EC2 사용량에 대해 더 높은 할인을 제공할 수 있는 EC2 전용 plan을 활용할 기회를 놓칩니다.

오답입니다. 각 member account에서 구매하는 것은 management account에서 중앙 구매하는 것보다 비효율적입니다. account 간 사용량이 이동할 경우 commitment가 활용되지 못할 수 있기 때문입니다. 또한 EC2 Instance Savings Plans는 Lambda나 Fargate를 커버하지 않으므로, 이 옵션은 새로운 serverless pipeline을 전혀 다루지 못합니다. 3-year All Upfront 기간을 사용하긴 하지만, 회사의 전체 compute 사용량을 완전히 포괄하지 못하므로 전체적으로 가장 큰 절감을 제공할 수 없습니다.

Max I/O performance mode는 부하를 분산하여 고도로 병렬적인 접근에서 확장성을 개선할 수 있지만, 20,000개의 동시 1080p 스트림에 필요한 막대한 지속 처리량을 자동으로 제공하지는 못합니다. 여전히 EFS throughput 제한(bursting credits 또는 provisioned throughput)을 해결해야 하며 비용이 크게 증가할 수 있습니다. 이는 부분적 완화책일 뿐, 가장 비용 효율적이고 확장 가능한 해결책은 아닙니다.

instance store를 비디오에 사용하는 것은 운영적으로 복잡하고 취약합니다. instance store는 ephemeral이며 큰 로컬 용량이 필요하고, 종료 시 S3로 200 MB 자산을 동기화하는 것은 scaling 이벤트 및 termination 상황에서 신뢰하기 어렵습니다. 또한 fleet 전체에 콘텐츠를 중복 저장하여 스토리지를 낭비하고, 전 세계적으로 낮은 지연 시간 전송을 제공하지 못합니다. 이는 비디오 라이브러리에 대한 표준적이고 비용 효율적인 패턴이 아닙니다.

ALB 앞단의 CloudFront는 동적 콘텐츠를 가속하고 일부 정적 응답을 캐시할 수 있지만, 비디오를 EFS에 유지하면 origin 병목이 그대로 남습니다. 비디오 전송은 종종 range requests에 의존하며 캐시 단편화 또는 miss를 유발할 수 있습니다. CloudFront가 origin에서 가져와야 할 때 EFS의 throughput/latency 제약이 여전히 느린 응답과 타임아웃을 초래합니다. 이는 S3를 origin으로 사용하는 것보다 효과가 떨어지고 잠재적으로 더 비쌀 수 있습니다.

desired 28로 용량을 추가하고 20개에 대해 Reserved Instances를 사용하므로 성능은 개선되지만, 가장 비용 효율적이지는 않습니다. 워크로드의 평균 CPU가 10%에 불과하므로 baseline에 20개 인스턴스는 크게 과다 프로비저닝되어 있습니다. 3년 동안 20개를 예약하면 불필요한 지출이 고정됩니다. 또한 desired capacity를 28로 설정하는 것은 진정한 탄력성이 아니며, scaling policies가 이를 낮추지 않는 한 spike 시간 외에도 추가 인스턴스가 계속 실행됩니다.

DefaultTargetCapacityType을 On-Demand로 설정한 Spot Fleet은 사실상 대부분 On-Demand capacity를 프로비저닝하므로, Auto Scaling에서 On-Demand를 사용하는 것 대비 비용을 크게 줄이지 못합니다. 또한 Spot Fleet은 EC2 Auto Scaling mixed instances policies에 비해 legacy 접근 방식입니다. 그리고 baseline을 적정 규모로 맞추지 못하며 TotalTargetCapacity를 20으로 지속 유지하므로 평균 CPU 10% 기준으로 여전히 과다 프로비저닝입니다.

maintain request로 주로 Spot capacity(DefaultTargetCapacityType=Spot)에 의존하므로 비용은 줄일 수 있지만, 중요한 시장 개장 시간 spike 동안 interruption 및 capacity-availability risk를 도입합니다. 문제는 컴플라이언스 프로그램을 위해 spike 동안 지연 시간 해결을 강조하며, 명시적인 interruption tolerance와 On-Demand fallback 없이 Spot은 위험합니다. 또한 이미 NLB 뒤에서 실행되는 stateless API에 대해 NLB를 ALB로 교체하는 것은 불필요하며 명확한 이점 없이 변경만 추가합니다.

오답입니다. 모든 초기화를 핸들러로 옮기면 일반적으로 호출당 지연이 증가하고, 실행 환경당 한 번만 무거운 작업을 수행하는 이점을 무너뜨립니다. 또한 SnapStart는 $LATEST에서 구성할 수 없고 published version이 필요합니다. 이 선택지는 SnapStart를 잘못 사용하며 성능 특성도 악화시킵니다.

명시된 비용 목표에 비추어 오답입니다. alias에 Provisioned Concurrency를 설정하면 cold start를 줄이고 burst를 처리할 수 있지만, 트래픽이 0일 때도 provisioned capacity에 대한 지속 비용이 발생합니다. 문제는 항상 켜져 있는 용량 비용 없이 시작 지연을 최소화하라고 명시하므로, spiky workload에는 비용 효율성이 떨어집니다.

오답/덜 적절합니다. SnapStart는 published version에서 활성화해야 하며 Provisioned Concurrency와 함께 사용할 수도 있지만, Provisioned Concurrency를 추가하면 항상 켜짐 비용이 다시 발생합니다. 또한 고유 ID/암호화 seed를 snapshotting하는 정확성 위험을 해결하지 못합니다. 해당 로직을 snapshot 밖으로 옮기지 않으면 중복되거나 안전하지 않은 상태가 발생할 수 있습니다.

Lambda memory를 늘리면 function 실행 시간이 줄어들 수 있지만, 데이터베이스 connection limit 또는 connection storm을 직접 해결하지는 못합니다. 각 쿼리 후 DB connection을 명시적으로 닫는 것은 일반적으로 Lambda-to-RDS에서 역효과가 나는데, connection churn(auth/TLS 설정)을 증가시키고 DB CPU를 높일 수 있기 때문입니다. 이 옵션은 동시 지속 시간을 약간 줄일 수는 있지만, 버스트 동안 500 connections 소진을 안정적으로 방지하지는 못합니다.

Amazon ElastiCache for Redis는 반복되는 read 쿼리가 지배적이고 결과를 캐시할 수 있을 때(예: course catalog browsing) 유용합니다. 그러나 workload는 등록(enrollment)을 위한 트랜잭션 읽기 및 쓰기로 설명되어 있으며, 증상에는 DB connections가 거의 최대치이고 CPU가 높은 것이 포함됩니다. caching은 Lambda가 생성하는 동시 DB connections 수를 줄이지 못하며, write-heavy 또는 강한 일관성이 필요한 트랜잭션 경로에는 도움이 되지 않습니다.

handler 외부에서 DB client를 초기화하고 connections를 재사용하는 것은 좋은 Lambda 최적화이지만, 단일 warm execution environment 내에서만 도움이 됩니다. concurrency가 3,200으로 급증하면 Lambda는 많은 병렬 환경을 생성하며, 각 환경이 하나 이상의 connection을 보유할 수 있어 500-connection RDS 한도를 여전히 압도합니다. 이는 부분적인 완화책일 뿐, 버스트 조건에서 RDS Proxy에 비해 견고한 해결책이 아닙니다.

ASG + ALB는 EC2 용량을 추가할 수 있지만, 컨테이너 오케스트레이션에 대한 운영 부담(여전히 호스트, 배포, bin packing 관리)을 줄이지 못하고, Kafka 기반 아키텍처를 Kinesis로 전환하면(애플리케이션 변경 및 재설계 필요) 자체 관리형 Kafka 문제를 ‘해결’하는 방식이 아닙니다. read replica와 S3 오프로딩은 도움이 되지만, Kafka와 컨테이너 관리가 여전히 무거워 “운영 부담 최소화” 관점에서 최선의 답은 아닙니다.

Multi-AZ와 storage autoscaling은 데이터베이스 가용성과 스토리지 관리를 개선하지만, 사전판매 급증에 대한 read 처리량을 실질적으로 늘리지는 않습니다. 옵션 A와 마찬가지로 Kafka에서 Kinesis로의 전환을 제안하는데, 이는 기존 Kafka 기반 아키텍처에서 운영 부담이 낮고 변경이 적은 스왑이 아닙니다. 또한 컴퓨팅을 EC2 ASG에 유지하므로 컨테이너와 스케일링 동작에 대해 여전히 상당한 운영 작업이 필요합니다.

EC2에서 직접 Kubernetes 클러스터를 만드는 것은 managed EKS/Fargate에 비해 운영 오버헤드(control plane/worker 관리, 업그레이드, 스케일링, 보안 하드닝)를 증가시킵니다. MSK와 CloudFront는 좋은 선택이지만, 컴퓨팅 계층이 ‘다음 주 이벤트 전에 빠르게 운영 부담을 최소화’ 요구사항과 충돌합니다. 이 옵션은 스트리밍과 CDN은 현대화하지만, 컨테이너 운영을 현재 구성보다 더 복잡하게 만듭니다.

Amazon FSx for Windows File Server는 애플리케이션이 SMB를 통해 액세스할 수 있는 관리형 SMB 파일 시스템을 제공하며, AWS DataSync는 데이터를 그 안으로 마이그레이션할 수 있습니다. 그러나 요구 사항은 특히 중간 기간 동안 내구성과 비용 효율성을 위해 공유 스토리지를 Amazon S3로 이동하는 것입니다. FSx for Windows는 S3를 기본 스토리지 백엔드로 사용하는 대신 FSx 파일 시스템에 데이터를 저장하므로, 핵심 스토리지 위치 요구 사항을 충족하지 않습니다. 또한 설계 목표가 S3를 내구성 있는 백엔드로 사용하면서 SMB 액세스는 온프레미스에 유지하는 것인데, AWS에서 호스팅되는 파일 시스템 서비스를 추가로 도입하게 됩니다.

on-premises SMB 리포지토리에서 Amazon S3 bucket으로 데이터를 직접 복사하면 내구성/비용 목표는 충족할 수 있지만, 액세스 요구 사항은 충족하지 못합니다. 애플리케이션은 4개월 동안 native S3 API를 사용할 수 없고 최소한의 변경으로 SMB를 통해 데이터셋에 계속 액세스해야 합니다. S3는 object store이며, 중간 서비스 없이 Windows 클라이언트를 위한 SMB endpoint를 제공하지 않습니다.

AWS Server Migration Service(과거 서비스)는 서버 워크로드 마이그레이션을 위한 것이지 S3를 백엔드로 하는 SMB 인터페이스를 제공하기 위한 것이 아닙니다. file server를 EC2로 lift-and-shift하더라도 AWS에서 file server를 운영하는 것이 되어 요구 사항이 금지합니다. 또한 운영 부담(패치, 스케일링, HA)을 추가하며, 데이터셋을 S3에 primary repository로 저장한다는 목표를 본질적으로 달성하지도 못합니다.

오답. account access keys(특히 root 또는 광범위한 권한의 keys)를 공유하는 것은 가장 secure하지 않은 접근 중 하나입니다. long-term credentials를 사용하며, 안전한 auditing 및 rotation이 어렵고 AWS best practices를 위반합니다. 또한 account-level keys는 일반적으로 광범위한 access를 의미하므로 least privilege를 깨고, compromise 시 blast radius가 매우 큽니다.

오답. IAM user를 생성하고 long-term access keys를 공유하는 것은 third-party access에 대해 명시적으로 권장되지 않습니다. permissions를 제한하더라도 long-term credentials는 노출(유출, 재사용, 저장 위험)을 증가시키며 지속적인 rotation과 안전한 배포가 필요합니다. 이는 temporary credentials 사용 요구사항을 충족하지 못하며 가장 secure한 패턴이 아닙니다.

부분적으로 맞지만 MOST secure는 아님. IAM role과 STS AssumeRole을 사용하면 temporary credentials를 제공하고 least privilege를 지원하므로 좋습니다. 그러나 독립적인 third-party access에서는 ExternalId를 생략하면 고객이 confused deputy 시나리오에 더 노출됩니다. ExternalId(및 선택적 추가 조건)를 추가하는 것이 더 강력하고 권장되는 control입니다.

management account의 trail이 S3 bucket에 기록하더라도, 반드시 organization trail인 것은 아닙니다. organization-level trail을 활성화하지 않으면 CloudTrail은 모든 멤버 account의 이벤트를 자동으로 캡처하지 않습니다. multi-Region 및 S3 encryption/MFA Delete를 사용하더라도, 최소 운영으로 모든 현재 및 향후 account 전반의 모든 API call을 기록해야 한다는 요구 사항을 충족하지 못합니다.

각 멤버 account에 trail과 bucket을 생성하면 account별 API 활동을 캡처할 수 있고 모든 Region에 대해 encryption과 MFA Delete로 구성할 수 있습니다. 그러나 운영 오버헤드가 매우 큽니다(30+ account, 매월 새 account, 다수 Region) 그리고 구성 드리프트 가능성이 증가합니다. 이는 지속적인 운영 노력을 최소화해야 한다는 요구 사항에 반합니다.

SNS 알림을 외부 관리 시스템으로 추가하면 추가 통합과 운영 부담이 생기며, 핵심 로깅 및 보관 요구 사항을 충족하는 데 필요하지 않습니다. 또한 management account의 trail만으로는 organization trail로 구성하지 않는 한 모든 멤버 account 커버리지를 보장하지 못합니다. 이 옵션은 불완전하며 필요 이상으로 운영 부담이 큽니다.

ElastiCache for Redis는 DB 부하를 줄일 수 있지만 운영 복잡성(VPC 설계, 노드 sizing, scaling, patching, monitoring)을 증가시키고, Lambda 코드 변경과 cache invalidation/TTL 전략이 필요합니다. 30–90초 내의 동일 GET 요청 패턴에는 API Gateway caching이 훨씬 적은 노력과 더 적은 구성 요소로 유사한 이점을 제공하므로, 여기서는 Redis가 불필요합니다.

Aurora Serverless v2 maximum capacity를 높이면 스파이크를 처리하기 위해 더 많은 compute와 memory를 허용할 수 있지만, 피크 스케일링 동안 비용이 증가하고 중복 읽기를 제거하지는 못합니다. 트래픽 패턴은 회피 가능한 반복 쿼리를 시사하므로, 캐싱이 더 비용 효율적인 1차 조치입니다. DB 스케일링은 일반적으로 요청 패턴 최적화와 캐싱 계층 추가 이후에 사용됩니다.

API Gateway throttling(rate/burst limits)은 다운스트림 시스템을 과부하로부터 보호하지만, 요청을 거부하거나 지연(429 응답)시키는 방식이므로 모바일 앱 경험을 해치며 추가 사용량 지원 요구 사항을 충족하지 못합니다. Throttling은 안전장치로는 적절하지만, 합법적인 수요 증가와 반복 읽기 트래픽을 처리하기 위한 1차 전략은 아닙니다.

오답. 아티팩트가 S3에 저장되므로 보안 요구 사항을 위반합니다(승인된 레지스트리가 아님). 또한 Lambda layers는 ZIP archives이며, S3에 저장된 Docker image로부터 생성되지 않습니다. 여러 ZIP 기반 함수에 layer를 연결하는 것은 일반적인 재사용 패턴이지만, 명시된 프로덕션 제약과 충돌하고 layers가 빌드/게시되는 방식에 대한 설명도 부정확합니다.

오답. ECR이 승인된 레지스트리이긴 하지만, Lambda layers는 ECR container image로부터 직접 생성되지 않습니다. layers는 ZIP archives로 게시됩니다(Lambda에 업로드). 일반적인 배포 워크플로는 종종 S3를 스테이징 위치로 사용합니다. 이 옵션의 전제(layer-from-ECR-image)는 지원되는 Lambda 기능이 아니므로, 거버넌스 친화적으로 들리더라도 유효하지 않은 접근입니다.

오답. ECS/Fargate는 장기 실행 container를 실행하지만, Lambda는 “실행 중인 container”를 Lambda layer로 참조할 수 없습니다. layers는 init 시점에 Lambda 실행 환경에 마운트되는 정적 의존성 번들입니다. ECS를 사용하는 것은 불필요한 운영 오버헤드(서비스 관리, scaling, networking)를 추가하며, Lambda runtimes에 대한 패키징/재사용 요구 사항도 해결하지 못합니다.

각 AWS account에 Client VPN endpoint를 생성하면 액세스를 제공할 수는 있지만, 여기서는 최적의 아키텍처가 아닙니다. 여러 endpoint, 중복된 구성, 더 높은 운영 오버헤드를 초래하기 때문입니다. 또한 사용자가 필요에 따라 서로 다른 endpoint에 연결하지 않는 한, 단일 사용자 연결로 6개의 모든 VPC에 대한 중앙 집중식 액세스를 본질적으로 해결하지도 못합니다. 문제는 원격 사용자가 모든 VPC의 애플리케이션에 도달할 수 있는 확장 가능한 솔루션을 요구하는데, 이 옵션은 액세스를 중앙 집중화하기보다 분산시킵니다. 또한 적절한 transit routing을 갖춘 단일 endpoint보다 덜 세련되고 잠재적으로 더 비쌀 수 있습니다.

이 옵션이 틀린 이유는 VPC peering이 transitive routing을 지원하지 않기 때문입니다. hub VPC와 연결된 Client VPN endpoint는 해당 VPC의 리소스에 대한 액세스를 제공할 수 있지만, VPN client의 트래픽이 hub를 거쳐 spoke VPC들로 가는 transit 경로로 peering connection을 통해 계속 전달될 수는 없습니다. route table과 authorization rule을 구성하더라도, AWS는 이 목적을 위해 peered VPC를 transit gateway처럼 사용하는 것을 허용하지 않습니다. 따라서 hub account의 단일 Client VPN endpoint는 peering만으로는 모든 peered VPC에 도달할 수 없습니다.

이 옵션이 틀린 이유는 AWS Client VPN이 여러 VPC에 걸친 AWS workload에 도달하기 위한 메커니즘으로 기존 Site-to-Site VPN에 연결하도록 설계되지 않았기 때문입니다. Site-to-Site VPN은 corporate network를 AWS에 연결하지만, Client VPN을 통해 연결하는 원격 사용자는 여전히 spoke VPC들에 대한 동일한 기본 라우팅 제한에 직면하게 됩니다. 또한 hub VPC와 peered spoke들 사이의 transitive connectivity 부재를 해결하지 못한 채 불필요한 hairpinning과 복잡성만 추가합니다. 결과적으로 이 설계는 모든 VPC의 애플리케이션에 대한 확장 가능한 액세스 요구 사항을 충족하지 못합니다.

오답. CloudFront service IP range에 대한 IP allow listing에 의존하는데, 문제에서 이를 명시적으로 금지하며 CloudFront IP range는 자주 변경되어 운영상 취약하다. 또한 “ALB를 프라이빗 서브넷으로 이동”은 설명된 아키텍처(퍼블릭 서브넷의 ALB)와 충돌하며, 재설계(internal ALB)와 함께 CloudFront가 origin에 도달할 수 있는 지원 경로가 여전히 필요하다.

오답. AWS Systems Manager Parameter Store는 Secrets Manager처럼 임의의 random string에 대해 동일한 방식의 automatic rotation을 제공하지 않는다. 또한 ALB listener rule은 주로 라우팅/포워딩 결정을 위한 것이며, secret header 기반으로 무단 요청을 차단하는 견고한 보안 강제 수단으로는 AWS WAF의 명시적 allow/block 제어에 비해 부적절하다.

오답. Shield Advanced는 DDoS 보호와 가시성을 제공하지만 origin 인증을 해결하지 못한다. 또한 이 옵션은 네트워크 계층에서 CloudFront IP range만 허용하는 방식(security group policy)에 의존하는데, 이는 “static IP allow list 금지” 요구사항을 위반하며 유지보수가 어렵다. 여기서 필요한 origin access control은 애플리케이션 계층 검증 메커니즘(예: WAF header match)이다.

4분마다 snapshot을 생성하고 이를 다른 Region으로 복사하는 것은 9 TB relational database에 대해 4분 미만 RPO를 달성하는 실용적인 방법이 아닙니다. Snapshot 생성, cross-Region copy, 그리고 restore 작업은 상당한 지연을 유발하며, backup에서 새 Aurora cluster를 restore하는 것은 거의 확실하게 12분 RTO를 초과합니다. 이 옵션은 warm standby disaster recovery 설계가 아니라 backup-and-restore 전략입니다. 이는 거의 실시간에 가까운 cross-Region failover가 아니라 더 긴 복구 시간 창에 적합합니다.

RDS for PostgreSQL cross-Region read replica는 유효한 disaster recovery 패턴이지만, 9 TB database에서 4분 미만의 엄격한 RPO를 충족하기 위한 최선의 선택은 아닙니다. 표준 RDS PostgreSQL의 cross-Region replication은 asynchronous 방식이며, 쓰기 워크로드가 많거나 대규모 운영 조건에서는 lag를 엄격하게 제한하기가 더 어렵습니다. 일부 환경에서는 이 옵션이 작동할 수 있지만, 이 문제는 제시된 목표를 확실하게 충족하기 위해 선택해야 하는 솔루션을 묻고 있습니다. Aurora 기반 cross-Region replication 패턴이 일반적으로 엄격한 분 단위 DR 요구 사항에 더 잘 부합합니다.

same-Region의 read replica는 secondary AWS Region으로 fail over해야 한다는 명시적 요구 사항을 충족하지 않습니다. 이는 instance 또는 Availability Zone 장애에는 도움이 될 수 있지만, 전체 Regional outage에 대한 보호는 제공하지 않습니다. compliance 요구 사항이 secondary-Region failover를 구체적으로 요구하므로, 이 옵션은 비용이나 promotion 속도와 관계없이 제외해야 합니다. 따라서 정답이 될 수 없습니다.