연습 문제

문제 1

금융 서비스 회사가 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(보안 원칙) 지침.

문제 2

개발자들은 private subnet에 있는 Amazon Linux EC2 instance에 대한 안전한 SSH 접근이 필요합니다. 이들은 원격 및 현장에서 근무합니다. Instance는 NAT gateway를 통해 인터넷에 연결됩니다. 회사는 AWS 서비스를 사용하고 비용을 낮게 유지하고자 합니다. Bastion 없이 가장 비용 효율적이고 안전한 접근 방법을 제공해야 합니다. 어떻게 해야 합니까?

문제 분석

핵심 개념: 이 질문은 SSH(포트 22)를 노출하지 않고 bastion host를 관리하지 않으면서, 비용 최적화된 방식으로 AWS 네이티브 서비스를 사용하여 private EC2 instance에 대한 안전한 관리자 접근을 테스트합니다. 핵심 서비스는 AWS Systems Manager(SSM) Session Manager입니다. 정답인 이유: AmazonSSMManagedInstanceCore 정책을 instance role에 연결하면(그리고 Amazon Linux 2/2023에서 기본적으로 설치/실행되는 SSM Agent가 작동 중인지 확인하면) 인바운드 security group 규칙, public IP 또는 bastion 없이도 private subnet의 instance에 대한 Session Manager 접근이 가능해집니다. Session Manager는 Systems Manager endpoint로의 아웃바운드 연결(NAT gateway를 통한 인터넷 또는 VPC endpoint 경유)을 사용하며, 감사 가능하고 IAM으로 제어되는 대화형 쉘 접근을 제공합니다. 이는 운영 오버헤드와 비용을 낮게 유지하면서 원격 및 현장 개발자 모두를 위한 안전한 SSH 유사 접근 요구 사항을 충족합니다. 주요 AWS 기능 / 모범 사례: - Session Manager는 포트 22를 열지 않고도 브라우저/CLI 기반 쉘 접근을 제공합니다. - IAM 정책은 세션을 시작할 수 있는 사람을 제어합니다. MFA 및 최소 권한을 강제할 수 있습니다. - CloudTrail을 통한 전체 감사 및 CloudWatch Logs/S3로의 선택적 세션 로깅. - Bastion 수명 주기 관리(패치, 강화, 키 교체)가 필요 없습니다. - 더 강력한 보안을 위해 SSM용 VPC interface endpoint(ssm, ssmmessages, ec2messages)를 추가하여 NAT 이그레스를 방지할 수 있지만, 문제에서 이미 NAT가 존재한다고 명시하고 있습니다. 일반적인 오해: 많은 사람들이 SSH에는 bastion이나 VPN이 필요하다고 가정합니다. 작동은 하지만 비용과 운영 부담(bastion) 또는 복잡성(모든 개발자를 위한 VPN)이 추가됩니다. EC2 Instance Connect는 여전히 SSH에 대한 네트워크 도달 가능성을 요구하며 일반적으로 bastion/퍼블릭 경로가 필요합니다. 인바운드 접근 경로의 필요성을 제거하지 않습니다. 시험 팁: "private subnets", "secure admin access", "no bastion", "use AWS services"를 보면 기본적으로 Systems Manager Session Manager를 떠올리십시오. 기존 SSH/VPN 접근 방식과 차별화되는 요소로 IAM role + AmazonSSMManagedInstanceCore, 인바운드 규칙 없음, 감사/로깅을 찾으십시오.

문제 3

의료 기관이 임상 시험 데이터 분석을 지원하기 위해 연구 개발 워크로드를 AWS Cloud로 마이그레이션하고 있습니다. 이 기관은 종양학, 심장학 및 신경학을 포함한 여러 연구 부서에 걸쳐 클라우드 인프라에 대한 특정 예산을 할당했습니다. 최고 재무 책임자(CFO)는 각 연구 부서별 클라우드 지출에 대한 명확한 가시성을 요구하며, 총 지출이 할당된 월 예산 $50,000의 75%에 도달하면 자동으로 알림을 받기를 원합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 비즈니스 단위(연구 부서)에 비용을 할당하고 사전 예산 알림을 적용하는 AWS 비용 거버넌스를 테스트합니다. 주요 서비스는 AWS Cost Allocation Tags(속성 부여용) 및 AWS Budgets(임계값 기반 경고용)입니다. 정답인 이유: CFO는 (1) 종양학/심장학/신경학별 지출에 대한 명확한 가시성과 (2) 총 월 지출이 $50,000 예산의 75%에 도달할 때 자동 알림이 필요합니다. 리소스에 적용되고 결제 콘솔에서 활성화된 비용 할당 태그를 사용하면 Cost Explorer 및 Cost & Usage Report와 같은 도구에서 부서별 비용 보고가 가능합니다. 그런 다음 AWS Budgets를 사용하면 75%($37,500)에서 경고가 발생하고 이메일 및/또는 Amazon SNS를 통해 알림이 전송되는 $50,000의 월간 비용 예산을 생성할 수 있습니다. 이는 속성 부여 및 경고 요구 사항을 모두 직접적으로 충족합니다. 주요 AWS 기능: - 비용 할당 태그: Department=Oncology와 같은 태그를 적용하고 비용 할당 태그로 활성화하여 결제 보고서에 표시되도록 합니다. - AWS Budgets(비용 예산): 총 지출에 대한 월간 예산을 생성합니다. 선택적으로 더 깊은 거버넌스를 위해 부서별로 태그 필터링된 예산을 생성할 수도 있습니다. - 경고: 예산 임계값(실제 지출 및/또는 예측 지출)을 구성하고 자동화를 위해 이메일/SNS로 알림을 보냅니다. - 모범 사례: 일관된 태그 정책(종종 AWS Organizations Tag Policies를 통해)을 사용하여 계정 전체에 태그 지정 표준을 적용합니다. 일반적인 오해: 자주 빠지는 함정은 Cost Explorer "예측 분석"이 소유권을 자동으로 식별할 수 있다고 가정하는 것입니다. Cost Explorer는 지출을 예측할 수 있지만 태그/계정 구조 없이는 부서 소유권을 유추할 수 없습니다. 또 다른 오해는 예산 임계값에 이상 탐지를 사용하는 것입니다. 이상 탐지는 "예산의 75%" 마일스톤이 아니라 비정상적인 지출 패턴을 감지합니다. 시험 팁: "부서/팀/프로젝트별 가시성"이 보이면 비용 할당 태그(또는 별도 계정)와 Cost Explorer/CUR을 생각하십시오. "예산의 X%에서 알림"이 보이면 경고(이메일/SNS)가 있는 AWS Budgets를 생각하십시오. 예기치 않은 급증에는 Anomaly Detection을 사용하고 최적화 검사에는 Trusted Advisor를 사용하십시오. 예산 임계값 알림에는 사용하지 마십시오.

문제 4

금융 서비스 회사가 사용자 지정 저장 프로시저 및 독점 분석 도구가 있는 Microsoft SQL Server 데이터베이스에서 고객 포트폴리오 관리 시스템을 운영합니다. 데이터베이스 유지 관리, 백업 관리 및 데이터 센터 비용으로 인한 운영 오버헤드가 증가함에 따라 회사는 신속하게 AWS로 마이그레이션해야 합니다. 애플리케이션은 특수 타사 금융 계산 라이브러리 및 사용자 지정 보안 확장을 사용하기 위해 관리자 권한이 필요합니다. 회사는 예산이 제한되어 있으며 현재 기능을 유지하면서 가장 비용 효율적인 마이그레이션 솔루션을 원합니다. 회사가 데이터베이스를 AWS로 가장 비용 효율적으로 마이그레이션하는 데 도움이 되는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 OS/DB 수준의 관리자 권한이 필요한 SQL Server 기능을 보존하면서 가장 비용 효율적인 AWS 데이터베이스 마이그레이션 대상을 선택하는 것을 테스트합니다. 주요 서비스는 Amazon RDS for SQL Server, Amazon RDS Custom for SQL Server 및 Amazon EC2의 SQL Server입니다. 정답인 이유: Amazon RDS Custom for SQL Server는 백업, 패치 오케스트레이션 및 자동화된 모니터링과 같은 차별화되지 않은 과중한 작업을 오프로드하면서 표준 RDS가 허용하는 것 이상의 액세스(예: 타사 에이전트/라이브러리 설치, 사용자 지정 보안 확장 또는 OS/인스턴스 수준 변경)가 필요한 워크로드를 위해 설계되었습니다. 회사는 특수 타사 금융 계산 라이브러리 및 사용자 지정 보안 확장을 사용하기 위해 관리자 권한이 명시적으로 필요합니다. 표준 RDS for SQL Server는 호스트 수준 액세스 및 많은 권한 있는 작업을 제한하므로 현재 기능이 손상될 가능성이 높습니다. EC2는 전체 제어 권한을 유지하지만 운영 오버헤드(패치, 백업, HA 설계, 모니터링)를 줄이지 못하므로 유지 관리 부담과 데이터 센터 비용을 신속하게 줄이려는 목표와 충돌합니다. 주요 AWS 기능: RDS Custom은 자동화된 백업, 특정 시점 복구 및 관리형 유지 관리 기간과 같은 관리형 데이터베이스 이점을 유지하면서 기본 DB 인스턴스/OS(AWS Systems Manager 사용)에 대한 액세스를 통해 "사용자 지정"을 제공합니다. BYOL(Bring-Your-Own-License) 시나리오를 지원하고 AWS KMS 암호화, CloudWatch 지표/로그 및 IAM 제어와 통합됩니다. 일반적으로 전체 아키텍처 재설계 없이 권한 있는 확장이 필요한 "있는 그대로의" SQL Server 워크로드를 마이그레이션하는 가장 빠른 경로입니다. 일반적인 오해: 옵션 C는 EC2가 유연하기 때문에 언뜻 보기에 "가장 저렴해" 보일 수 있지만 지속적인 관리 노력과 HA/DR, 패치 및 백업 프로세스를 엔지니어링해야 할 필요성으로 인해 총 소유 비용이 상승합니다. 옵션 A는 독점적인 데이터베이스 내/호스트 라이브러리를 Lambda로 신속하게 교체할 수 있다고 가정합니다. 이는 일반적으로 주요 리팩터링이며 엄격한 기능 또는 성능 요구 사항을 충족하지 못할 수 있습니다. 옵션 D는 대규모 재작성이며 "신속한 마이그레이션"이 아닙니다. 시험 팁: "시스템 관리자/OS 관리자 액세스 필요", "타사 에이전트", "사용자 지정 드라이버" 또는 "특수 보안 확장"과 같은 요구 사항이 표시되면 RDS Custom(관리형 이점 + 권한 있는 액세스)을 생각하십시오. 운영을 최소화해야 하고 특별한 호스트 액세스가 필요하지 않은 경우 표준 RDS가 일반적으로 비용 최적화된 선택입니다. 최대 제어가 필요하고 운영 부담을 수용할 수 있는 경우 EC2를 선택하십시오.

문제 5

한 게임 회사가 /26 CIDR 블록(192.168.1.0/26)이 있는 VPC에 멀티플레이어 게임 서버를 배포했습니다. 게임의 인기가 높아짐에 따라 피크 시간대에 플레이어 트래픽을 처리하기 위해 더 많은 EC2 인스턴스가 필요합니다. 현재 VPC는 64개의 IP 주소만 수용할 수 있지만, 회사는 확장되는 플레이어 기반을 위해 200개 이상의 게임 서버 인스턴스를 지원하도록 확장해야 합니다. 솔루션은 관리 복잡성과 배포 시간을 최소화해야 합니다. 운영 오버헤드가 가장 적게 IP 주소 부족 문제를 해결하는 솔루션은 무엇입니까?

문제 분석

개요: 핵심 개념: 이 질문은 VPC IP 주소 지정 확장성과 사용 가능한 프라이빗 IPv4 공간을 확장하는 가장 간단한 방법을 테스트합니다. AWS에서 VPC는 기본 IPv4 CIDR과 (선택적으로) 하나 이상의 보조 IPv4 CIDR 블록을 가질 수 있습니다. 그런 다음 연결된 CIDR 블록에서 추가 서브넷을 생성할 수 있습니다. 정답인 이유: 기존 VPC는 /26(총 64개 IP; AWS가 서브넷당 5개를 예약한 후 사용 가능한 수는 더 적음)입니다. 200개 이상의 EC2 게임 서버를 지원하기 위해 회사는 최소한의 운영 오버헤드로 신속하게 더 많은 프라이빗 IP가 필요합니다. 동일한 VPC에 보조 IPv4 CIDR 블록(예: /22)을 추가하는 것이 가장 직접적인 솔루션입니다. 새 VPC, VPC 간 연결, 추가 라우팅 도메인 복잡성, VPC 내 애플리케이션 통신 패턴의 변경이 없습니다. 단순히 새 CIDR을 연결하고, 해당 범위에 새 서브넷을 생성하고, 거기에 추가 인스턴스를 배포하면 됩니다. 주요 AWS 기능: - VPC 보조 IPv4 CIDR 연결: 네트워크를 재설계하지 않고 주소 공간을 확장합니다. - 보조 CIDR의 새 서브넷: 새 Auto Scaling 그룹이나 플릿을 새 서브넷에 배치할 수 있습니다. - 보안 그룹/NACL, IGW/NAT, VPC 엔드포인트: 동일한 VPC에서 재사용할 수 있습니다(종종 새 서브넷 ID를 포함하기 위한 사소한 업데이트만 필요함). - 운영 단순성: 모니터링할 단일 VPC, 단일 핵심 네트워크 구성 요소 세트, 상호 연결 라우팅 정책 없음. 일반적인 오해: 새롭고 더 큰 VPC를 생성하고 연결(피어링, Transit Gateway, VPN)하는 것이 더 "깔끔해" 보일 수 있습니다. 그러나 이러한 접근 방식은 추가 라우팅, 보안 경계 고려 사항, 잠재적인 중복 CIDR 제약 조건 및 운영 작업(여러 VPC, 여러 서브넷 세트, 교차 VPC 트래픽 계획)을 도입합니다. 또한 기존 VPC의 주소 공간을 확장하는 것만큼 간단하게 핵심 문제를 해결하지 못합니다. 시험 팁: VPC 내부의 IP 고갈에 대해 "최소한의 운영 오버헤드"가 요구 사항인 경우, 추가 VPC 및 연결을 생성하는 것보다 보조 IPv4 CIDR(또는 IPv6)을 추가하는 것을 먼저 고려하십시오. Transit Gateway는 다중 VPC/허브 앤 스포크 설계용으로 예약하고, 관리 부담 때문에 프로덕션용 VPN 인스턴스는 피하십시오. 또한 서브넷의 사용 가능한 IP는 AWS의 서브넷당 5개 예약 주소로 인해 줄어들므로 이에 따라 용량을 계획하십시오.

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

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

문제 6

글로벌 미디어 제작 회사가 AWS에 비디오 편집 협업 플랫폼을 배포해야 합니다. 이 플랫폼은 북미, 유럽 및 아시아 태평양 지역에 위치한 스튜디오의 영화 편집자와 콘텐츠 제작자에게 서비스를 제공합니다. 사용자는 2GB에서 50GB 크기의 대용량 비디오 파일을 자주 업로드하고 다운로드합니다. 개발 팀은 파일 전송 지연 시간을 최소화하고 글로벌 사용자를 위한 처리량 성능을 극대화하는 비용 효율적인 아키텍처를 요구합니다. 이를 달성하기 위해 솔루션 아키텍트는 무엇을 권장해야 합니까?

문제 분석

개요: 핵심 개념: 이 질문은 Amazon S3 및 엣지 네트워크 최적화를 사용하여 대용량 객체에 대한 글로벌 고처리량 파일 전송 설계를 테스트합니다. 핵심 개념은 수 GB의 파일을 업로드/다운로드하는 지리적으로 분산된 사용자를 위해 지연 시간을 줄이고 처리량을 향상시키는 것입니다. 정답인 이유: Amazon S3 Transfer Acceleration은 트래픽을 가장 가까운 AWS 엣지 로케이션으로 라우팅한 다음 AWS 글로벌 백본 네트워크를 통해 대상 리전으로 전송함으로써 S3 버킷을 오가는 장거리 전송 속도를 높이도록 특별히 구축되었습니다. 2~50GB의 비디오 파일을 업로드하는 북미, 유럽 및 아시아 태평양 사용자의 경우, Transfer Acceleration은 단일 리전으로 퍼블릭 인터넷을 종단 간 통과하는 것에 비해 업로드 및 다운로드 성능을 크게 향상시킬 수 있습니다. 또한 운영상 비용 효율적입니다. S3에 내구성 있고 확장 가능한 객체 스토리지를 유지하고(플릿 관리 없음), S3 스토리지/요청 비용과 사용 시 가속 요금만 지불하면 됩니다. 주요 AWS 기능: - S3 Transfer Acceleration: 가속 엔드포인트(예: bucketname.s3-accelerate.amazonaws.com)와 AWS 엣지 로케이션을 사용하여 TCP 및 라우팅을 최적화합니다. - S3 멀티파트 업로드(multipart upload): 처리량과 복원력을 극대화하기 위한 대용량 파일의 모범 사례(병렬 파트, 파트당 재시도). - 글로벌 백본: 엣지에서 리전으로의 트래픽이 AWS 네트워크에 유지되어 일반적으로 일관성과 처리량이 향상됩니다. - 중앙 S3 버킷(또는 소규모 리전 버킷 세트)이 기록 시스템인 글로벌 협업 패턴에 잘 작동합니다. 일반적인 오해: - CloudFront는 인기 있는 콘텐츠의 다운로드를 캐싱하고 가속화하는 데 탁월하지만, 대용량의 빈번한 업로드를 위한 기본 업로드 가속 솔루션은 아닙니다(추가 설계를 통해 업로드를 지원할 수는 있음). 질문은 매우 큰 파일의 빈번한 업로드 및 다운로드를 강조하며 Transfer Acceleration을 직접적으로 가리킵니다. - Cache-Control 헤더는 캐싱 동작(일반적으로 브라우저/CDN에 의한)에만 영향을 미치며 본질적으로 글로벌 업로드 처리량을 향상시키지는 않습니다. - EC2 + Auto Scaling은 운영 오버헤드를 추가하며 본질적으로 글로벌 전송 지연 시간을 해결하지 않습니다. 병목 현상은 컴퓨팅 확장이 아니라 네트워크 거리와 라우팅입니다. 시험 팁: "글로벌 사용자", "대용량 파일 업로드", "전송 지연 시간 최소화 / 처리량 극대화"를 보면 S3 Transfer Acceleration(업로드/다운로드) 및 멀티파트 업로드를 생각하십시오. 요구 사항이 주로 "다운로드 가속 및 캐싱"인 경우 CloudFront를 생각하십시오. 또한 질문에서 POSIX 파일 시스템이나 특수 컴퓨팅 처리를 명시적으로 요구하지 않는 한 비용과 확장성을 위해 자체 관리형 EC2 파일 호스팅보다 관리형 스토리지(S3)를 선호하십시오.

문제 7

생명공학 연구 회사가 온프레미스 연구소에서 호스팅되는 게놈 시퀀싱 분석을 위한 고성능 컴퓨팅(high-performance computing) 솔루션을 개발하고 있습니다. 연구 팀은 병렬 I/O 작업이 필요한 특수 생물정보학 소프트웨어를 사용하여 대규모 데이터 세트(분석당 5-50TB)를 처리합니다. 회사는 1밀리초 미만(sub-millisecond)의 지연 시간으로 POSIX 호환 병렬 파일 시스템 액세스를 지원하는 공유 스토리지 솔루션이 필요합니다. 이 솔루션은 완전 관리형이어야 하며 피크 처리 기간 동안 100개 이상의 컴퓨팅 노드에서 발생하는 동시 액세스를 처리할 수 있도록 확장 가능해야 합니다. 고성능 병렬 파일 시스템 액세스에 대한 이러한 요구 사항을 충족하는 AWS 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 많은 동시 클라이언트가 있는 HPC 워크로드를 위해 매우 낮은 지연 시간과 높은 처리량을 제공하는 완전 관리형 POSIX 호환 병렬 파일 시스템의 선택을 테스트합니다. AWS에서 이를 위해 특별히 구축된 관리형 서비스는 Amazon FSx for Lustre입니다. 정답인 이유: Amazon FSx for Lustre는 많은 컴퓨팅 노드의 병렬 I/O가 필요한 게놈, 시뮬레이션 및 ML과 같은 워크로드를 위해 설계된 고성능 병렬 파일 시스템(Lustre)을 제공합니다. POSIX 의미론을 지원하며 여러 스토리지 서버에 데이터를 스트라이핑하여 1밀리초 미만의 지연 시간과 대규모 집계 처리량에 최적화되어 있습니다. 수백 또는 수천 개의 클라이언트를 지원하도록 확장되어 피크 처리 중 100개 이상의 컴퓨팅 노드에 대한 요구 사항과 일치합니다. 주요 AWS 기능: FSx for Lustre는 완전 관리형입니다(프로비저닝, 패치 적용, 모니터링 및 복구를 AWS에서 처리함). SSD 스토리지를 사용하면 가장 낮은 지연 시간과 가장 높은 IOPS 특성을 제공합니다. 컴퓨팅 노드의 Lustre 클라이언트는 진정한 병렬 읽기/쓰기, 메타데이터 성능 및 파일 스트라이핑을 가능하게 합니다. 이는 기존 NFS 기반 시스템이 동일한 성능 수준에서 제공하지 못하는 기능입니다. FSx for Lustre는 일반적으로 HPC 컴퓨팅 플릿과 짝을 이루며 데이터 리포지토리 기능(대규모 게놈 데이터 세트를 스테이징하는 데 유용함)을 위해 S3와 통합될 수 있지만, 여기서 핵심 요구 사항은 병렬 POSIX 액세스와 낮은 지연 시간입니다. 일반적인 오해: Amazon EFS는 종종 "공유 POSIX 스토리지"로 선택되지만 NFS 파일 시스템이며 HPC 스크래치 워크로드를 위한 Lustre 스타일의 병렬 I/O 또는 일반적인 1밀리초 미만의 지연 시간을 제공하지 않습니다. Storage Gateway Volume Gateway는 하이브리드 사용 사례를 위한 블록 스토리지 통합을 제공하지만 병렬 파일 시스템이 아니며 초저지연, 고동시성 HPC I/O 패턴을 위해 설계되지 않았습니다. 시험 팁: "병렬 파일 시스템", "Lustre", "HPC", "게놈", "1밀리초 미만의 지연 시간" 및 "100개 이상의 노드"가 보이면 기본적으로 FSx for Lustre를 선택하십시오. 일반적인 공유 NFS(웹/콘텐츠, 홈 디렉터리)의 경우 EFS를 선택하고, 처리량이 높고 지연 시간이 짧은 병렬 워크로드의 경우 FSx for Lustre를 선택하십시오. 또한 "완전 관리형"은 시험에서 DIY EC2 기반 파일 서버를 최선의 답변에서 제외시킵니다.

문제 8

(2개 선택)

한 금융 서비스 회사가 온프레미스 Red Hat Enterprise Linux 서버에서 Java 기반 거래 애플리케이션을 운영하고 있습니다. 이 애플리케이션은 트랜잭션 데이터와 시장 분석을 저장하기 위해 MySQL Enterprise 데이터베이스를 사용합니다. 증가하는 규제 요구 사항과 비즈니스 성장으로 인해 회사는 AWS로 마이그레이션해야 합니다. 회사는 마이그레이션 중 코드 변경을 최소화하는 동시에 AWS 환경이 내결함성을 제공하고 피크 시장 시간(오전 9시~오후 4시 EST) 동안 거래량을 처리할 수 있도록 보장하고자 합니다. 이러한 요구 사항을 충족하기 위해 회사는 어떤 조치 조합을 취해야 합니까? (2개 선택)

문제 분석

핵심 개념: 이 질문은 상태 저장(stateful), 규제 대상 워크로드에 대한 "복원력이 있는 리프트 앤 시프트(lift-and-shift)"를 테스트합니다. 즉, 내결함성을 달성하고 예측 가능한 피크 수요를 처리하면서 코드 변경을 최소화하여 Java 앱을 실행하는 것입니다. 핵심 서비스는 애플리케이션 계층을 위한 EC2 Auto Scaling + Application Load Balancer(ALB)와 데이터베이스 계층을 위한 Aurora MySQL Multi-AZ이며, AWS DMS로 마이그레이션됩니다. 정답인 이유: 옵션 B는 기존 Java 애플리케이션을 Amazon EC2에 배포하는 것이 현재 RHEL 서버와 가장 유사하기 때문에 "코드 변경 최소화"와 가장 잘 일치합니다. ALB 뒤에 여러 Availability Zone에 걸쳐 Auto Scaling group을 사용하면 고가용성(AZ 장애 허용)과 피크 거래 시간(오전 9시-오후 4시 EST) 동안 scale out하고 이후에 scale in할 수 있는 탄력성을 제공합니다. 옵션 D는 가용성과 운영 복원력을 향상시키면서 관계형 MySQL 엔진 의미 체계를 보존합니다. AWS DMS를 사용하여 Amazon Aurora MySQL(MySQL과 호환됨)로 마이그레이션하면 데이터베이스 패러다임 전환에 비해 애플리케이션 변경이 최소화됩니다. Aurora Multi-AZ(작성자 및 AZ 전반에 복제된 스토리지, 장애 조치 포함)는 금융 워크로드에 적합한 강력한 내결함성을 제공합니다. 주요 AWS 기능: - 정상적인 instance로만 트래픽을 라우팅하기 위한 ALB 상태 검사 + 교차 AZ 로드 밸런싱. - 피크 처리를 위한 예약된 조정(예측 가능한 시장 시간) 및/또는 대상 추적(CPU/RequestCount)이 있는 EC2 Auto Scaling. - 리팩터링을 줄이기 위한 Aurora MySQL 호환성; Multi-AZ 장애 조치 및 관리형 백업. - 컷오버 중 가동 중지 시간을 줄이기 위한 지속적인 복제(CDC)를 위한 AWS DMS. 일반적인 오해: Fargate(A)도 운영을 줄일 수 있지만 "컨테이너화"는 종종 패키징 변경, 새로운 빌드 파이프라인 및 잠재적인 런타임 차이를 의미하며, 이는 간단한 EC2 리호스팅보다 더 많은 변경입니다. Lambda(C)로 다시 작성하는 것은 "코드 변경 최소화"의 반대입니다. DocumentDB(E)는 MySQL과 호환되지 않습니다. MongoDB와 호환되며 상당한 스키마/쿼리 리팩터링이 필요합니다. 시험 팁: "코드 변경 최소화"가 보이면 리팩터링(Lambda/마이크로서비스) 또는 데이터베이스 모델 변경(NoSQL)보다 리호스트/리플랫폼 패턴(EC2, 관리형 관계형 DB)을 기본으로 사용하십시오. "내결함성"의 경우 컴퓨팅(AZ 전반의 ASG) 및 데이터(Aurora Multi-AZ) 모두에서 Multi-AZ 설계를 찾고 가동 중지 시간이 짧은 마이그레이션을 위해 DMS를 고려하십시오.

문제 9

한 금융 서비스 회사가 AWS에서 실시간 거래 플랫폼을 운영하고 있습니다. 모든 거래 주문은 단일 Availability Zone의 Amazon EC2 인스턴스에서 실행되는 RabbitMQ 대기열에 메시지로 게시됩니다. 이 메시지들은 별도의 EC2 인스턴스에서 실행되는 위험 평가 애플리케이션에 의해 처리됩니다. 이 애플리케이션은 거래 데이터를 또 다른 EC2 인스턴스의 MySQL 데이터베이스에 저장합니다. 모든 EC2 인스턴스는 동일한 Availability Zone에 있습니다. 이 회사는 99.9%의 가동 시간을 요구하는 규정 준수 요구 사항으로 인해 최소한의 운영 오버헤드로 최고의 가용성을 제공하도록 아키텍처를 재설계해야 합니다. 솔루션 아키텍트는 이러한 요구 사항을 충족하기 위해 무엇을 해야 합니까?

문제 분석

핵심 개념: 이 질문은 관리형 서비스(Amazon MQ, Amazon RDS Multi-AZ)와 상태 비저장 스케일링 패턴(Auto Scaling)을 사용하여 최소한의 운영 오버헤드로 Availability Zone 전반에 걸친 고가용성(HA)을 설계하는 능력을 테스트합니다. 정답인 이유: 현재 설계는 단일 AZ의 EC2 관리형 스택(RabbitMQ, 앱, MySQL)으로, 여러 단일 장애점과 높은 운영 부담(패치, 백업, 장애 조치, 모니터링, 복구)을 발생시킵니다. 최소한의 운영 오버헤드로 99.9%의 가동 시간을 충족하기 위한 최선의 접근 방식은 (1) 브로커를 관리형 HA 서비스로 이동하고, (2) 데이터베이스를 관리형 Multi-AZ 서비스로 이동하며, (3) 애플리케이션 계층을 Multi-AZ 및 자가 복구 가능하게 만드는 것입니다. 옵션 B가 정확히 이를 수행합니다. Amazon MQ for RabbitMQ는 AZ 전반에 걸쳐 내장된 active/standby 브로커 중복성을 제공하며, Amazon RDS for MySQL Multi-AZ는 동기식 복제 및 자동 장애 조치를 제공합니다. 위험 평가 애플리케이션은 인스턴스/AZ 장애를 견딜 수 있도록 로드 밸런서(암시됨) 뒤의 Multi-AZ Auto Scaling 그룹에 배포될 수 있습니다. 주요 AWS 기능: - Amazon MQ for RabbitMQ: 관리형 브로커, 자동화된 프로비저닝/패치, HA를 위한 active/standby 배포, 간소화된 모니터링/통합. - Amazon RDS for MySQL Multi-AZ: 다른 AZ의 대기 인스턴스로의 동기식 복제, 자동 장애 조치, 관리형 백업, 패치 및 유지 관리. - 여러 AZ의 서브넷에 걸친 EC2 Auto Scaling: 실패한 인스턴스를 자동으로 교체하고 스케일링을 지원합니다. 탄력적인 트래픽 분산을 위해 Application Load Balancer와 함께 사용합니다. 일반적인 오해: A와 D는 EC2의 데이터베이스에 Auto Scaling을 사용할 것을 제안합니다. 데이터베이스는 상태 저장(stateful)입니다. Auto Scaling 자체는 데이터베이스 복제, 일관된 스토리지 또는 자동 장애 조치를 제공하지 않습니다. 여전히 복제, 백업 및 장애 조치를 직접 엔지니어링해야 합니다(높은 운영 오버헤드). C와 D는 또한 Auto Scaling을 사용하여 EC2에서 RabbitMQ를 실행할 것을 제안합니다. 메시지 브로커는 상태 저장이며 클러스터링/쿼럼, 내구성 있는 스토리지 및 신중한 장애 조치 처리가 필요하므로 Amazon MQ에 비해 운영 복잡성이 다시 증가합니다. 시험 팁: 요구 사항이 '최고의 가용성'과 '최소한의 운영 오버헤드'를 강조할 때, 내장된 Multi-AZ 및 자동 장애 조치 기능이 있는 관리형 서비스(RDS Multi-AZ, Amazon MQ 등)를 선호하십시오. 상태 비저장 계층에는 Auto Scaling을 사용하고, Auto Scaling만으로 상태 저장 구성 요소(데이터베이스/브로커)를 고가용성으로 만든다고 가정하지 마십시오.

문제 10

(3개 선택)

한 의료 네트워크가 .csv 형식으로 진단 보고서를 생성하는 on-premises 의료 영상 기기를 갖춘 여러 클리닉을 운영하고 있습니다. 이 네트워크는 더 나은 확장성과 비용 효율성을 위해 데이터 분석을 AWS Cloud로 마이그레이션하고자 합니다. 영상 기기는 SMB file share에 데이터를 쓸 수 있으며, 의료 연구 팀은 환자 진단 추세에 대해 SQL 기반 분석을 수행해야 합니다. 연구 팀은 업무 시간 동안 매일 3~4회 분석 쿼리를 실행합니다. 솔루션은 비용 효율적이어야 하며 의료 기기에서 생성된 .csv 파일에 대한 표준 SQL 쿼리 기능을 지원해야 합니다. 이러한 요구 사항을 가장 비용 효율적으로 충족하는 단계의 조합은 무엇입니까? (3개 선택)

문제 분석

핵심 개념: 이 질문은 on-premises에서 생성된 파일에 대한 비용 최적화된 serverless 분석 패턴을 테스트합니다. .csv 데이터를 Amazon S3에 저장하고 Amazon Athena를 사용하여 표준 SQL로 쿼리하며, AWS Glue Data Catalog가 스키마 메타데이터를 제공합니다. 정답인 이유: 의료 기기는 SMB share에만 쓸 수 있으므로, 사용자 지정 전송 소프트웨어를 구축하지 않고 AWS로 수집하는 가장 비용 효율적인 방법은 S3 File Gateway 모드의 AWS Storage Gateway(A)입니다. 이는 로컬에 SMB file share를 제공하고 객체를 Amazon S3에 내구성 있게 저장하므로 .csv 보고서 파일에 이상적입니다. 데이터가 S3에 저장되면 연구 팀은 하루에 몇 번 SQL 쿼리를 실행해야 합니다. Amazon Athena(F)는 serverless이며 스캔한 TB당 요금을 청구하므로 항상 켜져 있는 cluster에 비해 간헐적인 분석에 매우 비용 효율적입니다. 적절한 스키마, 파티션 및 테이블 정의를 사용하여 SQL 쿼리를 활성화하려면 AWS Glue crawler(C)가 S3 데이터에서 스키마를 추론하고 Athena가 사용하는 Glue Data Catalog에서 테이블을 생성/유지 관리할 수 있습니다. 주요 AWS 기능: S3 File Gateway는 S3에 데이터를 영구 저장하면서 지연 시간이 짧은 액세스를 위한 로컬 캐싱과 함께 SMB/NFS 액세스를 지원합니다. S3는 보존을 위한 저비용의 내구성 있는 스토리지 및 수명 주기 정책을 제공합니다. Glue crawler는 스키마 검색을 자동화하고 Data Catalog를 업데이트합니다. Athena는 Presto/Trino 기반 SQL을 사용하고, Glue Data Catalog와 통합되며, 스캔되는 데이터를 줄이기 위해 파티셔닝(날짜/클리닉별)을 지원하고, 미사용 데이터(S3 SSE-KMS) 및 전송 중 데이터를 암호화할 수 있습니다. 일반적인 오해: EMR(D)은 S3를 쿼리할 수 있지만 cluster를 프로비저닝하고 비용을 지불해야 하므로(또는 일시적인 cluster를 관리해야 하므로) 매일 3~4회의 쿼리를 실행하기에는 일반적으로 더 비싸고 운영 부담이 큽니다. Redshift(E)는 COPY/Spectrum을 통해 S3를 쿼리할 수 있지만, 원시 CSV에 대한 가볍고 주기적인 ad hoc 쿼리의 경우 cluster(또는 serverless)가 가장 비용 효율적인 방법은 아닙니다. FSx File Gateway 모드(B)는 여기에 적합하지 않습니다. 요구 사항은 AWS에서 Windows 파일 시스템을 유지 관리하는 것이 아니라 S3 객체에 대한 분석과 함께 SMB 수집을 수행하는 것입니다. 시험 팁: 간헐적으로 사용하는 "S3의 파일에 대한 SQL"의 경우 기본적으로 Athena + Glue Data Catalog를 선택하십시오. 사용자 지정 코드 없이 "on-prem SMB/NFS에서 S3로"의 경우 기본적으로 Storage Gateway S3 File Gateway를 선택하십시오. "매일 몇 번" 및 "비용 효율적"과 같은 비용 단서를 찾으십시오. 이는 일반적으로 항상 켜져 있는 cluster를 배제합니다.

Practice Test #3

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(29)

다른 모의고사

Practice Test #1

Practice Test #2

Practice Test #4

Practice Test #5

Practice Test #6

Practice Test #7

Practice Test #8

Practice Test #9

Practice Test #10

지금 학습 시작하기