연습 문제

문제 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

디지털 교육 플랫폼이 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을 사용하십시오.

문제 3

유전체학 연구 컨소시엄이 북미와 유럽 전역의 지역 실험실에 규제 대상 데이터 주석(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를 구분하세요.

문제 4

(2개 선택)

한 교육 기술 회사가 이번 분기에 1주일간의 글로벌 가상 해커톤을 호스팅할 준비를 하고 있다. 플랫폼은 Amazon EC2의 웹 및 애플리케이션 티어 앞단에 Application Load Balancer를 사용하고 Amazon Aurora PostgreSQL 데이터베이스를 사용한다. 페이로드의 약 70%는 정적 자산이며 요청의 약 95%는 읽기 전용이다. 회사는 이벤트 기간 동안 북미, 유럽, APAC에서 트래픽이 15배 급증할 것으로 예상하며, 전 세계 사용자를 대상으로 p95 응답 시간을 최소화하려고 한다. 전 세계적으로 시스템 응답 시간을 줄이기 위해 솔루션스 아키텍트가 수행해야 할 단계 조합은 무엇인가? (두 개 선택)

문제 분석

핵심 개념: 이 문제는 읽기 비중이 높고 정적 콘텐츠 비중이 높은 웹 애플리케이션의 글로벌 성능 최적화를 테스트한다. 즉, 엣지 캐싱(Amazon CloudFront), 글로벌 트래픽 스티어링(Route 53 latency-based routing), multi-Region 애플리케이션 배포, 그리고 낮은 지연의 cross-Region 데이터베이스 읽기(Aurora Global Database)를 활용하는 것이다. 정답이 맞는 이유: 15배의 글로벌 트래픽 급증과 전 세계 사용자를 고려할 때, p95 지연의 가장 큰 요인은 네트워크 거리와 오리진 부하다. 옵션 E는 CloudFront를 통해 약 70%의 정적 자산을 엣지 로케이션에서 캐싱하고, Route 53 latency-based routing으로 사용자를 가장 가까운 정상 Region으로 보내 즉시 지연을 줄인다. Auto Scaling 그룹은 동적 컴퓨팅에 대한 급증을 처리한다. 옵션 D는 남아 있는 병목인 데이터베이스 읽기(95% 읽기 전용)를 해결한다. Aurora Global Database는 낮은 지연의 물리적 replication으로 cross-Region 읽기를 제공하므로, 각 Region의 애플리케이션 티어가 단일 writer Region까지 대양을 가로질러 요청하지 않고 로컬(또는 준로컬)에서 읽을 수 있다. 정적 자산을 S3에 저장하고 cross-Region replication을 적용하면 multi-Region 오리진과 복원력을 지원하며, multi-Region 웹/앱 티어는 동적 요청의 RTT를 줄인다. 주요 AWS 기능 / 모범 사례: - CloudFront: 정적 콘텐츠 캐시, 오리진 부하 감소, 전 세계 p95 개선; 적절한 cache key를 사용하면 일부 동적 콘텐츠도 캐시 가능. - Route 53 latency-based routing: 가장 낮은 지연의 Region으로 사용자를 유도하며, 일반적으로 health check와 함께 사용. - Aurora Global Database: 1개의 primary writer Region과 최대 5개의 secondary Region을 빠른 물리적 replication으로 구성; secondary Region의 reader endpoint를 사용해 읽기 확장. - Auto Scaling을 통한 multi-Region active/active(웹/앱): 스파이크를 흡수하고 사용자-오리진 간 지연을 감소. 흔한 오해: - “Direct Connect만 추가” (옵션 B)는 인터넷 사용자를 돕지 않는다. 이는 온프레미스에서 AWS로의 프라이빗 연결을 위한 것이다. - “S3 cross-Region replication만” (옵션 A)은 내구성/DR에는 도움이 되지만 엣지 캐싱을 제공하지 않는다. 또한 “웹 티어를 S3로 교체”는 정적 웹사이트에만 해당하며 동적 앱/API 요구를 해결하지 못한다. - “RDS for PostgreSQL/private subnet으로 이동” (옵션 C)은 글로벌 지연을 개선하지 않으며 유연성을 떨어뜨릴 수 있다. 시험 팁: 글로벌 사용자 + 정적 콘텐츠 비중이 높으면 먼저 CloudFront를 떠올려라. 읽기 비중이 높은 데이터베이스 + multi-Region 요구가 보이면 Aurora Global Database(또는 read replica)와 Route 53 latency-based routing을 생각하라. 최적의 p95 개선을 위해 캐싱 + multi-Region 컴퓨팅 + cross-Region 읽기 전략을 결합하라.

문제 5

(2개 선택)

한 핀테크 회사가 레거시 리포팅 플랫폼을 타사 호스팅 시설에서 AWS로 이전하고 있습니다. 이 플랫폼은 단일 Linux 애플리케이션 서버 VM(Nginx 및 Java 서비스) 1대와 별도의 VM에 있는 PostgreSQL 12 데이터베이스로 구성되어 있으며, 각 VM은 총 420 TB에 달하는 여러 개의 연결된 볼륨을 사용합니다. 회사는 가장 가까운 AWS Region으로 연결되는 전용 10 Gbps AWS Direct Connect 링크를 보유하고 있으며 현재 다른 워크로드에서 사용되지 않습니다. 비즈니스 요구 사항은 마이그레이션 컷오버 다운타임을 30분 미만으로 유지하는 것이며, 마이그레이션 후 데이터베이스는 Amazon RDS for PostgreSQL에서 실행되기를 원합니다. 다운타임을 최소화하면서 워크로드를 마이그레이션하기 위해 솔루션스 아키텍트가 수행해야 할 단계 조합은 무엇입니까? (두 개 선택)

문제 분석

핵심 개념: 이 문제는 매우 큰 데이터 볼륨, 엄격한 cutover downtime 목표, 그리고 데이터베이스를 Amazon RDS for PostgreSQL로 현대화해야 한다는 요구 사항 사이에서 균형을 맞추는 migration 메커니즘을 선택하는지를 평가합니다. 데이터베이스는 RDS로 지속적인 replication과 함께 마이그레이션되어야 하며, 애플리케이션 서버의 매우 큰 attached-volume 규모 때문에 대량 seeding이 가장 큰 과제가 됩니다. 정답인 이유: 대상으로 Amazon RDS for PostgreSQL이 명시되어 있으므로 AWS Database Migration Service (AWS DMS)가 강하게 시사됩니다. DMS는 self-managed PostgreSQL에서 RDS로 full load와 지속적인 change data capture (CDC)를 지원하기 때문입니다. 애플리케이션 서버의 경우 attached storage 총량이 420 TB로, 이는 일회성 network import 방식으로 빠르게 옮기기에는 현실적으로 너무 큽니다. AWS Snowball Edge Storage Optimized는 매우 큰 데이터셋의 대량 오프라인 전송을 위해 설계되었습니다. Snowball Edge로 대규모 VM image/data를 seed하고 DMS로 데이터베이스를 동기화 상태로 유지하는 방식이 제시된 선택지 중 downtime을 가장 적게 제공합니다. 주요 기능: AWS DMS는 진행 중인 PostgreSQL 변경 사항을 Amazon RDS로 복제할 수 있으므로 최종 cutover까지 source 데이터베이스를 online 상태로 유지할 수 있습니다. Snowball Edge Storage Optimized 디바이스는 petabyte 규모의 데이터 이동을 목적으로 하며, network-only 접근 방식과 비교해 초기 대량 전송에 필요한 시간을 크게 줄일 수 있습니다. 이후 대량 seed가 완료되면 최종 동기화 및 cutover 트래픽에는 Direct Connect를 사용할 수 있습니다. 흔한 오해: AWS SMS는 VM rehosting 서비스이지만, 데이터베이스를 Amazon RDS로 마이그레이션하지 않으며 시험에서 데이터베이스 대상의 현대화를 강조할 때 최선의 답이 아닙니다. VM Import/Export는 일회성 import 메커니즘이며 low-downtime cutover에 필요한 증분 replication 패턴을 지원하지 않습니다. 흔한 함정은 downtime 요구 사항에만 집중하고 막대한 420 TB 규모를 간과하는 것인데, 이 규모에서는 대량 seeding이 핵심 설계 요소가 됩니다. 시험 팁: 대상이 Amazon RDS이고 downtime을 최소화해야 한다면 AWS DMS with CDC를 찾으세요. 데이터셋이 수백 TB 규모라면 초기 대량 전송을 처리하기 위해 Snow Family 디바이스를 찾으세요. 요구 사항에 데이터베이스가 최종적으로 RDS에 있어야 한다고 명시되어 있는데도 단순히 데이터베이스 VM을 rehost하는 선택지는 제거하세요.

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

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

문제 6

Helios Media는 온프레미스 네트워크(10.50.0.0/16)와 Helios Media AWS 계정에 있는 VPC X라는 이름의 VPC(172.31.0.0/16)를 운영하고 있습니다. 온프레미스 네트워크는 virtual private gateway에서 종단되는 AWS Site-to-Site VPN을 통해 VPC X에 연결되어 있으며, 온프레미스 서버는 VPC X의 리소스에 성공적으로 연결할 수 있습니다. Helios Media는 최근 Orion Labs를 인수했으며, Orion Labs는 VPC Y라는 이름의 VPC(10.90.0.0/16)를 가진 별도의 AWS 계정을 운영하고 있고, 온프레미스 네트워크, VPC X, VPC Y 간에는 IP 주소 중복이 없습니다. 두 회사는 VPC X와 VPC Y 사이에 VPC peering connection을 설정했습니다. Helios Media는 이제 온프레미스 서버가 VPC Y의 워크로드에 액세스할 수 있기를 원하며, 트래픽을 허용하도록 network ACL과 security group을 이미 구성했습니다. 운영 노력(operational effort)을 최소화하면서 이 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 7

한 fintech startup이 Application Load Balancer (ALB) 뒤에서 Auto Scaling group의 EC2 instances에서 실행되는 Amazon ECS cluster에서 모바일 wallet API를 운영하고 있습니다. 매주 금요일 01:00 UTC에 실패한 로그인 시도가 급증하여 authentication microservice의 CPU가 90%까지 상승합니다. 실패한 시도는 약 600개의 source IP addresses에서 발생하며 이 IP들은 7일마다 순환하고, 그중 많은 IP가 5-minute window 내에 300건을 초과하는 로그인 요청을 보냅니다. solutions architect는 운영 효율성을 가장 높이면서 이러한 실패한 로그인이 authentication service를 과부하시키지 않도록 해야 합니다. 무엇을 해야 합니까?

문제 분석

핵심 개념: 이 문제는 Application Load Balancer 뒤의 HTTP(S) 워크로드에 대한 엣지 보호를 AWS WAF로 구현하는 능력을 평가하며, 특히 IP allow/deny list를 지속적으로 관리하지 않고도 남용 트래픽(credential stuffing/brute-force)의 급증을 완화하기 위한 rate-based rules를 다룹니다. 정답이 맞는 이유: 공격 패턴은 매주 순환하는 다수의 source IPs(약 600개)로 특징지어지며, 개별 IP가 5-minute window 내에 300건을 초과하는 로그인 요청을 보내 authentication service의 CPU를 높입니다. ALB에 연결된 AWS WAF web ACL은 요청이 ECS에 도달하기 전에 차단하거나(또는 조치)하여 authentication microservice의 부하를 줄일 수 있습니다. rate-based rule은 이를 위해 설계된 기능으로, originating IP별 요청률을 자동으로 추적하고 임계값을 초과하면 Block 조치를 수행합니다. 이는 “5분 내 300건 초과” 조건과 정확히 일치하며, IP가 순환하더라도 운영 오버헤드를 줄여줍니다. 주요 AWS 기능: AWS WAF rate-based rules는 5-minute sliding window 동안 요청을 집계하며, abusive clients를 차단하기 위해 Block 같은 action을 구성할 수 있습니다. web ACL은 ALB에 연결할 수 있어 중앙에서 관리되는 L7 filtering을 제공합니다. 또한 scope-down statements를 사용해 login URI(예: /auth/login)로 규칙 범위를 제한하여 다른 endpoint에 영향을 주지 않게 할 수 있고, WAF logging을 CloudWatch Logs/S3/Kinesis Data Firehose로 전송해 조사에 활용할 수 있습니다. 이는 Well-Architected의 Security(엣지에서 보호, least privilege) 및 Reliability(과부하 방지) 원칙과 부합합니다. 흔한 오해: security groups와 Firewall Manager는 L3/L4에서 동작하며 HTTP request-rate limiting을 위해 설계되지 않았습니다. IP를 나열해 차단할 수 있다 하더라도, 매주 IP가 순환하므로 정적 deny list는 운영 효율성이 떨어집니다. WAF의 IP set blocking 역시 set을 지속적으로 업데이트해야 하며, 이는 시나리오에서 피하려는 운영 부담입니다. 시험 팁: ALB + 공격자 IP가 순환 + 요청 burst(예: 5분당 N건)가 보이면 AWS WAF rate-based rules를 떠올리십시오. 악성 IP가 안정적이고 알려져 있을 때는 IP sets를 사용하고, 패턴이 volumetric/behavioral이며 IP가 자주 바뀔 때는 rate-based rules를 사용하십시오. compute 앞단에서 관리형 L7 제어를 우선 적용해 downstream services를 보호하고 scaling 압박을 줄이십시오.

문제 8

한 핀테크 회사는 ap-southeast-1의 공개 Amazon API Gateway HTTP API 뒤에서 AWS Lambda 함수로 결제 webhook 수신기를 실행하고 있다. 호출은 비동기적으로 처리되며(API는 200 ms 이내에 HTTP 202를 반환하고 Lambda는 처리를 계속함), 비즈니스 요구사항은 전체 Region 장애 시 5분 이내 자동 Regional failover(클라이언트 SDK 변경 없음, 단일 공개 hostname)이다. 정상 운영 시에는 end-to-end latency를 300 ms 미만으로 유지해야 하며, 기존 IAM authorization을 유지하면서 ap-southeast-2로 failover를 지원해야 한다. 어떤 솔루션이 이러한 요구사항을 충족하는가?

문제 분석

핵심 개념: 이 문제는 단일 안정적 hostname, 빠른 자동 failover, 그리고 authorization 동작 유지가 필요한 API Gateway + Lambda serverless endpoint의 multi-Region 복원력을 테스트한다. 핵심 패턴은 Amazon Route 53과 API Gateway custom domain name을 사용한 DNS failover로 프런트되는 active/passive(또는 active/active) multi-Region API endpoint이다. 정답이 맞는 이유: 옵션 D는 ap-southeast-1과 ap-southeast-2 모두에 전체 스택(API Gateway HTTP API와 Lambda)을 배포한 다음, 각 Region에서 API Gateway custom domain name을 사용하고 Route 53 failover routing과 health check를 통해 단일 공개 hostname을 수 분 내에 정상 Region으로 이동시킨다. 이는 클라이언트가 동일한 도메인을 계속 호출하므로 “클라이언트 SDK 변경 없음” 및 “단일 공개 hostname” 요구사항을 충족한다. 또한 Route 53 health check와 failover policy가 Regional outage 동안 트래픽을 빠르게 전환할 수 있으므로 5분 RTO 요구사항을 충족한다. 정상 운영 시에는 클라이언트가 primary Region endpoint로 직접 resolve되므로(추가 proxy hop 없음) latency를 낮게 유지한다. 주요 AWS 기능: - 각 Region의 Regional HTTP API에 매핑된 API Gateway custom domain name. - API 가용성을 반영하는 path에 대한 health check와 함께 사용하는 Route 53 failover routing policy(PRIMARY/SECONDARY). - Region별 Lambda 배포(Lambda는 Regional이므로 필요). - IAM authorization 유지: API Gateway IAM auth(SigV4)는 동일한 모델로 유지되며, 클라이언트는 execute-api에 대해 계속 요청에 서명한다. custom domain을 사용하는 경우 API가 IAM auth를 수용하도록 구성되어 있고 클라이언트가 올바른 service/region 기대치로 서명하도록 보장해야 한다. 실제로 많은 webhook sender는 IAM을 사용하지 않지만, 요구사항이 명시적으로 이를 유지하라고 하므로, non-API-Gateway front door를 도입하기보다 각 Region에서 API Gateway + IAM을 유지하는 것이 가장 적합하다. 흔한 오해: - “secondary API를 primary Lambda로만 연결”은 실패한다. API Gateway Lambda proxy integration으로 cross-Region의 Lambda를 호출할 수 없기 때문이다. - “모든 것에 Global Accelerator 사용”은 빠른 failover 관점에서 매력적이지만, ALB/NLB처럼 API Gateway endpoint를 origin으로 직접 프런트하는 방식이 아니며, API Gateway 앞에 ALB를 두는 것은 표준적이거나 필요한 패턴이 아니다. 시험 팁: Regional outage에서 단일 DNS 이름이 필요하면 Route 53 failover(또는 latency/weighted) + health check를 떠올려라. API Gateway의 multi-Region에서는 일반적으로 Region별로 API와 backend를 복제하고, custom domain을 사용해 클라이언트 hostname을 안정적으로 유지한다. cross-Region Lambda integration에 의존하거나 latency를 증가시키는 불필요한 extra hop이 있는 설계는 피하라.

문제 9

지역 음식 배달 스타트업이 코로케이션 시설의 단일 랙 서버에서 상태 저장형 Node.js 웹 애플리케이션과 MySQL 5.7 데이터베이스를 실행하고 있습니다. 마케팅 계획에 따르면 30일 내 피크 동시 사용자 수가 400명에서 4,500명으로 증가할 것으로 예상되며, CTO는 최소 두 개의 Availability Zone에 걸친 99.99% 서비스 가용성, 인증 사용자에 대한 세션 연속성, 60초 미만의 데이터베이스 RTO, 그리고 최소한의 코드 변경으로 단일 AWS Region으로 마이그레이션할 때 단일 장애 지점 제거를 요구합니다. 가장 높은 수준의 신뢰성을 제공해야 하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 세션 연속성과 매우 낮은 RTO를 충족하는 관계형 데이터베이스를 갖춘 고가용성 Multi-AZ 웹 계층을 설계하는 능력을 평가합니다. 단일 장애 지점을 제거하고 빠른 장애 조치를 제공하는 관리형 서비스를 선택하는 데 초점을 둡니다. 정답인 이유: 옵션 B는 최소한의 애플리케이션 변경으로 엔드투엔드에서 가장 높은 신뢰성을 제공합니다. Node.js 앱은 세션을 ElastiCache for Redis(Multi-AZ 및 automatic failover)로 외부화하여 무상태(stateless)화되며, 이를 통해 여러 AZ에 걸쳐 Application Load Balancer (ALB) 뒤에서 수평 확장이 가능합니다. 데이터베이스 측면에서 Aurora MySQL(Multi-AZ)은 고가용성을 위해 설계되었습니다. 스토리지가 여러 AZ에 복제되며 장애 조치가 일반적으로 표준 RDS Multi-AZ보다 더 빠르기 때문에 60초 미만 RTO 요구사항을 충족하는 데 도움이 됩니다. 이 아키텍처는 컴퓨팅, 세션, 데이터베이스 계층에서 단일 장애 지점을 제거합니다. 주요 AWS 기능: - Aurora MySQL compatibility는 MySQL 5.7에서의 코드 변경을 최소화합니다. - 서로 다른 AZ에 writer와 reader를 두는 Aurora Multi-AZ는 빠른 장애 조치와 읽기 확장을 지원합니다. - 여러 AZ에 걸친 EC2 Auto Scaling + ALB health checks는 400명에서 4,500명 동시 사용자로의 탄력적이고 복원력 있는 웹 계층 확장을 제공합니다. - Multi-AZ automatic failover가 있는 ElastiCache for Redis replication group은 노드/AZ 장애 중에도 세션 연속성을 유지합니다. - ALB는 HTTP/HTTPS, path-based routing을 지원하며 Auto Scaling과 통합되어 신뢰할 수 있는 트래픽 분산을 제공합니다. 흔한 오해: - “어떤 Multi-AZ RDS든 <60초 RTO에 충분하다”: RDS Multi-AZ도 고가용성이지만, Aurora는 분산 스토리지 아키텍처로 인해 일반적으로 더 빠른 장애 조치와 더 높은 복원력을 제공하도록 설계되었습니다. - “Memcached도 세션에 괜찮다”: Memcached는 내구성이 없고 Multi-AZ automatic failover가 없으므로 세션 연속성과 가용성 목표를 달성하기가 더 어렵습니다. - “세션에 graph DB를 사용한다”: Neptune은 세션 저장을 목적으로 하지 않으며, 신뢰성을 높이지 않으면서 복잡성만 추가합니다. 시험 팁: 최소 두 개의 AZ에 걸친 99.99%를 위해서는 모든 상태 저장 구성요소가 Multi-AZ 관리형(DB, cache)이거나(또는) 애플리케이션 계층이 무상태화되어야 합니다. 세션 연속성을 위해 Memcached보다 Redis(복제 + 장애 조치)를 선호합니다. 엄격한 RTO 요구사항에는 MySQL-compatible 관리형 데이터베이스 중 Aurora가 흔히 최적의 선택입니다.

문제 10

유전체학 연구 실험실이 eu-central-1 Region에서 72 TB 규모의 온프레미스 MariaDB 데이터베이스를 Amazon Aurora MySQL로 1회성 마이그레이션할 계획이다. 인터넷 링크가 150 Mbps뿐이라 데이터를 전송하는 데 약 45일이 걸릴 것으로 예상되며, 실험실은 더 빠른 접근 방식이 필요하고 데이터베이스를 가장 짧은 시간 내에 마이그레이션할 솔루션이 무엇인지 결정해야 한다.

문제 분석

핵심 개념: 이 문제는 WAN 대역폭이 심하게 제한된 상황에서 매우 큰 규모의 일회성 데이터베이스 마이그레이션에 대해 가장 빠르고 실용적인 마이그레이션 방법을 선택하는지를 평가합니다. 핵심은 온라인 네트워크 기반 마이그레이션 방식과 오프라인 대량 데이터 전송을 구분하고, Aurora MySQL로 데이터를 로드하는 데 적절한 AWS 서비스를 선택하는 것입니다. 정답인 이유: 72 TB의 데이터는 150 Mbps 링크로 전송하면 너무 오래 걸리며, 1 Gbps Direct Connect를 사용하더라도 전송에 여러 날이 필요하고 프로비저닝 리드 타임도 추가됩니다. AWS Snowball Edge는 제한된 네트워크 링크보다 더 빠르게 대규모 데이터셋을 AWS로 이동하도록 특별히 설계된 서비스로, 데이터를 물리적으로 AWS로 배송하는 방식입니다. 데이터가 Amazon S3에 로드된 후에는 AWS DMS가 S3를 소스로 사용하여 Aurora MySQL로 데이터를 로드할 수 있으므로, 제시된 보기 중 가장 빠르고 유효한 선택지입니다. 주요 특징: - AWS Snowball Edge는 오프라인 페타바이트 규모 데이터 전송을 제공하며, 일반적으로 일회성 대량 마이그레이션에 사용됩니다. - 이 디바이스는 S3-compatible interface를 지원하므로 데이터를 효율적으로 스테이징하고 가져올 수 있습니다. - AWS DMS는 구조화된 데이터를 로드하기 위해 Amazon S3를 source endpoint로, Aurora MySQL을 target endpoint로 지원합니다. - DMS는 대량 데이터가 AWS로 전송된 후 Aurora로 데이터베이스 로드를 수행할 수 있습니다. 흔한 오해: 흔한 실수 중 하나는 대규모 마이그레이션에서 Direct Connect가 항상 가장 빠른 옵션이라고 가정하는 것입니다. Direct Connect는 대역폭을 향상시키지만, 매우 큰 규모의 일회성 전송에서는 물리적 데이터 전송이 전체적으로 더 빠른 경우가 많습니다. 또 다른 오해는 AWS Application Migration Service가 데이터베이스를 Aurora로 마이그레이션할 수 있다고 생각하는 것입니다. 이 서비스는 논리적 데이터베이스 마이그레이션이 아니라 서버 rehosting을 위한 것입니다. 또한 AWS DMS가 유효한 마이그레이션 패턴에서 Amazon S3를 소스로 지원한다는 점을 놓치기 쉽습니다. 시험 팁: - 수십 테라바이트 이상의 일회성 마이그레이션에서는 네트워크 대역폭이 제한적일 경우 Snow Family 서비스를 먼저 고려하세요. - Aurora로의 데이터베이스 마이그레이션에는 AWS Application Migration Service가 아니라 AWS DMS를 사용하세요. - 관리형 데이터베이스 서비스로의 데이터베이스 엔진 변환 또는 마이그레이션에 MGN을 잘못 사용하는 답변은 제거하세요. - 문제에서 LEAST amount of time을 묻는 경우, 전송 속도와 서비스 적합성을 모두 평가에 포함하세요.

Practice Test #5

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(9)

다른 모의고사

Practice Test #1

Practice Test #2

Practice Test #3

Practice Test #4

지금 학습 시작하기