실전 문제

문제 1

다국적 헬스장 프랜차이즈가 앱 기반 QR 방문 패스를 발급하며, 이 패스는 전 세계의 개찰구에서 스캔됩니다. 개찰구 스캐너는 백엔드 API를 호출하여 QR 데이터를 단일 데이터베이스 테이블과 대조해 검증하고, 스캔이 성공하면 패스를 원자적으로 사용 처리(redeemed)로 표시합니다. 회사는 DNS 이름 api.fitpass.example.org 하에 AWS에 배포해야 하며, 데이터베이스는 세 개의 AWS Region(us-east-1, eu-west-1, ap-southeast-1)에 호스팅해야 합니다. 전 세계 피크 트래픽은 분당 75,000건의 검증이며 페이로드는 20 KB 미만이고, 비즈니스는 가능한 한 가장 낮은 종단 간 검증 지연 시간을 요구하며 사용자의 가장 가까운 AWS edge location 기준 p95가 120 ms 미만이어야 합니다. 가장 낮은 지연 시간으로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 database lookup과 atomic redemption update를 수행하는 dynamic API에 대해 가장 낮은 지연 시간의 global architecture를 선택하는 내용입니다. 전 세계에 분산된 API 트래픽에 대해, 사용자를 최적의 네트워크 성능으로 가장 가까운 정상 regional application endpoint로 라우팅하도록 특별히 설계된 AWS 서비스는 AWS Global Accelerator입니다. database는 세 개의 Region에 존재해야 하지만, application은 여전히 dynamic하고 cache할 수 없는 API 호출을 위한 실용적인 request-routing 계층이 필요합니다. 정답인 이유: Option A가 최선의 답인 이유는 AWS Global Accelerator를 사용하여 client를 AWS global backbone을 통해 가장 가까운 regional ECS 기반 API endpoint로 전달해 dynamic request의 network latency를 최소화하기 때문입니다. us-east-1, eu-west-1, ap-southeast-1의 ECS 서비스는 사용자와 가까운 위치에서 regional processing을 제공하며, Route 53은 필요한 DNS 이름을 accelerator에 매핑할 수 있습니다. 제공된 선택지 중에서 이것이 전 세계에 분산된 low-latency API에 가장 적절한 architecture입니다. 주요 기능: - AWS Global Accelerator는 anycast static IP를 제공하고 빠른 failover와 함께 트래픽을 가장 가까운 정상 regional endpoint로 라우팅합니다. - ECS는 database read 및 write를 수행해야 하는 API 서비스에 적합한 regional compute platform입니다. - Aurora Global Database는 cross-Region replication과 multi-Region database 배치를 지원하여 database를 세 개의 Region에 호스팅해야 하는 요구 사항을 충족합니다. - Route 53은 custom DNS 이름 api.fitpass.example.org를 Global Accelerator endpoint에 alias로 연결할 수 있습니다. 흔한 오해: CloudFront는 종종 모든 global API에 대한 최선의 선택으로 오해되지만, 주로 CDN 및 edge proxy이며 여러 regional application stack에 걸친 dynamic하고 write-heavy한 API routing을 위한 기본 최적 선택은 아닙니다. CloudFront Functions는 database를 전혀 호출할 수 없고, Lambda@Edge도 DynamoDB를 대상으로 하는 write-heavy transactional backend를 구현하기 위한 의도된 메커니즘이 아닙니다. DynamoDB global tables는 active-active data에 매우 뛰어나지만, option C와 D의 주변 compute 및 routing 패턴에는 문제가 있습니다. 시험 팁: 가장 낮은 지연 시간으로 가장 가까운 regional backend에 도달해야 하는 globally distributed dynamic API의 경우, 먼저 CloudFront보다 AWS Global Accelerator를 떠올리세요. caching, static content delivery 또는 edge request manipulation이 설계의 핵심일 때는 CloudFront를 사용하세요. 어떤 선택지가 CloudFront Functions 또는 Lambda@Edge가 direct database transaction과 함께 전체 backend business logic를 수행한다고 제안한다면 주의해야 합니다. 이러한 서비스에는 중요한 capability 및 architectural limitation이 있기 때문입니다.

문제 2

한 미디어 회사는 Windows Server 2019에서 실행 중인 온프레미스 Microsoft SQL Server 인스턴스의 결제 처리 데이터베이스를 AWS로 마이그레이션해야 하며, 보안 정책에 따라 데이터베이스 자격 증명은 90일마다 로테이션되어야 합니다. 가장 적은 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 가장 낮은 운영 부담의 관리형 데이터베이스 마이그레이션 대상 선택과, AWS 네이티브 관리형 기능을 사용한 필수 자격 증명 로테이션 구현을 평가합니다. 핵심 서비스는 Amazon RDS for SQL Server(관리형 관계형 데이터베이스)와 AWS Secrets Manager(내장 로테이션을 제공하는 관리형 시크릿 스토리지)입니다. 정답이 맞는 이유: 온프레미스 Microsoft SQL Server 데이터베이스를 Amazon RDS for SQL Server로 마이그레이션하면 운영 오버헤드가 최소화됩니다. 이는 AWS가 데이터베이스 프로비저닝, 패치(엔진 및 RDS의 OS), 백업, point-in-time recovery, 모니터링 통합, 고가용성 옵션(Multi-AZ)을 관리하기 때문입니다. 90일마다 데이터베이스 자격 증명을 로테이션해야 한다는 보안 요구 사항은 자격 증명을 AWS Secrets Manager에 저장하고 90일 스케줄로 자동 로테이션을 활성화하는 방식으로 가장 잘 충족됩니다. Secrets Manager는 네이티브 로테이션 워크플로( AWS Lambda 기반)를 제공하고 RDS와 깔끔하게 통합되어, 사용자 정의 코드와 지속적인 유지보수를 줄입니다. 주요 AWS 기능: - Amazon RDS for SQL Server: 자동 백업, maintenance windows, Multi-AZ, CloudWatch metrics, 그리고 간소화된 확장/운영을 제공하는 관리형 SQL Server. - AWS Secrets Manager: 암호화된 시크릿 스토리지(KMS), 자동 로테이션 스케줄링(예: 90일마다), 지원되는 엔진용 로테이션 Lambda 템플릿, 버저닝(AWSCURRENT/AWSPREVIOUS), 그리고 CloudTrail을 통한 감사 가능성. - 모범 사례: 애플리케이션은 하드코딩 대신 Secrets Manager에서 런타임에 자격 증명을 조회(또는 캐싱 라이브러리 사용)합니다. 일반적인 오해: Systems Manager Parameter Store와 사용자 정의 Lambda 로테이션을 제안하는 옵션은 더 저렴하거나 단순해 보일 수 있지만 운영 오버헤드를 증가시킵니다. 로테이션 로직을 구축하고, SQL 로그인 변경을 안전하게 처리하며, 애플리케이션 업데이트를 조율하고, 실패/롤백을 관리하며, Lambda와 스케줄을 유지보수해야 합니다. AWS SCT를 통해 DynamoDB 또는 Neptune을 제안하는 옵션은 대규모 재설계가 필요하고 결제 처리용 관계형 SQL Server 워크로드의 직접적인 대상이 아니므로 부적절합니다. 시험 팁: 상용 데이터베이스 엔진에서 “least operational overhead”가 보이면, 자체 관리형 EC2보다 관리형 서비스(RDS)를 우선합니다. “매 X일마다 자격 증명 로테이션”이 보이면, 사용자 정의 로테이션 메커니즘보다 AWS Secrets Manager 자동 로테이션을 우선합니다. 또한 문제에서 명시적으로 요구하지 않는 한 불필요한 현대화(예: DynamoDB/Neptune)는 피하십시오.

문제 3

(3개 선택)

글로벌 디지털 미디어 에이전시는 단일 AWS Organizations 관리 계정 하의 9개 AWS 계정 전반에서 Amazon EC2에서 수명이 짧은 분석 워커를 실행하고 있습니다. Finance는 모든 EC2 지출이 필수 CostCenter 태그를 통해 귀속되도록 요구하지만, 내부 감사에서 두 개의 개발자 계정에서 실행 중인 인스턴스 240개 중 43개(18%)에 CostCenter 태그가 누락된 것이 발견되었습니다. 또한 리더십은 조직 전체에 대한 즉각적인 가시성과, 해당 태그 없이 새 EC2 인스턴스를 시작하는 것을 차단하되 올바르게 태그된 시작은 허용하는 예방적 제어를 요구합니다. 솔루션스 아키텍트는 현재의 격차를 시정하고 조직 전반의 중앙 집중식 보고로 재발을 방지하기 위해 어떤 조치를 취해야 합니까? (세 가지 선택)

문제 분석

핵심 개념: 이 문제는 태깅에 대한 조직 전반 거버넌스를 테스트합니다: (1) 기존 비준수 리소스를 찾기 위한 탐지(Detective) 제어, (2) 향후 비준수 시작을 막기 위한 예방(Preventive) 제어, (3) AWS Organizations 내 여러 AWS 계정 전반의 중앙 집중식 가시성. 주요 서비스는 AWS Config(규칙 + 집계)와 AWS Organizations SCP(가드레일)입니다. 정답이 맞는 이유: 현재의 격차(43개 인스턴스에 CostCenter 누락)를 시정하고 즉각적인 가시성을 제공하려면, EC2 리소스에 필수 태그가 있는지 평가하고 준수 상태를 중앙에서 보고하는 탐지 메커니즘이 필요합니다. AWS Config의 관리형 규칙 required-tags는 EC2 인스턴스를 평가하고 CostCenter가 누락된 것을 플래그할 수 있습니다(A). 9개 계정과 여러 Regions 전반에서 보고를 중앙화하려면, 조직 수준의 AWS Config aggregator가 준수 결과를 단일 계정으로 수집하여 쿼리와 대시보드를 제공할 수 있습니다(E). 재발을 방지하려면, 태그 없이 새 EC2 시작을 차단하되 올바르게 태그된 시작은 허용하는 예방적 제어가 필요합니다. 조직 수준 SCP는 aws:RequestTag/CostCenter가 없을 때 ec2:RunInstances를 거부(그리고 선택적으로 생성 시 TagSpecifications 강제)하여 개발자 계정을 포함한 모든 멤버 계정에서 태그 없는 시작을 차단할 수 있습니다(B). 주요 AWS 기능: - AWS Config 관리형 규칙 required-tags: 지정된 태그 키의 존재 여부를 지원되는 리소스 유형에 대해 지속적으로 평가하며, 시정(Remediation) 워크플로와 통합됩니다. - AWS Config Aggregator(조직 집계): 계정/Regions 전반의 준수 상태를 중앙에서 확인하며, advanced queries로 쿼리할 수 있습니다. - SCP 조건 키: aws:RequestTag/CostCenter 및 aws:TagKeys는 RunInstances 같은 API 호출에서 TagSpecifications가 제공될 때 생성 시 태그 강제를 적용할 수 있습니다. 흔한 오해: Security Hub와 Inspector는 보안 태세/취약점 도구이며, 비용 할당 태그 준수의 권위 있는 강제 메커니즘이 아닙니다. IAM 정책으로 RunInstances를 거부할 수는 있지만, 계정별로 배포/유지해야 하며 정책이 적용되지 않는 프린시펄에 의해 우회될 수 있어 SCP 가드레일보다 약합니다. 시험 팁: 대규모에서 “필수 태그”는 AWS Config로 탐지 + Config Aggregator로 중앙 보고를 사용합니다. 조직 전반에서 “태그 없이 생성 차단”은 aws:RequestTag 및 aws:TagKeys를 사용하는 SCP를 사용합니다. 기억할 점: SCP는 최대 권한을 설정하며 권한을 부여하지는 않지만, 계정 전반의 예방적 거버넌스에 이상적입니다.

문제 4

글로벌 미디어 구독 서비스가 ap-southeast-2의 세 개 Availability Zone에 걸쳐 Amazon EC2에서 상태 비저장 고객 대시보드를 출시할 계획입니다. 평균 CPU > 60%가 5분 동안 지속될 때 6~120 인스턴스로 Auto Scaling을 수행하며 99.9% 가용성이 필요합니다. 또한 ap-northeast-1에 RTO 10분의 active-passive 재해 복구(DR) 환경을 구현하고 Route 53 health check(30초 간격, 연속 2회 실패 후 장애로 판단)를 사용하되, 정상 운영 중에는 ap-southeast-2에서만 트래픽을 제공해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 Application Load Balancer, Auto Scaling, 그리고 health check가 포함된 Amazon Route 53 DNS failover를 사용하여 상태 비저장 EC2 웹 계층에 대한 multi-Region 고가용성과 재해 복구(DR) 설계를 평가합니다. 또한 서비스 범위도 간접적으로 테스트합니다. ALB와 Auto Scaling group은 Regional이며, 일부 선택지에서 제안하는 것처럼 Region/VPC를 가로질러 확장할 수 없습니다. 정답이 맞는 이유: 선택지 C는 active-passive DR 패턴을 구현합니다. 정상 운영 중에는 ap-southeast-2가 모든 트래픽을 제공(Primary)하고, ap-northeast-1은 프로비저닝되어 준비된 상태(Secondary)이지만 장애 시에만 트래픽을 수신합니다. Route 53 failover routing과 health check를 통해 primary 엔드포인트가 비정상 상태가 되면 DNS 응답이 secondary로 전환됩니다. 지정된 health check 설정(30초 간격, 연속 2회 실패 후 장애)은 요구 사항과 일치하며, 60초 TTL은 DNS 캐싱 지연을 줄여 10분 RTO를 충족하는 데 도움이 됩니다. Primary Region은 세 개 AZ에 걸친 ALB와 최소 6/최대 120의 Auto Scaling group, 그리고 평균 CPU > 60%가 5분 지속될 때 스케일링을 사용하여 스케일링 요구 사항과 99.9% 가용성 목표를 충족합니다. 주요 AWS 기능: - ALB는 Regional이며 Region 내 여러 AZ에 걸쳐 구성할 수 있어 복원력을 향상합니다. - 여러 AZ에 걸친 EC2 Auto Scaling은 탄력성과 AZ 장애 허용을 제공합니다. - Route 53 failover routing policy는 health check가 포함된 primary/secondary record를 지원합니다. - health check 간격과 실패 임계값은 감지 시간을 결정하며, TTL은 클라이언트 측 DNS 캐싱에 영향을 주어 실질적인 failover 시간에 영향을 줍니다. 흔한 오해: A와 D는 ALB가 VPC/Region 전반으로 “확장”될 수 있고 단일 Auto Scaling group이 두 Region/VPC에 걸쳐 인스턴스를 시작할 수 있다고 가정합니다. 실제로 ALB와 ASG는 단일 Region 범위이며(또한 ALB는 해당 Region의 subnet과 연결됨), VPC peering도 단일 ALB가 다른 Region의 인스턴스를 대상으로 삼을 수 있게 해주지 않습니다. B는 비슷해 보이지만 active-passive 동작을 강제하지 않습니다. “두 record에 health check를 활성화”는 모호하며 active-active(예: weighted/multivalue) 또는 의도치 않은 트래픽 분산으로 이어질 수 있습니다. 시험 팁: - Regional 경계를 기억하세요: ALB, ASG, subnet은 Regional이며 Route 53은 global입니다. - Route 53로 active-passive DR을 구성할 때는 health check와 함께 명시적인 primary/secondary가 있는 “failover routing policy”를 찾으세요. - RTO는 감지 시간 + DNS TTL + 프로비저닝 준비 상태에 좌우됩니다. secondary 스택을 warm 상태로 유지하고 TTL을 낮게 설정하면 RTO가 개선됩니다.

문제 5

한 물류 회사가 2,500대의 자율 창고 로봇 플릿을 배포하고 있으며, 각 로봇은 Wi-Fi를 통해 매초 8 KB의 텔레메트리를 AWS로 전송합니다. 이 회사는 유입 스트림에 대해 준실시간(<=3초) 분석을 제공하고, 내구적이며 순서가 보장되고 고도의 병렬 처리가 가능한 수집을 보장하며, 데이터를 재처리할 수 있어야 하고, 처리된 결과를 BI를 위한 데이터 웨어하우스로 전달하는 데이터 플랫폼이 필요합니다. 이러한 요구 사항을 충족하기 위해 솔루션스 아키텍트는 어떤 전략을 사용해야 합니까?

문제 분석

핵심 개념: 이 문제는 올바른 스트리밍 수집 및 준실시간 분석 아키텍처를 선택하는 것을 평가합니다. 핵심 요구 사항인 내구적이고 순서가 보장되는 수집, 높은 병렬성, 재생/재처리 가능, 그리고 데이터 웨어하우스로의 전달은 Amazon Kinesis Data Streams (KDS) + 스트림 처리 계층 + Redshift 싱크에 직접적으로 매핑됩니다. 정답이 맞는 이유: Amazon Kinesis Data Streams는 높은 처리량과 낮은 지연의 스트리밍 수집을 위해 목적에 맞게 설계되었으며, shard별 레코드 순서 보장과 멀티 컨슈머 fan-out을 제공합니다. 2,500대 로봇이 각각 8 KB/s를 전송하므로 유입 볼륨은 약 20 MB/s(약 160 Mb/s)입니다. KDS는 write 처리량과 병렬 처리 요구를 충족하기 위해 shard를 추가하여 수평 확장이 가능합니다. 또한 KDS는 기본적으로 24시간(최대 365일) 데이터 보존을 제공하므로, 컨슈머가 체크포인트에서 다시 읽어 과거 데이터를 재처리할 수 있는데, 이는 문제에서 명시적으로 요구하는 사항입니다. 준실시간 분석(<=3초)은 Kinesis Client Library (KCL) 컨슈머 또는 관리형 처리(일반적으로 Kinesis Data Analytics / Apache Flink)를 사용해 달성할 수 있으며, 이후 정제된 결과를 BI를 위해 Amazon Redshift로 로드할 수 있습니다. 옵션에서 EMR을 언급한 것은 시험에서 흔한 패턴으로, 확장 가능한 컴퓨팅 계층을 사용해 변환한 뒤 Redshift로 적재하는 흐름을 반영합니다. 주요 AWS 기능: KDS는 shard 내에서의 순서 보장 처리, 여러 AZ에 걸친 내구적 복제, shard를 통한 수평 확장을 제공합니다. Enhanced fan-out은 여러 병렬 컨슈머에 전용 처리량을 제공하여 지원합니다. 체크포인팅(KCL/DynamoDB를 통해)은 exactly-once/at-least-once 처리 패턴과 재생을 가능하게 합니다. Redshift의 경우 일반적인 전달 방식은 S3에서의 마이크로 배치 COPY 또는 스트리밍 수집 패턴이며, EMR/Spark는 텔레메트리를 집계/윈도잉하고 S3/Redshift에 효율적으로 기록할 수 있습니다. 흔한 오해: Firehose(옵션 A)는 S3/Redshift/OpenSearch 등으로의 단순 전달에는 훌륭하지만, KDS와 같은 재생/재처리 제어 및 shard별 순서 보장 의미론을 제공하지 않으며, 버퍼링으로 인해 지연이 증가할 수 있습니다. SQS 기반 설계(옵션 C/D)는 대규모에서 엄격한 순서를 보존하지 못하며, 재생 가능한 스트림 분석에 적합하지 않습니다. 시험 팁: “순서가 보장되는 내구적 스트림”, “병렬 수집”, “재처리/재생”을 보면 Kinesis Data Streams(또는 Kafka/MSK)를 떠올리십시오. “BI를 위한 데이터 웨어하우스로 전달”을 보면 싱크로 Redshift를 떠올리며, 종종 중간의 정제 저장소(일반적으로 S3)와 처리 엔진(Flink/Spark/EMR)이 함께 사용됩니다.

이동 중에도 모든 문제를 풀고 싶으신가요?

Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.

문제 6

멀티미디어 분석 스타트업이 단일 Amazon S3 bucket에 JSON 요약과 썸네일을 저장합니다(평균 object 크기 200 KB; 시간당 약 80,000개의 신규 object; 애플리케이션에서 읽기와 쓰기 모두 수행). 회사는 지연 시간을 줄이고, 두 Region 모두에서의 쓰기를 지원하며, 애플리케이션을 위한 단일 데이터 액세스 endpoint를 제공하고, 15분 미만의 replication 지연을 갖는 eventual consistency를 허용하며, 애플리케이션 코드 변경을 최소화하고, 운영 오버헤드를 최소로 하기 위해 두 AWS Region(us-east-1 및 ap-southeast-2)에 동일한 애플리케이션 스택을 배포해야 합니다. 회사는 어떤 솔루션을 구현해야 합니까?

문제 분석

핵심 개념: 이 문제는 두 Region에서의 쓰기를 포함하는 active-active, multi-Region Amazon S3 액세스와 최소한의 애플리케이션 변경, 그리고 낮은 운영 오버헤드를 테스트합니다. 핵심 서비스는 S3 Cross-Region Replication(CRR)과 S3 Multi-Region Access Points(MRAP)이며, MRAP는 가장 가까운 정상 S3 bucket으로 요청을 라우팅하는 단일 글로벌 endpoint를 제공합니다. 정답이 맞는 이유: Option B만이 모든 요구 사항을 동시에 충족합니다: us-east-1과 ap-southeast-2에 두 개의 동일한 스택, 두 Region 모두에서 발생하는 쓰기, 단일 데이터 액세스 endpoint, 그리고 최소한의 코드 변경. Region별로 bucket 2개(Region당 1개)와 MRAP를 사용하면 애플리케이션은 전 세계적으로 하나의 S3 endpoint 이름을 사용할 수 있고, MRAP는 지연 시간과 가용성에 따라 가장 가까운 bucket으로 읽기/쓰기를 라우팅합니다. 양방향 replication은 Region 간 데이터가 수렴하도록 유지하며, 15분 미만의 replication 지연을 갖는 eventual consistency는 일반적인 CRR 동작과 부합합니다(더 엄격한 SLA가 필요하면 Replication Time Control을 사용할 수 있음). 주요 AWS 기능: - S3 Multi-Region Access Points: 단일 글로벌 endpoint, 지능형 라우팅, 자동 failover, 단순화된 multi-Region 아키텍처. - 양방향 replication: 두 개의 단방향 CRR rule(각 bucket이 서로에게 replication)로 구현. 두 bucket 모두에서 versioning 활성화 및 적절한 IAM role/policy 필요. - Replication 고려 사항: 신규 object replication 처리; 요구 사항에 따라 delete marker replication 및 replica modification sync를 선택적으로 구성. 흔한 오해: CloudFront와 Global Accelerator(Option A)는 읽기 지연 시간을 개선할 수 있지만, 단일하고 일관된 데이터 계층을 갖춘 multi-Region, active-active S3 쓰기를 제공하지는 않습니다. 단방향 CRR(Option C)은 “두 Region에서의 쓰기” 요구 사항을 충족하지 못합니다. VPC gateway endpoint와 Intelligent-Tiering(Option D)은 네트워킹/비용 기능이며 multi-Region replication이나 단일 글로벌 endpoint를 해결하지 못합니다. 시험 팁: “single endpoint” + “multi-Region S3” + “writes from both Regions” + “minimal app changes”를 보면, 두 개의 bucket과 replication, 그리고 S3 MRAP를 떠올리십시오. 또한 S3 replication은 bucket 쌍별로 구성되며 본질적으로 비동기입니다. 문제가 replication SLA를 언급한다면 Replication Time Control을 고려하되, MRAP는 글로벌 액세스의 핵심 구성 요소로 유지됩니다.

문제 7

다국적 소매 기업이 단일 payer account와 12개의 member account로 AWS Organizations를 사용하고 있다. 3년 전 회사는 3-year All Upfront Amazon EC2 Standard Reserved Instances를 구매했으며 이 Reserved Instances는 지난달 만료되었다. 현재 EC2 사용량은 us-east-1, eu-west-1, ap-southeast-2 전반에서 평균 2,000 normalized units이며, 회사는 AWS Lambda와 AWS Fargate에서 안정적인 일일 사용량을 갖는 새로운 event-driven data processing pipeline을 출시했다. 회사는 향후 36개월 동안 EC2 및 serverless 소비가 안정적일 것으로 예상하며 모든 account 전반에서 비용 절감을 극대화하고자 한다. 가장 큰 절감을 제공하는 구매 전략은 무엇인가?

문제 분석

핵심 개념: 이 문제는 AWS Organizations 전반에서 commitment-based discounts를 사용한 장기 AWS 비용 최적화를 평가합니다. 대상은 EC2 Reserved Instances (RIs)와 Savings Plans(Compute 및 EC2 Instance)이며, consolidated billing 하에서 여러 account와 서비스(EC2, Lambda, Fargate)에 어떻게 적용되는지를 묻습니다. 정답인 이유: 이 회사는 36개월 동안 안정적이고 예측 가능한 사용량을 보이며, 최대 절감을 원합니다. EC2의 경우, 3-year Standard RIs with All Upfront는 역사적으로 steady-state이고 instance family/size/region별 사용량이 명확할 때 가장 큰 할인을 제공합니다(특히 fleet가 잘 파악되어 있고 안정적인 경우). 기존의 구매 방식(3-year All Upfront Standard RIs)과 세 개 Region에 걸친 안정적인 2,000 normalized units 사용량은 regional RI coverage를 효과적으로 활용할 수 있음을 보여줍니다. 새로운 serverless pipeline의 경우, EC2 RIs는 Lambda나 Fargate에는 적용되지 않습니다. 3-year Compute Savings Plan with All Upfront는 Lambda, Fargate, 그리고 RIs와 정확히 매칭되지 않는 EC2 사용량까지 폭넓게 커버합니다. management (payer) account에서 구매하면, AWS Organizations에서 sharing이 활성화된 경우 Savings Plans 혜택이 member account 전반에 적용될 수 있어 활용률을 극대화하고 사용되지 않는 discount를 최소화할 수 있습니다. 주요 AWS 기능: - Consolidated billing 및 discount sharing: RI와 Savings Plans 할인은 organization 내 account 간에 공유될 수 있습니다(sharing 설정에 따름). - Standard RIs (3-year, All Upfront): 일반적으로 사용량이 안정적이고 속성이 명확할 때 가장 높은 EC2 할인을 제공합니다. - Compute Savings Plans: EC2, Fargate, Lambda에 적용되며, 혼합 compute 포트폴리오와 modernization에 적합합니다. - All Upfront 결제: 일반적으로 Partial/No Upfront보다 더 높은 실질 할인율을 제공합니다. 흔한 오해: - Savings Plans가 항상 RIs보다 낫다고 가정하는 것: Savings Plans는 유연하지만, 매우 예측 가능한 EC2 사용 패턴에서는 Standard RIs가 여전히 최고의 할인일 수 있습니다. - member account별로 구매하는 것: organization 전체에 공유되는 중앙 구매 commitment와 비교해 유연성이 떨어지고 활용되지 못할 가능성이 커질 수 있습니다. - “유연성”을 위해 No Upfront를 선택하는 것: 문제에서는 36개월의 안정적인 사용량과 최대 절감을 요구하므로, 더 긴 기간과 upfront 결제가 유리합니다. 시험 팁: - workload 구성에 Lambda/Fargate가 포함되면, 해당 서비스에 대해 Compute Savings Plans를 포함해야 합니다. - 매우 안정적인 EC2의 경우, 3-year Standard RIs(대개 가장 높은 할인)를 고려하고, Compute Savings Plans로 non-EC2 compute와 남는 EC2 사용량을 커버합니다. - discount sharing이 활성화되어 있다면, account 전반의 활용률을 극대화하기 위해 organization 수준 구매(management account)를 선호하세요.

문제 8

한 피트니스 교육 플랫폼은 Application Load Balancer 뒤에서 Auto Scaling group과 함께 Amazon EC2로 웹 계층을 운영하고, 모든 정적 자산을 Amazon EFS (General Purpose)에 저장하고 있습니다. 그런데 1080p 트레이닝 비디오 라이브러리(평균 파일 크기 200 MB)를 출시한 이후 트래픽이 12배 급증하여 피크 시 약 20,000명의 동시 사용자가 발생했고, 사용자들은 이제 5–10초 버퍼링과 간헐적인 HTTP 504 오류를 겪고 있습니다. 그렇다면 컴퓨팅 계층을 replatforming하지 않으면서 이러한 문제를 해결하기 위한 가장 비용 효율적이고 확장 가능한 배포 변경은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 대용량 정적 미디어에 대해 Amazon S3와 Amazon CloudFront를 사용하여 확장 가능하고 비용 효율적인 콘텐츠 전송을 설계하는 능력, 그리고 높은 fan-out의 대용량 객체 배포에 Amazon EFS가 부적절한 백엔드가 될 수 있음을 식별하는 능력을 평가합니다. 정답이 맞는 이유: 1080p 비디오(평균 200 MB)를 약 20,000명의 동시 사용자에게 제공하면 매우 높은 총 처리량과 다수의 동시 읽기가 발생합니다. EFS General Purpose에서는 성능이 throughput mode(bursting 또는 provisioned)에 의해 좌우되며 병목이 생길 수 있고, 이로 인해 지연 시간이 증가하며 ALB에서 HTTP 504로 나타나는 업스트림 타임아웃이 발생할 수 있습니다. 비디오 라이브러리를 Amazon S3로 마이그레이션하고 CloudFront를 앞단에 두면 origin 부하를 오프로딩하고, 동시 시청자에 대해 사실상 제한 없이 확장되며, edge caching과 최적화된 전송을 통해 지연 시간을 크게 줄입니다. 이는 EC2/ALB 컴퓨팅 계층을 변경하지 않고도 버퍼링과 504를 해결합니다. 주요 AWS 기능: S3는 매우 높은 요청률과 처리량을 제공하는 고내구성 object storage입니다. CloudFront는 edge location에서 콘텐츠를 캐시하고, 대용량 파일 전송을 지원하며, HTTP range requests(비디오 탐색 및 adaptive player에 중요), origin shielding, 그리고 접근 제어가 필요할 경우 signed URLs/cookies를 지원합니다. 또한 S3를 origin으로 사용하면 lifecycle policy(예: 오래된 비디오를 S3 Intelligent-Tiering로 전환)를 단순화할 수 있고, 피크에 맞춰 EFS throughput을 확장하는 것보다 비용을 줄일 수 있습니다. 흔한 오해: EFS performance mode(Max I/O)를 높이면 고도로 병렬적인 워크로드에서 확장성에 도움이 될 수 있지만, 대규모 스트리밍에 필요한 처리량 경제성을 본질적으로 해결하지는 못합니다. 또한 지연 시간이 증가할 수 있으며, 여전히 충분한 throughput 구성이 필요합니다. 비디오를 EFS에 둔 채로 ALB 앞에 CloudFront를 두는 방식은 비디오가 사실상 캐시 불가능(접근 패턴, range requests, cache miss)하거나 origin이 계속 제약을 받는 경우 핵심 문제를 해결하지 못합니다. 시험 팁: 대용량 정적 자산(이미지, 다운로드, 비디오)에는 기본적으로 S3 + CloudFront를 선택하세요. EFS는 애플리케이션을 위한 공유 POSIX 파일 시스템에 적합하며, 대규모 미디어 배포를 위한 CDN origin으로는 적합하지 않습니다. 부하 상황에서 버퍼링 + 504가 보이면 origin 포화(saturation)를 의심하고, 무거운 정적 전송을 컴퓨팅/파일 계층에서 edge/object storage로 분리하세요.

문제 9

한 핀테크 스타트업이 향후 3년 동안 지속될 컴플라이언스 프로그램을 위해 AWS에서 통화 견적 API를 운영하고 있습니다. 이 API는 두 개의 Availability Zone에 걸쳐 Network Load Balancer (NLB) 뒤의 target group에 등록된 20개의 Amazon EC2 On-Demand Instances에서 실행됩니다. 이 서비스는 stateless이며 24x7로 실행됩니다. 사용자들이 응답이 느리다고 보고합니다. metrics를 보면 정상 트래픽 동안 평균 CPU는 10%이지만, 매일 몇 시간 동안 시장 개장 시간에는 CPU가 100%까지 급증합니다. 회사는 급증 시 지연 시간을 해결하면서 3년 기간 동안 비용을 최소화하는 새로운 아키텍처가 필요합니다. 가장 비용 효율적인 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 24x7로 유지되는 안정적인 baseline과 예측 가능한 일일 급증이 있는 상황에서 비용 최적화된 탄력성을 테스트합니다. 핵심 서비스/개념은 EC2 Auto Scaling (load balancer 뒤의 stateless workload에 대한 동적 scaling)과 EC2 pricing models (baseline에는 Reserved Instances/Savings Plans, burst에는 On-Demand)입니다. 정답이 맞는 이유: 워크로드는 stateless이고 NLB 뒤에 있으며, 평균 CPU가 낮고(10%) 짧은 일일 기간 동안 포화(100%)가 발생합니다. 3년 관점에서 가장 비용 효율적인 설계는 항상 켜져 있는 baseline을 적정 규모로 맞추고 spike 구간에만 scale out하는 것입니다. 옵션 D는 작은 minimum capacity(4)로 baseline을 커버하고, 시장 개장 시간에 Auto Scaling으로 최대 28까지 확장하여 CPU spike 시 용량을 추가함으로써 지연 시간을 제거합니다. baseline(4개)에 대해서만 Reserved Instances를 구매하면 장기 비용을 최소화할 수 있고, 추가 인스턴스는 spike 동안에만 실행되므로(On-Demand) 24x7로 필요하지 않은 용량을 예약하는 것보다 더 저렴합니다. 주요 AWS 기능: - target tracking(예: 평균 CPU 또는 NLB metrics)을 사용하는 EC2 Auto Scaling으로 인스턴스를 자동으로 추가/제거 - health checks 및 registration/deregistration를 위한 Auto Scaling과 NLB target group 통합 - 항상 켜져 있는 baseline에는 Reserved Instances(또는 Compute Savings Plans), burst capacity에는 On-Demand - Well-Architected Cost Optimization: 수요에 맞춰 공급을 조정하고 steady-state usage에만 커밋 흔한 오해: 흔한 함정은 현재 fleet이 20이므로 너무 많은 인스턴스를 예약하는 것(옵션 A)입니다. 하지만 metrics는 지속적인 과다 프로비저닝(10% CPU)을 보여주므로 20개를 예약하면 3년 동안 비용이 낭비됩니다. 또 다른 오해는 Spot이 항상 가장 저렴하다는 것(옵션 B/C)입니다. 컴플라이언스 프로그램과 지연 시간에 민감한 시장 개장 시간 spike의 경우, Spot interruption risk와 capacity availability는 다양화와 fallback 없이 설계하면 성능과 신뢰성에 악영향을 줄 수 있습니다. 시험 팁: “24x7로 3년”과 “spiky”를 보면 “baseline은 reserve하고 burst는 autoscale”을 떠올리십시오. metrics를 사용해 baseline 과다 프로비저닝을 추론하십시오. stateless 서비스라면 기존 load balancer 뒤에서 Auto Scaling을 선호하십시오. Spot은 비용 효율적일 수 있지만, 시험에서는 보통 interruption tolerance가 명시되고 graceful handling 및 fallback 아키텍처가 포함될 때 선택됩니다.

문제 10

한 게임 분석 회사가 Amazon API Gateway 뒤에 매치메이킹 REST API를 배포하고 있으며, 이 API는 Java 17로 작성된 여러 AWS Lambda 함수를 호출합니다. 이 함수들은 핸들러 외부에서 무거운 정적 초기화를 수행하고(서드파티 라이브러리 로드, Spring context 빌드, 고유 ID/암호화 seed 생성), 현재 부하 테스트에서 cold start가 800–1200 ms가 걸립니다. 서비스 수준 목표(SLO)는 cold initialization의 95%가 200 ms 미만에 완료되어야 하며, 트래픽은 몇 초 내에 0에서 동시 요청 60까지 급증합니다. 또한 팀은 항상 켜져 있는(always-on) 용량 비용을 지불하지 않으면서 시작 지연을 최소화하는 가장 비용 효율적인 방법을 원합니다. 팀은 어떤 솔루션을 선택해야 합니까?

문제 분석

핵심 개념: 이 문제는 Java runtime에서 Lambda SnapStart와 Provisioned Concurrency를 사용한 AWS Lambda cold-start 완화, 그리고 실행 환경마다 고유해야 하는 초기화 코드(예: cryptographic seeds/unique IDs)를 어떻게 처리하는지를 평가합니다. 또한 Amazon API Gateway 뒤에서 bursty 트래픽을 처리할 때 versioning/aliases 요구사항과 비용 트레이드오프도 간접적으로 테스트합니다. 정답이 맞는 이유: (Java용) Lambda SnapStart는 init 단계 이후 초기화된 실행 환경의 snapshot을 생성하고 필요 시 on-demand로 복원하여 cold start를 줄입니다. 이는 라이브러리 로드나 Spring context 빌드 같은 무거운 정적 초기화에 이상적입니다. 하지만 런타임에서 고유해야 하는 항목(랜덤 seed, 고유 ID, 특정 crypto material, timestamp)은 snapshot에 “고정(frozen)”되면 안 됩니다. 그렇지 않으면 복원된 환경들 간에 값이 중복될 위험이 있습니다. 올바른 접근은 pre-snapshot hook을 사용해 runtime을 snapshotting에 적합하게 준비하고, 고유성에 민감한 초기화는 핸들러(또는 post-restore 로직)로 옮겨 환경/호출마다 적절히 생성되도록 하는 것입니다. SnapStart는 버전을 publish한 뒤 해당 버전에서 SnapStart를 활성화해야 하며($LATEST에서는 불가), 이는 항상 켜져 있는 용량 비용 없이 <200 ms cold init SLO를 충족하는 데 도움이 됩니다. 주요 AWS 기능: - Lambda SnapStart: 초기화된 Java 실행 환경을 snapshot하여 cold start를 크게 줄입니다. - Published versions: SnapStart는 version에서 활성화되며, 안정성을 위해 API Gateway는 alias/version을 호출해야 합니다. - Runtime hooks (pre-snapshot/post-restore): snapshotting 시 정확성을 보장합니다(예: RNG re-seeding, ephemeral state refresh). - Best practice: 무겁고 결정적인(deterministic) init은 핸들러 밖에 두고, 호출/환경별 고유성이 필요한 부분은 핸들러 또는 post-restore에 둡니다. 흔한 오해: Provisioned Concurrency도 cold start를 줄일 수 있지만, 사전 워밍된 용량에 대해 비용이 청구되므로 트래픽이 자주 0이고 갑작스런 burst가 있는 경우 비용 효율성이 떨어집니다. 또 다른 함정은 $LATEST에 SnapStart를 활성화하려는 것(지원되지 않음) 또는 고유 ID/seed를 snapshot에 포함시키는 것으로, 이는 중복 식별자 또는 약화된 randomness를 초래할 수 있습니다. 시험 팁: - 무거운 framework를 사용하는 Java cold start라면, on-demand 비용 동작을 원할 때는 SnapStart를 먼저 떠올리세요. - SnapStart는 $LATEST가 아니라 published version에서 동작한다는 점을 기억하세요. - 문제에 unique IDs/crypto seeds 또는 “고유해야 함”이 언급되면, 해당 상태가 snapshot에 포함되지 않도록 hook/handler 변경을 예상하세요. - 보장된 warm capacity가 필요하고 지속 비용을 정당화할 수 있으면 Provisioned Concurrency를, 항상 켜짐 비용 없이 cold start를 낮추려면 SnapStart를 선택하세요.

문제 11

디지털 교육 플랫폼이 AWS에서 등록(enrollment) 서비스를 실행하고 있습니다. 이 서비스는 Amazon API Gateway를 통해 REST endpoint를 노출하며, 이는 AWS Lambda function을 호출하고, 해당 function은 Amazon RDS for PostgreSQL DB instance에 대해 트랜잭션 읽기 및 쓰기를 수행합니다. 2시간짜리 “Early Access” 프로모션 동안 Amazon CloudWatch에서 동시 Lambda 실행이 기준선 80에서 3,200으로 급증했고, 활성 데이터베이스 연결이 500-connection 한도 중 470까지 증가했으며, DB CPU 사용률이 85% 이상으로 지속되어 간헐적인 502 오류와 p95 API 지연 시간이 2.5초를 초과하는 문제가 발생했습니다. 이러한 버스트 조건에서 애플리케이션 성능을 최적화하기 위해 solutions architect는 무엇을 권장해야 합니까?

문제 분석

핵심 개념: 이 문제는 Amazon RDS를 호출하는 AWS Lambda의 버스트 스케일링 동작과 그로 인해 발생하는 “connection storm” 문제를 평가합니다. 핵심 서비스는 Amazon RDS Proxy이며, 이는 connection pooling을 제공하고 serverless 및 고동시성 클라이언트의 데이터베이스 연결을 관리합니다. 정답이 맞는 이유: 프로모션 동안 Lambda concurrency가 3,200으로 급증하는 동시에 데이터베이스가 470/500 connections에 도달했고 CPU가 >85%로 지속되어 502와 높은 p95 latency가 발생했습니다. 이 패턴은 단순히 쿼리가 느린 것이 아니라, 너무 많은 동시 client connections 및 connection churn(빈번한 open/close, TLS/auth 오버헤드)으로 인해 데이터베이스가 과부하되었음을 강하게 시사합니다. RDS Proxy는 Lambda와 RDS 사이에 위치하여 PostgreSQL에 대한 설정된 연결의 warm pool을 유지하고, 더 적은 수의 DB connections로 많은 Lambda invocation을 multiplex합니다. 이를 통해 connection spike를 줄이고, connection 관리에 쓰이는 CPU를 낮추며, 버스트 동안의 복원력을 개선하고, latency를 안정화합니다. 주요 AWS 기능: RDS Proxy는 PostgreSQL을 지원하고, credential 관리를 위해 IAM 및 AWS Secrets Manager와 통합되며, connection pooling을 제공하고, 애플리케이션 측 재연결 로직을 줄여 failover 처리도 개선할 수 있습니다. Lambda의 경우 best practice는 function이 proxy endpoint를 가리키도록 하고 애플리케이션 연결을 열린 상태로 유지하는 것입니다(backend pooling은 proxy가 관리). 이는 버스트 부하를 완화하고 데이터베이스를 보호함으로써 AWS Well-Architected의 Reliability 및 Performance Efficiency pillar와 부합합니다. 흔한 오해: Caching(ElastiCache)은 read-heavy workload에 도움이 될 수 있지만, 문제는 트랜잭션 읽기/쓰기를 언급하고 connection 포화 상태를 보여줍니다. caching은 write pressure나 connection storm을 해결하지 못합니다. Lambda에서 연결 재사용(handler 외부 초기화)은 도움이 되지만, 극단적인 concurrency에서는 각 동시 실행 환경이 여전히 자체 connection(s)을 만들 수 있어 DB 한도를 빠르게 소진하므로 충분하지 않습니다. Lambda memory를 늘리면 compute가 빨라질 수는 있지만 DB connection 한도를 해결하지 못하며, 오히려 DB에 대한 병렬성을 증가시킬 수도 있습니다. 시험 팁: Lambda/API Gateway + RDS 조합에서 갑작스러운 concurrency spike, 한도에 근접한 높은 DB connections, 그리고 간헐적인 502/timeout과 함께 상승한 CPU가 보이면 “RDS Proxy/connection pooling”을 떠올리십시오. “연결 닫기” 지침보다 RDS Proxy를 선택하십시오. serverless에서는 요청마다 닫는 방식이 종종 churn을 악화시킵니다. bottleneck이 반복적인 reads이고 eventual consistency를 허용할 수 있을 때만 caching을 사용하십시오.

문제 12

온라인 티켓팅 플랫폼은 컨테이너화된 마이크로서비스를 여러 대의 public IP 주소가 있는 Amazon EC2 인스턴스에 배포해 실행하고 있으며, 자체 관리형 Apache Kafka 클러스터도 해당 EC2 인스턴스에서 실행 중이고, 트랜잭션 데이터베이스는 Amazon RDS for PostgreSQL로 마이그레이션되었습니다. 마케팅 팀은 다음 주 72시간 동안 진행되는 전국 단위 사전판매 기간에 트래픽이 5배 급증할 것으로 예측하고 있으며, 엔지니어링 리더십은 급증을 탄력적으로 처리하면서 운영 작업 부담을 최소화하고자 합니다—현재 아키텍처에 어떤 변경을 하면 운영 오버헤드를 가장 잘 줄이면서 사전판매 이벤트를 지원할 수 있습니까?

문제 분석

핵심 개념: 이 문제는 컨테이너, 스트리밍, 데이터베이스 read 스케일링, 엣지/정적 콘텐츠 전송에 대해 운영 작업 부담을 줄이면서 탄력적 확장을 제공하는 현대화 선택지를 평가합니다. 주요 managed 서비스: AWS Fargate가 포함된 Amazon EKS, Amazon MSK, Amazon RDS read replica, 그리고 Amazon CloudFront + Amazon S3. 정답이 맞는 이유: 현재 상태는 운영 부담이 큽니다: public IP가 있는 EC2에서 자체 관리형 컨테이너를 운영하고, 자체 관리형 Kafka 클러스터도 EC2에서 운영합니다. 72시간 동안 5배 급증이 예측되는 상황에서, 최선의 접근은 빠르고 예측 가능하게 확장되는 managed 서비스로 차별화되지 않는 운영 작업을 이전하는 것입니다. 옵션 D는 마이크로서비스에 대해 EKS on Fargate로 EC2 인스턴스 관리를 대체하여(노드 프로비저닝/패치/용량 계획 불필요) autoscaling(HPA/KEDA와 ALB ingress)을 지원해 급증 트래픽을 처리합니다. 또한 자체 관리형 Kafka를 Amazon MSK로 대체하여 Kafka API를 유지하면서 브로커 프로비저닝, 패치, 복구에 대한 운영 부담을 제거합니다. 데이터베이스의 경우, RDS for PostgreSQL read replica 추가가 티켓 탐색/검색과 같이 read가 많은 급증 상황에서 가장 직접적으로 관련된 스케일링 수단입니다. Multi-AZ는 주로 가용성을 개선하며 read 처리량을 늘리는 것이 아닙니다. 마지막으로, CloudFront 뒤의 S3로 정적 자산을 제공하면 오리진 트래픽을 오프로딩하고 전국 단위 지연 시간을 줄이며 스파이크를 흡수합니다. 주요 AWS 기능: - EKS on Fargate: Pod를 위한 serverless compute, ALB Ingress Controller / AWS Load Balancer Controller와 통합, Cluster Autoscaler 대안(Fargate profiles) 및 pod autoscaling 지원. - Amazon MSK: managed Kafka control plane, 자동 패치, 모니터링 통합, 자체 관리형 EC2 브로커보다 쉬운 스케일링. - RDS read replica: 수평 read 스케일링; 필요 시 promote 가능. - S3 + CloudFront: 캐싱, origin shielding, 높은 request rate 처리. 흔한 오해: - “Multi-AZ는 스케일링이다”: Multi-AZ는 failover/가용성을 개선하지만 read 용량을 늘리지는 않습니다(Aurora의 reader endpoint를 사용하는 경우는 예외지만, 여기서는 RDS PostgreSQL입니다). - “Kinesis는 Kafka의 드롭인 대체재다”: Kinesis는 훌륭하지만 애플리케이션 변경과 운영 재작업이 필요합니다. MSK가 자체 관리형 Kafka에서 가장 가까운 lift-and-shift 대안입니다. - “ALB 뒤의 ASG면 충분하다”: 여전히 컨테이너 오케스트레이션과 Kafka 운영을 EC2에서 수행해야 하므로, 운영 부담 최소화 목표와 충돌합니다. 시험 팁: 프롬프트가 스파이크 동안 운영 오버헤드 최소화를 강조하면 managed/serverless 옵션(Fargate, MSK, CloudFront)을 우선하고, 병목에 맞는 스케일링 메커니즘(read 급증에는 read replica, 정적 콘텐츠에는 캐싱)을 선택하십시오. 또한 “self-managed Kafka” 단서를 주의 깊게 보십시오—Kafka 호환성이 중요할 때 MSK가 AWS의 정석 managed 대체재입니다.

문제 13

한 fintech 기업이 co-location facility의 Windows VM에서 리스크 분석 도구를 실행하고 있으며, 이 도구는 SMB를 통해 65 TB 공유 파일 리포지토리를 읽고 쓰고, 평균 일일 변경량은 약 100 GB입니다. 기업은 내구성과 비용을 위해 공유 스토리지를 Amazon S3로 이전하려고 하지만, 애플리케이션이 native S3 API를 사용하도록 리팩터링되는 것은 4개월 후에나 가능합니다. 이 기간 동안 on-premises 애플리케이션은 최소한의 클라이언트 변경으로 SMB를 통해 동일한 데이터셋에 계속 액세스해야 하며, cutover는 AWS에서 file server를 실행할 필요가 없어야 합니다. solutions architect는 마이그레이션 중과 이후에도 on premises에서 중단 없는 SMB 액세스를 보장하면서 데이터를 새로운 S3 위치로 마이그레이션해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 애플리케이션을 리팩터링하지 않고, 그리고 AWS에서 file server를 실행하지 않으면서, 궁극적으로는 내구성이 높고 비용 효율적인 Amazon S3에 저장되는 데이터에 대해 SMB/NFS 파일 액세스를 제공하는 방법을 테스트합니다. 핵심 서비스는 AWS Storage Gateway (File Gateway)로, on-premises 클라이언트에 SMB file share를 제공하면서 객체를 S3에 저장합니다. 정답인 이유: 기업은 데이터셋이 지금은 S3에 존재하길 원하지만, Windows VM은 약 4개월 동안 최소한의 클라이언트 변경으로 SMB를 계속 사용해야 합니다. AWS Storage Gateway file gateway는 on premises에 VM으로 배포할 수 있으며 S3 bucket을 백엔드로 하는 SMB share를 노출할 수 있습니다. 애플리케이션은 SMB를 통해 동일한 데이터에 계속 액세스하며(일반적으로 UNC path를 gateway share로 재지정), gateway는 파일을 투명하게 S3 object로 저장합니다. 이는 SMB server endpoint가 EC2 기반 file server가 아니라 on-premises gateway VM이므로 “AWS에서 file server를 실행하지 않음” 제약을 충족합니다. 주요 AWS 기능: File Gateway는 SMB share를 지원하고, 인증/인가를 위해 Active Directory와 통합되며, hot data에 대한 저지연 액세스를 위해 local cache를 사용하면서 비동기적으로 S3에 업로드합니다. 대규모 데이터셋과 incremental change(100 GB/일)를 효율적으로 지원합니다. 초기 데이터 복사는 기존 SMB 리포지토리에서 gateway SMB share로 복사(또는 Robocopy 같은 도구 사용)하여 수행할 수 있으며, 이후에는 gateway를 통해 지속적인 액세스가 이루어지고 S3가 system of record가 됩니다. 흔한 오해: FSx for Windows File Server(옵션 A)는 SMB를 제공하지만 데이터는 S3가 아니라 FSx(EBS-backed)에 저장되며, AWS에서 관리형 file server를 실행하는 것이므로 명시적으로 허용되지 않습니다. S3로 직접 복사(옵션 B)는 앱이 리팩터링되지 않는 한 SMB 액세스를 깨뜨립니다. file server를 EC2로 lift-and-shift(옵션 C)하는 것은 “AWS에서 file server를 실행할 필요가 없어야 함” 요구 사항을 위반하며 운영 오버헤드를 추가합니다. 시험 팁: “SMB/NFS 클라이언트를 변경하지 않음” + “S3에 저장” + “리팩터링 없음”을 보면 Storage Gateway File Gateway를 떠올리세요. “AWS에서 SMB”와 Windows semantics가 필요하면 FSx for Windows를 떠올리되, S3 backing 여부와 AWS에서 file system을 실행하는 것이 허용되는지 제약을 확인하세요.

문제 14

AWS Organizations에서 blueOrg (orgA)라는 organization 하에 운영되는 독립적인 cybersecurity auditing firm은, 별도의 organization인 greenOrg (orgB)에 속한 고객의 AWS account에 programmatically access하여, 해당 업체의 management account에서 4시간마다 automated compliance scanner를 실행해야 합니다. 이 스캐너는 temporary credentials와 least privilege를 사용하여 EC2 Describe*, IAM Get*, S3 List* metadata만 읽습니다. API/CLI를 통해 orgA가 orgB의 resources에 access할 수 있도록 하는 가장 secure한 방법은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 서로 다른 AWS Organizations 간의 secure cross-account access를 AWS STS AssumeRole, least-privilege IAM roles, 그리고 confused deputy protection 메커니즘(ExternalId)을 사용해 구현하는지를 평가합니다. 또한 best practices(장기 credentials 회피, temporary credentials 사용, trust 및 permissions의 엄격한 범위 지정)를 간접적으로 테스트합니다. 정답이 맞는 이유: Option D는 third-party auditor가 고객 account에 programmatically access하는 가장 secure한 패턴입니다. 고객은 orgB(고객 account)에 필요한 read-only permissions(EC2 Describe*, IAM Get*, S3 List*)만 가진 IAM role을 생성합니다. role의 trust policy는 orgA의 auditor AWS account가 role을 assume할 수 있도록 허용하되, auditor가 고유한 ExternalId를 제공하는 경우에만 허용합니다. auditor는 management account에서 4시간마다 sts:AssumeRole을 호출하여 short-lived credentials를 획득합니다. 이는 temporary credentials, least privilege, 그리고 unauthorized role assumption에 대한 강력한 보호를 모두 충족합니다. 주요 AWS 기능: 1) IAM Role + Trust Policy: trust policy는 principal(auditor account)과 조건(sts:ExternalId)을 지정합니다. 선택적으로 고객은 aws:PrincipalArn을 사용해 auditor account 내의 특정 role로 더 제한할 수 있습니다. 2) AWS STS Temporary Credentials: AssumeRole은 시간 제한이 있는 credentials를 반환하여 blast radius를 줄이고 key rotation 부담을 제거합니다. 3) Confused Deputy 완화: ExternalId는 third party가 고객 account에 access할 때 AWS가 권장하는 control로, auditor가 속아 다른 고객의 role에 access하도록 자신의 permissions를 사용하게 되는 것을 방지합니다. 4) Least Privilege Permissions Policy: actions를 ec2:Describe*, iam:Get*, s3:List*로 제한하고 가능하면 resources 범위를 지정합니다(모든 action이 resource-level constraints를 지원하는 것은 아님). 흔한 오해: Option C(ExternalId 없는 role)는 users/keys보다 낫지만, 핵심 third-party security control이 빠져 있어 독립 업체 시나리오에서 “MOST secure”는 아닙니다. Options A와 B는 long-term credentials에 의존하므로 best practices를 위반하고 leakage 및 misuse 위험을 증가시킵니다. 시험 팁: “third-party access”, “temporary credentials”, “least privilege”가 보이면: 고객이 IAM role을 만들고 auditor가 STS로 assume하는 패턴을 떠올리세요. vendor/independent auditor라면 trust policy에 ExternalId를 추가하세요. access keys 공유는 피해야 합니다. 이는 AWS IAM guidance 및 Well-Architected Security Pillar 원칙(identity foundation, least privilege, credential management)과 일치합니다.

문제 15

유전체학 연구 컨소시엄이 북미와 유럽 전역의 지역 실험실에 규제 대상 데이터 주석(Annotation) 서비스를 제공합니다. 이 서비스는 단일 AWS Organizations organization에서 중앙 관리되는 30개 이상의 멤버 account 전반에 걸쳐 전적으로 AWS에서 실행됩니다. 워크로드는 활성화된 모든 Region에 배포되며, 매월 새로운 account가 추가됩니다. 감사 및 규제 요구 사항을 위해, 현재 및 향후 모든 account와 Region 전반의 AWS resource에 대한 모든 API call을 기록하고 변경 사항을 추적해야 하며, 저장 데이터 암호화(encryption at rest)와 함께 7년 동안 내구적이고 안전하게 저장해야 합니다. 로그는 변경 불가능(실수로 삭제되더라도 복구 가능)해야 하며, 서드파티 도구를 도입하지 않으면서 지속적인 운영 노력을 최소화해야 합니다. 가장 적은 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 AWS Organizations의 모든 기존 및 새로 추가되는 AWS accounts 전반에서 AWS CloudTrail을 사용해 중앙 집중식의 조직 전체 AWS API activity logging을 구현하고, 로그를 장기 보관을 위해 암호화 및 실수로 인한 삭제 방지와 함께 안전하게 저장하면서, 운영 오버헤드를 최소화하는 것에 관한 것입니다. 정답인 이유: management account에서 생성한 AWS CloudTrail organization trail은 AWS Organizations 조직의 모든 member accounts에 자동으로 적용되도록 특별히 설계되었습니다. trail을 multi-Region으로 구성하면 모든 활성화된 Regions 전반에서 logging을 제공하고, Amazon S3 bucket으로 중앙 전달하면 내구성이 높고 운영 부담이 적은 스토리지를 제공합니다. S3 encryption at rest를 활성화하면 암호화 요구 사항을 충족하고, S3 Versioning과 MFA Delete는 이전 object versions의 복구를 가능하게 하여 실수로 인한 삭제를 방지하는 데 도움이 됩니다. 이것은 보기 중에서 운영 효율성이 가장 높은 기본 AWS 솔루션입니다. 주요 기능: - CloudTrail organization trail은 현재 및 미래의 member accounts를 자동으로 포함합니다. - Multi-Region trail은 모든 활성화된 Regions의 events를 기록합니다. - 중앙 집중식 S3 storage는 장기 보관과 간소화된 audit access를 지원합니다. - S3 Versioning과 MFA Delete는 실수로 인한 삭제 및 덮어쓰기에 대해 강력한 보호를 제공합니다. - S3 server-side encryption은 encryption at rest에 대한 compliance 요구 사항을 지원합니다. 흔한 오해: management account의 표준 trail은 모든 member accounts의 events를 자동으로 수집하지 않으며, organization trail이어야 합니다. 각 account에 별도의 trails를 생성하는 것도 기술적으로는 가능하지만, 불필요한 운영 부담과 configuration drift 위험을 초래합니다. 또한, Versioning과 MFA Delete는 복구 가능성을 향상시키지만, 문제에서 엄격한 WORM immutability를 명시적으로 요구했다면 S3 Object Lock이 더 강력한 기능입니다. 다만 여기서는 정답 선택지에 포함되어 있지 않습니다. 시험 팁: 문제에서 AWS Organizations와 현재 및 미래의 accounts를 언급하면 CloudTrail organization trails와 같은 organization-level services를 우선 고려하세요. 중앙 집중식 audit logging의 경우, encryption 및 retention controls가 있는 전용 S3 bucket을 찾으세요. 한 account의 일반적인 trail이 조직 전체를 자동으로 포괄한다고 가정하지 않도록 주의하고, Versioning/MFA Delete와 같은 복구 가능성 제어와 Object Lock과 같은 진정한 immutable retention controls를 구분하세요.

문제 16

한 피트니스 분석 스타트업은 모바일 앱의 운동 리더보드를 구동하는 serverless REST API를 노출하고 있으며, 스택은 Regional endpoint를 사용하는 Amazon API Gateway API, AWS Lambda functions, 그리고 Amazon Aurora PostgreSQL Serverless v2 DB cluster로 구성되어 있습니다. 여러 wearable-device 파트너를 온보딩한 후 요청 볼륨이 급증했고, DB에서 간헐적인 out-of-memory 및 scaling pressure 이벤트가 보고되기 시작했습니다. 트래픽 분석 결과, 클라이언트가 30–90초 내에 동일한 리더보드 쿼리에 대해 동일한 HTTP GET 요청을 다수 발행하고 있으며, 트래픽의 70%가 현지 시간 09:00–18:00 사이에 발생하고, New Year 프로모션과 마라톤 이벤트 동안 3배 스파이크가 발생합니다. 회사는 추가 사용량을 지원하면서도 증분 비용과 운영 복잡성을 최소화해야 합니다. 어떤 전략이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 API 계층의 가장 앞단에서 캐싱을 적용하여 serverless 백엔드에 대한 반복적인 읽기 부하를 줄이는, 가장 단순하고 비용 효율적인 방법을 선택하는지를 테스트합니다. 핵심 서비스 기능은 REST APIs(Regional endpoint)에 대한 Amazon API Gateway stage-level caching으로, GET 요청의 응답을 캐시하여 Lambda 호출과 다운스트림 DB 쿼리를 크게 줄일 수 있습니다. 정답이 맞는 이유: 워크로드는 30–90초 내에 동일한 리더보드 쿼리에 대해 동일한 GET 요청이 많이 발생합니다. 짧은 TTL(예: 60초)로 API Gateway caching을 활성화하면 이 패턴을 직접적으로 겨냥할 수 있습니다. TTL 내의 반복 요청은 캐시에서 제공되므로 Lambda 실행과 Aurora Serverless v2 읽기를 피할 수 있습니다. 이는 DB의 메모리 압박과 scaling 이벤트를 줄이면서도 증분 비용과 운영 복잡성을 최소화합니다. 또한 일중 트래픽 패턴과 이벤트 스파이크에도 부합합니다. 캐싱은 애플리케이션 코드 변경 없이도 버스트성 읽기 트래픽을 흡수합니다. 주요 AWS 기능: API Gateway REST API caching은 stage 단위로 구성되며, cache size, TTL, cache key 파라미터(예: query string parameters, headers, path parameters)를 설정하여 리더보드(예: leaderboardId, time window, region)별로 올바르게 캐시를 분리할 수 있습니다. 또한 methods별로 선택적으로 캐싱을 활성화할 수 있고, 필요 시 authorization 설정이 cache keys에 반영되도록 할 수 있습니다. 이는 전형적인 “compute 및 database 앞단에 cache를 두는” 패턴이며, 불필요한 작업을 줄여 Well-Architected 비용 최적화를 지원합니다. 흔한 오해: ElastiCache(옵션 B)는 강력하지만 운영 오버헤드(cluster sizing, scaling, patching, VPC networking)가 추가되고, 코드 변경과 cache invalidation 전략이 필요하여 30–90초 내의 단기 동일 GET에 비해 불필요하게 복잡합니다. Aurora capacity 증가(옵션 C)는 중복 읽기를 줄이기보다 스파이크 동안 더 많은 compute/memory 비용을 지불하는 방식으로 증상을 완화합니다. Throttling(옵션 D)은 백엔드를 보호하지만 사용자 경험을 저하시키며 “추가 사용량 지원”을 충족하지 못합니다. 시험 팁: “동일한 GET이 많음”, “짧은 시간 창”, “비용/복잡성 최소화”가 보이면 요청 경로에 가장 가까운 managed caching(API Gateway caching 또는 해당되는 경우 CloudFront)을 우선 고려하십시오. DB capacity 확장은 보통 회피 가능한 부하를 제거하고 캐싱 계층을 추가한 이후의 2차 선택입니다. Throttling은 수요 충족이 아니라 보호를 위한 것입니다.

문제 17

한 ad-tech 스타트업이 Amazon API Gateway와 AWS Lambda로 메트릭 수집 API를 구축하고 있습니다. Python 3.11로 작성된 12개의 Lambda 함수 전반에서, 팀은 중앙 플랫폼 팀이 유지 관리하는 5개의 내부 라이브러리와 커스텀 클래스(압축 시 약 15 MB)를 재사용해야 합니다. 보안 팀은 프로덕션 배포가 승인된 레지스트리에서만 아티팩트를 가져오도록 요구합니다. Amazon ECR은 승인되었지만, 빌드 작업은 프로덕션 계정에서 S3로 아티팩트를 업로드할 수 없습니다. 솔루션스 아키텍트는 모든 함수에 대한 배포를 단순화하고, 최소한의 패키징 복잡도로 코드 재사용을 극대화해야 합니다. 어떤 접근 방식이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 AWS Lambda 배포 패키징 선택( ZIP vs container images), 코드 재사용 전략(layers vs 공유 base images), 그리고 공급망 제어(예: Amazon ECR과 같은 승인된 아티팩트 레지스트리)를 테스트합니다. 또한 여러 함수에 걸친 Lambda 제한과 운영 단순성도 간접적으로 테스트합니다. 정답인 이유: Option D가 모든 제약을 가장 잘 충족합니다. 보안 팀은 프로덕션 배포가 승인된 레지스트리(ECR 승인)에서만 아티팩트를 가져오도록 요구하며, 빌드 작업은 프로덕션 계정에서 S3로 아티팩트를 업로드할 수 없습니다. Lambda의 container image 지원을 사용하면 각 함수의 배포 패키지가 ECR에 저장된 OCI image가 되어, 프로덕션 계정의 S3에 ZIP 또는 layer 아티팩트를 둘 필요가 없습니다. 코드 재사용은 15 MB(압축) 내부 라이브러리와 공유 클래스를 포함하는 공통 base image로 표준화하여 달성하며, 각 함수 image는 handler 코드만 추가합니다. 이 접근 방식은 공유 의존성을 base image에서 한 번만 관리하고 일관되게 상속하므로 12개 함수에 대한 패키징 복잡도를 최소화합니다. 주요 AWS 기능: - Amazon ECR에 저장된 image로 AWS Lambda container image 지원(최대 10 GB image size). - 재사용을 극대화하고 중복을 줄이기 위한 Docker multi-stage builds 및 공유 base image 패턴. - 거버넌스 및 보안 요구 사항을 충족하기 위한 ECR repository policies, image scanning, immutable tags, lifecycle policies. - CI/CD가 image를 빌드하여 ECR에 push하고, 배포는 Lambda function image URI/digest를 업데이트. 흔한 오해: A와 B는 Lambda layers가 전통적인 재사용 메커니즘이기 때문에 매력적으로 보일 수 있습니다. 그러나 Lambda layers는 설명된 방식처럼 “ECR의 Docker image로부터” 생성되지 않습니다. layers는 ZIP archives로 게시됩니다(일반적으로 Lambda에 업로드되며, 배포 도구에서는 종종 S3를 소스로 사용). 또한 A는 S3를 아티팩트 저장소로 사용하므로 “승인된 레지스트리” 요구 사항을 위반하고, B는 ECR이 layer를 직접 백엔드로 제공할 수 있다고 잘못 가정합니다. C는 Lambda가 실행 중인 ECS/Fargate container를 layer로 참조할 수 없기 때문에 틀립니다. layers는 네트워크로 연결된 런타임 의존성 서비스가 아니라 정적 아티팩트입니다. 시험 팁: “승인된 레지스트리 = ECR” 및 S3 아티팩트 업로드 제한을 보면 Lambda container images를 강하게 고려하십시오. ZIP 기반 함수에는 layers를 사용하지만, 엄격한 레지스트리 기반 공급망 제어와 단순화된 의존성 재사용을 위해서는 ECR의 공유 base image가 종종 가장 깔끔한 패턴입니다. 또한 기억하십시오: Lambda layers는 ZIP 기반이며, Lambda container images는 ECR에서 pull됩니다.

문제 18

한 디자인 스튜디오는 1,200명의 직원이 원격으로 근무할 수 있도록 지원하고 있으며, 최대 300명의 동시 사용자가 4개의 AWS account에 걸쳐 6개의 VPC에 배포된 내부 워크로드에 안전하게 액세스할 수 있도록 확장 가능하고 비용 효율적인 AWS Client VPN 솔루션이 필요합니다. 공유 네트워킹(hub) account에는 이미 5개의 spoke VPC와 피어링되어 있고 CIDR 블록이 서로 겹치지 않는 hub VPC가 호스팅되어 있으며, 현재 기업 네트워크는 단일 AWS Site-to-Site VPN을 통해 hub VPC에 연결됩니다. 또한 이 솔루션은 원격 사용자가 모든 VPC의 애플리케이션에 도달할 수 있도록 하면서 월별 비용을 최소화해야 합니다.

문제 분석

핵심 개념: 이 문제는 AWS Client VPN을 multi-account, multi-VPC 원격 액세스를 위해 중앙 집중화할 수 있는지와, 확장 가능한 라우팅을 위해 어떤 네트워크 구성이 필요한지를 테스트합니다. 핵심 포인트는 VPC peering이 non-transitive라는 점이므로, hub VPC와 연결된 Client VPN endpoint의 트래픽이 peering connection을 통해 spoke VPC들로 단순히 전달될 수 없다는 것입니다. 단일 Client VPN endpoint에서 여러 VPC와 account 전반의 workload에 원격 사용자 액세스를 제공하려면 AWS Transit Gateway와 같은 transit routing service가 필요합니다. 정답인 이유: shared networking account에 단일 Client VPN endpoint를 두고 AWS Transit Gateway를 함께 사용하는 설계가 올바른 설계입니다. Transit Gateway는 여러 VPC와 account 전반에서 중앙 집중식의 transitive routing을 지원하기 때문입니다. Client VPN endpoint는 hub VPC의 subnet들과 연결되고, 해당 VPC는 Transit Gateway에 attach되며, 다른 account의 각 spoke VPC도 Transit Gateway에 attach됩니다. 적절한 route propagation과 authorization rule을 구성하면 원격 사용자는 하나의 VPN endpoint를 통해 6개의 모든 VPC에 있는 애플리케이션에 액세스할 수 있습니다. Transit Gateway는 비용이 추가되지만, 제시된 선택지 중 단일의 확장 가능한 endpoint로 연결 요구 사항을 충족하는 유일한 옵션입니다. 주요 AWS 기능 / 구성: - shared networking account의 subnet들과 연결된 AWS Client VPN endpoint. - account 전반의 hub VPC와 각 spoke VPC에 대한 AWS Transit Gateway attachment. - Client VPN client CIDR와 모든 VPC CIDR가 상호 도달 가능하도록 구성된 Transit Gateway route table. - 필요한 대상 CIDR에 대한 Client VPN authorization rule. - Client VPN client CIDR의 트래픽을 허용하도록 업데이트된 security group과 network ACL. 흔한 오해: - VPC peering이 중앙 집중식 Client VPN endpoint에서 peered VPC들로의 액세스를 허용한다고 가정하는 것. 그렇지 않습니다. peering은 transitive routing을 지원하지 않기 때문입니다. - 기존 Site-to-Site VPN을 원격 사용자가 모든 AWS VPC에 도달하는 경로로 재사용할 수 있다고 생각하는 것. 이는 핵심 라우팅 제한을 해결하지 못하며, 이 사용 사례를 위해 Client VPN이 설계된 방식도 아닙니다. - 가장 저렴해 보이는 옵션이 자동으로 정답이라고 가정하는 것. 라우팅 요구 사항을 충족하지 못하면 유효한 솔루션이 아닙니다. 시험 팁: 여러 account에 걸친 많은 VPC에 대한 중앙 집중식 원격 액세스가 보이면, 기존 네트워크가 peering 기반인지 Transit Gateway 기반인지 즉시 확인하세요. 하나의 VPN endpoint를 사용하는 hub-and-spoke 원격 액세스에서는 Transit Gateway가 보통 필요한 서비스입니다. transitive routing을 지원하기 때문입니다. 시험에서는 VPN client와 다른 VPC 사이의 transit에 VPC peering을 의존하는 답안을 제거하세요.

문제 19

한 디지털 출판 회사가 세 개의 퍼블릭 서브넷에 걸쳐 배포된 Application Load Balancer (ALB) 뒤의 세 개 프라이빗 서브넷에서 Amazon ECS Fargate task로 콘텐츠 API를 실행하고 있다. 단일 Amazon CloudFront distribution이 ALB를 유일한 origin으로 사용하며, 회사는 direct-to-origin 트래픽을 모두 차단하면서 CloudFront에서 기원한 요청만 허용해야 한다. 또한 최소 30일마다 자동화된 shared-secret rotation이 필요하고, static IP allow list에 의존해서는 안 된다. origin 보안을 강화하기 위해 solutions architect는 무엇을 해야 하는가?

문제 분석

핵심 개념: 이 문제는 ALB origin에 대한 CloudFront origin 보호 패턴을 테스트하며, static IP allow list를 사용하지 않고 실제로 CloudFront를 통해 들어온 요청만 허용하면서 direct-to-origin 액세스를 방지하고, 자동화된 secret rotation(최소 30일마다)을 요구한다. 핵심 서비스는 CloudFront (custom origin header), AWS WAF (L7에서 header 기반 allow/deny), AWS Secrets Manager (관리형 secret rotation)이다. 정답이 맞는 이유: Option A는 shared-secret 기반의 “origin verification” 메커니즘을 구현한다. CloudFront가 모든 origin 요청에 custom HTTP header를 주입하고, ALB에 연결된 AWS WAF가 기대하는 header 값이 포함된 요청만 허용한다. ALB를 직접 호출하는 클라이언트는 secret header 값을 알 수 없으므로 차단된다. Secrets Manager와 rotation Lambda를 사용하면 최소 30일마다 자동 rotation 요구사항을 충족한다. 이 방식은 static IP allow list를 전혀 사용하지 않으며 CloudFront edge IP가 변경되어도 동작한다. 주요 AWS 기능: - CloudFront custom origin headers: CloudFront는 ALB origin으로 전송되는 요청에 header(예: X-Origin-Verify)를 추가할 수 있다. - ALB에 대한 AWS WAF web ACL: rule로 header 존재 및 값 일치(string match)를 요구할 수 있다. 기본 동작을 block으로 두고, 일치하는 요청에 대한 allow rule을 둘 수 있다. - AWS Secrets Manager rotation: Lambda rotation function과 함께 native rotation scheduling을 사용해 주기적으로 secret을 업데이트할 수 있다. 운영 측면에서는 secret이 rotation될 때 CloudFront origin custom header 값도 업데이트해야 하며(보통 automation/CI/CD 또는 EventBridge-triggered workflow로 처리), 이를 통해 동기화한다. 흔한 오해: - “CloudFront IP만 허용” (B/D)는 문제에서 명시적으로 금지되어 있으며, CloudFront IP range는 변경되고 수가 많아 취약하고 운영 부담이 크다. - “ALB를 프라이빗 서브넷에 배치” (B)는 internet-facing ALB에 대한 유효한 구성으로 보기 어렵다. internal ALB는 프라이빗일 수 있지만, CloudFront가 origin에 도달할 수 있도록 일반적으로 퍼블릭 internet-facing endpoint 또는 다른 지원되는 연결 패턴이 필요하다. - “ALB listener rule로 header 검사” (C)는 보안 통제로서 지원되는 방식이 아니다. ALB listener rule은 header 기반 라우팅은 가능하지만 WAF 기반 차단을 대체할 수 없고, Parameter Store는 Secrets Manager처럼 임의 string에 대한 automatic rotation을 제공하지 않는다. 시험 팁: CloudFront-to-ALB origin 잠금(lockdown)에서는 “custom header + WAF header match”가 정석 패턴이다. rotation 요구가 있으면 임시방편보다 Secrets Manager rotation을 우선 고려하라. IP allow list를 금지하면 CloudFront IP range 또는 security group IP 정책에 의존하는 선택지는 제거하라.

문제 20

한 의료 분석 회사가 AWS에서 환자 텔레메트리 플랫폼을 설계하고 있으며, 약 9 TB의 관계형 데이터를 저장해야 하고 RPO 4분 미만 및 RTO 12분 미만을 충족해야 합니다. 또한 가능한 한 낮은 비용으로 보조 AWS Region으로 장애 조치(fail over)해야 한다는 요구 사항을 준수해야 합니다. 팀은 어떤 솔루션을 선택해야 합니까?

문제 분석

핵심 개념: 이 문제는 비용을 최소화하면서 4분 미만의 엄격한 RPO와 12분 미만의 RTO를 충족해야 하는 대규모 relational PostgreSQL 워크로드를 위한 cross-Region disaster recovery 아키텍처를 선택하는 것에 관한 것입니다. 핵심은 복구 목표와 운영 복잡성, 그리고 secondary Region을 준비 상태로 유지하는 비용 사이의 균형을 맞추는 것입니다. Aurora PostgreSQL은 snapshot 기반 복구보다 더 빠른 replication 및 failover 특성을 위해 설계되었으며, 분 단위 RPO를 달성하려면 continuous replication 사용이 필요합니다. 정답인 이유: primary Region에서 Aurora PostgreSQL cluster를 실행하고 secondary Region에서 또 다른 cluster를 AWS DMS replication과 함께 실행하면 요구되는 RPO와 RTO를 충족할 수 있는 active warm standby 패턴이 만들어집니다. secondary database는 이미 프로비저닝되어 있으므로 failover 시 snapshot과 관련된 긴 restore 시간을 피할 수 있습니다. backup-and-restore 방식과 비교하면, 이 설계는 4분 미만 RPO와 12분 미만 RTO 요구 사항을 모두 충족할 가능성이 훨씬 높습니다. 주요 기능: Aurora는 고성능과 빠른 복구 동작을 제공하는 관리형 PostgreSQL 호환 relational storage를 제공합니다. AWS DMS는 source와 동기화된 상태를 유지하도록 다른 Region의 target database로 ongoing replication을 지원합니다. target database가 이미 secondary Region에서 실행 중이므로, 팀은 disaster 발생 시 애플리케이션을 cut over하고 최종 replication 상태만 검증하면 됩니다. 흔한 오해: Snapshot copying은 종종 엄격한 RPO/RTO를 충족할 수 있는 DR 솔루션으로 오해되지만, snapshot은 본질적으로 backup 산출물이며 9 TB를 restore하는 것은 너무 느립니다. same-Region replica는 cross-Region compliance 요구 사항을 충족하지 않습니다. 표준 RDS PostgreSQL의 cross-Region read replica도 유용할 수 있지만, 매우 큰 database와 엄격한 분 단위 목표의 경우 Aurora 기반 아키텍처가 일반적으로 더 적합합니다. 시험 팁: 매우 낮은 RPO와 RTO가 함께 제시되고 cross-Region 요구 사항도 있다면, 먼저 snapshot/restore 옵션을 제거하세요. 그런 다음 warm standby 또는 continuously replicated 아키텍처를 비교하세요. 또한 문제에서 단순히 전체적으로 가장 저렴한 옵션이 아니라, 목표를 여전히 충족하는 솔루션 중 가장 낮은 비용을 묻는지에도 주의하세요.