클라우드/AWS

[Associate SAA-C03] - dump 정리 651 ~ 700

코딩하는 도람쥐 2024. 10. 13. 18:27

651

S3 버킷에 대량의 이미지 파일 저장 + 180일 동안 쉽게 사용해야함 + 다음 180일 동안은 거의 액세스하지 않음 + 360일 후에는 이미지를 보관하지만 즉시 사용할 수 있어야함 + 5년 후에는 감사자만 이미지에 액세스 + 12시간 이내에 이미지를 검색할 수 있어야함 

 

더보기

C. 180일 후에 객체를 S3 Standard-Infrequent Access(S3 Standard-IA)로, 360일 후에 S3 Glacier Instant Retrieval로, 5년 후에 S3 Glacier Deep Archive로 전환합니다.


이미지 손실 X ⇒ Standard-IA : 여러가용 영역 ↔ One-Zone-IA: 단일 가용 영역 → 이미지 손실 o
12시간 이내 검색 ⇒ Glacier Deep Archive
보관용 + 요청 시 즉시 사용 가능 ⇒ Glacier Instant Retrieval

 

- Glacier Flexible Retrieval: 검색에 3~5시간 소요

- Glacier Instant Retrieval: 즉각적인 데이터 액세스 제공


652
매일 6시간씩 실행되는 대규모 데이터 워크로드 + 프로세스 실행동안 데이터를 잃을 수 없음 + 중요한 데이터 워크로드를 지원하기 위해 EMR 클러스터 구성을 설계 + 가장 비용 효율적 

 

더보기

B. 온디맨드 인스턴스에서 기본 노드와 핵심 노드를 실행하고 스팟 인스턴스에서 작업 노드를 실행하는 임시 클러스터를 구성합니다.

 

데이터 손실 불가 ⇒ 온디맨드

스팟 인스턴스: 데이터 손실 위험 


* 임시 클러스터: 계산 시간 동안만 실행되므로 비용 절감 효과(작업 부하가 완료될 때까지 실행)


653
Organizations 조직의 특정 계정에서 생성된 모든 리소스에 태그를 지정하는 솔루션 + 리소스를 만든 사용자의 비용 센터 ID로 각 리소스에 태그 지정

 

더보기

A. 특정 AWS 계정을 관리 계정에서 Organizations의 새 조직 단위(OU)로 이동합니다. 리소스를 만들기 전에 모든 기존 리소스에 올바른 비용 센터 태그가 있어야 하는 서비스 제어 정책(SCP)을 만듭니다. 새 OU에 SCP를 적용합니다.


* AWS SCP: 조직 내 권한을 관리하는 데 사용할 수 있는 일종의 조직 정책
→ 조직에서 무엇이든 제한할 때는 SCP 정책 사용


654 
웹 애플리케이션을 AWS 클라우드로 마이그레이션 + EC2 인스턴스를 사용하여 애플리케이션 호스팅 + 정적 콘텐츠를 제공하는 Apache 웹 서버 포함 + Apache 웹 서버는 사용자 세션을 위해 로컬 Redis 서버를 사용하는 PHP 애플리케이션에 요청 + 고가용성으로 재설계 + AWS 관리 솔루션

 

더보기

D. 정적 콘텐츠를 호스팅하도록 구성된 S3 버킷에 Amazon S3 엔드포인트가 있는 Amazon CloudFront 배포를 구성합니다. PHP 애플리케이션에 대한 AWS Fargate 작업을 실행하는 Amazon Elastic Container Service(Amazon ECS) 서비스를 대상으로 하는 Application Load Balancer를 구성합니다. 여러 가용성 영역에서 실행되는 Amazon ElastiCache for Redis 클러스터를 사용하도록 PHP 애플리케이션을 구성합니다.

 

고가용성으로 재설계: ElastiCache for redis ⇒ 세션 정보를 처리 + 다중 가용 영역

⇒ S3 + CloudFront: 정적 콘텐츠 호스팅 + 고가용성 
⇒  EC2 + Linux + PHP ⇒ Fargate 와 좋은 조합

 

EC2 인스턴스: 직접 인스턴스를 관리해야 하므로 운영 오버헤드가 더 크고, 완전한 관리형 서비스가 아님

Elastic Beanstalk: 자동확장, 모니터링, 관리형 서비스 


655
웹 애플리케이션 + 회사는 더 나은 사용자 경험을 위해 세션 친화성(스티키 세션)과 함께 작동하도록 애플리케이션 설계 → 애플리케이션은 엔드포인트로서 인터넷을 통해 공개적으로 사용할 수 있어야함 + 추가 보안을 위해 WAF를 엔드포인트에 적용 + 스티키 세션을 엔드포인트에 구성해야함 

 

더보기

C. 퍼블릭 애플리케이션 로드 밸런서를 만듭니다. 애플리케이션 대상 그룹을 지정합니다.

E. AWS WAF에서 웹 ACL을 만듭니다. 웹 ACL을 엔드포인트와 연결합니다.

 

* 스티키 세션(친환경): 로드 밸런서 사용 시 항상 동일한 서버 인스턴스에 연결되도록 하는 기능. 
⇒ Network Load Balancer, Gateway Load Balancer : 스티키 세션 처리 불가능
웹에서 접근 가능하게 만드려면 Public ALB + 보안적으로 WAF의 웹 ACL (웹 ACL을 ALB에 통합)

* ACL: 웹 트래픽을 제어하고 보호하는 규칙들의 집합. 트래픽 필터링. 규칙 정의. 모니터링


656

역사적 사건의 이미지를 저장하는 웹사이트 운영 + 사건이 발생한 연도를 기준으로 이미지를 검색하고 볼 수 있는 기능 필요 + 평균적으로 사용자는 1년에 한 두번만 이미지 요청 → 이미지를 저장하고 사용자에게 전달하기 위한 고가용성 솔루션 + 비용 효율적 

 

더보기

D. Amazon S3 Standard-Infrequent Access(S3 Standard-IA)에 이미지를 저장합니다. S3 Standard-IA를 사용하여 정적 웹사이트를 사용하여 이미지를 직접 전달합니다.


⇒ S3 Infrequent Access 사용 (드물게 액세스되는 데이터를 위해 설계 , S3 Standard에 비해 저장 비용 낮음)


657

Organizations의 조직에 여러 AWS 계정 + 전 세계에 여러 사무실 + 보안 그룹 규칙을 업데이트하여 새로운 CIDR 범위를 허용하거나 조직 전체에서 오래된 CIDR 범위를 제거해야함 → CIDR 범위를 업데이트하는데 필요한 관리 오버헤드를 최소화하기 위해 보안 ⇒ 고객 관리 접두사 목록을 사용하면 CIDR 범위를 한 곳에서 관리 가능 + 가장 비용 효율적

 

더보기

B. CIDR 목록을 포함하는 VPC 고객 관리 접두사 목록을 만듭니다. AWS Resource Access Manager(AWS RAM)를 사용하여 조직 전체에서 접두사 목록을 공유합니다. 조직 전체의 보안 그룹에서 접두사 목록을 사용합니다.


* AWS Resource Access Manager (AWS RAM): 접두사 목록을 조직 전체에 공유할 수 있어 각 계정에서 동일한 접두사 목록을 사용할 수 있음. 중앙에서 업데이트하면 조직 전체에 동일한 업데이트. 

⇒ 접두사 목록: CIDR을 정의한 후 보안 그룹에 정의 가능. 접두사 목록을 사용하는 모든 보안 그룹이 자동으로 업데이트 되어 오버헤드가 줄어듦. 중앙 집중화된 관리


658 
온프레미스 네트워크 연결 스토리지(NAS) 시스템을 사용하여 고성능 컴퓨팅(HPC) 워크로드에 파일 공유 제공 → 지연에 민감한 HPC 워크로드와 스토리지를 AWS클라우드로 마이그레이션 + NFS 와 SMB 다중 프로토콜 액세스 제공 + 가장 짧은 지연 

 

더보기

A. 컴퓨팅 최적화된 EC2 인스턴스를 클러스터 배치 그룹에 배포합니다.

E. EC2 인스턴스를 Amazon FSx for NetApp ONTAP 파일 시스템에 연결합니다.

 

⇒최소 지연 시간 = 클러스터 배치 그룹

Amazon FSx for Lustre = SMB
Amazon FSx for OpenZFS = NFS
Amazon FSx for NetApp ONTAP = NFS, SMB, iSCSI

 

659
 2주 안에 AWS에 50TB의 데이터 전송 +  Site-to-Site VPN 연결 + 이미 90%의 활용도가 사용됨 

 

더보기

C. AWS Snowball Edge 스토리지 최적화


660
ASG의 On-Demand 인스턴스에서 애플리케이션 호스팅 + 피크 시간은 매일 같은 시간에 발생 + 피크 시간 시작 시 애플리케이션 성능이 느리다고 보고 + 피크 시간이 시작된 후 2~3시간 후 정상적으로 실행 → 피크 시간 시작 시 애플리케이션이 작동하는지 확인 

 

더보기

D. 자동 크기 조정 그룹이 피크 시간 전에 새 인스턴스를 시작할 수 있도록 예약된 크기 조정 정책을 구성합니다.


⇒ 예약된 확장 정책 : 매일 동일한 시간에 발생
동적 확장 정책: 예측 불가능한 작업


661
회사의 RDS 데이터베이스에 연결되는 AWS에서 애플리케이션 실행 + 주말과 연중 피크 타임에 확장 → 데이터베이스에 연결되는 애플리케이션에 대해 데이터베이스를 보다 효과적으로 확장 + 가장 적은 운영 오버헤드  

 

더보기

B. 데이터베이스의 대상 그룹과 함께 Amazon RDS Proxy를 사용합니다. RDS Proxy 엔드포인트를 사용하도록 애플리케이션을 변경합니다. 


⇒ RDS Proxy: RDS를 위해 완벽하게 관리되고 고가용성인 데이터베이스 프록시로, DB 장애에 대한 애플리케이션의 복원력을 높여줌 + 애플리케이션이 DB와 설정된 연결을 풀링하고 공유하여 DB 효율성과 애플리케이션의 확장성을 개선할 수 있음

 

* 연결 풀링: 데이터베이스와 연결을 자주 열고 닫을 때 발생하는 성능 부담을 줄이기 위해, 연결 풀이라는 미리 생성된 데이터베이스 연결들의 풀(pool)을 만들어두고 필요할 때 재사용


662 
Cost Explorer 사용하여 AWS 비용 모니터링 + EBS 스토리지 및 스냅샷 비용이 매달 증가한다는 것을 발견 + 회사는 추가 EBS 스토리지를 구매 X → 현재 스토리지 사용량에 대한 월별 비용을 최적화 + 가장 적은 운영 오버헤드 

 

더보기

D. 모든 불필요한 스냅샷을 삭제합니다. Amazon Data Lifecycle Manager를 사용하여 회사의 스냅샷 정책 요구 사항에 따라 스냅샷을 만들고 관리합니다. 


* AWS Cost Explorer: 비용과 사용량을 보고 분석할 수 있는 도구, 알람 기능은 없음, 보고서 기능 제공 , 최대 12개월 이전의 데이터를 소급해서 확인 가능
* Amazon Data Lifecycle Manager (DLM): 스냅샷 생명 주기 정책을 자동화하여 스냅샷의 생성 및 삭제를 관리할 수 있습니다. 이를 통해 스냅샷 관리를 자동화하고 운영 오버헤드를 줄일 수 있음


663 
새로운 애플리케이션 개발 + ECS 클러스터, S3 버킷, RDS for MYSQL 데이터베이스 + 데이터베이스에는 민감한 정보가 들어있음 → EC2 클러스터만 RDS for MYSQL 데이터베이스의 데이터와 S3 버킷의 데이터에 액세스할 수 있도록 하려고함 

 

더보기

A. S3 버킷과 RDS for MySQL 데이터베이스를 모두 암호화하기 위해 새로운 AWS Key Management Service(AWS KMS) 고객 관리 키를 만듭니다. KMS 키 정책에 ECS 작업 실행 역할에 대한 암호화 및 암호 해독 권한이 포함되어 있는지 확인합니다.


⇒ 네트워크 수준의 보안만으로는 민감한 데이터에 대한 완벽한 보호를 제공하지 못함
* AWS KMS 고객 관리 키: 사용자 지정 키를 생성하여 데이터 암호화 및 암호 해독에 사용
* KMS 키 정책: ECS 작업 실행 역할에 암호화 및 암호 해독 권한을 부여하여, 해당 역할이 S3 버킷과 RDS 데이터베이스의 암호화된 데이터를 처리


 664 
온프레미스에서 실행되는 웹 애플리케이션 + 피크 시간동안 지연 문제를 겪음 + 매달 두 번 발생 + 지연 문제: CPU 사용률이 정상 수준의 10배로 즉시 증가 → 지연 시간 개선을 위해 AWS로 마이그레이션 + 수요가 증가하면 자동으로 확장하려고함 + 배포에 Elastic Beanstalk 사용 

 

더보기

* Elastic Beanstalk : 완전 관리형 서비스. 코드로 자동 인프라 설정, 배포, 확장, 모니터링. 개발자가 인프라 관리x 로직에만 집중.

 

A. 무제한 모드에서 버스트 가능한 성능 인스턴스를 사용하도록 Elastic Beanstalk 환경을 구성합니다. 요청에 따라 확장되도록 환경을 구성합니다.


⇒ 무제한 모드에서 버스트 가능 성능 인스턴스를 사용하면 애플리케이션이 필요할 때 기준 성능을 넘어 버스트 가능

"즉각적으로 증가" ⇒ 예측할 수 없고 예측 지표를 사용 불가능 + 요구 사항은 자동 스케일링이 필요

필요할 때마다 성능을 일시적으로 증가시킬 수 있도록 설정하며, CPU 크레딧이 부족해도 성능 제한 없이 계속 동작


665
회사에는 전 세계에 고객 존재 + 자동화를 사용하여 시스템과 인프라를 보호 → 인프라에 모든 증분적 변경사항 추적, 감사

 

더보기

B. AWS CloudFormation을 사용하여 인프라를 설정합니다. AWS Config를 사용하여 변경 사항을 추적합니다.

⇒ 구성변경 사항 : Config


* AWS CloudFormation: 자동화를 사용하여 시스템 및 네트워크 인프라 보호
* AWS Config: 보안 및 거버넌스를 위한 리소스 인벤토리, 구성 내역, 구성 변경 알림을 제공하는 완전 관리형 서비스 + 인프라에 대한 모든 증분 변경 사항을 추적

* AWS Service Catalog: 리소스 효율적 관리, 배포 


666
EC2 인스턴스에서 웹 사이트 호스팅 + 상태 비저장 Python 애플리케이션 + MYSQL 데이터베이스 → 안정성에 대해 우려 + 고가용성으로 마이그레이션 + 코드 수정 불가능 + 고가용성 달성 

 

더보기

B. Amazon RDS for MySQL Multi-AZ DB 인스턴스로 데이터베이스를 마이그레이션합니다.

E. 두 개의 가용성 영역에 분산된 EC2 인스턴스의 자동 크기 조정 그룹에 트래픽을 분산하기 위한 애플리케이션 부하 분산 장치를 생성합니다. 


⇒ 데이터베이스 Multi-AZ로 마이그레이션 + EC2의 Auto Scailing Group 앞단에 ALB 설정

장애조치 + 가용성


#667
마이그레이션 중 + 회사의 AWS 리전과 온프레미스 위치에서 S3의 데이터에 안전하게 액세스 + 인터넷을 통과 X + AWS Direct Connect 연결

 

더보기

C. Amazon S3에 대한 인터페이스 엔드포인트를 만듭니다. 인터페이스 엔드포인트를 사용하여 Region과 온프레미스 위치에서 데이터에 안전하게 액세스합니다. 

 

* S3 Gateway VPC Endpoint ⇒ 트래픽이 인터넷을 통과하는 것을 방지(프라이빗 연결) S3, DynamoDB 만 지원 + VPC 내부에서만 액세스 가능 → 온프레미스와 연결 x

* 인터페이스 VPC 엔드포인트: VPN 및 AWS Direct Connect를 통해 온프레미스에 있는 애플리케이션에서 직접 액세스할 수 있으며, VPC 피어링을 통해 다른 AWS 리전에 있는 애플리케이션에서 액세스 → PrivateLink를 통해 Amazon S3에 안전하게 연결 + 인터넷 통과 x


668 
Organizations에 새로운 조직 생성 + 개발팀을 위한 여러 계정 + IAM Identity Center(AWS Single Sign-On) 사용하여 계정에 액세스 → 개발팀은 미리 정의된 애플리케이션 이름을 사용하여 생성된 리소스에 태그를 지정해야함 + 이름 태그에 승인된 값이 있는 경우에만 리소스를 생성할 수 있는 솔루션을 설계 

 

더보기

D. 허용된 애플리케이션 이름 목록이 있는 태그 정책을 조직에 만듭니다.

 

* IAM Identity Center(AWS Single Sign-On): 사용자 관리 및 접근 제어. 하나의 자격 증명으로 여러 AWS 접근, 중앙 집중식 관리 
* 태그 정책: 지정된 리소스 유형에 대한 비준수 태그 작업이 시행되도록 지정 가능 + 모든 계정에서 태그 규칙 정의하고 시행. 

 

⇒ IAM 정책은 태그 값의 유효성을 직접 검증할 수 없음. 


669

RDS for PostgreSQL에서 데이터베이스 실행 + 30일마다 암호를 순환하여 마스터 사용자 암호를 관리하는 안전한 솔루션 원함 

→ 가장 적은 운영 오버헤드 

 

더보기

C. AWS Secrets Manager를 Amazon RDS for PostgreSQL과 통합하여 비밀번호 교체를 자동화합니다.

⇒ 자격 증명 관리 운영 오버헤드 최소화 ⇒ 자동 회전 기능이 있는 Secrets Manager

 

* AWS Secrets Manager: 애플리케이션, 서비스 및 리소스에 대한 액세스를 보호하는데 도움이 되는 비밀 관리 서비스


670
DynamoDB 테이블을 사용하는 애플리케이션에서 테스트 수행 + 일주일에 한 번 4시간동안 실행 + 테스트 중에 애플리케이션이 테이블에 대해 초당 수행하는 읽기 및 쓰기 작업 수를 알고 있음 + 테이블 비용 최적화 

 

더보기

B. 프로비저닝 모드를 선택합니다. 읽기 및 쓰기 용량 단위를 적절히 업데이트합니다.

 

* 프로비저닝된 용량 모드: 필요한 초당 읽기 및 쓰기 수를 지정하고 , 그에 따라 요금 청구 + 예측 가능한 트래픽 패턴이 있을때 사용
* 주문형 모드: 예측할 수 없거나 상당하거나 일관된 데이터베이스 트래픽이 없는 워크로드에 적합


671 
회사는 AWS 비용에 대한 주기적 재무 평가 수행 + 최근에 비정상적인 지출 확인 → 비정상적인 지출을 방지하기 위한 솔루션 + 비정상적인 지출이 발생하는 경우 이해관계자에게 알려야함 

 

더보기

B. AWS Billing and Cost Management 콘솔에서 AWS 비용 이상 감지 모니터를 만듭니다.

 

* Billing and Cost Management의 비용 이상 감지: 비정상적인 지출 패턴을 자동으로 감지하도록 설계


672

S3에 대량의 새로운 클릭스트림 데이터 수신 + S3의 클릭스트림 데이터를 빠르게 분석 → 데이터 파이프라인에서 데이터를 추가로 처리할지 여부 결정 + 가장 적은 운영 오버헤드 

 

*  Amazon S3의 클릭스트림 데이터: 사용자가 수행하는 각 클릭 이벤트에 대한 정보를 기록한 데이터

 

더보기

B. AWS Glue 크롤러를 구성하여 데이터를 크롤링합니다. Amazon Athena를 구성하여 데이터를 쿼리합니다.

 

AWS Glue 크롤러 + Amazon Athena = S3에 저장된 데이터를 쿼리하는 데 최적화


* AWS Glue: 완전 관리형 추출, 변환 및 로드(ETL) 서비스
* AWS Glue 크롤러: 데이터에 대한 스키마 생성 + Athena를 사용하여 별도의 데이터베이스에 로드할 필요 없이 직접 데이터를 쿼리

* Athena: SQL 쿼리를 사용하여 Amazon S3에서 직접 데이터를 분석할 수 있는 서버리스 쿼리 서비스

 

Kinesis Data Analytics: 주로 스트리밍 데이터를 실시간으로 처리하기 위해 설계되었습니다. 클릭스트림 데이터는 일반적으로 대량의 데이터가 일괄로 수신되며, 이를 실시간으로 처리하는 것이 필요한 경우는 드물음.


673
데이터 센터에서 SMB 파일 서버 운영 + 대용량 파일을 파일 생성일로부터 최대 7일 동안 저장 + 7일 후 최대 24시간의 검색 시간으로 파일에 액세스해야함 

 

더보기

B. 회사의 저장 공간을 늘리기 위해 Amazon S3 파일 게이트웨이를 만듭니다. 7일 후 S3 Glacier Deep Archive로 데이터를 전환하기 위한 S3 라이프사이클 정책을 만듭니다.


* Amazon S3 File Gateway: SMB와 NFS를 지원
* Amazon FSx File Gateway: Windows 워크로드를 위한 SMB를 지원 + S3가 아닌 FSx for Windows 파일 서버에 파일 저장

* S3 Glacier Flexible Retrieval: 장기저장, 몇 분 이내 검색 가능. 


 674 
 ASG의 EC2 인스턴스에서 웹 애플리케이션 실행 + RDS for PostgreSQL DB 인스턴스에서 실행되는 데이터베이스 사용 → 트래픽이 증가하면 애플리케이션이 느리게 실행 + 트래픽이 많은 기간동안 많은 읽기 부하 경험  

더보기

트래픽이 많은 기간 동안 많은 읽기 부하 경험 ⇒ 성능 문제 해결 + 부하 분산

 

B. DB 인스턴스에 대한 읽기 복제본을 만듭니다. 읽기 복제본에 읽기 트래픽을 보내도록 애플리케이션을 구성합니다.

D. Amazon ElastiCache 클러스터를 만듭니다. ElastiCache 클러스터에서 쿼리 결과를 캐시하도록 애플리케이션을 구성합니다.

 

1. 읽기 복제본 생성: 읽기 트래픽을 오프로드하여 부하 분산 및 전반적인 성능 개선
2. ElastiCache: 자주 액세스하는 데이터를 캐시하여 DB의 부하 줄일 수 있음

⇒ 대기 DB 인스턴스로 읽기 트래픽 전송"은 작동X


675
회사는 규정 요구 사항을 충족하기 위해 EBS 볼륨의 스냅샷을 하나씩 생성 + 규정 준수 요구 사항 → EBS 볼륨의 스냅샷을 실수로 삭제되는 것을 방지하는 아키텍처를 구현하려고함 + 스토리지 관리자 사용자의 권한을 변경해서는 안됨 + 최소한의 관리 노력 

 

더보기

D. EBS 스냅샷을 잠가 삭제를 방지합니다.


⇒ EBS 스냅샷 잠금: “잠금” 기능을 사용하면 EBS의 스냅샷을 포함한 리소스를 실수로 삭제하는 것을 방지 가능(스냅샷 수준에서 설정 가능하므로 관리자의 권한 변경 X)


676
NLB, ASG + 회사는 VPC에서 거의 실시간으로 네트워크로 인터페이스로 들어오고 나가는 트래픽에 대한 정보를 수집 → 분석을  해 OpenSearch Service로 정보를 보내려고함 

 

더보기

B. Amazon CloudWatch Logs에서 로그 그룹을 만듭니다. VPC Flow Logs를 구성하여 로그 데이터를 로그 그룹으로 보냅니다. Amazon Kinesis Data Firehose를 사용하여 로그 그룹에서 OpenSearch Service로 로그를 스트리밍합니다.


* CloudTrail: AWS 계정 활동에 대한 이벤트 로그 캡처하는데 사용, 네트워크 트래픽 정보를 수집하는데 적합하지 않음
* VPC Flow Logs 데이터 → CloudWatch Logs의 로그 그룹으로 전송하면 데이터를 중앙에서 관리하고 분석할 수 있음
* Kinesis Data Firehose: 실시간 데이터 분석 및 OpenSearch 서비스로 전송(S3/Redshift 도 가능)

+ Amazon Kinesis Data Streams은 조금 더 복잡함. 


677 
프로덕션 EKS 클러스터에서 실행되는 애플리케이션 개발 + EKS 클러스터에는 온디맨드 인스턴스로 프로비저닝된 관리형 노드 그룹 존재 + 개발 작업을 위한 전담 EKS 클러스터 필요 → 애플리케이션 복원력을 테스트하기 위해 클러스터를 드물게 사용 + EKS 클러스터는 모든 노드를 관리해야함 + 가장 비용 효율적 

 

더보기

B. 두 개의 관리형 노드 그룹을 만듭니다. 온디맨드 인스턴스로 한 노드 그룹을 프로비저닝합니다. 스팟 인스턴스로 두 번째 노드 그룹을 프로비저닝합니다.


⇒ 개발 클러스터는 드물게 사용되고 애플리케이션 복원력 테스트에 사용되므로, 스팟 인스턴스를 사용( 테스트 목적으로 드물게 사용되며 가장 비용 효율적)


678
S3에 민감한 데이터 저장 + 암호화 솔루션 생성 → 암호화해야 하는 모든 데이터에 대해 최소한의 노력으로 사용자가 암호화 키를 만들고 순환하고 비활성화할 수 있는 기능을 완전히 제어 

 

더보기

B. AWS Key Management Service(AWS KMS)를 사용하여 고객 관리 키를 만듭니다. 새 키를 사용하여 AWS KMS 키(SSE-KMS)를 사용하여 서버 측 암호화를 사용하여 S3 객체를 암호화합니다.


⇒ AWS KMS 사용 + 고객 관리 키

고객이 AWS KMS에서 키를 생성하고 관리할 수 있도록 하며, SSE-KMS를 사용해 S3 객체를 암호화

 

SSE-S3는 Amazon S3에서 제공하는 서버 측 암호화로, S3가 암호화 키를 관리, 사용자는 키 생성, 관리x


679 
온프레미스 가상 머신(VM)을 AWS에 백업하려고함 + 백업 솔루션은 온프레미스 백업을 S3 버킷에 객체로 내보냄

→ S3 백업은 30일 동안 보관해야하고 30일 후에는 자동으로 삭제해야함 (3가지 선택)

 

더보기

A. S3 객체 잠금이 활성화된 S3 버킷을 생성합니다.
30일 동안 보관 ⇒ 객체 잠금(객체 잠금을 활성화하려면 버전 관리 활성화)

 

C. 객체에 대한 기본 보존 기간을 30일로 구성합니다.

기본 보관 기간 : 새 객체에 객체 잠금이 적용 되는 기간

 

E. 30일 후에 객체가 만료되도록 S3 수명 주기 정책을 구성합니다.


680
S3 버킷에서 EFS 파일 시스템과 다른 S3 버킷으로 파일을 복사 + 파일은 지속적으로 복사 →  새 파일은 원래 S3 버킷에 일관되게 추가 + 복사된 파일은 소스 파일이 변경되는 경우에만 덮어써야함 + 가장 적은 운영 오버헤드 

 

더보기

A. 대상 S3 버킷과 EFS 파일 시스템 모두에 대한 AWS DataSync 위치를 만듭니다. 대상 S3 버킷과 EFS 파일 시스템에 대한 작업을 만듭니다. 전송 모드를 변경된 데이터만 전송하도록 설정합니다.


* AWS DataSync: 서로 다른 스토리지 솔루션 간에 효율적이고 안정적인 데이터 복사를 위해 설계, 데이터 전송 자동화. 

변경된 데이터만 전송하도록 전송 모드를 설정하여 AWS DataSync 작업을 설정하면 새 파일이나 수정된 파일만 복사


#681
EC2 인스턴스를 사용하고 EBS 볼륨에 데이터를 저장 + KMS 키를 사용하여 모든 데이터가 저장 중에 암호화되도록 + 회사는 암호화 키의 로테이션을 제어할 수 있어야함 + 최소한의 운영 오버헤드 

 

더보기

A. 고객 관리 키를 만듭니다. 키를 사용하여 EBS 볼륨을 암호화합니다.
⇒ "암호화 키의 회전을 제어할 수 있음" = 고객 관리 키(AWS에서 생성하지만 KMS에서 고객이 관리) 


682 
EC2 인스턴스에서 휴면 상태의 데이터 암호화를 시행하기 위한 솔루션 + 자동으로 비준수 리소스를 식별하고 결과에 대한 규정 준수 정책을 시행 + 가장 적은 운영 오버헤드 

 

더보기

A. 사용자가 암호화된 Amazon Elastic Block Store(Amazon EBS) 볼륨만 생성할 수 있도록 허용하는 IAM 정책을 사용합니다. AWS Config와 AWS Systems Manager를 사용하여 암호화되지 않은 EBS 볼륨의 탐지 및 수정을 자동화합니다.

 

⇒ 사용자가 암호화된 EBS 볼륨만 만들 수 있도록 허용하는 IAM 정책을 만들면 암호화되지 않은 볼륨의 생성을 사전에 방지

 

* AWS Config을 사용하면 비준수 리소스를 감지하는 규칙을 설정
* AWS Systems Manager Automation을 사용하여 자동화된 수정을 수행


* Amazon Macie: AWS에 저장된 민감한 데이터를 검색, 분류 및 보호하는 데 도움이 되는 서비스 + 머신 러닝 알고리즘과 관리 식별자를 사용하여 개인 식별 정보(PII) 및 금융 정보를 포함한 다양한 유형의 민감한 정보를 감지

 

* Amazon Inspector: 소프트웨어 취약성 및 의도하지 않은 네트워크 노출에 대해 AWS 워크로드를 지속적으로 스캔하는 자동화된 취약성 관리 서비스 


683 
다중 계층 온프레미스 애플리케이션을 AWS로 마이그레이션 + 단일 노드 MYSQL 데이터베이스와 다중 노드 웹 계층으로 구성

→ 마이그레이션 중에 애플리케이션의 변경을 최소화 + 마이그레이션 후 애플리케이션의 복원력을 개선 

 

더보기

A. 애플리케이션 로드 밸런서 뒤의 자동 확장 그룹에 있는 Amazon EC2 인스턴스로 웹 계층을 마이그레이션합니다. 

C. 데이터베이스를 Amazon RDS Multi-AZ 배포로 마이그레이션합니다. 


웹 계층 마이그레이션: 애플리케이션 로드 밸런서(ALB) 뒤의 자동 확장 그룹에 있는 Amazon EC2 인스턴스로 웹 계층을 마이그레이션 ⇒ 수평적 확장성, 자동 확장 및 향상된 복원력 제공


Amazon RDS Multi-AZ로의 데이터베이스 마이그레이션: Multi-AZ 배포에서 데이터베이스를 Amazon RDS로 마이그레이션하면 고가용성과 자동 장애 조치가 제공


684

온프레미스에서 AWS로 웹 애플리케이션을 마이그레이션 + 회사는 eu-central-1 지역 근처에 있음 + 규정 때문에 회사는 eu-central-1에서 일부 애플리케이션을 시작할 수 없음 → 회사는 단일 자릿수 밀리초 지연시간을 달성하려고함 

 

더보기

B. 회사의 VPC를 eu-central-1에서 선택한 로컬 영역으로 확장하여 AWS 로컬 영역에 애플리케이션을 배포합니다.


* AWS Local Zone(로컬 영역): 컴퓨팅, 스토리지, 데이터베이스 및 기타 선택 서비스를 대규모 인구, 산업 및 IT 센터에 더 가깝게 배치하여 최종 사용자에게 단일 자릿수 밀리초 지연 시간이 필요한 애플리케이션을 제공
* AWS Wavelength: 모바일 네트워크용

 

⇒ CloudFront의 엣지 위치를 사용하는 것은 전 세계적으로 콘텐츠를 배포하는 데 유용하지만, 온프레미스와의 연결을 고려할 때 요구되는 저지연 솔루션에는 적합하지 않


685
웹 사이트는 예측할 수 없는 트래픽 존재 + Lambda 함수를 사용하여 개인 RDS for PostgreSQL DB 인스턴스에 직접 액세스 + 예측 가능한 데이터베이스 성능을 유지하고 Lambda 호출이 너무 많은 연결로 데이터베이스를 과부하시키지 않도록 하려고함 

 

더보기

B. 클라이언트 드라이버를 RDS 프록시 엔드포인트로 지정합니다. VPC 내부에 Lambda 함수를 배포합니다.

 

lambda함수가 rds에 액세스하려면 vpc 내부에 있어야함


⇒ RDS Proxy: RDS를 위한 완전 관리형, 고가용성, 확장 가능한 프록시로, Lambda에서 실행되는 애플리케이션에서 RDS 인스턴스에 쉽게 연결 가능. 데이터베이스에 대한 연결 관리를 오프로드하여 성능과 안정성 개선

 

* 사용자 지정 엔드포인트: 여러 RDS 인스턴스나 읽기 복제본에 대한 단일 연결 지점을 제공



686

회사는 온프레미스 위치를 AWS 클라우드의 리전에 있는 VPC에 연결해야함 + 내년에 계정과 VPC의 수가 늘어날 것 → 새로운 연결의 관리를 간소화해야하며 확장 기능 제공 + 최소한의 관리 오버헤드 

 

더보기

C. 전송 게이트웨이를 만듭니다. VPC 연결을 위한 VPC 첨부 파일을 만듭니다. 온프레미스 연결을 위한 VPN 첨부 파일을 만듭니다


* Transit Gateway (전송 게이트웨이): VPC Peering과 마찬가지로 서로 다른 VPC 간에 통신이 가능하게 하는 서비스(여러 VPC 간 연결 정책 중앙에서 관리 가능)


687

한 회사는 매달 제조 공정에 필요한 리소스를 예측하는 솔루션 필요 + 현재 S3 버킷에 저장된 과거 값을 사용해야함 → 머신 러닝(ML) 경험이 없으며 교육 및 예측을 위해 관리형 서비스를 사용해야함 

 

더보기

A. Amazon SageMaker 모델을 배포합니다. 추론을 위한 SageMaker 엔드포인트를 만듭니다.

B. Amazon SageMaker를 사용하여 S3 버킷의 과거 데이터를 사용하여 모델을 학습합니다.

 

Amazon Forecast는 더 이상 신규 고객에게 제공되지 않습니다.


더보기

D. Amazon Forecast 예측기를 사용하여 입력을 기반으로 예측을 생성하는 함수 URL로 AWS Lambda 함수를 구성합니다.

E. S3 버킷의 과거 데이터를 사용하여 Amazon Forsecast 예측기를 훈련합니다.

 

* AWS SageMaker: 완전 관리형 기계 학습 (ML) 서비스 (머신 러닝 경험이 없으므로 X)
* AWS Forecast: 통계 및 기계 학습 알고리즘을 사용하여 매우 정확한 시계열 예측을 제공하는 완전 관리형 서비스(사전 ML 경험이 없어도 매우 정확한 예측 가능)


#688 
Organizations에서 AWS 계정을 관리 + IAM Identity Center(AWS Single Sign-On)와 AWS Control Tower가 계정에 대해 구성 + 모든 계정에서 여러 사용자 권한을 관리하려고 함 + 권한은 여러 IAM 사용자가 사용하며 개발자와 관리자 팀 간에 분할해야함 + 각 팀에는 다른 권한이 필요함 → 두 팀 모두에서 고용된 새 사용자를 포함하는 솔루션을 원함 + 최소한의 운영 오버헤드 

 

* IAM Identity Center(AWS Single Sign-On): 사용자 관리 및 접근 제어. 하나의 자격 증명으로 여러 AWS 접근, 중앙 집중식 관리 

더보기

C. IAM Identity Center에서 개별 사용자를 만듭니다. IAM Identity Center에서 새로운 개발자 및 관리자 그룹을 만듭니다. 각 그룹에 적합한 IAM 정책을 포함하는 새로운 권한 집합을 만듭니다. 새로운 그룹을 적절한 계정에 할당합니다. 새로운 권한 집합을 새로운 그룹에 할당합니다. 새로운 사용자가 고용되면 적절한 그룹에 추가합니다.

 

조직화된 관리 + 세분화된 권한 + 유지 관리 용이성


* 개별 사용자 생성: IAM Identity Center에서 개별 사용자를 생성하여 모든 계정에서 중앙 집중적 관리
* 그룹 생성 및 권한 집합: 개발자 및 관리자 팀을 위한 그룹을 생성하고, 각 그룹에 적합한 IAM 정책을 포함하는 권한 집합 생성
* 계정 할당: 새로 만든 그룹을 적절한 AWS 계정에 할당하여 팀별로 필요한 리소스와 접근 권한을 관리
* 사용자 추가: 새로운 사용자가 고용되면 적절한 그룹에 추가하여 권한을 자동으로 부여

 

각 계정에서 개별 사용자를 만드는 것은 오버헤드 


689 
EBS 볼륨 암호화 전략을 표준화 + 볼륨 암호화 검사를 운영하는데 필요한 비용과 구성 노력을 최소화 

 

더보기

D. Amazon EBS에 대한 AWS Config 규칙을 생성하여 볼륨이 암호화되었는지 평가하고 암호화되지 않은 경우 볼륨에 플래그를 지정합니다.


* AWS Config: 리소스 구성을 자동으로 평가하고 규정 준수를 모니터링하는 관리형 서비스

⇒  특정 리소스(EBS 볼륨)가 암호화되었는지 여부를 지속적으로 검사하고 규정 위반 사항을 자동으로 감지


690

회사가 정기적으로 GB 크기의 파일을 S3에 업로드 + 파일을 업로드 한 후, 회사는 EC2 Spot 인스턴스의 플릿을 사용하여 파일 형식을 트랜스코딩 → 회사는 온프레미스 데이터 센터에서 S3로 데이터를 업로드하고 S3에서 EC2 인스턴스로 데이터를 다운로드할 때
처리량을 확장해야함 

 

* Amazon EC2 Spot Instances의 플릿(Spot Fleet): 다양한 인스턴스 유형과 가용 영역에서 스팟 인스턴스를 요청하고 관리

 

더보기

C. S3 멀티파트 업로드를 사용합니다. 

D. 객체의 여러 바이트 범위를 병렬로 가져옵니다.


* S3 멀티파트 업로드: 멀티파트 업로드는 큰 파일을 여러 부분으로 나누어 병렬로 업로드 + 업로드 속도를 크게 향상
* 병렬 다운로드: S3에서 파일을 다운로드할 때 여러 바이트 범위를 병렬로 가져오는 방법을 사용하여 처리량을 확장. 파일을 여러 부분으로 나누어 동시에 다운로드함으로써 다운로드 속도를 크게 향상


691
웹 애플리케이션은 ASG에 있는 EC2 인스턴스에서 실행 + 회사는 콘텐츠를 자주 변경할 계획 → 변경이 발생하는 즉시 새 콘텐츠를 반환하는 강력한 일관성을 가져야함 

 

더보기

B. Amazon Elastic File System(Amazon EFS) 파일 시스템을 만듭니다. 개별 EC2 인스턴스에 EFS 파일 시스템을 마운트합니다. 

E. 웹 콘텐츠를 저장할 Amazon S3 버킷을 만듭니다. Cache-Control 헤더의 메타데이터를 no-cache로 설정합니다. Amazon CloudFront를 사용하여 콘텐츠를 전달합니다.


* EFS: 완전히 탄력적인 서버리스 파일 스토리지를 제공하므로 스토리지 용량과 성능을 프로비저닝하거나 관리하지 않고도 파일 데이터를 공유(가용성, 내구성, 일관성)


* No-Cache: Cache-Control 헤더를 no-Cache로 설정하면 CloudFront가 항상 원본에서 최신 콘텐츠를 가져오도록 하여 강력한 일관성 유지 가능(no-cache 값은 대부분의 브라우저에서 max-age=0 과 동일한 뜻, 즉, 캐시는 저장하지만 사용하려고 할 때마다 서버에 재검증 요청)


692
ALB를 사용하여 3개의 AWS 지역에 애플리케이션 배포 + Route 53은 이러한 지역간의 트래픽을 분산하는데 사용 → 가장 고성능 경험을 제공하기 위해 어떤 Route 53 구성을 사용해야하는지 

 

더보기

A. 대기 시간 정책이 있는 A 레코드를 만듭니다.


* LBR(지연 기반 라우팅): 가장 낮은 대기 시간을 가진 AWS 리전으로 트래픽을 라우팅. 각 리전의 응답 시간을 기준


* 지리적 위치 정책: 사용자의 지리적 위치를 기반으로 트래픽을 라우팅. 가장 가까운 리전을 선택

* 장애 조치 정책: 이 정책은 주로 한 리전이 다운되었을 때 다른 리전으로 트래픽을 전환

* 지리적 근접성 정책: 가장 가까운 AWS 리전으로 라우팅하여 성능을 최적화


693
회사는 NoSQL 데이터베이스가 포함된 웹 애플리케이션 + ALB뒤의 EC2 인스턴스에서 실행 + 인스턴스는 단일 가용영역의 EC2 ASG에서 실행 → 트래픽이 증가하면서 고가용성의 필요성 + 데이터베이스는 일관성 필요 + 최소한의 운영 오버헤드 

 

더보기

D. 세 개의 가용성 영역에 걸쳐 EC2 인스턴스를 사용하도록 자동 확장 그룹을 수정합니다. AWS Database Migration Service(AWS DMS)를 사용하여 내장된 NoSQL 데이터베이스를 Amazon DynamoDB로 마이그레이션합니다. 


⇒ DynamoDB: 강력한 일관성 + 최종적 일관성 + 서버리스 + No SQL
+ Auto Scailing Group 사용


694
쇼핑 애플리케이션 구축 + 매 달 한번씩 변경되는 카탈로그 제공, 트래픽 볼륨에 따라 확장해야함 + 가능한 가장 낮은 지연 시간을 원함 + 사용자의 쇼핑 카트 데이터는 고가용성이 있어야함 → 사용자 세션 데이터는 사용자가 연결이 끊겼다가 다시 연결하더라도 사용할 수 있어야함 + 쇼핑 카트 데이터가 항상 보존

 

더보기

B. Amazon DynamoDB의 카탈로그 데이터와 사용자 세션의 쇼핑 카트 데이터를 캐시하도록 Redis용 Amazon ElastiCache를 구성합니다.

 

* Amazon ElastiCache for Redis: Redis가 메모리 내 데이터 스토리지와 지속성 옵션을 모두 제공하기 때문에 세션 상태 스토리지에 적합, Redis는 복제, 지속성 및 고가용성(Redis Sentinel 또는 클러스터를 통해)과 같은 기능을 지원 → 이를 통해 개별 웹 서버에 장애가 발생하더라도 세션 상태가 보존되고 사용 가능


695
EKS에 배포될 마이크로서비스 기반 애플리케이션 구축 + 마이크로서비스는 서로 상호작용 → 향후 성능 문제를 식별하기 위해 애플리케이션을 관찰할 수 있도록 

 

더보기

B. EKS 클러스터에서 메트릭을 수집하도록 Amazon CloudWatch Container Insights를 구성합니다. 마이크로서비스 간의 요청을 추적하도록 AWS X-Ray를 구성합니다.


* Amazon CloudWatch Container Insights: 이 서비스는 컨테이너화된 애플리케이션에 대한 모니터링 및 문제 해결 기능을 제공, EKS 클러스터 및 컨테이너에서 메트릭, 로그 및 이벤트를 수집하고 집계


* AWS X-Ray: 애플리케이션으로 보낸 요청에 대한 엔드 투 엔드 교차 서비스 뷰 제공, 애플리케이션을 통과하는 요청에 대한 애플리케이션 중심의 뷰 제공. 마이크로서비스 간 흐름 추적, 지연 시간 분석, 성능 문제 시각화 

 

* ElastiCache: 주로 데이터베이스 쿼리의 응답 시간을 줄이거나 빈번한 데이터 요청에 대한 성능을 개선


696
회사는 고객에게 데이터에 대한 안전한 액세스를 제공 + 회사는 고객 데이터를 처리하고 결과를 S3에 저장 → 모든 데이터는 강력한 규정과 보안 요구 사항의 적용을 받음 + 데이터는 저장 시 암호화 + 각 고객은 AWS 계정에서만 데이터에 액세스할 수 있어야함 +
회사 직원은 데이터에 액세스할 수 없어야함 

 

더보기

C. 각 고객에 대해 별도의 AWS Key Management Service(AWS KMS) 키를 제공합니다. 데이터 서버 측을 암호화합니다. 각 KMS 키 정책에서 고객이 제공하는 IAM 역할을 제외한 모든 주체에 대한 데이터 복호화를 거부합니다. 


⇒ ACM 인증서는 웹에서 사용되므로 선택지에서 제외

 

* 서버 측 암호화 : 데이터가 전송된 후 서버에서 암호화
* 클라이언트 측 암호화: 데이터가 서버로 전송되기 전에 클라이언트에서 암호화

 

S3 버킷 정책: 버킷에 대한 접근을 제어 하는 역할이지만, 데이터 복호화 권한을 KMS 키 수준에서 제어하지않음


697
아키텍트가 VPC 생성 + 모든 EC2 인스턴스를 프라이빗 서브넷에서 시작해야함 + 프라이빗 서브넷에서 포트 80 및 443에서 웹 서버를 실행하는 EC2 인스턴스를 시작하면 외부 인터넷 트래픽이 서버에 연결할 수 없음 

 

더보기

B. 퍼블릭 서브넷에서 인터넷 연결 애플리케이션 로드 밸런서(ALB)를 프로비저닝합니다. AL과 연결된 대상 그룹에 EC2 인스턴스를 추가합니다. 웹사이트의 DNS 레코드가 ALB로 확인되는지 확인합니다. 


⇒ 퍼블릭 서브넷에 있는 ALB를 프로비저닝(ALB와 연결된 타겟 그룹에 인스턴스 추가) 


698 
Fargate 클러스터를 사용하여 EKS에 새로운 애플리케이션 배포 + 데이터 지속성을 위한 스토리지 솔루션 필요 + 고가용성 및 내결함성이 필요 + 여러 애플리케이션 컨테이너 간에 공유되어야함 + 가장 적은 운영 오버헤드 

 

더보기

B. Amazon Elastic File System(Amazon EFS) 파일 시스템을 만듭니다. EKS 클러스터의 StorageClass 객체에 파일 시스템을 등록합니다. 모든 컨테이너에 동일한 파일 시스템을 사용합니다. 


Fargate 클러스터 사용 + 데이터 지속성을 위한 스토리지 솔루션(고가용성, 내결함성) 
⇒고가용성과 내결함성이 있고 Fargate와 잘 연동되는 스토리지 서비스는 EFS + EFS는 자동으로 여러 인스턴스와 컨테이너 간에 데이터를 동기화하므로, Lambda 함수를 추가로 사용할 필요 X

 

EBS 볼륨은 기본적으로 한 인스턴스에만 연결될 수 있으므로 여러 컨테이너 간에 데이터 공유가 어려움.
 


699 
로컬 데이터 센터에서 Docker 컨테이너를 사용하는 애플리케이션 + 호스트의 볼륨에 영구 데이터를 저장하는 컨테이너 호스트에서 실행 + 컨테이너 인스턴스는 저장된 영구 데이터를 사용함 → 서버나 스토리지 인프라를 관리하고 싶지 않음 + 완전 관리형 서비스로
옮기고자함 

 

더보기

B. AWS Fargate 시작 유형으로 Amazon Elastic Container Service(Amazon ECS)를 사용합니다. Amazon Elastic File System(Amazon EFS) 볼륨을 만듭니다. 컨테이너에 마운트된 영구 스토리지 볼륨으로 EFS 볼륨을 추가합니다. 


 서버나 스토리지 인프라 관리x + Docker 컨테이너 사용 


⇒ Amazon Fargate (컨테이너 사용 시 사용하는 서버리스 서비) + EFS 사용
 Fargate에서 S3 마운트하는 것 일반적으로 지원 X


700
새로운 인터넷 기반 애플리케이션을 출시 + 통신 TCP/UDP 프로토콜 + 글로벌 사용자에게 높은 가용성과 최소 지연 시간을 제공 

더보기

A. 각 지역의 애플리케이션 앞에 내부 네트워크 로드 밸런서를 생성합니다.

C. 각 지역의 로드 밸런서로 트래픽을 라우팅하기 위해 AWS Global Accelerator 가속기를 생성합니다. 


⇒ Global Accelerator + Network Load Balancer


 

728x90
반응형