Practice Test #7

인터넷을 통해 AWS CLI로 85TB를 업로드하면 상당한 WAN 대역폭을 소비하며 일반적으로 느리고 운영상 위험합니다(재시도, 긴 전송 시간). multipart upload가 대용량 객체에 도움이 되지만 네트워크 대역폭 사용을 최소화해야 하는 요구 사항을 충족하지는 않습니다. 이 옵션은 대역폭이 충분하고 시간 제약이 크지 않을 때만 가장 좋습니다.

S3 File Gateway는 S3를 백엔드로 사용하는 NFS 마운트를 제공하지만 여전히 네트워크를 통해 AWS로 데이터를 전송합니다. 게이트웨이를 통해 85TB를 복사하면 상당한 대역폭을 소비하며 인터넷 링크에 따라 오랜 시간이 걸릴 수 있습니다. File Gateway는 대량 마이그레이션 중 대역폭을 최소화하는 것이 아니라 지속적인 하이브리드 워크플로 및 캐싱에 더 적합합니다.

Direct Connect는 퍼블릭 인터넷보다 더 높고 일관된 처리량을 제공할 수 있지만 여전히 네트워크 대역폭을 사용하며 일반적으로 프로비저닝 리드 타임과 지속적인 비용이 발생합니다. 네트워크 사용을 최소화해야 하는 일회성 정적 85TB 마이그레이션의 경우 Snowball이 더 적합하며 일반적으로 Direct Connect를 설정하는 것보다 시작하는 것이 더 빠릅니다.

Instance store는 매우 높은 IOPS를 제공할 수 있지만 EBS snapshot을 instance store로 직접 복원하는 것은 기본 "복원" 작업이 아닙니다. snapshot에서 EBS 볼륨을 생성한 후 OS/파일 수준에서 데이터를 복사해야 하므로 50TB의 경우 시간이 많이 걸립니다. 또한 운영 복잡성이 추가되고 4시간의 창을 놓칠 위험이 있습니다. 게다가 instance store는 임시적이므로 반복 가능한 규정 준수 테스트 데이터 세트에는 일반적으로 바람직하지 않습니다.

EBS Multi-Attach는 io1/io2에서만 지원되며 격리된 복제본을 생성하기 위한 것이 아니라 조정된 쓰기가 있는 클러스터링된 애플리케이션을 위한 것입니다. 동일한 프로덕션 볼륨을 스테이징에 연결하면 완전한 격리 요구 사항을 위반하고 스테이징 환경에서 쓰기를 수행할 경우 데이터 손상이나 성능 저하의 위험이 있습니다. Snapshot은 이 옵션이 프로덕션 볼륨 연결을 제안한다는 사실을 바꾸지 않으며, 이것이 핵심 문제입니다.

새로운 EBS 볼륨을 생성하고 snapshot에서 복원하면 격리가 제공되지만 Fast Snapshot Restore가 없으면 볼륨이 lazy-loading됩니다. 일관된 고성능을 달성하려면 모든 블록을 읽어 볼륨을 초기화해야 하는 경우가 많으며, 50TB의 경우 시간이 오래 걸리고 4시간의 창을 초과할 수 있습니다. 이 옵션은 그럴듯하지만 복제 시간을 최소화하지 않으며 복원 후 즉각적이고 지속적인 10,000+ IOPS 성능을 보장하지 않습니다.

AWS Budgets는 주로 비용 또는 사용량 임계값을 설정하고 지출이 정의된 한도를 초과할 때 알림을 보내도록 설계되었습니다. budgets는 필터와 cost category로 범위를 지정할 수 있지만, 60일 기간 동안의 과거 EC2 지출 패턴을 상세하게 탐색 분석하는 용도로는 설계되지 않았습니다. 문제는 무엇이 증가를 유발했는지에 대한 조사와 시각화를 요구하며, 이는 Cost Explorer가 더 적합하게 처리합니다. Budgets는 보완적인 governance 도구로는 유용하지만, 여기서의 기본 분석 솔루션은 아닙니다.

AWS Billing Dashboard는 요약 수준의 billing 보기와 기본 차트를 제공하지만, 어떤 EC2 instance type 또는 관련 family가 compute 비용 증가를 유발했는지 분리해낼 수 있을 정도의 drill-down 기능은 제공하지 않습니다. 비용이 변했다는 사실을 확인하는 데는 유용하지만, 유연한 그룹화와 함께 사용자 지정 기간 전반에 걸친 상세 분석을 수행하기에는 적합하지 않습니다. 요구 사항은 비용 급증의 구체적인 원인을 식별하는 것이므로, Billing Dashboard는 너무 제한적입니다. Cost Explorer에서 제공되는 더 풍부한 조사 기능이 부족합니다.

AWS Cost and Usage Reports를 Amazon S3 및 Amazon QuickSight와 결합하면 line-item billing 분석을 포함한 매우 상세하고 사용자 지정 가능한 비용 분석을 확실히 제공할 수 있습니다. 그러나 이 접근 방식은 CUR 활성화, report 데이터 저장 및 관리, dataset 준비, dashboard 구축이 필요하므로 구현 및 유지 관리 노력이 더 많이 듭니다. 문제는 명시적으로 최소한의 관리 노력을 요구하므로, 이 솔루션은 60일간의 EC2 비용 조사에는 불필요하게 복잡합니다. 기본 billing 도구를 넘어서는 고급 사용자 지정 보고가 필요한 조직에 더 적합합니다.

틀렸습니다. Route 53 장애 조치는 DNS 기반이며 클라이언트와 리졸버가 의도한 TTL 이상으로 레코드를 캐시할 수 있기 때문에 즉각적인 장애 조치를 보장할 수 없습니다. 또한 NLB는 "Lambda를 호출"할 수 없습니다. Lambda 통합은 NLB UDP 리스너가 아니라 ALB(HTTP/HTTPS) 또는 기타 이벤트 소스와 연결됩니다. NLB가 UDP를 지원하지만 설명된 처리 아키텍처는 유효하지 않으며 마이크로초/즉각적인 장애 조치 요구 사항을 충족하지 않습니다.

틀렸습니다. Application Load Balancer는 Layer 7 로드 밸런서이며 UDP를 지원하지 않습니다. Global Accelerator가 지연 시간 및 장애 조치에 도움이 되더라도 ALB endpoint는 트레이딩 터미널에서 UDP 트래픽을 수락할 수 없습니다. 이 옵션은 근본적인 프로토콜 요구 사항을 충족하지 못하므로 설명된 시스템에 대한 올바른 설계가 될 수 없습니다.

틀렸습니다. 이는 Route 53 DNS 장애 조치와 ALB를 결합합니다. 두 가지 요구 사항을 충족하지 못합니다. ALB는 UDP를 지원하지 않으며 Route 53 장애 조치는 DNS 캐싱/TTL 동작으로 인해 즉각적이지 않습니다. 적극적인 상태 검사를 수행하더라도 DNS 기반 접근 방식은 일반적으로 Global Accelerator에 비해 마이크로초에 민감하고 지속적인 트레이딩 장애 조치 기대치를 충족할 수 없습니다.

EventBridge와 SNS는 이벤트 감지 및 알림에 적합하지만, AWS Config는 이 사용 사례에 가장 적합한 선택은 아닙니다. AWS Config는 주로 구성 규정 준수 평가와 선택적 복구를 위해 설계되었으며, KMS key deletion scheduling 이벤트를 가장 간결한 대응 경로로 직접 처리하기 위한 서비스는 아닙니다. 직접적인 EventBridge-to-Systems Manager Automation 통합과 비교하면 불필요한 복잡성이 추가됩니다. 따라서 예약된 key deletion을 자동으로 취소하는 데 있어 운영 오버헤드가 가장 적은 솔루션이라고 볼 수 없습니다.

이 옵션은 EventBridge가 KMS ScheduleKeyDeletion 이벤트를 감지하고 Lambda function을 호출하여 CancelKeyDeletion을 실행하도록 구성하면 동작할 수 있습니다. 그러나 Lambda는 작성, 테스트, 보안 설정, 모니터링, 유지 관리가 필요한 custom code를 도입합니다. 문제에서 운영 오버헤드가 가장 적은 방법을 요구하므로, 맞춤형 Lambda 기반 복구 경로보다 관리형 Systems Manager Automation workflow가 더 바람직합니다. 또한 실제 KMS deletion scheduling 작업이 아니라 DeleteKey라고 표현한 점도 부정확합니다.

이 옵션은 CloudTrail, CloudWatch Logs, metric filter, alarm, SNS 알림을 사용하여 알림 메커니즘을 제공합니다. 그러나 KMS key의 예약된 삭제를 취소하기 위한 자동 복구는 포함하지 않습니다. 요구 사항에서 삭제 시도를 자동으로 차단해야 한다고 명시했으므로, 알림만으로는 충분하지 않습니다. 또한 이 이벤트 기반 사용 사례에서는 EventBridge보다 운영 부담이 더 큰 로그 처리 경로를 사용합니다.