[Associate SAA-C03] - dump 정리 731 ~ 770

클라우드/AWS

[Associate SAA-C03] - dump 정리 731 ~ 770

코딩하는 도람쥐 2024. 10. 15. 14:25

728x90

731
DynamoDB 테이블을 저장소로 사용하는 애플리케이션 + 테이블에 대한 많은 요청이 최신 데이터를 반환하지 않는다는 것 발견 + 회사의 사용자는 데이터베이스 성능과 관련된 다른 문제는 보고 X + 지연 시간은 허용 범위에 있음

C. 테이블에 대해 강력한 일관성을 갖춘 읽기를 요청합니다

* DynamoDB: 최종 일관성, 강력한 일관성 제공
- 최종일관성: 최근에 완료된 쓰기 작업의 결과가 응답에 반영되지 않을 수 있음
- 강력한 일관성: 성공한 모든 이전 쓰기 작업의 업데이트가 반영된 최신 데이터가 포함된 응답을 반환

732
RDS 데이터베이스가 있는 EC2 인스턴스에 애플리케이션 배포 + 최소 권한 원칙을 사용하여 데이터베이스 액세스 자격증명 구성 → 보안 팀은 SQL 주입 및 기타 웹 기반 공격으로부터 애플리케이션 데이터베이스를 보호 + 최소한의 운영 오버헤드

B. AWS WAF를 사용하여 애플리케이션을 보호합니다. RDS 매개변수 그룹을 사용하여 보안 설정을 구성합니다.

733
Organizations의 조직에 속하는 AWS 계정에서 애플리케이션 실행 + Aurora PostgreSQL 데이터베이스에서 애플리케이션 실행 → 악의적인 활동 방지 + DB의 비정상적인 실패 및 불완전한 로그인 식별 + 가장 운영적으로 효율

B. 조직의 구성원 계정에 대해 Amazon GuardDuty에서 Amazon RDS 보호 기능을 활성화합니다.

* Amazon GuardDuty: 악성 활동과 무단 동작을 지속적으로 모니터링하여 Amazon Web Services 계정, 워크로드 및 Amazon S3에 저장된 데이터를 보호하는 위협 탐지 서비스

734
자사 기업 데이터 센터에서 us-east-1 지역의 자사 VPC로 Direct Connect 연결 + 최근 온프레미스 데이터 센터와 eu-west-2 지역 간에 여러 개의 VPC와 Direct Connect 연결을 사용하는 회사를 인수 → 두 지역과 데이터 센터 간의 연결이 필요 + 운영 오버헤드를 줄이고 확장 가능한 솔루션

D. 기존 Direct Connect 연결을 Direct Connect 게이트웨이에 연결합니다. 각 지역의 VPC의 가상 프라이빗 게이트웨이에서 Direct Connect 게이트웨이로 트래픽을 라우팅합니다.

⇒ 여러 다른 지역에 있는 하나 이상의 VPC에 Direct Connect를 설정하려면 Direct Connect Gateway 사용

735
백엔드 프로세서에 점수 업데이트를 스트리밍한 다음 리더보드에 결과를 게시하는 모바일 게임 개발 + 대규모 트래픽 급증을 처리, 수신 순서대로 모바일 게임 업데이트 처리, 처리된 업데이트를 고가용성 데이터베이스에 저장할 수 있는 솔루션 설계 + 필요한 관리 오버헤드 최소화

A. Amazon Kinesis Data Streams에 점수 업데이트를 푸시합니다. AWS Lambda로 Kinesis Data Streams에서 업데이트를 처리합니다. 처리된 업데이트를 Amazon DynamoDB에 저장합니다.

스트리밍 + 수신된 순서대로 + 고가용성 데이터베이스 + 최소한의 운영 오버헤드
⇒ Kinesis Data Streams + DynamoDB + Lambda

* DynamoDB: 높은 가용성과 확장성을 제공하는 NOSQL 데이터베이스 서비스 + 빠른 읽기/쓰기를 지원하므로 수 많은 이미지 업데이트 빠르게 처리 가능

736
us-west-2 지역에 배포된 애플리케이션이 있는 계정 + 로그는 각 계정의 S3 버킷에 저장 → 단일 S3 버킷을 사용하는 중앙 집중식 로그 분석 솔루션을 구축하려고함 + 로그는 us-west-2를 떠나서는 안되고 최소한의 운영 오버헤드 + 가장 비용 효율적

B. S3 Same-Region Replication을 사용하여 S3 버킷에서 us-west-2의 다른 S3 버킷으로 로그를 복제합니다. 이 S3 버킷을 로그 분석에 사용합니다.

* S3 Same-Region Replication(SRR): 동일한 AWS 리전 내에서 S3 버킷 간 데이터를 복제
→ 데이터가 그 리전을 떠나지 않음 + 동일한 AWS 리전 내에서 대상 스토리지 클래스와 동일한 이중화를 갖는 다른 S3 객체 사본을 생성 → 다른 S3 버킷에서 로그를 자동으로 집계

737
전 세계 학생들에게 주문형(온디맨드) 교육 비디오를 제공하는 애플리케이션 + 권한이 있는 콘텐츠 개발자가 비디오를 업로드할 수 있도록 허용 + 데이터는 us-east-2 지역의 S3 버킷에 저장 → eu-west-2 지역에 S3 버킷을, ap-southeast-1 지역에 S3 버킷을 생성 + 데이터를 새로운 S3 버킷에 복제하려함 + 비디오를 업로드 하는 개발자와 eu-west-2와 ap-southeast-1 근처에서 비디오를 스트리밍하는 학생의 대기시간을 최소화

C. 3개 지역에 모두 있는 S3 버킷 간에 양방향 복제를 구성합니다.

E. S3 다중 지역 액세스 포인트를 만듭니다. 비디오 스트리밍 및 업로드를 위해 다중 지역 액세스 포인트의 Amazon 리소스 이름(ARN)을 사용하도록 애플리케이션을 수정합니다.

* S3 양방향 복제: 3개의 리전 모두 복제를 동기화 상태로 유지하기
* 다중 지역 액세스 포인트: 여러 지역에 흩어져 있는 분산된 S3 리소스를 통합하여 서로 다른 지역 간에 빠르고 안정적인 데이터 전송사용자의 지리적 위치에 따라 가장 가까운 버킷으로 트래픽을 자동으로 라우팅 → 비디오 스트리밍 지연 시간이 최소화

738
회사에 새로운 모바일 앱 + 전 세계 어디에서나 사용자는 선택한 주제에 대한 지역 뉴스를 볼 수 있음 + 앱 내부에서 사진과 비디오도 게시 가능 → 종종 콘텐츠 게시 후 처음 몇분 동안 콘텐츠에 액세스 + 새 콘텐츠가 기존 콘텐츠를 빠르게 대체한 후 기존 콘텐츠는 사라짐 + 뉴스의 지역적 특성으로 인해 사용자는 업로드된 AWS 리전 내에서 콘텐츠의 90%를 소비 + 콘텐츠 업로드에 대한 가장 낮은 지연 시간

B. Amazon S3에 콘텐츠를 업로드하고 저장합니다. 업로드에는 S3 Transfer Acceleration을 사용합니다.

⇒ CloudFront: 업로드용이 아닌 읽기용 옵션
* S3 Transfer Acceleration: 업로드 및 다운로드 지연을 최소화하고 성능을 극대화하기 위한 비용 효율적인 솔루션

739
서버리스 아키텍처를 사용하는 새로운 애플리케이션 구축 + 들어오는 요청을 관리하기 위한 API Gateway REST API와 Lambda 함수로 구성 → API Gateway REST API에서 수신한 메시지를 여러 대상 Lambda 함수로 보내 처리할 수 있는 서비스를 추가하려고 함 + 대상 Lambda 함수가 함수에 필요한 메시지만 수신할 수 있는 메시지 필터링을 제공 해야함 + 최소한의 운영 오버헤드

A. API Gateway REST API에서 Amazon Simple Notification Service(Amazon SNS) 주제로 요청을 보냅니다. Amazon Simple Queue Service(Amazon SQS) 대기열을 SNS 주제에 구독합니다. 대상 Lambda 함수를 구성하여 다양한 SQS 대기열을 폴링합니다.

⇒ SNS : 메시지 필터링

# 740
수백만 개의 보관 파일을 S3로 마이그레이션 + 고객이 제공한 키를 사용하여 모든 보관 데이터를 암호화 구현 + 기존의 암호화되지 않은 객체와 미래의 객체를 암호화하는 솔루션

A. Amazon S3 인벤토리 보고서를 필터링하여 암호화되지 않은 객체 목록을 만듭니다. S3 일괄 작업 작업을 구성하여 고객 제공 키(SSE-C)를 사용하여 서버 측 암호화로 목록의 객체를 암호화합니다. S3 기본 암호화 기능을 구성하여 고객 제공 키(SSE-C)를 사용하여 서버 측 암호화를 사용합니다.

⇒ S3 인벤토리 기능을 사용하여 암호화되지 않은 객체를 나열 가능 +S3 인벤토리 목록에 “암호화 상태” 필드 존재, 이를 이용하여 암호화되지 않은 객체 필터링

AWS Batch(일괄 작업): 기존에 암호화되지 않은 S3 객체 암호화하기 위해 사용 가능

S3 기본 암호화 기능: 향후 업로드 될 모든 객체가 고객 제공키를 사용해 자동으로 암호화되도록 보장.

741

회사의 도메인 이름 레코드를 호스팅하는 DNS 공급자가 AWS에서 실행되는 웹사이트에 대한 서비스 중단을 경험 → 보다 탄력적인 관리형 DNS 서비스로 마이그레이션 + DNS 호스팅 서비스를 빠르게 마이그레이션

A. 도메인 이름에 대한 Amazon Route 53 퍼블릭 호스팅 존을 만듭니다. 이전 공급자가 호스팅한 도메인 레코드가 포함된 존 파일을 가져옵니다.

742
RDS 데이터베이스에 연결되는 AWS에서 애플리케이션 구축 → 애플리케이션 구성을 관리하고 데이터베이스 및 기타 서비스에 대한 자격 증명을 안전하게 저장하고 검색 + 최소한의 관리 오버헤드

A. AWS AppConfig를 사용하여 애플리케이션 구성을 저장하고 관리합니다. AWS Secrets Manager를 사용하여 자격 증명을 저장하고 검색합니다.

* AWS AppConfig 캐싱전략: 애플리케이션의 구성을 배포하고 관리하는데 도움이 되는 서비스
자격 증명 순환 + 최소 운영 오버헤드 ⇒ AWS Secrets Manager 사용

743
RDS MYSQL 인스턴스 통신 중 전송중인 모든 데이터 암호화 + KMS를 통한 휴면 암호화는 활성화, 전송 중인 데이터는 활성화 X

(휴면 암호화: 미사용 상태로 암호화)

전송중인 데이터의 암호화 활성화 ⇒ 전송 중 데이터를 보호하기 위해 SSL/TLS를 사용

D. AWS에서 제공하는 루트 인증서를 다운로드합니다. RDS 인스턴스에 대한 모든 연결에서 인증서를 제공합니다.

⇒ 루트 인증서 사용: 신뢰할 수 있는 인증서를 사용하여 SSL/TLS 연결을 설정하는 것으로 안전

744
회사가 ELB 뒤의 EC2 인스턴스에서 실행되는 새로운 웹 서비스 설계 → 많은 웹 서비스 클라이언트는 방화벽에서 허가된 IP 주소에만 도달할 수 있음

A. 연관된 Elastic IP 주소가 있는 네트워크 로드 밸런서.

⇒ Elastic IP: 고정된 공용 IP 주소 → 클라이언트는 해당 IP 주소를 통해 항상 LB에 접근 가능
NLB는 Elastic IP 주소를 사용하여 고정된 IP 주소 유지 가능

Application Load Balancer: Elastic ip 할당 불가 → 동적 IP할당, 도메인 이름을 통해서만 접근 가능

745
새로운 AWS 계정 + 새로 프로비저닝, 기본 설정은 변경 X → 계정 루트 사용자의 보안에 대해 우려

B. 일상적인 관리 작업을 위한 IAM 사용자를 만듭니다. 루트 사용자에 대해 다중 요소 인증을 활성화합니다

⇒ 루트 사용자에 대해 다중 요소 인증(MFA)을 활성화하면 비밀번호 외에도 추가적인 인증 수단(예: 인증 앱, 하드웨어 토큰)을 통해 보안을 강화

⇒ 모범 사례: 필요하지 않은 작업에는 AWS 계정 루트 사용자를 사용 X

대신 관리자 액세스가 필요한 각 사람에 대해 새 IAM 사용자 생성

746
거의 실시간으로 스트리밍 데이터를 처리하는 애플리케이션 배포 + 워크로드에 EC2 인스턴스를 사용할 계획 → 노드 간에 가능한 가장 낮은 지연 시간 제공

A. 각 EC2 인스턴스에서 향상된 네트워킹을 활성화하고 구성합니다.

C. 클러스터 배치 그룹에서 EC2 인스턴스를 실행합니다.

⇒ 향상된 네트워킹 활성화: 네트워킹은 더 높은 대역폭, 더 높은 초당 패킷(PPS) 성능, 더 낮은 인스턴스 간 대기 시간을 제공
⇒ 클러스터 배치 그룹: 클러스터 배치 그룹은 단일 가용성 영역 내의 인스턴스를 논리적으로 그룹화, 이 구성은 낮은 네트워크 대기 시간, 높은 네트워크 처리량

747
두 개의 데이터 센터를 폐쇄하고 100TB가 넘는 데이터를 AWS로 마이그레이션 + 대부분의 데이터는 비정형, 파일 스토리지는 여러 공급업체의 SMB 기반 스토리지 유형으로 구성 → 마이그레이션 후 데이터 액세스하기 위해 애플리케이션을 변경하고 싶지 않음 +
최소한의 운영 오버헤드

C. AWS DataSync를 사용하여 데이터를 Amazon FSx for Windows File Server로 마이그레이션합니다.

⇒ SMB + 완전관리 ⇒ 윈도우용 Fsx

* Fsx는 Windows 파일 시스템 기능과 네트워크를 통해 파일 저장소에 액세스하기 위한 SMB 프로토콜을 기본적으로 지원

* DataSync: 데이터를 안전하고 효율적으로 마이그레이션.

* FSx for Lustre: 고성능 컴퓨팅에 적합한 파일 시스템

748
Organizations에서 조직을 사용하여 애플리케이션이 포함된 AWS 계정 관리 + 조직에 전담 모니터링 멤버 계정을 설정 → CloudWatch를 사용하여 계정 전체에서 관찰 데이터를 쿼리하고 시각화

여러 AWS 계정에서 CloudWatch 데이터를 중앙에서 모니터링하고 시각화 ⇒ 교차 계정 모니터링

A. 모니터링 계정에 대해 CloudWatch 교차 계정 관찰 기능을 활성화합니다. 모니터링 계정에서 제공하는 AWS CloudFormation 템플릿을 각 AWS 계정에 배포하여 모니터링 계정과 데이터를 공유합니다.

⇒ Amazon CloudWatch 교차 계정 관찰 기능을 사용하면 여러 계정에 걸쳐 있는 데이터를 모니터링하고 문제를 해결
CloudFormation 템플릿 ⇒ 교차 계정 관찰을 위한 개별 소스 계정 설정

* SCP: 계정간에 정책 적용 가능, 주로 서비스 사용 제한에 사용. 데이터 수집, 시각화x

749
웹 사이트는 대중에게 제품을 판매하는데 사용 + ALB 뒤의 ASG 그룹의 EC2 인스터스에서 실행 + CloudFront 배포판 존재 + WAF는 SQL 주입 공격으로 부터 보호하는데 사용 → 보안 로그 검토 한 결과 웹 사이트에 액세스하는 것을 차단해야 하는 외부 악성 IP 발견

B. AWS WAF의 구성을 수정하여 악성 IP 주소를 차단하기 위한 IP 일치 조건을 추가합니다.

WAF: 웹 방화벽. CloudFront 배포판과 Application Load Balancer에 대한 요청을 필터링

IP 일치 조건 → 특정 IP 주소나 범위에서 들어오는 트래픽을 필터링하고 차단

네트워크 ACL은 VPC에서 작동

750
Organizations에 10개의 AWS 계정이 포함된 조직을 설정 → 수천 명의 직원에게 계정에 대한 액세스를 제공하는 솔루션을 설계 + 회사에는 기존 ID 공급자(IdP)가 있음 + AWS 인증을 위해 기존 IdP를 사용하려고함

C. AWS IAM Identity Center(AWS Single Sign-On)를 구성합니다. IAM Identity Center를 기존 IdP에 연결합니다. 기존 IdP에서 사용자와 그룹을 프로비저닝합니다.

* AWS IAM Identity Center(AWS Single Sign-On): 하나의 계정을 통해 여러 aws 계정을 관리하고 User를 생성하고 각 aws 계정에 대한 권한을 쉽게 설정할 수 있는 서비스(중앙 집중식 액세스 관리) → 기존 자격 증명을 사용하여 AWS 계정에 접근 가능하므로 별도의 IAM 계정 생성할 필요 X

* AWS RAM: 리소스를 다른 계정과 공유하는 데 사용, IdP와 통합하여 인증 및 권한 관리를 제공하지 않음.

751

회사의 AWS 계정에 대한 AWS Identity and Access Management 권한 부여 모델 설계 + AWS 계정의 AWS 서비스와 리소스에 대한 전체 액세스 권한을 가진 5명의 특정 직원을 지정 → 지정된 5명의 직원 각각에 대해 IAM 사용자를 만들고 IAM 사용자 그룹 생성

C. AdministratorAccess ID 기반 정책을 IAM 사용자 그룹에 연결합니다. 지정된 직원 IAM 사용자 5명을 각각 IAM 사용자 그룹에 배치합니다.

* ID 기반 정책: IAM 사용자 또는 IAM 사용자 그룹에 직접 연결되는 정책 → 지정된 사용자나 그룹에 대해 권한을 부여
* 리소스 기반 정책: 특정 리소스에 부착되며, IAM 사용자 그룹에 적용 X

* AdministratorAccess ID 기반 정책: AWS리소스에 대한 모든 권한 부여

* SystemAdministrator ID 기반 정책: 특정 권한을 사용자 정의하여 필요한 리소스 및 작업 접근 제어

752
가상 머신을 기반으로 다중 계층 결제 처리 애플리케이션 + 계층 간의 통신은 정확히 한 번 전달을 보장하는 타사 미들웨어 솔루션을 통해 비동기적으로 발생 → 최소한의 인프라 관리가 필요한 솔루션+ 정확히 한 번 전달을 보장

A. 아키텍처의 컴퓨팅 계층에 AWS Lambda를 사용합니다.

⇒ Lambda: 결제 처리를 위함

D. Amazon Simple Queue Service(Amazon SQS) FIFO 대기열을 컴퓨팅 계층 간 메시징 구성 요소로 사용합니다.
* SQS FIFO: 각 작업에 대해 정확히 한 번만 실행되도록 보장

753
SFTP를 통해 온프레미스 “파일 시스템” 이 매일 수신하는 보고서 파일을 분석하는 야간 일괄 처리 루틴 → AWS로 옮기고 싶어함 + 솔루션은 고가용성과 복원력 + 운영 노력을 최소화

A. SFTP용 AWS Transfer와 Amazon Elastic File System(Amazon EFS) 파일 시스템을 스토리지에 배포합니다. 예약된 스케일링 정책이 있는 Auto Scaling 그룹의 Amazon EC2 인스턴스를 사용하여 배치 작업을 실행합니다.

AWS Transfer Family ⇒ SFTP 프로토콜
EFS, Auto Scailing Group ⇒ 고가용성 + 복원성 + 파일 시스템

754
전 세계 사용자가 여러 AWS 지역의 EC2 인스턴스에 배포된 HTTP 기반 애플리케이션에 액세스 + 애플리케이션의 가용성과 성능을 개선 → 가용성에 영향을 미치거나 보안을 손상시키거나 과도한 리소스를 소모할 수 있는 웹 익스폴로잇으로부터 애플리케이션을
보호 + 정적 IP 주소가 필요

B. 각 리전의 애플리케이션 로드 밸런서(ALB) 뒤에 EC2 인스턴스를 배치합니다. ALB에 AWS WAF를 배포합니다. AWS Global Accelerator를 사용하여 가속기를 만들고 ALB를 엔드포인트로 등록합니다.

HTTP ⇒ Applicaton Load Balancer 필요
* AWS Global Accelerator : 전 세계적으로 트래픽을 AWS 글로벌 네트워크를 통해 라우팅하여 성능을 최적화, 정적 IP 주소를 제공 → 기본적으로 2개의 static ip제공

+ WAF로 보안 강화

755
데이터 플랫폼은 Aurora MYSQL 데이터베이스 사용 + 여러 개의 읽기 복제본과 여러 개의 DB 인스턴스가 여러 가용성 영역에 걸쳐 있음 + 최근에 데이터베이스에서 연결이 너무 많다는 오류 보고 → 읽기 복제본이 기본 작성자로 승격될 때 장애 조치 시간을 20%
줄이려고함

B. Aurora 데이터베이스 앞에 Amazon RDS Proxy를 사용합니다.
⇒ RDS Proxy : 연결 풀링을 통해 연결 수 최적화 + 동시 연결 수를 줄여 많은 연결로 인한 부하감소 + 읽기 복제

756
S3에 텍스트 파일 저장 + 고객 채팅 메시지, 날짜 및 시간 정보, 고객 개인 식별 정보(PII)가 포함 + 품질 관리를 위해 외부 서비스 공급자에게 대화 샘플을 제공하는 솔루션 필요 + 가장 최근 대화까지 무작위로 샘플 대화를 선택해야함 + 고객 PII를 외부 서비스 공급자와
공유해서는 안된다 + 고객 대화수가 증가하면 확장 + 운영 오버헤드 최소화

A. Object Lambda 액세스 포인트를 만듭니다. 함수가 파일을 읽을 때 PII를 삭제하는 AWS Lambda 함수를 만듭니다. 외부 서비스 공급자에게 Object Lambda 액세스 포인트에 액세스하도록 지시합니다.

⇒ Object Lambda 액세스 포인트: Lambda 함수가 파일을 읽을 때 PII를 삭제하므로, 외부 서비스 공급자는 PII가 제거된 데이터만 액세스

757
EC2 인스턴스에서 레거시 시스템 실행 + 애플리케이션 코드를 수정 X, 두 개 이상의 인스턴스에서 실행할 수 없음 + 시스템의 복구 시간을 개선할 수 있는 복원력 있는 솔루션을 설계

C. 장애 발생 시 EC2 인스턴스를 복구하기 위한 Amazon CloudWatch 알람을 생성합니다.

⇒ CloudWatch를 사용한 EC2 인스턴스 복구 : 인스턴스 시스템 상태 확인 실패 시, CloudWatch 알람을 사용하여 자동으로 인스턴스 복구 가능

- 종료 보호: 실수로 인스턴스를 삭제하는 것을 방지하기 위한 것
- EC2 인스턴스를 Multi-AZ 배포 ⇒ 문제에 2개 이상의 인스턴스에서 실행 X
- RAID 구성을 사용하는 EBS 볼륨으로 인스턴스 시작 ⇒ 복원력에는 도움, 복구 시간 개선에는 X

758

컨테이너화된 애플리케이션 워크로드를 3개의 가용성 영역에 걸쳐 VPC에 배포 + 가용성 영역에서 가용성이 높은 솔루션 필요 → 애플리케이션에 최소한의 변경만 요구 + 가장 적은 운영 오버헤드

A. Amazon Elastic Container Service(Amazon ECS)를 사용합니다. Amazon ECS Service Auto Scaling을 구성하여 대상 추적 스케일링을 사용합니다. 최소 용량을 3으로 설정합니다. 작업 배치 전략 유형을 가용성 영역 속성으로 확산으로 설정합니다.

⇒ EKS 자체 관리 노드 사용: 클러스터 관리를 직접 해야하므로 운영 오버헤드 증가

* Amazon ECS: 완전 관리형 서비스로, 클러스터 관리, 스케일링 및 로깅 등을 자동으로 처리하여 운영 오버헤드 최소화

* 작업 배치 전략: 가용성 영역 속성으로 확산. 균등하게 컨테이너 작업을 분배.

759
S3 + 1GB ~ 10GB 단일 비디오 파일 + 5분 이내에 영화 콘텐츠 제공 + 옛날 영화보다 최신 영화에 대한 수요가 더 높음 + 호스팅 서비스 비용 최소화

C. S3 Intelligent-Tiering에 최신 영화 비디오 파일을 저장합니다. S3 Glacier Flexible Retrieval에 이전 영화 비디오 파일을 저장합니다. 사용자가 이전 영화를 주문하면 신속한 검색을 사용하여 비디오 파일을 검색합니다.

⇒ S3 Intelligent-Tiering에 최신 영화 저장 + S3 Glacier Flexible Retrieval에 옛날 영화 저장, 사용자가 옛날 영화를 주문하면 신속 검색 사용 + 패턴이 불확실하기 때문에 고객이 미리 데이터를 분리할 수 없으므로 즉석에서 결정

* S3 Glacier Flexible Retrieval: 대용량 데이터 장기보관 + 저렴한 비용 + 3~5시간 내 복구 + 자동 복구 99.9% 내구성

* S3 Standard-IA: 저장 비용이 저렴하지만, 액세스 빈도가 높아질 경우 검색 및 데이터 전송 비용이 증가

760
공급업체가 Docker 컨테이너 이미지로 제공하는 아키텍처 설계 + 임시 파일을 위해 사용할 수 있는 50GB의 스토리지 필요 + 인프라는 서버리스 + 가장 적은 운영 오버헤드

C. AWS Fargate 시작 유형을 사용하는 Amazon Elastic Container Service(Amazon ECS) 클러스터를 만듭니다. Amazon Elastic File System(Amazon EFS) 볼륨이 있는 컨테이너 이미지에 대한 작업 정의를 만듭니다. 해당 작업 정의로 서비스를 만듭니다.

⇒ Lambda는 512MB 제한.
⇒ ECS , Fargate 서버리스, EFS 자동 크기 확장

761

온프레미스 LDAP 디렉토리 서비스를 이용하여 AWS Management Console에 사용자를 인증해야함 + 디렉토리 서비스는 SAML과 호환되지 않음 + 어떤 솔루션

D. AWS 보안 토큰 서비스(AWS STS)를 사용하여 단기 자격 증명을 얻는 온프레미스 맞춤형 ID 브로커 애플리케이션이나 프로세스를 개발합니다.

⇒ IAM 정책은 AWS 리소스에 대한 권한을 정의하는 데 사용되며, 사용자 인증에는 적합X
SAML 2.0과 호환되지 않는 경우 유사한 기능을 수행하기 위해 사용자 지정 ID 브로커 애플리케이션을 빌드 가능

762
EC2 인스턴스를 시작하기 위해 여러 AMI 저장 + 회사 운영에 필요한 중요한 데이터와 구성이 포함 → 실수로 삭제된 AMI를 빠르고 효율적으로 복구하는 솔루션 + 가장 적은 운영 오버헤드

C. 휴지통에 보관 규칙을 만듭니다.

⇒ 휴지통은 실수로 삭제된 Amazon EBS 스냅샷과 EBS 지원 AMI를 복원할 수 있는 데이터 복구 기능
휴지통을 사용할 때 리소스가 삭제되면 영구적으로 삭제되기 전에 지정한 기간 동안 휴지통에 보관됨, 보관 기간이 만료되기 전에 언제든지 휴지통에서 리소스를 복원 가능

763
온프레미스에 150TB의 보관된 이미지 데이터를 저장 → 다음 달 안에 AWS 클라우드로 옮겨야함 + 현재 네트워크 연결은 밤에만 이 목적으로 최대 100Mbps의 업로드를 허용 → 데이터를 옮기고 마이그레이션 마감일을 맞추는 가장 비용 효율적

B. 여러 개의 AWS Snowball 장치를 주문하여 데이터를 AWS로 배송합니다.

⇒ 10PB 이상은 스노모빌 권장, 10PB 미만은 스노볼 권장 (스노모빌 비용이 더 많이 듬)

764
온프레미스에서 AWS 3계층 애플리케이션을 마이그레이션 + 웹 계층과 애플리케이션 계층은 VM에서 시행 + 데이터베이스 계층은 MYSQL에서 실행 → 아키텍처를 가능한 최소한으로 변경하여 애플리케이션을 마이그레이션 + 특정 시점으로 데이터를 복원할 수
있는 데이터베이스 솔루션 + 운영 오버헤드 최소화

B. 웹 티어를 퍼블릭 서브넷의 Amazon EC2 인스턴스로 마이그레이션합니다. 애플리케이션 티어를 프라이빗 서브넷의 EC2 인스턴스로 마이그레이션합니다. 데이터베이스 티어를 프라이빗 서브넷의 Amazon Aurora MySQL로 마이그레이션합니다.

웹 티어 : 퍼블릭 서브넷
앱 티어: 프라이빗 서브넷
데이터베이스: 프라이빗 서브넷 ⇒ Aurora MYSQL

Aurora MYSQL: 고성능, 고가용성

RDS for MySQL: 기존 구조 최대한 유지

765
다른 회사가 개발팀의 SQS 대기열에 액세스 + 자체 계정 권한을 포기하지 않고 대기열을 폴링

C. 다른 회사가 SQS 대기열에 액세스할 수 있도록 하는 SQS 액세스 정책을 만듭니다.

인스턴스 프로필: 서비스에 대한 액세스 권한 부여X, EC2 인스턴스에 대한 권한
IAM 정책: 동일한 AWS 계정내의 사용자, 그룹 또는 역할에 사용
SQS 액세스 정책: SQS 리소스에 대한 교차 계정 액세스 부여 가능(다른 회사의 AWS 계정의 권한을 손상시키지 않고 대기열 폴링 권한 부여 가능)

#766

개발자는 최신 버전의 Linux를 실행하는 EC2 인스턴스에서 SSH 액세스를 얻을 수 있는 안전한 방법을 원함 + EC2 인스턴스는 프라이빗 서브넷에 호스팅되고 퍼블릭 서브넷에 배포된 NAT GW를 통해 인터넷에 액세스 + 가장 비용 효율적 충족

D. EC2 인스턴스와 연관된 IAM 역할에 AmazonSSMManagedInstanceCore IAM 정책을 연결합니다. 개발자에게 AWS Systems Manager Session Manager를 사용하여 EC2 인스턴스에 액세스하도록 지시합니다.

* AWS Systems Manager Session Manager: SSH 키나 배스천 호스트를 사용하지 않고도 EC2 인스턴스에 안전하게 연결할 수 있는 서비스

⇒ 배스천 호스트는 EC2 인스턴스이므으로 비용이 추가

767
회사가 생성하는 데이터의 양은 지난 몇 달 동안 기하급수적으로 증가 + 회사의 연구원들은 정기적으로 전체 데이터 세트의 하위 집합을 최소한의 지연으로 즉시 사용할 수 있도록 요구 + 전체 데이터 세트에 매일 액세스할 필요 X + 회사는 지속적인 자본 비용 감소

C. Amazon S3 버킷을 대상 스토리지로 사용하여 캐시된 볼륨이 있는 AWS Storage Gateway 볼륨 게이트웨이를 배포합니다. 데이터를 Storage Gateway 어플라이언스로 마이그레이션합니다.

⇒ Storage Gateway Volume : 저장된 볼륨, 캐시된 볼륨

- 캐시된 볼륨: 자주 액세스하는 데이터에 대한 저지연 액세스 유지
- 저장된 볼륨: 모든데이터를로컬에저장하도록함

768

EC2 인스턴스에서 실행되는 비즈니스에 중요한 애플리케이션 + DynamoDB 테이블에 데이터 저장 → 지난 24시간 이내의 모든 지점으로 테이블을 되돌릴 수 있어야 함+가장 적은 운영 오버헤드

A. 테이블에 대한 지정 시간 복구를 구성합니다.

* 시점복구: DynamoDB 테이블을 쓰거나 삭제하는 작업으로부터 보호

테스트 스크립트가 실수로 프로덕션 DynamoDB 테이블에 쓴다고 가정 → 시점복구를 사용하면 해당테이블을 지난 35일 동안의 어느 시점으로든 복원가능, 시점 복구를 활성화한 후에는 현재시간에서 5분 전부터 35일전까지의 어느시점으로든 복원

769
S3 버킷에 파일을 업로드하는 데 사용되는 애플리케이션 호스팅 + 업로드의 양과 빈도는 시간당 몇 개의 파일에서 수백 개의 동시 업로드까지 다양 → 이러한 요구사항을 충족하는 비용 효율적인 아키텍처

B. S3 버킷 내에서 객체 생성 이벤트 알림을 구성하여 AWS Lambda 함수를 호출하여 파일을 처리합니다.

→ S3 버킷에서 객체 생성 이벤트를 직접 감지하여 람다 호출하여 파일 처리

Kinesis Data Streams → S3( 불가능 ) + Firehose라면 S3에 가

770
회사는 AWS 계정에서 비생산 개발환경을 사용하여 새로운 기능을 테스트한 다음 기능을 프로덕션에 배포+ 프로덕션 인스턴스는 다른 시간대에 있는 고객 때문에 지속적으로 사용 + 회사는 주중 영업시간에만 비생산인스턴스를 사용 + 주말에는 비생산 인스턴스 사용 X + 비용 최적화

C. 프로덕션 인스턴스에 Compute Savings Plans를 사용합니다. 비프로덕션 인스턴스에 On-Demand Instances를 사용합니다. 사용하지 않을 때는 비프로덕션 인스턴스를 종료합니다.

- 프로덕션 환경: ComputeSavingsPlans 사용 ⇒온디맨드 요금에 비해 큰 폭의 할인제공 (프로덕션 환경에서 인스턴스를 지속적으로 사용해야하기 때문에 상당한 비용 절감 효과)
- 비프로덕션환경: 주중 영업시간에만 사용되므로 온디맨드 인스턴스가 적합함(필요할때만 비용지불)

* Compute Savings Plans는 특정 인스턴스 유형에 제한되지 않고 다양한 AWS 컴퓨팅 리소스에 대해 할인을 제공하는 요금제 → 온디맨드 인스턴스보다 훨씬 저렴

728x90