AWS SAA-C03 Examtopics (801 ~ 820)

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

 

■ Question #801

금융 회사는 매우 민감한 데이터를 처리해야 합니다. 회사는 Amazon S3 버킷에 데이터를 저장합니다. 회사는 데이터가 전송 중 및 저장 중에 암호화되도록 해야 합니다. 회사는 AWS 클라우드 외부에서 암호화 키를 관리해야 합니다.

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

A. AWS Key Management Service(AWS KMS) 고객 관리 키를 사용하는 서버 측 암호화(SSE)로 S3 버킷의 데이터를 암호화합니다.

B. AWS Key Management Service(AWS KMS) AWS 관리 키를 사용하는 서버 측 암호화(SSE)로 S3 버킷의 데이터를 암호화합니다.

C. 기본 서버 측 암호화(SSE)를 사용하여 S3 버킷의 데이터를 암호화합니다.

D. S3 버킷에 데이터를 저장하기 전에 회사 데이터 센터에서 데이터를 암호화합니다.

D. S3 버킷에 데이터를 저장하기 전에 회사 데이터 센터에서 데이터를 암호화합니다.
- 외부에서 암호화 키를 관리해야 한다는 요구 사항을 고려하면, AWS KMS를 통한 서버 측 암호화는 적합하지 않습니다. 이는 KMS 키가 AWS 클라우드 내에서 관리되기 때문입니다.
- 데이터를 S3 버킷에 업로드하기 전에 회사 데이터 센터에서 직접 암호화하면, 암호화 키를 완전히 회사의 통제 하에 두고 데이터를 보호할 수 있습니다. 이 방법은 클라이언트 측 암호화로, 데이터를 업로드하기 전에 암호화된 상태로 만들어 AWS에 저장하므로, AWS에 의존하지 않고 데이터의 기밀성을 유지할 수 있습니다.
- 회사가 직접 암호화하고 관리하는 키를 사용하여 데이터를 보호하기 때문에 AWS 클라우드 외부에서 암호화 키를 관리할 수 있습니다.

---

■ Question #802

한 회사가 AWS에서 결제 애플리케이션을 실행하려고 합니다. 이 애플리케이션은 모바일 기기에서 결제 알림을 수신합니다. 결제 알림은 추가 처리를 위해 전송되기 전에 기본 검증이 필요합니다. 백엔드 처리 애플리케이션은 장기 실행되며 컴퓨팅 및 메모리를 조정해야 합니다. 이 회사는 인프라를 관리하고 싶어하지 않습니다.

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

A. Amazon Simple Queue Service(Amazon SQS) 대기열을 만듭니다. 모바일 기기에서 결제 알림을 수신하기 위해 대기열을 Amazon EventBridge 규칙과 통합합니다. 결제 알림을 검증하고 알림을 백엔드 애플리케이션으로 보내도록 규칙을 구성합니다. Amazon Elastic Kubernetes Service (Amazon EKS) Anywhere에 백엔드 애플리케이션을 배포합니다. 독립형 클러스터를 만듭니다.

B. Amazon API Gateway API를 만듭니다. API를 AWS Step Functions 상태 머신과 통합하여 모바일 기기에서 결제 알림을 수신합니다. 상태 머신을 호출하여 결제 알림을 검증하고 알림을 백엔드 애플리케이션으로 보냅니다. Amazon Elastic Kubernetes Service (Amazon EKS)에 백엔드 애플리케이션을 배포합니다. 자체 관리 노드가 있는 EKS 클러스터를 구성합니다.

C. Amazon Simple Queue Service(Amazon SQS) 대기열을 만듭니다. 모바일 기기에서 결제 알림을 수신하기 위해 대기열을 Amazon EventBridge 규칙과 통합합니다. 결제 알림을 검증하고 백엔드 애플리케이션으로 알림을 보내도록 규칙을 구성합니다. Amazon EC2 Spot Instances에 백엔드 애플리케이션을 배포합니다. 기본 할당 전략으로 Spot Fleet을 구성합니다.

D. Amazon API Gateway API를 만듭니다. API를 AWS Lambda와 통합하여 모바일 기기에서 결제 알림을 받습니다. Lambda 함수를 호출하여 결제 알림을 검증하고 알림을 백엔드 애플리케이션으로 보냅니다. Amazon Elastic Container Service (Amazon ECS)에 백엔드 애플리케이션을 배포합니다. AWS Fargate 시작 유형으로 Amazon ECS를 구성합니다.

D. Amazon API Gateway API를 만듭니다. API를 AWS Lambda와 통합하여 모바일 기기에서 결제 알림을 받습니다. Lambda 함수를 호출하여 결제 알림을 검증하고 알림을 백엔드 애플리케이션으로 보냅니다. Amazon Elastic Container Service (Amazon ECS)에 백엔드 애플리케이션을 배포합니다. AWS Fargate 시작 유형으로 Amazon ECS를 구성합니다.
- API Gateway는 모바일 기기에서의 결제 알림 수신을 위한 강력한 인터페이스를 제공합니다. API Gateway는 RESTful API를 통해 데이터 수신을 쉽게 관리할 수 있으며, 요청을 Lambda로 라우팅하여 서버리스 아키텍처를 구현할 수 있습니다.
- AWS Lambda는 서버리스 방식으로 기본적인 검증 로직을 손쉽게 구현할 수 있습니다. Lambda는 관리가 필요 없고, 이벤트 기반으로 유연하게 확장됩니다.
- AWS Fargate는 컨테이너를 직접 관리할 필요 없이 애플리케이션을 배포하고 실행할 수 있는 서버리스 컨테이너 실행 서비스입니다. AWS Fargate는 Amazon Elastic Container Service (ECS)와 Amazon Elastic Kubernetes Service (EKS)에서 모두 사용할 수 있으며, 사용자 대신 서버 인프라를 관리하여 컨테이너화된 애플리케이션을 더 쉽게 실행할 수 있습니다.
- Amazon ECS와 AWS Fargate는 백엔드 애플리케이션을 실행하는 데 필요한 컴퓨팅과 메모리 자원을 자동으로 관리할 수 있는 서버리스 컨테이너 관리 솔루션입니다. ECS와 Fargate를 사용하면 클러스터를 직접 관리하지 않고도, 필요에 따라 자원을 동적으로 조정할 수 있습니다.
- Fargate는 AWS에서 완전히 관리되므로, 인프라의 관리 부담이 줄어들고 운영 오버헤드가 최소화됩니다.

---

■ Question #803

솔루션 아키텍트가 회사를 위한 사용자 인증 솔루션을 설계하고 있습니다. 이 솔루션은 일관되지 않은 지리적 위치, IP 주소 또는 장치에서 로그인하는 사용자에 대해 2단계 인증을 호출해야 합니다. 이 솔루션은 또한 수백만 명의 사용자를 수용할 수 있도록 확장할 수 있어야 합니다.

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

A. 사용자 인증을 위해 Amazon Cognito 사용자 풀을 구성합니다. 다중 요소 인증(MFA)으로 위험 기반 적응 인증 기능을 활성화합니다.

B. 사용자 인증을 위해 Amazon Cognito ID 풀을 구성합니다. 다중 요소 인증(MFA)을 활성화합니다.

C. 사용자 인증을 위해 AWS Identity and Access Management(IAM) 사용자를 구성합니다. AllowManageOwnUserMFA 작업을 허용하는 IAM 정책을 연결합니다.

D. 사용자 인증을 위해 AWS IAM Identity Center(AWS Single Sign-On) 인증을 구성합니다. 다중 요소 인증(MFA)을 요구하도록 권한 집합을 구성합니다.

요구사항 분석
- 2단계 인증(MFA)을 적용해야 함
- 일관되지 않은 지리적 위치, IP 주소, 장치에 따라 동적 인증을 호출해야 함
- 수백만 명의 사용자를 확장할 수 있는 솔루션이어야 함

A. 사용자 인증을 위해 Amazon Cognito 사용자 풀을 구성합니다. 다중 요소 인증(MFA)으로 위험 기반 적응 인증 기능을 활성화합니다.
- Amazon Cognito는 AWS에서 제공하는 사용자 인증 및 권한 부여를 위한 서비스로, 웹 및 모바일 애플리케이션에서 사용자자인증을 쉽게 관리하고, 사용자 데이터를 안전하게 보호할 수 있도록 설계되었습니다. Cognito는 확장성, 보안, 사용자 정의를 고려한 기능을 제공하며, 애플리케이션의 사용자 인증을 간편하게 처리할 수 있습니다.
- Amazon Cognito는 수백만 명의 사용자를 확장 가능한 방식으로 지원할 수 있습니다.
- 적응형 인증 기능을 통해 사용자의 로그인 위치, IP 주소, 장치 등을 기반으로 위험도를 평가하고, 필요시 MFA를 호출할 수 있습니다.

---

■ Question #804

한 회사에 Amazon S3 데이터 레이크가 있습니다. 이 회사에는 데이터 레이크의 데이터를 변환하여 매일 데이터 웨어하우스에 로드하는 솔루션이 필요합니다. 데이터 웨어하우스에는 대량 병렬 처리(MPP) 기능이 있어야 합니다. 그런 다음 데이터 분석가는 데이터에 SQL 명령을 사용하여 머신 러닝(ML) 모델을 만들고 학습해야 합니다. 이 솔루션은 가능한 한 서버리스 AWS 서비스를 사용해야 합니다.

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

A. 매일 Amazon EMR 작업을 실행하여 데이터를 변환하고 Amazon Redshift에 데이터를 로드합니다. Amazon Redshift ML을 사용하여 ML 모델을 만들고 학습합니다.

B. 매일 Amazon EMR 작업을 실행하여 데이터를 변환하고 Amazon Aurora Serverless에 데이터를 로드합니다. Amazon Aurora ML을 사용하여 ML 모델을 만들고 학습합니다.

C. 매일 AWS Glue 작업을 실행하여 데이터를 변환하고 Amazon Redshift Serverless에 데이터를 로드합니다. Amazon Redshift ML을 사용하여 ML 모델을 만들고 학습합니다.

D. 매일 AWS Glue 작업을 실행하여 데이터를 변환하고 Amazon Athena 테이블에 데이터를 로드합니다. Amazon Athena ML을 사용하여 ML 모델을 만들고 학습합니다.

C. 매일 AWS Glue 작업을 실행하여 데이터를 변환하고 Amazon Redshift Serverless에 데이터를 로드합니다. Amazon Redshift ML을 사용하여 ML 모델을 만들고 학습합니다.
- AWS Glue는 서버리스 데이터 통합 서비스로, 데이터를 변환하는 데 적합하며, ETL(Extract, Transform, Load) 작업을 자동화하고 관리 오버헤드를 줄일 수 있습니다.
- Amazon Redshift Serverless는 대량 병렬 처리(MPP) 기능을 갖춘 서버리스 데이터 웨어하우스로, SQL 기반의 데이터 분석 및 ML 모델 학습에 적합합니다.
- Amazon Redshift ML은 Redshift에서 직접 SQL 명령을 사용하여 ML 모델을 만들고 학습할 수 있도록 지원합니다. 이를 통해 데이터 분석가는 익숙한 SQL 명령을 사용하여 머신 러닝 작업을 수행할 수 있습니다.
- 이 조합은 완전 서버리스 아키텍처로, 확장성과 관리 오버헤드를 줄이면서 요구 사항을 충족합니다.

---

■ Question #805

한 회사가 회사 로컬 데이터 센터의 Kubernetes 환경에서 컨테이너를 실행합니다. 이 회사는 Amazon Elastic Kubernetes Service (Amazon EKS) 및 기타 AWS 관리 서비스를 사용하려고 합니다. 데이터는 회사 데이터 센터에 로컬로 유지되어야 하며 규정 준수를 위해 원격 사이트나 클라우드에 저장할 수 없습니다.

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

A. 회사의 데이터 센터에 AWS 로컬 영역을 배포합니다.
B. 회사 데이터 센터에서 AWS Snowmobile을 사용합니다.
C. 회사 데이터 센터에 AWS Outposts 랙을 설치합니다.
D. 데이터 센터에 AWS Snowball Edge Storage Optimized 노드를 설치합니다.

C. 회사 데이터 센터에 AWS Outposts 랙을 설치합니다.
- AWS Outposts는 온프레미스 데이터 센터에 설치할 수 있는 완전한 AWS 서비스 환경을 제공하여, EKS를 포함한 다양한 AWS 관리 서비스를 로컬에서 사용할 수 있도록 합니다. Outposts 랙은 AWS 클라우드의 확장으로 간주되어 AWS 인프라와 동일한 API와 인터페이스를 제공합니다.
- Outposts를 통해 데이터를 로컬에 저장하면서도, AWS의 관리형 서비스를 활용할 수 있습니다. 이를 통해 회사의 규정 준수를 보장하면서 클라우드의 기능을 데이터 센터에 직접 적용할 수 있습니다.
- Amazon EKS를 Outposts에서 실행하여, 데이터가 로컬 데이터 센터에 유지되면서 Kubernetes를 활용할 수 있습니다.

---

■ Question #806

소셜 미디어 회사에 데이터를 수집하고 처리하는 워크로드가 있습니다. 워크로드는 온프레미스 NFS 스토리지에 데이터를 저장합니다. 데이터 저장소는 회사의 확장되는 비즈니스 요구 사항을 충족할 만큼 빠르게 확장할 수 없습니다. 회사는 현재 데이터 저장소를 AWS로 마이그레이션하려고 합니다.

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

A. AWS Storage Gateway Volume Gateway를 설정합니다. Amazon S3 Lifecycle 정책을 사용하여 데이터를 적절한 스토리지 클래스로 전환합니다.

B. AWS Storage Gateway Amazon S3 File Gateway를 설정합니다. Amazon S3 Lifecycle 정책을 사용하여 데이터를 적절한 스토리지 클래스로 전환합니다.

C. Amazon Elastic File System(Amazon EFS) Standard-Infrequent Access(Standard-IA) 스토리지 클래스를 사용합니다. Infrequent Access 라이프사이클 정책을 활성화합니다.

D. Amazon Elastic File System(Amazon EFS) One Zone-Infrequent Access(One Zone-IA) 스토리지 클래스를 사용합니다. Infrequent Access 라이프사이클 정책을 활성화합니다.

B. AWS Storage Gateway Amazon S3 File Gateway를 설정합니다. Amazon S3 Lifecycle 정책을 사용하여 데이터를 적절한 스토리지 클래스로 전환합니다.
- AWS Storage Gateway S3 File Gateway는 온프레미스 환경에서 NFS 또는 SMB 프로토콜을 통해 AWS S3 스토리지에 데이터를 저장할 수 있는 게이트웨이를 제공합니다. 이 방식은 기존 온프레미스 환경과의 호환성을 유지하면서 확장 가능한 스토리지를 제공하는 데 이상적입니다.
- 데이터를 Amazon S3에 저장하면 S3의 다양한 스토리지 클래스(예: Standard, Standard-IA, Glacier 등)를 사용할 수 있습니다. 이를 통해 데이터의 사용 빈도에 따라 비용 효율적으로 관리할 수 있습니다.
- S3 Lifecycle 정책을 사용하면, 오래된 데이터나 덜 자주 액세스하는 데이터를 자동으로 비용이 더 낮은 스토리지 클래스로 전환할 수 있어 비용 최적화가 가능합니다.

---

■ Question #807

한 회사에서는 마케팅 이벤트 중에 메시지 큐에서 지속적으로 증가하는 수의 메시지를 처리하기 위해 높은 동시성 AWS Lambda 함수를 사용합니다. Lambda 함수는 CPU 집약적 코드를 사용하여 메시지를 처리합니다. 이 회사는 컴퓨팅 비용을 줄이고 고객에게 서비스 지연 시간을 유지하려고 합니다.

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

A. Lambda 함수에 예약된 동시성을 구성합니다. Lambda 함수에 할당된 메모리를 줄입니다.

B. Lambda 함수에 대한 예약된 동시성을 구성합니다. AWS Compute Optimizer 권장 사항에 따라 메모리를 늘립니다.

C. Lambda 함수에 대한 프로비저닝된 동시성을 구성합니다. Lambda 함수에 할당된 메모리를 줄입니다.

D. Lambda 함수에 대한 프로비저닝된 동시성을 구성합니다. AWS Compute Optimizer 권장 사항에 따라 메모리를 늘립니다.

D. Lambda 함수에 대한 프로비저닝된 동시성을 구성합니다. AWS Compute Optimizer 권장 사항에 따라 메모리를 늘립니다.
- 프로비저닝된 동시성을 사용하면 Lambda 함수의 지연 시간을 안정적으로 유지할 수 있습니다. 프로비저닝된 동시성은 지정된 동시성 수준에서 Lambda 함수를 미리 준비하여, 특히 높은 트래픽 상황에서도 첫 번째 호출의 콜드 스타트 문제를 줄일 수 있습니다.
- AWS Compute Optimizer 권장 사항을 따라 메모리를 늘리면, Lambda 함수에 할당된 CPU 성능도 증가합니다. Lambda는 메모리 할당량에 비례하여 CPU 리소스를 할당하므로, 메모리를 늘리면 CPU 성능이 향상되어 CPU 집약적 작업을 더 효율적으로 처리할 수 있습니다.

- CPU 집약적 작업에서 충분한 메모리를 할당하면 작업 처리 시간이 줄어들고, Lambda 함수의 총 실행 비용이 감소할 수 있습니다. 이는 높은 동시성에서도 비용 효율성을 유지하는 데 도움이 됩니다.

---

■ Question #808

한 회사가 Amazon Elastic Container Service(Amazon ECS)에서 워크로드를 실행합니다. ECS 작업 정의에서 사용하는 컨테이너 이미지는 Common Vulnerabilities and Exposures(CVE)에 대해 스캔해야 합니다. 생성된 새 컨테이너 이미지도 스캔해야 합니다.

워크로드에 가장 적은 변경을 가하면서 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

A. Amazon Elastic Container Registry(Amazon ECR)를 개인 이미지 저장소로 사용하여 컨테이너 이미지를 저장합니다. ECR 기본 스캔에 대해 푸시 필터에서 스캔을 지정합니다.

B. 컨테이너 이미지를 Amazon S3 버킷에 저장합니다. Amazon Macie를 사용하여 이미지를 스캔합니다. S3 이벤트 알림을 사용하여 s3:ObjectCreated:Put 이벤트 유형이 있는 모든 이벤트에 대해 Macie 스캔을 시작합니다.
C. 워크로드를 Amazon Elastic Kubernetes Service(Amazon EKS)에 배포합니다. Amazon Elastic Container Registry (Amazon ECR)를 개인 이미지 저장소로 사용합니다. ECR 강화 스캔에 대해 푸시 필터에서 스캔을 지정합니다.

D. 버전 관리가 활성화된 Amazon S3 버킷에 컨테이너 이미지를 저장합니다. s3:ObjectCreated:* 이벤트에 대한 S3 이벤트 알림을 구성하여 AWS Lambda 함수를 호출합니다. Lambda 함수를 구성하여 Amazon Inspector 스캔을 시작합니다.

A. Amazon Elastic Container Registry(Amazon ECR)를 개인 이미지 저장소로 사용하여 컨테이너 이미지를 저장합니다. ECR 기본 스캔에 대해 푸시 필터에서 스캔을 지정합니다.
- Amazon ECR은 Amazon ECS와 자연스럽게 통합되며, 기본 스캔 기능을 통해 컨테이너 이미지에 대해 CVE 스캔을 자동으로 수행할 수 있습니다. ECR의 스캔 기능은 이미지가 푸시될 때 자동으로 스캔을 시작하도록 설정할 수 있어, 추가적인 구성 없이 CVE를 관리할 수 있습니다.
- ECR 스캔은 CVE와 같은 보안 취약점에 대해 이미지를 검사하고, 결과를 손쉽게 확인할 수 있는 기능을 제공합니다.
- 이 접근 방식은 Amazon ECS와 Amazon ECR 간의 통합이 이미 제공되기 때문에, 워크로드에 대한 변경을 최소화하면서 보안 요구 사항을 충족할 수 있습니다.

---

■ Question #809

한 회사가 AWS Batch 작업을 사용하여 하루 종료 판매 프로세스를 실행합니다. 이 회사에는 AWS Batch 작업이 성공하면 타사 보고 애플리케이션을 호출하는 서버리스 솔루션이 필요합니다. 보고 애플리케이션에는 사용자 이름 및 비밀번호 인증을 사용하는 HTTP API 인터페이스가 있습니다.

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

A. 들어오는 AWS Batch 작업 SUCCEEDED 이벤트와 일치하도록 Amazon EventBridge 규칙을 구성합니다. 사용자 이름과 비밀번호를 사용하여 타사 API를 EventBridge API 대상으로 구성합니다. API 대상을 EventBridge 규칙 대상으로 설정합니다.

B. Amazon EventBridge Scheduler를 구성하여 들어오는 AWS Batch 작업 SUCCEEDED 이벤트와 일치시킵니다. 사용자 이름과 비밀번호를 사용하여 타사 API를 호출하도록 AWS Lambda 함수를 구성합니다. Lambda 함수를 EventBridge 규칙 대상으로 설정 합니다.
C. AWS Batch 작업을 구성하여 Amazon API Gateway REST API에 작업 SUCCEEDED 이벤트를 게시합니다. 사용자 이름과 비밀번호를 사용하여 타사 API를 호출하도록 API Gateway REST API에서 HTTP 프록시 통합을 구성합니다.

D. Amazon API Gateway REST API에 작업 SUCCEEDED 이벤트를 게시하도록 AWS Batch 작업을 구성합니다. API Gateway REST API에서 AWS Lambda 함수로 프록시 통합을 구성합니다. 사용자 이름과 비밀번호를 사용하여 타사 API를 호출하도록 Lambda 함수를 구성합니다.

A. 들어오는 AWS Batch 작업 SUCCEEDED 이벤트와 일치하도록 Amazon EventBridge 규칙을 구성합니다. 사용자 이름과 비밀번호를 사용하여 타사 API를 EventBridge API 대상으로 구성합니다. API 대상을 EventBridge 규칙 대상으로 설정합니다.
- 직접 호출: EventBridge의 API 대상 기능을 통해 AWS Batch 작업이 성공하면 타사 API를 직접 호출할 수 있습니다. 이는 중간에 다른 서비스가 필요 없이 직접적으로 호출할 수 있는 가장 간단한 구조를 제공합니다.
- API 대상 설정: EventBridge의 API 대상 설정에서 HTTP 인증을 포함할 수 있으므로, 사용자 이름과 비밀번호를 통해 기본적인 인증 처리를 할 수 있습니다.
- 운영 오버헤드 최소화: Lambda 함수를 사용할 필요가 없기 때문에 구조가 간단하고 운영 오버헤드가 줄어듭니다.
- EventBridge의 기능 제한: EventBridge의 API 대상은 복잡한 요청 처리 로직, 오류 처리, 상태 모니터링 기능에서는 제한적일 수 있습니다. 단순한 API 호출에는 적합하지만, 복잡한 로직이 필요한 경우 제약이 있을 수 있습니다.

A 옵션은 단순한 HTTP 호출과 기본적인 인증이 필요한 상황에서 최적의 선택이 될 수 있습니다. EventBridge의 API 대상 기능을 활용하면 간결하고 효율적인 아키텍처를 구축할 수 있습니다.

B 옵션은 복잡한 인증 또는 비즈니스 로직이 필요한 경우 더 나은 선택이 될 수 있습니다. Lambda를 사용하면 유연하게 요청과 응답을 처리할 수 있으며, 복잡한 로직을 포함할 수 있습니다.

따라서, 단순한 API 호출과 기본 인증이 필요하다면 A 옵션을 고려하고, 추가 로직 처리나 복잡한 에러 관리가 필요하다면 B 옵션이 더 적합할 것입니다.

---

■ Question #810

한 회사가 공급업체로부터 데이터를 수집하고 처리합니다. 공급업체는 공급업체 자체 AWS 계정의 Amazon RDS for MySQL 데이터베이스에 데이터를 저장합니다. 회사의 VPC에는 인터넷 게이트웨이, AWS Direct Connect 연결 또는 AWS Site-to-Site VPN 연결이 없습니다. 회사는 공급업체 데이터베이스에 있는 데이터에 액세스해야 합니다.

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

A. 공급업체에 AWS Hosted Connection Direct Connect Program에 가입하도록 지시합니다. VPC 피어링을 사용하여 회사의 VPC와 공급업체의 VPC를 연결합니다.

B. 회사의 VPC와 공급업체의 VPC 사이에 클라이언트 VPN 연결을 구성합니다. VPC 피어링을 사용하여 회사의 VPC와 공급업체의 VPC를 연결합니다.

C. 공급업체에 네트워크 로드 밸런서(NLB)를 만들도록 지시합니다. NLB를 Amazon RDS for MySQL 데이터베이스 앞에 배치합니다. AWS PrivateLink를 사용하여 회사의 VPC와 공급업체의 VPC를 통합합니다.

D. AWS Transit Gateway를 사용하여 회사의 VPC와 공급업체의 VPC를 통합합니다. VPC 피어링을 사용하여 회사의 VPC와 공급업체의 VPC를 연결합니다.

C. 공급업체에 네트워크 로드 밸런서(NLB)를 만들도록 지시합니다. NLB를 Amazon RDS for MySQL 데이터베이스 앞에 배치합니다. AWS PrivateLink를 사용하여 회사의 VPC와 공급업체의 VPC를 통합 합니다.
- AWS PrivateLink를 사용하면 공급업체의 VPC에 있는 RDS 데이터베이스에 대한 프라이빗 액세스를 제공할 수 있습니다. PrivateLink를 통해, 공급업체의 VPC와 회사의 VPC 간의 통신이 AWS 네트워크 내에서 안전하게 처리됩니다.

- 공급업체가 네트워크 로드 밸런서(NLB)를 만들고 이를 RDS 인스턴스 앞에 배치하면, 회사의 VPC에서 PrivateLink를 통해 안전하게 NLB에 연결할 수 있습니다. 이렇게 하면, 회사의 VPC와 공급업체의 VPC 간의 데이터 전송이 인터넷이나 외부 네트워ㅋ,를 거치지 않게 됩니다.
- 이 솔루션은 VPC 간에 직접적인 네트워크 연결이 없어도 AWS 내부의 프라이빗 경로를 통해 데이터베이스에 안전하게 연결할 수 있는 방법을 제공합니다.

---

■ Question #811

한 회사가 Amazon Managed Grafana를 시각화 도구로 설정하려고 합니다. 이 회사는 Amazon RDS 데이터베이스의 데이터를 하나의 데이터 소스로 시각화하려고 합니다. 이 회사는 인터넷을 통해 데이터를 노출하지 않는 안전한 솔루션이 필요합니다.

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

A. VPC 없이 Amazon Managed Grafana 작업 공간을 만듭니다. RDS 데이터베이스에 대한 퍼블릭 엔드포인트를 만듭니다. 퍼블릭 엔드포인트를 Amazon Managed Grafana의 데이터 소스로 구성합니다.

B. VPC에 Amazon Managed Grafana 작업 공간을 만듭니다. RDS 데이터베이스에 대한 개인 엔드포인트를 만듭니다. Amazon Managed Grafana에서 개인 엔드포인트를 데이터 소스로 구성합니다.

C. VPC 없이 Amazon Managed Grafana 작업 공간 만들기 AWS PrivateLink 엔드포인트를 만들어 Amazon Managed Grafana와 Amazon RDS 간의 연결을 설정합니다. Amazon Managed Grafana에서 Amazon RDS를 데이터 소스로 설정합니다.

D. VPC에 Amazon Managed Grafana 작업 공간을 만듭니다. RDS 데이터베이스에 대한 퍼블릭 엔드포인트를 만듭니다. Amazon Managed Grafana에서 퍼블릭 엔드포인트를 데이터 소스로 구성합니다.

B. VPC에 Amazon Managed Grafana 작업 공간을 만듭니다. RDS 데이터베이스에 대한 개인 엔드포인트를 만듭니다. Amazon Managed Grafana에서 개인 엔드포인트를 데이터 소스로 구성합니다.
- Amazon Managed Grafana를 VPC에 배치하면, Grafana와 RDS 간의 통신이 VPC 내에서만 이루어집니다. 이는 데이터를 인터넷에 노출시키지 않고 안전하게 통신할 수 있는 방법입니다.

- RDS 데이터베이스에 대한 개인 엔드포인트를 구성하면, RDS 인스턴스에 대한 프라이빗 연결이 설정되어, VPC 외부에서는 접근이 불가능하게 됩니다. 이렇게 하면 Grafana와 RDS 데이터베이스 간의 연결이 인터넷을 통하지 않고 VPC 내에서 이루어지므로 보안성이 높아집니다.

- Amazon Managed Grafana 작업 공간에서 개인 엔드포인트를 데이터 소스로 설정하면, 데이터를 안전하게 시각화할 수 있습니다.

---

■ Question #812

한 회사가 Amazon S3에 데이터 레이크를 호스팅합니다. 데이터 레이크는 다양한 데이터 소스에서 Apache Parquet 형식으로 데이터를 수집합니다. 이 회사는 여러 변환 단계를 사용하여 수집된 데이터를 준비합니다. 이 단계에는 이상치 필터링, 표준 날짜 및 시간 값으로 데이터 정규화, 분석을 위한 집계 생성이 포함됩니다. 이 회사는 데이터 분석가가 액세스하는 S3 버킷에 변환된 데이터를 저장해야 합니다. 이 회사는 코드가 필요 없는 데이터 변환을 위한 사전 구축된 솔루션이 필요합니다. 이 솔루션은 데이터 계보 및 데이터 프로파일링을 제공해야 합니다. 이 회사는 회사 전체의 직원과 데이터 변환 단계를 공유해야 합니다.

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

A. AWS Glue Studio 비주얼 캔버스를 구성하여 데이터를 변환합니다. AWS Glue 작업을 사용하여 직원과 변환 단계를 공유합니다.

B. Amazon EMR Serverless를 구성하여 데이터를 변환합니다. EMR Serverless 작업을 사용하여 직원과 변환 단계를 공유합니다.

C. AWS Glue DataBrew를 구성하여 데이터를 변환합니다. DataBrew 레시피를 사용하여 직원과 변환 단계를 공유합니다.

D. 데이터에 대한 Amazon Athena 테이블을 만듭니다. 데이터를 변환하기 위한 Athena SQL 쿼리를 작성합니다. Athena SQL 쿼리를 직원과 공유합니다.

요구사항 분석
- 코드가 필요 없는 데이터 변환을 지원해야 하며,
- 데이터 계보 및 데이터 프로파일링을 제공해야 하고,
- 직원과 데이터 변환 단계를 공유할 수 있는 기능이 필요합니다

C. AWS Glue DataBrew를 구성하여 데이터를 변환합니다. DataBrew 레시피를 사용하여 직원과 변환 단계를 공유합니다.

- AWS Glue DataBrew는 코드가 필요 없는 데이터 변환을 위한 시각적 인터페이스를 제공하여, 사용자가 드래그 앤 드롭 방식으로 데이터를 정리하고 변환할 수 있도록 지원합니다. 이는 비개발자도 쉽게 사용할 수 있는 접근 방식입니다.
- DataBrew는 데이터 프로파일링 기능을 제공하여, 데이터 품질을 모니터링하고 이상치를 탐지하는 등 데이터의 계보 및 특성을 파악할 수 있습니다.
- 변환 작업을 레시피로 정의할 수 있으며, 이 레시피는 재사용 가능하고 다른 사용자와 쉽게 공유할 수 있습니다. 이를 통해, 회사 전체의 직원들이 동일한 데이터 변환 단계를 공유하고 일관성 있게 작업할 수 있습니다.

---

■ Question #813

솔루션 아키텍트는 애플리케이션 로드 밸런서(ALB) 뒤에 있는 개별 대상 그룹에 있는 여러 Amazon EC2 인스턴스에서 웹 애플리케이션을 실행합니다. 사용자는 공개 웹사이트를 통해 애플리케이션에 접근할 수 있습니다. 솔루션 아키텍트는 엔지니어가 웹사이트의 개발 버전을 사용하여 특정 개발 EC2 인스턴스 하나에 액세스하여 애플리케이션의 새로운 기능을 테스트할 수 있도록 허용하려고 합니다. 솔루션 아키텍트는 Amazon Route 53 호스팅 영역을 사용하여 엔지니어에게 개발 인스턴스에 대한 액세스 권한을 제공하려고 합니다. 솔루션은 개발 인스턴스가 교체되더라도 자동으로 개발 인스턴스로 라우팅해야 합니다.

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

A. ALB로 설정된 값을 갖는 개발 웹사이트에 대한 A 레코드를 만듭니다. 개발 인스턴스를 포함하는 대상 그룹에 개발 웹사이트에 대한 요청을 전달하는 ALB에 리스너 규칙을 만듭니다.

B. 공용 IP 주소로 개발 인스턴스를 다시 만듭니다. 개발 인스턴스의 공용 IP 주소로 설정된 값을 갖는 개발 웹사이트에 대한 A 레코드를 만듭니다.

C. ALB로 설정된 값을 갖는 개발 웹사이트에 대한 A 레코드를 만듭니다. ALB에 개발 웹사이트에 대한 요청을 개발 인스턴스의 공용 IP 주소로 리디렉션하는 리스너 규칙을 만듭니다.

D. 모든 인스턴스를 동일한 대상 그룹에 배치합니다. 개발 웹사이트에 대한 A 레코드를 만듭니다. 값을 ALB로 설정합니다. 개발 웹사이트에 대한 요청을 대상 그룹으로 전달하는 ALB에 리스너 규칙을 만듭니다.

A. ALB로 설정된 값을 갖는 개발 웹사이트에 대한 A 레코드를 만듭니다. 개발 인스턴스를 포함하는 대상 그룹에 개발 웹사이트에 대한 요청을 전달하는 ALB에 리스너 규칙을 만듭니다.
- ALB (Application Load Balancer)를 사용하면, 특정 URL 경로나 호스트 헤더에 대한 요청을 특정 대상 그룹으로 라우팅할 수 있습니다. 이를 통해 개발 인스턴스에 대한 엔지니어의 요청을 ALB를 통해 안전하게 관리할 수 있습니다.

- Amazon Route 53 A 레코드를 ALB로 설정하면, Route 53에서 개발 웹사이트의 DNS 요청을 ALB로 전달하게 됩니다.
- ALB의 리스너 규칙을 사용하여, 개발 인스턴스를 포함하는 특정 대상 그룹으로 개발 웹사이트에 대한 요청을 라우팅할 수 있습니다. 이 방법은 개발 인스턴스가 교체되더라도, 대상 그룹의 구성을 변경하면 요청이 자동으로 새로운 개발 인스턴스로 전달됩니다.
- 이 구조는 확장 가능하고 동적이며, 개발 인스턴스를 직접 관리하거나 수동으로 DNS 설정을 변경할 필요가 없습니다.

---

■ Question #814

한 회사가 회사 데이터 센터의 쿠버네티스 클러스터에서 컨테이너 애플리케이션을 실행합니다. 이 애플리케이션은 Advanced Message Queuing Protocol (AMQP)을 사용하여 메시지 큐와 통신합니다. 데이터 센터는 회사의 확장되는 비즈니스 요구 사항을 충족할 만큼 빠르게 확장할 수 없습니다. 이 회사는 워크로드를 AWS로 마이그레이션하려고 합니다.

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

A. 컨테이너 애플리케이션을 Amazon Elastic Container Service(Amazon ECS)로 마이그레이션합니다. Amazon Simple Queue Service (Amazon SQS)를 사용하여 메시지를 검색합니다.

B. 컨테이너 애플리케이션을 Amazon Elastic Kubernetes Service(Amazon EKS)로 마이그레이션합니다. Amazon MQ를 사용하여 메시지를 검색합니다.

C. 고가용성 Amazon EC2 인스턴스를 사용하여 애플리케이션을 실행합니다. Amazon MQ를 사용하여 메시지를 검색합니다.

D. AWS Lambda 함수를 사용하여 애플리케이션을 실행합니다. Amazon Simple Queue Service(Amazon SQS)를 사용하여 메시지를 검색합니다.

B. 컨테이너 애플리케이션을 Amazon Elastic Kubernetes Service(Amazon EKS)로 마이그레이션합니다. Amazon MQ를 사용하여 메시지를 검색합니다.
- AMQP (Advanced Message Queuing Protocol)는 메시지 지향 미들웨어를 위한 오픈 표준 애플리케이션 레이어 프로토콜로, 메시지 지향 애플리케이션 간에 신뢰성 있고 상호 운용 가능한 통신을 제공하기 위해 설계되었습니다. 주로 메시지 브로커와 클라이언트 애플리케이션 간의 메시지 전송에 사용됩니다.
- AMQP 지원: Amazon MQ는 RabbitMQ와 ActiveMQ를 지원하여 AMQP 프로토콜을 네이티브로 지원합니다. 이는 기존 애플리케이션이 AMQP를 사용하는 경우, 애플리케이션 코드를 최소한으로 변경하여 AWS로의 마이그레이션이 가능하다는 의미입니다.
- EKS의 관리형 쿠버네티스 서비스: 기존의 쿠버네티스 클러스터를 관리하던 워크로드를 Amazon EKS로 마이그레이션하면, AWS에서 관리되는 쿠버네티스 클러스터를 사용함으로써 운영 오버헤드를 줄일 수 있습니다.
- 유지 관리 감소: Amazon EKS와 Amazon MQ를 사용하면, AWS에서 클러스터와 메시징 시스템을 관리하므로 운영 오버헤드가 크게 줄어듭니다. 이는 기존 데이터 센터에서의 관리 부담을 크게 덜어줍니다.

---

■ Question #815

온라인 게임 회사가 여러 AWS 리전의 네트워크 로드 밸런서(NLB) 뒤에 있는 Amazon EC2 인스턴스에서 플랫폼을 호스팅합니다. NLB는 인터넷을 통해 대상에 요청을 라우팅할 수 있습니다. 이 회사는 글로벌 고객 기반의 엔드투엔드 로드 시간을 줄여 고객 플레이 경험을 개선하고자 합니다.

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

A. 각 지역에 기존 NLB를 대체하기 위해 애플리케이션 로드 밸런서(ALB)를 만듭니다. 각 지역의 ALB에 대한 대상으로 기존 EC2 인스턴스를 등록합니다.

B. 각 지역의 NLB에 동일한 가중치의 트래픽을 라우팅하도록 Amazon Route 53을 구성합니다.

C. 회사가 대규모 고객 기반을 보유하고 있는 다른 지역에 추가 NLB 및 EC2 인스턴스를 생성합니다.

D. AWS Global Accelerator에서 표준 가속기를 만듭니다. 기존 NLB를 대상 엔드포인트로 구성합니다.

D. AWS Global Accelerator에서 표준 가속기를 만듭니다. 기존 NLB를 대상 엔드포인트로 구성합니다.
- AWS Global Accelerator는 전 세계에 걸친 고성능 네트워크 경로를 제공하여, 사용자와 애플리케이션 간의 트래픽을 최적의 경로로 전달합니다. Global Accelerator는 AWS 글로벌 네트워크를 활용해 최단 경로를 통해 데이터 전송을 가속화하여 지연 시간을 줄이고 사용자 경험을 개선할 수 있습니다.
- Global Accelerator의 표준 가속기를 사용하면, 특정 지리적 위치에서 사용자 트래픽을 가장 가까운 NLB로 자동으로 라우팅할 수 있습니다. 이는 전 세계적으로 분산된 사용자들에게 지리적으로 최적화된 엔드포인트를 제공하는 효과가 있습니다.
- 기존의 NLB와 통합 가능: Global Accelerator는 기존의 NLB와 원활하게 통합할 수 있습니다. 따라서 현재의 인프라를 크게 변경하지 않고도 성능을 개선할 수 있습니다.

---

■ Question #816

한 회사에는 SFTP를 사용하여 여러 공급업체로부터 재무 데이터를 수집하는 온프레미스 애플리케이션이 있습니다. 이 회사는 AWS 클라우드로 마이그레이션하고 있습니다. 이 회사는 Amazon S3 API를 사용하여 공급업체의 파일을 업로드하는 애플리케이션을 만들었습니다. 일부 공급업체는 S3 API를 지원하지 않는 레거시 애플리케이션에서 시스템을 실행합니다. 공급업체는 SFTP 기반 애플리케이션을 사용하여 데이터를 업로드하려고 합니다. 이 회사는 레거시 애플리케이션을 사용하는 공급업체의 요구 사항에 대해 관리형 서비스를 사용하려고 합니다.

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

A. 레거시 애플리케이션을 사용하는 공급업체의 스토리지에서 Amazon S3로 데이터를 복제하기 위해 AWS Database Migration Service (AWS DMS) 인스턴스를 만듭니다. 공급업체에 AWS DMS 인스턴스에 액세스할 수 있는 자격 증명을 제공합니다.

B. 레거시 애플리케이션을 사용하는 공급업체를 위한 AWS Transfer Family 엔드포인트를 생성합니다.

C. SFTP 서버를 실행하도록 Amazon EC2 인스턴스를 구성합니다. 레거시 애플리케이션을 사용하는 공급업체에 SFTP 서버를 사용하여 데이터를 업로드하도록 지시합니다.

D. 레거시 애플리케이션을 사용하여 SMB 파일 공유에 파일을 업로드하는 공급업체를 위해 Amazon S3 파일 게이트웨이를 구성합니다.

B. 레거시 애플리케이션을 사용하는 공급업체를 위한 AWS Transfer Family 엔드포인트를 생성합니다.
- AWS Transfer Family는 완전 관리형 SFTP 서비스를 제공하여, SFTP를 사용하는 레거시 애플리케이션과의 통합을 간편하게 해줍니다. 이를 통해 회사는 AWS Transfer Family를 사용하여 공급업체의 데이터를 안전하게 수집하고 Amazon S3에 저장할 수 있습니다.
- AWS Transfer Family는 고가용성 및 확장성을 제공하며, 사용자는 SFTP를 통해 파일을 업로드하는 동안 자동으로 Amazon S3에 데이터를 저장할 수 있습니다. 이로 인해 회사는 S3 API를 지원하지 않는 공급업체의 요구를 충족할 수 있습니다.
- 운영 오버헤드가 적음: AWS Transfer Family는 AWS에서 관리되는 서비스이기 때문에, 서버 설정 및 유지보수에 대한 부담이 적고, 관리 오버헤드가 크게 줄어듭니다. 공급업체에는 SFTP 자격 증명만 제공하면 되므로 쉽게 통합할 수 있습니다.

---

■ Question #817

마케팅 팀은 다가올 다종목 스포츠 이벤트에 대한 캠페인을 구축하고자 합니다. 이 팀은 지난 5년간의 뉴스 기사를 PDF 형식으로 보유하고 있습니다. 이 팀은 뉴스 기사의 내용과 감정에 대한 통찰력을 추출하는 솔루션이 필요합니다. 이 솔루션은 Amazon Textract를 사용하여 뉴스 기사를 처리해야 합니다.

어떤 솔루션이 운영 오버헤드를 최소화하면서 이러한 요구 사항을 충족할까요?

A. 추출된 인사이트를 분석을 위해 Amazon Athena에 제공합니다. 추출된 인사이트와 분석을 Amazon S3 버킷에 저장합니다.

B. 추출된 인사이트를 Amazon DynamoDB 테이블에 저장합니다. Amazon SageMaker를 사용하여 감정 모델을 구축합니다.

C. 추출된 인사이트를 분석을 위해 Amazon Comprehend에 제공합니다. 분석을 Amazon S3 버킷에 저장합니다.

D. 추출된 인사이트를 Amazon S3 버킷에 저장합니다. Amazon QuickSight를 사용하여 데이터를 시각화하고 분석합니다.

C. 추출된 인사이트를 분석을 위해 Amazon Comprehend에 제공합니다. 분석을 Amazon S3 버킷에 저장합니다.
- Amazon Textract는 PDF 문서에서 텍스트와 데이터를 추출할 수 있습니다. 이 단계에서 뉴스 기사에서 텍스트를 추출한 후, 이를 Amazon Comprehend에 제공하여 감정 분석을 수행할 수 있습니다. Amazon Comprehend는 감정 분석, 엔터티 추출, 키워드 추출 등 다양한 텍스트 분석 기능을 지원합니다.
- Amazon Comprehend는 관리형 NLP(자연어 처리) 서비스로, 직접 모델을 학습하거나 유지보수할 필요 없이 쉽게 감정 분석을 수행할 수 있습니다. 이는 운영 오버헤드를 크게 줄여줍니다.
- 분석된 인사이트는 Amazon S3 버킷에 저장하여 추후에 데이터 저장 및 분석을 쉽게 관리할 수 있습니다. Amazon S3는 비용 효율적이고 확장 가능한 스토리지 솔루션입니다.

---

■ Question #818

회사의 애플리케이션은 여러 가용성 영역에 있는 Amazon EC2 인스턴스에서 실행됩니다. 애플리케이션은 타사 애플리케이션에서 실시간 데이터를 수집해야 합니다. 회사에는 수집된 원시 데이터를 Amazon S3 버킷에 저장하는 데이터 수집 솔루션이 필요합니다.

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

A. 데이터 수집을 위해 Amazon Kinesis 데이터 스트림을 만듭니다. Kinesis 데이터 스트림을 소비하기 위해 Amazon Kinesis Data Firehose 전달 스트림을 만듭니다. 전달 스트림의 대상으로 S3 버킷을 지정합니다.

B. AWS Database Migration Service(AWS DMS)에서 데이터베이스 마이그레이션 작업을 만듭니다. EC2 인스턴스의 복제 인스턴스를 소스 엔드포인트로 지정합니다. S3 버킷을 대상 엔드포인트로 지정합니다. 마이그레이션 유형을 설정하여 기존 데이터를 마이그레이션하고 진행 중인 변경 사항을 복제합니다.
C. EC2 인스턴스에서 AWS DataSync 에이전트를 생성하고 구성합니다. EC2 인스턴스에서 S3 버킷으로 데이터를 전송하도록 DataSync 작업을 구성합니다.

D. 데이터 수집을 위해 애플리케이션에 AWS Direct Connect 연결을 만듭니다. 애플리케이션에서 직접 PUT 작업을 사용하기 위해 Amazon Kinesis Data Firehose 전송 스트림을 만듭니다. 전송 스트림의 대상으로 S3 버킷을 지정합니다.

A. 데이터 수집을 위해 Amazon Kinesis 데이터 스트림을 만듭니다. Kinesis 데이터 스트림을 소비하기 위해 Amazon Kinesis Data Firehose 전달 스트림을 만듭니다. 전달 스트림의 대상으로 S3 버킷을 지정합니다.
- Amazon Kinesis 데이터 스트림은 실시간 데이터 수집에 최적화되어 있으며, 데이터 수집 및 처리에 대한 확장성을 제공합니다. Kinesis 데이터 스트림을 사용하면 실시간으로 들어오는 데이터를 빠르고 안정적으로 수집할 수 있습니다.
- Kinesis Data Firehose는 수집된 데이터를 자동으로 Amazon S3에 전달하는 관리형 서비스로, Kinesis 데이터 스트림과 통합하여 실시간 데이터 수집 및 저장을 효율적으로 처리할 수 있습니다.
- 이 접근법은 서버리스 아키텍처로 관리 오버헤드가 적으며, 실시간 데이터 수집 및 저장을 손쉽게 처리할 수 있습니다. 또한, 확장성 및 고가용성을 제공하기 때문에 여러 가용성 영역에서 안정적인 데이터 수집이 가능합니다.

---

■ Question #819

회사의 애플리케이션은 여러 데이터 소스에서 데이터를 수신하고 있습니다. 데이터 크기는 다양하며 시간이 지남에 따라 증가할 것으로 예상됩니다. 현재 최대 크기는 700KB입니다. 더 많은 데이터 소스가 추가됨에 따라 데이터 볼륨과 데이터 크기가 계속 증가합니다. 회사는 애플리케이션의 기본 데이터베이스로 Amazon DynamoDB를 사용하기로 결정했습니다. 솔루션 아키텍트는 대용량 데이터 크기를 처리하는 솔루션을 식별해야 합니다.

어떤 솔루션이 가장 운영 효율적인 방식으로 이러한 요구 사항을 충족할까요?

A. DynamoDB 항목 크기 제한을 초과하는 데이터를 필터링하기 위한 AWS Lambda 함수를 만듭니다. 더 큰 데이터는 Amazon DocumentDB(MongoDB 호환) 데이터베이스에 저장합니다.

B. Amazon S3 버킷에 대용량 데이터를 객체로 저장합니다. DynamoDB 테이블에서 데이터의 S3 URL을 가리키는 속성이 있는 항목을 만듭니다.

C. 들어오는 모든 대용량 데이터를 동일한 파티션 키를 가진 항목 컬렉션으로 분할합니다. BatchWriteItem API 작업을 사용하여 단일 작업으로 DynamoDB 테이블에 데이터를 씁니다.

D. DynamoDB 테이블에 작성되는 대용량 객체를 압축하기 위해 gzip 압축을 사용하는 AWS Lambda 함수를 생성합니다.

B. Amazon S3 버킷에 대용량 데이터를 객체로 저장합니다. DynamoDB 테이블에서 데이터의 S3 URL을 가리키는 속성이 있는 항목을 만듭니다.
- Amazon DynamoDB의 항목 크기 제한은 400KB입니다. 이는 단일 항목에 저장할 수 있는 데이터의 최대 크기입니다. 데이터 크기가 700KB를 초과하고, 시간이 지남에 따라 더 커질 것으로 예상되기 때문에 이 한계를 해결해야 합니다.
- Amazon S3는 대용량 데이터를 객체로 저장하기에 이상적입니다. S3는 거의 무제한에 가까운 스토리지 용량을 제공하며, 객체 기반의 접근 방식을 통해 큰 데이터를 효율적으로 저장할 수 있습니다.
- DynamoDB에서 S3에 저장된 데이터를 참조하는 URL 속성을 항목으로 관리하면, DynamoDB의 크기 제한을 우회하면서도 빠르고 효율적으로 데이터에 접근할 수 있습니다. 이 방법은 비용 효율적이며, 대용량 데이터를 관리하기에 적합합니다.

---

■ Question #820

한 회사가 온프레미스 데이터 센터에서 AWS로 레거시 애플리케이션을 마이그레이션하고 있습니다. 이 애플리케이션은 하루 종일 다양한 반복 일정으로 1~20분 사이에 실행되는 수백 개의 크론 작업에 의존합니다. 이 회사는 최소한의 리팩토링으로 AWS에서 크론 작업을 예약하고 실행할 수 있는 솔루션을 원합니다. 이 솔루션은 향후 이벤트에 대한 응답으로 크론 작업을 실행할 수 있어야 합니다.

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

A. Cron 작업에 대한 컨테이너 이미지를 만듭니다. Amazon EventBridge Scheduler를 사용하여 반복 일정을 만듭니다. Cron 작업 작업을 AWS Lambda 함수로 실행합니다.

B. Cron 작업에 대한 컨테이너 이미지를 만듭니다. Amazon Elastic Container Service(Amazon ECS)에서 AWS Batch를 사용하여 스케줄링 정책을 사용하여 Cron 작업을 실행합니다.

C. Cron 작업에 대한 컨테이너 이미지를 만듭니다. Amazon EventBridge Scheduler를 사용하여 반복 일정을 만듭니다. AWS Fargate에서 Cron 작업 작업을 실행합니다.

D. cron 작업에 대한 컨테이너 이미지를 만듭니다. 지정된 시간에 cron 작업을 실행하기 위해 Wait 상태를 사용하는 AWS Step Functions에서 워크플로를 만듭니다. RunTask 작업을 사용하여 AWS Fargate에서 cron 작업 태스크를 실행합니다.

C. Cron 작업에 대한 컨테이너 이미지를 만듭니다. Amazon EventBridge Scheduler를 사용하여 반복 일정을 만듭니다. AWS Fargate에서 Cron 작업 작업을 실행합니다.
- Amazon EventBridge Scheduler는 정기적인 작업 예약을 관리하는 강력한 기능을 제공합니다. 이를 통해 크론 작업과 같은 반복 일정을 쉽게 정의하고 관리할 수 있습니다.
- AWS Fargate는 서버리스 컨테이너 관리 서비스로, 컨테이너 이미지를 기반으로 작업을 실행할 수 있습니다. 이를 통해 리소스 관리 없이 컨테이너 작업을 실행할 수 있으며, 다양한 크론 작업을 효율적으로 관리할 수 있습니다.
- 컨테이너 이미지로 작업을 정의함으로써, 온프레미스에서 크론 작업을 AWS로 마이그레이션할 때 리팩토링이 최소화됩니다. 기존의 스크립트를 컨테이너화하여 그대로 사용할 수 있습니다.
- EventBridge Scheduler를 통해 반복적인 일정을 설정할 수 있으며, 이벤트 기반 트리거와도 쉽게 통합할 수 있습니다. 따라서 이벤트 발생 시에도 크론 작업을 유연하게 실행할 수 있습니다.