연습 문제

문제 1

미디어 제작 회사가 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는 일회성 마이그레이션을 시작하는 가장 빠른 방법이 아니라 안정적이고 예측 가능한 네트워크 연결 요구 사항을 위한 것입니다.

문제 2

금융 서비스 회사가 규정 준수 테스트 및 위험 분석을 위해 프로덕션 환경에서 스테이징 환경으로 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 복원/초기화 시간과 초기 읽기 성능입니다.

문제 3

한 의료 기술 스타트업이 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와 같은 조사 도구와 혼동하지 않도록 주의하세요.

문제 4

한 금융 트레이딩 회사가 UDP 프로토콜을 사용하여 글로벌 금융 센터 전역의 5,000개 이상의 트레이딩 터미널에서 시장 데이터를 수신하는 고빈도 트레이딩 시스템을 운영하고 있습니다. 이 시스템은 실시간으로 트레이드 신호를 처리하고 마이크로초 내에 터미널로 실행 확인을 다시 보냅니다. 회사는 초저지연 트레이딩 작업을 위해 네트워크 지연 시간을 최소화하는 솔루션이 필요합니다. 또한 시스템은 시장 시간 동안 지속적인 트레이딩 작업을 보장하기 위해 보조 AWS Region으로의 즉각적인 장애 조치 기능을 제공해야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 UDP 기반 워크로드를 위한 초저지연 글로벌 인그레스 및 빠른 리전 장애 조치를 테스트합니다. 핵심 서비스는 애니캐스트 정적 IP 및 상태 기반 트래픽 전환을 위한 AWS Global Accelerator(GA)와 오버헤드가 매우 적은 Layer 4(TCP/UDP) 로드 밸런싱을 위한 Network Load Balancer(NLB)입니다. 정답인 이유: 옵션 B는 각 Region에 NLB endpoint가 있는 AWS Global Accelerator를 사용합니다. GA는 AWS 엣지 로케이션에서 애니캐스트 IP를 알리므로 트레이딩 터미널은 퍼블릭 인터넷을 통해 가장 가까운 엣지에 연결한 다음 트래픽이 AWS 글로벌 백본을 통과하여 최적의 정상 리전 endpoint로 이동합니다. 이는 일반적으로 DNS 기반 라우팅에 비해 지터와 지연 시간을 줄이고, GA가 지속적으로 endpoint의 상태를 검사하고 DNS TTL이 만료될 때까지 기다리지 않고 비정상 Region에서 트래픽을 전환하기 때문에 거의 즉각적인 장애 조치를 제공합니다. NLB는 트레이딩 터미널에서 요구하는 UDP를 지원하며 마이크로초에 민감한 Layer 4 트래픽에 적합한 로드 밸런서 유형입니다. 주요 AWS 기능 / 모범 사례: - AWS Global Accelerator: 정적 애니캐스트 IP, 엣지 진입, AWS 백본 라우팅, endpoint 가중치 및 Region 전반의 빠른 상태 검사 기반 장애 조치. - NLB: UDP 지원, 높은 처리량, 짧은 지연 시간 및 소스 IP 보존(트레이딩 환경의 감사/제어에 유용). - 지속적인 트레이딩 요구 사항을 충족하기 위한 GA endpoint 그룹이 있는 다중 리전 액티브/스탠바이(또는 액티브/액티브). - 컴퓨팅 선택: Fargate의 ECS는 제공된 옵션 내에서 허용됩니다. 실제 HFT에서는 향상된 네트워킹(ENA), 배치 그룹 및 조정된 커널/네트워크 설정이 있는 EC2를 선호할 수 있지만 여기서는 제공되지 않습니다. 일반적인 오해: Route 53 장애 조치(옵션 A 및 D)는 올바른 다중 리전 접근 방식처럼 보일 수 있지만 DNS 장애 조치는 캐싱/TTL 및 리졸버 동작으로 인해 "즉각적"이지 않으며 GA가 수행하는 방식으로 네트워크 경로 지연 시간을 최적화하지 않습니다. ALB(옵션 C 및 D)는 Layer 7이며 UDP를 지원하지 않으므로 근본적으로 호환되지 않습니다. 시험 팁: - 프로토콜이 UDP인 경우 ALB를 즉시 제거하십시오. - 초저지연 + 글로벌 사용자 + 빠른 장애 조치의 경우 Route 53 장애 조치보다 Global Accelerator를 선호하십시오. - 지연 시간에 민감한 Layer 4 워크로드 및 교차 리전 복원력을 위해 GA를 NLB와 페어링하십시오.

문제 5

한 의료 기관이 환자 의료 기록 및 상담 데이터를 처리하는 원격 진료 플랫폼을 개발했습니다. HIPAA 규정을 준수하기 위해 모든 환자 데이터는 저장 시 암호화되어야 합니다. 이 기관은 암호화 키를 관리하기 위해 AWS Key Management Service(AWS KMS)를 사용합니다. 이 기관은 환자 데이터 암호화에 사용되는 KMS 키의 우발적인 삭제를 방지하는 솔루션이 필요합니다. 이 솔루션은 누군가 KMS 키를 삭제하려고 시도할 때마다 Amazon Simple Notification Service(Amazon SNS)를 통해 IT 보안 팀에 실시간 이메일 알림을 보내야 하며, 삭제를 자동으로 차단해야 합니다. 운영 오버헤드가 가장 적게 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 KMS key deletion scheduling 이벤트를 감지하고 이를 자동으로 복구하면서 실시간 알림도 전송하여, 실수로 AWS KMS key가 삭제되는 것을 어떻게 방지할지 테스트합니다. AWS KMS에서 customer managed key는 즉시 삭제되지 않습니다. 사용자가 반드시 ScheduleKeyDeletion을 호출해야 하며, 그러면 대기 기간이 시작되고, CancelKeyDeletion으로 삭제를 되돌릴 수 있습니다. 정답인 이유: 가장 적절한 솔루션은 Amazon EventBridge를 사용하여 CloudTrail management event에서 KMS ScheduleKeyDeletion API 호출을 감지한 다음, AWS Systems Manager Automation runbook을 트리거하여 CancelKeyDeletion을 자동으로 호출하는 것입니다. 동일한 EventBridge rule은 Amazon SNS로도 게시할 수 있으므로 IT security team이 실시간 email 알림을 받을 수 있습니다. 이 접근 방식은 관리형 AWS 서비스를 사용하고, custom code를 피하며, 알림과 자동 차단 요구 사항을 모두 충족하면서 운영 오버헤드를 최소화합니다. 주요 AWS 기능: - AWS CloudTrail은 ScheduleKeyDeletion과 같은 KMS management API 호출을 기록하며, EventBridge는 이러한 이벤트를 거의 실시간으로 매칭할 수 있습니다. - AWS Systems Manager Automation은 영향을 받은 KMS key에 대해 CancelKeyDeletion을 호출하는 관리형 복구 workflow를 실행할 수 있습니다. - Amazon SNS는 security team에 대한 email 알림을 포함해 즉각적인 fan-out 알림을 제공합니다. - KMS key deletion에는 항상 대기 기간이 있으므로, scheduling 시도가 발생한 후 실수로 인한 삭제를 방지하는 올바른 방법은 자동 취소입니다. 흔한 오해: - customer managed key에 대한 KMS DeleteKey API는 없습니다. 관련 작업은 ScheduleKeyDeletion입니다. “DeleteKey”라고 설명하는 것은 부정확하며 시험에서 오해를 유발할 수 있습니다. - AWS Config는 규정 준수 평가와 일부 복구 시나리오에 유용하지만, 예약된 KMS key deletion 이벤트를 취소하는 데 가장 직접적이거나 운영 오버헤드가 가장 낮은 서비스는 아닙니다. - CloudWatch alarm과 metric filter는 이벤트에 대해 알림을 보낼 수 있지만, 그것만으로는 복구를 수행하지 않습니다. 시험 팁: 문제에서 운영 오버헤드가 가장 적은 방법을 묻는다면, custom Lambda code보다 EventBridge와 Systems Manager Automation 같은 기본 서비스 통합을 우선적으로 고려하세요. KMS deletion protection에서는 lifecycle을 기억하세요. ScheduleKeyDeletion이 프로세스를 시작하고, CancelKeyDeletion이 이를 되돌립니다. 또한 KMS key가 즉시 삭제된다고 잘못 표현하는 문구도 주의하세요. AWS KMS는 customer managed key에 대해 항상 대기 기간을 적용합니다.

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

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

문제 6

한 게임 회사가 여러 모바일 및 웹 게임 클라이언트로부터 플레이어 액션, 게임 이벤트 및 텔레메트리 데이터를 수집해야 하는 실시간 멀티플레이어 게임 플랫폼을 개발하고 있습니다. 이 게임 플랫폼은 특별 이벤트, 토너먼트 및 신규 게임 출시 중에 갑작스러운 스파이크가 발생하는 등 변동성이 매우 큰 트래픽 패턴을 겪습니다. 플랫폼은 수 분 내에 1,000명에서 50,000명의 동시 플레이어로 증가하는 트래픽 스파이크를 처리하고, 서드파티 게임 분석 서비스와 통합해야 하며, 안전한 데이터 수집을 위한 플레이어 인증을 포함해야 합니다. 이 솔루션은 실시간 리더보드 및 행동 분석을 위해 게임 데이터를 처리해야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 7

의료 연구 기관이 임상 시험 데이터와 환자 기록을 Amazon S3에 저장해야 합니다. 규정 준수 요구 사항으로 인해, 기관은 업로드된 의료 데이터가 변경되거나 변조될 수 없도록 보장해야 합니다. 데이터는 규제 승인 프로세스가 완료된 후 연구 팀이 수정을 허용하기로 결정할 때까지 무기한으로 불변(immutable) 상태를 유지해야 합니다. 지정된 규정 준수 책임자와 선임 연구원(AWS 계정의 특정 사용자)만이 법적으로 요구될 때 불변성 보호를 제거하고 의료 기록을 삭제할 수 있는 권한을 가져야 합니다. 솔루션 아키텍트는 이러한 의료 데이터 보호 요구 사항을 충족하기 위해 무엇을 권장해야 합니까?

문제 분석

핵심 개념: 이 질문은 규제 대상 데이터에 대한 Amazon S3 불변성 제어(S3 Object Lock (WORM), versioning, retention controls (retention periods 대 legal holds), 그리고 보호를 제거하고 객체를 삭제할 수 있는 사람을 제한하기 위한 최소 권한 IAM)를 테스트합니다. 정답인 이유: 요구 사항은 업로드된 데이터가 변경되거나 변조될 수 없어야 하며, 변경을 허용하기로 명시적인 결정이 내려질 때까지 무기한으로 불변 상태를 유지해야 한다는 것입니다. S3 Object Lock은 객체 버전 수준에서 WORM 보호를 제공합니다. Legal Hold는 무기한 보존 요구 사항을 위해 특별히 설계되었습니다. 만료일이 없으며 legal hold가 제거될 때까지 객체 버전을 덮어쓰거나 삭제할 수 없도록 방지합니다. 지정된 규정 준수 책임자/선임 연구원에게만 s3:PutObjectLegalHold 권한(및 s3:GetObjectLegalHold 및 삭제 권한과 같은 관련 권한)을 부여함으로써, 해당 특정 사용자만이 hold를 제거하고 법적으로 요구될 때 객체 버전을 삭제할 수 있습니다. 주요 AWS 기능: - S3 Object Lock은 S3 bucket versioning이 필요하며 bucket 생성 시 활성화되어야 합니다. - Legal Hold: 무기한 보호; retention date를 설정할 필요가 없습니다. - IAM 제어: s3:PutObjectLegalHold(및 삭제)를 소수의 보안 주체로 제한합니다. 선택적으로 MFA를 요구하고 더 강력한 가드레일을 위해 permission boundaries/SCP를 사용합니다. - (선택적 모범 사례) root/admin조차도 보존을 우회할 수 없도록 해야 하는 경우 Compliance mode에서 S3 Object Lock을 사용합니다. 그러나 "승인될 때까지 무기한"의 경우 legal hold가 가장 직접적으로 적합합니다. 일반적인 오해: - 매우 긴 retention period(예: 75년)를 설정하는 것은 "무기한"과 같지 않으며, 더 일찍 릴리스해야 하는 경우 운영/법적 문제를 일으킬 수 있습니다. - CloudTrail로 모니터링하고 백업에서 복원하는 것은 예방적 불변성이 아니라 탐지/수정입니다. - Glacier Vault Lock은 Glacier vault(레거시)용이며 S3 기반 기록 관리를 위한 표준 접근 방식이 아닙니다. 시험 팁: S3에서 "WORM/immutable"을 보면 "S3 Object Lock + versioning"을 생각하십시오. 요구 사항이 "알려진 날짜까지 보존"인 경우 retention period를 사용하십시오. "누군가 명시적으로 제거할 때까지 무기한 보존"인 경우 Legal Hold를 사용하십시오. 특정 역할만 hold를 제거하고 보호된 버전을 삭제할 수 있도록 항상 IAM 최소 권한과 짝을 지으십시오.

문제 8

미디어 스트리밍 회사가 여러 리전에 걸쳐 Amazon S3에 수천 개의 비디오 파일과 사용자 생성 콘텐츠를 저장하고 있습니다. 이 회사는 3년 동안 운영되어 왔으며 500TB 이상의 데이터를 축적했습니다. 사용자 선호도 및 콘텐츠 수명 주기의 변화로 인해 많은 오래된 비디오는 액세스가 거의 또는 전혀 발생하지 않습니다. 클라우드 아키텍트는 조직의 50개 이상의 S3 버킷 전반에서 스토리지 비용을 최적화하기 위해 액세스가 거의 없거나 전혀 사용되지 않는 비디오 콘텐츠가 포함된 S3 버킷을 식별하는 솔루션을 구현해야 합니다. 최소한의 운영 오버헤드로 이 목표를 달성할 수 있는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 대규모 Amazon S3의 비용 최적화, 특히 최소한의 운영 노력으로 많은 버킷에서 액세스가 적거나 없는 버킷(및 객체)을 식별하는 방법을 테스트합니다. 핵심 서비스는 스토리지 사용량 및 활동 추세에 대한 조직 전체의 가시성을 제공하는 S3 Storage Lens입니다. 정답인 이유: S3 Storage Lens는 AWS Organization(또는 선택한 계정/리전) 전반의 지표를 집계하고 비활성 또는 거의 액세스되지 않는 데이터 식별을 포함하여 스토리지 사용량 및 활동을 보고하도록 특별히 구축되었습니다. 여러 리전에 걸쳐 50개 이상의 버킷과 500TB가 있는 경우 중앙 집중식 관리형 분석 보기가 필요합니다. Storage Lens는 로그 파이프라인을 구축하거나 클러스터를 실행하거나 각 버킷을 수동으로 검사할 필요가 없으므로 운영 오버헤드를 최소화합니다. 비용 최적화 결정(예: S3 Intelligent-Tiering, S3 Glacier 티어로의 수명 주기 전환 또는 만료)을 직접 지원하는 대시보드 및 지표를 제공합니다. 주요 AWS 기능: S3 Storage Lens는 AWS Organizations를 사용하여 조직 수준에서 구성할 수 있으므로 계정 및 리전 전반에 걸쳐 단일 창(single pane of glass)을 제공합니다. 스토리지 바이트, 객체 수, 활동 지표(예: 요청 지표)와 같은 지표를 제공하며 추가 분석을 위해 지표를 Amazon S3로 내보낼 수 있습니다. 고급 지표(Storage Lens advanced)는 추가적인 인사이트와 더 긴 보존 기간을 제공하며, 이는 지속적인 거버넌스를 위한 "최소한의 운영 오버헤드" 요구 사항과 일치합니다. 일반적인 오해: CloudWatch S3 지표는 종종 "사용되지 않는 데이터"를 보여주는 것으로 간주되지만, S3의 기본 CloudWatch 지표는 제한적이며 추가 계측 없이는 객체 수준의 액세스 빈도 인사이트를 제공하지 않습니다. CloudTrail 데이터 이벤트는 객체 수준 API 활동을 캡처할 수 있지만, 모든 버킷에 대해 이를 활성화하고 500TB 규모에서 로그를 처리하는 것은 비용이 많이 들고 운영 부담이 큽니다. 수동 콘솔 검토는 확장되지 않으며 오류가 발생하기 쉽습니다. 시험 팁: 질문에서 조직 전체의 가시성, 비용 최적화 및 최소한의 운영 오버헤드를 요구하는 경우, 사용자 지정 분석 파이프라인을 구축하는 것보다 관리형 특수 목적 서비스(예: S3 Storage Lens, AWS Trusted Advisor, Cost Explorer)를 찾으십시오. 또한 "버킷 수준 지표"(상위 수준)와 "객체 액세스 패턴"(종종 특수 도구 또는 로그 필요)을 구별하십시오.

문제 9

한 금융 서비스 회사가 serverless 아키텍처를 사용하여 사기 탐지 시스템을 현대화하려고 합니다. 이 시스템은 SQL 쿼리를 사용하여 트랜잭션 데이터에 대한 실시간 분석을 수행해야 합니다. 이 회사는 현재 500TB의 트랜잭션 로그를 Amazon S3 버킷에 저장하고 있습니다. 데이터는 금융 규정 준수를 위해 암호화되어야 하며, 재해 복구(disaster recovery) 목적으로 보조 AWS Region으로 복제되어야 합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 최소한의 운영 오버헤드로 암호화 및 교차 Region 재해 복구 요구 사항을 충족하면서, SQL(Amazon Athena)을 사용하여 Amazon S3에서 serverless, low-ops 분석 패턴을 선택하는 능력을 테스트합니다. 정답인 이유: 옵션 A는 내구성 있는 데이터 레이크로 Amazon S3를, DR을 위해 S3 Cross-Region Replication (CRR)을, 규정 준수 수준의 암호화를 위해 SSE-KMS를, serverless SQL 분석을 위해 Amazon Athena를 결합합니다. Athena는 데이터베이스 서버를 프로비저닝하거나 관리할 필요 없이 S3의 데이터에 대해 직접 SQL을 실행하도록 특별히 구축되었으므로 500TB의 로그를 쿼리하는 데 운영 오버헤드가 가장 적은 선택입니다. AWS KMS multi-Region 키를 사용하면 여러 Region에 걸쳐 일관된 암호화 상태를 지원하고 복제된 데이터에 대한 키 관리를 단순화합니다. 주요 AWS 기능: - Amazon Athena: S3 기반의 serverless, 쿼리당 지불 방식의 SQL 분석; 성능 향상 및 비용 절감을 위한 스키마 검색 및 파티셔닝을 위해 AWS Glue Data Catalog와 통합됩니다. - S3 CRR: DR을 위해 객체를 보조 Region으로 자동 복제합니다; 올바르게 구성된 경우 KMS로 암호화된 객체를 복제할 수 있습니다. - multi-Region 키를 사용하는 SSE-KMS: 중앙 집중식 제어, 감사 가능성(CloudTrail), 암호화된 복제 및 규정 준수 요구 사항을 지원하기 위해 여러 Region에서 관련 키를 사용할 수 있는 기능. - 운영 모범 사례: 버킷 버전 관리(CRR에 필수), 복제 역할을 위한 최소 권한 IAM, S3 복제가 키를 사용할 수 있도록 허용하는 KMS 키 정책을 사용합니다. 일반적인 오해: - "SQL 쿼리"를 위해 Amazon RDS를 선택하는 것은 함정입니다: RDS는 기본적으로 serverless가 아니며, 인스턴스 크기 조정, 확장, 패치 적용 및 S3에서의 데이터 로딩/ETL이 필요하므로 운영 오버헤드가 높고 500TB 로그 분석에 이상적이지 않습니다. - SSE-S3를 사용하는 것이 더 간단해 보일 수 있지만, 규제가 심한 많은 금융 환경에서는 세분화된 액세스 제어, 교체 및 감사 요구 사항을 위해 고객 관리형 키(KMS)가 필요합니다. - 요구 사항이 새롭고 규정을 준수하는 설계(예: 첫날부터 암호화, 버전 관리, 복제 적용)를 암시하는 경우, 기존 버킷을 재사용한다고 해서 본질적으로 운영이 줄어드는 것은 아닙니다. 시험 팁: "serverless", "S3의 SQL", "최소한의 운영 오버헤드"가 보이면 일반적으로 Athena가 가장 적합합니다. S3 데이터의 교차 Region DR의 경우 CRR이 기본 답안이며, 규정 준수가 엄격한 암호화 요구 사항의 경우 SSE-KMS(multi-Region 워크플로가 관련된 경우 종종 multi-Region 키와 함께)를 선호합니다. CRR에는 암호화된 복제를 위한 버전 관리 및 적절한 KMS 권한이 필요하다는 점을 항상 기억하십시오.

문제 10

금융 서비스 회사가 Amazon EC2 인스턴스를 사용하여 AWS에 새로운 거래 플랫폼을 배포하고 있습니다. 이 플랫폼은 실시간 시장 데이터를 처리하고 알고리즘 전략을 기반으로 거래를 실행합니다. 플랫폼은 정상적인 시장 변동성 동안 불필요한 경보를 피하기 위해 정교한 모니터링이 필요합니다. 시장 개장 시간 동안 메모리 사용률이 75%를 초과하는 것만으로는 허용되지만, 메모리 사용률이 75%를 초과하고 동시에 네트워크 패킷 손실률이 2%를 초과하는 경우에는 즉각적인 개입이 필요합니다. 모니터링 솔루션은 오탐지(false positive) 경보를 최소화하면서 중요한 조건에 대한 신속한 대응을 보장해야 합니다. 솔루션 아키텍트는 이러한 모니터링 요구 사항을 충족하기 위해 무엇을 구현해야 합니까?

문제 분석

핵심 개념: 이 질문은 다중 신호 장애 조건을 감지하면서 노이즈를 줄이기 위한 Amazon CloudWatch 경보 패턴을 테스트합니다. 특히, 부울 논리(AND/OR/NOT)를 사용하여 여러 기본 경보의 상태를 결합하여 더 높은 충실도의 경보를 생성하는 CloudWatch composite alarms에 중점을 둡니다. 정답인 이유: 요구 사항은 정상적인 변동성 동안 오탐지를 방지하는 것입니다. 메모리 >75% 단독으로는 때때로 허용되지만, 메모리 >75% AND 패킷 손실 >2%가 동시에 발생하면 즉각적인 조치가 필요합니다. 이를 모델링하는 가장 깔끔한 방법은 두 개의 metric alarms(하나는 메모리 사용률, 하나는 패킷 손실용)를 생성한 다음, 두 기본 경보가 모두 ALARM 상태일 때만 ALARM 상태가 되는 composite alarm을 생성하는 것입니다(ALARM(memory) AND ALARM(packetloss)). 이는 비즈니스 로직과 직접적으로 일치하며, 단일 지표만으로는 중요한 경보를 트리거하지 않으므로 불필요한 페이징을 최소화합니다. 주요 AWS 기능: CloudWatch composite alarms는 다른 경보를 참조하는 규칙 표현식을 지원하며 경보 상관관계를 위해 설계되었습니다. 가시성과 문제 해결을 위해 기본 경보를 유지하면서 composite alarm에서만 Amazon SNS, OpsCenter 또는 인시던트 도구를 통해 알림을 보낼 수 있습니다. 메모리 사용률의 경우 EC2는 기본적으로 메모리를 게시하지 않으므로 일반적으로 CloudWatch Agent를 설치하여 mem_used_percent를 게시합니다. 패킷 손실의 경우 패킷 손실 측정 방법에 따라 CloudWatch Agent, VPC Flow Logs 파생 지표 또는 애플리케이션/네트워크 원격 측정(telemetry)을 사용할 수 있습니다. 또한 평가 기간(evaluation periods)과 경보를 위한 데이터 포인트(datapoints-to-alarm)를 조정하여 "동시"가 N 기간 동안 지속됨을 의미하도록 할 수 있습니다. 일반적인 오해: Dashboards는 사람이 관찰하는 데 도움이 되지만 경보 로직을 구현하지는 않습니다. Synthetics canaries는 호스트 수준의 상관 조건이 아니라 엔드포인트를 테스트합니다. 단일 metric alarm은 두 개의 다른 지표에 걸쳐 AND를 기본적으로 표현할 수 없습니다. metric math는 지표를 결합할 수 있지만 상태 저장 상관관계에 오류가 발생하기 쉽고 composite alarms와 동일한 경보 간(alarm-on-alarm) 의미 체계를 제공하지 않습니다. 시험 팁: "조건 A와 조건 B가 함께 발생할 때만 경보" 또는 "경보 노이즈 감소"와 같은 요구 사항이 표시되면 CloudWatch composite alarms를 생각하십시오. 각 신호에 대해 metric alarms를 사용한 다음 페이징을 위해 composite alarm을 사용합니다. CloudWatch Agent를 통해 사용자 지정 지표(예: 메모리)를 고려하고 운영 기대치에 맞게 평가 기간을 조정하는 것을 잊지 마십시오.

Practice Test #7

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(29)

다른 모의고사

Practice Test #1

Practice Test #2

Practice Test #3

Practice Test #4

Practice Test #5

Practice Test #6

Practice Test #8

Practice Test #9

Practice Test #10

지금 학습 시작하기