[Associate SAA-C03] - dump 정리 501 ~ 530

클라우드/AWS

[Associate SAA-C03] - dump 정리 501 ~ 530

코딩하는 도람쥐 2024. 10. 8. 22:47

728x90

501

고객 결제 데이터를 S3의 회사 데이터 레이크로 수집 + 평균적으로 1분마다 결제 데이터 수신 + 실시간으로 결제 데이터를 분석 → 데이터 레이크로 수집 + 가장 높은 운영 효율성

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

⇒ Kinesis data firehose: 데이터를 실시간 스트림으로 받아서 처리 및 전송하는 서비스. S3, Redshift 등의 저장소로 전송 가능

kinesis data analytics: 스트리밍 소스에 대해 강력한 SQL 코드를 작성하고 시계열 분석을 수행, 실시간 대시보드 제공 및 실시간 지표 생성 가능

502

EC2에서 콘텐츠 관리 시스템을 사용하는 웹 사이트 운영 + Amazon Aurora MySQL Multi-AZ DB 인스턴스를 사용 + 웹 사이트 이미지는 EC2 인스턴스 내부에 마운트된 EBS 볼륨에 저장- → 웹 사이트의 성능과 복원력을 개선하기 위해 어떤 조치

C. 웹사이트 이미지를 모든 EC2 인스턴스에 마운트된 Amazon Elastic File System(Amazon EFS) 파일 시스템으로 옮깁니다.

E. 기존 EC2 인스턴스에서 Amazon Machine Image(AMI)를 만듭니다. AMI를 사용하여 Auto Scaling 그룹의 일부로 Application Load Balancer 뒤에 새 인스턴스를 프로비저닝합니다. Auto Scaling 그룹을 구성하여 최소 두 개의 인스턴스를 유지합니다. 웹사이트에 대한 Amazon CloudFront 배포를 구성합니다.

EC2 ↔ S3 마운트 불가능

* Amazon EFS: 여러 EC2 인스턴스에서 동시에 액세스할 수 있는 확장 가능하고 완벽하게 관리되는 파일 스토리지

* Amazon CloudFront: 사용자에게 더 가까운 엣지 위치에 콘텐츠를 캐싱하여 지연 시간을 줄이고 콘텐츠 전송을 개선

503

인프라 모니터링 서비스 운영 + AWS 계정의 데이터를 모니터링 할 수 있는 새로운 기능을 구축 + 고객 계정의 AWS API를 호출하여 EC2 인스턴스를 설명하고 CloudWatch 메트릭을 읽음 → 가장 안전한 방법으로 고객 계정에 액세스

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

* 신뢰정책: IAM 역할을 사용하여 AWS 계정 간 액세스 권한 위임 기능

→ 신뢰 정책을 통해 회사의 AWS 계정은 고객의 IAM 역할을 일시적으로 가정하여 고객 계정 내의 지정된 리소스(EC2 인스턴스 및 CloudWatch 메트릭)에 대한 액세스를 허용

504

수백 개의 AWS 계정에 걸쳐 있는 us-east-1 지역의 여러 VPC 연결 + 자체 AWS 계정을 가지고 있음 → 가장 운영 효율적인 솔루션

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

여러 VPC 연결 → Transit Gateway : 중앙 집중화된 허브

각 VPC 연결 → VPC Peering

505

매일 밤 일괄 작업 + 주문형 청구를 사용하는 자동 확장 그룹 + ‘한 인스턴스에서 작업이 실패하면 다른 인스턴스가 작업을 다시 처리’

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

→ 일괄 작업처럼 중단을 견딜 수 있는 작업에는 매우 비용 효율적 → 만약 인스턴스가 중단되더라도, 다른 인스턴스로 대체하기 때문

506

웹 사이트 기능 구축 + 기능을 사용하면 사용자가 사진 업로드 가능 → 수요가 크게 증가할 것을 예상 → 사용자의 업로드 트래픽을 처리할 수 있도록 + 가장 확장성이 뛰어난 것

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

* Amazon S3: 매우 확장성이 뛰어난 객체 스토리지 서비스로, 대규모 업로드 트래픽 쉽게 처리 가능

⇒ 사전 서명된 URL: 사용자의 브라우저가 직접 S3로 파일을 업로드할 수 있습니다. 이는 애플리케이션 서버를 통하지 않기 때문에 서버 부하를 줄이고, 업로드 속도를 향상시킴

507

여행 티켓팅을 위한 웹 애플리케이션 + 글로벌 사용자 기반을 제공하기 위해 애플리케이션을 확장하려고함 + AWS 여러 지역에 배포 + 평균 지연 시간은 1초 미만이어야함 → 여러 지역에 웹 플랫폼을 별도로 배포 → 글로벌하게 일관된 단일 기본 예약 데이터베이스를 유지 관리

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

⇒ DynamoDB 글로벌 테이블은 여러 AWS 지역에 걸쳐 데이터를 자동으로 복제하여 글로벌 분산 애플리케이션에 적합

DynamoDB가 제공하는 자동 복제는 Regions 간의 수동 동기화 필요성을 제거

508

여러 Microsoft Windows Server 워크로드를 EC2 인스턴스로 마이그레이션 +필요에 따라 워크로드를 수동으로 백업하여 이미지 생성 → 자연재해가 발생하는 경우 다른 지역에서 워크로드를 신속하게 복구하려고 함 + 24시간 이상의 데이터 손실을 원하지 않음 + 인스턴스의 모든 백업을 자동화 + 최소한의 관리 노력

B. Amazon EC2 지원 Amazon Machine Image(AMI) 수명 주기 정책을 만들어 태그 기반 백업을 만듭니다. 백업을 하루에 두 번 실행하도록 예약합니다. us-west-2 리전에 대한 복사본을 구성합니다.

→ 리전 백업 자동화

D. AWS Backup을 사용하여 백업 볼트를 만듭니다. AWS Backup을 사용하여 태그 값을 기반으로 EC2 인스턴스에 대한 백업 계획을 만듭니다. 복사본의 대상을 us-west-2로 정의합니다. 하루에 두 번 실행되도록 백업 일정을 지정합니다.

→ EC2 인스턴스 백업 자동화

509

이미지 처리를 위한 2계층 애플리케이션 운영 + 두 개의 가용성 영역 사용 + 애플리케이션이 생각보다 느리게 실행 → 웹 서버 로그 파일의 보안 감사에서 애플리케이션이 소수의 IP 주소에서 수백만 개의 불법 요청을 받고 있음 → 즉각적인 성능 문제 해결

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

⇒ 보안 그룹 : 거부 X → 허용만 가능

510

두 지역에서 실행되는 애플리케이션 + 두 지역 간의 VPC 는 안전하게 통신해야함

C. ap-southeast-2 VPC와 eu-west-1 VP 간에 VPC 피어링 연결을 구성합니다. 서브넷 경로 테이블을 업데이트합니다. eu-west-1 애플리케이션 서버 IP 주소에서 트래픽을 허용하는 ap-southeast-2 데이터베이스 보안 그룹에 인바운드 규칙을 만듭니다.

⇒ VPC Peering 연결을 설정한 후에는 두 VPC 모두에서 서브넷 경로 테이블을 업데이트하여 피어링 연결을 통해 다른 VPC의 CIDR 블록으로 트래픽을 라우팅

* VPC Peering: 다른 리전에 있는 피어 VPC의 보안 그룹을 참조 X -→ Peer VPC의 CIDR 블록 사용하여 보안그룹 설정

511

PostgreSQL 데이터베이스 스키마를 사용하는 소프트웨어 개발 + 여러 개발 환경과 데이터베이스를 구성해야함 → 평균적으로 개발 환경은 8시간 근무일의 절반 동안 사용 → 가장 비용 효율적 충족

C. 각 개발 환경을 고유한 Amazon Aurora On-Demand PostgreSQL 호환 데이터베이스로 구성합니다.

Amazon Aurora On-Demand PostgreSQL : Amazon Aurora의 이점을 제공하는 동시에 온디맨드 방식으로 사용료를 지불. 일반적으로 프로비저닝된 용량 옵션에 비해 개별 개발 환경에 비용 효율적

512

계정별로 태그가 지정된 리소스가 있는 Organizations를 사용 + AWS Backup을 사용하여 인프라 리소스를 백업 → 모든 리소스를 백업 + 가장 적은 운영 오버헤드

A. AWS Config를 사용하여 태그가 지정되지 않은 모든 리소스를 식별합니다. 식별된 리소스에 프로그래밍 방식으로 태그를 지정합니다. 백업 계획에서 태그를 사용합니다.

* Config: 리소스 구성을 지속적으로 평가하고 태그가 지정되지 않은 리소스를 식별 → 식별되면 필요한 태그를 프로그래밍 방식으로 적용하여 각 리소스에 대한 백업 요구 사항을 표시 가능 + 백업 계획 구성에서 태그를 사용하면 태그가 지정된 리소스만 백업 프로세스에 포함되어 운영 오버헤드를 줄이고 필요한 모든 리소스 백업 가능

513

회사는 여러 기기 유형에 이미지를 표시할 수 있도록 이미지 크기를 자동으로 조정하는 솔루션 필요 + 애플리케이션은 하루종일 예측할 수 없는 트래픽 패턴 경험 → 확장성을 극대화하는 고가용성 솔루션

A. Amazon S3에 호스팅된 정적 웹사이트를 만들고, AWS Lambda 함수를 호출하여 이미지 크기를 조정하고 이미지를 Amazon S3 버킷에 저장합니다.

image → S3 또는 CloudFront 사용

⇒ AWS S3 + Lambda 사용 → 사용자가 업로드한 원본 이미지를 저장할 Amazon S3 버킷을 설정, 새 이미지가 업로드될 때마다 AWS Lambda 함수를 호출하도록 S3 버킷에 이벤트 트리거 구성, Lambda 함수는 업로드된 이미지를 검색하고, 장치 요구 사항에 따라 필요한 크기 조정 작업을 수행하고, 크기 조정된 이미지를 S3 버킷이나 크기 조정된 이미지에 지정된 다른 버킷에 다시 저장하도록 설계

514

EC2 인스턴스에서 마이크로서비스 애플리케이션 실행 + 확장성을 위해 EKS 클러스터로 마이그레이션하려고함 + 보안 규정 준수를 유지하기 위해 엔드포인트 프라이빗 액세스를 True로 설정 + 엔드포인트 퍼블릭 엑세스를 False 로 설정하여 EKS 제어 평면 구성 →

데이터 평면을 프라이빗 서브넷에 배치해야함 → 노드가 클러스터에 가입할 수 없기 떄문에 오류 알림을 받음

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

⇒ AWS 인터페이스 VPC 엔드포인트를 사용하여 VPC와 Amazon Elastic Kubernetes Service 사이에 프라이빗 연결을 생성 가능 + 인터넷 게이트웨이, NAT 디바이스, VPN 연결 또는 AWS Direct Connect 연결을 사용하지 않고 VPC에 있는 것처럼 Amazon EKS에 액세스 + VPC의 인스턴스에서 Amazon EKS에 액세스하는 데 퍼블릭 IP 주소가 필요X

515

온프레미스 애플리케이션을 AWS 로 마이그레이션 + Redshift를 솔루션으로 사용하고 싶어함

* Redshift: AWS에서 완전관리형으로 제공해주는 확장이 쉽고 안전한 페타바이트급 데이터 웨어하우스 서비스

- 클라이언트 측 및 서버 측 암호화 지원

- 지정된 시간 동안 및 애플레케이션이 활성화되지 않은 경우 분석 워크로드 처리

- 분당 페타바이트 규모의 데이터와 수천만건의 요청을 지원하기 위한 글로벌 확장

516

고객에게 API 인터페이스를 제공하여 재무 정보를 검색할 수 있도록 함 + 연중 최대 사용량 기간 동안 더 많은 요청 예상 → 고객 만족을 보장하기 위해 API가 낮은 지연 시간으로 일관되게 응답해야함 + API에 대한 컴퓨팅 호스트를 제공 + 최소한의 운영 오버헤드

⇒ B. 프로비저닝된 동시성을 갖춘 Amazon API Gateway 및 AWS Lambda 함수를 사용합니다.

* 프로비저닝: 사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해 두는 것

* 프로비저닝된 동시성: 함수에 대해 콜드 스타트 지연 시간을 줄이는데 사용

517

회사에서 AWS Systems Manager Session Manager 로그를 보관 목적으로 S3 버킷으로 보내고 싶어함 + 가장 높은 운영 효율성

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

518

RDS MYSQL DB 인스턴스 사용 + 데이터베이스의 디스크 공간이 부족해지고 있음 → 다운타임 없이 디스크 공간을 늘리고 싶음 + 최소한의 노력

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

→ 스토리지 자동 확장 활성화 : RDS가 애플리케이션의 요구 사항에 따라 스토리지 용량 자동으로 조정( 자동확장 = 다운 타임 없이)

519

회사는 고객이 AWS에서 데이터를 수집하고 분석하는 것을 가속화하기 위한 솔루션과 도구 제공 → 고객이 셀프 서비스 목적으로 사용할 수 있는 공통 솔루션과 도구 세트를 중앙에서 관리하고 배포해야함.

B. 고객을 위한 AWS 서비스 카탈로그 제품을 생성합니다.

Service Catalog를 사용하면 고객이 셀프 서비스로 제공할 수 있는 표준화된 제품 세트(이 경우 솔루션 및 도구)를 정의 가능

고객이 승인된 AWS 리소스를 셀프 서비스 방식으로 배포할 수 있도록 도와줌

* AWS Service Catalog: 승인된 서비스와 도구 모음을 고객에게 제공. 제품 및 솔루션을 미리 정의하고 카탈로그 형태로 제공. 중앙에서 관리하고 배포.

* CloudFormation: 인프라를 코드로 관리 + 템플릿을 사용해 AWS 리소스를 자동으로 생성, 관리, 업데이트 + 리소스 배포 자동화

* AWS Systems Manager: 인프라 관리 작업 자동화 + 중앙관리

* AWS Config: 리소스 구성 상태 모니터링 + 설정 변경 추적.

520

데이터베이스에 대한 애플리케이션 읽기 및 쓰기 처리량이 중간에서 높을 것으로 예상 + 트래픽은 예측할 수 없음 → 트래픽에 대응하여 확장해야함+ 어떤 DynamoDB 테이블 구성이 이러한 요구 사항을 가장 비용 효율적

B. DynamoDB Standard 테이블 클래스를 사용하여 DynamoDB를 주문형 모드로 구성합니다.

⇒ (주문형)온디맨드: 트래픽 패턴 예측 불가능 + 대규모 작업이 실행되는 경우에 적합 + 유연함 + 사용량에 따라 자동 처리

* DynamoDB Standard: 덜 자주 액세스하는 Standard-IA에 비해 중간-높은 트래픽 앱에 필요한 가장 빠른 성능을 제공

* DynamoDB Standard Infrequent Access : 주로 액세스 빈도가 낮은 데이터에 적합

521

소매업체에 여러 사업 + 사업의 IT팀은 자체 AWS 계정을 관리 + 각 팀 계정은 Organizations의 조직에 속함 + 각 팀은 자체 AWS 계정의 DynamoDB 테이블에서 제품 재고 수준을 모니터링 + 회사는 공유 AWS 계정에 중앙 재고 보고 애플리케이션 배포 → 애플리케이션은 모든 팀의 DynamoDB 테이블에서 항목을 읽을 수 있어야함 + 안전하게 충족하는 인증 옵션

C. 모든 비즈니스 계정에서 DynamoDB 테이블에 대한 액세스 권한을 부여하는 정책과 인벤토리 애플리케이션 계정에서 특정 역할을 신뢰하는 신뢰 정책이 있는 BU_ROLE이라는 IAM 역할을 만듭니다. 인벤토리 계정에서 STS AssumeRole API 작업에 대한 액세스를 허용하는 APP_ROLE이라는 역할을 만듭니다. 애플리케이션이 APP_ROLE을 사용하도록 구성하고 DynamoDB 테이블을 읽기 위해 교차 계정 역할 BU_ROLE을 가정합니다.

⇒ IAM 역할을 사용하는 방식은 액세스 키나 비밀번호를 직접 관리하는 것보다 훨씬 안전함 + 임시 자격 증명을 사용하므로 보안 위험이 줄어듬

→ Secrets Manager: 여러 계정 간 액세스 관리에 적합하지 않음 + 민감한 데이터를 안전하게 관리하고 보호. 데이터베이스 자격증명, API키, 토큰 등 비밀정보 저장, 자동으로 관리 및 교체

522

EKS를 사용하여 컨테이너 애플리케이션 실행 + 회사의 작업 부하가 하루종일 일정하지 않음

→ 회사는 EKS가 작업 부하에 따라 확장 및 축소되기를 원함 + 가장 적은 운영 오버헤드

B. Kubernetes Metrics Server를 사용하여 수평적 Pod 자동 확장을 활성화합니다.

C. Kubernetes Cluster Autoscaler를 사용하여 클러스터의 노드 수를 관리합니다.

* Kubernetes Metrics Server: 수평적 포드 자동 확장을 통해 CPU/메모리 사용량에 따라 포드 동적 확장

* Kubernetes Cluster Autoscaler: 포드 리소스 요구 사항 및 이벤트에 대응하여 EKS 클러스터의 노드 수를 자동으로 조정

523

마이크로서비스 기반 서버리스 웹 애플리케이션 실행 + 여러 DynamoDB 테이블에서 데이터를 검색할 수 있어야함 → 애플리케이션의 기본 성능에 영향을 미치지 않고 데이터를 검색할 수 있는 기능을 제공 해야함 + 가장 운영적으로 효율적인 방식

D. DynamoDB 커넥터를 사용한 Amazon Athena Federated Query

* AWS AppSync 리졸버→ 데이터 검색 + 코딩 필요

* Amazon Athena 통합 질의(Federated Query): 데이터 분석가, 엔지니어 및 데이터 과학자가 관계형, 비-관계형, 객체 및 사용자 지정 데이터 소스에 저장된 데이터에 대해 SQL 질의를 실행할 수 있는 기능

524

IAM 권한과 관련된 액세스 거부 오류와 권한 없음 오류를 분석하고 문제를 해결하고자 함 + CloudTrail을 켰음 → 최소한의 노력으로 요구사항 충족

C. Amazon Athena 쿼리로 CloudTrail 로그를 검색하여 오류를 식별합니다.

⇒ Athena: Amazon S3의 데이터에 대해 SQL 쿼리를 실행 가능 사용자 정의 코드나 스크립트를 작성하지 않고도 로그를 쿼리하고 특정 오류를 식별하는 가장 쉬운 방법

AWS CloudTrail이 AWS 계정에서 발생하는 API 호출을 기록하여 이벤트를 로그 파일 형태로 Amazon S3에 저장하고 이 로그 파일을 Athena를 통해 SQL 쿼리를 실행하여 분석하면 다양한 정보를 추출하고 오류를 식별

525

기존 AWS 사용 비용을 운영 비용 대시보드에 추가 + 회사가 사용 비용에 프로그래밍 방식으로 액세스할 수 있는 솔루션을 추천 → 현재 연도 비용 데이터에 액세스하고 향후 12개월의 비용을 예측할 수 있어야함 + 가장 적은 운영 오버헤드

A. AWS Cost Explorer API를 페이지 분할로 사용하여 사용 비용 관련 데이터에 액세스합니다.

* AWS Cost Explorer: 비용과 사용량을 보고 분석할 수 있는 도구, 알람 기능은 없음. 보고서 기능 제공 , 최대 12개월 이전의 데이터를 소급해서 확인 가능

→ Cost Explorer API는 향후 12개월의 비용을 예측하는 기능을 제공 + 프로그래밍 방식으로 비용 데이터에 액세스

* AWS Budget: 예산 초과 알림, 모니터링 + 알림 및 보고서 형식. 프로그래밍적 접근은 제한적.

526

애플리케이션의 회복성 검토 + DB 관리자가 최근 확장 연습의 일환으로 Amazon Aurora PostgreSQL DB 작성자 인스턴스를 장애조치 했다는 것을 알아 챔 + 장애 조치로 인해 3분간 애플리케이션이 다운 → 최소한의 운영 오버헤드로 확장 연습의 다운타임을 줄이는 방법

D. 데이터베이스에 대한 Amazon RDS 프록시를 설정합니다. 프록시 엔드포인트를 사용하도록 애플리케이션을 업데이트

→ RDS Proxy: RDS를 위한 완전 관리형, 고가용성, 확장 가능한 프록시. 연결을 자동으로 재조정하여 다운타임을 줄임. 프록시 엔드포인트를 사용하여 장애 조치가 발생해도 지속적인 연결 유지.

읽기 복제본 → 부하 분산 / 장애 조치 시 다운타임 발생

527

지역 구독 기반 스트리밍 서비스 + EC2 인스턴스의 웹 서버와 애플리케이션 서버 + 인스턴스는 ELB뒤에 ASG에 있음 + 여러 가용 영역에 걸쳐 확장되는 Aurora 글로벌 데이터베이스 클러스터 포함 → 전 세계적으로 확장하고 애플레케이션의 다운타임을 최소화 + 가장 많은 내결함성 제공

D. 웹 계층과 애플리케이션 계층을 두 번째 지역에 배포합니다. Amazon Aurora 글로벌 데이터베이스를 사용하여 기본 지역과 두 번째 지역에 데이터베이스를 배포합니다. 두 번째 지역에 대한 장애 조치 라우팅 정책과 함께 Amazon Route 53 상태 확인을 사용합니다. 필요에 따라 보조를 기본으로 승격합니다.

⇒ Aurora PostgreSQL 크로스 리전 복제본을 사용하는 것은 Aurora 글로벌

데이터베이스보다 비효율적 + DMS는 최적화되어있지 않음 + ASG는 지역에 걸쳐 있을 수 없음

528

일괄 처리 시스템을 AWS로 마이그레이션 + FTP를 사용하여 수천 개의 파일을 주기적으로 수신 + 일괄작업은 밤새 처리 + 완료하는 데 몇시간이 걸림 + 파일을 보내는 FTP 클라이언트를 최소한으로 변경하여 최대한 빨리 들어오는 데이터 파일을 처리 → 성공적으로 처리된 후 들어오는 데이터 파일을 삭제 → 각 파일에 대한 처리에는 3~8분

D. AWS Transfer Family를 사용하여 Amazon S3 Standard에 수신 파일을 저장할 FTP 서버를 만듭니다. AWS Lambda 함수를 만들어 파일을 처리하고 처리 후 파일을 삭제합니다. S3 이벤트 알림을 사용하여 파일이 도착하면 Lambda 함수를 호출합니다.

* AWS Transfer Family: SFTP, FTPS 및 FTP를 통하여 S3 또는 EFS에서 파일을 송수신할 수 있는 완전관리형 지원 → 사용하면 파일을 S3로 직접 수신 → FTP 서버를 관리할 필요가 없음

* AWS Batch: 작업을 트리거할뿐이며, 여전히 어딘가에서 실행되어야함(ex: Lambda)

각 파일을 처리 하는데 3~8분 소요 → Lambda 의미

529

회사는 데이터베이스에 거래 및 민감한 데이터 보유 → 보안을 강화하고 데이터베이스의 운영 오버헤드를 줄이는 솔루션

B. Amazon RDS로 데이터베이스를 마이그레이션하고 저장 중 암호화를 구성합니다.

⇒ RDS :Serverless

* RDS: 관리되므로 운영 오버헤드가 제일 적음 + 휴면 암호화 ⇒ 보안

* Amazon Macie: 데이터 보안을 위한 것이 아니라 PII와 민감한 데이터를 식별하기 위한 것

* Amazon CloudWatch: 클라우드 이벤트를 위한 것이며 데이터베이스 보호 X

530

TCP/UDP 멀티 플레이어 게임 기능 + Route 53을 사용하여 트래픽을 여러 네트워크 로드밸런서로 연결 → 사용자 증가에 대비하여 온라인 게임의 성능을 개선하고 지연 시간을 줄여야함

C. NLB 앞에 AWS Global Accelerator를 추가합니다. 올바른 리스너 포트를 사용하도록 Global Accelerator 엔드포인트를 구성합니다.

* Global Accelerator: 글로벌 사용자에게 제공하는 애플리케이션의 가용성과 성능을 향상하는데 도움이 되는 네트워킹 서비스

⇒ 가장 가까운 엔드포인트 접속을 자동으로 빠르게 라우팅을 도와줌, 최저 대기 시간

* API Gateway는 주로 RESTful API에 사용되며, TCP 및 UDP 트래픽을 처리x

728x90