[Associate SAA-C03] - dump 정리 401 ~ 440
401
기존 애플리케이션을 고가용성 + 복원력 → 정전으로 인해 DB 서버가 충돌한 후 최근에 데이터 손실 경험
단일 장애 지점을 피하는 솔루션 → 사용자 수요를 충족하도록 확장할 수 있는 기능
A. 여러 가용성 영역에 걸쳐 Auto Scaling 그룹에서 Amazon EC2 인스턴스를 사용하여 애플리케이션 서버를 배포합니다. Multi-AZ 구성에서 Amazon RDS DB 인스턴스를 사용합니다.
Multi-AZ에서 Auto Scailing Group 인스턴스 사용 : 단일 장애 지점 방지
RDS의 Multi-AZ 모드: 고가용성, 복원력
EBS: 하나의 인스턴스에만 쓸 수 있도록 설계
402
대량의 스트리밍 데이터를 수집하고 처리 → Kinesis Data Streams 전송 → 이틀에 한 번씩 데이터 소비 / Amazon S3 버킷에 데이터를 씀 / S3가 Kinesis Data Streams로 전송하는 모든 데이터를 수신 x.
A. 데이터 보존 기간을 수정하여 Kinesis Data Streams 기본 설정을 업데이트합니다.
⇒ 기본 보존 기간은 24시간이지만, 데이터를 읽는 것은 이틀에 한 번씩 이루어지므로 S3는 데이터를 수신 X → 데이터 보존 기간을 48시간으로 수정해야함
403
Lambda 함수를 사용하여 S3에 파일을 업로드 하는 애플리케이션 + 작업 수행하는데 필요한 권한 → 개발자는 이미 S3에 필요한 유효한 IAM 자격증명이 있는 IAM 사용자를 가지고 있음
D. 필요한 권한이 있는 IAM 실행 역할을 생성하고 해당 IAM 역할을 Lambda 함수에 연결합니다.
⇒ Lambda 실행 역할을 생성하고 기존 S3 IAM 역할을 Lambda 함수에 연결
404
S3 + Lambda를 사용한 문서 처리 → 많은 문서를 처리 X
D. Amazon Simple Queue Service(Amazon SQS) 대기열을 만듭니다. 요청을 대기열로 보냅니다. 대기열을 Lambda의 이벤트 소스로 구성합니다.
SQS를 사용해 S3 버킷을 Lambda 함수에서 분리 → 문서가 손실되지 않고 Lambda 함수를 사용할 수 없는 경우에도 나중에 처리 가능
405
근무 시간동안 트래픽이 상당히 증가하지만 주말에는 작동할 필요가 없음 → 어떤 조치를 취해야 시스템이 수요를 충족하도록 확장
D. 대상 추적 확장 정책을 사용하여 인스턴스 CPU 사용률에 따라 자동 확장 그룹을 확장합니다.
E. 예약된 스케일링을 사용하여 주말에 자동 스케일링 그룹 최소, 최대 및 원하는 용량을 0으로 변경합니다. 주 초에 기본값으로 되돌립니다.
* 대상 추적 확장 정책 : CPU 사용률과 같은 특정 메트릭에 대한 대상 값 설정 가능
⇒ 근무 시간에 적용
* 예약된 스케일링 : 주말에 최소, 최대 및 원하는 용량 0으로 설정
⇒ 주말에 적용
406
퍼블릭 서브넷의 웹 서버는 포트 443에서 인터넷에 열려 있어야 합니다. 데이터베이스 서브넷의 Amazon RDS for MySQL DB 인스턴스는 포트 3306에서 웹 서버에만 액세스
C. DB 보안그룹 : 포트 3306에서 웹 서버의 보안 그룹의 트래픽 허용
D. 웹 보안그룹: 포트 443에서 0.0.0.0/0의 트래픽 허용
407
호스팅된 게임 애플리케이션에 대한 공유 스토리지 솔루션 구현 → Lustre 클라이언트 사용하여 데이터에 액세스
D. Amazon FSx for Lustre 파일 시스템을 만듭니다. 파일 시스템을 원본 서버에 연결합니다. 애플리케이션 서버를 파일 시스템에 연결합니다.
* AWS Lustre: 기계 학습, 고성능 컴퓨팅(HPC) 등 속도가 중요한 워크로드에 사용
408
UDP 사용 + 분산된 원격 장치 + 데이터를 즉시 처리 + 데이터는 저장되지 않음 + 지연 시간 최소화하는 솔루션
B. AWS Global Accelerator를 사용합니다. 두 리전 각각에 엔드포인트로 Network Load Balancer(NLB)를 만듭니다. Fargate 시작 유형으로 Amazon Elastic Container Service(Amazon ECS) 클러스터를 만듭니다. 클러스터에서 ECS 서비스를 만듭니다. NLProcess의 대상으로 ECS 서비스를 설정합니다. Amazon ECS에서 데이터를 처리합니다.
* Global Accelerator: 글로벌 사용자에게 제공하는 애플리케이션의 가용성과 성능을 향상하는데 도움이 되는 네트워킹 서비스 → 가장 가까운 엔드포인트 접속을 자동으로 빠르게 라우팅을 도와줌, 최저 대기 시간 + UDP → NLB 사용
409
Windows → AWS로 마이그레이션 → 온프레미스 파일 공유를 대체하는 것 중 가장 탄력적이고 내구성이 좋은 것
C. 파일 공유를 Amazon FSx for Windows File Server로 마이그레이션합니다.
EFS → Linux 인스턴스에만 작동 가능
410
EBS 볼륨에 쓰여진 모든 데이터가 휴면상태에서 암호화되도록 하기
B. EBS 볼륨을 암호화된 볼륨으로 만듭니다. EBS 볼륨을 EC2 인스턴스에 연결합니다.
* EBS 볼륨 암호화: 볼륨에 쓰인 데이터가 AWS 관리 키를 사용하여 저장 시 자동으로 암호화됨
411
산발적인 사용 패턴이 있는 웹 애플리케이션 : 매월 초에는 사용량이 많고 매주 초에 보통 사용하며 주중에는 예측할 수 없는 사용량 → 애플리케이션을 AWS 클라우드로 옮기고 싶어하며 데이터베이스 수정이 필요없는 비용 효율적인 데이터베이스 플랫폼
C. MySQL 호환 Amazon Aurora Serverless
→ RDS가 저렴하지만 “예측할 수 없는” 사용 패턴이 있는 경우에 Aurora Serverless가 더 저렴함
412
이미지 호스팅 회사가 S3 버킷에 객체 저장 → S3 버킷에 있는 객체가 실수로 대중에게 노출되는 것을 피하고자 함 + 모든 S3 객체는 비공개로 유지
D. 계정 수준에서 S3 Block Public Access 기능을 사용합니다. AWS Organizations를 사용하여 IAM 사용자가 설정을 변경하지 못하도록 하는 서비스 제어 정책(SCP)을 만듭니다. SCP를 계정에 적용합니다.
* S3 Block Public Access: 리소스에 대한 퍼블릭 액세스를 제한할 수 있도록 정책 및 권한 재정의함 → 버킷과 객체를 더욱 쉽게 보호 가능
* SCP: AWS Organizations 내의 계정에서 IAM 사용자가 특정 작업을 수행하지 못하도록 제한할 수 있는 정책
* AWS Trusted Advisor: aws 계정을 지속적으로 분석하고 aws 모범사례 및 Well-Architected 가이드라인을 따르는 데 도움이 되는 권장사항 제공
413
회사에서 사용자 트래픽 증가 → 트래픽 증가에 따라 사용자에게 적시에 마케팅 및 주문 확인 이메일을 보내는데 상당한 지연 발생 + 복잡한 이메일 전달 문제 해결을 위해 소요되는 시간을 줄이고 운영 오버헤드 최소화
B. Amazon Simple Email Service(Amazon SES)를 통해 이메일을 보내도록 웹 인스턴스를 구성합니다.
* SNS: 알림 및 메시징 서비스. SNS가 구독한 클라이언트에 메세지를 보내는 서비스. ex. 경고 알림, 알림 전달, 푸시 알림
* SES: 기업이 자체 이메일 주소와 도메인을 사용하여 메일을 보내고 받는 비용 효율적이고 확장 가능한 이메일 서비스.
ex. 대량 이메일, 트랜잭션 이메일
414
매일 수백개의 보고서를 생성하는 비즈니스 시스템 + 보고서를 CSV 형식으로 네트워크 공유에 저장 + 회사는 분석을 위해 이 데이터를 거의 실시간으로 클라우드에 저장해야함 + 최소한의 관리 오버헤드
B. Amazon S3 파일 게이트웨이를 만듭니다. S3 파일 게이트웨이에서 새 네트워크 공유를 사용하도록 비즈니스 시스템을 업데이트합니다.
* S3 File Gateway: 공유에 쓰여진 모든 파일을 백그라운드에서 S3 버킷에 자동으로 업로드함. 거의 실시간 전송.
→ 예약된 작업, 스크립트 또는 자동화가 필요없이 S3로의 전송 및 업로드가 처리됨
* DataSync : 네트워크 공유와 S3 간의 파일 전송을 자동화하고 최적화하는 완전 관리형 서비스.
→ API를 사용하기 위해 완전히 새로운 애플리케이션을 만드는 것(오버헤드)
415
S3 Standard에 페타바이트 규모의 데이터 저장 + 데이터는 여러 S3버킷에 저장되고 다양한 빈도로 액세스 → 모든 데이터에 대한 액세스 패턴을 알지 못함 + S3 사용 비용 최적화 + 가장 높은 운영 효율성
A. S3 버킷의 객체를 S3 Intelligent-Tiering으로 전환하는 규칙으로 S3 수명 주기 구성을 만듭니다.
* S3-Intelligent-Tiering: 데이터에 액세스 패턴을 예측하기 어려울 때 비용 절감 극대화.
416
글로벌 전자상거래 회사가 AWS에서 웹 애플리케이션 호스팅(정적 콘텐츠,동적 콘텐츠) + RDS 데이터베이스에 온라인 거래 처리 데이터 저장 → 페이지 로드 속도가 느림
B. Amazon CloudFront 배포를 설정합니다.
D. RDS DB 인스턴스에 대한 읽기 복제본을 생성합니다.
* CloudFront: 캐싱은 페이지 로드 시간과 서버 로드를 줄여줌
* RDS DB 읽기 복제본: DB 성능을 위한 것
→ RDS 다중 배포: 장애조치를 위한 것
417
EC2 인스턴스 + Lambda 함수를 사용하여 애플리케이션 실행 / 프라이빗 서브넷에서 실행 / Lambda 함수는 애플리케이션이 작동하려면 EC2 인스턴스에 대한 직접적인 네트워크 액세스 필요 / 최소 1년동안 실행
→ 사용하는 Lambda 함수 수가 증가 예상 + 모든 리소스에서 절감 효과를 극대화 + 서비스 간 네트워크 지연 시간을 낮게 유지
C. Compute Savings Plan을 구매합니다. Lambda 함수의 지속 시간과 메모리 사용량, 호출 횟수, 전송되는 데이터 양을 최적화합니다. Lambda 함수를 EC2 인스턴스가 포함된 프라이빗 서브넷에 연결합니다.
* Compute Savings Plans: 최대 66%까지 비용 절감 가능한 요금 모델로 인스턴스 패밀리, 크기, AZ, 리전 등과 관계 없이 EC2 인스턴스 사용량에 적용되며, Fargate 또는 Lambda 사용량에도 적용
* EC2 Instance Savings Plans: 리전의 개별 인스턴스 패밀리에 대한 사용량 약정을 조건으로 최대 72%의 할인 혜택을 제공하는 가장 저렴한 모델
418
개발 계정 + 프로덕션 계정의 두 가지 AWS 계정에서 S3 버킷에 액세스 할 수 있도록 허용 + 현재 계정에서 적절한 권한이 있는 IAM 그룹에 할당된 고유한 IAM 사용자를 사용하여 개발 계정에서 S3 버킷에 액세스 할 수 있음 + 프로덕션 계정에서 IAM 역할 생성 → 역할에는 프로덕션 계정에서 S3 버킷에 대한 액세스 권한을 부여하는 정책 → 최소 권한 원칙
B. 프로덕션 계정의 역할에 대한 신뢰 정책에서 개발 계정을 주체로 추가합니다.
* 신뢰정책: IAM 역할을 사용하여 AWS 계정 간 액세스 권한 위임 기능
⇒ IAM 역할을 가정하여 프로덕션 계정의 S3 버킷에 대한 교차 계정 액세스가 허용됩니다.
개발 계정 사용자는 역할을 가정하여 프로덕션 버킷에 대한 임시 액세스 권한을 얻을 수 있습니다
⇒ 개발 계정 사용자에게 관리자 액세스 정책을 연결하는 것은 최소 권한 원칙에 위배
⇒ 각 팀원에 대해 프로덕션 계정에 사용자를 만드는 것은 중복된 사용자 관리가 필요하게 되어 비효율적
419
모든 기능이 활성화된 AWS Organizations 사용 + ap-southeast-2 지역에서 여러 EC2 워크로드를 실행 + 다른 지역에서 리소스가 생성되는 것을 방지하는 서비스 제어 정책(SCP) + 보안 정책에 따라 모든 데이터를 암호화 → 직원들이 볼륨을 암호화하지 않고
EC2 인스턴스에 대한 볼륨을 생성
→ IAM 사용자 또는 루트 사용자가 ap-southeast-2에서 시작하는 모든 새 EC2 인스턴스에서 암호화된 EBS 볼륨을 사용하기를 원함
EBS 볼륨을 생성하는 직원에게 최소한의 영향을 미치는 솔루션
C. SCP를 만듭니다. SCP를 루트 조직 단위(OU)에 연결합니다. ec2:Encrypted 조건이 false와 같을 때 ec2:CreateVolume 작업을 거부하도록 SCP를 정의합니다.
→ 조직의 모든 계정에 있는 모든 IAM 사용자 또는 루트 사용자는 암호화하지 않고는 EBS 볼륨을 생성할 수 없습니다.
E. 조직 관리 계정에서 기본 EBS 볼륨 암호화 설정을 지정합니다.
→ SCP(서비스 제어 정책) 생성 후 OU에 연결하면 조직의 모든 계정에 있는 사용자에게 적용
420
RDS for PostgreSQL DB 클러스터 사용하여 프로덕션 데이터베이스 워크로드에 대한 관리 작업을 간소화하고자 함 → 데이터베이스 고가용성 보장 + 40초 이내에 자동 장애 조치 지원을 제공 + 기본 인스턴스에서 읽기를 오프로드하고 비용을 최대한 낮추고자 함
D. Amazon RDS Multi-AZ DB 클러스터 배포를 사용하여 읽기 워크로드를 리더 엔드포인트로 지정합니다.
* Multi-AZ 인스턴스 : 장애 조치에 60~120초 소요
* Multi-AZ 클러스터: 장애 조치에 약 35초 소요
* DB 클러스터 리더 엔드포인트: DB 클러스터에 대한 읽기 전용 연결 시 로드밸런싱을 지원
→ 기본 인스턴스에서 읽기 작업을 오프로드 가능
421
고가용성 SFTP 서비스 운영 + 탄력적 IP 주소 + SFTP 서비스는 Linux 인스턴스에 연결된 공유 스토리지로 백업 + 높은 IOPS 성능과 고도로 구성 가능한 보안을 제공하는 서버리스 옵션 + 사용자 권한에 대한 제어 유지
B. 암호화된 Amazon Elastic File System(Amazon EFS) 볼륨을 만듭니다. 탄력적 IP 주소와 인터넷에 연결된 액세스가 있는 VPC 엔드포인트가 있는 AWS Transfer Family SFTP 서비스를 만듭니다. 신뢰할 수 있는 IP 주소만 허용하는 보안 그룹을 엔드포인트에 연결합니다. EFS 볼륨을 SFTP 서비스 엔드포인트에 연결합니다. 사용자에게 SFTP 서비스에 대한 액세스 권한을 부여합니다.
* AWS Transfer Family: SFTP, FTPS 및 FTP를 통하여 S3 또는 EFS에서 파일을 송수신할 수 있는 완전관리형 지원
* EFS: 서버리스, 완벽한 탄력적 파일 스토리지 + Linux
* S3는 EFS보다 IOPS가 낮음 S3는 "높은 IOPS 성능"을 보장하지 않음
422
사용자는 비동기 API를 통해 모델에 액세스+ 독립적인 마이크로서비스에서 개발 + 수백명의 사용자에게 모델 제공 → 모델의 사용 패턴은 불규칙 + 일부 모델은 며칠 또는 몇 주 동안 사용되지 않을 수 있음 + 다른 모델은 한 번에 수천 개의 요청을 일괄 수신 가능
D. API에서 Amazon Simple Queue Service(Amazon SQS) 대기열로 요청을 보냅니다. 대기열에서 읽는 Amazon Elastic Container Service(Amazon ECS) 서비스로 모델을 배포합니다. 대기열 크기에 따라 클러스터와 서비스 사본 모두에 대해 Amazon ECS에서 AWS Auto Scaling을 활성화합니다.
→ 컨테이너 + 서버리스
비동기 요청 처리, 불규칙한 패턴 → SQS 사용
마이크로서비스 → ECS + ASG
* App Mesh: 서비스 간의 트래픽을 관리 → SQS보다 설계가 더 복잡함.
* 마이크로서비스: 소프트웨어가 잘 정의된 API를 통해 통신하는 소규모의 독립적인 서비스로 구성되어 있는 경우의 SW 개발을 위한 아키텍처 및 조직적 접근 방식
423
IAM : 사용자 역할 및 그룹에 사용되는 ID 기반 정책
IAM의 ID 기반 정책 개요:
- 사용자(User): 개별 사용자에게 부여되는 정책으로, 특정 사용자가 AWS 리소스에 액세스할 수 있는 권한을 정의
- 역할(Role): AWS 서비스나 애플리케이션이 다른 AWS 리소스에 접근할 수 있도록 권한을 부여. 사용자도 역할을 맡을 수 있습니다.
- 그룹(Group): 여러 사용자에게 공통된 권한을 부여하는 정책으로, 그룹 내 사용자에게 정책을 일괄적으로 적용
424
회사가 On-Demand 인스턴스에서 사용자 지정 애플리케이션 실행 + 하루 24시간, 주 7일 실행해야 하는 프런트엔드 노드와 작업 부하에 따라 단시간만 실행해야 하는 백엔드 노드 + 백엔드 노드의 수는 하루종일 다름 → 작업 부하에 따라 더 많은 인스턴스를 확장
B. 프런트엔드 노드에는 예약 인스턴스를 사용합니다. 백엔드 노드에는 스팟 인스턴스를 사용합니다.
* Front-end: 하루 24시간, 주 7일 => 예약 인스턴스 사용
* Back-end: 단시간만 + 노드의 수는 하루종일 다름 → 스팟 인스턴스를 사용하면 여유 용량을 더 낮은 비용으로 사용 가능
* AWS Fargate: 컨테이너를 위한 서버리스 컴퓨팅 엔진
425
온프레미스에서 워크로드 실행을 위해 높은 블록 스토리지 용량 + 일일 피크 입출력 트랜잭션: 초당 15,000 IOPS를 넘지 않음
→ 스토리지 용량과 무관하게 디스크 성능을 프로비저닝 → EBS 볼륨 유형 가장 비용 효율적
C. GP3 볼륨 유형
* io1: 최대 64000 IOPS
* io2: 최대 256000 IOPS
* GP2, GP3 : 둘 다 최대 IOPS는 16000이지만 GP3가 비용 효율적
426
헬스케어 애플리케이션의 데이터 저장 + 데이터는 자주 변경 + 저장된 데이터의 모든 수준에서 감사 액세스 필요 → 스토리지 용량이 부족한 온프레미스 인프라에서 애플리케이션 호스팅 → 기존 데이터를 AWS로 안전하게 마이그레이션
A. AWS DataSync를 사용하여 기존 데이터를 Amazon S3로 이동합니다. AWS CloudTrail을 사용하여 데이터 이벤트를 기록합니다.
⇒ 데이터의 모든 수준에서 감사가 필요하므로 CloudTrail을 사용하여 관리 이벤트(x) , 데이터 이벤트(ㅇ)를 기록해야함
* AWS Storage Gateway: 온프레미스를 AWS에 연결하는데 사용.
* AWS DataSync: 스토리지 간 데이터 복사. 자주 변경되는 데이터를 관리.
* AWS Snowcone: 물리적인 데이터 전송 장치
* S3 Transfer Acceleration: Transfer Acceleration은 인터넷을 통해 데이터를 더 빠르게 전송하는 기술
427
MYSQL 데이터베이스로 복잡한 JAVA 애플리케이션 구현 → Apache Tomcat에 배포되어야하며 고가용성이어야함
B. AWS Elastic Beanstalk를 사용하여 애플리케이션을 배포합니다. 로드 밸런싱 환경과 롤링 배포 정책을 구성합니다.
* AWS elastic Beanstalk: 애플리케이션을 신속하게 배포,관리 및 확장할 수 있는 서비스
* Amazon ElastiCache : 자주 조회되는 데이터 캐시
428
서버리스 : API Gateway, Lambda, DynamoDB 사용.
Lambda 함수는 DynamoDB 테이블을 읽고 쓸 수 있는 권한 필요 → DynamoDB 테이블을 가장 안전하게 액세스 솔루션
B. Lambda를 신뢰할 수 있는 서비스로 포함하는 IAM 역할을 만듭니다. DynamoDB 테이블에 대한 읽기 및 쓰기 액세스를 허용하는 정책을 역할에 연결합니다. Lambda 함수의 구성을 업데이트하여 새 역할을 실행 역할로 사용합니다.
→DynamoDB에 액세스하기 위한 IAM 역할이며 Lambda에 액세스하는 역할X
access_key_id 및 secret_access_key을 Systems Manager Parameter Store에 저장하는 것은 보안 위험.
429
다음 IAM 정책은 IAM 그룹에 첨부되었습니다. 이것은 그룹에 적용되는 유일한 정책입니다.
그룹 구성원에 대한 이 정책의 효과적인 IAM 권한은 무엇입니까?
D. 그룹 멤버는 멀티팩터 인증(MFA)으로 로그인한 경우에만 us-east-1 지역에 대한 ec2:StopInstances 및 ec2:TerminateInstances 권한이 허용됩니다. 그룹 멤버는 us-east-1 지역 내에서 다른 모든 Amazon EC2 작업이 허용됩니다.
⇒ us-east-1 리전 내에서 모든 EC2 작업을 허용하지만, MFA를 사용하지 않은 경우 EC2 인스턴스를 중지하거나 종료하는 작업을 명시적으로 거부
430
.csv 파일을 S3 버킷에 업로드하는 기계 센서 + .csv 파일은 이미지로 변환되어야 하며 그래픽 보고서의 자동 생성을 위해 가능한 한 빨리 제공 → 이미지는 1개월 후에 무의미 + csv 파일은 1년에 두 번 기계 학습 모델을 훈련하기 위해 보관 → ML 훈련 및 감사는 몇 주 전에 계획 + 가장 비용 효율적 충족
B. .csv 파일을 이미지로 변환하고 이미지를 S3 버킷에 저장하는 AWS Lambda 함수를 설계합니다. .csv 파일이 업로드되면 Lambda 함수를 호출합니다.
C. S3 버킷의 .csv 파일과 이미지 파일에 대한 S3 라이프사이클 규칙을 만듭니다. 업로드한 후 1일 후에 .csv 파일을 S3 Standard에서 S3 Glacier로 전환합니다. 30일 후에 이미지 파일을 만료합니다.
Lambda 사용: .csv 파일이 업로드될 때 트리거하여 이미지로 변환하여 S3에 이미지 저장
S3 Glacier로 전환 : 저비용, 장기 보관용 스토리지. 자주 접근되지 않거나 보관이 필요한 데이터를 저장.
→ 몇 주전에 ML 훈련 및 감사가 계획되므로 S3 Glacier의 긴 데이터 복구 시간은 문제가 되지 않음
431
새로운 비디오 게임 웹 사이트 개발 + RDS for MYSQL + 여러 플레이어가 동시에 온라인에서 경쟁 → 게임 개발자는 거의 실시간으로 상위 10개 스코어보드를 표시하고 현재 점수를 유지 + 게임 중지하고 복원할 수 있는 기능 제공
⇒ 사용자가 게임을 중단하고 나중에 재시작할 때 빠르게 상태를 복원
B. 웹 애플리케이션에 표시할 점수를 계산하고 캐시하기 위해 Redis 클러스터용 Amazon ElastiCache를 설정합니다.
* Redis: 빠른 읽기 및 쓰기 성능, 게임과 같은 실시간 애플리케이션. 클러스터가 중지되어도 데이터를 복원
String 뿐만 아니라 List, Set, Hash, Bit 배열 등 다양한 자료구조 지원(게임 스코어) + 데이터 복원 기능 존재(게임 중지 및 복원 시에도 현재 점수 유지 가능)
* Memcached: String 타입만 지원하고 오로지 읽기 전용
432
회사가 머신 러닝 알고리즘 사용 모델을 구축, 훈련 → 모델을 사용하여 복잡한 시나리오를 시각화하고 고객 데이터의 추세를 감지
→ 모델을 보고 플랫폼과 통합하여 증강된 데이터를 분석하고 비즈니스 인텔리전스 대시보드에서 직접 데이터 사용 + 최소한의 운영
오버헤드
B. Amazon SageMaker를 사용하여 모델을 빌드하고 학습합니다. Amazon QuickSight를 사용하여 데이터를 시각화합니다
* AWS SageMaker: 완전 관리형 기계 학습 (ML) 서비스.
* AWS QuickSight: 데이터 시각화
* OpenSearch Service: 검색 및 분석 엔진으로, 대량의 데이터를 실시간으로 검색하고 분석
433
여러 AWS 계정에서 프로덕션 및 비프로덕션 환경 워크로드 실행 (계정은 Organizations)
→ 비용 사용 태그 수정을 방지하는 솔루션 설계
C. 권한이 있는 주체 외에는 태그를 수정하지 못하도록 SCP(서비스 제어 정책)를 만듭니다.
* AWS SCP: 조직 내 권한을 관리하는 데 사용할 수 있는 일종의 조직 정책
→ 조직에서 무엇이든 제한할 때는 SCP 정책 사용
434
AWS 클라우드에서 애플리케이션 호스팅 + ASG,ELB, EC2 인스턴스에서 실행 + DynamoDB 테이블
→ 최소한의 다운타임으로 다른 AWS 지역에서 애플리케이션 사용
A. 재해 복구 지역에서 자동 확장 그룹과 로드 밸런서를 만듭니다. DynamoDB 테이블을 글로벌 테이블로 구성합니다. DNS 장애 조치를 구성하여 새 재해 복구 지역의 로드 밸런서를 가리킵니다.
* CloudFormation: 인프라 코드화. 자동화된 리소스 프로비저닝. 개발 및 테스트 환경. 템플릿에서 정의
→ 다운타임 발생.
* DynamoDB 글로벌 테이블: 자동 다중 지역, 다중 마스터 복제를 제공해 DR 지역 모두에서 데이터 사용 가능
* DNS 장애 조치: 새 DR 지역의 LB를 가르키도록 구성. 필요할때 DR 지역으로의 트래픽을 원활하게 장애 조치 가능
→ Route 53에는 인스턴스가 다운될 때 DNS 장애 조치 기능이 있으므로 따로 CloudWatch와 람다는 필요 x
435
데이터베이스 20TB + 2주안에 마이그레이션 진행 + 최소한의 다운타임
A. AWS Snowball Edge Storage Optimized 장치를 주문합니다. AWS Schema Conversion Tool(AWS SCT)과 함께 AWS Database Migration Service(AWS DMS)를 사용하여 진행 중인 변경 사항의 복제와 함께 데이터베이스를 마이그레이션합니다. Snowball Edge 장치를 AWS로 보내 마이그레이션을 완료하고 진행 중인 복제를 계속합니다.
* AWS Snowmobile: 클라우드에 연결을 설정할 수 없는 원격 위치에서 대량의 데이터(페타바이트)를 오프라인으로 전송하는 데 사용. 데이터 마이그레이션 중에 DMS를 통해 진행 중인 변경 사항도 캡처할 수 있어 최소한의 다운타임을 보장
* AWS Direct Connect: 설정하는데 최소 한달 소요
436
Amazon RDS for PostgreSQL DB 인스턴스 → 인프라를 추가하지 않고도 더 큰 작업 부하 수용
⇒ 수직적으로 확장 = 더 큰 인스턴스를 선택하는 것 의미함
A. 전체 작업 부하에 대해 예약된 DB 인스턴스를 구매합니다. Amazon RDS for PostgreSQL DB 인스턴스를 더 크게 만듭니다.
437
DDoS 공격
B. AWS WAF를 배포하고 ALB와 연결한 후 속도 제한 규칙을 구성합니다.
→ AWS WAF + ALB는 소스 IP가 변경되어도 속도 제한을 구성 (IP 주소에서 오는 요청 수를 제한)
* WAF 속도 제한 규칙: 각 IP 주소에서 오는 요청 수를 제한하여 과도한 트래픽이 웹 사이트를 압도하는 것 방지 가능
* Amazon Inspector: 보안 평가 서비스로, AWS 리소스에 대한 보안 취약성 스캔과 평가를 자동화. 보안 및 규정 준수를 강화
* Amazon GuardDuty: 위협 탐지 서비스로, AWS 계정 및 리소스에 대한 잠재적인 악성 활동 및 보안 위협을 모니터링하고 분석하여 사용자에게 알림을 제공
438
회사가 외부 감사자와 회계 데이터 공유 + 데이터는 프라이빗 서브넷에 있는 RDS DB 인스턴스에 저장
→ 감사자는 자체 AWS 계정이 있으며 자체 데이터베이스 사본이 필요함 → 감사자와 데이터베이스를 공유하는 가장 안전한 방법
D. 데이터베이스의 암호화된 스냅샷을 만듭니다. 감사자와 스냅샷을 공유합니다. AWS Key Management Service(AWS KMS) 암호화 키에 대한 액세스를 허용합니다.
RDS 사용하면 계정 간에 스냅샷을 공유 가능 + 암호화와 암호화키를 공유하여 보다 안전한 방법 제공
→ S3에 복사하는 것은 보안이 낮아짐.
439
IP 주소 범위가 작은 VPC 구성 + VPC에 있는 EC2 인스턴스 수가 증가하고 있으며 향후 워크로드에 필요한 IP 주소 부족
→ 운영 오버헤드 최소화
A. 추가 IPv4 CIDR 블록을 추가하여 IP 주소 수를 늘리고 VPC에 추가 서브넷을 만듭니다. 새 CIDR을 사용하여 새 서브넷에 새 리소스를 만듭니다.
⇒ 추가 IPV4 Cidr 블록 추가: 기존 VPC 내에서 IP 공간 확장 가능 → 별도의 VPC 생성 X 이므로 운영 오버헤드가 최소화
440
애플리케이션 테스트 RDS for MYSQL DB 인스턴스 사용 + DB 인스턴스 종료하기 전에 두 개의 백업 생성 + mysqldump 유틸리티 사용하여 DB 덤프를 만들어 첫 번째 백업 생성 + RDS 종료 시 최종 DB 스냅샷 옵션 활성화 하여 두 번째 백업 생성
→ 가장 최근의 백업에서 새 DB 인스턴스를 생성하고자 함 + DB인스턴스 호스팅 위해 Amazon Aurora MYSQL 호환 에디션 선택
새 DB 인스턴스를 만드는 솔루션
A. RDS 스냅샷을 Aurora로 직접 가져옵니다.
C. 데이터베이스 덤프를 Amazon S3에 업로드합니다. 그런 다음 데이터베이스 덤프를 Aurora로 가져옵니다.
MySQL에서 MySQL로 마이그레이션 도구가 필요하지 않기 때문. MySQL 유틸리티를 사용할 것입니다.