클라우드/AWS

[Associate SAA-C03] - dump 정리 601 ~ 630

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

601 
RDS for PostgreSQL DB 인스턴스에서 중요한 데이터베이스를 실행 → 최소한의 다운타임과 데이터 손실로 Aurora PostgreSQL로 마이그레이션 + 최소한의 운영 오버헤드 

 

더보기

B. RDS for PostgreSQL DB 인스턴스의 Aurora 읽기 복제본을 만듭니다. Aurora 읽기 복제본을 새 Aurora PostgreSQL DB 클러스터로 승격합니다.


⇒ Aurora 읽기 복제본 : RDS PostgreSQL → Aurora PostgreSQL로 복제본 생성. 실시간 복제로 최소한의 다운타임. 

최소 운영 오버헤드 ⇒ 읽기 복제본 사용


602
EBS 스토리지를 사용하는 수백 개의 EC2 인스턴스 → 재해 발생 후 모든 EC2 인스턴스를 복구할 수 있어야함 + 최소한의 노력 

 

더보기

C. AWS Backup을 사용하여 EC2 인스턴스 전체 그룹에 대한 백업 계획을 설정합니다. AWS Backup API 또는 AWS CLI를 사용하여 여러 EC2 인스턴스의 복원 프로세스를 가속화합니다.


⇒ AWS Backup: 백업 자동화. EBS, RDS, EFS, DynamoDB, AWS Storage 지원. 백업을 중앙에서 관리. 


603
회사는 반구조화된 데이터 세트의 대규모 병렬 주문형 처리를 위한 서버리스 솔루션을 원함 + 데이터는 S3에 저장된 로그, 미디어 파일, 판매 거래 및 IoT 센서 데이터로 구성 → 솔루션이 데이터 세트의 수천개 항목을 병렬 처리하기를 원함 + 가장 높은 운영 효율성 

 

더보기

B. AWS Step Functions Map 상태를 분산 모드로 사용하여 데이터를 병렬로 처리합니다.


인라인 모드: 단순한 워크플로에 적합하며, 모든 단계가 하나의 JSON 정의 안에 포함
분산 모드: 대규모의 복잡한 워크플로에 적합하며, 워크플로를 여러 상태 머신으로 나눌 수 있어 관리와 확장성이 용이


AWS Step Functions: 대규모 병렬 워크로드를 조정하여 반구조화된 데이터의 주문형 처리 가능. Map 상태를 사용하여 분산 처리를 조정하고 확장 map 상태는 작업을 여러 리소스에 분산하여 대규모 데이터 세트의 항목을 병렬로 처리
분산모드에서 Map 상태를 사용하면 병렬 처리 및 확장이 자동으로 처리


604
6주안에 10PB 데이터를 S3로 마이그레이션 + 인터넷으로의 500Mbps 업링크 + 대역폭의 80% 사용

 

더보기

D. 여러 AWS Snowball 디바이스를 주문합니다. 데이터를 디바이스에 복사합니다. 디바이스를 AWS로 보내 데이터를 Amazon S3에 복사합니다.


페타바이트 마이그레이션 ⇒ AWS Snowball 사용


605
온프레미스 인터넷 소형 컴퓨터 시스템 인터페이스 네트워크 스토리지 서버 + 클라우드로 이전하여 이러한 서버의 수를 줄이고자함 → 자주 사용되는 데이터에 대한 저지연 액세스를 제공하고 최소한의 인프라 변경으로 온프레미스 서버에 대한 종속성을 줄여야함 

 

더보기

D. 캐시 볼륨으로 구성된 AWS Storage Gateway 볼륨 게이트웨이를 배포합니다.

 

* Storage Gateway: 파일 기반 게이트웨이, 볼륨 기반, 테이프 기반 솔루션
- 캐시된 볼륨: 자주 액세스 하는 데이터에 대한 저지연 액세스 유지
- 저장된 볼륨: 모든 데이터를 로컬에 저장하도록함


606
S3에 객체를 업로드할 수 있는 애플리케이션을 설계 + 객체 내구성을 극대화해야함 + 객체는 언제든지, 얼마든지 사용할 수 있어야함 + 객체가 업로드된 후 처음 30일 동안 객체에 자주 액세스하지만, 30일이 지난 객체에 액세스할 가능성은 훨씬 낮음 + 가장 비용 효율적으로 충족 

 

더보기

B. 30일 후에 객체를 S3 Standard-Infrequent Access(S3 Standard-IA)로 전환하기 위한 S3 Lifecycle 규칙을 사용하여 모든 객체를 S3 Standard에 저장합니다.

 

⇒ S3 Standard 에서 S3 Standard Infrequent Access로 S3 Lifecycle 구성

 

S3 Standard-Infrequent Access(S3 Standard-IA): 다중 가용 영역. 

S3 One Zone-Infrequent Access(S3 One Zone-IA): 단일 가용 영역 


 607 
2TB의 범용 SSD Amazon Elastic Block Store(Amazon EBS) 스토리지가 있는 Amazon RDS for Oracle의 다중 AZ 배포 + 평균 문서 크기가 6MB인 바이너리 대형 개체(BLOB) + DB의 성능 개선, 고가용성 + 복원력 + 비용 효율성 

 

더보기

C. Amazon S3 버킷을 만듭니다. S3 버킷에 문서를 저장하도록 애플리케이션을 업데이트합니다. 기존 데이터베이스에 객체 메타데이터를 저장합니다.


* Amazon S3 : 매우 큰 용량을 저렴하게 저장할 수 있는 솔루션 + 저장된 데이터의 양에 비례하여 비용이 발생하며, RDS와 비교했을 때 대용량 데이터를 저장하는 데 있어 훨씬 비용 효율적


608
전 세계 20000개가 넘는 리테일 매장에 배치된 고객에게 서비스를 제공하는 애플리케이션 + 포트 443에서 HTTPS를 통해 노출되는 백엔드 웹 서비스로 구성 + ALB + 공용인터넷을 통해서 웹과 통신한다

→ 리테일 매장에서 등록한 IP 주소로만 액세스를 제한하여 애플리케이션 엔드포인트의 보안을 강화 

 

더보기

A. AWS WAF 웹 ACL을 ALB와 연결합니다. ALB에서 IP 규칙 세트를 사용하여 트래픽을 필터링합니다. 규칙의 IP 주소를 업데이트하여 등록된 IP 주소를 포함합니다.


⇒ AWS WAF 웹 ACL ↔ ALB 와 연결 (ALB의 IP 규칙 세트를 사용하여 트래픽을 필터링함)


609
Lake Formation을 사용하여 AWS에서 데이터 분석 플랫폼 + S3 및 RDS와 같은 다양한 소스에서 데이터를 수집 → 민감한 정보가 포함된 데이터 일부에 대한 액세스를 차단하는 보안 솔루션 + 최소한의 운영 오버헤드

 

더보기

B. 행 수준 보안 및 셀 수준 보안을 구현하기 위해 데이터 필터를 만듭니다.


* Lake Formation: 데이터 레이크의 구축, 보안 설정, 관리를 손쉽게 만들어주는 서비스

 

데이터 필터 사용하여 열 수준, 행 수준, 셸 수준의 보안 구현 ⇒ 민감한 데이터에 대한 액세스 방지 가능


610
VPC에서 실행되는 EC2 인스턴스 배포 + EC2 인스턴스는 소스 데이터를 S3 버킷에 로드하여 나중에 데이터를 처리할 수 있도록 함 → 규정 준수에 따라 데이터는 퍼블릭 인터넷을 통해 전송되어서는 x + 온프레미스 데이터 센터에 있는 서버는 EC2 인스턴스에서 실행되는 애플리케이션의 출력을 사용 

 

더보기

B. Amazon S3에 대한 게이트웨이 VPC 엔드포인트를 배포합니다. 온프레미스 네트워크와 VPC 간에 AWS Direct Connect 연결을 설정합니다.

 

EC2 인스턴스의 소스 데이터 → S3 버킷에 로드하여 나중에 데이터 처리 퍼블릭 인터넷을 통한 전송 X
⇒ S3가 있으므로 게이트웨이 VPC 엔드포인트 사용

 

* AWS Direct Connect : 온프레미스-클라우드 전용 네트워크


611
타사 공급업체에서 거의 실시간으로 데이터를 수신할 수 있는 REST 기반 인터페이스가 있는 애플리케이션 → 수신되면 애플리케이션은 데이터를 처리하고 추가 분석을 위해 저장 + 애플리케이션은 EC2 인스턴스에서 실행중 → 데이터를 보낼 때 많은 503 서비스 사용 불가 오류 수신 + 데이터 볼륨이 증가하면 컴퓨팅 용량이 최대 한도에 도달하고 애플리케이션은 모든 요청을 처리 X → 확장성이 뛰어난 솔루션 제공 

 

더보기

A. Amazon Kinesis Data Streams를 사용하여 데이터를 수집합니다. AWS Lambda 함수를 사용하여 데이터를 처리합니다.


* Kinesis Data Streams: 대량의 스트리밍 데이터 수집 및 처리량을 처리할 수 있는 자동 확장 스트림을 제공 → 데이터 수신 주변의 병목 현상이 제거.

* AWS Lambda는 확장 가능한 서버리스 방식으로 데이터를 처리하고 저장하여 EC2 용량 제한을 피할 수 있음

 


612
프라이빗 서브넷의 EC2 인스턴스에서 실행되는 애플리케이션 + S3 버킷에서 민감한 정보를 처리 → 인터넷을 사용하여 S3에 연결 x

 

더보기

D. VPC 엔드포인트를 구성합니다. S3 버킷 정책을 업데이트하여 VPC 엔드포인트에서 액세스를 허용합니다. 애플리케이션을 업데이트하여 새 VPC 엔드포인트를 사용합니다.


 613 
EKS를 사용하여 컨테이너 애플리케이션 실행 + EKS 클러스터는 Kubernetes secrets 객체에 민감한 정보를 저장 → 회사는 정보가 암호화되었는지 확인 + 최소한의 운영 오버헤드 

 

더보기

B. AWS Key Management Service(AWS KMS)를 사용하여 EKS 클러스터에서 비밀 암호화를 활성화합니다.

 

⇒ KMS는 EKS와 통합되어 자동으로 암호화 가능. 오버헤드가 거의 없음. 

AWS KMS 키를 사용하여 클러스터 수준에서 비밀 암호화 활성화
EKS 클러스터에 대한 최소한의 구성 변경만 필요하고 코드를 변경할 필요가 없음


614
 ASG 일부로 EC2 인스턴스에서 실행되는 웹 및 애플리케이션 서버 + 데이터 스토리지를 위한 RDS DB 인스턴스 → 웹 서버만 액세스할 수 있도록 애플리케이션 서버에 대한 액세스를 제한 

 

더보기

D. 애플리케이션 서버의 자동 확장 그룹을 포함하는 대상 그룹으로 애플리케이션 로드 밸런서를 배포합니다. 웹 서버만 애플리케이션 서버에 액세스할 수 있도록 보안 그룹을 구성합니다.


⇒ 웹 서버이므로 애플리케이션 로드밸런서 배포 + 웹 서버만 애플리케이션 서버에 액세스할 수 있도록 보안그룹 구성


615
 EKS에서 실행되는 마이크로서비스 아키텍처 → 중앙 위치에서 애플리케이션의 메트릭과 로그를 수집,집계, 요약하는 솔루션을 구현 

 

더보기

D. 기존 EKS 클러스터에서 Amazon CloudWatch Container Insights를 구성합니다. CloudWatch 콘솔에서 메트릭과 로그를 확인합니다.

 

마이크로 서비스 모니터링 → 컨테이너 중심의 도구 필요

 

* Amazon CloudWatch Container Insights: EKS 모니터링 + 컨테이너화된 애플리케이션과 마이크로서비스에서 메트릭과 로그를 수집, 집계 및 요약

 

* AWS App Mesh: 서비스 간의 통신을 관리

* CloudTrail: AWS 계정에서 발생하는 API 호출 및 이벤트를 기록. AWS 리소스에 대한 변경 사항을 추적

* Amazon OpenSearch Service: 실시간 검색 및 로그 분석을 위한 관리형 서비스로, 데이터를 인덱싱하고 쿼리


616
회사가 AWS에 최신 제품 배포 + 제품은 NLB 뒤의 ASG 그룹에서 실행 + 제품의 객체를 S3 버킷에 저장 + 최근 시스템에 악의적인 공격 경험 → AWS 계정, 워크로드, S3 버킷에 대한 액세스 패턴에서 악의적인 활동을 지속적으로 모니터링하는 솔루션 + 의심스러운 활동을 보고하고 대시보드에 정보를 표시 

 

더보기

C. Amazon GuardDuty를 구성하여 모니터링하고 결과를 AWS Security Hub에 보고합니다.

 

* Amazon Macie: AWS에 저장된 민감한 데이터를 검색, 분류 및 보호하는 데 도움이 되는 서비스
* Amazon Inspector: 소프트웨어 취약성 및 의도하지 않은 네트워크 노출에 대해 AWS 워크로드를 지속적으로 스캔하는 자동화된 취약성 관리 서비스 ex) EC2, ECR 취약점 발견

 

* Amazon GuardDuty: AWS 계정 및 워크로드에서 악의적 활동을 모니터링하고 상세한 보안 조사 결과를 제공하여 가시성 및 해결을 촉진하는 위협 탐지 서비스
ex) AWS CloudTrail, VPC, EKS, DNS의 로그분석


617
 온프레미스 데이터 센터를 AWS로 마이그레이션 + 데이터 센터는 NFS 기반 파일 시스템에 데이터를 저장하는 스토리지 서버 + 200GB의 데이터 보관 → 기존 서비스를 중단하지 않고 데이터를 마이그레이션 + NFS 프로토콜 사용 + 비용 효율적 

 

더보기

B. Amazon Elastic File System(Amazon EFS) 파일 시스템을 만듭니다.

E. 온프레미스 데이터 센터에 AWS DataSync 에이전트를 설치합니다. 온프레미스 위치와 AWS 간에 DataSync 작업을 사용합니다. 


* AWS EFS: 간단하고 확장 가능하며 탄력적인 완전관리형 NFS 파일 시스템 + POSIX 규정 준수 공유 파일 스토리지
* AWS DataSync: 기존 서비스를 중단하지 않고 온프레미스 NFS 서버에서 EFS로 마이그레이션을 수행


618
us-east-1 지역에서 볼륨으로 마운트된 SMB 파일 공유가 있는 EC2 인스턴스에 FSx for Windows File Server를 사용 + 파일 시스템을 us-west-2 지역으로 복제 + 데이터는 5년 동안어떤 사용자도 삭제해서는 안됨.

 

더보기

C. us-east-1에 Multi-AZ 배포 유형이 있는 FSx for Windows File Server 파일 시스템을 만듭니다. AWS Backup을 사용하여 백업을 us-west-2로 복사하는 백업 규칙을 포함하는 일일 백업 계획을 만듭니다. us-west-2의 대상 볼트에 대해 규정 준수 모드에서 AWS Backup Vault Lock을 구성합니다. 최소 5년의 기간을 구성합니다.

 

⇒ 고가용성 = 다중 AZ 데이터

어떤 사용자도 삭제 x = 규정 준수 모드


619
Organizations를 통해 개발자에게 개별 AWS 계정을 제공 → 개별 개발자는 자신의 계정에 대한 AWS 계정 루트 사용자 수준 액세스 권한을 가지므로 새 개발자 계정에 적용되는 필수 AWS CloudTrail 구성이 수정되지 않도록 하려함 

 

더보기

C. CloudTrail 변경을 금지하는 서비스 제어 정책(SCP)을 만들고 개발자 계정에 연결합니다.

 

⇒ Organizations + 제한 ⇒ SCP (서비스 제어 정책)


620
AWS 클라우드에 중요한 애플리케이션 배포 → 일관되고 지연시간이 짧은 성능을 갖춘 내구성 있는 스토리지  

 

더보기

⇒ 프로비저닝된 IOPS SSD Amazon EBS 볼륨


 621 
온라인 사진 공유 회사가 us-west-1 지역에 있는 S3 버킷에 사진을 저장 → us-east-1 지역에 있는 모든 새 사진의 사본을 저장해야함 + 최소한의 운영 노력 
 

더보기

A. us-east-1에 두 번째 S3 버킷을 만듭니다. S3 Cross-Region Replication을 사용하여 기존 S3 버킷에서 두 번째 S3 버킷으로 사진을 복사합니다.

 

* S3 버킷의 교차 출처 리소스 공유(CORS) : 브라우저가 다른 도메인에서 리소스를 요청할 수 있도록 허용하거나 거부하는 설정으로, S3 버킷 간 데이터 복사와는 관련이 없음
* S3 Cross-Region Replication: 특정 리전에 S3 버킷을 다른 리전의 S3 버킷에 복제하는것(가장 적은 운영 오버헤드, S3 기본 내부의 기능)


622 
새로운 웹 애플리케이션 생성 + 정적 단일 페이지와 영구 데이터베이스 계층으로 구성 + 오전 4시간 동안 수백만 명의 사용자를 보유, 나머지 시간 동안에는 수천 명의 사용자만 보유 → 가장 큰 확장성 제공 

 

더보기

A. Amazon DynamoDB를 데이터베이스 솔루션으로 배포합니다. 주문형 용량(On-demand)을 프로비저닝합니다.

D. 정적 콘텐츠를 Amazon S3 버킷에 배포합니다. S3 버킷을 원본으로 하여 Amazon CloudFront 배포를 프로비저닝합니다.


⇒ DynamoDB → On-demand 프로비저닝(온디맨드는 자동확장보다 확장성이 뛰어남)

트래픽이 일관되지 x = 온디맨드 
정적 컨텐츠 S3 → CloudFront 배포


623
 API Gateway 사용하여 타사 서비스 제공자가 액세스하는 REST API를 관리 → SQL 주입 및 크로스 사이트 스크립팅 공격으로부터 보호 

더보기

⇒ AWS WAF 사용


624 
Active Directory 사용자 그룹을 통해 온프레미스 리소스에 대한 액세스를 보존하는 동시에 AWS 리소스에 대한 사용자 액세스 관리 

 

더보기

D. SAML(Security Assertion Markup Language) 2.0 기반 페더레이션을 구성합니다. 적절한 정책이 첨부된 역할을 만듭니다. 역할을 Active Directory 그룹에 매핑합니다.

 

⇒ SAML: 하나의 자격 증명으로 한 번만 로그인하여 여러 앱에 액세스할 수 있도록 해 주는 기술, 사용자가 로그인하면 ID 공급자가 사용자를 확인한 후 사용자가 액세스하려는 사이트, 서비스 또는 앱의 서비스 공급자 측으로 인증 데이터를 전달

ID 공급자 ⇒ 온프레미스 AD

서비스 공급자 ⇒ AWS


625
애플리케이션 로드 밸런서 뒤에 웹사이트를 호스팅 + 전 세계적으로 콘텐츠에 대한 다른 배포 권한 → 배포 권한을 위반하지 않고 사용자에게 올바른 콘텐츠가 제공되도록 

 

더보기

C. 지리적 위치 정책으로 Amazon Route 53 구성


* Route 53 지리적 위치 정책: 지정된 웹 배포를 통해 배포하는 모든 파일에 대해 국가 수준에서 콘텐츠 배포를 제어 가능


626
사내에 데이터 저장 + 가용 용량을 초과하여 증가 → 사내 위치에서 S3 버킷으로 데이터를 마이그레이션 + 전송 후 데이터 무결성을 자동으로 검증하는 솔루션 

 

* 데이터 무결성: 데이터가 저장, 전송 또는 처리되는 동안 변형되지 않도록 보장

더보기

B. 온프레미스에 AWS DataSync 에이전트를 배포합니다. DataSync 에이전트를 구성하여 S3 버킷으로 온라인 데이터 전송을 수행합니다.

 

* AWS DataSync: Direct Connect를 통해 온프레미스에서 AWS 환경으로 대용량 데이터 세트 효율적으로 전송 가능 + 전송 프로세스 중에 데이터에 지속적으로 액세스하고 업데이트 가능


627
한 회사에서 두 개의 DNS 서버를 AWS로 마이그레이션 + 약 200개의 존을 호스팅하고 매일 평균 100만 개의 요청을 받음 → 회사는 두 서버의 관리와 관련된 운영 오버헤드를 최소화하면서 가용성을 극대화하려고함 

 

더보기

A. Amazon Route 53 콘솔에서 200개의 새로운 호스팅 영역을 만듭니다. 영역 파일을 가져옵니다.


⇒ Route 53의 영역 가져오기
운영 오버헤드를 최소화하면서 가용성을 극대화 =  severless = Amazon Route 53

 

* Amazon Route 53: AWS의 관리형 DNS 서비스로, 두 개의 DNS 서버를 직접 관리하는 대신 AWS에서 자동으로 처리


628
Organizations의 여러 AWS 계정에서 애플리케이션 실행 + 멀티파트 업로드를 사용하여 여러 리전의 여러 S3버킷의 데이터를 업로드 → 비용 준수 목적으로 불완전한 멀티파트 업로드를 보고하려고함 + 가장 적은 운영 오버헤드 

 

더보기

C. S3 Storage Lens를 구성하여 완료되지 않은 멀티파트 업로드 객체 수를 보고합니다.


* S3 Storage Lens: S3의 저장소 사용량과 성능을 시각적으로 분석할 수 있는 도구 + 불완전한 멀티파트 업로드 객체 수 모니터링 + 완전 관리형 S3 스토리지 분석 솔루션
* Incomplete MPU Bytes: 불완전한 멀티파트가 있는 범위의 총 바이트를 보여줌


629
RDS for MYSQL에서 프로덕션 데이터베이스 운영 + 보안 규정 준수를 위해 데이터베이스 버전을 업그레이드하려고함 → 중요한 데이터가 포함되어 있으므로 데이터를 잃지 않고 기능을 업그레이드하고 테스트할 수 있는 빠른 솔루션 + 가장 적은 운영 오버헤드 

 

더보기

D. Amazon RDS Blue/Green 배포를 사용하여 프로덕션 변경 사항을 배포하고 테스트합니다.

 

* Blue/Green 배포: 데이터베이스 패치 및 시스템 업데이트로 최신 상태를 유지 애플리케이션을 변경하지 않고도 스테이징 환경을 새 프로덕션 환경으로 전환

전환 중 데이터 손실X


630
하루에 한 번 실행되고 완료하는데 최대 2시간이 걸릴 수 있는 데이터 처리 작업을 만들고 있음 + 작업이 중단되면 처음부터 다시 시작해야함 → 가장 비용 효율적인 방식

 

더보기

C. Amazon EventBridge 예약된 이벤트에 의해 트리거되는 Amazon Elastic Container Service(Amazon ECS) Fargate 작업을 사용합니다. 

 

* Fargate: EKS 또는 ECS에서 실행되는 동안 컨테이너화된 앱이 사용하는 vCPU, RAM, OS, CPU 아키텍처 및 스토리지 양에 따라 요금 청구


⇒ Lambda: 최대 15분 실행이므로 X
EC2: 비용 비쌈


 

728x90
반응형