AWS SAA-C03 Examtopics (501 ~ 520)

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

 

■ Question #501

한 회사가 고객 결제 데이터를 Amazon S3의 회사 데이터 레이크(Data Lake)로 수집하려고 합니다. 회사는 평균적으로 1분마다 결제 데이터를 수신합니다. 회사는 실시간으로 결제 데이터를 분석하려고 합니다. 그런 다음 회사는 데이터를 데이터 레이크(Data Lake)로 수집하려고 합니다.

어떤 솔루션이 가장 높은 운영 효율성으로 이러한 요구 사항을 충족할까요?

A. Amazon Kinesis Data Streams를 사용하여 데이터를 수집합니다. AWS Lambda를 사용하여 실시간으로 데이터를 분석합니다.
B. AWS Glue를 사용하여 데이터를 수집합니다. Amazon Kinesis Data Analytics를 사용하여 실시간으로 데이터를 분석합니다.
C. Amazon Kinesis Data Firehose를 사용하여 데이터를 수집합니다. Amazon Kinesis Data Analytics를 사용하여 실시간으로 데이터를 분석합니다.
D. Amazon API Gateway를 사용하여 데이터를 수집합니다. AWS Lambda를 사용하여 실시간으로 데이터를 분석합니다.

C. Amazon Kinesis Data Firehose를 사용하여 데이터를 수집합니다. Amazon Kinesis Data Analytics를 사용하여 실시간으로 데이터를 분석합니다.

Kinesis : AWS 에서 제공하는 실시간 데이터 처리, 분석 시스템
- Kinesis Data Stream :실시간으로 data 들을 받아들일 수 있는 입구이자 저장소로서의 역할로, 한 시스템이 실시간으로 Data Stream에 데이터를 전송하면 해당 Data Stream을 listening 하고있던 다른 한 시스템이 해당 데이터를 받아 처리

- Kinesis Data Firehose (Delivery Stream) : 주목적은 미리 정의된 목적지(Destination)에 데이터를 안전하게 전달(Deliver)하는 것으로, 여기서 목적지라 함은 S3 bucket, ElasticSearch, Amazon Redshift 등이 data lake의 역할을 할 수 있는 다양한 저장소를 말함 (Date Firehose는 데이터를 그저 전달하는 것 뿐만 아니라 람다(Lambda)를 이용해 가공하는 작업도 가능)

- Kinesis Video Stream : 사용자 디바이스에서 AWS로 비디오 데이터를 쉽고 안전하게 스트리밍할 수 있게 도와주는 서비스

- Kinesis Data Analytics : 실시간으로 스트리밍 데이터를 필터링, 집계 및 변환하는 고급 분석 기능을 제공하는 서비스

Amazon Kinesis Data Firehose
- Kinesis Data Firehose는 데이터를 실시간으로 수집하여 Amazon S3, Redshift, Elasticsearch, 또는 Splunk와 같은 대상에 자동으로 전송할 수 있습니다. Firehose는 자동으로 데이터를 배치하여 S3에 저장할 수 있으며, 데이터를 지속적으로 전송하면서 운영 오버헤드를 최소화합니다. 이를 통해 *데이터 레이크로 결제 데이터를 효율적으로 수집할 수 있습니다. (데이터 레이크(Data Lake) : 모든 규모의 정형 및 비정형 데이터를 저장할 수 있는 중앙 집중식 리포지토리)

- Firehose는 완전 관리형 서비스이기 때문에 별도의 클러스터 관리나 프로비저닝이 필요 없으며, 실시간 데이터 스트림을 처리하는 데 매우 적합합니다. 자동으로 데이터를 버퍼링하고 압축하여 운영 효율성을 높일 수 있습니다.

Amazon Kinesis Data Analytics
- Kinesis Data Analytics는 Kinesis 스트림이나 Firehose에서 데이터를 실시간으로 분석할 수 있는 서비스입니다. SQL 기반의 쿼리를 사용하여 실시간으로 데이터를 처리하고, 결제 데이터를 즉시 분석할 수 있습니다. 이는 결제 데이터를 실시간으로 분석하려는 회사의 요구 사항을 충족시킵니다.

- 이 솔루션은 데이터가 수집되는 즉시 분석을 수행할 수 있으므로, 실시간 처리 요구 사항에 맞는 저지연 데이터 분석을 제공합니다.

 

운영 효율성
- Kinesis Data Firehose는 완전 관리형 서비스로, 운영 부담을 최소화하면서 데이터를 수집하고 S3 같은 대상에 자동으로 적재할 수 있습니다. 수동으로 처리할 필요 없이 자동 배치 및 전송이 이루어지기 때문에 운영 복잡성을 줄일 수 있습니다.
- Kinesis Data Analytics도 서버리스 아키텍처로, 데이터 처리 및 분석을 자동으로 확장할 수 있으며, 복잡한 인프라 관리 없이 실시간 분석을 수행할 수 있어 운영 효율성이 매우 높습니다.

---

■ Question #502

한 회사가 Amazon EC2에서 콘텐츠 관리 시스템(CMS)을 사용하는 웹사이트를 운영합니다. CMS는 단일 EC2 인스턴스에서 실행되고 데이터 계층에 Amazon Aurora MySQL Multi-AZ DB 인스턴스를 사용합니다. 웹사이트 이미지는 EC2 인스턴스 내부에 마운트된 Amazon Elastic Block Store(Amazon EBS) 볼륨에 저장됩니다.

솔루션 아키텍트는 웹사이트의 성능과 복원력을 개선하기 위해 어떤 조치 조합을 취해야 합니까? (두 가지를 선택하세요.)

A. 웹사이트 이미지를 모든 EC2 인스턴스에 마운트된 Amazon S3 버킷으로 이동합니다.
B. 기본 EC2 인스턴스에서 NFS 공유를 사용하여 웹사이트 이미지를 공유합니다. 이 공유를 다른 EC2 인스턴스에 마운트합니다.
C. 웹사이트 이미지를 모든 EC2 인스턴스에 마운트된 Amazon Elastic File System(Amazon EFS) 파일 시스템으로 옮깁니다.
D. 기존 EC2 인스턴스에서 Amazon Machine Image(AMI)를 만듭니다. AMI를 사용하여 Auto Scaling 그룹의 일부로 Application Load Balancer 뒤에 새 인스턴스를 프로비저닝합니다. Auto Scaling 그룹을 구성하여 최소 두 개의 인스턴스를 유지합니다. 웹사이트에 대한 AWS Global Accelerator에서 가속기를 구성합니다.
E. 기존 EC2 인스턴스에서 Amazon Machine Image(AMI)를 만듭니다. AMI를 사용하여 Auto Scaling 그룹의 일부로 Application Load Balancer 뒤에 새 인스턴스를 프로비저닝합니다. 최소 두 개의 인스턴스를 유지하도록 Auto Scaling 그룹을 구성합니다. 웹사이트에 대한 Amazon CloudFront 배포를 구성합니다.

C. 웹사이트 이미지를 모든 EC2 인스턴스에 마운트된 Amazon Elastic File System(Amazon EFS) 파일 시스템으로 옮깁니다.
- Amazon EFS는 공유 파일 시스템으로 여러 EC2 인스턴스에서 동시에 액세스할 수 있는 완전 관리형 파일 스토리지입니다.
- EFS는 고가용성과 확장성을 제공하므로, 여러 EC2 인스턴스가 동시에 같은 파일 시스템을 사용하여 복원력을 높일 수 있습니다.

- 또한, EFS는 여러 가용 영역(AZ)에 걸쳐 데이터를 복제하여 데이터 가용성과 복원력을 강화합니다. 따라서 웹사이트 이미지 파일을 EBS에서 EFS로 옮기면 EC2 인스턴스 간에 파일을 쉽게 공유할 수 있고, 인스턴스 장애 시에도 파일에 계속 접근할 수 있습니다.

E. 기존 EC2 인스턴스에서 Amazon Machine Image(AMI)를 만듭니다. AMI를 사용하여 Auto Scaling 그룹의 일부로 Application Load Balancer 뒤에 새 인스턴스를 프로비저닝합니다. 최소 두 개의 인스턴스를 유지하도록 Auto Scaling 그룹을 구성합니다. 웹사이트에 대한 Amazon CloudFront 배포를 구성합니다.
- Auto Scaling 그룹을 사용하면 트래픽에 따라 EC2 인스턴스를 자동으로 확장하거나 축소할 수 있습니다. 이를 통해 사이트 성능과 복원력을 개선할 수 있습니다.

- 예를 들어, 트래픽이 급증할 때 Auto Scaling 그룹이 인스턴스를 추가하여 성능을 보장하고, 장애 시에도 다른 인스턴스가 트래픽을 처리할 수 있어 복원력이 강화됩니다.

- Application Load Balancer(ALB)는 여러 EC2 인스턴스로 들어오는 트래픽을 자동으로 분산시켜 성능을 최적화하고, 인스턴스 간 균형을 유지합니다.

- Amazon CloudFront는 AWS에서 제공하는 글로벌 콘텐츠 전송 네트워크(CDN) 서비스로, 웹 콘텐츠(예: 이미지, 동영상, HTML 파일 등)를 사용자에게 빠르고 안전하게 제공할 수 있게 해줍니다. CloudFront는 전 세계 여러 위치에 분산된 엣지 서버를 통해 사용자와 가까운 서버에서 콘텐츠를 캐시하고 전송하여 지연 시간을 최소화하고 성능을 향상시킵니다.

---

■ Question #503

한 회사가 인프라 모니터링 서비스를 운영합니다. 이 회사는 고객 AWS 계정의 데이터를 모니터링할 수 있는 새로운 기능을 구축하고 있습니다. 이 새로운 기능은 고객 계정의 AWS API를 호출하여 Amazon EC2 인스턴스를 설명하고 Amazon CloudWatch 메트릭을 읽습니다.

이 회사는 가장 안전한 방법으로 고객 계정에 액세스하려면 무엇을 해야 합니까?

A. 고객이 자신의 계정에 EC2 및 CloudWatch 읽기 전용 권한과 회사 계정에 대한 신뢰 정책이 있는 IAM 역할을 생성했는지 확인합니다.
B. 읽기 전용 EC2 및 CloudWatch 권한이 있는 역할에 대한 임시 AWS 자격 증명을 제공하는 토큰 자동 판매기를 구현하는 서버리스 API를 만듭니다.
C. 고객이 자신의 계정에서 읽기 전용 EC2 및 CloudWatch 권한이 있는 IAM 사용자를 생성하도록 합니다. 비밀 관리 시스템에서 고객 액세스 및 비밀 키를 암호화하고 저장합니다.
D. 고객이 자신의 계정에서 Amazon Cognito 사용자를 만들어 읽기 전용 EC2 및 CloudWatch 권한이 있는 IAM 역할을 사용하도록 합니다. Amazon Cognito 사용자와 비밀번호를 암호화하여 비밀 관리 시스템에 저장합니다.

A. 고객이 자신의 계정에 EC2 및 CloudWatch 읽기 전용 권한과 회사 계정에 대한 신뢰 정책이 있는 IAM 역할을 생성했는지 확인 합니다.

IAM 역할과 신뢰 정책을 사용하여 회사가 고객 계정에 안전하게 접근할 수 있는 가장 표준적이고 안전한 방식입니다. 고객은 자신의 계정에서 역할을 직접 관리하며, 회사는 고객 계정의 역할을 AssumeRole API를 통해 접근하는 방식으로, 보안과 관리의 유연성을 동시에 확보할 수 있습니다.
- Assume Role은 AWS IAM에서 지원하는 기능 중 하나입니다. AWS IAM에서 Assume Role을 사용하면 IAM 사용자 또는 AWS 외부 자격 증명으로 다른 AWS 계정 또는 리소스에 액세스할 수 있음

IAM 역할과 신뢰 정책
- 고객이 자신의 계정에서 특정 권한을 가진 IAM 역할을 생성하고, 해당 역할에 신뢰 정책을 설정하여 회사의 AWS 계정만 이 역할을 사용할 수 있도록 허용하는 방식은 가장 안전하고 관리하기 쉬운 접근 방식입니다.

- 이 방식은 고객의 계정에서 직접 IAM 역할을 생성하고 회사 계정에 이 역할을 위임하는 것이기 때문에, 고객 데이터에 대한 접근을 고객이 제어할 수 있습니다.

- 회사는 고객의 역할을 AssumeRole API를 통해 접근할 수 있으며, 이 과정에서 임시 자격 증명이 발급되므로 보안적으로도 안전합니다. 이 방식은 최소한의 권한을 부여하고, 권한 남용을 방지할 수 있습니다.

보안
- 임시 자격 증명을 사용하면 고객 계정에 장기적인 자격 증명이 남아 있지 않으며, 필요할 때만 역할을 사용하여 접근할 수 있습니다. 또한 고객은 회사 계정이 어떤 권한을 가질지 정확하게 통제할 수 있습니다.

- 신뢰 정책은 고객 계정 내에서 회사 계정만 해당 역할을 사용할 수 있도록 보장합니다. 이를 통해 고객은 불필요한 접근을 방지하고, 특정 권한만 부여할 수 있습니다.

---

■ Question #504

회사는 수백 개의 AWS 계정에 걸쳐 있는 us-east-1 리전의 여러 VPC를 연결해야 합니다. 회사의 네트워크 팀은 클라우드 네트워크를 관리하기 위한 자체 AWS 계정을 보유하고 있습니다.

VPC를 연결하기 위한 가장 운영 효율적인 솔루션은 무엇입니까?

A. 각 VPC 간에 VPC 피어링 연결을 설정합니다. 각 연관된 서브넷의 라우팅 테이블을 업데이트합니다.
B. 각 VPC에 NAT 게이트웨이와 인터넷 게이트웨이를 구성하여 인터넷을 통해 각 VPC를 연결합니다.
C. 네트워킹 팀의 AWS 계정에 AWS 트랜짓 게이트웨이(AWS Transit Gateway)를 만듭니다. 각 VPC에서 정적 라우팅을 구성합니다.
D. 각 VPC에 VPN 게이트웨이를 배포합니다. 네트워킹 팀의 AWS 계정에서 각 VPC에 연결하기 위해 트랜짓 VPC를 만듭니다.

C. 네트워킹 팀의 AWS 계정에서 AWS Transit Gateway를 만듭니다. 각 VPC에서 정적 경로를 구성합니다.

AWS Transit Gateway는 여러 AWS 계정에 걸쳐 있는 VPC (Virtual Private Cloud)를 중앙에서 효율적으로 관리하고 연견할 수 있는 가장 확장성 있고 운영 효율적인 솔루션입니다. Transit Gateway는 중앙 허브로 모든 VPC (Virtual Private Cloud)를 연결하여 관리 부담을 줄이고, 성능과 보안 면에서도 우수합니다.
- VPC (Virtual Private Cloud) : 퍼블릭 클라우드 환경에서 사용할 수 있는 기존 네트워크와 아주 유사한 가상 네트워크
- AWS Transit Gateway와 VPC 피어링의 주요 차이점은 AWS Transit Gateway가 허브 앤 스포크 모델에서 여러 VPC를 서로 연결하도록 설계된 반면, VPC 피어링은 피어 투 피어 모델에서 두 VPC를 서로 연결하도록 설계되었다는 점

 AWS Transit Gateway
- AWS Transit Gateway는 여러 VPC (Virtual Private Cloud), 온프레미스 네트워크, 그리고 AWS 계정 간의 네트워크를 중앙에서 관리하고 연결할 수 있는 서비스입니다. Transit Gateway는 다수의 VPC (Virtual Private Cloud)를 효율적으로 연결할 수 있도록 설계되어 있으며, 각 VPC (Virtual Private Cloud)를 직접 연결할 필요 없이 중앙 허브 역할을 수행합니다.

- 운영 효율성 면에서, 각 VPC(Virtual Private Cloud) 간에 직접 연결하는 VPC (Virtual Private Cloud) 피어링 방식과 달리, Transit Gateway는 하나의 중앙 허브로 모든 연결을 관리할 수 있어 설정 및 관리가 훨씬 간단하고 확장성이 뛰어납니다.
- 네트워킹 팀의 AWS 계정에서 Transit Gateway를 생성하고, 각 VPC (Virtual Private Cloud)를 Transit Gateway에 연결함으로써 회사의 모든 AWS 계정에 걸친 여러 VPC (Virtual Private Cloud)를 효율적으로 중앙에서 관리할 수 있습니다.

정적 경로 설정
- 각 VPC에서 정적 경로를 구성함으로써, 해당 VPC (Virtual Private Cloud)에서 Transit Gateway를 통해 다른 VPC로 트래픽을 전달할 수 있습니다. 이는 추가적인 경로 설정 없이 VPC (Virtual Private Cloud) 간에 원활하게 통신할 수 있도록 해 줍니다.
- 중앙 집중화된 네트워크 관리로 인해 운영 복잡성을 줄이고, 네트워크 트래픽을 효율적으로 라우팅할 수 있습니다.

---

■ Question #505

한 회사에는 데이터를 처리하기 위해 매일 밤 일괄 작업을 실행하는 Amazon EC2 인스턴스가 있습니다. EC2 인스턴스는 주문형 청구를 사용하는 자동 확장 그룹에서 실행됩니다. 한 인스턴스에서 작업이 실패하면 다른 인스턴스가 작업을 다시 처리합니다. 일괄 작업은 매일 오전 12시부터 오전 6시(현지 시간) 사이에 실행됩니다.

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

A. 배치 작업이 사용하는 자동 확장 그룹의 인스턴스 패밀리를 포함하는 Amazon EC2용 1년 절감 플랜을 구매합니다.
B. 일괄 작업이 사용하는 자동 확장 그룹의 인스턴스의 특정 인스턴스 유형 및 운영 체제에 대한 1년 예약 인스턴스를 구매합니다.
C. 자동 확장 그룹에 대한 새 시작 템플릿을 만듭니다. 인스턴스를 스팟 인스턴스(Spot Instances)로 설정합니다. CPU 사용량에 따라 확장할 정책을 설정합니다.
D. 자동 확장 그룹에 대한 새 시작 템플릿을 만듭니다. 인스턴스 크기를 늘립니다. CPU 사용량에 따라 확장할 정책을 설정합니다.

C. 자동 확장 그룹에 대한 새 시작 템플릿을 만듭니다. 인스턴스를 Spot Instances로 설정합니다. CPU 사용량에 따라 확장할 정책을 설정합니다.

Spot Instances를 사용하여 매우 낮은 비용으로 EC2 인스턴스를 실행하고, 자동 확장 그룹을 통해 필요한 시점에만 인스턴스를 프로비저닝하여 비용 효율성을 극대화할 수 있는 최적의 솔루션입니다. Spot Instances의 특성상 중단될 수 있지만, 이 시나리오에서는 작업이 자동으로 재시작되므로 큰 문제 없이 비용 절감 효과를 극대화할 수 있습니다.

Spot Instances의 비용 절감
- Spot Instances는 Amazon EC2의 미사용 컴퓨팅 용량을 매우 할인된 가격으로 제공하는 방식입니다. 일반적으로 온디맨드 인스턴스보다 최대 90% 저렴할 수 있습니다.
- 회사의 작업이 매일 밤에 실행되고, 특정 시간 동안에만 실행되는 일괄 작업이므로, 만약 인스턴스가 중단되더라도 자동 확장 그룹을 통해 작업이 다른 인스턴스에서 다시 실행되기 때문에, Spot Instances의 중단 가능성도 큰 문제로 작용하지 않습니다.
- Spot Instances는 비용 절감을 최적화할 수 있는 가장 좋은 옵션입니다. 특히 일괄 작업의 경우, 작업이 중단되더라도 다시 재시작되도록 설계되어 있어, Spot Instances의 중단 가능성을 감내할 수 있는 구조입니다.

자동 확장 그룹과 CPU 사용량에 따른 확장
- 자동 확장 그룹을 사용하여 CPU 사용량에 따라 EC2 인스턴스를 자동으로 확장함으로써, 시스템 부하가 높을 때는 추가 인스턴스를 프로비저닝하고, 부하가 낮아지면 인스턴스를 축소할 수 있습니다. 이렇게 함으로써 필요한 시점에만 리소스를 사용하여 비용 효율성을 극대화할 수 있습니다.

- 이는 특히 매일 밤 12시부터 6시 사이에만 리소스를 집중적으로 사용하는 상황에서 매우 적합한 방법입니다. 일괄 작업은 특정 시간 동안에만 실행되기 때문에 자동 확장이 잘 맞습니다.

---

■ Question #506

소셜 미디어 회사가 웹사이트 기능을 구축하고 있습니다. 이 기능을 사용하면 사용자가 사진을 업로드할 수 있습니다. 이 회사는 대규모 이벤트 기간 동안 수요가 크게 증가할 것으로 예상하고 웹사이트가 사용자의 업로드 트래픽을 처리할 수 있도록 해야 합니다.

어떤 솔루션이 가장 확장성이 뛰어나 이러한 요구 사항을 충족합니까?

A. 사용자 브라우저에서 애플리케이션 서버로 파일을 업로드합니다. 파일을 Amazon S3 버킷으로 전송합니다.
B. AWS Storage Gateway 파일 게이트웨이를 프로비저닝합니다. 사용자 브라우저에서 파일 게이트웨이로 직접 파일을 업로드합니다.
C. 애플리케이션에서 Amazon S3 사전 서명 URL을 생성합니다. 사용자의 브라우저에서 S3 버킷으로 직접 파일을 업로드합니다.
D. Amazon Elastic File System(Amazon EFS) 파일 시스템을 프로비저닝합니다. 사용자의 브라우저에서 파일 시스템으로 직접 파일을 업로드합니다.

C. 애플리케이션에서 Amazon S3 사전 서명 URL을 생성합니다. 사용자의 브라우저에서 S3 버킷으로 직접 파일을 업로드합니다.

S3 사전 서명 URL을 사용하여 브라우저에서 직접 파일을 업로드하는 방식이 가장 확장성이 뛰어나고 비용 효율적인 솔루션입니다. 이 방식은 서버 부하를 줄이면서도 많은 양의 파일 업로드 트래픽을 처리할 수 있으므로, 대규모 이벤트에서의 급증하는 수요를 안전하고 효율적으로 처리할 수 있습니다.

Amazon S3의 확장성
- Amazon S3는 AWS에서 제공하는 완전 관리형 객체 스토리지 서비스로, 매우 뛰어난 확장성과 고가용성을 제공합니다. 수요가 급격히 증가하는 대규모 이벤트 기간에도 S3는 자동으로 확장되며, 수천 개 이상의 동시 파일 업로드 요청을 처리할 수 있습니다.

- C는 사용자가 직접 S3 버킷으로 파일을 업로드하는 구조이므로, 애플리케이션 서버에 과부하가 발생하지 않고, 애플리케이션의 성능이 저하되지 않도록 보장합니다. 이는 애플리케이션 서버를 거치지 않고 S3 버킷으로 바로 파일을 업로드하므로, 네트워크 트래픽과 서버 부하를 크게 줄일 수 있는 확장성이 높은 방식입니다.

사전 서명된 URL (Pre-signed URL)
- 사전 서명된 URL을 사용하면 애플리케이션 서버가 AWS의 보안 액세스 권한을 위임하여 사용자 브라우저가 S3 버킷에 파일을 직접 업로드할 수 있습니다. 이 방식은 S3에 직접 접근할 수 있도록 권한을 제한하여 부여하는 것으로, 업로드 시 인증을 보장하면서도 애플리케이션 서버를 통하지 않고 S3에 파일을 안전하게 업로드할 수 있습니다.

- 애플리케이션 서버는 사전 서명된 URL만 생성하고, 실제 파일 업로드는 사용자의 브라우저와 S3 간에 직접 이루어지기 때문에 서버 부하가 크게 줄어듭니다. 이로 인해 확장성이 매우 뛰어나고, 많은 사용자가 동시다발적으로 파일을 업로드하는 상황에서도 대응할 수 있습니다.

---

■ Question #507

한 회사에 여행 티켓팅을 위한 웹 애플리케이션이 있습니다. 이 애플리케이션은 북미의 단일 데이터 센터에서 실행되는 데이터베이스를 기반으로 합니다. 이 회사는 글로벌 사용자 기반을 제공하기 위해 애플리케이션을 확장하려고 합니다. 이 회사는 애플리케이션을 여러 AWS 지역에 배포해야 합니다. 예약 데이터베이스 업데이트 시 평균 지연 시간은 1초 미만이어야 합니다.

이 회사는 여러 지역에 웹 플랫폼을 별도로 배포하려고 합니다. 그러나 이 회사는 글로벌하게 일관된 단일 기본 예약 데이터베이스를 유지 관리해야 합니다. 이러한 요구 사항을 충족하기 위해 솔루션 아키텍트는 어떤 솔루션을 권장해야 합니까?

A. Amazon DynamoDB를 사용하도록 애플리케이션을 변환합니다. 중앙 예약 테이블에 글로벌 테이블을 사용합니다. 각 지역 배포에서 올바른 지역 엔드포인트를 사용합니다.
B. 데이터베이스를 Amazon Aurora MySQL 데이터베이스로 마이그레이션합니다. 각 지역에 Aurora Read Replica를 배포합니다. 각 지역 배포에서 올바른 지역 엔드포인트를 사용하여 데이터베이스에 액세스합니다.
C. 데이터베이스를 Amazon RDS for MySQL 데이터베이스로 마이그레이션합니다. 각 리전에 MySQL 읽기 복제본을 배포합니다. 각 리전 배포에서 올바른 리전 엔드포인트를 사용하여 데이터베이스에 액세스합니다.
D. 애플리케이션을 Amazon Aurora Serverless 데이터베이스로 마이그레이션합니다. 각 리전에 데이터베이스 인스턴스를 배포합니다. 각 리전 배포에서 올바른 리전 엔드포인트를 사용하여 데이터베이스에 액세스합니다. AWS Lambda 함수를 사용하여 각 리전에서 이벤트 스트림을 처리하여 데이터베이스를 동기화합니다.

A. Amazon DynamoDB를 사용하도록 애플리케이션을 변환합니다. 중앙 예약 테이블에 글로벌 테이블을 사용합니다. 각 지역 배포에서 올바른 지역 엔드포인트를 사용합니다.

DynamoDB 글로벌 테이블을 사용하여 여러 리전에서 쓰기 및 읽기 작업을 처리하면서도 글로벌 데이터베이스 일관성을 유지하고, 낮은 지연 시간을 제공할 수 있는 가장 확장성 있고 효율적인 솔루션입니다. DynamoDB의 글로벌 테이블은 여러 리전에서 데이터를 실시간으로 복제하며, 사용자 요청에 빠르게 대응할 수 있어 이 시나리오의 요구사항을 충족시킬 수 있습니다.

Amazon DynamoDB 글로벌 테이블
- DynamoDB 글로벌 테이블은 여러 AWS 리전 간에 데이터를 자동으로 복제하여 글로벌한 데이터베이스 일관성을 유지하면서도 낮은 지연 시간을 보장할 수 있습니다. 이 시스템은 멀티마스터 아키텍처를 제공하여, 각 리전에서 읽기 및 쓰기 작업을 처리할 수 있으므로 지연 시간을 줄일 수 있습니다.

- 글로벌 테이블은 리전 간의 데이터 동기화를 자동으로 처리하므로, 1초 미만의 지연 시간이라는 요구사항을 충족할 수 있습니다. 사용자 요청은 가장 가까운 리전에서 처리되며, 데이터베이스 업데이트는 각 리전 간에 빠르게 전파됩니다.

확장성 및 고가용성
- DynamoDB는 완전 관리형 NoSQL 서비스로서, 자동으로 확장되며 글로벌 사용자 수요를 처리할 수 있습니다. 여러 리전에 걸쳐 트래픽이 분산되므로, 성능 면에서 매우 효율적입니다.
- DynamoDB의 글로벌 테이블은 고가용성과 내구성을 제공하므로, 데이터 손실 위험이 줄어들고, 동시에 여러 리전에서 데이터 업데이트가 일관되게 이루어집니다.

글로벌 데이터베이스 유지
- 글로벌 테이블을 사용하면 중앙 예약 데이터베이스를 각 리전에서 일관되게 관리할 수 있습니다. 이는 글로벌하게 일관된 단일 기본 데이터베이스를 유지해야 한다는 요구사항을 충족합니다.

---

■ Question #508

한 회사가 여러 Microsoft Windows Server 워크로드를 us-west-1 리전에서 실행되는 Amazon EC2 인스턴스로 마이그레이션했습니다. 이 회사는 필요에 따라 워크로드를 수동으로 백업하여 이미지를 만듭니다.

us-west-1 리전에서 자연 재해가 발생하는 경우 이 회사는 us-west-2 지역에서 워크로드를 신속하게 복구하려고 합니다. 이 회사는 EC2 인스턴스에서 24시간 이상의 데이터 손실을 원하지 않습니다. 또한 이 회사는 EC2 인스턴스의 모든 백업을 자동화하려고 합니다.

어떤 솔루션이 최소한의 관리 노력으로 이러한 요구 사항을 충족할까요? (두 가지를 선택하세요.)

A. Amazon EC2 지원 Amazon Machine Image(AMI) 수명 주기 정책을 만들어 태그 기반 백업을 만듭니다. 백업을 하루에 두 번 실행하도록 예약합니다. 필요에 따라 이미지를 복사합니다.
B. Amazon EC2 지원 Amazon Machine Image(AMI) 수명 주기 정책을 만들어 태그 기반 백업을 만듭니다. 백업을 하루에 두 번 실행하도록 예약합니다. us-west-2 리전에 대한 복사본을 구성합니다.
C. AWS Backup을 사용하여 us-west-1과 us-west-2에 백업 볼트를 만듭니다. 태그 값을 기반으로 EC2 인스턴스에 대한 백업 계획을 만듭니다. 백업 데이터를 us-west-2에 복사하기 위해 예약된 작업으로 실행할 AWS Lambda 함수를 만듭니다.
D. AWS Backup을 사용하여 백업 볼트를 만듭니다. AWS Backup을 사용하여 태그 값을 기반으로 EC2 인스턴스에 대한 백업 계획을 만듭니다. 복사본의 대상을 us-west-2로 정의합니다. 하루에 두 번 실행되도록 백업 일정을 지정합니다.
E. AWS Backup을 사용하여 백업 볼트를 만듭니다. AWS Backup을 사용하여 태그 값을 기반으로 EC2 인스턴스에 대한 백업 계획을 만듭니다. 하루에 두 번 실행되도록 백업 일정을 지정합니다. us-west-2에 필요에 따라 복사합니다.

B와 D는 백업을 자동화하고 us-west-2로 복사본을 자동 생성하여 24시간 이내의 데이터 손실을 방지하는 최적의 솔루션입니다. 이 두 옵션 모두 관리 노력을 최소화하면서 재해 발생 시 신속한 복구를 가능하게 합니다.

B. Amazon EC2 지원 Amazon Machine Image(AMI) 수명 주기 정책을 만들어 태그 기반 백업을 만듭니다. 백업을 하루에 두 번 실행하도록 예약합니다. us-west-2 리전에 대한 복사본을 구성합니다. 
- AMI 수명 주기 정책을 사용하면 Amazon EC2 인스턴스의 백업을 자동화할 수 있습니다. 이를 통해 관리 부담을 줄이고 백업을 자동으로 생성할 수 있습니다.

- 이 솔루션에서는 us-west-2 리전으로 백업을 자동으로 복사하므로, us-west-1에서 자연 재해가 발생하는 경우에도 데이터를 신속하게 복구할 수 있습니다.

- 하루에 두 번 백업을 실행하는 일정으로 설정하여 데이터 손실을 24시간 이내로 제한할 수 있습니다.
- 자동화된 백업과 자동 리전 간 복사는 관리 노력을 줄이면서 요구 사항을 충족시킵니다.

D. AWS Backup을 사용하여 백업 볼트를 만듭니다. AWS Backup을 사용하여 태그 값을 기반으로 EC2 인스턴스에 대한 백업 계획을 만듭니다. 복사본의 대상을 us-west-2로 정의합니다. 하루에 두 번 실행되도록 백업 일정을 지정합니다.
- AWS Backup은 다양한 AWS 리소스에 대한 백업을 자동화하고 관리할 수 있는 서비스입니다. EC2 인스턴스에 대한 태그 기반 백업 계획을 설정하여 백업을 자동으로 실행할 수 있습니다.

- 백업 데이터를 us-west-2로 자동 복사하도록 정의할 수 있으며, 하루에 두 번 실행되는 백업 일정을 설정하여 데이터 손실을 최소화할 수 있습니다.

- AWS Backup은 복원 기능을 제공하여 us-west-2 리전에서 신속한 복구를 가능하게 합니다.
- AWS Backup은 중앙에서 관리되며, 여러 리소스의 백업을 한 번에 관리할 수 있기 때문에 관리 노력을 최소화할 수 있습니다.

---

■ Question #509

한 회사가 이미지 처리를 위한 2계층 애플리케이션을 운영합니다. 이 애플리케이션은 각각 하나의 퍼블릭 서브넷과 하나의 프라이빗 서브넷이 있는 두 개의 가용성 영역을 사용합니다. 웹 계층의 애플리케이션 로드 밸런서(ALB)는 퍼블릭 서브넷을 사용합니다. 애플리케이션 계층의 Amazon EC2 인스턴스는 프라이빗 서브넷을 사용합니다.

사용자는 애플리케이션이 예상보다 느리게 실행된다고 보고합니다. 웹 서버 로그 파일의 보안 감사에서 애플리케이션이 소수의 IP 주소에서 수백만 개의 불법 요청을 받고 있음을 보여줍니다. 솔루션 아키텍트는 회사가 보다 영구적인 솔루션을 조사하는 동안 즉각적인 성능 문제를 해결해야 합니다. 이 요구 사항을 충족하기 위해 솔루션 아키텍트는 무엇을 권장해야 합니까?

A. 웹 계층에 대한 인바운드 보안 그룹을 수정합니다. 리소스를 소비하는 IP 주소에 대한 거부 규칙을 추가합니다.
B. 웹 티어 서브넷에 대한 네트워크 ACL을 수정합니다. 리소스를 소비하는 IP 주소에 대한 인바운드 거부 규칙을 추가합니다.
C. 애플리케이션 계층에 대한 인바운드 보안 그룹을 수정합니다. 리소스를 소비하는 IP 주소에 대한 거부 규칙을 추가합니다.
D. 애플리케이션 계층 서브넷에 대한 네트워크 ACL을 수정합니다. 리소스를 소비하는 IP 주소에 대한 인바운드 거부 규칙을 추가합니다.

B. 웹 티어 서브넷에 대한 네트워크 ACL을 수정합니다. 리소스를 소비하는 IP 주소에 대한 인바운드 거부 규칙을 추가합니다.

AWS 보안 그룹(Security Group)은 허용 규칙만 지정할 수 있으며, 거부 규칙을 설정할 수는 없습니다. 보안 그룹은 기본적으로 모든 트래픽을 차단하고, 명시적으로 허용한 트래픽만 통과시키는 방식입니다.

네트워크 ACL(Network ACL)은 보안 그룹(Security Group)과 다르게 허용 및 거부 규칙을 모두 설정할 수 있습니다.
- 네트워크 ACL은 상태 비저장 방식으로 동작하므로, 트래픽이 인바운드 또는 아웃바운드에 대해 각각 허용 또는 거부 규칙을 설정할 수 있습니다.
- 불법 요청을 보내는 특정 IP 주소에 대해 명시적으로 거부 규칙을 추가할 수 있습니다. 이를 통해 해당 IP에서 오는 트래픽을 차단할 수 있습니다.

 

웹 티어 서브넷에서 불법 요청이 발생하고 있으므로, 웹 티어 서브넷에 적용된 네트워크 ACL을 수정하여 불법 요청을 보내는 IP 주소를 차단하는 것이 효과적인 해결책입니다.

네트워크 ACL은 서브넷 수준에서 동작하므로, 웹 티어가 위치한 퍼블릭 서브넷에 적용하여 문제가 되는 IP 주소로부터의 요청을 거부할 수 있습니다.

---

■ Question #510

글로벌 마케팅 회사는 ap-southeast-2 리전과 eu-west-1 리전에서 애플리케이션을 운영하고 있습니다. eu-west-1의 VPC에서 실행되는 애플리케이션은 ap-southeast-2의 VPC에서 실행되는 데이터베이스와 안전하게 통신해야 합니다.

이 요구 사항을 충족할 네트워크 설계는 무엇입니까?

A. eu-west-1 VPC와 ap-southeast-2 VPC 간에 VPC 피어링 연결을 만듭니다. ap-southeast-2 보안 그룹의 데이터베이스 서버 IP 주소에서 트래픽을 허용하는 규칙을 eu-west-1 애플리케이션 보안 그룹의 인바운드 규칙으로 만듭니다.
B. ap-southeast-2 VPC와 eu-west-1 VPC 간에 VPC 피어링 연결을 구성합니다. 서브넷 경로 테이블을 업데이트합니다. eu-west-1의 애플리케이션 서버 보안 그룹 ID를 참조하는 인바운드 규칙을 ap-southeast-2 데이터베이스 보안 그룹에 만듭니다.
C. ap-southeast-2 VPC와 eu-west-1 VPC 간에 VPC 피어링 연결을 구성합니다. 서브넷 경로 테이블을 업데이트합니다. eu-west-11 애플리케이션 서버의 IP 주소에서 트래픽을 허용하는 인바운드 규칙을 ap-southeast-2 데이터베이스 보안 그룹에 만듭니다.
D. eu-west-1 VPC와 ap-southeast-2 VPC 간에 피어링 어태치먼트가 있는 트랜짓 게이트웨이(Transit Gateway)를 만듭니다. 트랜짓 게이트웨이(Transit Gateway)가 제대로 피어링되고 라우팅이 구성된 후 eu-west-1의 애플리케이션 서버의 보안 그룹 ID를 참조하는 인바운드 규칙을 데이터베이스 보안 그룹에 만듭니다.

B. ap-southeast-2 VPC와 eu-west-1 VPC 간에 VPC 피어링 연결을 구성합니다. 서브넷 경로 테이블을 업데이트합니다. eu-west-1의 애플리케이션 서버 보안 그룹 ID를 참조하는 인바운드 규칙을 ap-southeast-2 데이터베이스 보안 그룹에 만듭니다.

VPC 피어링과 보안 그룹 ID 참조를 사용하여 두 리전 간 안전하고 직접적인 통신을 설정하는 간단하면서도 효율적인 방법입니다. 그러나 네트워크가 더 확장되거나 여러 VPC를 관리해야 하는 경우 D 옵션(트랜짓 게이트웨이)이 더 나은 선택일 수 있습니다.
- 트랜짓 게이트웨이(Transit Gateway)는 AWS에서 여러 VPC를 중앙에서 연결하고 관리할 수 있는 네트워크 허브 역할을 합니다. 트랜짓 게이트웨이를 사용하면 여러 리전 간 VPC 연결을 간단하게 설정할 수 있습니다.

---

■ Question #511

한 회사가 PostgreSQL 데이터베이스 스키마를 사용하는 소프트웨어를 개발하고 있습니다. 회사는 개발자들을 위한 여러 개발 환경과 데이터베이스를 구성해야 합니다. 평균적으로 각 개발 환경은 8시간 근무 시간 중 절반 동안 사용됩니다.

다음 중 어떤 솔루션이 이러한 요구 사항을 가장 비용 효율적으로 충족할 수 있습니까?

A. 각 개발 환경에 Amazon Aurora PostgreSQL 데이터베이스를 구성한다.
B. 각 개발 환경에 Amazon RDS for PostgreSQL Single-AZ DB 인스턴스를 구성한다.
C. 각 개발 환경에 Amazon Aurora On-Demand PostgreSQL 호환 데이터베이스를 구성한다.
D. 각 개발 환경에 Amazon S3 Object Select를 사용하여 Amazon S3 버킷을 구성한다.

B. 각 개발 환경에 Amazon RDS for PostgreSQL Single-AZ DB 인스턴스를 구성한다.

Amazon RDS for PostgreSQL Single-AZ DB 인스턴스는 개발 환경에 필요한 기능을 제공하면서도 비용 효율적인 선택입니다. Aurora보다 저렴하고, S3 Object Select보다 적합한 데이터베이스 서비스를 제공합니다.
- Single-AZ DB Instances : 가장 간단한 데이터베이스 구성이며, 단일 가용성 영역 내의 단일 데이터베이스 인스턴스로 구성됩니다.  이 구성은 가용성 영역이 하나만 사용되므로 중복성을 제공하지 않습니다.

- Multi-AZ DB Instances : 하나의 Primary DB Instance와 하나의 Standby Replica Instance로 구성되어 있으며, Primary DB Instance는 읽기/쓰기 작업을 수행하고, Standby Replica로 동기식으로 데이터를 복제합니다. (애플리케이션의 중단을 최소화하고, 가용성을 높이는 일반적인 방식이라고 할 수 있음)

개발 환경의 사용 패턴
- 각 개발 환경은 8시간 중 절반 동안만 사용됩니다. 즉, 개발 환경은 하루 약 4시간만 사용된다는 의미입니다. 따라서 항상 고성능, 고가용성 데이터베이스를 실행할 필요는 없으며, 비용을 줄이기 위해 단순하고 저렴한 데이터베이스 솔루션이 적합합니다.

 

Amazon RDS for PostgreSQL Single-AZ
- Amazon RDS는 관계형 데이터베이스를 관리하는 완전 관리형 서비스로, 개발자가 인프라 관리에 신경 쓰지 않고 소프트웨어 개발에 집중할 수 있습니다. Single-AZ 옵션은 비용 절감을 위해 고가용성 대신 단일 가용성 영역에서 데이터베이스를 실행하는 방식입니다.

- 개발 환경에서는 고가용성(Aurora와 같은 Multi-AZ)의 필요성이 적기 때문에 Single-AZ RDS 인스턴스가 비용 대비 효율적입니다.

 

Amazon Aurora와의 비교
- Amazon Aurora는 AWS에서 제공하는 고성능, 고가용성 데이터베이스 서비스입니다. 성능이 뛰어나고 자동 확장 기능이 있지만, 그만큼 비용이 더 높습니다. 개발 환경에서는 Aurora의 성능이 과도하게 높고, 불필요한 추가 비용이 발생할 수 있습니다. 따라서 Aurora는 비용 효율성이 떨어집니다.

- A와 C는 모두 Amazon Aurora 기반이므로, RDS보다 더 높은 비용이 발생할 가능성이 큽니다. 특히 개발 환경에서는 Aurora의 고성능이 반드시 필요한 것은 아닙니다.

 

S3(Simple Storage Service) Object Select와의 비교
- S3 Object Select는 Amazon S3 버킷에 저장된 데이터에서 쿼리를 수행할 수 있는 기능이지만, 이것은 객체 스토리지로, 관계형 데이터베이스 시스템이 아닙니다. PostgreSQL과 같은 SQL 기반의 정형화된 데이터베이스를 사용하는 소프트웨어 개발에 적합하지 않습니다.

---

■ Question #512

한 회사는 AWS Organizations를 사용하여 계정별로 태그가 지정된 리소스를 관리하고 있습니다. 또한 AWS Backup을 사용하여 AWS 인프라 리소스를 백업하고 있습니다. 회사는 모든 AWS 리소스를 백업해야 합니다.

다음 중 최소한의 운영 오버헤드로 이러한 요구 사항을 충족할 수 있는 솔루션은 무엇입니까?

A. AWS Config를 사용하여 태그가 없는 모든 리소스를 식별합니다. 식별된 리소스에 대해 프로그램 방식으로 태그를 지정하고, 백업 계획에서 태그를 사용합니다.
B. AWS Config를 사용하여 실행 중이지 않은 모든 리소스를 식별하고, 해당 리소스를 백업 볼트에 추가합니다.
C. 모든 AWS 계정 소유자가 자신의 리소스를 검토하여 백업이 필요한 리소스를 식별하도록 요구합니다.
D. Amazon Inspector를 사용하여 규정 위반 리소스를 식별합니다.

A. AWS Config를 사용하여 태그가 없는 모든 리소스를 식별합니다. 식별된 리소스에 대해 프로그램 방식으로 태그를 지정하고, 백업 계획에서 태그를 사용합니다.

AWS Config를 사용하여 태그가 없는 리소스를 자동으로 식별하고, 백업 계획에 태그를 사용하는 방식이 최소한의 운영 오버헤드로 모든 리소스를 백업할 수 있는 가장 적합한 솔루션입니다.

AWS Organizations와 태그 관리
- AWS Organizations : 여러 조직을 하나의 AWS 계정 조직으로 통합하여 사용자가 만들고 중앙에서 관리할 수 있게 해주는 계정 관리 서비스로, 여러 AWS 계정에 대한 권한 설정 및 각 계정의 청구 정보를 통합한 일괄 청구를 이용할 수 있습니다.

- 회사가 AWS Organizations를 사용하고 있다는 점에서 여러 AWS 계정에 걸쳐 리소스를 관리하고 있으며, 각 리소스에 태그가 지정되어 있다는 것을 알 수 있습니다. 태그는 리소스를 분류하고, 관리 및 백업 계획을 적용하는 데 매우 중요한 역할을 합니다. 태그를 사용하면 백업할 리소스를 효율적으로 선택할 수 있습니다.

 

AWS Config를 사용한 리소스 식별
- AWS Config는 AWS 환경에서 모든 리소스의 구성을 추적하고, 변경 사항을 모니터링하는 서비스입니다. 태그가 없는 리소스를 자동으로 식별할 수 있으며, 백업 계획에서 누락될 수 있는 리소스를 찾는 데 유용합니다.

- 태그가 없는 리소스를 식별한 후, 이를 프로그램 방식으로 태그 지정하여 백업 계획에 포함시킬 수 있습니다. 이렇게 하면 수동 작업 없이도 모든 리소스를 관리할 수 있습니다.

 

백업 계획에서 태그 사용
- AWS Backup은 태그를 기반으로 백업할 리소스를 선택할 수 있습니다. 따라서 모든 리소스에 태그를 지정하면 백업 작업을 자동화할 수 있어 운영 오버헤드를 크게 줄일 수 있습니다.

- 태그가 지정된 리소스를 기반으로 백업 계획을 구성하면, AWS Organizations의 각 계정에서 관리되는 리소스를 중앙에서 효율적으로 백업할 수 있습니다.

---

■ Question #513

한 소셜 미디어 회사는 AWS 클라우드에 호스팅된 애플리케이션에서 사용자들이 이미지를 업로드할 수 있도록 하기를 원합니다. 이 회사는 이미지를 여러 장치 유형에서 표시할 수 있도록 자동으로 크기를 조정하는 솔루션이 필요합니다. 애플리케이션은 하루 동안 예츨할 수 없는 트래픽 패턴을 경험합니다. 회사는 높은 가용성을 유지하고 확장성을 극대화하는 솔루션을 찾고 있습니다.

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

A. Amazon S3에 호스팅된 정적 웹사이트를 생성하여 AWS Lambda 함수가 이미지를 리사이징하고 Amazon S3 버킷에 이미지를 저장하도록 설정합니다.
B. Amazon CloudFront에 호스팅된 정적 웹사이트를 생성하여 AWS Step Functions를 호출해 이미지를 리사이징하고, 이미지를 Amazon RDS 데이터베이스에 저장합니다.
C. Amazon EC2 인스턴스에서 실행되는 웹 서버에 호스팅된 동적 웹사이트를 생성합니다. EC2 인스턴스에서 이미지를 리사이징하고 이미지를 Amazon S3 버킷에 저장하는 프로세스를 설정합니다.
D. 자동으로 확장되는 Amazon Elastic Container Service(Amazon ECS) 클러스터에 호스팅된 동적 웹사이트를 생성하여 Amazon Simple Queue Service(Amazon SQS)에서 리사이징 작업을 생성합니다. 그런 다음 Amazon EC2 인스턴스에서 실행되는 이미지 리사이징 프로그램을 설정하여 리사이징 작업을 처리합니다.

A. Amazon S3에 호스팅된 정적 웹사이트를 생성하여 AWS Lambda 함수가 이미지를 리사이징하고 Amazon S3 버킷에 이미지를 저장하도록 설정합니다.

Amazon S3와 AWS Lambda를 사용하여 서버리스 방식으로 이미지를 처리하고, 트래픽 변동에 자동으로 확장할 수 있는 가장 효율적인 방법입니다. Lambda는 서버를 관리할 필요 없이 이벤트 기반으로 동작하며, S3는 안전하고 확장 가능한 스토리지 솔루션을 제공합니다. 이 솔루션은 비용 효율성, 확장성, 운영 편의성을 모두 충족하는 최적의 선택입니다.

- 이미지 업로드 및 리사이징 : 사용자가 여러 장치에서 이미지를 업로드하고 자동으로 크기를 조정해야 합니다. 따라서 이미지 리사이징 기능이 필요하며, 이를 효율적으로 처리할 수 있는 확장 가능한 솔루션이 필요합니다.- 예측할 수 없는 트래픽 패턴 : 트래픽 패턴이 예측할 수 없으므로, 시스템은 트래픽 변화에 따라 자동으로 확장할 수 있어야 합니다.
- 높은 가용성과 확장성 : 시스템은 높은 가용성을 유지해야 하고, 자동 확장을 통해 트래픽 증가에도 대응할 수 있어야 합니다.

Amazon S3 + AWS Lambda
- Amazon S3는 정적 웹사이트를 호스팅할 수 있으며, 이미지를 저장하는 데 매우 적합한 솔루션입니다. 또한 높은 가용성과 내구성을 제공하므로 이미지를 안전하게 저장할 수 있습니다.
- AWS Lambda는 서버리스 컴퓨팅 서비스로, 이미지 업로드 시 이벤트 기반으로 이미지를 리사이징할 수 있습니다. 트래픽이 증가해도 Lambda는 자동으로 확장되어 추가 인스턴스를 생성하지 않고도 처리할 수 있습니다.
- 서버 관리가 필요 없으며 Lambda 함수가 이벤트를 처리하고 이미지를 리사이징한 후 다시 S3에 저장하므로 운영 오버헤드가 매우 낮습니다.
- 이 솔루션은 확장성과 비용 효율성이 뛰어나며, 트래픽 변동에도 유연하게 대응할 수 있습니다.

---

■ Question #514

한 회사에서 Amazon EC2 인스턴스에서 마이크로서비스 애플리케이션을 실행하고 있습니다. 이 회사는 확장성을 위해 애플리케이션을 Amazon Elastic Kubernetes Service(Amazon EKS) 클러스터로 마이그레이션하려고 합니다. 이 회사는 보안 규정 준수를 유지하기 위해 엔드포인트 프라이빗(private) 액세스를 true로 설정하고 엔드포인트 퍼블릭(public) 액세스를 false로 설정하여 Amazon EKS 컨트롤 플레인을 구성해야 합니다. 또한 데이터 플레인을 프라이빗 서브넷에 배치해야 합니다. 그러나 노드가 클러스터에 가입할 수 없기 때문에 오류 알림을 받았습니다.

어떤 솔루션으로 노드가 클러스터에 가입할 수 있나요?

A. AmazonEKSNodeRole IAM 역할에 AWS Identity and Access Management(IAM)에서 필요한 권한을 부여합니다.
B. 노드가 제어 플레인에 액세스할 수 있도록 인터페이스 VPC 엔드포인트를 생성합니다.
C. 퍼블릭 서브넷에서 노드를 다시 생성하고, EC2 노드를 위한 보안 그룹을 제한합니다.
D. 노드의 보안 그룹에서 아웃바운드 트래픽을 허용합니다.

B. 노드가 제어 플레인에 액세스할 수 있도록 인터페이스 VPC 엔드포인트를 생성합니다.

Amazon EKS(Elastic Kubernetes Service) : 완전관리형 컨테이너 오케스트레이션 서비스로, 쿠버네티스 클러스터를 설정, 운영, 유지 관리하는 복잡한 작업을 AWS가 대신 수행

프라이빗 액세스와 퍼블릭 액세스 설정
- 질문에서 Amazon EKS (Elastic Kubernetes Service) 제어 플레인을 프라이빗 액세스만 허용하고, 퍼블릭 액세스를 차단한 상태로 설정했다는 점이 중요합니다. 즉, 제어 플레인은 인터넷을 통해 접근할 수 없으며, VPC (Virtual Private Cloud)내에서만 접근할 수 있습니다.
- 이 설정 때문에 데이터 플레인(노드)는 퍼블릭 인터넷을 통해 EKS (Elastic Kubernetes Service) 제어 플레인에 접근할 수 없고, 프라이빗 네트워크 내에서만 접근해야 합니다.

노드의 클러스터 연결 문제
- 데이터 플레인에 있는 노드가 EKS (Elastic Kubernetes Service) 제어 플레인에 연결하려면, 프라이빗 네트워크 내에서 안전하게 연결할 수 있는 경로가 필요합니다.
- Amazon EKS (Elastic Kubernetes Service)에서 제어 플레인과 데이터 플레인의 통신은 AWS API를 통해 이루어지며, 이 통신을 허용하기 위해서는 인터페이스 VPC (Virtual Private Cloud) 엔드포인트가 필요합니다. 이 엔드포인트는 프라이빗 네트워크 내에서 API 서버에 연결할 수 있는 경로를 제공합니다.

인터페이스 VPC (Virtual Private Cloud) 엔드포인트
- 인터페이스 VPC (Virtual Private Cloud) 엔드포인트는 AWS 프라이빗 링크(PrivateLink)를 통해 VPC (Virtual Private Cloud) 내에서 특정 AWS 서비스(이 경우, Amazon EKS API)에 액세스할 수 있도록 합니다. 이 엔드포인트를 설정하면 노드는 인터넷 연결 없이 EKS (Elastic Kubernetes Service) 제어 플레인에 안전하게 연결할 수 있습니다.
- 따라서 EKS (Elastic Kubernetes Service) 제어 플레인을 프라이빗 액세스만 허용하도록 구성한 상황에서는 인터페이스 VPC (Virtual Private Cloud)엔드포인트를 통해 연결이 이루어져야 합니다.

---

■ Question #515

회사가 온프레미스 애플리케이션을 AWS로 마이그레이션하고 있으며, Amazon Redshift를 솔루션으로 사용하려고 합니다. 이 시나리오에서 Amazon Redshift에 적합한 사용 사례는 무엇입니까? (세 가지 선택)

A. 전통적인, 컨테이너화된, 이벤트 기반 애플리케이션과 함께 데이터를 액세스할 수 있도록 데이터 API 지원
B. 클라이언트 측 및 서버 측 암호화 지원
C. 애플리케이션이 비활성 상태일 때와 특정 시간 동안 분석 작업 구축
D. 백엔드 데이터베이스에 가해지는 압력을 줄이기 위해 데이터 캐싱
E. 전 세계적으로 확장하여 페타바이트 규모의 데이터와 수천만 건의 요청을 지원
F. AWS Management Console을 사용하여 클러스터의 보조 복제본 생성

Amazon Redshift는 주로 대규모 데이터 분석과 데이터 웨어하우징에 적합한 서비스

B. 클라이언트 측 및 서버 측 암호화 지원
- Amazon Redshift는 데이터를 보호하기 위해 클라이언트 측 및 서버 측 암호화를 모두 지원합니다. 이 기능은 데이터 보안과 관련된 중요한 요구 사항을 충족하는 데 적합합니다. Redshift는 암호화 기능을 통해 데이터 전송 중 및 저장 중에 데이터를 보호할 수 있습니다.

C. 애플리케이션이 비활성 상태일 때와 특정 시간 동안 분석 작업 구축
- Amazon Redshift는 대규모 데이터 분석 작업에 최적화되어 있습니다. 배치 작업이나 정기적인 분석을 위한 환경에서 매우 적합하며, 특히 애플리케이션이 비활성 상태일 때 또는 특정 시간에 데이터를 처리하는 시나리오에서 유용합니다.

E. 전 세계적으로 확장하여 페타바이트 규모의 데이터와 수천만 건의 요청을 지원
- Redshift는 페타바이트 규모의 데이터를 처리할 수 있는 대규모 데이터 웨어하우스 솔루션입니다. 수천만 건의 요청을 처리하며, 글로벌 확장성을 제공합니다. Redshift의 분산 아키텍처는 데이터 분석 워크로드를 확장하는 데 매우 적합합니다.

---

■ Question #516

회사는 고객이 금융 정보를 조회할 수 있도록 API 인터페이스를 제공합니다. 회사는 연중 최대 사용 시간 동안 더 많은 요청이 있을 것으로 예상합니다. 회사는 고객 만족을 위해 API가 일관되게 낮은 지연 시간으로 응답해야 합니다. 또한 회사는 API를 위한 컴퓨팅 호스트를 제공해야 합니다.

최소한의 운영 오버헤드로 이러한 요구 사항을 충족할 수 있는 솔루션은 무엇입니까?

A. Application Load Balancer와 Amazon Elastic Container Service(Amazon ECS)를 사용합니다.
B. Amazon API Gateway와 프로비저닝된 동시성을 가진 AWS Lambda 함수를 사용합니다.
C. Application Load Balancer와 Amazon Elastic Kubernetes Service(Amazon EKS) 클러스터를 사용합니다.
D. Amazon API Gateway와 예약된 동시성을 가진 AWS Lambda 함수를 사용합니다.

B. Amazon API Gateway와 프로비저닝된 동시성을 가진 AWS Lambda 함수를 사용합니다.

API 인터페이스 제공
- 회사는 고객이 금융 정보를 조회할 수 있도록 API 인터페이스를 제공해야 하며, 일관되게 낮은 지연 시간이 중요한 요구 사항입니다. Amazon API Gateway는 완전 관리형 API 서비스로, HTTP 기반 API를 손쉽게 구축할 수 있으며 낮은 지연 시간으로 트래픽을 처리할 수 있습니다.
- API Gateway는 규모와 관계없이 REST 및 WebSocket API를 생성, 게시, 유지, 모니터링 및 보호하기 위한 AWS 서비스로, 화장성이 뛰어나며, API 요청 수가 급격히 증가할 때에도 자동으로 확장할 수 있습니다.

AWS Lambda와 프로비저닝된 동시성
- 프로비저닝된 동시성(Provisioned Concurrency) : Lambda 함수를 지속적으로 초기화하며 런타임 환경을 준비함으로써, 사용자의 요청에 바로 응답할 수 있는 상태로 만들어줍니다.
- AWS Lambda는 서버리스 컴퓨팅 서비스로, 서버를 관리할 필요 없이 애플리케이션 코드를 실행할 수 있습니다. Lambda는 이벤트 기반으로 실행되며, 자동 확장이 가능하여 트래픽 변화에 유연하게 대응할 수 있습니다.
- 프로비저닝된 동시성을 사용하면, Lambda 함수의 인스턴스를 미리 준비해 두어 트래픽이 많을 때도 즉시 응답할 수 있도록 합니다. 이를 통해 API가 일관된 낮은 지연 시간을 유지할 수 있습니다. 특히, 최대 사용 시간 동안 더 많은 요청이 예상되는 경우 프로비저닝된 동시성을 설정하면 급증하는 트래픽에도 안정적으로 응답할 수 있습니다.

운영 오버헤드 최소화
- 서버 관리가 필요 없는 서버리스 구조는 운영 오버헤드를 크게 줄여 줍니다. Lambda와 API Gateway는 자동으로 확장되고, 관리가 용이하며, 인프라를 직접 설정할 필요가 없습니다.
- 프로비저닝된 동시성은 미리 준비된 인스턴스가 즉시 트래픽을 처리할 수 있도록 하여, 성능을 보장하면서도 운영 부담을 최소화합니다.

---

■ Question #517

어떤 회사에서 모든 AWS Systems Manager Session Manager 로그를 보관 목적으로 Amazon S3 버킷으로 보내고 싶어합니다. 어떤 솔루션이 가장 높은 운영 효율성으로 이 요구 사항을 충족할까요?

A. Systems Manager 콘솔에서 S3 로깅을 활성화합니다. 세션 데이터를 보낼 S3 버킷을 선택합니다.
B. Amazon CloudWatch 에이전트를 설치합니다. 모든 로그를 CloudWatch 로그 그룹으로 푸시합니다. 보관 목적으로 그룹에서 S3 버킷으로 로그를 내보냅니다.
C. 모든 서버 로그를 중앙 S3 버킷에 업로드하기 위한 Systems Manager 문서를 만듭니다. Amazon EventBridge를 사용하여 계정에 있는 모든 서버에 대해 Systems Manager 문서를 매일 실행합니다.
D. Amazon CloudWatch 에이전트를 설치합니다. 모든 로그를 CloudWatch 로그 그룹으로 푸시합니다. 들어오는 모든 로그 이벤트를 Amazon Kinesis Data Firehose 전송 스트림으로 푸시하는 CloudWatch 로그 구독을 만듭니다. Amazon S3를 대상으로 설정합니다.

A. Systems Manager 콘솔에서 S3 로깅을 활성화합니다. 세션 데이터를 보낼 S3 버킷을 선택합니다.

Session Manager : 종합 관리형 AWS Systems Manager 기능으로, Session Manager를 사용하여 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스, 엣지 디바이스, 온프레미스 서버 및 가상 머신을 관리할 수 있습니다.

Systems Manager Session Manager 로그 전송을 위한 간편한 설정
- AWS Systems Manager Session Manager는 서버와의 연결을 중앙에서 관리하며, 세션 기록을 Amazon S3로 쉽게 전송할 수 있는 기능을 기본적으로 제공합니다.
- A에서언급된 Systems Manager 콘솔에서 S3 로깅을 활성화하는 방식은 가장 직관적이고 간단한 설정입니다. 운영 부담 없이 콘솔에서 몇 가지 클릭만으로 S3 버킷을 지정하고 세션 로그를 자동으로 전송할 수 있습니다.
- Systems Manager는 기본적으로 S3와 통합되어 있으며, S3 버킷에 로그를 저장하는 것이 매우 간편하게 설정됩니다.

운영 오버헤드 최소화
- 추가적인 설정이나 복잡한 인프라 관리가 필요하지 않으며, 콘솔에서 바로 활성화할 수 있습니다. 다른 옵션들과 비교했을 때, 별도의 로그 전송 서비스나 추가적인 관리가 필요하지 않기 때문에 운영 오버헤드가 가장 낮습니다.
- 다른 방법들(예: B, C, D)은 각각 추가적인 AWS 서비스(예: CloudWatch, Kinesis Data Firehose 등)를 활용해 로그를 전송하거나 처리하는 과정이 필요하며, 이로 인해 운영 복잡성과 비용이 증가할 수 있습니다.

---

■ Question #518

한 애플리케이션이 Amazon RDS MySQL DB 인스턴스를 사용 중입니다. RDS 데이터베이스의 디스크 공간이 부족해지고 있습니다. 솔루션 아키텍트는 다운타임 없이 디스크 공간을 늘리고 싶어합니다.

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

A. RDS에서 스토리지 자동 확장을 활성화합니다.
B. RDS 데이터베이스 인스턴스 크기를 늘립니다.
C. RDS 데이터베이스 인스턴스 스토리지 유형을 프로비저닝된 IOPS로 변경합니다.
D. RDS 데이터베이스를 백업하고, 스토리지 용량을 늘린 후 데이터베이스를 복원하고 이전 인스턴스를 중지합니다.

A. RDS에서 스토리지 자동 확장 활성화

스토리지 자동 확장 기능
- Amazon RDS(Relational Database Service)는 스토리지 자동 확장(Storage Auto Scaling) 기능을 제공합니다. 이 기능을 활성화하면, RDS (Relational Database Service) 인스턴스의 스토리지가 자동으로 확장되어 디스크 공간이 부족해질 때 추가 용량을 자동으로 할당할 수 있습니다. (RDS : 관계형 데이터베이스를 제공하는 AWS의 서비스)
- 이 과정에서 다운타임이 발생하지 않으며, 애플리케이션은 정상적으로 동작을 계속할 수 있습니다. 즉, 스토리지 확장이 투명하게 이루어져 사용자는 중단 없이 서비스를 이용할 수 있습니다.

최소한의 노력
- 스토리지 자동 확장을 활성화하면, 추가적인 수동 조작 없이 RDS (Relational Database Service) 인스턴스의 스토리지가 자동으로 관리됩니다. 이는 솔루션 아키텍트가 요구한 다운타임 없이 최소한의 노력으로 디스크 공간을 늘리는 방법에 부합합니다.

---

■ Question #519

컨설팅 회사는 전 세계 고객에게 전문 서비스를 제공합니다. 회사는 고객이 AWS에서 데이터를 수집하고 분석하는 과정을 신속하게 진행할 수 있도록 솔루션과 도구를 제공합니다. 회사는 고객이 셀프 서비스 방식으로 사용할 수 있는 공통 솔루션 및 도구 세트를 중앙에서 관리하고 배포할 필요가 있습니다.

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

A. 고객을 위해 AWS CloudFormation 템플릿을 생성합니다.
B. 고객을 위해 AWS Service Catalog 제품을 생성합니다.
C. 고객을 위해 AWS Systems Manager 템플릿을 생성합니다.
D. 고객을 위해 AWS Config 항목을 생성합니다.

B. 고객을 위해 AWS Service Catalog 제품을 생성합니다.

AWS Service Catalog는 고객이 셀프 서비스로 사용할 수 있는 솔루션과 도구 세트를 중앙에서 관리하고 배포할 수 있는 AWS 서비스입니다. 기업은 특정 애플리케이션, 인프라, 또는 기타 솔루션을 제품(Product)으로 정의하고, 이를 중앙에서 관리하면서 여러 고객이나 팀에 배포할 수 있습니다.

중앙 관리 및 배포
- AWS Service Catalog는 여러 고객이 표준화된 방식으로 쉽게 리소스를 배포하고 사용할 수 있도록 해줍니다. 회사는 고객에게 제공할 사전 정의된 도구와 솔루션을 제품 카탈로그로 관리할 수 있으며, 이를 통해 고객은 자신이 필요한 도구를 셀프 서비스 방식으로 사용하게 됩니다. 또한 Service Catalog는 회사가 제공하는 솔루션을 버전 관리하고, 배포된 리소스의 승인된 구성을 유지 관리할 수 있습니다.

솔루션과 도구 세트의 표준화
- Service Catalog를 통해 제공된 제품은 표준화된 템플릿(예: CloudFormation)을 기반으로 하므로, 모든 고객이 일관된 방식으로 솔루션을 사용할 수 있습니다. 또한 이를 통해 비용 절감과 리소스 관리의 효율성이 향상됩니다.

셀프 서비스 사용
- 고객은 제공된 제품 카탈로그에서 자신에게 필요한 솔루션을 선택하고, 몇 번의 클릭만으로 이를 AWS 환경에 배포할 수 있습니다. 이 방식은 고객이 직접 서비스 배포를 제어할 수 있으면서도, 회사는 중앙에서 관리할 수 있어 운영 오버헤드가 줄어듭니다.

---

■ Question #520

회사는 Amazon EC2 인스턴스에서 실행될 새로운 웹 애플리케이션을 설계 중입니다. 애플리케이션은 백엔드 데이터 저장소로 Amazon DynamoDB를 사용할 예정입니다. 애플리케이션 트래픽은 예측할 수 없으며, 회사는 데이터베이스에 대한 읽기 및 쓰기 처리량이 중간에서 높을 것으로 예상하고 있습니다. 회사는 애플리케이션 트래픽에 따라 확장할 수 있는 구성을 원합니다.

이 요구 사항을 가장 비용 효율적으로 충족할 DynamoDB 테이블 구성은 무엇입니까?

A. DynamoDB를 프로비저닝된 읽기 및 쓰기 용량으로 설정하고, DynamoDB Standard 테이블 클래스를 사용합니다. DynamoDB 자동 확장을 최대 정의된 용량으로 설정합니다.
B. DynamoDB를 온디맨드(on-demand) 모드로 설정하고, DynamoDB Standard 테이블 클래스를 사용합니다.
C. DynamoDB를 프로비저닝된 읽기 및 쓰기 용량으로 설정하고, DynamoDB Standard Infrequent Access (DynamoDB Standard-IA) 테이블 클래스를 사용합니다. DynamoDB 자동 확장을 최대 정의된 용량으로 설정합니다.
D. DynamoDB를 온디맨드 모드로 설정하고, DynamoDB Standard Infrequent Access (DynamoDB Standard-IA) 테이블 클래스를 사용합니다.

B. DynamoDB를 온디맨드(on-demand) 모드로 설정하고, DynamoDB Standard 테이블 클래스를 사용합니다.

트래픽 패턴 예측 불가능성
- 문제에서 애플리케이션 트래픽은 예측할 수 없다고 명시되어 있습니다. 트래픽이 예측 불가능한 경우에는 DynamoDB의 온디맨드(on-demand) 모드가 가장 적합한 선택입니다. 온디맨드(on-demand) 모드는 사용량에 따라 자동으로 읽기 및 쓰기 처리량을 조정하기 때문에 트래픽이 급격히 증가하거나 감소할 때에도 유연하게 대응할 수 있습니다.

읽기 및 쓰기 처리량 요구
- 중간에서 높은 읽기 및 쓰기 처리량을 기대하고 있기 때문에, 온디맨드(on-demand) 모드는 적은 트래픽일 때 비용을 절감하고, 트래픽이 많을 때도 성능을 유지할 수 있는 유연한 옵션입니다.
- 온디맨드(on-demand) 모드는 처리량을 동적으로 확장할 수 있어, 트래픽이 예측 불가능한 상황에서도 적절한 성능을 제공하며, 사용한 만큼만 요금이 부과됩니다.

DynamoDB Standard 테이블 클래스
- DynamoDB Standard는 일반적인 읽기 및 쓰기 빈도가 높은 워크로드에 적합한 테이블 클래스입니다. 이 클래스는 읽기와 쓰기가 빈번하게 발생할 것으로 예상되는 상황에서 비용 효율적입니다.
- 반면에 DynamoDB Standard-IA(Standard-Infrequent Access)는 주로 읽기/쓰기가 빈번하지 않은 워크로드에 적합하며, 자주 액세스되는 데이터를 처리할 때는 오히려 비용이 더 증가할 수 있습니다. 이 시나리오에서는 읽기와 쓰기 처리량이 중간서서 높을 것으로 예상되므로 Standard 테이블 클래스가 적합합니다.