[AWS-SAA] Examtopics 151~160
![[AWS-SAA] Examtopics 151~160](/assets/img/study_AWS/saa-co2_logo.png){kind=logo}
SAA Examtopics 151~160번 문제를 풀어보자.
Prob. 151
솔루션 설계자는 작업자와 파트너 간의 파일 교환을 가능하게 하는 온프레미스 시스템에 대한 완전 관리형 대안을 제공해야 합니다. 온프레미스 시스템, 원격 직원 및 외부 파트너에서 연결하는 작업자는 솔루션에 쉽게 액세스할 수 있어야 합니다.
어떤 솔루션이 이러한 기준을 충족합니까?
A. AWS Transfer for SFTP를 사용하여 Amazon S3로 파일을 전송하거나 내보냅니다.
B. 로컬 스토리지 및 대규모 데이터 전송에는 AWS Snowball Edge를 사용하십시오.
C. Amazon FSX를 사용하여 파일을 저장하고 전송하여 파일을 원격으로 사용할 수 있습니다.
D. AWS 스토리지 게이트웨이를 사용하여 파일을 저장하고 Amazon S3로 전송할 볼륨 게이트웨이를 생성합니다.
해설 : 쉽게 액세스할 수 있어야 함 문제 요점. 작업자와 파트너 간의 파일 교환을 가능. AWS 전송 제품군은 Amazon S3 또는 Amazon EFS로 직접 주고받는 파일 전송을 완벽하게 관리합니다. SFTP(Secure File Transfer Protocol), FTP(File Transfer Protocol over SSL) 및 FTP(File Transfer Protocol)를 지원하는 AWS 전송 제품군은 기존 인증 시스템과 통합하고 Amazon Route 53과 DNS 라우팅을 제공하여 사용자의 파일 전송 워크플로우를 AWS로 원활하게 마이그레이션할 수 있도록 지원합니다. 고객 및 파트너, 또는 이들의 애플리케이션에 대한 정보를 제공합니다. AWS 전송 제품군을 사용하면 기존 데이터 교환 프로세스를 보존하면서 Amazon S3 또는 Amazon EFS의 우수한 경제성, 데이터 내구성 및 보안을 활용할 수 있습니다. AWS Snow Family 콘솔에서 Snowball Edge Compute Optimized 또는 Snowball Edge Storage Optimized 중 원하는 디바이스를 선택. AWS Snowball Edge 스토리지 용량 또는 컴퓨팅 파워 제한 없이 테라바이트 용량의 데이터를 클라우드로 쉽게 마이그레이션/연결이 끊긴 외진 엣지 환경에서 애플리케이션 성능을 가속화하고 연결이 없거나 거의 안되는 상황에서 컴퓨팅 워크로드를 실행/연결이 끊긴 외진 엣지 환경에서 애플리케이션 성능을 가속화하고 연결이 없거나 거의 안되는 상황에서 컴퓨팅 워크로드를 실행. 페타바이트 규모의 데이터 마이그레이션/로컬에서 데이터 처리 및 분석/제조업용 데이터 최적화. Amazon FSX 모든 기능 포함 및 완전관리형/높은 가용성 및 보호/비용 효과성/하이브리드 활성화됨. 스토리지 게이트웨이 File Gateway에서 전송 Volume Gateway에서 백업 Tape Gateway에서 저장 A 정답 -> 파일을 이동할때 보통 S3/EFS/FSx를 사용하는데 서로 프로토콜이 다른거 같지만 S3는 FTP기반이라 적합. B 탈락 -> 장비를 받아 외부 데이터를 저장한 후 AWS로 보내여 S3로 마이그레이션해주지만 일회용인 재난 사진용으로 부적합. C 탈락 -> Amazon FSX는 지원하는 파일 시스템이 있고 원격으로 할 수 있는지 모르겠음 부적합. D 탈락 -> 볼륨 게이트웨이는 주로 백업용 데이터에 많이 사용하여 부적합.
정답 및 해설 보기
Answer : A
온프레미스 시스템에 대한 완전 관리형 대안을 제공.
온프레미스 시스템, 원격 직원 및 외부 파트너에서 연결하는 작업자는 액세스.
오프라인 데이터 또는 원격 스토리지를 클라우드로 신속하게 이동.
선적 레이블이 전자 잉크 화면에 자동으로 표시.
단 몇 번의 클릭으로 다양한 기능의 고성능 파일 시스템을 시작, 실행 및 크기 조정.
클라우드 내 다기능 고성능 파일 시스템을 쉽고 비용 효과적으로 시작, 실행 및 확장.
안정성과 보안성, 확장성 및 폭넓은 기능 세트로 광범위한 워크로드를 지원.
최신 AWS 컴퓨팅, 네트워킹 및 디스크 기술을 기반으로 구축되어 높은 성능과 낮은 TCO(총 소유 비용으로 자산의 매입 가격과 운용 원가를 더한 금액)를 제공.
하드웨어 프로비저닝, 패치 및 백업을 모두 처리하는 완전관리형 서비스이기 때문에 애플리케이션, 최종 사용자 및 비즈니스에 집중.
NetApp의 ONTAP/OpenZFS/Windows Server/Lustre파일 시스템 지원.
사실상 무제한의 클라우드 스토리지에 대한 온프레미스에게 액세스 권한을 제공. = 하이브리드 클라우드 스토리지 서비스/백업 툴.
로컬에서 데이터를 캐싱(하드웨어 게이트웨이 어플라이언스 장치).
데이터센터에 Appliance를 설치하고 데이터를 캐싱하여 Storage Gateway를 통해 S3에 백업을 하고, S3에 저장된 데이터로 분석.
Prob. 152
기업은 프라이빗 서브넷의 Amazon EC2 인스턴스에서 애플리케이션을 운영하고 있습니다. 프로그램은 Amazon S3에서 데이터를 저장하고 검색할 수 있어야 합니다. 비용을 절감하기 위해 회사는 AWS 리소스 구성을 최적화하려고 합니다.
비즈니스는 이 작업을 어떻게 수행해야 합니까?
A. NAT 게이트웨이를 배포하여 S3 버킷에 액세스합니다.
B. AWS 스토리지 게이트웨이를 배포하여 S3 버킷에 액세스합니다.
C. S3 게이트웨이 엔트포인트을 배포하여 S3 버킷에 액세스합니다.
D. S3 인터페이스 엔트포인트을 배포하여 S3 버킷에 액세스합니다.
해설 : AWS 리소스 구성을 최적화로 비용을 절감 문제 요점. 프라이빗 서브넷의 Amazon EC2 인스턴스. 게이트웨이 엔트포인트은 지원되는 서비스에 연결할 수 있도록 라우팅 테이블 내에서 사용되는 대상이며, 현재 게이트웨이 엔트포인트을 사용하는 지원되는 서비스는 Amazon S3 및 Dynamo뿐입니다. A 탈락 -> NAT 게이트웨이를 통해 VPC밖 리소스에 연결하기에 인터넷을 사용하여 부적합. B 탈락 -> 스토리지 게이트웨이는 온프레미스에서 클라우드의 스토리지를 사용할 때 하기에 부적합. C 정답 -> 게이트웨이 엔드포인트로 인터넷 회선보다 비용 절감 가능하고 구성을 최적화로 만들어서 적합. D 탈락 -> 인터페이스 엔드포인트는 서로 다른 VPC내의 인스턴스에 사설 링크를 할때 사용하여 부적합.
정답 및 해설 보기
Answer : C
Amazon S3에서 데이터를 저장하고 검색.
Prob. 153
AWS는 기업에서 사용자 데이터를 저장하는 데 사용합니다. 데이터는 지속적으로 액세스되며 작업 시간 동안 최대 사용량이 발생합니다. 액세스 패턴은 다양하며 일부 데이터는 액세스하지 않고 몇 개월이 걸립니다. 솔루션 설계자는 높은 수준의 가용성을 유지하면서 비용 효율적이고 내구성 있는 솔루션을 선택해야 합니다.
이 기준을 충족하는 스토리지 옵션은 무엇입니까?
A. Amazon S3 Standard
B. Amazon S3 Intelligent-Tiering
C. Amazon S3 Glacier Deep Archive
D. Amazon S3 One Zone-Infrequent Access (S3 One Zone-IA)
해설 : 높은 수준의 가용성을 유지하면서 비용 효율적이고 내구성 문제 요점. AWS는 사용자 데이터를 저장하는 데 사용. Intelligent-Tiering A 탈락 -> 기본적인 클래스로 트래픽이 많은 데이터에 적합하고 3개의 존에 가용성을 유지하지만 일부 데이터는 액세스하지 않기 때문에 비싼 스토리지 요금을 낼수 있어 부적합. B 정답 -> 모든 클래스 중에 가장 비용 효율적인 타입으로 데이터의 상황에 맞게 여러 계층화된 형태의 서비스로 적합. C 탈락 -> 글래시어 딥 아카이브는 데이터에 감사용으로 지속적으로 액세스되는 데이터에 부적합. D 탈락 -> 원 존은 하나의 스토리지를 사용하는 것인데 비용은 싸나 그만큼 가용성 부족하여 부적합.
정답 및 해설 보기
Answer : B
데이터는 지속적으로 액세스되며 작업 시간 동안 최대 사용량이 발생.
액세스 패턴은 다양하며 일부 데이터는 액세스하지 않고 몇 개월이 걸림.
• S3 Standard와 동일한 낮은 지연 시간 및 높은 처리 성능입니다.
• 월별 모니터링 및 자동 계층화 비용이 적습니다.
• 다음을 기반으로 두 액세스 계층 간에 개체를 자동으로 이동합니다.
액세스 패턴을 변경합니다.
• 여러 개체에 걸쳐 99.999999999%의 내구성을 제공하도록 설계되었습니다.
가용성 영역입니다.
• 전체 가용성 영역에 영향을 미치는 이벤트에 대해 탄력적으로 대처합니다.
• 특정 연도에 99.9%의 가용성을 제공하도록 설계되었습니다.
Prob. 154
기업은 Amazon EC2 인스턴스를 사용하여 레거시 데이터 처리 애플리케이션을 운영합니다. 데이터는 순차적으로 처리되지만 결과의 순서는 중요하지 않습니다. 응용 프로그램은 모놀리식 방식으로 설계되었습니다. 비즈니스가 증가하는 수요에 대응하여 애플리케이션을 확장할 수 있는 유일한 방법은 인스턴스 크기를 늘리는 것입니다. 조직의 엔지니어는 Amazon Elastic Container Service(Amazon ECS)를 사용하는 마이크로서비스 아키텍처를 사용하여 프로그램을 재설계하기로 결정했습니다.
솔루션 설계자는 마이크로서비스 간 통신을 위해 무엇을 제안해야 합니까?
A. Amazon SQS(Simple Queue Service) 대기열을 생성합니다. 데이터 생성자에 코드를 추가하고 데이터를 대기열로 보냅니다. 큐의 데이터를 처리하기 위해 데이터 소비자에 코드를 추가합니다.
B. Amazon Simple Notification Service(Amazon SNS) 항목을 만듭니다. 데이터 생성자에 코드를 추가하고 항목에 알림을 게시합니다. 데이터 소비자에 코드를 추가하여 주제에 가입합니다.
C. 메시지를 전달할 AWS Lambda 함수를 만듭니다. 데이터 생성자에 코드를 추가하여 데이터 개체로 람다 함수를 호출합니다. 데이터 소비자에 코드를 추가하여 람다 함수에서 전달되는 데이터 개체를 수신합니다.
D. Amazon DynamoDB 테이블을 생성합니다. DynamoDB 스트림을 사용합니다. 데이터 생성자에 코드를 추가하여 데이터를 테이블에 삽입합니다. 데이터 소비자에 코드를 추가하여 DynamoDB Streams API를 사용하여 새 테이블 항목을 탐지하고 데이터를 검색합니다.
해설 : 마이크로서비스 간 통신 문제 요점. Amazon EC2 인스턴스를 사용. “조사 결과의 순서는 관련이 없습니다.” - AWS 모범 사례인 애플리케이션을 분리할 수 있습니다. DynamoDB Streams A 정답 -> 서로 다른 서비스 간에 메시지를 잠시 저장하는 용도로 SQS를 사용하고 이것에 대한 추가 코드를 각각에 맞게 추가하여 비동기적으로 적합. B 탈락 -> SNS서비스는 단일성/단방향 서비스로 생성자 이벤트가 발생하면 항목에 알림을 게시하며 소비자는 이것을 주제에 가입(알람에 대응)하여 순서대로 처리하여 부적합. C 탈락 -> 생성자가 이벤트 발생하면 람다 함수를 호출하여 전달하고 소비자는 그것을 받아 처리하는데 순서대로 처리하여 부적합. D 탈락 -> 좋아 보이지만 주요 질문에서 약간 벗어난 주제이며 시간 순으로 처리하여 부적합.
정답 및 해설 보기
Answer : A
기존에 운영하던 혹은 구형 시스템에서 생성 저장된 데이터 처리.
데이터는 순차적으로 처리되지만 결과의 순서는 중요하지 않음.
모놀리식 아키텍처는 모든 비즈니스 관련 사항을 함께 결합하는 하나의 코드 베이스를 갖춘 대규모의 단일 컴퓨팅 네트워크.
증가하는 수요에 대응하여 애플리케이션을 확장 = 인스턴스 크기를 늘리는 것.
Amazon ECS를 사용하는 마이크로서비스 아키텍처를 사용.
모든 변경 사항(put, update, delete)를 24시간 언제든지 stream record로서 실시간으로 스트리밍으로 받음.
DynamoDB Streams는 DynamoDB 테이블에서 시간 순서에 따라 항목 수준 수정을 캡처하고 이 정보를 최대 24시간 동안 로그에 저장.
로그와 데이터 항목은 변경 전후 거의 실시간으로 나타나므로 애플리케이션에서 이러한 로그와 데이터에 액세스.
유휴 시 암호화는 DynamoDB Streams의 데이터를 암호화.
변경 사항에 대한 정렬된 정보 흐름.
Prob. 155
한 기업이 클래식 애플리케이션을 AWS로 마이그레이션하는 것을 고려하고 있습니다. 현재 애플리케이션은 NFS를 통해 온프레미스 스토리지 시스템과 통신합니다. NFS 이외의 다른 통신 프로토콜을 사용하여 이 기능을 수행하도록 프로그램을 변경할 수 없습니다.
솔루션 설계자는 마이그레이션 후 사용을 위해 어떤 스토리지 솔루션을 제안해야 합니까?
A. AWS DataSync
B. Amazon Elastic Block Store (Amazon EBS)
C. Amazon Elastic File System (Amazon EFS)
D. Amazon EMR File System (Amazon EMRFS)
해설 : NFS 이외의 다른 통신 프로토콜을 변경할 수 없음 문제 요점. AWS로 마이그레이션하는 것을 고려. Amazon EFS(Amazon Elastic File System)는 스토리지를 프로비저닝하거나 관리하지 않고도 파일 데이터를 공유할 수 있는 단순하고 서버 없는 탄력적인 파일 시스템을 제공합니다. AWS 클라우드 서비스 및 사내 리소스와 함께 사용할 수 있으며, 애플리케이션을 중단하지 않고 온디맨드 방식으로 페타바이트로 확장할 수 있도록 설계되었습니다. Amazon EFS를 사용하면 파일을 추가 및 제거할 때 파일 시스템을 자동으로 확장 및 축소할 수 있으므로 성장에 맞춰 용량을 프로비저닝하고 관리할 필요가 없습니다. 보통 스토리지 게이트웨이로 온프레미스와 AWS 스토리지 서비스 사이에 연동으로 파일을 이동하는 파일 시스템으로 S3/EFS/FSx 서비스가 있으며 FTP/NFS/SMB 등을 제공함. AWS DataSync Amazon EMRFS EMRFS가 Amazon S3에 쓰는 객체를 암호화하고, EMRFS가 Amazon S3의 암호화된 객체와 함께 작동. Amazon S3는 모든 GET, PUT 및 LIST 작업에 대해 강력한 읽기 후 쓰기 일관성을 제공. A 탈락 -> 온프레미스의 데이터를 사용하기 위해서가 아닌 데이터를 AWS로 이동하기 위한 서비스로 부적합. B 탈락 -> EBS는 스토리지에 대한 서비스로 연결과 다른 주제라서 부적합. C 정답 -> EFS는 NFS를 지원하는 서비스로 파일을 연동하거나 이동할때 해당 시스템으로 S3에 저장하거나 데이터센터에 연결하여 적합. D 탈락 -> EMR파일 시스템은 하둡파일 시스템을 구현하기 위한 AWS 서비스로 부적합.
정답 및 해설 보기
Answer : C
NFS를 통해 온프레미스 스토리지 시스템과 통신.
온프레미스와 AWS 스토리지 서비스 사이에서 데이터 이동을 자동화 및 가속화.
AWS 스토리지/온프레미스 -> AWS 스토리지 이동.
Agent를 사용 - 동일한 AWS 계정에서 데이터를 전송할 땐 사용하지 않음 = 다른 계정으로 옮길때는 필요(주로 EC2에 설치).
데이터 -> NFS, SMB, HDFS, S3 API지원 -> S3, EFS, FSx, SnowCone.
필터 적용 가능/스케줄 설정 가능/데이터 무결성 검사/동시에 여러 소스에서 하나의 대상으로 전송 가능(통합)/전송 실패시 재전송.
EMR 파일 시스템 (EMRFS) 은 모든 Amazon EMR 클러스터가 Amazon EMR에서 Amazon S3로 직접 일반 파일을 읽고 쓰는 데 사용하는 HDFS(하둡) 구현.
EMRFS는 하둡과 함께 사용할 영구 데이터를 Amazon S3에 저장하는 편리함을 제공하는 동시에 데이터 암호화와 같은 기능도 제공.
보안 구성을 사용하여 다른 암호화 설정과 함께 Amazon S3에서 EMRFS 객체에 대한 암호화를 설정.
EMRFS를 사용하여 작성한 내용은 성능에 영향을 미치지 않고 Amazon S3에서 읽게 되는 내용.
클러스터 사용자, 그룹 또는 Amazon S3의 EMRFS 데이터 위치에 따라 Amazon S3에 대한 EMRFS 요청에 서로 다른 IAM 역할을 사용.
Prob. 156
기업은 확장성 및 가용성 요구 사항을 충족하기 위해 컨테이너에서 미션 크리티컬 앱을 실행하려고 합니다. 회사는 오히려 주요 애플리케이션 유지 관리에 집중할 것입니다. 회사는 컨테이너화된 워크로드의 기본 인프라 프로비저닝 및 유지 관리에 대한 책임을 원하지 않습니다.
이러한 기준을 충족하기 위해 솔루션 설계자는 어떤 조치를 취해야 합니까?
A. Amazon EC2 인스턴스를 사용하고 인스턴스에 Docker를 설치합니다.
B. Amazon EC2 작업자 노드에서 Amazon ECS(Amazon Elastic Container Service)를 사용합니다.
C. AWS Fargate에서 Amazon Elastic Container Service(Amazon ECS)를 사용합니다.
D. Amazon ECS(Amazon Elastic Container Service)에 최적화된 AMI(Amazon 시스템 이미지)의 Amazon EC2 인스턴스를 사용합니다.
해설 : 기본 인프라 프로비저닝 및 유지 관리에 대한 책임 없음 문제 요점. 확장성 및 가용성 요구 사항을 충족하기 위해 컨테이너. EC2로 서버를 관리해야하나 서버리스(Fargate)로 관리를 안해도 돼냐의 차이. A, 탈락 -> Docker는 컨테이너화 시스템인데 이것을 EC2에 설치하기 때문에 관리해줘야 하여 부적합. B 탈락 -> Amazon ECS는 컨테이너화 시스템인데 EC2를 작업자 노드 선택하여 배포하여 관리해줘야해서 부적합. C 정답 -> AWS Fargate는 서버리스 엔진으로 AWS가 관리하기 때문에 관리를 하지 않고도 컨테이너 시스템을 사용하여 적합. D 탈락 -> EC2자체를 AMI으로 ECS에 최적화된 서버를 만드는데 관리해줘야 하여 부적합.
정답 및 해설 보기
Answer : C
유지 관리에 집중.
컨테이너화된 워크로드.
AMI는 EC2를 여러 형태로 만듬 -> NAT 게이트웨이, ECS 등…
Prob. 157
기업은 이벤트 데이터를 생성하는 서비스를 운영합니다. 회사는 이벤트 데이터를 수신하는 대로 처리하기 위해 AWS를 사용하고자 합니다. 데이터는 처리 중에 보존되어야 하는 특정 순서로 구조화됩니다. 회사는 가능한 가장 낮은 운영 비용으로 솔루션을 배포하기를 원합니다.
솔루션 아키텍트가 이 작업을 어떻게 수행합니까?
A. 메시지를 보관할 Amazon SQS(Amazon Simple Queue Service) FIFO 대기열을 만듭니다. 대기열에서 메시지를 처리하도록 AWS 람다 기능을 설정합니다.
B. 처리할 페이로드를 포함하는 통지를 배달하는 Amazon SNS(Amazon Simple Notification Service) 항목을 만듭니다. AWS 람다 기능을 구독자로 구성합니다.
C. 메시지를 보관할 Amazon SQS(Simple Queue Service) 표준 대기열을 만듭니다. 대기열의 메시지를 독립적으로 처리하도록 AWS 람다 기능을 설정합니다.
D. 처리할 페이로드를 포함하는 통지를 배달하는 Amazon SNS(Amazon Simple Notification Service) 항목을 만듭니다. Amazon SQS(Simple Queue Service) 대기열을 구독자로 구성합니다.
해설 : 가능한 가장 낮은 운영 비용 문제 요점. 이벤트 데이터를 생성하는 서비스를 운영. FIFO(First-In-First-Out) 대기열은 작업 및 이벤트의 순서가 중요하거나 중복을 허용할 수 없는 경우 애플리케이션 간의 메시징을 향상시키도록 설계되었습니다. FIFO 대기열을 사용할 수 있는 상황의 예는 다음과 같습니다. A 정답 -> 이벤트 데이터를 생성하고 SQS FIFO로 보내면 순서대로 구조화하고 AWS의 람다 함수로 처리하며 이 서비스는 비용이 낮아 적합. B 탈락 -> SNS는 항목에 대한 이벤트(생성된 데이터)를 구독자(람다 함수)에게 알림을 보내는데 순서 없이 보내여 부적합. C 탈락 -> 표준 대기열은 순서 없이 사용하여 부적합. D 탈락 -> SNS로 SQS에 알림을 주는데 처리에 대한 부분이 없어 부적합.
정답 및 해설 보기
Answer : A
이벤트 데이터를 수신하는 대로 처리하기 위해 AWS를 사용.
특정 순서로 구조화.
사용자가 입력한 명령이 올바른 순서로 실행되는지 확인합니다.
올바른 순서로 가격 수정 사항을 전송하여 올바른 제품 가격을 표시합니다.
학생이 계정을 등록하기 전에 과정에 등록하지 못하도록 합니다.
Prob. 158
비즈니스 데이터베이스는 Amazon Aurora MySQL DB 클러스터의 us-east-1 리전에서 호스팅됩니다. 데이터베이스 크기는 약 4TB입니다. 회사의 재해 복구 계획은 us-west-2 지역을 포함하도록 확장되어야 합니다. 회사는 15분 RTO(복구 시간 목표) 내에 us-west-2로 장애 조치할 수 있어야 합니다.
솔루션 설계자는 이러한 요구 사항을 충족하기 위해 어떤 권장 사항을 제시해야 합니까?
A. us-east-1 및 us-west-2에 Multi-Region Aurora MySQL DB 클러스터를 생성합니다. Amazon Route 53 상태 점검을 사용하여 us-east-1을 모니터링하고 실패 시 us-west-2로 페일오버합니다.
B. us-east-1에서 DB 클러스터의 스냅샷을 만듭니다. 리소스 이벤트를 수신할 때 AWS Lamda 함수를 호출하는 Amazon EventBridge(Amazon CloudWatch Events) 규칙을 구성합니다. 장애가 감지되면 스냅샷을 us-west-2로 복사하고 us-west-2에서 스냅샷을 복원하도록 람다 기능을 구성합니다.
C. AWS CloudFormation 스크립트를 생성하여 오류 발생 시 us-west-2에 다른 Aurora MySQL DB 클러스터를 생성합니다. 리소스 이벤트를 수신할 때 AWS Lamda 함수를 호출하는 Amazon EventBridge(Amazon CloudWatch Events) 규칙을 구성합니다. 장애가 감지되면 us-west-2에 AWS CloudFormation 스택을 배포하도록 Lambda 기능을 구성합니다.
D. 기본 DB 클러스터가 us-east-1에 있고 보조 DB 클러스터가 us-west-2에 있는 Aurora 글로벌 데이터베이스로 데이터베이스를 재생성합니다. 리소스 이벤트를 수신할 때 AWS Lamda 함수를 호출하는 Amazon EventBridge(Amazon CloudWatch Events) 규칙을 구성합니다. 장애가 감지되면 us-west-2에서 DB 클러스터를 승격하도록 람다 기능을 구성합니다.
해설 : us-west-2로 장애 조치 문제 요점. Amazon Aurora MySQL DB 클러스터의 us-east-1 리전에서 호스팅. RPO(Recovery Point Objective) - 재해 발생 이전의 알려진 상태로의 “롤백” 또는 동기화 목표 상태를 의미합니다. 즉, RPO는 중단된 복구 가능한 응용 프로그램에서 처리를 재개할 수 있는 재해 이후 복구 지점. RTO (Recovery Time Objective) - 복구에 걸리는 시간에 대한 목표입니다. 예를 들어 1시에 백업을 한다고 가정하면 6시에 장애가 나면 RPO는 5시간입니다. 복구에 걸리는 시간이 3시간이어서 9시에 복구가 완료되었다고 한다면 RTO는 3시간임. 여러 Amazon 영역에서 고가용성을 위해 Aurora 글로벌 데이터베이스를 설정할 수 있습니다. 각 Aurora 글로벌 데이터베이스는 여러 Amazon 영역에 걸쳐 있으므로 지연 시간이 짧은 글로벌 읽기 및 Amazon 영역 전체의 운영 중단 시 재해 복구가 가능합니다. Aurora는 기본 Amazon 영역에서 각 보조 영역으로 모든 데이터 및 업데이트 복제를 자동으로 처리합니다. -> 답 A의 주장. 그에 반해 A는 멀티 리전으로 만들고 route53에서만 설정하면 운영노력도 적게들고 딱히 부하도 많은거 같지 않습니다. AWS CloudFormation 멀티 리전은 결국 Aurora 글로벌 데이터베이스의 기술에서 나온 것임. A 탈락 -> 멀티 리전으로 장애시 다른 지역의 DB로 복구 가능하고 Route 53을 수동 작업으로 람다 함수로 승격한 보조DB에 연결을 설정하고 상태 점검을 모니터링한다는 말이 없어서 부적합. B 탈락 -> 스냅샷을 만들어 놓고 장애 발생시 그때야 다른 리전으로 옮겨서 실행하면 오랜 시간이 걸려서 부적합. C 탈락 -> 이것은 스크립트(복제 설정 코드)로 다른 리전에 인프라를 구성 및 관리해주는 것 같은데 데이터를 옮겨서 실행해야하면 오랜 시간이 걸려서 부적합. D 정답 -> Aurora의 글로벌 데이터베이스 기술로 데이터베이스를 다른 리전에 복제하여 보조 읽기 전용으로 사용하며 마스터(기본)에 문제가 생길 시 보조를 람다 함수로 승격시키고 쓰기 기능을 받아 적합.
정답 및 해설 보기
Answer : D (or A?)
재해 복구 계획은 us-west-2 지역을 포함하도록 확장.
15분 RTO(복구 시간 목표) 내 장애 조치.
제 생각에는 A인것 같습니다.
D에 나와있는 마스터 승격은 굳이 람다가 없어도 되는것이고, db데이터를 넣을때마다 람다를 호출해서 마스터를 확인하는건 좋은 방법이 아닌것 같습니다.
링크https://aws.amazon.com/ko/blogs/database/deploy-multi-region-amazon-aurora-applications-with-a-failover-blueprint/
코드형 인프라로 클라우드 프로비저닝 가속화로 인프라를 코드로 처리하여 AWS 및 서드 파티 리소스를 모델링, 프로비저닝 및 관리.
AWS CloudFormation은 AWS 리소스를 모델링하고 설정하여 리소스 관리 시간을 줄이고 AWS에서 실행되는 애플리케이션에 더 많은 시간을 사용하도록 해 주는 서비스.
필요한 모든 AWS 리소스를 설명하는 템플릿을 생성하면 CloudFormation이 해당 리소스의 프로비저닝과 구성을 담당.
인프라 관리 간소화/신속하게 인프라 복제/인프라 변경 사항을 쉽게 제어 및 추적.
Prob. 159
기업에서 거의 실시간 스트리밍 데이터를 처리하는 애플리케이션을 설치하고 있습니다. 워크로드는 Amazon EC2 인스턴스에서 실행됩니다. 네트워크 아키텍처는 노드 간의 대기 시간이 가능한 한 최소화되도록 구성되어야 합니다.
이러한 요구 사항에 적합한 네트워크 솔루션 조합은 무엇입니까? (2개를 선택하세요.)
A. 각 EC2 인스턴스에서 고급(enhanced) 네트워킹을 사용하도록 설정하고 구성합니다.
B. EC2 인스턴스를 별도의 계정으로 그룹화합니다.
C. 클러스터 배치 그룹에서 EC2 인스턴스를 실행합니다.
D. 각 EC2 인스턴스에 여러 개의 탄력적인 네트워크 인터페이스를 연결합니다.
E. Amazon EBS(Amazon Elastic Block Store)에 최적화된 인스턴스 유형을 사용합니다.
해설 : 네트워크 아키텍처는 노드 간의 대기 시간이 가능한 한 최소화 문제 요점. 거의 실시간 스트리밍 데이터를 처리. D에 ENI는 네트워크 성능을 올리지 않는다. C에 클러스터 배치 그룹은 낮은 네트워크 지연 시간과 높은 네트워크 처리량의 이점을 제공하는 단일 가용성 영역 내의 인스턴스 논리적 그룹입니다. 향상된 네트워킹은 더 높은 대역폭, 더 높은 초당 패킷(PPS) 성능 및 더 낮은 인스턴스 간 지연 시간을 일관되게 제공합니다. A 정답 -> 고급 네트워킹으로 설정하여 노드 간의 대기 시간을 줄여서 적합. B 탈락 -> 계정을 그룹화해도 보안이나 접근에 관한 것으로 논리적인 것이지 물리적으론 네트워크의 대기 시간에 영향이 없어 부적합. C 정답 -> 클러스터 배치 그룹은 단일 가용성 영역내에 논리적인 그룹화된 노드 간의 네트워크 성능을 올려서 적합. D 탈락 -> ENI는 네트워킹 성능이 아니라 다양한 IP를 연결할 수 있게 하고 각각의 성능은 동일하여 부적합. E 탈락 -> EBS는 스토리지에 대한 것으로 네트워크와는 무관하여 부적합.
정답 및 해설 보기
Answer : A, C
워크로드는 Amazon EC2 인스턴스에서 실행.
Prob. 160
기업은 시장 분석 관리를 제3자 파트너에게 아웃소싱합니다. 공급업체는 회사 계정의 리소스에 대한 제한된 프로그래밍 방식 액세스를 요구합니다. 허용 가능한 액세스를 보장하기 위해 필요한 모든 정책이 수립되었습니다.
공급업체에 계정에 대한 가장 안전한 액세스를 제공하는 새로운 구성 요소는 무엇입니까?
A. IAM 사용자를 만듭니다.
B. 서비스 제어 정책(SCP)을 구현합니다.
C. 외부 ID와 교차 계정 역할(cross-account role)을 사용합니다.
D. SSO(Single Sign-On) ID 제공자를 구성합니다.
해설 : 공급업체에 계정에 대한 가장 안전한 액세스 문제 요점. 시장 분석 관리를 제3자 파트너에게 아웃소싱(맡김-공급업체). A 탈락 -> 다른 IAM 사용자가 아닌 다른 AWS 계정에 대한 액세스 권한을 부여해야 합니다(같은 계정에서) 부적합. B 탈락 -> SCP는 조직에 속한 모든 AWS 계정에 적용되는 조직 차원의 정책이라 부적합. C 정답 -> 계정 간에 공유할 “IAM 역할”이 필요하여 적합. D 탈락 -> SSO는 한 번의 인증으로 다른 서비스까지 액세스까지 제공하는 것이라 부적합.
정답 및 해설 보기
Answer : C
공급업체는 회사 계정의 리소스에 대한 제한된 프로그래밍 방식 액세스를 요구.
필요한 모든 정책이 수립.
- Ref
