연습 문제

문제 1

글로벌 스트리밍 미디어 회사가 여러 리전에서 250개 이상의 비디오 스트리밍 플랫폼을 운영하고 있습니다. 이 회사는 콘텐츠 추천 및 사용자 경험을 최적화하기 위해 매일 약 25TB의 사용자 시청 행동 및 상호 작용 데이터를 처리해야 합니다. 솔루션은 대용량 실시간 데이터 수집(ingestion)을 처리하고, 안정적인 데이터 전송을 제공하며, 대규모 스트리밍 데이터에 대한 효율적인 분석 처리를 가능하게 해야 합니다. 솔루션 아키텍트는 스트리밍 행동 데이터를 수집하고 처리하기 위해 무엇을 권장해야 합니까?

문제 분석

핵심 개념: 이 질문은 처리량이 높고 안정적인 스트리밍 수집 및 분석 파이프라인 설계에 대해 테스트합니다. 주요 AWS 서비스는 Amazon Kinesis Data Streams(실시간 수집 및 버퍼링), Amazon Kinesis Data Firehose(스토리지/분석 대상으로의 관리형 전송), Amazon S3(내구성 있는 데이터 레이크), Amazon Redshift(분석/데이터 웨어하우스)입니다. 정답인 이유: 250개 이상의 플랫폼에서 매일 약 25TB의 데이터를 처리해야 하므로, 회사는 내구성 있는 버퍼링과 안정적인 전송을 갖춘 확장 가능한 거의 실시간 수집이 필요합니다. Kinesis Data Streams는 샤드당 정렬된 레코드, 재생을 위한 보존, 샤드(또는 온디맨드 모드)를 통한 수평 확장을 제공하여 대용량 이벤트 수집을 위해 특별히 구축되었습니다. 그런 다음 Kinesis Data Firehose는 배치 처리, 재시도 및 선택적 변환을 통해 데이터를 S3 데이터 레이크에 저장하는 완전 관리형의 안정적인 전송 계층을 제공하여 운영 오버헤드를 최소화합니다. S3에서 대규모 행동 분석 및 추천 기능 생성을 위해 데이터를 Redshift로 로드(예: S3에서 COPY)할 수 있습니다. 주요 AWS 기능: - Kinesis Data Streams: 샤드 기반 확장(또는 온디맨드), 다중 소비자, 향상된 팬아웃(enhanced fan-out), 재처리를 위한 보존, IAM/KMS와의 통합. - Kinesis Data Firehose: 자동 배치/압축/암호화, 재시도 로직, S3 전송, 선택적 Lambda 기반 변환. - S3 데이터 레이크: 높은 내구성, 수명 주기 정책, 효율적인 다운스트림 쿼리를 위한 파티셔닝된 스토리지. - Redshift: 빠른 집계를 위한 열 기반 스토리지 및 MPP; 처리량이 높은 로드를 위한 S3에서 COPY. 일반적인 오해: Data Pipeline 및 DIY EC2 수집은 실행 가능해 보일 수 있지만, 이 규모의 실시간 스트리밍에 최적화되어 있지 않으며 상당한 운영 부담을 추가합니다. CloudFront는 콘텐츠 전송/캐시 서비스이지 이벤트 수집 시스템이 아닙니다. 행동 원격 측정에 이를 사용하는 것은 아키텍처상 맞지 않습니다. 시험 팁: "대용량 실시간 수집(high-volume real-time ingestion)"과 "안정적인 전송(reliable transmission)" 및 "분석(analytics)"이 보이면 Kinesis(수집/버퍼링을 위한 Streams, 관리형 전송을 위한 Firehose) + 랜딩 존으로서의 S3를 생각하십시오. 분석 요구 사항에 따라 Redshift/EMR/Athena와 페어링하십시오. Redshift는 대규모 구조화된 행동 분석을 위한 일반적인 선택입니다.

문제 2

한 회사가 매일 EBS 스냅샷을 생성하며 EC2에서 SQL Server를 실행합니다. 정리 스크립트가 실수로 모든 스냅샷을 삭제했습니다. 이 회사는 스냅샷을 영구적으로 보관하지 않으면서 데이터 손실을 방지해야 합니다. 최소한의 개발로 우발적인 삭제에 대한 안전망을 제공해야 합니다. 최소한의 개발 노력으로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념 - 이 질문은 우발적인 삭제에 대한 복원력을 제공하는 AWS Backup/Amazon EBS 데이터 보호 제어, 특히 EBS 스냅샷 휴지통(Recycle Bin) 기능(EBS 스냅샷 관리의 일부) 및 보존 기반 복구를 테스트합니다. 이는 복구 가능성, 제어된 보존 및 운영 위험 최소화와 같은 복원력 있는 아키텍처 원칙과 일치합니다. 정답인 이유 - 7일 EBS 스냅샷 휴지통 보존 규칙은 "안전망"을 생성하여 스냅샷이 (스크립트나 사용자에 의해) 실수로 삭제되더라도 휴지통에 보존되고 보존 기간 동안 복원될 수 있도록 합니다. 이는 스냅샷을 영구적으로 보관하지 않아야 한다는 요구 사항을 충족하면서 인시던트(모든 스냅샷의 우발적 삭제)를 직접적으로 해결합니다. 또한 최소한의 개발이 필요합니다. 백업 워크플로를 재설계하는 대신 보존 규칙을 한 번만 구성하면 됩니다. 주요 AWS 기능 - EBS 스냅샷 휴지통을 사용하면 보존 규칙(태그별 또는 계정/리전의 모든 스냅샷에 대해)을 설정하여 삭제된 스냅샷을 보존 기간이 만료될 때까지 복구할 수 있습니다. 이는 우발적인 삭제를 위해 특별히 구축되었으며 일반적인 스냅샷 수명 주기 정책을 보완(대체하지 않음)합니다. 이는 계정/리전 수준의 제어이며 교차 리전 복사 파이프라인을 구축하는 것에 비해 운영상 간단합니다. 일반적인 오해 - IAM에서 스냅샷 삭제를 거부하는 것(옵션 A)은 삭제를 방지하는 것처럼 보이지만 불안정합니다. 정리 스크립트가 다른 역할로 실행될 수 있고, 관리자가 여전히 삭제할 수 있으며, 삭제가 이미 발생했거나 합법적인 삭제가 필요한 경우에는 도움이 되지 않습니다. 교차 리전 복사(옵션 B)는 재해 복구를 개선하지만 별도의 제어로 복사본을 보호하지 않는 한 본질적으로 우발적인 삭제로부터 보호하지 못합니다. 또한 비용과 운영 오버헤드가 추가됩니다. "스냅샷을 S3 Standard-IA로 복사"(옵션 D)는 EBS 스냅샷이 작동하는 방식이 아닙니다. 스냅샷은 EBS에서 관리하며 S3 스토리지 클래스로 직접 계층화할 수 없습니다. 시험 팁 - "우발적 삭제(accidental deletion)" + "영구 보관 안 함(don't keep forever)" + "최소한의 개발(least development)"이 보이면 관리형 보존/복구 기능인 EBS 스냅샷 휴지통, AWS Backup Vault Lock(백업용) 및 수명 주기 정책을 찾으십시오. 시간 제한 보존 및 최소한의 사용자 지정 자동화를 통해 삭제 후 복구 가능성을 직접 제공하는 옵션을 선택하십시오.

문제 3

금융 서비스 회사가 50개 이상의 파트너 은행에서 매일 트랜잭션 보고서를 처리하기 위한 중요한 파일 교환 시스템을 운영합니다. 이 시스템은 현재 공유 스토리지로 지원되는 FTP 서비스를 실행하는 탄력적 IP 주소(Elastic IP)가 있는 두 개의 Amazon EC2 인스턴스를 사용합니다. 시스템은 매일 약 10,000개의 파일을 처리하며 각 파일의 크기는 100MB에서 2GB 사이입니다. 회사는 영업 시간(오전 9시 - 오후 5시 EST) 동안 15,000 IOPS의 최대 로드를 처리하고 엔터프라이즈급 보안 제어를 제공할 수 있는 서버리스 아키텍처로 마이그레이션해야 합니다. 솔루션은 특정 파트너 은행 IP 범위에서의 파일 전송을 지원하고 규정 준수 감사를 위해 세분화된 사용자 액세스 제어를 유지해야 합니다. 이러한 고성능 및 보안 요구 사항을 가장 잘 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 serverless이고, 대량의 파일 볼륨에 대해 높은 확장성을 제공하며, 금융 서비스 파트너 통합에 충분할 만큼 안전한 fully managed 파일 전송 서비스를 선택하는지를 평가합니다. 가장 적합한 선택은 backend로 Amazon S3를 사용하는 SFTP 기반의 AWS Transfer Family입니다. 그 이유는 S3가 스토리지 성능을 프로비저닝할 필요 없이 사실상 무제한에 가까운 확장성을 제공하고, Transfer Family가 managed 사용자 액세스 제어와 로깅을 제공하기 때문입니다. 정답인 이유: 옵션 C가 최선의 답인 이유는 AWS Transfer Family with SFTP를 사용하기 때문이며, 이는 EC2 기반 FTP 서버를 운영할 필요를 없애는 managed 서비스입니다. Amazon S3는 많은 대용량 파일을 처리하는 serverless 아키텍처에 가장 적절한 backend이며, block 또는 file 스토리지처럼 IOPS를 산정하거나 프로비저닝할 필요가 없습니다. 세분화된 액세스 제어는 특정 bucket 또는 prefix 범위로 제한된 IAM role 및 policy를 통해 적용할 수 있고, 암호화와 로깅은 규정 준수 요구 사항을 지원합니다. 주요 기능: - AWS Transfer Family는 서버를 관리하지 않고도 managed SFTP endpoint를 지원합니다. - Amazon S3는 대용량 파일 교환 워크로드를 위한 내구성이 높고 대규모로 확장 가능한 object 스토리지를 제공합니다. - IAM policy는 최소 권한 액세스를 위해 각 사용자를 특정 S3 prefix로 제한할 수 있습니다. - S3 기본 암호화와 AWS Transfer Family 로깅은 보안 및 감사 요구 사항을 지원합니다. - 엄격한 source-IP 필터링이 필요한 경우 VPC-hosted endpoint와 security group을 사용해 IP 기반 제한을 구현할 수 있습니다. 흔한 오해: - EBS는 Transfer Family backend로 사용할 수 없습니다. - NAT gateway는 파트너 연결에 대한 inbound internet 액세스 제어를 제공하지 않습니다. - CloudTrail은 API 활동을 기록하지만, 자세한 전송/세션 가시성은 일반적으로 Transfer Family 로깅 및 관련 서비스 로그에서 제공합니다. - S3 Transfer Acceleration은 직접적인 S3 액세스에 적용되며, AWS Transfer Family를 통해 연결하는 클라이언트에는 적용되지 않습니다. 시험 팁: 문제에서 serverless managed 파일 전송, 외부 파트너 액세스, 대량 파일 볼륨, 세분화된 권한을 강조한다면, 명확하게 타당한 EFS 전용 요구 사항이 없는 한 AWS Transfer Family with S3를 떠올리세요. 지원되지 않는 스토리지 backend나 잘못된 네트워킹 패턴을 제안하는 답은 제거하세요. 프로토콜 요구 사항이 명시적으로 달리 말하지 않는 한, 민감한 금융 워크로드에는 FTP보다 SFTP를 우선하세요.

문제 4

의료 회사가 X-ray 및 MRI 스캔을 처리하는 의료 영상 분석 애플리케이션을 운영합니다. 이 애플리케이션은 동일한 AWS 리전 내의 Amazon S3 버킷에서 대용량 의료 이미지 파일을 자주 저장하고 검색합니다. IT 팀은 지난 분기 동안 월별 데이터 전송 요금이 40% 증가한 것을 관찰했습니다. 솔루션 아키텍트는 의료 영상 처리를 위해 S3 버킷에 대한 안전한 액세스를 유지하면서 데이터 전송 요금을 최소화하는 비용 효율적인 솔루션을 구현해야 합니다. 솔루션 아키텍트는 이 요구 사항을 어떻게 충족할 수 있습니까?

문제 분석

핵심 개념: 이 질문은 Amazon S3 데이터 전송 비용을 줄이고 VPC에서 S3로의 프라이빗 연결에 대한 보안을 개선하는 방법을 테스트합니다. 주요 서비스는 Amazon S3 VPC 게이트웨이 엔드포인트입니다(S3용 AWS PrivateLink는 인터페이스 엔드포인트가 아닌 게이트웨이 엔드포인트를 사용함). 정답인 이유: S3 VPC 게이트웨이 엔드포인트는 퍼블릭 인터넷을 통과하지 않고, 인터넷 게이트웨이(IGW)를 사용하지 않고, NAT 게이트웨이를 사용하지 않고 VPC의 리소스(VPC의 EC2, ECS, EKS, Lambda)와 Amazon S3 간의 프라이빗 직접 연결을 제공합니다. 이렇게 하면 NAT 게이트웨이 데이터 처리 요금이 제거되고 인터넷 경로에 대한 노출이 줄어듭니다. "대용량 파일을 자주 저장하고 검색"하는 워크로드의 경우 NAT 게이트웨이 GB당 처리 요금을 피하는 것이 종종 가장 큰 비용 절감 효과를 가져옵니다. 엔드포인트는 리전별로 고가용성을 제공하며 트래픽은 AWS 네트워크에 유지됩니다. 주요 AWS 기능: 1) 게이트웨이 엔드포인트 라우팅 테이블 항목: S3 접두사로 향하는 트래픽이 엔드포인트로 라우팅되도록 엔드포인트를 VPC 라우팅 테이블과 연결합니다. 2) 엔드포인트 정책: 필요한 의료 영상 버킷 및 작업(예: s3:GetObject, s3:PutObject)으로만 액세스를 제한하고 조건(aws:PrincipalArn, s3:prefix 등)을 적용할 수도 있습니다. 3) 심층 방어: 엔드포인트 정책을 VPC 엔드포인트(aws:SourceVpce) 및 IAM 최소 권한을 통한 액세스가 필요한 S3 버킷 정책과 결합합니다. 이는 AWS Well-Architected(비용 최적화 + 보안 원칙)와 일치합니다. 일반적인 오해: 많은 사람들이 "동일한 리전 S3 액세스"가 항상 무료라고 가정합니다. S3 요청 비용 및 리전 내 데이터 전송 패턴은 다양하지만 요금 증가의 일반적인 원인은 NAT 게이트웨이(GB당 NAT 데이터 처리 발생) 또는 기타 이그레스 경로를 통해 S3 트래픽을 라우팅하는 것입니다. 또 다른 오해는 API Gateway 또는 퍼블릭 서브넷/IGW가 비용을 줄인다는 것입니다. 이들은 일반적으로 비용을 추가하고 프라이빗 라우팅 이점을 제공하지 않습니다. 시험 팁: "VPC 내에서 S3로의 데이터 전송 요금 절감" 및 "안전한/프라이빗 액세스 유지"가 보이면 "S3 게이트웨이 엔드포인트"를 생각하십시오. 옵션에 S3 액세스를 위한 NAT 게이트웨이가 언급되어 있으면 일반적으로 비용에 대한 위험 신호입니다. 또한 안전한 패턴으로 "엔드포인트 정책" 및 "aws:SourceVpce가 있는 버킷 정책"을 찾으십시오.

문제 5

한 이러닝 플랫폼이 Network Load Balancer 뒤에 있는 Amazon Linux EC2 인스턴스를 사용하여 다중 계층 교육 콘텐츠 전송 시스템을 운영하고 있습니다. 인프라는 3개의 가용 영역에 분산된 Auto Scaling 그룹에서 실행됩니다. 이 플랫폼은 피크 학습 시간(오후 6시~10시)에 학생들이 대용량 비디오 강의와 PDF 자료를 다운로드할 때 상당한 확장 이벤트를 겪으며, 이로 인해 시스템은 증가된 로드를 처리하기 위해 추가 온디맨드(On-Demand) 인스턴스를 프로비저닝합니다. 이 플랫폼은 약 15,000명의 동시 접속 학생에게 서비스를 제공하며 콘텐츠 전송에 대한 짧은 지연 시간을 유지하면서 인프라 비용을 줄여야 합니다. 정적 교육 콘텐츠(비디오, PDF, 이미지)가 전체 대역폭 사용량의 80%를 차지합니다. 플랫폼을 가장 비용 효율적으로 재설계하기 위해 솔루션 아키텍트는 무엇을 권장해야 합니까?

문제 분석

개요: 핵심 개념: 이 질문은 대규모로 주로 정적인 콘텐츠를 비용 최적화하여 전송하는 방법을 테스트합니다. 주요 서비스는 Amazon S3 오리진이 있는 Amazon CloudFront(CDN)로, EC2/Auto Scaling에서 대역폭 및 요청 로드를 오프로드하는 동시에 엣지 캐싱을 통해 지연 시간을 개선합니다. 정답인 이유: 대역폭의 80%가 정적(비디오, PDF, 이미지)이므로 가장 비용 효율적인 재설계는 해당 콘텐츠를 EC2 플릿에서 이동하여 S3가 지원하는 CloudFront를 통해 제공하는 것입니다. CloudFront는 학생들과 가까운 엣지 로케이션에 콘텐츠를 캐시하여 오리진 가져오기를 줄이고 오후 6시~10시 급증 동안 필요한 EC2 데이터 전송 및 컴퓨팅을 극적으로 낮춥니다. 이는 확장 이벤트(온디맨드 인스턴스 감소)를 줄이고 15,000명의 동시 사용자에 대해 짧은 지연 시간을 유지하거나 개선합니다. S3는 내구성이 뛰어나고 저렴한 스토리지를 제공하며, CloudFront는 글로벌 배포 및 최적화된 전송을 제공합니다. 주요 AWS 기능 / 모범 사례: 적절한 스토리지 클래스(예: 핫 콘텐츠의 경우 S3 Standard, 가변 액세스 패턴의 경우 S3 Intelligent-Tiering 고려)가 있는 S3 버킷을 오리진으로 사용합니다. 적절한 TTL, 캐시 정책 및 압축을 사용하여 CloudFront 캐싱을 활성화합니다. 원본 액세스 제어(OAC)를 사용하여 직접적인 S3 액세스를 제한하고 CloudFront를 통해서만 콘텐츠를 제공합니다. 선택적으로 보호된 코스 자료에 대해 서명된 URL/쿠키를 사용하고 성능을 위해 HTTP/2/HTTP/3을 활성화합니다. 이는 AWS Well-Architected 비용 최적화(수요 감소, 관리형 서비스 사용) 및 성능 효율성(엣지 캐싱)과 일치합니다. 일반적인 오해: 확장이 눈에 띄기 때문에 인스턴스 구매(Savings Plans/Spot)에 집중하기 쉽지만, 이는 주요 동인(정적 대역폭)이 아닌 증상(컴퓨팅 비용)을 치료하는 것입니다. 또한 Lambda/API Gateway는 대규모 정적 파일 전송을 위한 것이 아니며 비용이 많이 들고 운영상 어색할 것입니다. 시험 팁: 워크로드가 정적 콘텐츠와 대역폭에 의해 지배될 때 가장 먼저 "S3 + CloudFront"를 생각하십시오. 질문에서 글로벌 또는 대규모 다운로드에 대한 짧은 지연 시간을 언급하는 경우 CDN이 일반적으로 최고의 아키텍처 레버입니다. 구매 모델(Savings Plans/Spot)은 컴퓨팅 로드를 줄이고 목적에 맞게 구축된 관리형 서비스로 전환한 후의 2차 최적화입니다.

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

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

문제 6

한 의료 기관이 민감한 환자 의료 기록과 규정 준수 문서를 저장하기 위해 Amazon S3를 사용하고 있습니다. S3 bucket은 최소 권한 원칙에 따라 특정 의료 규정 준수 팀 IAM user에게만 액세스를 제한하는 bucket policy를 구현합니다. 이 의료 기관의 관리자들은 S3 bucket에 있는 중요한 환자 기록이 우발적으로 삭제될 것을 우려하고 있으며, 의도치 않은 삭제로부터 이러한 문서를 보호하기 위해 더 안전한 솔루션을 구현해야 합니다. 환자 의료 기록을 보호하기 위해 solutions architect는 무엇을 권장해야 합니까?

문제 분석

핵심 개념: 이 질문은 우발적이거나 의도치 않은 삭제에 대비한 Amazon S3 데이터 보호 제어를 테스트합니다. 주요 S3 기능은 Versioning(이전 object 버전을 유지하기 위함)과 MFA Delete(버전을 영구적으로 삭제하거나 versioning을 일시 중지하기 위해 multi-factor authentication을 요구하기 위함)입니다. 정답인 이유: S3 Versioning을 활성화하면 object가 삭제될 때 S3가 데이터를 즉시 제거하지 않고 delete marker를 추가하여 이전 버전을 보존합니다. 이를 통해 관리자는 delete marker를 제거하거나 이전 버전을 복원하여 환자 기록을 복구할 수 있습니다. MFA Delete를 추가하면 버전이 지정된 object 삭제 및 versioning 상태 변경 시 MFA를 요구하여 삭제 보호를 더욱 강화하며, 손상된 자격 증명이나 운영자의 실수로 인해 중요한 기록이 영구적으로 제거될 위험을 줄입니다. 이는 보존 및 복구 가능성이 필수적인 의료 기록에 특히 적합합니다. 주요 AWS 기능: 1) S3 Versioning: 동일한 bucket에 object의 여러 변형을 유지하여 우발적인 삭제/덮어쓰기로부터 롤백 및 복구를 가능하게 합니다. 2) MFA Delete: object 버전을 영구적으로 삭제하거나 versioning을 일시 중지하려면 MFA가 필요합니다(bucket 수준에서 구성되며, 일반적으로 root user 또는 승인된 프로세스를 통해 수행됨). 3) 최소 권한 bucket policy는 여전히 유용하지만, 삭제가 허용된 후에는 본질적으로 복구 가능성을 제공하지 않습니다. 일반적인 오해: 'IAM user에 MFA 활성화'로 충분하다고 생각하기 쉽지만, 로그인 시의 MFA는 자격 증명이 오용될 경우 프로그래밍 방식의 삭제를 방지하지 못하며 복구 기능도 제공하지 않습니다. 또 다른 오해는 암호화(SSE-KMS)가 삭제를 방지한다는 것입니다. 암호화는 기밀성을 보호할 뿐 가용성이나 복구 가능성을 보호하지는 않습니다. 또한 Lifecycle policy는 IAM user에게 연결할 수 없으며 액세스 제어 메커니즘으로 설계되지 않았습니다. 시험 팁: S3의 '우발적 삭제(accidental deletion)'에 대해서는 먼저 Versioning을 찾으십시오. 질문에서 영구 삭제를 방지하거나 삭제에 대한 추가 보증이 필요하다고 강조하는 경우 MFA Delete를 추가하십시오. 규정 준수/불변성 요구 사항의 경우 다른 질문에서는 S3 Object Lock(WORM)도 고려해야 하지만, 여기서는 옵션 중 가장 적합한 것이 Versioning + MFA Delete입니다. 참조: Amazon S3 Versioning 및 MFA Delete 설명서; AWS Well-Architected Framework (Security 및 Reliability 원칙: 데이터 보호, 복구 활성화).

문제 7

한 게임 회사가 AWS Fargate를 사용하는 Amazon ECS에서 리소스 집약적인 멀티플레이어 게임을 실행합니다. 이 게임은 짧은 트래픽 폭증(bursts)과 함께 연중무휴(24/7)로 사용 가능해야 합니다. 솔루션은 고가용성을 보장하고 트래픽 폭증을 비용 효율적으로 처리해야 합니다. 이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?

문제 분석

Core Concept: 이 질문은 ECS capacity provider를 사용하여 Amazon ECS 및 AWS Fargate에서 비용 최적화되고 가용성이 높은 확장을 테스트하며, Fargate(온디맨드)와 Fargate Spot(중단 위험이 있는 예비 용량) 간의 장단점을 다룹니다. Why the Answer is Correct: 게임은 연중무휴로 사용 가능해야 하며(안정적인 기본 용량은 신뢰할 수 있어야 함) 짧고 폭발적인 스파이크를 비용 효율적으로 처리해야 합니다. 가장 비용 효율적인 패턴은 가용성과 예측 가능한 용량을 보장하기 위해 일반 Fargate에서 정상 상태 서비스를 실행한 다음, 훨씬 저렴한 Fargate Spot을 폭증 용량으로 사용하는 것입니다. Spot 용량이 중단되거나 사용할 수 없게 되더라도 기본 서비스는 온디맨드 Fargate에서 정상 상태를 유지하여 연중무휴 가용성을 보존합니다. Key AWS Features: ECS capacity provider를 사용하면 Fargate 및 Fargate Spot 전반에 걸쳐 전략(base 및 weight)을 정의할 수 있습니다. 일반적인 접근 방식은 다음과 같습니다. - Base: Fargate의 N개 작업(보장된 기준선) - Weight: 스케일 아웃 시 Fargate Spot에 우선적으로 추가 작업 할당 이는 ECS Service Auto Scaling(CPU/메모리 또는 ALB 요청 수에 대한 대상 추적)과 통합됩니다. 복원력을 위해 여러 AZ에 걸쳐 여러 서브넷을 사용하고 서비스에 적절한 상태 확인 및 배포 설정이 있는지 확인합니다. Spot 중단 처리는 내재되어 있습니다. ECS는 중단된 Spot 작업을 중지하고 원하는 수에 따라 교체합니다. 혼합 전략을 사용하면 Spot이 제한될 경우 교체 작업이 Fargate에 배치될 수 있습니다. Common Misconceptions: "적절한 크기 조정(rightsizing)"(CloudWatch/Compute Optimizer)에 초점을 맞춘 옵션은 낭비를 줄일 수 있지만 폭증 비용 최적화를 직접적으로 해결하지는 않습니다. 또 다른 일반적인 함정은 정상 상태를 Spot에 두는 것입니다. 비용은 저렴하지만 Spot은 예고 없이 중단될 수 있으므로 연중무휴 가용성 요구 사항을 위반합니다. Exam Tips: "steady state + bursts" 및 "most cost-effective"를 보면 특히 상태 비저장 또는 수평 확장 가능한 워크로드의 경우 "온디맨드의 기준선, Spot의 폭증"을 생각하십시오. ECS/Fargate의 경우 시험에 친숙한 메커니즘은 Fargate 및 Fargate Spot을 Auto Scaling과 결합하는 ECS capacity provider 전략입니다. 질문에서 중단을 명시적으로 허용하지 않는 한 항상 Spot 사용을 중요하지 않거나 오버플로 용량에 매핑하십시오.

문제 8

(2개 선택)

한 금융 서비스 회사가 여러 Linux 서버에서 실행되는 컨테이너화된 마이크로서비스로 구성된 실시간 거래 플랫폼을 온프레미스에서 운영하고 있습니다. 이 플랫폼은 트랜잭션 데이터와 사용자 포트폴리오를 저장하는 MySQL 데이터베이스 클러스터에 연결됩니다. 현재 인프라는 거래 피크 시간대(시장 개장/폐장)에 확장을 위해 상당한 수동 개입이 필요하며, IT 팀은 기능 개발보다 인프라 유지 관리에 시간의 60%를 소비하고 있습니다. 이 회사는 운영 오버헤드를 줄이고, 용량 계획에 대한 우려를 없애며, 거래 피크 시 자동 확장을 활성화하고자 합니다. 솔루션은 고가용성을 유지하고 인프라 관리 부담을 줄이면서 컨테이너화된 애플리케이션을 지원해야 합니다. 솔루션 아키텍트가 이를 달성하기 위해 취해야 할 작업의 조합은 무엇입니까? (2개 선택)

문제 분석

핵심 개념: 이 질문은 온프레미스의 컨테이너 기반 피크 중심 워크로드를 최소한의 운영으로 고가용성 및 자동 확장을 제공하는 관리형 AWS 서비스로 마이그레이션하는 것을 테스트합니다. 핵심 서비스는 마이크로서비스를 위한 Amazon ECS와 함께 사용하는 AWS Fargate(서버리스 컨테이너)와 관리형 고가용성 관계형 데이터베이스를 위한 Multi-AZ가 적용된 Amazon RDS for MySQL입니다. 정답인 이유: 옵션 E(Fargate의 ECS)는 EC2 호스트 관리, OS 패치 또는 클러스터 용량 계획을 수행할 필요성을 제거합니다. 작업 CPU/메모리를 정의하고 ECS Service Auto Scaling(CPU/메모리에 대한 대상 추적 또는 사용자 지정 CloudWatch 지표)을 사용하여 시장 개장/폐장 시 스케일 아웃하고 이후에 스케일 인합니다. 이는 컨테이너를 지원하면서 "용량 계획에 대한 우려 제거" 및 "인프라 관리 부담 감소"를 직접적으로 해결합니다. 옵션 A(RDS for MySQL Multi-AZ)는 데이터베이스 관리 작업(백업, 패치, 모니터링 통합)을 오프로드하고 자동 장애 조치와 함께 다른 AZ의 대기 인스턴스로의 동기식 복제를 통해 고가용성을 제공합니다. 이는 운영 오버헤드를 줄이고 트랜잭션 및 포트폴리오 데이터에 대한 복원력을 향상시킵니다. 주요 AWS 기능: - AWS Fargate: 컨테이너를 위한 서버리스 컴퓨팅; EC2 관리 불필요; ECS 서비스, 작업용 IAM 역할 및 ALB와 통합. - ECS Service Auto Scaling: 대상 추적 정책; 예약된 확장은 예측 가능한 시장 이벤트와 일치시킬 수도 있습니다. - Amazon RDS for MySQL Multi-AZ: 자동 장애 조치, 관리형 백업, 유지 관리 기간 및 CloudWatch 지표. - 복원력 모범 사례: 상태 저장 구성 요소(데이터베이스) 및 수평 확장 가능한 상태 비저장 서비스(마이크로서비스)를 위한 Multi-AZ 설계. 일반적인 오해: EC2 Auto Scaling 그룹(옵션 B)은 확장이 가능하지만 여전히 AMI 수명 주기 관리, 패치 적용, 클러스터 크기 조정 및 용량 계획이 필요하므로 인프라 관리를 최소화하려는 목표에 어긋납니다. ElastiCache(옵션 C)는 성능을 향상시킬 수 있지만 그 자체로 확장/운영 부담을 없애지는 못하며 캐시 무효화의 복잡성을 추가합니다. 문제에서 요구하지도 않습니다. CloudWatch 경보(옵션 D)는 가시성을 향상시키지만 확장 작업과 결합하지 않는 한 본질적으로 자동 확장을 제공하거나 유지 관리를 줄이지는 않습니다. 시험 팁: 요구 사항이 "운영 오버헤드 감소", "용량 계획 없음" 및 "컨테이너"를 강조하는 경우 EC2 기반 컨테이너 호스팅보다 Fargate의 ECS(또는 Fargate의 EKS)를 기본으로 선택하십시오. 최소한의 관리로 고가용성이 필요한 MySQL의 경우 RDS Multi-AZ를 선택하십시오. 각 요구 사항을 명시적으로 매핑하십시오: 컴퓨팅 운영 감소를 위한 서버리스 컨테이너; 복원력 있는 상태를 위한 관리형 Multi-AZ 데이터베이스.

문제 9

글로벌 전자 상거래 플랫폼이 5개의 새로운 리전에서 동시에 운영을 시작합니다. 이 플랫폼은 현재 200만 명의 고객에게 서비스를 제공하고 있으며 6개월 이내에 800만 명의 고객에 도달할 것으로 예상합니다. 솔루션 아키텍트는 다양한 팀(Development, Operations, Marketing, Finance, Customer Support)에 걸쳐 150명 이상의 신규 직원을 위한 액세스 관리를 설정해야 합니다. 아키텍트는 팀 기능별로 사용자를 IAM 그룹으로 구성할 계획입니다. 신규 사용자에게 권한을 부여하는 가장 안전한 추가 작업은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 AWS IAM 자격 증명 기반 액세스 관리 모범 사례를 테스트합니다. 즉, IAM 그룹에 연결된 IAM 정책을 사용하여 권한을 할당하고, 최소 권한을 따르며, 많은 사용자를 위한 액세스 제어를 확장하는 방법을 묻습니다. 또한 IAM 그룹이 할 수 있는 것과 할 수 없는 것(그룹에는 역할을 "연결"할 수 없음)에 대한 이해를 암시적으로 테스트합니다. 정답인 이유: 직무별로 구성된 많은 신규 직원에게 권한을 부여하는 가장 안전하고 표준적인 접근 방식은 최소 권한 IAM 정책을 생성하고 해당 정책을 해당 IAM 그룹(예: Dev, Ops, Finance)에 연결하는 것입니다. 사용자는 그룹 멤버십을 통해 권한을 상속받으므로 관리가 중앙 집중화되고, 드리프트가 감소하며, 신속한 온보딩/오프보딩이 지원됩니다. 이는 AWS 보안 모범 사례 및 AWS Well-Architected 보안 원칙(최소 권한 구현 및 대규모 자격 증명 관리)과 일치합니다. 주요 AWS 기능: - IAM 그룹: 그룹에 정책을 연결하고 사용자를 추가/제거하여 대규모로 권한을 관리합니다. - 고객 관리형 IAM 정책: 각 팀의 직무에 맞게 조정된 재사용 가능하고 버전 제어가 가능한 정책입니다. - 최소 권한 기법: 최소한의 작업/리소스로 시작하고, 가능한 경우 리소스 수준 권한을 사용하며, 조건(예: aws:RequestedRegion, MFA 조건, 소스 IP, 태그 기반 액세스 제어)을 추가합니다. - 직무 분리: 팀별로 고유한 정책을 사용하여 광범위한 공유 권한을 방지합니다. 일반적인 오해: - SCP(옵션 A)는 AWS Organizations에서 계정/OU에 대한 가드레일을 설정하기 위한 것이며, IAM 사용자에게 권한을 부여하기 위한 것이 아닙니다. SCP는 권한을 부여하지 않으며, 자격 증명 정책이 허용할 수 있는 범위를 제한할 뿐입니다. - "그룹에 역할 연결"(옵션 B)은 IAM의 작동 방식이 아닙니다. 그룹은 역할을 자동으로 수임할 수 없습니다. 역할은 sts:AssumeRole을 통해 보안 주체(사용자, 서비스, 페더레이션 자격 증명)가 수임합니다. - 권한 경계(옵션 D)는 강력하지만 주로 관리를 위임하고 역할/사용자의 최대 권한을 제한하기 위한 것입니다. 자격 증명 정책을 통해 권한을 부여해야 하는 필요성을 대체하지 않으며, 주어진 시나리오에서 가장 중요한 "가장 안전한" 다음 단계가 아닙니다. 시험 팁: - 기억하세요: IAM 정책은 권한을 부여하고, SCP 및 권한 경계는 최대 한도를 설정합니다. - 직원 액세스의 경우 실제 설계에서는 IAM Identity Center(SSO)를 선호하지만, 시험에서 그룹이 명시적으로 언급된 경우 "IAM 그룹 + 최소 권한 정책"이 표준 정답입니다. - 옵션에서 그룹에 역할을 연결할 것을 제안한다면 이를 오답의 신호로 간주하세요. 그룹에는 역할이 아닌 정책을 연결합니다.

문제 10

회사는 Amazon CloudFront distribution이 SSL/TLS certificate를 사용하도록 구성하려고 합니다. 회사는 도메인 이름(예: 'www.example.com')을 소유하고 있으며 기본 CloudFront 도메인 이름 대신 이를 사용하려고 합니다. 회사는 custom domain에 대한 certificate를 배포해야 하며 추가 비용을 피하고자 합니다. 추가 비용 발생 없이 certificate를 배포할 수 있는 솔루션은 무엇입니까? 추가 비용 발생 없이 certificate를 배포할 수 있는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 Amazon CloudFront custom domain 이름(alternate domain names/CNAMEs)과 함께 SSL/TLS certificate를 사용하는 방법과 CloudFront에 대한 AWS Certificate Manager (ACM) 요금 및 리전 요구 사항이 어떻게 작동하는지 테스트합니다. 정답인 이유: CloudFront distribution에서 www.example.com과 같은 custom domain에 대해 HTTPS를 제공하려면 ACM certificate(또는 가져온 certificate)를 distribution에 연결해야 합니다. CloudFront의 경우 ACM certificate는 US East (N. Virginia) Region(us-east-1)에서 요청(또는 가져오기)해야 합니다. Public ACM certificate는 추가 비용 없이 발급됩니다. 따라서 us-east-1에서 Amazon 발급 public certificate를 요청하면 추가 certificate 비용 없이 CloudFront용 certificate가 배포됩니다. 주요 AWS 기능: - CloudFront Alternate Domain Names (CNAMEs): CloudFront가 기본 *.cloudfront.net 도메인 대신 www.example.com에 대한 요청에 응답하도록 합니다. - ACM Public Certificates: CloudFront와 같은 AWS 서비스와 함께 사용할 때 발급 및 갱신이 무료입니다. - CloudFront의 리전 요구 사항: CloudFront는 글로벌 서비스이지만 us-east-1에서만 ACM certificate를 가져옵니다. - Validation: 일반적으로 Route 53(또는 DNS 공급자)의 DNS validation을 통해 도메인 소유권을 검증하며, 이는 운영상 더 간단하고 자동 갱신을 지원합니다. 일반적인 오해: - “CloudFront certificate는 어느 리전에서나 작동한다”: 오답입니다. us-west-1(또는 us-east-1 이외의 리전)의 certificate는 CloudFront distribution용으로 선택할 수 없습니다. - “Private certificate도 무료이다”: 오답입니다. ACM Private CA(private certificate 발급에 사용됨)에는 지속적인 비용(월별 CA 요금 및 certificate당 요금)이 발생합니다. 또한 private certificate는 일반적으로 퍼블릭 인터넷 연결 CloudFront 엔드포인트가 아닌 내부/프라이빗 PKI 용도로 사용됩니다. 시험 팁: - 암기: CloudFront + ACM certificate는 반드시 us-east-1에 있어야 합니다. - 비용과 복잡성을 피하기 위해 인터넷 연결 도메인에는 public ACM certificate를 선호하십시오. - “추가 비용 방지(avoid additional costs)”라는 문구가 보이면 ACM Private CA 옵션을 제외하십시오. - custom domain을 사용할 때 CloudFront distribution을 가리키는 DNS(예: Route 53 ALIAS/AAAA)도 필요하다는 점을 기억하십시오. 하지만 여기서는 certificate 선택이 핵심 테스트 포인트입니다.

Practice Test #1

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(29)

다른 모의고사

Practice Test #2

Practice Test #3

Practice Test #4

Practice Test #5

Practice Test #6

Practice Test #7

Practice Test #8

Practice Test #9

Practice Test #10

지금 학습 시작하기