AWS SAA-C03 Examtopics (641 ~ 660)

AWS Certified Solutions Architect - Associate 공부하면서 작성된 글로 일부오류가있을수있습니다.

 

■ Question #641

한 회사가 재무 검토를 위해 AWS 비용을 모니터링하고자 합니다. 클라우드 운영팀은 AWS Organizations 관리 계정에서 모든 멤버 계정에 대한 AWS 비용 및 사용 보고서를 쿼리하는 아키텍처를 설계하고 있습니다. 팀은 한 달에 한 번 이 쿼리를 실행하고 청구서에 대한 자세한 분석을 제공해야 합니다.

이러한 요구 사항을 충족하는 가장 확장 가능하고 비용 효율적인 방법은 어떤 솔루션입니까?

A. 관리 계정에서 비용 및 사용 보고서를 활성화합니다. Amazon Kinesis에 보고서를 전달합니다. Amazon EMR을 사용하여 분석합니다.
B. 관리 계정에서 비용 및 사용 보고서를 활성화합니다. 보고서를 Amazon S3에 전달합니다. 분석을 위해 Amazon Athena를 사용합니다.
C. 멤버 계정에 대한 비용 및 사용 보고서를 활성화합니다. 보고서를 Amazon S3에 전달합니다. 분석을 위해 Amazon Redshift를 사용합니다.
D. 멤버 계정에 대한 비용 및 사용 보고서를 활성화합니다. 보고서를 Amazon Kinesis에 전달합니다. Amazon QuickSight tor 분석을 사용합니다.

B. 관리 계정에서 비용 및 사용 보고서를 활성화합니다. 보고서를 Amazon S3에 전달합니다. 분석을 위해 Amazon Athena를 사용합니다.

관리 계정에서 비용 및 사용 보고서를 활성화
- AWS Organizations 관리 계정은 모든 멤버 계정의 비용 및 사용 데이터를 수집할 수 있습니다.
- 관리 계정에서 비용 및 사용 보고서를 활성화하면 AWS Billing and Cost Management 콘솔에서 데이터를 Amazon S3로 자동으로 전달할 수 있습니다.

Amazon S3에 비용 및 사용 보고서 저장
- 비용 및 사용 보고서는 CSV 형식의 정형 데이터로 Amazon S3에 저장됩니다.
- S3의 저렴한 스토리지와 데이터 수명 주기 관리 기능을 사용하여 비용을 절감할 수 있습니다.

Amazon Athena를 사용한 분석
- Amazon Athena는 서버리스 대화형 쿼리 서비스로, S3에 저장된 데이터를 SQL로 직접 분석할 수 있습니다.
- 비용 효율적이며, 한 달에 한 번 실행되는 쿼리에 적합합니다.
- Athena의 확장성을 통해 대규모 데이터도 효율적으로 처리할 수 있습니다.
- 별도의 데이터 이동이나 ETL 작업이 필요 없으므로 관리 오버헤드가 최소화됩니다.

---

■ Question #642

한 회사가 AWS 클라우드의 자동 확장 그룹에 속하는 Amazon EC2 인스턴스에서 게임 애플리케이션을 실행하려고 합니다. 이 애플리케이션은 UDP 패킷을 사용하여 데이터를 전송합니다. 이 회사는 트래픽이 증가하거나 감소함에 따라 애플리케이션이 확장 및 축소될 수 있도록 하려고 합니다.

솔루션 아키텍트는 이러한 요구 사항을 충족하기 위해 무엇을 해야 할까요?

A. 자동 크기 조정 그룹에 네트워크 부하 분산 장치를 연결합니다.
B. 자동 크기 조정 그룹에 애플리케이션 부하 분산 장치를 연결합니다.
C. 트래픽을 적절히 라우팅하기 위해 가중치가 적용된 정책으로 Amazon Route 53 레코드 세트를 배포합니다.
D. 자동 크기 조정 그룹의 EC2 인스턴스로 포트 포워딩이 구성된 NAT 인스턴스를 배포합니다.

A. 자동 크기 조정 그룹에 네트워크 부하 분산 장치를 연결합니다.

UDP 트래픽 처리
- 네트워크 로드 밸런서(Network Load Balancer, NLB)는 UDP 트래픽을 지원합니다. UDP는 연결 지향이 아닌 프로토콜이므로 TCP 기반 애플리케이션 로드 밸런서(ALB)보다 NLB가 적합합니다.
- NLB는 EC2 인스턴스 간에 UDP 트래픽을 효율적으로 라우팅할 수 있습니다.

자동 크기 조정 지원
- NLB는 자동 크기 조정 그룹(ASG)와 쉽게 통합되며, EC2 인스턴스의 가용성 및 확장을 지원합니다.
- ASG는 트래픽이 증가하거나 감소할 때 인스턴스를 자동으로 추가하거나 제거하여 확장 및 축소를 원활히 수행합니다.

고성능 및 확장성
- NLB는 고성능 및 저지연 요구 사항을 충족하며, 게임 애플리케이션과 같은 실시간 트래픽 처리에 이상적입니다.
- 특히 대규모 UDP 트래픽 처리에서 효율적입니다.

---

■ Question #643

한 회사가 다양한 브랜드를 위해 AWS에서 여러 웹사이트를 운영합니다. 각 웹사이트는 매일 수십 기가바이트의 웹 트래픽 로그를 생성합니다. 솔루션 아키텍트는 회사 개발자가 모든 회사 웹사이트의 트래픽 패턴을 분석할 수 있는 확장 가능한 솔루션을 설계해야 합니다. 개발자의 이러한 분석은 몇 달 동안 일주일에 한 번씩 필요에 따라 수행됩니다. 솔루션은 표준 SQL을 사용한 쿼리를 지원해야 합니다.

이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?

A. Amazon S3에 로그를 저장합니다. Amazon Athena tor 분석을 사용합니다.
B. Amazon RDS에 로그를 저장합니다. 분석을 위해 데이터베이스 클라이언트를 사용합니다.
C. Amazon OpenSearch Service에 로그를 저장합니다. OpenSearch Service를 사용하여 분석합니다.
D. Amazon EMR 클러스터에 로그를 저장합니다. SQL 기반 분석을 위해 지원되는 오픈 소스 프레임워크를 사용합니다.

A. Amazon S3에 로그를 저장합니다. Amazon Athena tor 분석을 사용합니다.

저비용 스토리지 및 분석
- Amazon S3는 비용 효율적이고 확장 가능한 스토리지 솔루션입니다. 대량의 로그 데이터를 수십 기가바이트에서 수백 기가바이트 이상으로 안전하게 저장할 수 있습니다.
- Amazon Athena는 서버리스 SQL 기반 쿼리 서비스로, S3에 저장된 데이터를 직접 분석할 수 있습니다. 추가적인 인프라 프로비저닝이 필요하지 않으므로 비용이 절감됩니다.
- 표준 SQL 지원: Athena는 표준 SQL을 사용하여 데이터를 쿼리할 수 있으므로 개발자가 별도의 학습 없이 쉽게 사용할 수 있습니다.

주간 분석 및 비용 효율성
- 로그 데이터 분석이 일주일에 한 번 수행되므로 서버리스인 Athena를 사용하는 것이 적합합니다. Athena는 사용한 만큼만 비용을 지불하므로 비정기적인 분석에 매우 효율적입니다.

확장성 및 관리 오버헤드 최소화
- Athena는 완전 관리형 서비스이므로 유지 관리가 필요 없습니다. Amazon S3는 거의 무제한의 확장성을 제공하므로 로그 데이터 증가에도 효과적으로 대응할 수 있습니다.

---

■ Question #644

국제적인 회사에는 회사가 운영하는 각 국가에 대한 하위 도메인이 있습니다. 하위 도메인은 example.com, country1. example.com, country2.example.com으로 포맷됩니다. 회사의 워크로드는 Application Load Balancer 뒤에 있습니다. 회사는 전송 중인 웹사이트 데이터를 암호화하려고 합니다.

이러한 요구 사항을 충족하는 단계의 조합은 무엇입니까? (두 가지를 선택하세요.)

A. AWS Certificate Manager(ACM) 콘솔을 사용하여 최상위 도메인 example com에 대한 공용 인증서와 *.example.com에 대한 와일드카드 인증서를 요청합니다.
B. AWS Certificate Manager(ACM) 콘솔을 사용하여 최상위 도메인 example.com에 대한 개인 인증서와 *.example.com에 대한 와일드카드 인증서를 요청합니다.
C. AWS Certificate Manager(ACM) 콘솔을 사용하여 최상위 도메인 example.com에 대한 공개 및 비공개 인증서를 요청합니다.
D. 이메일 주소로 도메인 소유권을 검증합니다. DNS 공급자에 필요한 DNS 레코드를 추가하여 DNS 검증으로 전환합니다.
E. DNS 공급자에 필요한 DNS 레코드를 추가하여 도메인의 도메인 소유권을 검증합니다.

A. AWS Certificate Manager(ACM) 콘솔을 사용하여 최상위 도메인 example.com에 대한 공용 인증서와 *.example.com에 대한 와일드카드 인증서를 요청합니다.
- 이 단계는 최상위 도메인 ('example.com') 및 하위 도메인('.example.com', 예: 'country1.example.com', 'country2 .example.com') 모두에 대해 유효한 인증서를 확보하는 데 필요합니다.
- 와일드카드 인증서는 하위 도메인을 지원하며, 전송 중인 데이터를 암호화하기 위해 필요합니다.
- 공용 인증서는 인터넷에서 액세스 가능한 웹사이트에 적합합니다.

E. DNS 공급자에 필요한 DNS 레코드를 추가하여 도메인의 도메인 소유권을 검증합니다.
- ACM에서 요청한 인증서를 활성화하려면 도메인 소유권을 검증해야 합니다.
- DNS 검증은 안정적이고 한 번 설정하면 추가적인 작업 없이 인증서를 갱신할 수 있어 이메일 검증보다 관리 오버헤드가 낮습니다.

---

■ Question #645

회사는 온프레미스 키 관리자에서 암호화 키를 사용해야 합니다. 키 관리자는 규제 및 규정 준수 요구 사항으로 인해 AWS 클라우드 외부에 있습니다. 회사는 AWS 클라우드 외부에 보관되고 다양한 공급업체의 다양한 외부 키 관리자를 지원하는 암호화 키를 사용하여 암호화 및 복호화를 관리하려고 합니다.

어떤 솔루션이 최소한의 운영 오버헤드로 이러한 요구 사항을 충족할까요?

A. CloudHSM 클러스터로 지원되는 AWS CloudHSM 키 저장소를 사용합니다.
B. 외부 키 관리자가 지원하는 AWS Key Management Service(AWS KMS) 외부 키 저장소를 사용합니다.
C. 기본 AWS Key Management Service(AWS KMS) 관리 키 저장소를 사용합니다.
D. AWS CloudHSM 클러스터가 지원하는 사용자 지정 키 저장소를 사용합니다.

B. 외부 키 관리자가 지원하는 AWS Key Management Service(AWS KMS) 외부 키 저장소를 사용합니다.

AWS Key Management Service(AWS KMS) 외부 키 저장소(EKS)는 외부 키 관리자를 AWS KMS와 통합하여 AWS 클라우드에서 암호화 및 복호화를 수행할 수 있는 기능을 제공합니다. EKS는 다음과 같은 이점을 제공합니다:

외부 키 관리자의 통합 지원
- 규제 및 규정 준수 요구 사항으로 인해 키를 온프레미스에 보관해야 하는 경우, 외부 키 관리자를 통해 AWS 리소스에서 암호화 및 복호화를 수행할 수 있습니다.
- 키는 AWS 클라우드 외부에 남아 있으면서도 AWS KMS API를 통해 암호화 작업을 관리할 수 있습니다.

운영 오버헤드 최소화
- AWS KMS API를 계속 사용할 수 있으므로 개발팀은 키 관리와 관련된 코드 변경 없이 외부 키를 사용할 수 있습니다.

다양한 공급업체 지원
- EKS는 여러 외부 키 관리자와의 통합을 지원하여 다양한 키 관리 시스템과의 유연성을 제공합니다.

---

■ Question #646

솔루션 아키텍트는 AWS 클라우드에서 고성능 컴퓨팅(HPC) 워크로드를 호스팅해야 합니다. 워크로드는 수백 개의 Amazon EC2 인스턴스에서 실행되며, 대규모 데이터 세트의 분산 처리를 가능하게 하기 위해 공유 파일 시스템에 대한 병렬 액세스가 필요합니다. 데이터 세트는 여러 인스턴스에서 동시에 액세스됩니다. 워크로드는 1ms 이내의 액세스 지연 시간이 필요합니다. 처리가 완료된 후 엔지니어는 수동 후처리를 위해 데이터 세트에 액세스해야 합니다.

어떤 솔루션이 이러한 요구 사항을 충족할까요?

A. Amazon Elastic File System(Amazon EFS)을 공유 파일 시스템으로 사용합니다. Amazon EFS에서 데이터 세트에 액세스합니다.
B. 공유 파일 시스템으로 사용할 Amazon S3 버킷을 마운트합니다. S3 버킷에서 직접 후처리를 수행합니다.
C. Amazon FSx for Lustre를 공유 파일 시스템으로 사용합니다. 후처리를 위해 파일 시스템을 Amazon S3 버킷에 연결합니다.
D. AWS Resource Access Manager를 구성하여 Amazon S3 버킷을 공유하면 모든 인스턴스에 마운트하여 처리 및 사후 처리를 수행할 수 있습니다.

C. Amazon FSx for Lustre를 공유 파일 시스템으로 사용합니다. 후처리를 위해 파일 시스템을 Amazon S3 버킷에 연결합니다.

Amazon FSx for Lustre는 AWS에서 제공하는 고성능 병렬 파일 시스템으로, 고속 데이터 처리가 필요한 고성능 컴퓨팅(HPC) 및 빅데이터 워크로드를 위해 설계되었습니다. FSx for Lustre는 오픈 소스 Lustre 파일 시스템을 기반으로 하며, 데이터 집약적인 애플리케이션에서 초고속 처리와 낮은 지연 시간을 제공합니다.

다음과 같은 이유로 이 옵션이 적합합니다.
병렬 액세스 및 낮은 지연 시간
- FSx for Lustre는 1ms 미만의 짧은 지연 시간과 수백 GB/s의 처리량을 제공하여 대규모 데이터 세트를 다루는 HPC 워크로드에 적합합니다.
- 여러 EC2 인스턴스에서 동시에 병렬로 데이터에 액세스할 수 있습니다.

S3와의 원활한 통합
- FSx for Lustre는 Amazon S3와 통합하여 데이터를 쉽게 가져오거나 내보낼 수 있습니다. 엔지니어는 FSx for Lustre에 저장된 데이터 세트를 S3로 내보낸 후, 후처리를 수행할 수 있습니다.

고성능 공유 파일 시스템
- FSx for Lustre는 HPC 워크로드를 위해 설계된 고성능 병렬 파일 시스템으로, 컴퓨팅 집약적 워크로드에 최적화되어 있습니다.

---

■ Question #647

게임 회사가 VoIP 기능을 갖춘 애플리케이션을 구축하고 있습니다. 이 애플리케이션은 전 세계 사용자에게 트래픽을 제공합니다. 이 애플리케이션은 AWS 리전에서 자동화된 장애 조치를 통해 고가용성을 갖춰야 합니다. 이 회사는 사용자 기기에서 IP 주소 캐싱에 의존하지 않고도 사용자의 지연 시간을 최소화하고자 합니다.

솔루션 아키텍트는 이러한 요구 사항을 충족하기 위해 무엇을 해야 할까요?

A. AWS Global Accelerator를 상태 점검과 함께 사용합니다.
B. 지리적 위치 라우팅 정책과 함께 Amazon Route 53을 사용합니다.
C. 여러 출처를 포함하는 Amazon CloudFront 배포를 생성합니다.
D. 경로 기반 라우팅을 사용하는 애플리케이션 로드 밸런서를 생성합니다.

A. AWS Global Accelerator를 상태 점검과 함께 사용합니다.

AWS Global Accelerator는 전 세계 사용자에게 지연 시간이 낮고 고가용성을 보장하는 글로벌 네트워크 경로를 제공합니다. 또한, IP 주소 캐싱에 의존하지 않으면서 장애 조치와 지연 시간 최적화를 수행할 수 있는 솔루션입니다.

사용자 지연 시간 최소화
- AWS Global Accelerator는 사용자가 가장 가까운 AWS 엣지 로케이션을 통해 연결할 수 있도록 글로벌 Anycast IP를 제공하여 지연 시간을 최소화합니다.

자동화된 장애 조치
- 상태 점검을 통해 활성 리전의 상태를 지속적으로 모니터링하고, 리전 장애가 발생하면 자동으로 트래픽을 다른 리전으로 라우팅합니다.

IP 주소 캐싱 문제 해결
- Global Accelerator는 고정 Anycast IP를 사용하므로 사용자 디바이스의 IP 주소 캐싱 문제를 방지하며, 트래픽을 자동으로 최적의 리전으로 라우팅할 수 있습니다.

---

■ Question #648

기상 예보 회사는 밀리초 미만의 지연 시간으로 수백 기가바이트의 데이터를 처리해야 합니다. 이 회사는 데이터 센터에 고성능 컴퓨팅(HPC) 환경을 보유하고 있으며 예측 기능을 확장하려고 합니다. 솔루션 아키텍트는 대량의 지속적인 처리량을 처리할 수 있는 고가용성 클라우드 스토리지 솔루션을 식별해야 합니다. 솔루션에 저장된 파일은 전체 데이터 세트에 동시에 액세스하고 처리하는 수천 개의 컴퓨팅 인스턴스에서 액세스할 수 있어야 합니다.

솔루션 아키텍트는 이러한 요구 사항을 충족하기 위해 무엇을 해야 합니까?

A. Lustre 스크래치 파일 시스템에 Amazon FSx를 사용하세요.
B. Lustre 영구 파일 시스템에 Amazon FSx를 사용합니다.
C. 버스팅 처리량 모드로 Amazon Elastic File System(Amazon EFS)을 사용합니다.
D. Provisioned Throughput 모드를 사용하여 Amazon Elastic File System(Amazon EFS)을 사용합니다.

B. Lustre 영구 파일 시스템에 Amazon FSx를 사용합니다.

높은 처리량 및 낮은 지연 시간
- Lustre 파일 시스템은 대규모 HPC 워크로드에 적합하며, 밀리초 미만의 지연 시간으로 데이터를 처리할 수 있습니다.

대규모 병렬 액세스
- Lustre 파일 시스템은 수천 개의 컴퓨팅 인스턴스에서 병렬로 데이터를 액세스하고 처리할 수 있도록 설계되었습니다.

영구 데이터 보존
- 영구 파일 시스템은 데이터를 지속적으로 보존하고, 여러 워크로드 및 세션에서 동일한 데이터 세트를 사용할 수 있도록 지원합니다. 스크래치 파일 시스템(A)과 비교할 때 데이터 보존이 필요할 때 적합합니다.

---

■ Question #649

전자상거래 회사가 온프레미스에서 PostgreSQL 데이터베이스를 운영합니다. 이 데이터베이스는 높은 IOPS Amazon Elastic Block Store(Amazon EBS) 블록 스토리지를 사용하여 데이터를 저장합니다. 초당 일일 최대 I/O 트랜잭션은 15,000 IOPS를 초과하지 않습니다. 이 회사는 데이터베이스를 Amazon RDS for PostgreSQL로 마이그레이션하고 디스크 스토리지 용량과 무관하게 디스크 IOPS 성능을 프로비저닝하려고 합니다.

어떤 솔루션이 이러한 요구 사항을 가장 비용 효율적으로 충족할까요?

A. 일반 용도 SSD(gp2) EBS 볼륨 스토리지 유형을 구성하고 15,000 IOPS를 프로비저닝합니다.
B. 프로비저닝된 IOPS SSD(io1) EBS 볼륨 스토리지 유형을 구성하고 15,000 IOPS를 프로비저닝합니다.
C. 일반 용도 SSD(gp3) EBS 볼륨 스토리지 유형을 구성하고 15,000 IOPS를 프로비저닝합니다.
D. 최대 IOPS를 달성하도록 EBS 자기 볼륨 유형을 구성합니다.

C. 일반 용도 SSD(gp3) EBS 볼륨 스토리지 유형을 구성하고 15,000 IOPS를 프로비저닝합니다.
- Amazon RDS for PostgreSQL에서 IOPS 요구 사항을 충족하는 가장 비용 효율적인 방식은 gp3 EBS 볼륨을 사용하는 것입니다. 

---

■ Question #650

한 회사가 온프레미스 Microsoft SQL Server Enterprise Edition 데이터베이스를 AWS로 마이그레이션하려고 합니다. 회사의 온라인 애플리케이션은 데이터베이스를 사용하여 거래를 처리합니다. 데이터 분석 팀은 동일한 프로덕션 데이터베이스를 사용하여 분석 처리를 위한 보고서를 실행합니다. 회사는 가능한 한 관리형 서비스로 이동하여 운영 오버헤드를 줄이고자 합니다.

어떤 솔루션이 이러한 요구 사항을 가장 적은 운영 오버헤드로 충족할까요?

A. Microsoft SOL Server용 Amazon RDS로 마이그레이션합니다. 보고 목적으로 읽기 복제본을 사용합니다.
B. Amazon EC2에서 Microsoft SQL Server로 마이그레이션합니다. 보고 목적으로 Always On 읽기 복제본을 사용합니다.
C. Amazon DynamoDB로 마이그레이션합니다. 보고 목적으로 DynamoDB 주문형 복제본 사용
D. Amazon Aurora MySQL로 마이그레이션합니다. 보고 목적으로 Aurora 읽기 복제본을 사용합니다.

A. Microsoft SQL Server용 Amazon RDS로 마이그레이션합니다. 보고 목적으로 읽기 복제본을 사용합니다.

운영 오버헤드를 줄이고 관리형 서비스를 사용하려는 회사의 요구 사항과 Microsoft SQL Server의 기존 환경을 고려했을 때, Amazon RDS for SQL Server가 최적의 선택입니다. 이 솔루션은 관리형 서비스로 운영 오버헤드를 최소화하며, 읽기 복제본을 활용하여 보고 및 분석 워크로드를 분리할 수 있습니다.

장점
- Amazon RDS for SQL Server는 완전 관리형 서비스로, 운영 오버헤드를 크게 줄입니다. (예: 패치, 백업, 스케일링 자동화)
- RDS 읽기 복제본을 활용하여 읽기 전용 워크로드(보고 및 분석)를 처리하고, 프로덕션 데이터베이스에 부담을 줄일 수 있습니다.
- Microsoft SQL Server Enterprise Edition의 기능을 유지합니다.

---

■ Question #651

한 회사가 Amazon S3 버킷에 대량의 이미지 파일을 저장합니다. 이미지는 처음 180일 동안 쉽게 사용할 수 있어야 합니다. 이미지는 그 다음 180일 동안은 거의 액세스하지 않습니다. 360일 후에는 이미지를 보관해야 하지만 요청 시 즉시 사용할 수 있어야 합니다. 5년 후에는 감사자만 이미지에 액세스할 수 있습니다. 감사자는 12시간 이내에 이미지를 검색할 수 있어야 합니다. 이 프로세스 중에 이미지가 손실되어서는 안 됩니다. 개발자는 처음 180일 동안 S3 Standard 스토리지를 사용합니다. 개발자는 S3 Lifecycle 규칙을 구성해야 합니다.

이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?

A. 180일 후에 객체를 S3 One Zone-Infrequent Access(S3 One Zone-IA)로 전환합니다. 360일 후에는 S3 Glacier Instant Retrieval로, 5년 후에는 S3 Glacier Deep Archive로 전환합니다.
B. 180일 후에 객체를 S3 One Zone-Infrequent Access(S3 One Zone-IA)로 전환합니다. 360일 에에 S3 Glacier Flexible Retrieval로, 5년 후에 S3 Glacier Deep Archive로 전환합니다.
C. 180일 후에 객체를 S3 Standard-Infrequent Access(S3 Standard-IA)로, 360일 후에 S3 Glacier Instant Retrieval로, 5년 후에 S3 Glacier Deep Archive로 전환합니다.
D. 180일 후에 객체를 S3 Standard-Infrequent Access(S3 Standard-IA)로, 360일 후에 S3 Glacier Flexible Retrieval로, 5년 후에 S3 Glacier Deep Archive로 전환합니다.

C. 180일 후에 객체를 S3 Standard-Infrequent Access(S3 Standard-IA)로, 360일 후에 S3 Glacier Instant Retrieval로, 5년 후에 S3 Glacier Deep Archive로 전환합니다.

초기 180일(쉽게 접근 가능해야 함)
- S3 Standard-IA는 데이터에 덜 자주 액세스하면서도 짧은 지연 시간과 높은 가용성을 제공합니다.

360일 후(요청 시 즉시 사용 가능해야 함)
- S3 Glacier Instant Retrieval은 “요청 시 즉시 접근"이라는 조건을 충족하는 가장 적합한 스토리지 클래스입니다.
- Amazon S3 Glacier Instant Retrieval은 Amazon S3 Glacier 스토리지 클래스의 한 유형으로, 데이터를 밀리초 미만의 지연 시간으로 즉시 액세스할 수 있는 가장 빠른 데이터 검색 옵션을 제공합니다. 이는 자주 접근하지 않지만 즉각적인 액세스가 필요한 데이터에 적합하며, 긴 보존 기간이 필요한 워크로드에 비용 효율적인 솔루션을 제공합니다.
- D 옵션의 S3 Glacier Flexible Retrieval은 몇 분에서 몇 시간까지 검색 시간이 걸릴 수 있어 조건에 부합하지 않습니다.

5년 후(12시간 이내 검색 가능)
- S3 Glacier Deep Archive는 장기 보관을 위한 가장 저렴한 스토리지 옵션입니다.
- Amazon S3 Glacier Deep Archive는 Amazon S3의 스토리지 클래스 중 가장 저렴한 옵션으로, 장기 데이터 보관에 최적화된 스토리지입니다. 이 클래스는 자주 액세스되지 않는 데이터를 최소 7~10년 또는 그 이상 보존해야 하는 워크로드에 적합하며, 초저가의 스토리지 비용을 제공합니다. (데이터 검색 시간은 12시간에서 최대 48시간까지 걸릴 수 있음)
- 검색 시간이 최대 12시간이지만 감사 요구 사항을 충족합니다.

---

■ Question #652

어떤 회사에는 매일 6시간씩 실행되는 대규모 데이터 워크로드가 있습니다. 이 회사는 프로세스가 실행되는 동안 데이터를 잃을 수 없습니다. 솔루션 아키텍트는 이 중요한 데이터 워크로드를 지원하기 위해 Amazon EMR 클러스터 구성을 설계하고 있습니다.

어떤 솔루션이 이러한 요구 사항을 가장 비용 효율적으로 충족할까요?

A. 온디맨드 인스턴스에서 기본 노드와 핵심 노드를 실행하고 스팟 인스턴스에서 작업 노드를 실행하는 장기 실행 클러스터를 구성합니다.
B. 온디맨드 인스턴스에서 기본 노드와 핵심 노드를 실행하고 스팟 인스턴스에서 작업 노드를 실행하는 일시적 클러스터를 구성합니다.
C. 온디맨드 인스턴스에서 기본 노드를 실행하고 스팟 인스턴스에서 핵심 노드와 작업 노드를 실행하는 일시적 클러스터를 구성합니다.
D. 온디맨드 인스턴스에서 기본 노드를 실행하고 스팟 인스턴스에서 핵심 노드를 실행하고 스팟 인스턴스에서 작업 노드를 실행하는 장기 실행 클러스터를 구성합니다.

B. 온디맨드 인스턴스에서 기본 노드와 핵심 노드를 실행하고 스팟 인스턴스에서 작업 노드를 실행하는 일시적 클러스터를 구성합니다.

온디맨드 인스턴스를 기본 및 핵심 노드에, 스팟 인스턴스를 작업 노드에 사용하며, 일시적 클러스터를 통해 비용을 절약하면서도 데이터 손실 방지와 성능 요구를 충족합니다.

온디맨드 인스턴스를 기본 노드와 핵심 노드에 사용
- 기본 노드는 클러스터를 관리하고 Hadoop 분산 파일 시스템(HDFS) 메타데이터를 유지합니다. 데이터 손실을 방지하기 위해 항상 안정적이고 중단되지 않는 온디맨드 인스턴스에서 실행해야 합니다.
- 핵심 노드는 HDFS에 데이터를 저장하고 작업을 실행합니다. 핵심 노드도 안정적인 온디맨드 인스턴스에서 실행해야 데이터 손실을 방지할 수 있습니다.

스팟 인스턴스를 작업 노드에 사용
- 작업 노드는 데이터를 저장하지 않으며 작업만 처리합니다. 스팟 인스턴스를 사용하여 비용을 절감할 수 있으며, 중단되더라도 데이터 손실은 발생하지 않습니다.

일시적 클러스터
- 이 데이터 워크로드는 매일 6시간씩 실행됩니다. 워크로드가 일정 시간 동안만 실행되므로 일시적 클러스터를 사용하는 것이 비용 효율적입니다.
- 워크로드가 끝나면 클러스터를 종료하여 리소스를 절약할 수 있습니다.

---

■ Question #653

한 회사가 사용자를 비용 센터에 매핑하는 Amazon RDS 데이터베이스를 유지 관리합니다. 이 회사는 AWS Organizations의 조직에 계정을 가지고 있습니다. 이 회사는 조직의 특정 AWS 계정에서 생성된 모든 리소스에 태그를 지정하는 솔루션이 필요합니다. 이 솔루션은 리소스를 만든 사용자의 비용 센터 ID로 각 리소스에 태그를 지정해야 합니다.

어떤 솔루션이 이러한 요구 사항을 충족할까요?

A. 특정 AWS 계정을 관리 계정에서 Organizations의 새 조직 단위(OU)로 이동합니다. 리소스를 만들기 전에 모든 기존 리소스에 올바른 비용 센터 태그가 지정되어야 하는 서비스 제어 정책(SCP)을 만듭니다. SCP를 새 OU에 적용합니다.
B. Lambda 함수가 RDS 데이터베이스에서 적절한 비용 센터를 조회한 후 리소스에 태그를 지정하는 AWS Lambda 함수를 만듭니다. Lambda 함수를 호출하기 위해 AWS CloudTrail 이벤트에 반응하는 Amazon EventBridge 규칙을 구성합니다.
C. AWS Lambda 함수를 배포하기 위해 AWS CloudFormation 스택을 만듭니다. Lambda 함수가 RDS 데이터베이스에서 적절한 비용 센터를 조회하고 리소스에 태그를 지정하도록 구성합니다. CloudFormation 스택을 호출하기 위한 Amazon EventBridge 예약 규칙을 만듭니다.
D. 리소스에 기본값을 태그 지정하는 AWS Lambda 함수를 만듭니다. 리소스에 비용 센터 태그가 없는 경우 Lambda 함수를 호출하도록 AWS CloudTrail 이벤트에 반응하는 Amazon EventBridge 규칙을 구성합니다.

B. Lambda 함수가 RDS 데이터베이스에서 적절한 비용 센터를 조회한 후 리소스에 태그를 지정하는 AWS Lambda 함수를 만듭니다. Lambda 함수를 호출하기 위해 AWS CloudTrail 이벤트에 반응하는 Amazon EventBridge 규칙을 구성합니다.

EventBridge와 Lambda를 사용한 자동 태깅
- EventBridge 규칙을 사용하여 리소스 생성 이벤트(AWS CloudTrail에서 기록된 API 호출)를 모니터링합니다.
- 생성된 이벤트는 AWS Lambda 함수로 전달됩니다.
- Lambda 함수는 RDS 데이터베이스에서 적절한 비용 센터를 조회하고, 생성된 리소스에 태그를 적용합니다.

동적 비용 센터 조회
- 비용 센터 ID는 RDS 데이터베이스에서 사용자 기반으로 동적으로 조회됩니다. 이는 각 리소스에 정확한 태그를 적용할 수 있도록 보장합니다.

자동화 및 운영 오버헤드 최소화
- EventBridge와 Lambda의 조합으로 리소스 생성 시 태그를 자동으로 적용하므로 관리 작업을 줄일 수 있습니다.

---

■ Question #654

한 회사가 최근 웹 애플리케이션을 AWS 클라우드로 마이그레이션했습니다. 이 회사는 Amazon EC2 인스턴스를 사용하여 여러 프로세스를 실행하여 애플리케이션을 호스팅합니다. 프로세스에는 정적 콘텐츠를 제공하는 Apache 웹 서버가 포함됩니다. Apache 웹 서버는 사용자 세션을 위해 로컬 Redis 서버를 사용하는 PHP 애플리케이션에 요청을 합니다. 이 회사는 아키텍처를 고가용성으로 재설계하고 AWS 관리 솔루션을 사용하려고 합니다.

이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

A. AWS Elastic Beanstalk를 사용하여 정적 콘텐츠와 PHP 애플리케이션을 호스팅합니다. Elastic Beanstalk를 구성하여 EC2 인스턴스를 퍼블릭 서브넷에 배포합니다. 퍼블릭 IP 주소를 할당합니다.
B. AWS Lambda를 사용하여 정적 콘텐츠와 PHP 애플리케이션을 호스팅합니다. Amazon API Gateway REST API를 사용하여 요청을 Lambda 함수로 프록시합니다. API Gateway CORS 구성을 설정하여 도메인 이름에 응답합니다. Amazon ElastiCache for Redis를 구성하여 세션 정보를 처리합니다.
C. EC2 인스턴스에 백엔드 코드를 유지합니다. Multi-AZ가 활성화된 Amazon ElastiCache for Redis 클러스터를 만듭니다. 클러스터 모드에서 Redis 클러스터용 ElastiCache를 구성합니다. 프런트엔드 리소스를 Amazon S3에 복사합니다. EC2 인스턴스를 참조하도록 백엔드 코드를 구성합니다.
D. 정적 콘텐츠를 호스팅하도록 구성된 S3 버킷에 Amazon S3 엔드포인트가 있는 Amazon CloudFront 배포를 구성합니다. PHP 애플리케이션에 대한 AWS Fargate 작업을 실행하는 Amazon Elastic Container Service(Amazon ECS) 서비스를 대상으로 하는 Application Load Balancer를 구성합니다. 여러 가용 영역에서 실행되는 Redis 클러스터용 Amazon ElastiCache를 사용하도록 PHP 애플리케이션을 구성합니다.

D. 정적 콘텐츠를 호스팅하도록 구성된 S3 버킷에 Amazon S3 엔드포인트가 있는 Amazon CloudFront 배포를 구성합니다. PHP 애플리케이션에 대한 AWS Fargate 작업을 실행하는 Amazon Elastic Container Service(Amazon ECS) 서비스를 대상으로 하는 Application Load Balancer를 구성합니다. 여러 가용 영역에서 실행되는 Redis 클러스터용 Amazon ElastiCache를 사용하도록 PHP 애플리케이션을 구성합니다.

정적 콘텐츠에 대한 고가용성과 확장성 제공
- Amazon S3: 정적 콘텐츠는 S3 버킷에 저장됩니다. 이는 고가용성과 높은 내구성을 제공합니다.
- Amazon CloudFront: S3의 콘텐츠를 글로벌 사용자에게 낮은 지연 시간으로 제공하며, 캐싱을 통해 성능을 최적화합니다.

PHP 애플리케이션에 대한 컨테이너 기반 관리형 서비스
- Amazon ECS with AWS Fargate: PHP 애플리케이션을 Fargate로 실행하면 서버를 관리하지 않고도 컨테이너 기반 워크로드를 실행할 수 있습니다. 이는 고가용성과 확장성을 제공합니다.
- Amazon ECS with AWS Fargate는 AWS에서 제공하는 서버리스 컨테이너 오케스트레이션 서비스인 Amazon Elastic Container Service (ECS)와 AWS Fargate를 결합한 솔루션입니다. 이를 통해 컨테이너 기반 애플리케이션을 실행하는 데 필요한 서버 또는 클러스터 관리를 제거하고, 완전 관리형 서버리스 컨테이너 서비스를 제공합니다.

Redis 세션 관리
- Amazon ElastiCache for Redis: 관리형 Redis 클러스터를 사용하여 세션 정보를 처리합니다. 멀티 AZ 구성을 통해 고가용성을 확보합니다.

로드 밸런싱
- Application Load Balancer (ALB): ALB를 통해 PHP 애플리케이션으로 요청을 분산시켜 고가용성을 보장합니다.

---

■ Question #655

한 회사가 대상 그룹이 있는 자동 확장 그룹의 Amazon EC2 인스턴스에서 웹 애플리케이션을 실행합니다. 이 회사는 더 나은 사용자 경험을 위해 세션 선호도(스티키 세션)와 함께 작동하도록 애플리케이션을 설계했습니다. 애플리케이션은 엔드포인트로서 인터넷을 통해 공개적으로 사용할 수 있어야 합니다. 추가 보안을 위해 WAF를 엔드포인트에 적용해야 합니다. 세션 선호도(스티키 세션)를 엔드포인트에서 구성해야 합니다.

이러한 요구 사항을 충족하는 단계 조합은 무엇입니까? (두 가지 선택)

A. 공용 네트워크 부하 분산 장치를 만듭니다. 애플리케이션 대상 그룹을 지정합니다.
B. 게이트웨이 부하 분산 장치를 만듭니다. 애플리케이션 대상 그룹을 지정합니다.
C. 공용 애플리케이션 부하 분산 장치를 만듭니다. 애플리케이션 대상 그룹을 지정합니다.
D. 두 번째 대상 그룹을 만듭니다. EC2 인스턴스에 탄력적 IP 주소를 추가합니다.
E. AWS WAF에서 웹 ACL을 만듭니다. 웹 ACL을 엔드포인트와 연결합니다.

C. 공용 애플리케이션 부하 분산 장치를 만듭니다. 애플리케이션 대상 그룹을 지정합니다.
- 애플리케이션 부하 분산 장치는 세션 선호도(스티키 세션)를 지원합니다.
- HTTP(S) 트래픽을 처리하며, 대상 그룹을 사용하여 요청을 Amazon EC2 인스턴스로 라우팅할 수 있습니다.
- ALB는 인터넷을 통해 공개 엔드포인트로 사용할 수 있습니다.

E. AWS WAF에서 웹 ACL을 만듭니다. 웹 ACL을 엔드포인트와 연결합니다.
- AWS WAF를 사용하면 웹 애플리케이션에 대한 추가 보안 계층을 추가할 수 있습니다.
- WAF 웹 ACL을 ALB에 연결하여 DDoS 공격, SQL 주입 등의 일반적인 웹 공격으로부터 보호할 수 있습니다.

---

■ Question #656

한 회사가 역사적 사건의 이미지를 저장하는 웹사이트를 운영합니다. 웹사이트 사용자는 이미지의 이벤트가 발생한 연도를 기준으로 이미지를 검색하고 볼 수 있는 기능이 필요합니다. 평균적으로 사용자는 각 이미지를 1년에 한두 번만 요청합니다. 이 회사는 이미지를 저장하고 사용자에게 제공할 수 있는 고가용성 솔루션을 원합니다.

이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?

A. Amazon Elastic Block Store(Amazon EBS)에 이미지를 저장합니다. Amazon EC2에서 실행되는 웹 서버를 사용합니다.
B. Amazon Elastic File System(Amazon EFS)에 이미지를 저장합니다. Amazon EC2에서 실행되는 웹 서버를 사용합니다.
C. Amazon S3 Standard에 이미지를 저장합니다. S3 Standard를 사용하여 정적 웹사이트를 사용하여 이미지를 직접 제공합니다.
D. Amazon S3 Standard-Infrequent Access(S3 Standard-IA)에 이미지를 저장합니다. S3 Standard-IA를 사용하여 정적 웹사이트를 사용하여 이미지를 직접 제공합니다.

D. Amazon S3 Standard-Infrequent Access(S3 Standard-IA)에 이미지를 저장합니다. S3 Standard-IA를 사용하여 정적 웹사이트를 사용하여 이미지를 직접 제공합니다.

저장 및 비용 효율성
- S3 Standard-IA는 자주 액세스하지 않는 데이터에 대해 최적화된 비용 효율적인 스토리지입니다.
- 이 솔루션은 낮은 요청 빈도(1년에 한두 번)와 높은 내구성 및 가용성을 요구하는 데이터를 저장하기에 적합합니다.
- 사용자는 이미지에 대한 요청 빈도가 낮기 때문에 S3 Standard-IA가 최적의 스토리지 클래스입니다.

정적 웹사이트 호스팅
- Amazon S3는 정적 웹사이트 호스팅을 지원하므로 추가 인프라 없이도 이미지 파일을 직접 제공할 수 있습니다.
- 이는 EC2 인스턴스나 웹 서버 관리의 필요성을 제거하여 운영 오버헤드를 줄입니다.

고가용성 및 내구성
- Amazon S3는 99.99% 가용성과 99.999999999% 내구성을 제공합니다.
- 데이터 손실을 방지하고 전 세계 사용자에게 안정적으로 이미지를 제공할 수 있습니다.

---

■ Question #657

한 회사에는 AWS Organizations의 조직에 여러 AWS 계정이 있으며, 이를 여러 사업부에서 사용합니다. 이 회사는 전 세계에 여러 사무실이 있습니다. 이 회사는 보안 그룹 규칙을 업데이트하여 새로운 사무실 CIDR 범위를 허용하거나 조직 전체에서 이전 CIDR 범위를 제거해야 합니다. 이 회사는 CIDR 범위 업데이트에 필요한 관리 오버헤드를 최소화하기 위해 보안 그룹 규칙의 관리를 중앙화하려고 합니다.

이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?

A. 조직의 관리 계정에 VPC 보안 그룹을 만듭니다. CIDR 범위 업데이트가 필요할 때 보안 그룹을 업데이트합니다.
B. CIDR 목록이 포함된 VPC 고객 관리 접두사 목록을 만듭니다. AWS Resource Access Manager(AWS RAM)를 사용하여 조직 전체에서 접두사 목록을 공유합니다. 조직 전체의 보안 그룹에서 접두사 목록을 사용합니다.
C. AWS 관리 접두사 목록을 만듭니다. AWS Security Hub 정책을 사용하여 조직 전체에서 보안 그룹 업데이트를 시행합니다. AWS Lambda 함수를 사용하여 CIDR 범위가 변경될 때 접두사 목록을 자동으로 업데이트합니다.
D. 중앙 관리 AWS 계정에 보안 그룹을 만듭니다. 조직 전체에 대한 AWS Firewall Manager 공통 보안 그룹 정책을 만듭니다. 정책에서 이전에 만든 보안 그룹을 기본 그룹으로 선택합니다.

B. CIDR 목록이 포함된 VPC 고객 관리 접두사 목록을 만듭니다. AWS Resource Access Manager(AWS RAM)를 사용하여 조직 전체에서 접두사 목록을 공유합니다. 조직 전체의 보안 그룹에서 접두사 목록을 사용합니다.

접두사 목록을 사용한 중앙화된 관리
- VPC 고객 관리 접두사 목록은 보안 그룹에서 IP CIDR 범위를 정의하고 참조하는 중앙화된 방법을 제공합니다.
- CIDR 범위를 업데이트하려면 접두사 목록만 수정하면 됩니다. 이로 인해 보안 그룹 규칙을 개별적으로 업데이트할 필요가 없어 관리 오버헤드가 크게 줄어듭니다.

AWS Resource Access Manager(AWS RAM)
- AWS Resource Access Manager (AWS RAM)는 AWS 계정, AWS Organizations, 또는 특정 리소스와의 리소스 공유를 간소화하기 위한 서비스입니다. AWS RAM을 사용하면 여러 계정 간에 지원되는 AWS 리소스를 안전하게 공유할 수 있으며, 이를 통해 리소스 중복을 줄이고 관리 효율성을 높일 수 있습니다.
- AWS RAM을 사용하면 접두사 목록을 조직 전체의 여러 계정에서 공유할 수 있습니다.
- 조직 내 모든 계정에서 동일한 접두사 목록을 참조하여 보안 그룹을 설정할 수 있으므로 중앙화된 관리를 실현할 수 있습니다.

비용 효율성
- 접두사 목록과 AWS RAM은 별도의 비용 없이 AWS 서비스의 기본 기능으로 제공됩니다.
- 보안 그룹을 조직 전체에서 일관되게 관리하고 업데이트할 수 있어 추가 리소스를 생성하거나 복잡한 작업을 수행할 필요가 없습니다.

---

■ Question #658

한 회사에서 온프레미스 네트워크 연결 스토리지(NAS) 시스템을 사용하여 고성능 컴퓨팅(HPC) 워크로드에 파일 공유를 제공합니다. 이 회사는 지연에 민감한 HPC 워크로드와 스토리지를 AWS 클라우드로 마이그레이션하려고 합니다. 이 회사는 파일 시스템에서 NFS 및 SMB 다중 프로토콜 액세스를 제공할 수 있어야 합니다.

어떤 솔루션이 가장 짧은 지연 시간으로 이러한 요구 사항을 충족할까요? (두 가지 선택)

A. 컴퓨팅 최적화 EC2 인스턴스를 클러스터 배치 그룹에 배포합니다.
B. 컴퓨팅 최적화 EC2 인스턴스를 파티션 배치 그룹에 배포합니다.
C. EC2 인스턴스를 Amazon FSx for Lustre 파일 시스템에 연결합니다.
D. EC2 인스턴스를 Amazon FSx for OpenZFS 파일 시스템에 연결합니다.
E. EC2 인스턴스를 Amazon FSx for NetApp ONTAP 파일 시스템에 연결합니다.

A. 컴퓨팅 최적화 EC2 인스턴스를 클러스터 배치 그룹에 배포합니다.
- 컴퓨팅 최적화 EC2 인스턴스는 HPC 워크로드를 처리하기 위해 설계된 인스턴스 유형입니다. 낮은 지연 시간과 높은 처리량을 제공합니다.
- 클러스터 배치 그룹은 네트워크 성능을 극대화하고 HPC 워크로드에서 필수적인 노드 간 빠른 통신을 제공합니다.

E. EC2 인스턴스를 Amazon FSx for NetApp ONTAP 파일 시스템에 연결합니다.
- Amazon FSx for NetApp ONTAP은 AWS에서 제공하는 완전 관리형 파일 스토리지 서비스로, NetApp의 ONTAP 데이터 관리 소프트웨어를 기반으로 구축되었습니다. 이를 통해 기업은 NetApp의 고급 데이터 관리 기능과 AWS의 확장성, 내구성, 유연성을 결합하여 기존 온프레미스 워크로드를 클라우드로 손쉽게 마이그레이션할 수 있습니다.
- Amazon FSx for NetApp ONTAP은 NFS 및 SMB 다중 프로토콜 액세스를 제공하며, 지연에 민감한 애플리케이션과 고성능 스토리지 요구 사항을 충족합니다.
- FSx for NetApp ONTAP은 HPC 워크로드의 스토리지 성능과 확장성을 보장하며 온프레미스 NAS와 유사한 관리 및 데이터 보호 기능을 제공합니다.

---

■ Question #659

한 회사가 데이터 센터를 이전하고 2주 안에 50TB의 데이터를 AWS로 안전하게 전송하려고 합니다. 기존 데이터 센터에는 AWS에 대한 Site-to-Site VPN 연결이 있으며 90%가 활용됩니다. 솔루션 아키텍트는 이러한 요구 사항을 충족하기 위해 어떤 AWS 서비스를 사용해야 합니까?

A. VPC 엔드포인트가 있는 AWS DataSync
B. AWS 직접 연결
C .AWS Snowball Edge 스토리지 최적화
D .AWS 스토리지 게이트웨이

C. AWS Snowball Edge 스토리지 최적화

데이터 전송 요구 사항 (50TB)와 시간 제한 (2주)
- 50TB의 데이터를 2주 안에 전송하려면 고속 데이터 전송 솔루션이 필요합니다.
- AWS Snowball Edge 스토리지 최적화는 대량의 데이터를 빠르고 안전하게 전송하기 위해 설계된 물리적 디바이스를 제공합니다.
- 네트워크 대역폭의 제약 (90% 사용 중인 VPN)으로 인해 인터넷 기반 전송은 비효율적일 수 있습니다. Snowball Edge는 네트워크 대역폭에 의존하지 않으므로 적합합니다.

보안 및 안정성
- Snowball Edge는 데이터를 암호화하여 물리적으로 AWS로 전송하기 때문에 데이터 손실이나 보안 위협을 방지합니다.
- 물리적 디바이스를 사용하므로 네트워크 부하를 증가시키지 않습니다.

---

■ Question #660

한 회사가 Auto Scaling 그룹의 Amazon EC2 On-Demand Instances에서 애플리케이션을 호스팅합니다. 애플리케이션 피크 시간은 매일 같은 시간에 발생합니다. 애플리케이션 사용자는 피크 시간 시작 시 애플리케이션 성능이 느리다고 보고합니다. 애플리케이션은 피크 시간이 시작된 후 2~3시간 후에 정상적으로 실행됩니다. 이 회사는 피크 시간 시작 시 애플리케이션이 제대로 작동하는지 확인하고자 합니다.

어떤 솔루션이 이러한 요구 사항을 충족할까요?

A. 트래픽을 인스턴스에 적절하게 분산시키기 위해 애플리케이션 로드 밸런서를 구성합니다.
B. 메모리 활용도에 따라 새 인스턴스를 시작하기 위해 자동 크기 조정 그룹에 대한 동적 크기 조정 정책을 구성합니다.
C. CPU 사용률에 따라 새 인스턴스를 시작하도록 자동 크기 조정 그룹에 대한 동적 크기 조정 정책을 구성합니다.
D. 자동 크기 조정 그룹이 피크 시간 전에 새 인스턴스를 시작할 수 있도록 예약된 크기 조정 정책을 구성합니다.

문제 분석
- 피크 시간 시작 시 애플리케이션 성능이 느려지는 문제는 새로운 인스턴스가 준비되는 데 필요한 시간과 관련이 있습니다.
- 애플리케이션이 피크 시간에 정상적으로 작동하려면, 피크 시간 전에 인스턴스가 준비되고 가동 상태여야 합니다.

D.자동 크기 조정 그룹이 피크 시간 전에 새 인스턴스를 시작할 수 있도록 예약된 크기 조정 정책을 구성합니다.
- 예약된 크기 조정 정책은 예상된 피크 시간에 따라 미리 인스턴스를 프로비저닝합니다.
- 애플리케이션의 피크 시간이 매일 같은 시간에 발생하므로, 이 정책을 사용하면 필요한 인스턴스를 피크 시간 전에 가동 상태로 준비할 수 있습니다.
- 이는 성능 문제를 해결하고 사용자가 성능 저하를 경험하지 않도록 보장합니다.