실전 문제

문제 1

웹 서비스가 load balancer 뒤의 EC2에서 실행되고 있지만, 많은 클라이언트가 방화벽을 통해 allowlist된 IP만 허용할 수 있습니다. 고정 IP를 통해 서비스에 접근할 수 있도록 해야 합니다. 무엇을 권장해야 합니까?

문제 2

글로벌 컨설팅 회사가 다양한 지역 사무소에 걸쳐 25개의 AWS 계정을 관리하기 위해 AWS Organizations를 사용하고 있습니다. 본사 IT 팀은 민감한 고객 계약 및 규정 준수 문서가 포함된 중앙 Amazon S3 버킷을 마스터 계정에서 유지 관리합니다. 최근 보안 감사로 인해, 이 회사는 AWS Organization 내의 계정에 속한 사용자만 이 중요한 S3 버킷에 액세스할 수 있도록 보장해야 합니다. 지속적인 관리 작업과 유지 관리 노력을 최소화하면서 AWS Organization 내의 계정 사용자에게만 S3 버킷 액세스를 제한하도록 액세스 제어를 구현해야 합니다. 최소한의 운영 오버헤드로 액세스 제어 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 AWS Organizations와 통합되는 IAM 정책 조건 키를 사용하여 Amazon S3 리소스 기반 액세스 제어를 테스트합니다. 목표는 지속적인 관리를 최소화하면서 특정 AWS Organization의 계정에 속한 보안 주체(사용자/역할)만 중앙 S3 버킷에 액세스할 수 있도록 제한하는 것입니다. 정답인 이유: S3 버킷 정책 조건 키인 aws:PrincipalOrgID를 사용하는 것은 '내 Organization의 보안 주체만' 액세스하도록 강제하는 가장 직접적이고 유지 관리가 적은 방법입니다. 버킷 정책에 Organization ID(o-xxxxxxxxxx)를 한 번 지정하면, S3는 요청 시 호출자의 보안 주체를 평가합니다. Organization의 멤버인 모든 계정은 자동으로 일치하며, Organization 외부의 계정은 거부됩니다(명시적 Deny와 결합하거나 Allow 문이 적절히 범위가 지정된 경우). 이를 통해 계정 ID를 나열하거나, 계정별 정책 문을 관리하거나, 계정이 가입/탈퇴할 때 정책을 업데이트할 필요가 없어집니다. 주요 AWS 기능: - S3 버킷 정책(리소스 기반 정책)은 글로벌 조건 키를 사용할 수 있습니다. - aws:PrincipalOrgID 조건 키는 특정 AWS Organization의 일부인 보안 주체로 액세스를 제한합니다. - 중앙 집중식 데이터 레이크, 공유 규정 준수 리포지토리 및 다중 계정 거버넌스 패턴과 잘 작동합니다. - AWS Well-Architected 보안 원칙과 일치: 최소 권한을 구현하고 구성 편차가 발생할 수 있는 수동 프로세스를 줄입니다. 일반적인 오해: - 많은 사람들이 버킷 정책에 모든 계정 ID를 나열해야 한다고 가정합니다. 이는 운영 오버헤드를 증가시키고 계정이 변경될 때 오류가 발생하기 쉽습니다. - 일부는 OU 기반 제어(경로)를 Organization 전체 제어와 혼동합니다. OU 경로는 유용할 수 있지만 더 복잡하며 조직 개편 시 변경될 수 있습니다. - 정책을 모니터링하고 자동 업데이트하는 것(CloudTrail + 자동화)은 강력해 보이지만, 네이티브 조건 키가 이미 동적 멤버십 적용을 제공하는 경우에는 불필요합니다. 시험 팁: '내 AWS Organization의 계정만' 및 '최소한의 운영 오버헤드'라는 문구를 보면 리소스 정책(S3, KMS 등)에서 aws:PrincipalOrgID를 찾으십시오. 요구 사항이 IAM 조건이 제공하는 것 이상의 사용자 지정 로직을 명시적으로 필요로 하지 않는 한, 이벤트 기반 자동화보다 네이티브 정책 조건을 선호하십시오.

문제 3

글로벌 스트리밍 미디어 회사가 여러 리전에서 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는 대규모 구조화된 행동 분석을 위한 일반적인 선택입니다.

문제 4

다국적 의료 기관이 15개의 의학 연구 애플리케이션을 여러 AWS 계정에 걸쳐 AWS로 이전하여 IT 인프라를 통합하고 있습니다. 이 기관은 임상 시험, 환자 데이터 분석 및 규정 준수 시스템을 위한 별도의 환경이 포함된 이러한 계정을 중앙에서 관리하기 위해 AWS Organizations를 사용합니다. IT 보안 팀은 2,000개 이상의 의료진 계정이 포함된 기존 온프레미스 Microsoft Active Directory 인프라를 통해 중앙 집중식 사용자 관리를 유지하면서 15개 AWS 계정 모두에서 작동하는 통합 SSO(Single Sign-On) 인증 시스템을 요구합니다. 이러한 요구 사항을 가장 효과적으로 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 기존 on-premises Microsoft Active Directory (AD)와 통합된 AWS IAM Identity Center(이전 명칭: AWS Single Sign-On)를 사용하여 AWS Organizations 내 여러 AWS accounts 전반에서 federated identity와 centralized access management를 테스트합니다. 정답인 이유: 가장 효과적인 접근 방식은 IAM Identity Center를 활성화하고 이를 조직의 기존 self-managed Microsoft AD에 연결하면서 user lifecycle과 group management를 AD에서 중앙 집중식으로 유지하는 것입니다. Option A는 IAM Identity Center가 사용하는 directory로 AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD)를 사용한 다음, AWS Managed Microsoft AD에서 on-prem AD로의 one-way trust를 설정함으로써 이를 수행합니다. 이를 통해 IAM Identity Center는 on-prem AD에 대해 사용자 인증을 수행하고(trust를 통해) 중앙에서 관리되는 일관된 permission sets와 assignments로 모든 15개 AWS accounts에 대한 SSO access를 제공할 수 있습니다. 주요 AWS 기능: IAM Identity Center는 AWS Organizations와 기본적으로 통합되어 여러 accounts 전반에서 SSO를 제공하며, 여기에는 account discovery와 centralized permission set management가 포함됩니다. AWS Managed Microsoft AD를 사용하면 AD trust relationships를 지원하는 managed되고 highly available한 AWS 내 AD를 제공할 수 있습니다. one-way trust(일반적으로 AWS Managed Microsoft AD가 on-prem AD를 신뢰)는 AWS 리소스가 on-prem identities를 인증할 수 있도록 하면서 on-prem domain이 AWS를 역으로 신뢰할 필요는 없게 하므로 위험과 복잡성을 줄이는 데 일반적으로 사용됩니다. 이는 least privilege와 통제된 trust boundaries에 부합합니다. 일반적인 오해: Two-way trust(Option B)는 더 “완전한” 것처럼 보일 수 있지만, trust boundary를 확장하며 AWS accounts로의 SSO에는 거의 필요하지 않습니다. 또한 추가적인 보안 고려 사항을 초래할 수 있습니다. Directory Service만 사용하는 것(Option C)은 여러 accounts 전반에서 통합된 AWS console/application SSO를 제공하지 않습니다. 이는 주로 directory-dependent workloads(예: Windows auth, LDAP/Kerberos 요구 사항)를 위한 것입니다. on-prem IdP를 배포하는 것(Option D)도 가능하지만, 운영 오버헤드를 추가하며 AWS Organizations와 AD 기반 user management를 사용해 모든 accounts 전반에서 centralized SSO를 요구하는 사항에 직접적으로 가장 잘 부합하지는 않습니다. 시험 팁: AWS Organizations를 사용하는 multi-account SSO의 경우, 먼저 IAM Identity Center를 떠올리세요. 엔터프라이즈 identity source가 Microsoft AD라면, 일반적인 시험 패턴은 IAM Identity Center + AWS Managed Microsoft AD + on-prem으로의 AD trust입니다. forests/domains 전반에서 양방향 리소스 access를 요구하는 특정 요구 사항이 없는 한 one-way trust를 선호하세요.

문제 5

한 금융 기술 스타트업이 모바일 뱅킹 애플리케이션을 구축 중이며 AWS에 프로토타입 인프라를 수동으로 생성했습니다. 인프라는 EC2 인스턴스가 있는 Auto Scaling 그룹, 고성능 트래픽 처리를 위한 Network Load Balancer, 트랜잭션 처리를 위한 Amazon Aurora MySQL 클러스터로 구성됩니다. 보안 규정 준수 검증을 완료한 후, 회사는 4주 후로 예정된 출시를 지원하기 위해 완전히 자동화된 방식으로 스테이징 및 프로덕션 환경 모두에 대해 3개의 가용 영역(Availability Zone)에 걸쳐 동일한 인프라를 신속하게 배포해야 합니다. 이러한 요구 사항을 충족하기 위해 솔루션 아키텍트는 무엇을 권장해야 합니까?

문제 분석

핵심 개념: 이 질문은 여러 가용 영역(AZ) 및 여러 환경(스테이징 및 프로덕션)에 걸쳐 반복 가능하고 자동화된 환경 프로비저닝을 위한 코드형 인프라(IaC)를 테스트합니다. 주요 AWS 서비스는 AWS CloudFormation(또는 동급의 IaC)이며, 이는 동일하고 규정을 준수하는 스택을 신속하게 배포하기 위한 표준 시험 정답입니다. 정답인 이유: 보안 규정 준수 검증 후 회사는 동일한 아키텍처를 빠르고 일관되게 재현해야 합니다. CloudFormation 템플릿(잠재적으로 프로토타입을 참조로 생성됨)을 사용하면 스타트업이 Auto Scaling 그룹, Network Load Balancer 및 Aurora MySQL 클러스터를 선언적으로 정의하고 완전히 자동화된 방식으로 배포할 수 있습니다. CloudFormation은 3개의 AZ에 서브넷을 정의하고, NLB를 해당 서브넷과 연결하고, Auto Scaling 그룹이 이를 포괄하도록 구성하고, 해당 AZ에 걸쳐 DB 서브넷 그룹(및 필요에 따라 다중 AZ/복제본)으로 Aurora를 구성하여 다중 AZ 설계를 지원합니다. 스테이징 및 프로덕션을 위해 별도의 스택(또는 파라미터화된 스택)을 배포하여 환경별 파라미터가 있는 동일한 토폴로지를 보장할 수 있습니다. 주요 AWS 기능: CloudFormation은 변경 세트, 드리프트 감지, 스택 정책, 중첩 스택/모듈, 환경 차이(인스턴스 유형, 확장 제한, DB 크기, 태그)에 대한 파라미터화를 제공합니다. 자동화된 배포를 위해 CI/CD(CodePipeline/CodeBuild)와 통합되며 AWS Secrets Manager/SSM Parameter Store에 대한 동적 참조를 통해 보안 암호의 안전한 처리를 지원합니다. 이는 안정성(다중 AZ), 보안(반복 가능한 제어) 및 운영 우수성(자동화)에 대한 Well-Architected 모범 사례와 일치합니다. 일반적인 오해: Systems Manager Automation은 운영 런북을 오케스트레이션할 수 있지만 기존 프로토타입을 "캡처"하고 전체 인프라를 제품화되고 버전 제어되는 배포로 안정적으로 재생성하는 기본 도구는 아닙니다. AWS Config는 규정 준수를 인벤토리화하고 평가합니다. 자동 수정은 전체 다중 계층 환경을 프로비저닝하는 것이 아니라 드리프트/규정 위반을 수정하기 위한 것입니다. Elastic Beanstalk는 애플리케이션 플랫폼 추상화이며 네트워킹, 확장 및 데이터베이스 토폴로지에 대한 명시적 제어가 필요한 사용자 지정 NLB + Aurora 뱅킹 아키텍처에는 자연스럽게 맞지 않습니다. 시험 팁: "동일한 인프라 신속 배포(rapidly deploy identical infrastructure)", "완전 자동화(fully automated)", "다중 AZ(multiple AZs)" 및 "다중 환경(multiple environments)"이 보이면 기본적으로 IaC(CloudFormation/CDK/Terraform)를 선택하십시오. CloudFormation은 표준 AWS 네이티브 정답입니다. "프로토타입이 이미 존재함(prototype already exists)" 및 "반복 가능성과 일관성 필요(need repeatability and consistency)"와 같은 문구를 찾아 스테이징 대 프로덕션을 위한 IaC 및 파라미터화된 스택을 강화하십시오.

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

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

문제 6

한 회사가 매일 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(백업용) 및 수명 주기 정책을 찾으십시오. 시간 제한 보존 및 최소한의 사용자 지정 자동화를 통해 삭제 후 복구 가능성을 직접 제공하는 옵션을 선택하십시오.

문제 7

회사는 중요한 Amazon Machine Image(AMI)를 많이 저장합니다. 우발적으로 삭제된 AMI를 최소한의 노력으로 신속하게 복구할 수 있는 솔루션이 필요합니다. 우발적인 삭제로부터 AMI/스냅샷을 보호하고 쉽게 복구할 수 있도록 해야 합니다. 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 중요한 Amazon Machine Images (AMIs)를 실수로 삭제하는 것으로부터 보호하면서, 복구는 간단하게 유지하고 운영 노력은 낮게 유지하는 것에 관한 것입니다. 핵심 아이디어는 AMI의 복구 가능한 복사본을 별도의 AWS account에 유지하여 원본 AMI가 삭제되더라도 회사가 backup account에서 이를 복원하거나 다시 복사할 수 있도록 하는 것입니다. Cross-account AMI copy는 AMI와 연결된 snapshots를 함께 보존하므로 일반적인 AWS 보호 패턴입니다. 정답인 이유: AMIs를 다른 AWS account로 주기적으로 복사하면 전체 AMI 리소스에 대해 간단한 backup 및 recovery 메커니즘을 제공합니다. 단순히 기본 snapshots만이 아닙니다. 기본 account에서 AMI가 실수로 삭제되더라도 backup 복사본은 secondary account에 계속 남아 있으며, 다시 공유하거나 복사해 올 수 있습니다. 이 접근 방식은 한 account에서의 사용자 실수로 인한 영구 손실 위험을 줄여 주며, snapshots로부터 수동으로 AMIs를 다시 구축하는 것보다 운영하기가 더 쉽습니다. 주요 특징: - AMI copy에는 image로부터 instances를 시작하는 데 필요한 연결된 EBS snapshots가 포함됩니다. - 별도의 AWS account는 source account에서의 실수로 인한 삭제로부터 격리를 제공합니다. - 이 프로세스는 AWS Backup, EventBridge, Lambda 또는 custom scripts를 사용하여 일정에 따라 자동화할 수 있습니다. - 복구 시 재구성이 필요하지 않고 이미 사용 가능한 image로서 AMI가 존재하므로 더 간단합니다. 흔한 오해: - Recycle Bin은 삭제된 리소스의 보존에 유용하지만, 문제가 삭제된 AMIs 또는 snapshots에 대한 retention rules에 명시적으로 초점을 맞추지 않는 한 포괄적인 AMI 보호에 대한 예상 정답은 항상 아닙니다. 또한 사전 구성이 필요하며 별도 account만큼의 격리 이점을 제공하지 않을 수 있습니다. - snapshots만 복사하면 AMI registration metadata는 보존되지 않으므로, AMI를 다시 생성하려면 추가 단계가 필요합니다. - AMIs는 Cross-Region Replication을 위해 S3 buckets에 업로드되지 않습니다. 시험 팁: 문제가 중요한 AMIs를 실수로 삭제하는 것으로부터 보호하고 recovery를 가능하게 하는 것을 강조한다면, AMI를 복구 가능한 artifact로 보존하는 솔루션을 우선적으로 선택하세요. Cross-account AMI copies는 machine images에 대한 전형적인 AWS backup 패턴입니다. 반대로 문제가 policy 기반 undelete를 통해 삭제된 EBS snapshots 또는 삭제된 AMIs의 보존을 구체적으로 언급한다면, Recycle Bin이 더 관련성이 높아집니다.

문제 8

미디어 제작 회사가 5MB에서 300GB에 이르는 대용량 오디오 파일을 온프레미스 NFS 스토리지 시스템에 저장하고 있습니다. 총 스토리지 용량은 85TB이며 정적이고 더 이상의 증가는 예상되지 않습니다. 이 회사는 마이그레이션 프로세스 동안 네트워크 대역폭 사용을 최소화하면서 가능한 한 빨리 모든 오디오 파일을 Amazon S3로 마이그레이션하고자 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 (1) 빠르게 마이그레이션해야 하고 (2) 네트워크 대역폭 사용을 최소화해야 할 때 Amazon S3로의 가장 적절한 데이터 마이그레이션 방법을 선택하는 것을 테스트합니다. 핵심 AWS 개념은 온라인 전송 방법(AWS CLI, Storage Gateway, Direct Connect)과 대비되는 AWS Snow Family(Snowball Edge)를 사용한 "오프라인/물리적 데이터 전송"입니다. 정답인 이유: 85TB의 정적 데이터와 마이그레이션 중 네트워크 대역폭을 최소화해야 하는 요구 사항이 있으므로 AWS Snowball Edge가 가장 적합합니다. Snowball은 로컬 네트워크(고처리량 LAN 복사)를 통해 온프레미스에서 데이터를 로드한 다음, AWS가 데이터를 Amazon S3로 직접 가져오는 AWS로 다시 배송하는 물리적 어플라이언스를 제공합니다. 이 접근 방식은 회사의 인터넷/WAN 대역폭 소비를 크게 방지하며, 제한된 네트워크 링크를 통해 85TB를 푸시하는 것보다 일반적으로 엔드투엔드로 더 빠릅니다. 주요 AWS 기능: Snowball Edge는 S3로의 대규모 데이터 전송을 지원하며 오프라인 마이그레이션을 위해 설계되었습니다. Snowball 클라이언트(또는 디바이스/옵션에 따라 S3 호환 인터페이스)를 사용하여 디바이스로 데이터를 복사합니다. AWS는 안전한 전송과 변조 방지 하드웨어를 처리하며, 데이터는 엔드투엔드로 암호화됩니다. 85TB의 경우 사용 가능한 용량에 따라 하나 이상의 디바이스를 주문하고 로딩을 병렬화하여 마이그레이션을 가속화할 수 있습니다. 일반적인 오해: Storage Gateway(S3 File Gateway)는 S3를 NFS로 제공할 수 있지만 여전히 네트워크를 통해 AWS로 데이터를 업로드합니다. 이는 대역폭 사용이 아니라 애플리케이션 변경을 줄여줍니다. Direct Connect는 일관성을 향상시키고 처리량을 늘릴 수 있지만 여전히 네트워크 대역폭을 사용하며 리드 타임과 비용이 필요합니다. AWS CLI 직접 업로드는 가장 간단하지만 대역폭을 가장 많이 사용하며 수십 TB의 경우 종종 느립니다. 시험 팁: "수십 TB 이상"과 "네트워크 대역폭 최소화" 또는 "제한된 연결성"이 보이면 기본적으로 Snowball/Snowmobile을 선택하십시오. 최소한의 WAN 사용으로 일회성 대량 마이그레이션을 수행할 때가 아니라 지속적인 하이브리드 액세스/캐싱이 필요할 때 Storage Gateway를 사용하십시오. Direct Connect는 일회성 마이그레이션을 시작하는 가장 빠른 방법이 아니라 안정적이고 예측 가능한 네트워크 연결 요구 사항을 위한 것입니다.

문제 9

한 금융 서비스 회사가 일일 트랜잭션 조정 보고서를 처리하는 레거시 배치 처리 시스템을 현대화하고 있습니다. 현재 시스템은 조정 작업을 여러 처리 워커에 분배하는 중앙 코디네이터 서버를 사용합니다. 워크로드는 크게 변동합니다. 월말 기간에는 처리량이 300% 증가할 수 있는 반면, 주말에는 활동이 최소화됩니다. 이 회사는 운영 오버헤드를 최소화하면서 가변적인 워크로드를 효율적으로 처리하기 위해 최대의 복원력과 자동 조정 기능을 갖춘 AWS로 이 시스템을 마이그레이션해야 합니다. 솔루션 아키텍트는 이러한 요구 사항을 충족하기 위해 아키텍처를 어떻게 설계해야 합니까?

문제 분석

핵심 개념: 이 질문은 대기열 기반 워커 패턴과 이벤트 기반 조정을 사용하여 AWS에서 분리되고 복원력 있는 배치 처리를 테스트합니다. 핵심 서비스는 내구성 있는 작업 버퍼링을 위한 Amazon SQS와 탄력적인 워커 플릿을 위한 EC2 Auto Scaling입니다. 정답인 이유: 옵션 B는 확장 및 가용성 병목 현상인 단일 "중앙 코디네이터"를 제거하고 고가용성, 내구성 있는 메시지 스토리지 및 자연스러운 백프레셔를 제공하는 SQS로 대체하기 때문에 최상의 설계입니다. 워커는 SQS를 폴링하고 작업을 독립적으로 처리합니다. SQS 대기열 깊이(예: ApproximateNumberOfMessagesVisible 및/또는 ApproximateNumberOfMessagesNotVisible)를 기반으로 워커 Auto Scaling 그룹을 조정하면 용량이 미해결 작업에 직접 맞춰집니다. 이는 예측할 수 없는 급증(예: 월말 +300%)에 대한 자동 조정을 제공하고 활동이 적은 기간(주말)에는 축소하여 운영 오버헤드를 최소화합니다. 주요 AWS 기능: - SQS standard queue: 다중 AZ, 확장성이 뛰어난 버퍼링; 최소 한 번 전송(at-least-once delivery) 지원. - Visibility timeout: 여러 워커가 동일한 작업을 동시에 처리하는 것을 방지; 최대 처리 시간에 맞춰 조정. - Dead-letter queue (DLQ): maxReceiveCount 이후 포이즌 메시지 격리. - SQS 지표에 대한 target tracking/step scaling이 있는 EC2 Auto Scaling(종종 CloudWatch alarms를 통해): 배치 작업의 처리량과 더 직접적으로 연결된 CPU가 아닌 백로그를 기반으로 조정. - 복원력 모범 사례: 여러 AZ에 걸친 상태 비저장(stateless) 워커; 간헐적인 중복 전송을 처리하기 위한 멱등성(idempotent) 처리. 일반적인 오해: Scheduled scaling(옵션 A)은 회사에 알려진 월말 피크가 있기 때문에 매력적으로 보일 수 있지만, 계획되지 않은 급증에는 실패하고 조용한 기간에는 과도하게 프로비저닝될 수 있습니다. CPU 기반 조정(옵션 C/D)은 간접적이며 지연될 수 있습니다. 백로그가 증가하는 동안(I/O 바운드 작업) CPU가 낮거나 시끄러운 이웃(noisy neighbors)으로 인해 CPU가 높아 불안정한 조정으로 이어질 수 있습니다. CloudTrail은 작업 분배 메커니즘이 아닙니다. 시험 팁: 가변적인 배치/워커 워크로드의 경우 "SQS + Auto Scaling 워커"를 선호하고 코디네이터 CPU가 아닌 대기열 깊이/백로그를 기반으로 조정하십시오. 단일 장애점을 제거하고 분리 및 복원력을 위해 관리형 서비스를 사용하는 설계를 찾으십시오(AWS Well-Architected Reliability 원칙).

문제 10

사용자는 SAML과 호환되지 않는 온프레미스 LDAP 디렉터리를 사용하여 AWS Management Console에 인증해야 합니다. 기존 LDAP를 IdP로 사용하여 콘솔 액세스를 제공해야 합니다. 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 엔터프라이즈 자격 증명 소스가 SAML을 지원하지 않는 온프레미스 LDAP 디렉터일 때 AWS Management Console에 대한 연동 액세스를 테스트합니다. 핵심 AWS 개념은 연동, 임시 자격 증명, 그리고 장기 IAM 사용자를 관리하는 대신 AWS Security Token Service(AWS STS)를 사용하여 수명이 짧은 세션을 얻는 것입니다. 정답인 이유: LDAP 디렉터리가 SAML과 호환되지 않기 때문에 AWS 콘솔에 대한 표준 SAML 연동을 직접 사용할 수 없습니다. 확립된 패턴은 LDAP 앞에 자격 증명 변환 계층(자격 증명 브로커)을 배치하는 것입니다. 브로커는 LDAP에 대해 사용자를 인증한 다음 AWS STS(일반적으로 AssumeRole)를 호출하여 해당 사용자/그룹에 매핑된 IAM 역할에 대한 임시 자격 증명을 얻습니다. 그런 다음 브로커는 STS 세션 자격 증명을 AWS 콘솔 세션으로 교환하는 연동 로그인 URL(연동 엔드포인트 사용)을 생성하여 콘솔 액세스를 활성화합니다. 이는 사용자가 기존 LDAP로 인증하고 수명이 짧은 자격 증명을 통해 AWS 액세스 권한이 부여된다는 요구 사항을 충족합니다. 주요 AWS 기능: - 제한된 기간의 임시 자격 증명을 발급하는 AWS STS AssumeRole. - 브로커(또는 제한된 AWS 보안 주체)가 역할을 수임할 수 있도록 허용하는 신뢰 정책이 있는 IAM 역할. - 역할에 연결된 IAM 정책을 통한 세분화된 권한 부여, 종종 LDAP 그룹에서 매핑됨. - 장기 IAM 사용자 자격 증명을 피하고 LDAP에서 중앙 집중식 자격 증명 수명 주기를 활성화하여 운영 위험 감소. 일반적인 오해: 많은 사람들이 IAM Identity Center가 LDAP에 "직접" 연결될 수 있다고 가정합니다. 실제로 IAM Identity Center는 SAML 2.0(및 특정 디렉터리 통합)을 통해 외부 자격 증명 공급자를 지원하지만, LDAP 자체는 AWS 콘솔 로그인을 위한 연동 프로토콜이 아닙니다. 또 다른 오해는 LDAP 변경 사항을 기반으로 IAM 사용자 자격 증명을 동기화하거나 교체하려는 것입니다. 이는 불안정하고 안전하지 않으며 AWS 모범 사례에 위배됩니다. 시험 팁: "SAML과 호환되지 않는 LDAP"와 "AWS Management Console 액세스"가 보이면 "사용자 지정 자격 증명 브로커 + STS + 연동 콘솔 URL"을 생각하십시오. IAM 사용자보다 임시 자격 증명 및 역할 기반 액세스를 선호하십시오. 또한 AWS 자격 증명을 LDAP에 포함하거나 시스템 간에 암호/자격 증명 교체를 관리하려고 시도하는 대신 엔터프라이즈 그룹을 IAM 역할/정책에 매핑하십시오.

문제 11

한 의료 컨설팅 회사가 원격 환자 상담을 진행하고 규정 준수를 위해 모든 비디오 상담 녹화본을 Amazon S3 버킷에 저장합니다. 이 회사는 분석 및 보고를 위해 비디오 파일에서 음성 콘텐츠를 추출해야 합니다. 회사는 HIPAA 규정 준수를 유지하기 위해 추출된 텍스트에서 모든 환자 건강 정보(PHI) 및 개인 식별 정보(PII)를 자동으로 제거해야 합니다. 솔루션은 파일이 업로드될 때 자동으로 파일을 처리하고 삭제 처리된(sanitized) 트랜스크립트를 별도로 저장해야 합니다. 솔루션 아키텍트는 이러한 요구 사항을 충족하기 위해 무엇을 해야 합니까?

문제 분석

핵심 개념: 이 질문은 미디어 파일에서 음성을 텍스트로 변환하고 HIPAA에 부합하는 비식별화를 보장하기 위해 올바른 관리형 AWS AI 서비스를 선택하는 것을 테스트합니다. 핵심 서비스는 Amazon Transcribe(음성 인식) 및 내장된 PII redaction 기능이며, Amazon S3 + AWS Lambda를 사용한 이벤트 기반 자동화가 포함됩니다. 정답인 이유: 옵션 C는 (1) 업로드된 비디오 녹화본에서 음성 콘텐츠를 자동으로 전사하고, (2) 트랜스크립트에서 PII/PHI를 자동으로 제거하며, (3) 삭제 처리된 출력을 별도로 저장하는 모든 요구 사항을 직접 충족합니다. Amazon Transcribe는 S3에 저장된 비디오 파일의 오디오 트랙에서 전사를 지원하며 PII redaction 기능을 사용하여 수정된 트랜스크립트를 생성할 수 있습니다. S3 이벤트 알림을 사용하여 Lambda를 호출하는 것은 새 객체가 업로드될 때마다 Transcribe 작업을 시작하는 표준 서버리스 패턴입니다. 수정된 출력을 별도의 S3 버킷에 기록하면 규정 준수 제어(민감한 데이터와 삭제 처리된 데이터의 분리)를 지원하고 다운스트림 분석을 간소화합니다. 주요 AWS 기능: - 객체 생성 시 처리를 트리거하는 Amazon S3 이벤트 알림. - 오케스트레이션을 위한 AWS Lambda: Transcribe 작업 시작, 입력 S3 URI 전달, 출력 버킷/접두사 지정, ContentRedaction(PII redaction) 활성화. - Amazon Transcribe PII redaction: 트랜스크립트에서 감지된 PII(예: 이름, 주소, 전화번호)를 수정하고 수정된 텍스트를 출력하여 사용자 지정 로직의 필요성을 줄일 수 있습니다. - 보안 모범 사례: 별도의 버킷, Lambda/Transcribe에 대한 최소 권한 IAM, S3 SSE-KMS 암호화, 버킷 정책 및 액세스 로깅. 이는 AWS Well-Architected Security 원칙(데이터 보호, 최소 권한, 감사 가능성)과 일치합니다. 일반적인 오해: A는 유연해 보일 수 있지만 S3의 파일 기반 배치 전사에는 Kinesis가 불필요하며, 정규식 기반 PHI/PII 제거는 오류가 발생하기 쉽고 규정 준수에 위험합니다. B는 Textract가 비디오/오디오의 음성이 아니라 문서/이미지에서 텍스트를 추출하기 때문에 오답입니다. D는 솔루션을 지나치게 복잡하게 만듭니다. Chime SDK 미팅 흐름은 저장된 녹화본을 처리하는 것이 아니라 라이브 미팅을 위한 것입니다. Comprehend Medical은 의료 엔터티를 감지할 수 있지만 Transcribe의 기본 redaction에 비해 가장 간단하거나 직접적인 요구 사항은 아닙니다. 시험 팁: 오디오/비디오에서 "음성 콘텐츠 추출"이 보이면 Amazon Transcribe를 생각하십시오. "자동으로 PII 제거"가 보이면 Transcribe PII redaction(또는 텍스트 분류를 위한 Comprehend, 단 redaction이 기본적으로 지원되지 않는 경우에만)을 찾으십시오. "업로드 시 처리"의 경우 기본적으로 S3 이벤트 알림 + Lambda 오케스트레이션을 사용하고 삭제 처리된 출력을 엄격하게 제어되는 별도의 위치에 저장하십시오.

문제 12

한 의료 기관이 Amazon RDS MySQL 데이터베이스와 함께 Amazon EC2 인스턴스에서 환자 관리 시스템을 실행하고 있습니다. 애플리케이션은 현재 각 EC2 인스턴스의 구성 파일에 저장된 하드코딩된 자격 증명을 사용하여 데이터베이스에 연결합니다. 이 기관은 여러 가용 영역에 걸쳐 15개의 EC2 인스턴스를 보유하고 있으며 HIPAA 보안 요구 사항을 준수해야 합니다. 보안 팀은 하드코딩된 데이터베이스 자격 증명을 제거하고 자격 증명 관리의 관리 부담을 줄이는 동시에 민감한 환자 데이터에 대한 안전한 액세스를 보장하고자 합니다. 솔루션 아키텍트는 이러한 보안 및 운영 요구 사항을 충족하기 위해 무엇을 권장해야 합니까?

문제 분석

핵심 개념: 이 질문은 특히 규제 대상 워크로드(HIPAA)에 대한 데이터베이스 자격 증명의 안전한 보안 암호 저장 및 수명 주기 관리를 테스트합니다. 핵심 AWS 서비스는 보안 암호를 저장하고 자동으로 교체하도록 특별히 제작된 AWS Secrets Manager입니다. 정답인 이유: AWS Secrets Manager는 보안 암호를 중앙 집중화하고 애플리케이션(또는 부트스트랩 스크립트/사이드카)이 IAM 권한을 사용하여 런타임에 자격 증명을 검색할 수 있도록 함으로써 15개의 EC2 인스턴스에서 하드코딩된 자격 증명을 제거합니다. Amazon RDS MySQL 데이터베이스의 경우 Secrets Manager는 AWS 관리형 교체 Lambda 템플릿을 사용하여 기본 통합 및 자동 교체를 지원합니다. 이는 관리 부담(인스턴스 전반에 걸친 수동 암호 변경 없음)을 줄이고 주기적인 교체를 강제하며 자격 증명 스프롤을 최소화하여 보안 태세를 개선합니다. 이는 HIPAA의 액세스 제어 및 감사 기대치에 중요합니다. 주요 AWS 기능 / 모범 사례: - 자동 교체: RDS 암호와 저장된 보안 암호를 원자적으로 업데이트하는 교체 Lambda를 사용하여 교체(예: 30일마다)를 구성합니다. - 세분화된 액세스 제어: EC2 인스턴스에서 IAM 역할을 사용하여 특정 보안 암호에 대해서만 secretsmanager:GetSecretValue를 허용합니다. 파일을 통해 자격 증명을 배포하지 마십시오. - 암호화 및 감사: 보안 암호는 AWS KMS로 암호화되며 액세스는 AWS CloudTrail에 기록되어 규정 준수 증거를 지원합니다. - 다중 AZ EC2 플릿: 모든 인스턴스는 AZ 간에 파일을 복사하지 않고도 동일한 보안 암호를 안전하게 검색할 수 있습니다. 일반적인 오해: Parameter Store(SecureString)는 암호화된 값을 저장할 수 있지만 Secrets Manager만큼 RDS 자격 증명에 대한 최고 수준의 관리형 보안 암호 교체 워크플로를 제공하지는 않습니다. S3/EBS 암호화는 저장 데이터를 보호하지만 보안 암호 배포, 교체 조정 또는 최소 권한 런타임 검색을 해결하지는 않습니다. 시험 팁: "하드코딩된 자격 증명 제거"와 "관리 부담 감소" 및 "교체"가 보이면 기본적으로 Secrets Manager(특히 RDS의 경우)를 선택하십시오. 교체가 주요 요구 사항이 아닐 때 구성 값과 더 간단한 보안 암호에는 Parameter Store를 사용하십시오. 규정 준수 시나리오의 경우 IAM 최소 권한, KMS 암호화 및 CloudTrail 감사를 지원 제어로 고려하십시오.

문제 13

전자 상거래 회사의 마케팅 팀이 다가오는 Black Friday 할인 캠페인을 위한 프로모션 랜딩 페이지를 생성해야 합니다. 랜딩 페이지에는 제품 이미지, 프로모션 비디오, CSS 스타일링, 제품 캐러셀을 위한 대화형 JavaScript 요소 및 HTML 콘텐츠가 포함됩니다. 마케팅 팀은 캠페인 기간 동안 약 50,000명의 방문자를 예상하고 있으며, 이 정적 프로모션 콘텐츠를 호스팅하기 위해 가장 예산 친화적인 솔루션이 필요합니다. 이 페이지는 최소한의 인프라 관리 오버헤드로 전 세계 고객이 액세스할 수 있어야 합니다. 이 프로모션 랜딩 페이지에 가장 비용 효율적인 호스팅 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 최소한의 운영 오버헤드로 정적 웹 콘텐츠를 위한 비용 최적화된 호스팅을 테스트합니다. 주요 AWS 기능은 Amazon S3 static website hosting입니다(글로벌 성능을 위해 종종 Amazon CloudFront와 결합되지만, S3만으로도 요구 사항을 충족합니다). 정답인 이유: Amazon S3 static website hosting은 정적 자산(HTML, CSS, JavaScript, 이미지 및 비디오)을 제공하기 위한 가장 비용 효율적이고 관리가 적은 옵션입니다. 약 50,000명의 방문자가 있는 경우 S3는 서버, 로드 밸런서 또는 컨테이너 클러스터를 프로비저닝하지 않고도 자동으로 확장됩니다. 주로 스토리지 및 데이터 전송/요청에 대해서만 비용을 지불하므로 기한이 정해진 마케팅 캠페인에 예산 친화적입니다. 패치 적용, 용량 계획 또는 인스턴스 크기 조정이 없으므로 최소한의 인프라 관리가 필요한 마케팅 팀에 이상적입니다. 주요 AWS 기능: S3 static website hosting을 사용하면 인덱스 문서 및 오류 문서를 설정하고 HTTP를 통해 직접 콘텐츠를 제공할 수 있습니다. 프로덕션 수준의 글로벌 전송을 위한 일반적인 모범 사례는 S3 버킷 앞에 CloudFront를 배치하여 전 세계적으로 지연 시간을 줄이고, 트래픽을 오프로드하며, ACM 인증서 및 AWS WAF 보호를 통해 HTTPS를 추가하는 것입니다. CloudFront Origin Access Control (OAC)를 사용하여 액세스를 제어함으로써 버킷을 비공개로 유지하면서도 전 세계적으로 콘텐츠를 제공할 수 있습니다. 이러한 향상된 기능은 상당한 운영 부담 없이 성능과 보안을 개선합니다. 일반적인 오해: 팀은 "웹 서버"에 익숙하기 때문에 종종 EC2/ECS를 기본값으로 선택하지만, 정적 사이트의 경우 이는 불필요한 컴퓨팅 비용과 운영 작업(패치 적용, 확장, 모니터링)을 초래합니다. API Gateway + Lambda는 동적 렌더링에 강력하지만, 단순한 정적 페이지의 경우 과도하며 대규모에서는 더 많은 비용이 들 수 있습니다. 시험 팁: "정적 콘텐츠(static content)", "글로벌 사용자(global users)", "최소한의 관리(minimal management)", "가장 비용 효율적인(most cost-effective)"이라는 단어를 보면 S3 static website hosting(및 선택적으로 CloudFront)을 생각하십시오. 서버 측 처리, 사용자 지정 런타임 또는 복잡한 애플리케이션 로직이 필요한 경우에만 EC2/ECS를 예약하십시오. 마케팅 랜딩 페이지의 경우 비용 최적화 시나리오에서 S3가 표준 정답입니다. 참조: Amazon S3에서 정적 웹 사이트 호스팅 및 정적 콘텐츠 전송을 위한 CloudFront 모범 사례에 대한 AWS 설명서.

문제 14

(2개 선택)

한 의료 기관이 3개의 다른 시설에 걸쳐 15대의 Linux 기반 연구 데이터 서버를 운영하고 있습니다. 각 서버에는 규정 준수 목적으로 보존해야 하는 엄격한 POSIX 파일 권한 및 심볼릭 링크(symbolic links)가 포함된 중요한 환자 연구 데이터가 있습니다. 이 기관은 고성능 컴퓨팅 워크로드를 위해 모든 연구 데이터를 Amazon FSx for Lustre 파일 시스템으로 통합해야 합니다. 마이그레이션 중에 POSIX 권한, 심볼릭 링크 및 메타데이터를 보존해야 합니다. 총 데이터 크기는 약 500TB입니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까? (2개 선택)

문제 분석

핵심 개념: 이 문제는 POSIX permissions, symbolic links, metadata를 보존하면서 매우 큰 온프레미스 Linux 데이터셋을 Amazon FSx for Lustre로 마이그레이션하는 것에 관한 것입니다. 핵심 과제는 여러 시설에 걸쳐 있는 500 TB 규모의 파일시스템 인지 전송을 처리할 수 있는 AWS 마이그레이션 서비스를 선택하는 것입니다. DataSync는 파일 전송 중 POSIX metadata를 보존하도록 설계된 AWS 서비스이며, 네트워크 기반 전송이 비현실적인 경우 Snowball Edge를 사용할 수 있습니다. 흔한 시험 함정은 모든 AWS 파일 서비스가 DataSync의 직접 대상이라고 가정하거나, S3 staging이 항상 별다른 조건 없이 파일시스템 semantics를 보존한다고 생각하는 것입니다. 정답인 이유: Option D가 정답인 이유는 Snowball Edge Storage Optimized 디바이스를 각 사이트에 배치하고 DataSync와 함께 사용하여 대규모 파일 마이그레이션을 수행하면서 파일 attributes를 보존할 수 있기 때문입니다. Option C도 제공된 선택지의 맥락에서는 허용 가능한 또 다른 정답입니다. 네트워크 전송에 제약이 있을 수 있는 500 TB 규모에서는 데이터를 AWS로 물리적으로 배송하여 대량 수집하는 방식이 유효한 패턴이며, 이후 DataSync가 데이터를 다음 단계로 이동시킬 수 있기 때문입니다. S3는 기본 POSIX semantics를 보존하는 데 이상적이지 않지만, 시험 스타일의 의도는 이 규모에 적합한 AWS 관리형 대량 전송 메커니즘을 식별하는 것입니다. 주요 기능: AWS DataSync는 지원되는 파일 기반 스토리지 시스템 간 전송 시 ownership, permissions, timestamps, symbolic links를 보존합니다. Snowball Edge Storage Optimized는 디바이스당 수십에서 수백 테라바이트에 적합하며 여러 시설에서 병렬로 사용할 수 있습니다. WAN bandwidth가 충분하지 않아 적시에 마이그레이션하기 어려운 경우에는 대량 오프라인 전송 서비스가 선호되는 경우가 많습니다. 흔한 오해: 대표적인 오해 중 하나는 DataSync가 모든 AWS 파일 서비스에 직접 쓸 수 있다고 생각하는 것입니다. 실제 지원 여부는 서비스별로 다릅니다. 또 다른 오해는 S3가 POSIX metadata에 대해 파일시스템과 동등한 staging 계층이라는 생각인데, 그렇지 않습니다. Snowmobile도 자주 과도하게 선택되지만, 이는 500 TB 워크로드가 아니라 수 페타바이트에서 엑사바이트 규모의 마이그레이션을 위한 서비스입니다. 시험 팁: 문제가 POSIX permissions와 symlinks를 강조하면, S3로의 rsync 같은 일반적인 object-copy 도구보다 DataSync와 파일 인지 마이그레이션 경로를 우선 고려하세요. 매우 큰 데이터셋의 경우 규모가 수백 테라바이트이면 Snowball Edge를, 수 페타바이트 이상일 때만 Snowmobile을 찾으세요. 또한 선택지에 언급된 마이그레이션 도구가 대상 서비스에 실제로 직접 지원되는지도 확인하세요.

문제 15

금융 서비스 회사가 AWS에서 다중 계층 온라인 뱅킹 애플리케이션을 운영하고 있습니다. 웹 계층은 VPC 내의 퍼블릭 서브넷에서 실행되는 반면, 애플리케이션 로직 및 데이터베이스 계층은 동일한 VPC의 프라이빗 서브넷에서 호스팅됩니다. 규정 준수를 위해 이 회사는 전용 보안 VPC에 AWS Marketplace의 특수 DLP(데이터 손실 방지) 보안 어플라이언스를 배포했습니다. 이 어플라이언스는 민감한 데이터 탐지를 위해 네트워크 패킷을 처리할 수 있는 IP 인터페이스를 갖추고 있습니다. 솔루션 아키텍트는 뱅킹 애플리케이션을 DLP 어플라이언스와 통합하여 모든 고객 트래픽이 웹 서버에 도달하기 전에 민감한 데이터에 대해 검사되도록 해야 합니다. 이 솔루션은 운영 복잡성과 관리 오버헤드를 최소화해야 합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 최소한의 운영 오버헤드로 타사 인라인 네트워크 보안 어플라이언스(DLP)를 트래픽 경로에 삽입하는 방법을 테스트합니다. 가상 어플라이언스로의 투명한 패킷 스티어링을 위해 특별히 설계된 AWS 네이티브 서비스는 GENEVE 프로토콜을 사용하는 Gateway Load Balancer(GWLB) 및 Gateway Load Balancer endpoint(GWLBe)입니다. 정답인 이유: 전용 보안 VPC에 GWLB를 배포하고 그 뒤에 DLP 어플라이언스를 배치하면 뱅킹 애플리케이션 VPC가 GWLB 엔드포인트를 통해 투명하게 어플라이언스로 트래픽을 보낼 수 있습니다. 그런 다음 라우팅 테이블을 업데이트하여(또는 중앙 집중식 수신/송신 패턴을 사용하여) 고객 트래픽이 웹 계층에 도달하기 전에 검사를 위해 GWLBe로 조향되도록 할 수 있습니다. 이는 복잡한 프록시 구성, 애플리케이션 변경 또는 인스턴스별 어플라이언스 라우팅 없이 관리되고 확장 가능한 삽입 지점을 제공합니다. 또한 GWLB 대상 그룹을 통해 어플라이언스 플릿의 확장 및 상태 확인을 지원합니다. 주요 AWS 기능: - GWLB는 보안 어플라이언스에 대해 투명한 L3/L4 로드 밸런싱을 제공하고 원래의 소스/대상 IP를 보존합니다. - GWLBe는 애플리케이션 VPC의 탄력적 네트워크 인터페이스(ENI)로, VPC 라우팅 테이블의 다음 홉(next hop)이 됩니다. - 다중 VPC 아키텍처(보안 VPC + 애플리케이션 VPC)와 잘 작동하며 중앙 집중식 검사 패턴을 지원합니다. - 사용자 지정 NAT/프록시 체인을 피하고 단일 서비스 엔드포인트 뒤에서 어플라이언스 Auto Scaling을 활성화하여 운영 오버헤드를 줄입니다. 일반적인 오해: NLB/ALB는 종종 "어플라이언스로 트래픽 전송"을 위해 선택되지만 투명한 인라인 패킷 검사를 위해 설계되지 않았습니다. ALB는 HTTP/HTTPS(Layer 7)이며 연결을 종료합니다. NLB는 L4이지만 GWLB가 제공하는 라우팅 테이블 스티어링 및 어플라이언스 체이닝과 동일한 투명한 서비스 삽입 모델을 제공하지 않습니다. 시험 팁: "AWS Marketplace 보안 어플라이언스", "인라인 검사(inline inspection)", "투명한(transparent)", "전용 보안 VPC", "최소한의 운영 오버헤드"를 보면 GWLB + GWLBe를 생각하십시오. Transit Gateway는 VPC 간의 라우팅 연결을 위한 것이지 어플라이언스에 대한 관리되고 확장 가능한 서비스 삽입을 위한 것이 아닙니다. 참조: AWS Gateway Load Balancer 설명서 및 관리형 서비스를 통해 중앙 집중식 검사 및 운영 부담 최소화에 대한 AWS Well-Architected Framework(보안 원칙) 지침.

문제 16

금융 서비스 회사가 디지털 뱅킹 플랫폼을 AWS 클라우드 인프라로 확장하고 있습니다. 이 회사는 피크 시간에 시간당 50,000건 이상의 트랜잭션을 처리하는 중요한 결제 처리 시스템을 운영합니다. 레거시 데이터 센터에서는 전용 네트워크 어플라이언스를 사용하여 보안 결제 네트워크를 드나드는 모든 트래픽에 대해 심층 패킷 검사(deep packet inspection), 맬웨어 탐지 및 프로토콜 검증을 수행했습니다. 이 회사는 모든 남북(north-south) 및 동서(east-west) 트래픽 흐름에 대해 상태 저장 검사(stateful inspection), 사용자 지정 규칙 기반 필터링 및 침입 방지를 수행할 수 있는 동등한 네트워크 보안 제어를 AWS 프로덕션 VPC에 구현해야 합니다. 이 솔루션은 높은 처리량 요구 사항을 지원하고 여러 가용 영역(AZ)에 걸쳐 중앙 집중식 정책 관리를 제공해야 합니다. 이러한 네트워크 보안 요구 사항을 가장 잘 충족하는 AWS 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 남북(수신/송신) 및 동서(수평) VPC 트래픽을 모두 포괄하여 대규모로 기존의 심층 패킷 검사(DPI), 침입 방지 및 프로토콜 검증과 유사한 네트워크 계층 보안 제어를 AWS에 구현하는 방법을 테스트합니다. 이를 위해 설계된 AWS 네이티브 서비스는 AWS Network Firewall입니다. 정답인 이유: AWS Network Firewall은 Suricata 호환 규칙을 사용하여 상태 저장 검사, 상태 비저장 필터링 및 침입 방지 기능을 제공합니다. 각 가용 영역의 전용 방화벽 서브넷에 배포되며 VPC 라우팅을 사용하여 트래픽 경로에 삽입할 수 있습니다(예: 트래픽을 Network Firewall 엔드포인트로 전달). 이를 통해 결제 시스템의 전형적인 높은 처리량 요구 사항을 충족하면서 AZ 전반에 걸쳐 중앙 집중식의 일관된 정책 적용이 가능합니다. 프로토콜 검증 및 서명 기반 탐지를 위한 사용자 지정 규칙 그룹을 지원하여 설명된 레거시 어플라이언스 기능과 밀접하게 일치합니다. 주요 AWS 기능: 1) 상태 저장 및 상태 비저장 규칙 엔진: 연결 추적 및 애플리케이션/프로토콜 인식 검사를 위한 상태 저장 규칙; 고속 L3/L4 필터링을 위한 상태 비저장 규칙. 2) 관리형 규칙 그룹 및 사용자 지정 규칙 그룹: AWS 관리형 위협 서명을 사용하고 사용자 지정 허용/거부 규칙을 추가합니다. 3) 다중 AZ 아키텍처: 복원력을 위해 AZ당 엔드포인트를 배포하고 교차 AZ 병목 현상을 방지합니다. 남북 및 동서 검사를 위해 라우팅 테이블과 통합합니다. 4) 중앙 집중식 가시성: 금융 서비스에서 일반적인 SIEM 통합 및 감사 요구 사항을 위해 Amazon CloudWatch Logs, S3 또는 Kinesis Data Firehose에 로그를 기록합니다. 일반적인 오해: GuardDuty는 인라인 적용 방화벽이 아니라 탐지(경고) 기능입니다. Traffic Mirroring은 대역 외(out-of-band) 검사용이며 인라인으로 차단하지 않습니다. Firewall Manager는 정책 배포를 중앙 집중화하지만 기본 서비스(WAF, Shield, 보안 그룹, Network Firewall)에 의존합니다. 그 자체가 DPI/IPS 엔진은 아닙니다. 시험 팁: VPC 트래픽에 대한 "상태 저장 검사(stateful inspection)", "침입 방지(intrusion prevention)", "사용자 지정 규칙 기반 필터링(custom rule-based filtering)" 및 "인라인 적용(inline enforcement)"을 보면 AWS Network Firewall을 생각하십시오. 가시성/포렌식을 위해 Traffic Mirroring을, 위협 탐지를 위해 GuardDuty를, 다중 계정 거버넌스를 위해 Firewall Manager를 사용하십시오. 기본 인라인 IPS/방화벽 데이터 플레인으로는 사용하지 마십시오.

문제 17

한 미디어 회사가 영화(1–10GB 파일)를 S3에 저장합니다. 스트리밍은 구매 후 5분 이내에 시작되어야 합니다. 최신 영화(20년 미만)는 오래된 영화보다 수요가 더 많습니다. 이 회사는 수요에 따라 호스팅 비용을 최소화하려고 합니다. 5분 가용성 목표를 충족하면서 비용을 최소화하는 스토리지 클래스 및 검색을 선택하십시오. 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 access frequency와 필요한 retrieval time을 기준으로 Amazon S3 storage classes를 선택하는지를 평가합니다. 핵심 요구 사항은 구매 후 5분 이내에 streaming이 시작되어야 한다는 점이며, 오래된 영화는 수요가 더 낮으므로 더 저렴하게 저장되어야 합니다. 가장 적절한 설계는 최신 콘텐츠에는 frequent-access class를 사용하고, 오래된 콘텐츠에는 retrieval option이 5분 목표를 여전히 충족할 수 있는 경우에만 더 저렴한 archival class를 사용하는 것입니다. 정답인 이유: S3 Intelligent-Tiering은 access patterns가 변하더라도 storage cost를 자동으로 최적화하면서 immediate access를 계속 제공하므로 최신 영화에 적합합니다. 오래되어 수요가 낮은 영화의 경우, S3 Glacier Flexible Retrieval은 훨씬 낮은 storage cost를 제공하며, expedited retrieval은 1–5분 내 access를 위해 설계되어 명시된 availability target과 일치합니다. 제공된 보기 중에서, 이것은 5분 요구 사항을 충족하도록 의도된 retrieval mode와 더 저렴한 archival storage를 명시적으로 결합한 유일한 선택지입니다. 주요 기능: S3 Intelligent-Tiering은 millisecond access와 함께 automatic tiering을 제공하며, access patterns가 불확실하거나 가변적일 때 유용합니다. S3 Glacier Flexible Retrieval은 expedited, standard, bulk의 세 가지 restore tiers를 지원하며, expedited가 가장 빠르고 몇 분 내 긴급 retrieval을 위해 설계되었습니다. S3 Standard와 Standard-IA는 모두 immediate access를 제공하지만, Glacier classes는 restore latency를 허용할 수 있을 때 infrequently accessed objects의 storage cost를 크게 줄일 수 있습니다. 흔한 오해: 흔한 함정은 Glacier retrieval은 모두 너무 느리다고 가정하는 것이지만, expedited retrieval은 분 단위 access를 위해 특별히 존재합니다. 또 다른 오해는 Standard-IA에 'standard retrieval'과 같은 Glacier 스타일 retrieval modes가 있다고 보는 것인데, 그렇지 않습니다. Standard-IA는 restore operations가 필요 없으며 즉시 access됩니다. 또한 Glacier의 bulk retrieval은 거의 즉시 streaming해야 하는 요구 사항에는 너무 느립니다. 시험 팁: 문제가 짧은 retrieval SLA를 충족하면서 가장 낮은 비용을 요구할 때는, 가장 빠른 restore tier를 가진 archival class가 timing requirement를 충족할 수 있는지 비교하세요. 요구 사항이 분 단위일 때는 bulk retrieval이 포함된 선택지를 제거하세요. 또한 Glacier retrieval terms를 non-Glacier storage classes에 적용하는 것처럼 AWS terminology를 잘못 사용하는 distractors도 주의하세요.

문제 18

금융 서비스 회사가 규정 준수 테스트 및 위험 분석을 위해 프로덕션 환경에서 스테이징 환경으로 50TB의 고객 트랜잭션 데이터를 정기적으로 복제해야 합니다. 프로덕션 데이터는 us-east-1 리전의 Amazon EBS 볼륨을 사용하는 Amazon EC2 인스턴스에 상주합니다. 복제된 데이터는 테스트 중 영향을 방지하기 위해 프로덕션 데이터와 완전히 격리되어야 합니다. 위험 분석 소프트웨어는 10,000+ IOPS의 지속적으로 높은 IOPS 성능을 요구합니다. 복제 프로세스는 규제 기한을 맞추기 위해 4시간의 유지 관리 기간 내에 완료되어야 합니다. 모든 성능 및 격리 요구 사항을 충족하면서 프로덕션 데이터를 복제하는 데 필요한 시간을 최소화하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 엄격한 시간 창 내에서 높은 지속적 IOPS 요구 사항을 충족하고 복원 성능에 중점을 둔 대규모 Amazon EBS snapshot 기반 복제를 테스트합니다. 핵심 개념은 snapshot에서 표준 EBS 볼륨을 복원할 때 lazy-loading이 발생하여 복원 시간과 초기 I/O 성능 모두에 심각한 영향을 미칠 수 있다는 것입니다. 정답인 이유: 옵션 D는 특정 시점 복제를 위해 EBS snapshot을 사용하고 해당 snapshot에서 EBS Fast Snapshot Restore(FSR)를 활성화합니다. FSR은 대상 Availability Zone에서 snapshot의 데이터를 완전히 사용할 수 있도록 보장하여 일반적인 "first-read penalty"를 제거함으로써, 새로 생성된 볼륨이 프로비저닝된 성능을 즉시 제공할 수 있게 합니다. 4시간의 유지 관리 기간과 10,000+ IOPS의 지속적인 요구 사항이 있는 50TB 데이터 세트의 경우, 초기화 시간을 최소화하고 초기 읽기 중 성능 저하를 방지하는 것이 중요합니다. FSR이 활성화된 snapshot에서 새로운 EBS 볼륨을 생성하면 강력한 격리(프로덕션과 분리된 볼륨)와 고성능 테스트를 위한 신속한 준비 상태를 제공합니다. 주요 AWS 기능: - EBS Snapshots: 증분식이며 Amazon S3에 저장되고, 파일 수준에서 데이터를 복사하지 않고 볼륨을 복제하는 데 사용됩니다. - Fast Snapshot Restore: 특정 AZ에서 snapshot 데이터를 미리 웜업(pre-warm)하여 snapshot에서 생성된 볼륨이 즉시 전체 성능을 제공하도록 합니다. - High IOPS volumes: 10,000+ 지속적 IOPS 요구 사항을 충족하기 위해 일반적으로 io1/io2(또는 충분히 프로비저닝된 IOPS를 가진 gp3)를 사용합니다. 일반적인 오해: 많은 사람들이 "snapshot에서 복원"이 즉시 빠르다고 가정합니다. 실제로는 lazy loading으로 인해 표준 복원이 초기에는 느릴 수 있으며, 일관된 성능을 달성하기 위해 볼륨 초기화(모든 블록 읽기)를 실행해야 할 수 있습니다. 이는 50TB의 경우 4시간의 창을 초과하는 경우가 많습니다. 또 다른 오해는 프로덕션 스토리지 연결(예: Multi-Attach)이 빠른 복제를 제공한다는 것입니다. 이는 격리 요구 사항을 위반하고 위험을 초래할 수 있습니다. 시험 팁: 대규모 데이터 세트 + 촉박한 RTO/유지 관리 기간 + 복원 직후 높은 IOPS가 보이면 EBS Fast Snapshot Restore를 찾으십시오. 또한 격리 요구 사항의 경우 프로덕션 볼륨을 공유/연결하는 것보다 snapshot에서 새로운 볼륨을 생성하는 것을 선호하십시오. 요구 사항을 병목 현상에 매핑하십시오. 여기서 병목 현상은 단순한 원시 IOPS 프로비저닝이 아니라 snapshot 복원/초기화 시간과 초기 읽기 성능입니다.

문제 19

한 의료 기술 스타트업이 6개월 동안 AWS에서 원격 의료 플랫폼을 운영해 왔습니다. 이 플랫폼은 3개의 지리적 리전에서 15,000명의 활성 사용자에게 서비스를 제공합니다. 최근 CFO는 월별 AWS 청구서, 특히 컴퓨팅 비용이 40% 급증한 것을 발견했습니다. 재무팀은 승인 없이 여러 Amazon EC2 인스턴스가 t3.medium에서 c5.2xlarge 인스턴스로 자동 업그레이드된 것을 발견했습니다. 이들은 지난 60일간의 컴퓨팅 지출 패턴을 분석하고 비용 증가를 주도하는 특정 인스턴스 패밀리를 식별해야 합니다. 최소한의 관리 노력으로 상세한 비용 분석 및 시각화를 제공하기 위해 솔루션 아키텍트는 무엇을 구현해야 합니까?

문제 분석

핵심 개념: 이 문제는 AWS 비용 분석 도구에 대한 지식과, 과거 EC2 비용 증가를 조사할 때 가장 관리 부담이 적은 옵션을 선택하는 능력을 평가합니다. 핵심 요구 사항은 지난 60일간의 compute 지출을 검토하고, 어떤 EC2 instance type 또는 관련 family가 비용 급증의 원인이 되었는지 식별하며, 이를 기본 제공 시각화와 최소한의 운영 노력으로 수행하는 것입니다. 정답인 이유: AWS Cost Explorer가 가장 적합한 이유는 사용자 지정 기간(지난 60일 포함)에 대한 과거 지출 추세를 보여줄 수 있는 관리형 billing 분석 도구이기 때문입니다. solutions architect는 Amazon EC2로 필터링하고 usage type 또는 instance type과 같은 차원으로 비용을 그룹화하여, 어떤 업그레이드된 instance가 비용 증가의 원인인지 확인할 수 있습니다. instance family가 항상 직접적인 그룹화 차원으로 노출되지는 않더라도, Cost Explorer는 사용자 지정 보고 파이프라인을 구축하지 않고도 비용을 유발한 EC2 type을 식별하는 가장 빠른 방법을 제공합니다. 주요 AWS 기능: Cost Explorer는 대화형 차트, 일별 또는 월별 세분성, service 수준 필터링, 지원되는 billing 차원별 그룹화를 제공합니다. 이는 AWS Billing console에서 직접 과거 비용 분석과 추세 시각화를 수행하도록 설계되었습니다. 상세 billing 데이터를 내보내고 사용자 지정 dashboard를 구축하는 방식과 비교하면 설정이 거의 필요 없거나 전혀 필요 없습니다. 흔한 오해: AWS Budgets는 주로 임계값 기반 모니터링과 알림을 위한 도구이며, 과거 데이터를 깊이 있게 탐색하는 용도는 아닙니다. Billing Dashboard는 어떤 EC2 instance type이 지출을 유발했는지 식별하기에는 너무 높은 수준의 정보만 제공합니다. Cost and Usage Reports와 QuickSight를 함께 사용하면 더 세밀하고 사용자 지정 가능한 분석이 가능하지만, 이 접근 방식은 문제에서 허용하는 것보다 훨씬 더 많은 설정과 유지 관리가 필요합니다. 시험 팁: 요구 사항이 과거 비용 분석, 시각화, 최소한의 관리 노력에 중점을 둘 때는 Cost Explorer가 일반적으로 가장 좋은 정답입니다. line-item billing 세부 정보, 사용자 지정 보고 로직, 또는 기본 billing 도구를 넘어서는 enterprise 규모의 보고가 명시적으로 요구될 때만 CUR 기반 분석을 선택하세요. Budgets와 같은 알림 도구를 Cost Explorer와 같은 조사 도구와 혼동하지 않도록 주의하세요.

문제 20

한 금융 기술 스타트업이 분당 수천 건의 트랜잭션을 처리하는 실시간 결제 처리 플랫폼을 개발하고 있습니다. 이 플랫폼은 하루 종일 크게 변동하는 트랜잭션 볼륨(피크 시간대에는 비피크 시간대보다 10배 더 많은 트래픽 발생)에 따라 자동으로 확장되어야 하는 여러 마이크로서비스로 구성됩니다. 개발 팀은 빠른 배포와 고가용성을 달성하기 위해 마이크로서비스를 컨테이너화하고자 합니다. 이들은 인프라 관리보다는 애플리케이션 개발 및 결제 로직 최적화에 전적으로 집중해야 합니다. 솔루션은 자동 확장을 제공하고 서버 프로비저닝 및 유지 관리의 필요성을 제거해야 합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하기 위해 솔루션 아키텍트는 무엇을 권장해야 합니까?

문제 분석

핵심 개념: 이 질문은 서버리스 컨테이너 오케스트레이션 및 운영 책임 경계를 테스트합니다. 핵심 서비스는 AWS Fargate를 사용하는 Amazon ECS로, EC2 인스턴스를 관리하지 않고 컨테이너를 실행하여 "애플리케이션 개발에 집중"하고 "서버 프로비저닝 및 유지 관리 제거"와 일치합니다. 정답인 이유: AWS Fargate의 ECS는 최소한의 운영 오버헤드를 위해 특별히 구축되었습니다. 작업 정의(CPU/메모리), 서비스 및 조정 정책을 정의하면 AWS가 기본 컴퓨팅을 프로비저닝하고 관리합니다. 트래픽 변동이 심한(10배 피크) 결제 플랫폼의 경우, ECS Service Auto Scaling은 지표(예: CPU, 메모리 또는 분당 트랜잭션과 같은 사용자 지정 CloudWatch 지표)를 기반으로 실행 중인 작업 수를 조정할 수 있습니다. 이는 클러스터 용량 계획 없이 빠른 배포, 여러 AZ에 걸친 고가용성 및 자동 확장을 제공합니다. 주요 AWS 기능: - AWS Fargate: EC2 인스턴스 관리, 패치 적용, AMI 또는 용량 프로비저닝이 없습니다. - ECS Service Auto Scaling: 원하는 작업 수를 조정하기 위한 대상 추적(Target tracking) 및 단계 조정(Step scaling). - Application Load Balancer 통합: 트래픽을 작업으로 분산합니다. 상태 확인 및 블루/그린 패턴(종종 CodeDeploy를 통해)을 지원합니다. - 고가용성: 여러 AZ의 서브넷에서 작업을 실행합니다. 복원력을 위해 원하는 수(desired count)와 배포 회로 차단기(deployment circuit breaker)를 사용합니다. - 보안 및 규정 준수 지원 요소: 작업을 위한 IAM 역할, 작업별 보안 그룹(awsvpc 네트워킹), Secrets Manager/Parameter Store와의 통합—핀테크 컨텍스트에서 중요합니다. 일반적인 오해: 팀은 종종 EC2 시작 유형의 ECS가 "충분히 관리된다"고 가정합니다. ECS가 예약을 관리하지만 여전히 EC2 플릿(패치 적용, 확장, 인스턴스 유형, 용량 버퍼)을 관리해야 합니다. 마찬가지로 Docker가 있는 EC2 Auto Scaling은 인스턴스를 확장할 수 있지만 오케스트레이션 및 배포 메커니즘을 구축하고 운영해야 합니다. 시험 팁: "최소한의 운영 오버헤드", "서버 프로비저닝/유지 관리 없음", "컨테이너"가 보이면 시험은 일반적으로 Fargate(또는 Fargate의 EKS)를 가리킵니다. 질문에 ECS가 명시적으로 지정되어 있고 인프라 관리 제거가 강조되어 있다면 Fargate가 있는 ECS가 정답입니다. 요구 사항을 공동 책임 모델에 매핑하십시오. Fargate는 컨테이너 이식성과 자동 확장을 유지하면서 더 많은 차별화되지 않은 과중한 작업을 AWS로 이전합니다.