aws연습 문제

728x90

한 소셜 미디어 분석 선도 기업에서 도커화(Dockerized)한 자사의 애플리케이션 스택을 AWS 클라우드로 이전하는 것을 고려하고 있습니다. 회사는 EC2 시작 유형의 Elastic Container Service(ECS)와 Fargate 시작 유형의 Elastic Container Service(ECS)가 요금 면에서 어떤 차이가 있는지 파악하지 못했습니다.

다음 중 두 서비스의 요금 책정에 관한 설명으로 맞는 것은 무엇입니까?

EC2 시작 유형의 ECS는 EC2 인스턴스 및 EBS 볼륨 사용량에 따라 요금이 청구된다. Fargate 시작 유형은 컨테이너화된 애플리케이션이 요청하는 vCPU 및 메모리 리소스 양에 따라 요금이 부과된다.

Amazon Elastic Container Service(Amazon ECS)는 완벽히 관리되는 컨테이너 오케스트레이션 서비스입니다. ECS를 이용하면 AWS에서 Docker 콘테이너 애플리케이션을 손쉽고 안전하게 실행하고 스케일링할 수 있습니다.

Fargate 시작 타입을 선택하면 여러분의 컨테이너화된 애플리케이션이 요청하는 vCPU 및 메모리 리소스의 양에 대해 비용을 지불합니다. vCPU 및 메모리 리소스는 여러분의 컨테이너 이미지를 당겨온 시각부터 Amazon ECS 작업*이 종료될 때까지 계산되며, 초 단위까지 반올림됩니다. EC2 시작 타입을 선택하면 EC2 시작 타입에 대해 추가 요금이 부과되지 않습니다. 여러분은 애플리케이션을 저장하고 실행하기 위해 생성한 AWS 리소스(예, EC2 인스턴스 또는 EBS 볼륨)에 대해 요금을 지불합니다.

회사에서 사내 데이터베이스를 AWS 클라우드로 마이그레이션하려고 합니다. 회사의 CTO는 보조 인덱스, 외래 키, 저장 프로시저와 같은 복잡한 데이터베이스 구성을 처리할 수 있는 솔루션을 원합니다.

솔루션 아키텍트로서 위와 같은 사례를 해결하려면 다음의 AWS 서비스를 어떻게 조합해야 합니까? (2개를 고르시오.)

AWS Schema Conversion Tool

AWS Database Migration Service

AWS 데이터베이스 마이그레이션 서비스를 이용하면 빠르고 안전하게 데이터베이스를 AWS로 마이그레이션할 수 있습니다. 마이그레이션 중에 소스 데이터베이스가 완벽하게 운영되므로 데이터베이스에 의존하는 애플리케이션의 불가동 시간이 최소화됩니다. AWS 데이터베이스 마이그레이션 서비스는 Oracle 대 Oracle 같은 동종 마이그레이션을 지원하며, Oracle 또는 Microsoft SQL Server 대 Amazon Aurora 같은 다른 데이터베이스 플랫폼 간 이종 마이그레이션도 지원합니다.

제시된 활용 사례에서 회사의 CTO가 온프레미스 데이터 센터에 배포된 라이선스 기반의 값비싼 레거시 상용 데이터베이스 솔루션을 더 경제적이고 효율적인 AWS Cloud의 오픈소스로 마이그레이션하려고 하므로 이는 이종 데이터베이스 마이그레이션의 예입니다.

그러한 시나리오에서는 Oracle 대 Amazon Aurora, Oracle 대 PostgreSQL 또는 Microsoft SQL Server 대 MySQL 마이그레이션의 경우처럼 소스와 타깃 데이터베이스 엔진이 다릅니다. 이러한 경우, 소스와 타깃 데이터베이스의 스키마 구조, 데이터 타입, 데이터베이스 코드가 상당히 달라서 데이터 마이그레이션을 시작하기 전에 스키마와 코드를 변환해야 할 수 있습니다.

그렇기 때문에 이종 마이그레이션은 두 단계로 이루어집니다. 먼저 AWS 스키마 변환 툴을 사용하여 소스 스키마와 코드를 타깃 데이터베이스와 일치시키고, 다음으로 AWS 데이터베이스 마이그레이션 서비스를 사용하여 소스 데이터베이스로부터 타깃 데이터베이스로 데이터를 마이그레이션합니다. 필요한 모든 데이터 타입 변환은 AWS 데이터베이스 마이그레이션 서비스가 마이그레이션 중에 자동으로 수행할 것입니다. 소스 데이터베이스는 Amazon EC2 인스턴스에서 실행되는 AWS 외부의 온프레미스 환경에 있거나 Amazon RDS 데이터베이스에 있을 수 있습니다. 타깃은 Amazon EC2 또는 Amazon RDS의 데이터베이스가 될 수 있습니다.

한 회사의 엔지니어링 팀에서 Amazon SQS를 사용해 애플리케이션 아키텍처 밑단에 있는 컴포넌트를 분리하려고 합니다. 하지만 엔지니어링 팀은 공용 인터넷을 통해 SQS에 액세스하는 VPC 바인딩 컴포넌트에 대해 우려하고 있습니다.

솔루션 아키텍트로서 이 사례를 해결하기 위해 다음 중 어떤 솔루션을 제안하시겠습니까?

VPC 엔드포인트를 사용해 Amazon SQS에 액세스한다.

AWS 고객은 공용 IP를 사용하지 않고, 또한 공용 인터넷을 거치지 않고 VPC 엔드포인트를 사용하여 자신들의 Amazon 가상 사설 클라우드(Amazon VPC)로부터 Amazon Simple Queue Service(Amazon SQS)에 액세스할 수 있습니다. Amazon SQS의 VPC 엔드포인트는 여러분이 사적으로 VPC를 지원되는 AWS 서비스에 연결할 수 있게 해주는 스케일링 가능한 고가용성 기술인 AWS PrivateLink가 지원합니다.

Amazon VPC 엔드포인트는 구성이 간단합니다. 또한 인터넷 게이트웨이, 네트워크 주소 번역(NAT) 인스턴스, VPN 연결 또는 AWS Direct Connect 연결 없이 Amazon SQS에 대한 안정적인 연결성을 제공합니다. VPC 엔드포인트를 사용하면 여러분의 Amazon VPC와 Amazon SQS 대기열 간에 데이터가 Amazon 네트워크 안에서 전송되어 여러분의 인스턴스를 인터넷 트래픽으로부터 보호하는 데 도움이 됩니다.

AWS PrivateLink를 사용하면 데이터가 공용 인터넷에 노출되지 않으므로 클라우드 기반 애플리케이션과 공유되는 데이터의 보안이 간단해집니다. AWS PrivateLink는 Amazon 네트워크에서 안전하게 VPC, AWS 서비스, 온프레미스 애플리케이션 간에 사적 연결성을 제공합니다. AWS PrivateLink를 사용하면 다양한 계정과 VPC 간에 서비스들을 쉽게 연결하여 네트워크 아키텍처가 상당히 단순해집니다.

한 조직에서 개발 환경에 있는 사용자들에게 액세스 권한을 위임하여 해당 사용자들이 다른 AWS 계정 밑에서 관리되는 프로덕션 환경의 리소스에 접근할 수 있게 하려고 합니다.

솔루션 아키텍트의 관점에서 봤을 때, 다음 중 어떤 단계를 수행해야 합니까?

프로덕션 환경의 리소스에 액세스하는 데 필요한 권한을 가진 새로운 IAM 역할을 생성한다. 사용자는 프로덕션 환경에서 리소스에 액세스하는 동안 해당 IAM 역할을 맡을 수 있다.

IAM 역할을 이용하면 일반적으로 여러분 조직의 AWS 리소스에 액세스할 수 없는 사용자나 서비스에게 액세스 권한을 위임할 수 있습니다. IAM 사용자 또는 AWS 서비스는 AWS API 호출을 하는 데 사용할 수 있는 임시 보안 자격 증명을 얻기 위해 역할을 맡을 수 있습니다. 결과적으로, 여러분은 리소스에 액세스하기 위한 장기적인 자격 증명을 공유하지 않아도 됩니다. IAM 역할을 이용하면 다른 계정의 리소스에 액세스할 수 있습니다.

한 IT 회사에서 Amazon Redshift를 사용해 유통 조직을 위한 맞춤형 데이터 웨어하우스 솔루션을 구축했습니다. 회사의 일일 분석 보고서에는 지난 1년간의 데이터만 사용되기 때문에 비용 최적화 작업의 일환으로 1년이 지난 과거 데이터를 모두 S3로 이동하려고 합니다. 하지만 분석가들은 일일 보고서와 지난 과거 데이터를 상호 참조하는 기능을 계속해서 사용하고 싶어 합니다.

회사에서는 최소한의 비용과 최소한의 노력을 들여 솔루션을 개발하기를 원합니다. 솔루션 아키텍트로서 이 사례를 해결하기 위해 어떤 방법을 제안하시겠습니까?

Redshift Spectrum을 사용해 S3에 있는 과거 데이터를 가리키는 Redshift 클러스터 테이블을 생성한다. 분석 팀은 과거 데이터를 쿼리하여 Redshift의 일일 보고서와 상호 참조할 수 있다.

Amazon Redshift는 대규모 데이터셋의 저장과 분석을 위해 고안된 완전히 관리되는 페타바이트 스케일 클라우드 기반 데이터 웨어하우스 제품입니다.

Amazon Redshift 스펙트럼을 이용하면 Amazon Redshift 테이블에 데이터를 로딩할 필요 없이 Amazon S3 안의 파일에서 구조화/반구조화 데이터를 효율적으로 쿼리하고 검색할 수 있습니다.

Amaozn Redshift 스펙트럼은 전용 Amaozn Redshift 서버에 상주하며, 여러분의 클러스터와 독립되어 있습니다. Redshift 스펙트럼은 조건 필터링, 집계처럼 연산집약적인 많은 작업을 Redshift 스펙트럼 레이어까지 푸시합니다. 따라서 Redshift 스펙트럼 쿼리는 다른 쿼리에 비해 여러분 클러스터의 처리 능력을 훨씬 덜 사용합니다.

한 회사가 운영하는 멀티 티어 소셜 미디어 애플리케이션은 애플리케이션 로드 밸런서 뒤에 있는 EC2 인스턴스에서 실행되고 있습니다. 인스턴스는 여러 가용 영역에 걸쳐있는 EC2 오토 스케일링 그룹에서 실행되며 Amazon Aurora 데이터베이스를 사용합니다. 여러분은 솔루션 아키텍트로서 주기적으로 급증하는 요청에 대한 애플리케이션의 복원력을 높이는 작업을 진행하고 있습니다.

다음 중 이와 같은 사례에 적합한 솔루션은 무엇입니까? (2개를 고르시오.)

여러분은 Aurora 레플리카와 CloudFront 배포를 이용하여 애플리케이션이 요청률 급증에 대해 더 회복력을 갖도록 할 수 있습니다.

Aurora 복제본을 사용한다.

Aurora 레플리카에는 두 가지 목적이 있습니다. 여러분은 레플리카에 쿼리를 보내어 애플리케이션을 위해 읽기 작업을 스케일링할 수 있습니다. 일반적으로는 클러스터의 읽기 엔드포인트에 연결하여 그렇게 합니다. 그렇게 하면 Aurora가 읽기 전용 연결에 관한 로드를 여러분이 클러스터에 가진 Aurora 레플리카의 수만큼 분산시킬 수 있습니다. Aurora 레플리카는 가용성 향상에도 도움을 줍니다. 만일 클러스터의 쓰기 인스턴스를 사용할 수 없게 되면 Aurora는 자동으로 읽기 인스턴스 중 하나가 새로운 쓰기 인스턴스로서 그 자리를 대체하도록 합니다. 어떤 AWS 리전 안에서 DB 클러스터가 분산된 가용 영역(AZ)에 걸쳐 최대 15개의 Aurora 레플리카를 배포할 수 있습니다.

애플리케이션 로드 밸런서 앞에서 CloudFront 배포를 사용한다.

Amazon CloudFront는 개발자 친화적인 환경에서 낮은 레이턴시, 높은 전송 속도로 전 세계의 컨슈머에게 데이터, 비디오, 애플리케이션, API를 안전하게 전달하는 빠른 콘텐츠 전달 네트워크(CDN) 서비스입니다. CloudFront 접속 지점(POP)(엣지 위치)은 인기 있는 콘텐츠를 빠르게 열람자에게 제공할 수 있게 해줍니다. CloudFront는 또 어떤 콘텐츠가 POP에 머무를 정도로 인기가 있지 않을 때에도 여러분의 콘텐츠를 더욱 열람자에게 가까이 가져다주는 지역적 엣지 캐시도 있어서 그 콘텐츠의 성능을 개선해 줍니다.

CloudFront는 원점 페일오버 기능이 있어서 데이터의 회복력 수요를 지원해 줍니다. CloudFront는 엣지 위치 또는 접속 지점(POP)이라고 부르는 전 세계적인 데이터 네트워크를 통해 여러분의 콘텐츠를 전달하는 글로벌 서비스입니다. 여러분의 콘텐츠가 엣지 위치에 미리 캐시되어 있지 않은 경우, CloudFront는 여러분이 일정한 콘텐츠 버전의 소스로 지정한 원점으로부터 콘텐츠를 받습니다.

한 사이버 보안 회사가 자사 애플리케이션을 실행하기 위해 여러 개의 EC2 인스턴스를 사용하고 있습니다. 사내 인프라 유지보수 그룹은 EC2 인스턴스의 CPU 사용률이 특정 임계값을 초과할 때마다 이메일을 통해 알림을 받으려고 합니다.

최소한의 개발 노력을 들여 이에 맞는 솔루션을 구축하려면 다음 중 어떤 서비스를 사용해야 합니까? (2개를 고르시오.)

Amazon SNS - Amazon Simple Notification Service(SNS)는 여러분이 마이크로서비스, 분산 시스템, 서버리스 애플리케이션을 디커플링할 수 있는 가용성 높고 견고하며 안전하고 완벽히 관리되는 게시/구독(pub/sub) 메시징 서비스입니다. Amazon SNS는 빠른 처리 속도, 푸시 기반, 다대다(many-to-many) 메시징을 위한 토픽을 제공합니다.

Amazon CloudWatch - Amazon CloudWatch는 DevOps 엔지니어, 개발자, 사이트 신뢰성 엔지니어(SRE), IT 관리자를 위해 구축된 모니터링 및 관찰 서비스입니다. CloudWatch는 여러분의 애플리케이션을 모니터링하고 시스템 전체의 성능 변화에 대응하며 리소스 활용을 최적화하고 운용 건전성을 한눈에 알 수 있게 해주는 데이터와 실행 가능한 인사이트를 제공합니다. Amazon CloudWatch를 사용하면 여러분이 AWS에서 실행하는 애플리케이션과 AWS 클라우드 리소스를 모니터링할 수 있습니다.

어떤 EC2 인스턴스가 특정한 한계치를 위반하면 여러분은 CloudWatch 알람을 사용하여 SNS를 통해 이메일을 전송할 수 있습니다. 그러므로 두 선택지는 모두 정답입니다.

회사에 Application Load Balancer 뒤의 EC2 인스턴스의 Auto Scaling 그룹에서 호스팅되고 여러 AWS 리전에 배포되는 데이터 교환 포털이 있습니다. 사용자는 전 세계에서 찾을 수 있지만 대부분은 서울과 스웨덴 입니다. 이 두 위치의 규정 준수 요구 사항 때문에 서울 사용자는 ap-northeast-2 Asia Pacific(서울) 지역의 서버에 연결하고 스웨덴 사용자는 eu-west-1 유럽(아일랜드) 지역의 서버에 연결해야 합니다.

다음 중 이 요구 사항을 쉽게 충족할 수 있는 서비스는 무엇입니까?

Route 53 지리 위치 라우팅 정책을 사용합니다.

지리적 라우팅을 사용하면 사용자의 지리 위치, 즉 DNS 쿼리가 발생하는 위치를 기반으로 트래픽을 제공하는 리소스를 선택할 수 있습니다. 예를 들어 유럽에서 발생하는 모든 쿼리를 프랑크푸르트 리전에 위치한 ELB 로드 밸런서로 라우팅할 수 있습니다.

지리적 라우팅을 사용하는 경우, 콘텐츠를 지역화하고 웹 사이트의 일부 또는 전체를 사용자의 언어로 제공할 수 있습니다. 또한 지리적 라우팅을 사용하여 배포권이 있는 위치에서만 콘텐츠를 배포할 수 있도록 제한할 수 있습니다. 또한 예측 가능하고 간편하게 관리할 수 있는 방식으로 엔드포인트 간에 로드를 분산하는 데 사용함으로써, 사용자의 위치가 동일한 엔드포인트에 일관되게 라우팅되도록 할 수도 있습니다.

미국에서는 대륙, 국가 또는 주를 기준으로 지리적 위치를 지정할 수 있습니다. 중복되는 지리 리전에 대해 별도의 레코드를 생성하는 경우(예를 들면, 북미에 하나의 레코드, 캐나다에 하나의 레코드) 우선 순위는 가장 작은 지리 지역에 돌아갑니다. 이렇게 하면 한 대륙의 일부 쿼리를 하나의 리소스로 라우팅하고 그 대륙에서 선택된 여러 나라들의 쿼리는 다른 리소스로 라우팅할 수 있습니다.

지리 위치는 IP 주소를 위치에 매핑하는 방식으로 작동합니다. 그러나 일부 IP 주소들은 지리 위치에 매핑되지 않으므로, 7개 대륙 전체를 포괄하는 지리 위치 레코드를 생성한다 해도 Amazon Route 53은 식별할 수 없는 위치에서 온 일부 DNS 쿼리를 수신합니다. 어떤 위치에도 매핑되지 않는 IP 주소로부터 온 쿼리, 그리고 지리 위치 레코드를 생성하지 않은 위치로부터 온 쿼리 모두를 처리하는 기본 레코드를 생성할 수 있습니다. 기본 레코드를 생성하지 않으면, Route 53은 그 위치에서 온 쿼리에 대해 "응답 없음(no answer)"을 반환합니다.

실시간 데이터 분석 애플리케이션은 AWS Lambda를 사용하여 데이터를 처리하고 결과를 JSON 형식으로 S3 버킷에 저장합니다. 기존 워크플로의 속도를 높이려면 데이터를 별도의 분석 시스템으로 이동하지 않고 데이터에 대해 정교한 빅데이터 분석을 실행할 수 있는 서비스를 사용해야 합니다.

다음 중 이 요구 사항을 충족하기 위해 사용할 수 있는 서비스 그룹은 무엇입니까?

S3 Select, Amazon Athena, Amazon Redshift Spectrum

Amazon S3를 사용하면 데이터를 별도의 분석 시스템으로 이동하지 않고도 데이터에 대해 정교한 빅 데이터 분석을 실행할 수 있습니다. AWS에는 기존 워크플로를 최적화하고 Amazon S3와 통합하는 방법을 포함하여 클라우드에서 많은 양의 데이터를 더 빠르게 분석하고 처리할 수 있는 도구 모음이 있습니다.

1. S3 Select

Amazon S3 Select는 Amazon S3 버킷의 객체 내 데이터를 더 빠르고 저렴하게 분석하고 처리할 수 있도록 설계되었습니다. 간단한 SQL 표현식을 사용하여 Amazon S3의 객체에서 데이터의 하위 집합을 검색하는 기능을 제공하여 작동합니다. 애플리케이션은 더 이상 컴퓨팅 리소스를 사용하여 객체의 데이터를 스캔하고 필터링할 필요가 없으므로 잠재적으로 쿼리 성능을 최대 400%까지 높이고 쿼리 비용을 최대 80%까지 절감할 수 있습니다. S3 Select를 활용하려면 GET 대신 SELECT를 사용하도록 애플리케이션을 변경하기만 하면 됩니다.

2. Amazon Athena

Amazon Athena는 표준 SQL 표현식을 사용하여 Amazon S3의 데이터를 쉽게 분석할 수 있는 대화형 쿼리 서비스입니다. Athena는 서버리스이므로 관리할 인프라가 없으며 실행한 쿼리에 대해서만 비용을 지불하면 됩니다. Athena는 사용하기 쉽습니다. Amazon S3의 데이터를 가리키고 스키마를 정의한 다음 표준 SQL 표현식을 사용하여 쿼리를 시작하기만 하면 됩니다. 대부분의 결과는 몇 초 이내에 전달됩니다. Athena를 사용하면 분석을 위해 데이터를 준비하기 위해 복잡한 ETL 작업이 필요하지 않습니다. 이를 통해 SQL 기술을 가진 사람은 누구나 대규모 데이터 세트를 신속하게 분석할 수 있습니다.

3. Amazon Redshift Spectrum

Amazon Redshift에는 Redshift Spectrum도 포함되어 있어 Amazon S3의 엑사바이트 규모의 비정형 데이터에 대해 SQL 쿼리를 직접 실행할 수 있습니다. 로드 또는 변환이 필요하지 않으며 Avro, CSV, Grok, ORC, Parquet, RCFile, RegexSerDe, SequenceFile, TextFile 및 TSV를 포함한 개방형 데이터 형식을 사용할 수 있습니다. Redshift Spectrum은 검색되는 데이터를 기반으로 쿼리 컴퓨팅 용량을 자동으로 확장하므로 데이터 세트 크기에 관계없이 Amazon S3에 대한 쿼리가 빠르게 실행됩니다.

데이터 개인 정보 보호를 위해 의료 회사는 HIPAA(Health Insurance Portability and Accountability Act)를 준수하도록 요청받았습니다. 회사는 모든 백업을 Amazon S3 버킷에 저장합니다. S3 버킷에 저장된 데이터는 암호화되어야 합니다.

이 작업을 수행하는 가장 좋은 방법은 무엇입니까? (2개 선택)

HTTPS를 통해 데이터를 Amazon S3로 보내기 전에 먼저 자체 암호화 키를 사용하여 데이터를 로컬에서 암호화합니다.

AES-256 암호화를 사용하려면 S3 버킷에서 서버 측 암호화를 활성화합니다.

데이터 보호란 전송 중(Amazon S3 안팎으로 데이터가 이동 중)과 유휴 시(Amazon S3 데이터 센터의 디스크에 데이터가 저장된 동안) 데이터를 보호하는 것을 말합니다. SSL/TLS(Secure Socket Layer/Transport Layer Security)를 사용하거나 클라이언트 측 암호화를 사용하여 전송 중인 데이터를 보호할 수 있습니다. Amazon S3에서 유휴 데이터를 보호하는 다음과 같은 옵션이 있습니다.

1. 서버 측 암호화 – 데이터 센터의 디스크에 저장하기 전에 객체를 암호화하고 객체를 다운로드할 때 이를 해독하도록 Amazon S3에 요청합니다.

2. 클라이언트 측 암호화 – 클라이언트 측 데이터를 암호화하여 암호화된 데이터를 Amazon S3에 업로드합니다. 이 경우 사용자가 암호화 프로세스, 암호화 키 및 관련 도구를 관리합니다.

서버 측 암호화는 데이터를 받는 애플리케이션 또는 ㅐ서비스에 의해 해당 대상에서 데이터를 암호화하는 것입니다. Amazon S3에서 데이터 센터의 디스크에 데이터를 쓰면서 객체 수준에서 데이터를 암호화하고 사용자가 해당 데이터에 액세스할 때 자동으로 암호를 해독합니다. 요청을 인증하기만 하면 액세스 권한을 갖게 되며, 객체의 암호화 여부와 관계없이 액세스 방식에는 차이가 없습니다. 예를 들어, 미리 서명된 URL을 사용하여 객체를 공유하는 경우, 해당 URL은 암호화된 객체와 암호화되지 않은 객체에 동일하게 작동합니다. 또한 버킷에 객체를 나열하는 경우 목록 API에서는 암호화 여부와 관계없이 전체 객체의 목록을 반환합니다.

암호화 키 관리 방법으로 무엇을 선택하느냐에 따라 다음과 같은 세 가지 옵션을 독립적으로 사용할 수 있습니다.

Amazon S3 관리형 키를 사용한 서버 측 암호화(SSE-S3)

Amazon S3 관리형 키를 사용한 서버 측 암호화(SSE-S3)를 사용하면 각 객체는 고유한 키로 암호화됩니다. 또한 추가 보안 조치로 주기적으로 교체되는 루트 키를 사용하여 키 자체를 암호화합니다. Amazon S3 서버 측 암호화는 가장 강력한 블록 암호 중 하나인 256비트 Advanced Encryption Standard(AES-256) GCM을 사용하여 데이터를 암호화합니다. AES-GCM 이전에 암호화된 객체의 경우 AES-CBC는 여전히 해당 객체의 암호를 해독하도록 지원됩니다.

AWS Key Management Service에 저장된 KMS 키를 사용한 서버 측 암호화(SSE-KMS)

AWS KMS keys를 사용한 서버 측 암호화(SSE-KMS)는 SSE-S3와 유사하지만 이 서비스 사용 시 몇 가지 추가적인 이점이 있고 비용이 발생합니다. Amazon S3의 객체에 대한 무단 액세스에 대응하여 추가적인 보호를 제공하는 -KMS 키를 사용하려면 별도의 권한이 필요합니다. SSE-KMS도 KMS 키가 사용된 때와 사용 주체를 표시하는 감사 추적 기능을 제공합니다. 또한 고객 관리형 키를 생성하고 관리하거나 사용자, 서비스 및 리전에 고유한 AWS 관리형 CMK를 사용할 수 있습니다.

고객 제공 키를 사용한 서버 측 암호화(SSE-C)

고객 제공 키를 사용한 서버 측 암호화(SSE-C)를 사용하면 사용자는 암호화 키를 관리하고 Amazon S3는 암호화(디스크에 쓸 때) 및 해독(객체에 액세스할 때)을 관리합니다.

클라이언트 측 암호화는 데이터가 Amazon S3 서비스로 전달될 때 보안을 보장하기 위해 로컬에서 데이터를 암호화하는 작업입니다. Amazon S3 서비스는 암호화된 데이터를 수신하며 데이터를 암호화 또는 복호화하는 과정에 기여하지 않습니다.

클라이언트 측 암호화를 사용 설정하기 위한 다음 옵션이 있습니다.

- AWS Key Management Service(AWS KMS)에 저장된 키를 사용합니다.

- 애플리케이션 내에 저장한 키를 사용합니다.

회사는 Amazon S3 버킷에 데이터와 로그 파일을 씁니다. 이제 회사는 기존 데이터 파일과 Amazon S3에서 Amazon Kinesis Data Streams로의 진행 중인 파일 업데이트를 스트리밍하려고 합니다.

다음 중 이 요구 사항에 대한 솔루션을 구축하는 가장 빠른 방법으로 제안할 수 있는 것은 무엇입니까?

AWS Database Migration Service(AWS DMS)를 Amazon S3와 Amazon Kinesis Data Streams 간의 브리지로 활용합니다.

AWS Database Migration Service(AWS DMS)를 사용하여 이를 달성할 수 있습니다. AWS DMS를 사용하면 지원되는 소스에서 관계형 데이터베이스, 데이터 웨어하우스, 스트리밍 플랫폼 및 AWS 클라우드의 기타 데이터 저장소로 데이터를 원활하게 마이그레이션할 수 있습니다.

주어진 요구 사항은 가능한 한 최소한의 시간에 기능을 구현해야 합니다. 이러한 데이터 처리 요구 사항에 AWS DMS를 사용할 수 있습니다. AWS DMS를 사용하면 새 코드를 작성하고 유지 관리하지 않고도 실시간 분석을 위해 Amazon S3에서 Amazon Kinesis Data Streams로 데이터를 스트리밍하도록 기존 애플리케이션을 확장할 수 있습니다. AWS DMS는 Amazon S3를 원본으로 지정하고 Kinesis 및 Amazon Managed Streaming of Kafka(Amazon MSK)와 같은 스트리밍 서비스를 대상으로 지정하는 것을 지원합니다. AWS DMS를 사용하면 전체 및 변경 데이터 캡처(CDC) 파일을 이러한 서비스로 마이그레이션할 수 있습니다. AWS DMS는 복잡한 구성이나 코드 개발 없이 즉시 이 작업을 수행합니다. 워크로드에 따라 확장 또는 축소하도록 AWS DMS 복제 인스턴스를 구성할 수도 있습니다.

AWS DMS는 Amazon S3를 소스로, Kinesis를 대상으로 지원하므로 S3 버킷에 저장된 데이터가 Kinesis로 스트리밍됩니다. AWS Lambda, Amazon Kinesis Data Firehose, Amazon Kinesis Data Analytics 및 Kinesis 소비자 라이브러리(KCL)와 같은 여러 소비자는 데이터를 동시에 사용하여 데이터 세트에 대한 실시간 분석을 수행할 수 있습니다. 이 아키텍처의 각 AWS 서비스는 필요에 따라 독립적으로 확장할 수 있습니다.

Solutions Architect는 웹사이트와 애플리케이션에서 가져온 테라바이트 규모의 고객 데이터를 보유한 온라인 호텔 예약 회사에서 일하고 있습니다. Architect가 고객 예약 행동을 제시하고 고객 데이터에서 새로운 통찰력을 얻어야 하는 연례 기업 회의가 있습니다. Architect는 방대한 데이터 세트에 대해 거의 실시간으로 초고속 분석을 수행할 수 있는 서비스를 찾고 있습니다.

다음 서비스 중 방대한 양의 데이터를 저장하고 이에 대해 빠르고 유연한 쿼리를 수행할 수 있는 기능을 제공하는 서비스는 무엇입니까?

Amazon Redshift

Amazon Redshift는 클라우드에서 완벽하게 관리되는 페타바이트급 데이터 웨어하우스 서비스입니다. 작게는 수백 기가바이트부터 시작하여 페타바이트 이상까지 데이터를 확장할 수 있습니다. 이렇게 하면 데이터를 사용하여 비즈니스 및 고객에 대한 새로운 인사이트를 확보할 수도 있습니다.

데이터 웨어하우스를 생성할 때는 먼저 Amazon Redshift 클러스터라는 노드 집합을 시작하는 것이 첫 번째 단계입니다. 클러스터 프로비저닝을 마치면 데이터 집합을 업로드하여 데이터 분석 쿼리를 실행할 수 있습니다. Amazon Redshift는 데이터 집합의 크기와 상관없이 오늘날 사용되는 것과 동일한 SQL 기반 도구 및 비즈니스 인텔리전스 애플리케이션을 사용하여 쿼리 성능을 가속화합니다.

Redshift를 사용하면 표준 SQL 및 기존 BI(비즈니스 인텔리전스) 도구를 사용하여 모든 데이터를 분석할 수 있습니다. 또한 정교한 쿼리 최적화, 고성능 스토리지의 열 기반 스토리지, 대규모 병렬 쿼리 실행을 사용하여 테라바이트에서 페타바이트의 정형 및 반정형 데이터에 대해 복잡한 분석 쿼리를 실행할 수 있습니다.

RDS 읽기 전용 복제본 암호화에 대한 설명으로 옳은 것은?

마스터 데이터베이스가 암호화되면 읽기 전용 복제본도 암호화됩니다.

Amazon RDS 읽기 전용 복제본은 RDS 데이터베이스(DB) 인스턴스에 향상된 성능과 내구성을 제공합니다. 읽기가 많은 데이터베이스 워크로드에 대해 단일 DB 인스턴스의 용량 제약을 넘어 탄력적으로 쉽게 확장할 수 있습니다. MySQL, MariaDB, PostgreSQL, Oracle 및 SQL Server 데이터베이스 엔진의 경우 Amazon RDS는 원본 DB 인스턴스의 스냅샷을 사용하여 두 번째 DB 인스턴스를 생성합니다. 그런 다음 원본 DB 인스턴스에 변경 사항이 있을 때마다 엔진의 기본 비동기 복제를 사용하여 읽기 전용 복제본을 업데이트합니다. 읽기 전용 복제본은 가용 영역, 교차 AZ 또는 교차 리전 내에 있을 수 있습니다.

Amazon RDS 암호화로 실행되는 데이터베이스 인스턴스에서 기본 스토리지에 저장된 데이터는 자동 백업, 읽기 전용 복제본 및 스냅샷과 마찬가지로 암호화됩니다.

솔루션 아키텍트는 VPC를 모니터링하는 동안 일련의 DDoS 공격을 확인했습니다. 아키텍트는 클라이언트의 데이터를 보호하기 위해 현재 클라우드 인프라를 강화해야 합니다.

다음 중 이러한 종류의 공격을 완화하는 데 가장 적합한 솔루션은 무엇입니까

AWS Shield Advanced를 사용하여 DDoS 공격을 탐지하고 완화합니다.

AWS Shield는 AWS에서 실행되는 애플리케이션을 보호하는 디도스(DDoS) 보호 서비스입니다. AWS Shield는 애플리케이션 가동 중지 및 지연 시간을 최소화하는 상시 탐지 및 자동 인라인 통합을 제공하므로 DDoS 보호를 위해 AWS Support를 이용할 필요가 없습니다. AWS Shield에는 두 계층 – Standard 및 Advanced가 있습니다.

모든 AWS 고객은 추가 비용 없이 AWS Shield Standard에 의한 자동 보호를 받을 수 있습니다. AWS Shield Standard는 가장 일반적이고 빈번하게 발생하며 웹 사이트 또는 애플리케이션을 목표로 하는 네트워크 및 전송 계층 DDoS 공격으로부터 보호합니다. AWS Shield Standard를 Amazon CloudFront 및 Amazon Route 53과 함께 사용하면, 모든 알려진 인프라(계층 3 및 4) 공격으로부터 가용성을 포괄적으로 보호할 수 있습니다.

Amazon Elastic Compute Cloud(EC2), Elastic Load Balancing(ELB), Amazon CloudFront, AWS Global Accelerator 및 Amazon Route 53 리소스에서 실행되는 애플리케이션을 목표로 하는 공격에 대해 더 높은 수준의 보호를 구현하려면 AWS Shield Advanced를 구독하면 됩니다. AWS Shield Standard가 제공하는 네트워크 및 전송 계층 보호 이외에, AWS Shield Advanced는 정교한 대규모 DDoS 공격에 대한 추가 보호 및 완화, 실시간에 가까운 공격에 대한 가시성, 웹 애플리케이션 방화벽 AWS WAF와의 통합을 제공합니다. 또한, AWS Shield Advanced도 AWS Shield Response Team(SRT)에 대한 24X7 액세스를 제공하며 DDoS 관련 급증 시 Amazon Elastic Compute Cloud(EC2), Elastic Load Balancing(ELB), Amazon CloudFront, AWS Global Accelerator 및 Amazon Route 53 요금 보호를 제공합니다.

AWS Shield Advanced는 모든 Amazon CloudFront, AWS Global Accelerator 및 Amazon Route 53 엣지 로케이션에서 사용할 수 있습니다. 애플리케이션 앞에 Amazon CloudFront를 배포함으로써 전 세계 어디에서든 호스트된 웹 애플리케이션을 보호할 수 있습니다. 원본 서버는 Amazon Simple Storage Service(S3), Amazon Elastic Compute Cloud(EC2), Elastic Load Balancing(ELB) 또는 AWS 외부의 사용자 지정 서버가 될 수 있습니다.

AWS Shield Advanced는 사용자 또는 AWS SRT의 수동 개입 없이 애플리케이션 계층(L7) DDoS 이벤트를 완화하여 웹 애플리케이션을 자동으로 보호할 수 있습니다. Shield Advanced는 WebACL에 WAF 규칙을 생성하여 공격을 자동으로 완화하거나 카운트 전용 모드에서 활성화할 수 있습니다. 이를 통해 DDoS 이벤트에 신속하게 대응하여 애플리케이션 계층 DDoS 공격으로 인한 애플리케이션 가동 중단 시간을 방지할 수 있습니다.

AWS Shield Advanced에는 보호된 EC2, ELB, CloudFront, Global Accelerator 및 Route 53 리소스에 대한 DDoS 관련 사용량 급증으로 인한 확장 요금으로부터 보호하기 위해 DDoS 비용 보호 기능이 제공됩니다. DDoS 공격에 대한 대응으로 이러한 보호 대상 리소스가 확장될 경우, 일반 AWS Support 채널을 통해 Shield Advanced 서비스 크레딧을 요청할 수 있습니다.

Solutions Architect는 가장 저렴하고 안전한 방법으로 배스천 호스트를 설정해야 합니다. Architect는 SSH를 통해 액세스할 수 있는 유일한 사람이어야 합니다.

다음 중 이 요구 사항을 충족하며 비용 효율적인 것은 무엇입니까?

특정 네트워크만 포트 22에 액세스하도록 허용하는 보안 그룹으로 t2.micro EC2 인스턴스를 설정합니다.

배스천 호스트는 인터넷과 같은 외부 네트워크에서 개인 네트워크에 대한 액세스를 제공하는 것을 목적으로 하는 서버입니다. 잠재적인 공격에 노출되기 때문에 요새 호스트는 침투 가능성을 최소화해야 합니다.

배스천 호스트를 생성하려면 최대 보안을 위해 특정 IP 주소의 보안 그룹만 포함해야 하는 새 EC2 인스턴스를 생성할 수 있습니다. 비용도 질문에 고려되므로 호스트에 대해 작은 인스턴스를 선택해야 합니다. 기본적으로 t2.micro 인스턴스는 AWS에서 사용되지만 배포 중에 이러한 설정을 변경할 수 있습니다.

베타 테스트 프로그램의 일환으로 한 회사는 온프레미스 분석 애플리케이션의 데이터 파일을 NFS 인터페이스를 통해 AWS 클라우드와 통합하려고 합니다.

다음 AWS 서비스 중 주어진 사용 사례에 가장 효율적인 솔루션은 무엇입니까?

AWS Storage Gateway - File Gateway

AWS Storage Gateway는 거의 무제한의 클라우드 스토리지에 대한 온프레미스 액세스를 제공하는 하이브리드 클라우드 스토리지 서비스입니다. 이 서비스는 온프레미스 애플리케이션을 클라우드 스토리지에 원활하게 연결하고 지연 시간이 짧은 액세스를 위해 로컬로 데이터를 캐싱하는 세 가지 유형의 게이트웨이(테이프 게이트웨이, 파일 게이트웨이 및 볼륨 게이트웨이)를 제공합니다.

AWS Storage Gateway의 파일 인터페이스 또는 파일 게이트웨이는 애플리케이션 데이터 파일과 백업 이미지를 Amazon S3 클라우드 스토리지에 내구성 있는 객체로 저장하기 위해 클라우드에 원활하게 연결하는 방법을 제공합니다. 파일 게이트웨이는 로컬 캐싱을 통해 Amazon S3의 데이터에 대한 SMB 또는 NFS 기반 액세스를 제공합니다. 이 회사는 분석 데이터 파일을 NFS 인터페이스를 통해 AWS로 통합하기를 원하므로 AWS Storage Gateway - File Gateway가 정답입니다.

시스템 관리자가 IAM 정책을 생성하고 IAM 자격 증명에 연결합니다. 필요한 ID 기반 정책을 생성한 후 관리자는 이제 리소스 기반 정책을 생성합니다.

IAM 서비스가 지원하는 유일한 리소스 기반 정책은 무엇입니까?

신뢰 정책

정책을 생성하고 IAM 자격 증명(사용자, 사용자 그룹 또는 역할) 또는 AWS 리소스에 연결하여 AWS에서 액세스를 관리합니다. 정책은 자격 증명 또는 리소스와 연결될 때 권한을 정의하는 AWS의 객체입니다. 리소스 기반 정책은 Amazon S3 버킷과 같은 리소스에 연결하는 JSON 정책 문서입니다. 이러한 정책은 지정된 보안 주체에게 해당 리소스에 대한 특정 작업을 수행하고 적용되는 조건을 정의할 수 있는 권한을 부여합니다.

IAM 서비스는 역할 신뢰 정책이라고 하는 리소스 기반 정책 유형 하나만 지원하며, 이 유형은 IAM 역할에 연결됩니다. IAM 역할은 자격 증명이기도 하고 리소스 기반 정책을 지원하는 리소스이기도 합니다. 그러므로 IAM 역할에 신뢰 정책과 자격 증명 기반 정책을 모두 연결해야 합니다. 신뢰 정책은 역할을 수임할 수 있는 보안 주체 엔터티(계정, 사용자, 역할 및 페더레이션 사용자)를 정의합니다.

회사가 보고서와 규제 문서를 Amazon S3 버킷에 저장하고 있습니다. IT 감사를 준수하기 위해 그들은 Solutions Architect에게 버킷에 추가된 모든 새 객체와 제거된 객체를 추적하도록 지시했습니다. 또한 버전이 지정된 객체가 영구적으로 삭제되는지 여부도 추적해야 합니다. 설계자는 이러한 이벤트에 대한 알림을 사후 처리를 위한 대기열과 운영 팀에 알릴 Amazon SNS 주제에 게시하도록 Amazon S3를 구성해야 합니다.

다음 중 Architect가 구현해야 하는 가장 적합한 솔루션은 무엇입니까?

새 Amazon SNS 주제 및 Amazon SQS 대기열을 생성합니다. 버킷에 S3 이벤트 알림 구성을 추가하여 s3:ObjectCreated:* 및 s3:ObjectRemoved:Delete 이벤트 유형을 SQS 및 SNS에 게시합니다.

Amazon S3 이벤트 알림 기능을 사용하면 S3 버킷에서 특정 이벤트가 발생할 때 알림을 받을 수 있습니다. 알림을 사용 설정하려면 Amazon S3에서 게시하려는 이벤트를 식별하는 알림 구성을 추가합니다. 또한 해당 알림 구성이 Amazon S3에서 알림을 보낼 대상도 식별하는지 확인합니다. 버킷에 연결된 알림 하위 리소스에 이 구성을 저장합니다.

Amazon S3 이벤트 알림은 일반적으로 몇 초 만에 이벤트를 전달하지만 때로는 1분 이상 걸릴 수도 있습니다. 버전이 지정되지 않은 단일 객체에 동시에 두 번의 쓰기가 수행되면 단일 이벤트 알림만 전송될 수 있습니다. 쓰기에 성공할 때마다 이벤트 알림이 전송되도록 하려면 버킷에서 버전 관리를 활성화할 수 있습니다. 버전 관리를 사용하면 쓰기가 성공할 때마다 객체의 새 버전이 생성되고 이벤트 알림도 전송됩니다.

현재 Amazon S3은 다음 이벤트에 대한 알림을 게시할 수 있습니다.

- 새 객체 생성 이벤트

- 객체 제거 이벤트

- 객체 이벤트 복원

- RRS(Reduced Redundancy Storage) 객체 손실 이벤트

- 복제 이벤트

- S3 수명 주기 만료 이벤트

- S3 수명 주기 전환 이벤트

- S3 Intelligent-Tiering 자동 아카이브 이벤트

- 객체 태깅 이벤트

- 객체 ACL PUT 이벤트

Amazon S3은 다음과 같은 대상으로 이벤트 알림 메시지를 보낼 수 있습니다. 알림 구성에서 이 대상의 Amazon 리소스 이름(ARN) 값을 지정합니다.

- Amazon Simple Notification Service(Amazon SNS) 주제

- Amazon Simple Queue Service(Amazon SQS) 대기열

- AWS Lambda 함수

시나리오에서 버킷에 추가된 모든 새 객체와 제거된 객체를 추적이 필요하다고 요구하고 있습니다. SQS, SNS 및 Lambda에 지원되는 이벤트 유형 중 s3:ObjectCreated:* 및 s3:ObjectRemoved:Delete를 사용하면 요구 조건을 달성할 수 있습니다.

AWS Organizations에서 관리하는 단일 AWS 리전 내에 여러 AWS 계정이 있고 이러한 모든 계정의 모든 EC2 인스턴스가 비공개로 통신할 수 있도록 하고 싶습니다.

다음 솔루션 중 가장 저렴한 비용으로 기능을 제공하는 솔루션은 무엇입니까?

계정에 VPC를 생성하고 Resource Access Manager를 사용하여 하나 이상의 서브넷을 다른 계정과 공유

AWS Resource Access Manager(RAM)는 AWS 계정이나 AWS 조직 내에서 AWS 리소스를 쉽고 안전하게 공유할 수 있는 서비스입니다. AWS Transit Gateway, 서브넷, AWS License Manager 구성 및 Amazon Route 53 Resolver 규칙 리소스를 RAM과 공유할 수 있습니다. RAM을 사용하면 여러 계정에서 중복 리소스를 생성할 필요가 없으므로 소유하고 있는 모든 단일 계정에서 해당 리소스를 관리하는 운영 오버헤드가 줄어듭니다. 다중 계정 환경에서 중앙에서 리소스를 생성하고 RAM을 사용하여 리소스 공유 생성, 리소스 지정 및 계정 지정이라는 간단한 세 단계를 통해 계정 간에 해당 리소스를 공유할 수 있습니다. RAM은 추가 비용 없이 사용할 수 있습니다.

올바른 솔루션은 RAM을 사용하여 VPC 내에서 서브넷을 공유하는 것입니다. 이렇게 하면 모든 EC2 인스턴스가 동일한 VPC에 배포되고(다른 계정에서) 서로 쉽게 통신할 수 있습니다.

회사의 비즈니스 연속성 계획의 일환으로 IT 이사는 가능한 한 빨리 EC2 인스턴스에 대한 모든 EBS 볼륨의 자동 백업을 설정하도록 지시했습니다.

모든 EBS 볼륨을 자동으로 백업하는 가장 빠르고 비용 효율적인 솔루션은 무엇입니까?

Amazon Data Lifecycle Manager(Amazon DLM)를 사용하여 EBS 스냅샷 생성을 자동화합니다.

Amazon Data Lifecycle Manager를 사용하여 EBS 스냅샷 및 EBS-backed AMI의 생성, 보존 및 삭제를 자동화할 수 있습니다. 스냅샷 및 AMI 관리를 자동화하면 다음과 같은 이점이 있습니다.

- 정기적인 백업 일정을 실행하여 중요한 데이터를 보호합니다.

- 정기적으로 새로 고칠 수 있는 표준화된 AMI를 생성합니다.

- 감사 기관이나 내부 규정 준수 부서에서 요구하는 백업을 보관합니다.

- 오래된 백업을 삭제하여 스토리지 비용을 절감합니다.

- 격리된 계정에 데이터를 백업하는 재해 복구 백업 정책을 생성합니다.

Amazon CloudWatch Events 및 AWS CloudTrail의 모니터링 기능을 Amazon Data Lifecycle Manager와 조합하면 추가 비용 없이 Amazon EC2 인스턴스 및 개별 EBS 볼륨의 완벽한 백업 솔루션을 얻을 수 있습니다.

EBS 볼륨의 특정 시점 스냅샷을 생성하여 새 볼륨이나 데이터 백업의 기준으로 사용할 수 있습니다. 볼륨의 스냅샷이 주기적으로 생성되는 경우 스냅샷은 증분식이어서 새 스냅샷은 마지막 스냅샷 이후 변경된 블록만 저장합니다.

스냅샷은 비동기적으로 생성됩니다. 특정 시점 스냅샷은 즉시 생성되지만 스냅샷이 완료될 때까지, 즉 수정된 블록이 pending로 모두 이동할 때까지 스냅샷 상태는 Amazon S3입니다. 따라서 크기가 큰 최초의 스냅샷이나 변경된 블록이 많은 후속 스냅샷의 경우 몇 시간씩 시간이 걸릴 수 있습니다. 완료하는 동안 진행 중인 스냅샷은 볼륨에 대한 지속적인 읽기 및 쓰기의 영향을 받지 않습니다.

연결되어 사용 중인 볼륨의 스냅샷을 만들 수 있습니다. 하지만 스냅샷은 snapshot 명령을 실행할 때 Amazon EBS 볼륨에 기록된 데이터만 캡처합니다. 이때 애플리케이션이나 운영 체제에 의해 캐시된 데이터가 제외될 수 있습니다. 스냅샷을 만들기에 충분한 시간 동안 볼륨에 대한 파일 쓰기 작업을 일시 중지할 수 있는 경우 스냅샷이 완전해야 합니다. 하지만 볼륨에 대한 모든 파일 쓰기를 일시 중지할 수는 없는 경우에는 인스턴스 내에서 볼륨을 분리하고 snapshot 명령을 실행한 다음, 볼륨을 다시 마운트하여 일관되고 완전한 스냅샷이 되도록 해야 합니다. 스냅샷 상태가 pending인 상태에서 볼륨을 다시 마운트하고 사용할 수 있습니다.

스냅샷을 보다 쉽게 관리하기 위해 생성 중에 스냅샷에 태그를 지정하거나 나중에 태그를 추가할 수도 있습니다.

회사에서 개발 환경의 사용자 집합에 대한 액세스 권한을 위임하여 다른 AWS 계정으로 관리되는 프로덕션 환경의 일부 리소스에 액세스할 수 있도록 하려고 합니다.

Solutions Architect로서 다음 중 어떤 단계를 권장하시겠습니까?

프로덕션 환경의 리소스에 액세스하는 데 필요한 권한이 있는 새 IAM 역할을 생성합니다. 그러면 사용자는 프로덕션 환경에서 리소스에 액세스하는 동안 이 IAM 역할을 맡을 수 있습니다.

IAM 역할은 계정에 생성할 수 있는, 특정 권한을 지닌 IAM 자격 증명입니다. AWS에서 자격 증명이 할 수 있는 것과 없는 것을 결정하는 권한 정책을 갖춘 AWS 자격 증명이라는 점에서 IAM 역할은 IAM 사용자와 유사합니다. 그러나 역할은 한 사람과만 연관되지 않고 해당 역할이 필요한 사람이라면 누구든지 맡을 수 있어야 합니다. 또한 역할에는 그와 연관된 암호 또는 액세스 키와 같은 표준 장기 자격 증명이 없습니다. 대신에 역할을 맡은 사람에게는 해당 역할 세션을 위한 임시 보안 자격 증명이 제공됩니다.

역할을 사용하여 일반적으로 AWS 리소스에 액세스할 수 없는 사용자, 애플리케이션 또는 서비스에 액세스 권한을 위임할 수 있습니다. 예를 들어 AWS 계정의 사용자에게 이들이 대개 권한이 없는 리소스에 대한 액세스 권한을 부여하거나 한 AWS 계정의 사용자에게 다른 계정의 리소스에 대한 액세스 권한을 부여해야 할 경우가 있습니다. 또는 모바일 앱에서 AWS 리소스를 사용할 수 있도록 하되 앱에 AWS 키를 내장(교체하기 어렵고 사용자가 추출할 가능성이 있음)하길 원치 않는 경우도 있습니다. 때로는 기업 디렉토리에서처럼 AWS 외부에 정의된 자격 증명을 이미 보유하고 있는 사용자에게 AWS 액세스 권한을 부여해야 하는 경우도 있습니다. 또는 타사에 계정에 대한 액세스 권한을 부여하여 리소스에 대한 감사를 수행할 수 있도록 해야 할 경우도 있을 수 있습니다.

이러한 경우 IAM 역할을 사용하여 AWS 리소스에 대한 액세스 권한을 위임할 수 있습니다.

웹 애플리케이션에는 항상 실행되는 최소 6개의 Amazon Elastic Compute Cloud(EC2) 인스턴스가 필요합니다. 서울 리전의 3개 가용 영역(ap-northeast-2a, ap-northeast-2b 및 ap-northeast-2c)에 애플리케이션을 배포해야 합니다. 시스템은 하나의 가용 영역이 손실될 때까지 내결함성이 있어야 합니다.

다음 설정 중 시스템의 내결함성을 유지하는 가장 비용 효율적인 솔루션은 무엇입니까?

ap-northeast-2a의 인스턴스 3개, ap-northeast-2b의 인스턴스 3개, ap-northeast-2c의 인스턴스 3개

기본적으로 내결함성은 서비스 저하 없이 일부 구성 요소에 장애가 발생한 경우에도 시스템이 작동 상태를 유지하는 능력입니다. AWS에서는 시스템이 제대로 작동하고 소비자에게 서비스를 제공하기 위해 항상 실행되어야 하는 실행 중인 EC2 인스턴스 또는 리소스의 최소 수를 나타낼 수도 있습니다. 이것은 장애가 발생할 경우 하나 이상의 인스턴스 또는 리소스를 실행하는 것과 관련된 고가용성 개념과 상당히 다릅니다.

이 시나리오에서는 최소 6개의 인스턴스를 실행해야 하며 가장 비용 효율적이야 한다고 요구하고 있습니다. 1개의 가용 영역이 손실 되면 나머지 2개의 가용 영역에서 총 6개의 인스턴스가 있어야 합니다.

회사는 사용자의 운동 계획 애플리케이션을 개발했습니다. 애플리케이션은 일상적인 작업을 위해 다양한 AWS 서비스에 액세스해야 하는 EC2 인스턴스에 상주합니다.

다음 중 EC2 인스턴스가 S3 버킷 및 기타 AWS 서비스에 액세스하도록 허용하는 가장 좋은 방법은 무엇입니까?

IAM에서 역할을 생성하고 이를 EC2 인스턴스에 할당합니다.

이러한 경우 IAM 역할을 사용하여 AWS 리소스에 대한 액세스 권한을 위임할 수 있습니다.

API 자격 증명을 처리하는 모범 사례는 IAM(Identity Access Management) 서비스에서 새 역할을 생성한 다음 특정 EC2 인스턴스에 할당하는 것입니다. 이러한 방식으로 자격 증명을 안전하고 중앙 집중식으로 저장하고 관리할 수 있습니다.

전자 상거래 회사의 엔지니어링 팀은 EC2 인스턴스에 대한 비용 최적화 작업을 하고 있습니다. 팀은 여러 인스턴스 유형에서 온디맨드 및 스팟 인스턴스를 혼합하여 워크로드를 관리하려고 합니다. 그들은 이러한 인스턴스를 혼합하여 Auto Scaling 그룹을 만들고 싶습니다.

다음 중 엔지니어링 팀이 이 사례에 대한 인스턴스를 프로비저닝할 수 있는 옵션은 무엇입니까?

시작 템플릿을 사용하여 온디맨드 인스턴스와 스팟 인스턴스를 모두 사용하여 여러 인스턴스 유형에 용량을 프로비저닝하여 원하는 규모, 성능 및 비용을 달성할 수 있습니다.

시작 템플릿은 Amazon 머신 이미지(AMI)의 ID, 인스턴스 유형, 키 페어, 보안 그룹 및 시작하는 데 사용하는 기타 파라미터와 같은 인스턴스 구성 정보를 지정한다는 점에서 시작 구성과 유사합니다. EC2 인스턴스. 또한 시작 구성 대신 시작 템플릿을 정의하면 여러 버전의 템플릿을 가질 수 있습니다.

시작 템플릿을 사용하면 온디맨드 인스턴스와 스팟 인스턴스를 모두 사용하여 여러 인스턴스 유형에 용량을 프로비저닝하여 원하는 규모, 성능 및 비용을 달성할 수 있습니다.

소프트웨어 개발 회사는 온프레미스 인프라를 AWS 클라우드에 연결해야 합니다.

다음 중 이 작업을 수행하는 데 사용할 수 있는 AWS 서비스는 무엇입니까? (2개 선택)

IPsec VPN connection

AWS Direct Connect

IPsec VPN 연결, AWS VPN CloudHub 또는 타사 소프트웨어 VPN 어플라이언스가 될 수 있는 VPN 연결을 사용하여 VPC를 원격 네트워크에 연결할 수 있습니다. VPC VPN 연결은 IPSec을 사용하여 인터넷을 통해 인트라넷과 Amazon VPC 간에 암호화된 네트워크 연결을 설정합니다.

AWS Direct Connect는 인터넷을 사용하여 고객의 온프레미스 사이트를 AWS에 연결하는 대안을 제공하는 네트워크 서비스입니다. AWS Direct Connect에는 인터넷이 포함되지 않습니다. 대신 인트라넷과 Amazon VPC 간에 전용 사설 네트워크 연결을 사용합니다.

회사는 AWS에서 주력 웹 애플리케이션을 실행합니다. 애플리케이션은 피크 시간 동안 수천 명의 사용자에게 서비스를 제공합니다. 이 회사는 수십만 개의 금융 거래를 여러 내부 애플리케이션과 공유할 수 있는 확장 가능한 거의 실시간 솔루션이 필요합니다. 또한 솔루션은 대기 시간이 짧은 검색을 위해 정리된 트랜잭션을 문서 데이터베이스에 저장하기 전에 트랜잭션에서 민감한 세부 정보를 제거해야 합니다.

다음 중 어떤 것을 추천하시겠습니까?

스트리밍 트랜잭션을 Amazon Kinesis Data Streams에 공급합니다. Amazon Lambda 통합을 활용하여 모든 트랜잭션에서 민감한 데이터를 제거한 다음 정리된 트랜잭션을 DynamoDB에 저장합니다. 내부 애플리케이션은 Kinesis Data Stream에서 원시 트랜잭션을 사용할 수 있습니다.

Kinesis Data Streams를 사용하여 특수한 요구 사항에 따라 스트리밍 데이터를 처리하거나 분석하는 사용자 지정 애플리케이션을 구축할 수 있습니다. Kinesis Data Streams는 데이터 처리량 수준에서 데이터를 스트리밍하는 데 필요한 인프라, 스토리지, 네트워킹 및 구성을 관리합니다. 데이터 스트림을 위한 하드웨어, 소프트웨어 또는 기타 서비스의 프로비저닝, 배포 또는 지속적인 유지 관리에 대해 걱정할 필요가 없습니다.

주어진 사례의 경우 원시 금융 거래를 Kinesis Data Streams로 스트리밍할 수 있으며, Kinesis Data Streams는 데이터 스트림의 소비자 중 하나로 설정된 Lambda 함수에 의해 처리됩니다. Lambda는 모든 트랜잭션에서 민감한 데이터를 제거한 다음 정리된 트랜잭션을 DynamoDB에 저장합니다. 내부 애플리케이션을 데이터 스트림의 다른 소비자로 구성하고 원시 트랜잭션을 수집할 수 있습니다.

회사는 Amazon EC2 Windows 인스턴스에서 실행되는 .NET 웹 애플리케이션에 공유 파일 시스템을 사용해야 합니다. 파일 시스템은 Microsoft Active Directory와 통합할 수 있는 높은 수준의 처리량 및 IOPS를 제공해야 합니다.

이 요구 사항을 달성하기 위해 사용해야 하는 가장 적합한 서비스는 무엇입니까?

Amazon FSx for Windows File Server

Amazon FSx for Windows File Server는 완전 기본 Windows 파일 시스템이 지원하는 완전 관리형 Microsoft Windows 파일 서버를 제공합니다. FSx for Windows File Server는 엔터프라이즈 애플리케이션을 AWS 클라우드로 쉽게 리프트 앤 시프트할 수 있는 기능, 성능 및 호환성을 갖추고 있습니다.

Amazon FSx는 Microsoft Windows Server에 구축된 완전 관리형 파일 스토리지를 통해 광범위한 엔터프라이즈 Windows 워크로드를 지원합니다. Amazon FSx는 Windows 파일 시스템 기능과 네트워크를 통해 파일 스토리지에 액세스하기 위한 업계 표준 SMB(서버 메시지 블록) 프로토콜을 기본적으로 지원합니다. Amazon FSx는 기본 Windows 호환성, 엔터프라이즈 성능 및 기능, 일관된 밀리초 미만의 지연 시간으로 AWS 클라우드의 엔터프라이즈 애플리케이션에 최적화되어 있습니다.

Amazon FSx의 파일 스토리지를 사용하면 현재 Windows 개발자와 관리자가 사용하는 코드, 애플리케이션 및 도구를 변경 없이 계속 사용할 수 있습니다. Amazon FSx에 이상적인 Windows 애플리케이션 및 워크로드에는 비즈니스 애플리케이션, 홈 디렉터리, 웹 서비스, 콘텐츠 관리, 데이터 분석, 소프트웨어 빌드 설정 및 미디어 처리 워크로드가 포함됩니다.

완전 관리형 서비스인 FSx for Windows File Server는 파일 서버와 스토리지 볼륨을 설정하고 프로비저닝하는 관리 오버헤드를 제거합니다. 또한 Amazon FSx는 Windows 소프트웨어를 최신 상태로 유지하고 하드웨어 오류를 감지 및 해결하며 백업을 수행합니다. 또한 AWS IAM , Microsoft Active Directory용 AWS Directory Service , Amazon WorkSpaces , AWS Key Management Service 및 AWS CloudTrail 과 같은 다른 AWS 서비스와의 풍부한 통합을 제공합니다 .

Amazon FSx는 Microsoft의 DFS(분산 파일 시스템) 네임스페이스를 사용하여 동일한 네임스페이스의 여러 파일 시스템에서 성능을 최대 수십 Gbps 및 수백만 IOPS까지 확장할 수 있도록 지원합니다.

회사는 웹 애플리케이션의 Amazon RDS 데이터베이스 엔진으로 Amazon Aurora를 사용해야 합니다. Solutions Architect는 90일 백업 보존 정책을 구현하라는 지시를 받았습니다.

다음 중 주어진 요구 사항을 충족할 수 있는 옵션은 무엇입니까?

보관 기간이 90일인 일일 스냅샷을 생성하는 AWS Backup 계획을 생성합니다.

AWS Backup은 온프레미스 및 AWS 서비스 전반에서 데이터 보호를 자동화하고 중앙화할 수 있는 완전관리형 솔루션입니다. AWS Organizations와 AWS Backup을 함께 사용하면 중앙에서 데이터 보호(백업) 정책을 배포하여 조직의 AWS 계정 및 리소스 전반에 걸쳐 백업 활동을 구성, 관리, 제어할 수 있습니다. AWS Backup을 사용하여 AWS Backup Audit Manager를 통해 데이터 보호 정책 규정 준수를 감사하고 보고할 수도 있습니다.

AWS Backup을 사용하여 다음 AWS 서비스의 백업을 생성하고 관리할 수 있습니다.

- Amazon Elastic Block Store(Amazon EBS) 볼륨

- Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스(Windows 애플리케이션 포함)

- Amazon EC2의 Windows Volume Shadow Copy Service(VSS) 지원 애플리케이션(Windows Server, Microsoft SQL Server 및 Microsoft Exchange Server 포함).

- Amazon Relational Database Service(Amazon RDS) 데이터베이스(Amazon Aurora 클러스터 포함)

- Amazon DynamoDB 테이블, Amazon Elastic File System(Amazon EFS) 파일 시스템

- Amazon FSx for NetApp ONTAP 파일 시스템

- Amazon FSx for OpenZFS 파일 시스템

- Amazon FSx for Windows File Server 파일 시스템

- Amazon FSx for Lustre 파일 시스템

- Amazon Neptune 데이터베이스

- Amazon DocumentDB(MongoDB 호환) 데이터베이스

- AWS Storage Gateway 볼륨

- Amazon Simple Storage Service(Amazon S3).

- 또한 AWS Backup을 사용하여 Amazon Outposts, VMware CloudTM on AWS 및 온프레미스 VMware 가상 머신의 백업을 생성하고 관리할 수 있습니다.

이 시나리오에서는 AWS Backup을 사용하여 보존 기간이 90일인 백업 계획을 생성할 수 있습니다. 백업 계획은 AWS 리소스를 백업할 시기와 방법을 정의하는 정책 표현식입니다. 백업 계획에 리소스를 할당하면 AWS Backup이 백업 계획에 따라 해당 리소스에 대한 백업을 자동으로 백업하고 유지합니다.

신문 회사에는 Fargate 시작 유형을 사용하여 뉴스 웹 사이트를 호스팅하는 Amazon ECS 클러스터가 있습니다. 애플리케이션 데이터는 모두 미사용 데이터 암호화가 활성화된 Amazon Keyspaces(Apache Cassandra용)에 저장됩니다. 엄격한 보안 규정을 준수하려면 환경 변수를 사용하여 데이터베이스 자격 증명을 제공해야 합니다. Solutions Architect는 자격 증명이 안전하고 클러스터 자체에서 일반 텍스트로 볼 수 없는지 확인해야 합니다.

다음 중 최소한의 노력으로 구현할 수 있는 이 시나리오에서 가장 적합한 솔루션은 무엇입니까?

AWS Systems Manager Parameter Store를 사용하여 데이터베이스 자격 증명을 유지한 다음 AWS KMS를 사용하여 암호화합니다. Amazon ECS 작업 실행 역할(taskRoleArn)에 대한 IAM 역할을 생성하고 KMS와 Parameter Store 모두에 대한 액세스를 허용하는 작업 정의와 함께 참조합니다. 컨테이너 정의 내에서 컨테이너에 설정할 환경 변수의 이름과 컨테이너에 표시할 민감한 데이터가 포함된 Systems Manager Parameter Store 파라미터의 전체 ARN으로 비밀을 지정합니다.

Amazon ECS를 사용하면 AWS Secrets Manager 암호 또는 AWS Systems Manager 파라미터 스토어 파라미터에 민감한 데이터를 저장한 다음 컨테이너 정의에서 참조하여 민감한 데이터를 컨테이너에 주입할 수 있습니다. 이 기능은 EC2 및 Fargate 시작 유형을 모두 사용하는 작업에서 지원됩니다.

암호는 다음과 같은 방법으로 컨테이너에 노출될 수 있습니다.

- 환경 변수로 민감한 데이터를 컨테이너에 삽입하려면 secrets 컨테이너 정의 파라미터를 사용하세요.

- 컨테이너의 로그 구성에서 중요한 정보를 참조하려면 secretOptions 컨테이너 정의 파라미터를 사용하세요.

Systems Manager 파라미터 스토어 파라미터를 사용하여 컨테이너에 민감한 데이터를 지정할 때 다음 사항을 고려합니다.

- Systems Manager Parameter Store 파라미터는 태스크가 실행되는 동일한 계정에 있어야 합니다.

- Fargate에서 호스팅되는 태스크의 경우 이 기능을 사용하려면 태스크에서 플랫폼 버전 1.3.0 이상(Linux의 경우) 또는 1.0.0 이상(Windows의 경우)을 사용해야 합니다.

- EC2 인스턴스에서 호스팅되는 태스크의 경우 이 기능을 사용하려면 컨테이너 인스턴스에 버전 1.22.0 이상의 컨테이너 에이전트가 있어야 합니다. 그러나 최신 버전의 컨테이너 에이전트를 사용하는 것이 좋습니다.

- 컨테이너가 처음 시작될 때 해당 컨테이너에 중요한 정보가 주입됩니다. 암호 또는 Parameter Store 파라미터가 이후에 업데이트되거나 교체되면 컨테이너가 업데이트된 값을 자동으로 받지 않습니다. 새 태스크를 시작해야 하거나 작업이 서비스의 일부인 경우 서비스를 업데이트하고 새 배포 강제 적용을 사용하여 서비스에서 새 태스크를 시작하도록 강제로 지정할 수 있습니다.

Amazon ECS 암호에 대한 필수 IAM 권한을 사용하려면 Amazon ECS 태스크 실행 역할이 있어야 하며 태스크 정의에서 해당 역할을 참조해야 합니다. 이렇게 하면 컨테이너 에이전트가 필요한 AWS Systems Manager 리소스를 가져올 수 있습니다.

컨테이너 정의 내에서 컨테이너에 설정할 환경 변수의 이름으로 secrets를 지정하여 컨테이너에 제공할 민감한 데이터가 들어있는 Systems Manager 파라미터 스토어 파라미터의 전체Amazon 리소스 이름(ARN)을 지정합니다.

Systems Manager 파라미터 스토어 파라미터가 현재 실행 중인 태스크와 동일한 리전에 있는 경우, 파라미터의 전체 ARN 또는 이름을 사용할 수 있습니다. 파라미터가 다른 리전에 있다면 전체 ARN을 지정해야 합니다.

회사의 웹 애플리케이션은 CloudFront를 사용하여 S3 버킷에 저장된 이미지, 비디오 및 기타 정적 콘텐츠를 전 세계 사용자에게 배포하고 있습니다. 이 회사는 최근 일부 고품질 미디어 파일에 대한 새로운 회원 전용 액세스 권한을 도입했습니다. 현재 URL을 변경할 필요 없이 유료 구독자에게만 여러 개인 미디어 파일에 대한 액세스를 제공해야 한다는 요구 사항이 있습니다.

다음 중 이 요구 사항을 충족하기 위해 구현해야 하는 가장 적합한 솔루션은 무엇입니까?

CloudFront 서명된 쿠키를 사용하여 콘텐츠 액세스를 제어합니다.

CloudFront 서명된 URL 및 서명된 쿠키는 기본 기능이 같습니다. 바로 콘텐츠에 액세스할 수 있는 대상을 제어하는 기능입니다. CloudFront를 통해 프라이빗 콘텐츠를 제공 중이며 서명된 URL 또는 서명된 쿠키 중 하나를 결정해야 하는 경우, 다음 사항을 고려합니다.

다음과 같은 경우 서명된 URL을 사용합니다.

1. 애플리케이션 설치 파일을 다운로드하는 등 개별 파일에 대한 액세스를 제한하고 싶은 경우

2. 사용자가 쿠키를 지원하지 않는 클라이언트(예: 사용자 지정 HTTP 클라이언트)를 사용하는 경우

다음과 같은 경우 서명된 쿠키를 사용합니다.

1. HLS 형식의 비디오 파일 전체 또는 웹 사이트의 구독자 영역에 있는 파일 전체 등 제한된 파일 여러 개에 대한 액세스 권한을 제공하려는 경우

2. 현재의 URL을 변경하고 싶지 않은 경우

현재의 URL을 변경하지 않으려는 경우나 여러 제한된 파일(예: 웹 사이트의 구독자 영역에 있는 전체 파일)에 대한 액세스 권한을 제공하려는 경우, CloudFront 서명된 쿠키를 사용하여 콘텐츠 액세스를 제어할 수 있습니다.

회사에는 SQS 대기열이 있는 스팟 EC2 인스턴스의 Auto Scaling 그룹에서 호스팅되는 분산 배치 처리 애플리케이션이 있습니다. 클라이언트 측 버퍼링을 사용하도록 구성 요소를 구성하여 클라이언트에서 만들어진 호출이 먼저 버퍼링된 다음 SQS에 일괄 요청으로 보내집니다.

SQS 대기열에서 다른 소비 구성 요소가 메시지를 수신 및 처리하지 못하도록 하는 것은 무엇입니까?

가시성 시간 제한

가시성 제한 시간은 Amazon SQS가 다른 소비 구성 요소가 메시지를 수신 및 처리하지 못하도록 하는 기간입니다.

소비자가 대기열에서 메시지를 수신하고 처리할 때 메시지는 대기열에 남아 있습니다. Amazon SQS는 메시지를 자동으로 삭제하지 않습니다. Amazon SQS는 분산 시스템이므로 소비자가 실제로 메시지를 수신한다는 보장은 없습니다(예: 연결 문제 또는 소비자 애플리케이션 문제로 인해). 따라서 소비자는 메시지를 수신하고 처리한 후 큐에서 메시지를 삭제해야 합니다.

메시지를 수신한 직후에는 메시지가 대기열에 그대로 있습니다. 다른 소비자가 메시지를 다시 처리하지 못하게 하기 위해 Amazon SQS에서제한 시간 초과Amazon SQS에서 다른 소비자가 메시지를 수신하고 처리할 수 없도록 차단하는 기간을 말합니다. 메시지의 기본 제한 시간은 30초입니다. 최소는 0초입니다. 최대 시간은 12시간입니다.

회사는 자체 관리형 메시지 지향 미들웨어 시스템에서 Amazon SQS로 메시징 대기열을 마이그레이션하고 있습니다. 회사의 개발팀은 SQS 사용 비용을 최소화하려고 합니다.

다음 중 어떤 옵션을 권장하시겠습니까?

SQS 긴 폴링을 사용하여 Amazon SQS 대기열에서 메시지 검색

Amazon Simple Queue Service(SQS)는 마이크로서비스, 분산 시스템 및 서버리스 애플리케이션을 분리하고 확장할 수 있는 완전관리형 메시지 대기열 서비스입니다.

Amazon SQS는 대기열에서 메시지를 수신하기 위해 짧은 폴링과 긴 폴링을 제공합니다. 기본적으로 대기열은 짧은 폴링을 사용합니다. 짧은 폴링을 사용하면 쿼리에서 메시지를 찾지 못한 경우에도 Amazon SQS가 즉시 응답을 보냅니다. 긴 폴링의 경우 Amazon SQS는 요청에 지정된 최대 메시지 수까지 사용 가능한 메시지를 하나 이상 수집한 후 응답을 보냅니다. Amazon SQS는 폴링 대기 시간이 만료되는 경우에만 빈 응답을 보냅니다.

Amazon SQS 긴 폴링은 Amazon SQS 대기열에서 메시지를 검색하는 방법입니다. 일반 짧은 폴링은 폴링되는 메시지 대기열이 비어 있는 경우에도 즉각 응답을 반환하는 반면, 긴 폴링은 메시지가 메시지 대기열에 도달하거나 긴 폴링 제한 시간이 초과할 때까지 응답을 반환하지 않습니다.

긴 폴링을 사용하면 Amazon SQS 대기열에서 메시지가 사용 가능해지는 즉시 간편하고 경제적인 방법으로 메시지를 검색할 수 있습니다. 긴 폴링을 사용하면 빈 응답을 수신하는 횟수를 줄일 수 있으므로 SQS 사용 비용을 절감할 수 있습니다.

개발자는 HTML, CSS 및 JavaScript를 사용하여 웹사이트를 구축하는 방법을 배우고 있습니다. 그는 정적 웹 사이트를 만든 다음 Amazon S3에 배포했습니다. 개발자는 웹사이트의 엔드포인트를 파악하지 못하는 것 같습니다.

Amazon S3 웹 사이트 엔드포인트에 허용되는 형식은 무엇입니까? (2개 선택)

http://bucket-name.s3-website-Region.amazonaws.com

http://bucket-name.s3-website.Region.amazonaws.com

Amazon S3에서 정적 웹 사이트를 호스팅하려면 웹 사이트 호스팅을 위해 Amazon S3 버킷을 구성한 다음 웹 사이트 콘텐츠를 버킷에 업로드합니다. 버킷을 정적 웹 사이트로 구성할 때 정적 웹 사이트 호스팅을 활성화하고 권한을 설정하고 색인 문서를 추가합니다. 웹 사이트 요구 사항에 따라 리디렉션, 웹 트래픽 로깅 및 사용자 지정 오류 문서를 비롯한 다른 옵션을 구성할 수도 있습니다.

버킷을 정적 웹 사이트로 구성하면 버킷의 AWS 리전별 웹 사이트 엔드포인트에서 웹 사이트를 사용할 수 있습니다.

리전에 따라 Amazon S3 웹 사이트 엔드포인트는 다음 두 형식 중 하나를 따릅니다.

s3-website 대시(-) 리전 ‐ http://bucket-name.s3-website-Region.amazonaws.com

s3-website 점(.) 리전 ‐ http://bucket-name.s3-website.Region.amazonaws.com

빅 데이터 분석 회사는 Kinesis Data Streams(KDS)를 사용하여 회사의 필드 장치에서 IoT 데이터를 처리하고 있습니다. 여러 소비자 애플리케이션이 들어오는 데이터 스트림을 사용하고 있으며 엔지니어는 데이터 스트림의 생산자와 소비자 간의 데이터 전달 속도에 대한 성능 지연을 발견했습니다.

주어진 사례의 성능을 개선하기 위해 다음 중 어떤 것을 추천하시겠습니까?

Kinesis Data Streams의 향상된 팬아웃 기능 사용

Amazon Kinesis Data Streams(KDS)는 확장성과 내구성이 뛰어난 실시간 데이터 스트리밍 서비스입니다. KDS는 웹사이트 클릭스트림, 데이터베이스 이벤트 스트림, 금융 거래, 소셜 미디어 피드, IT 로그 및 위치 추적 이벤트와 같은 수십만 개의 소스에서 초당 기가바이트의 데이터를 지속적으로 캡처할 수 있습니다.

향상된 팬아웃을 사용하면 개발자는 스트림 소비자가 향상된 팬아웃을 사용하여 자체의 샤드당 초당 2MB의 읽기 처리량 파이프를 할당 받도록 등록할 수 있으며 이 처리량은 스트림의 샤드 수에 따라 자동 확장됩니다. 향상된 팬아웃 출시 전에는 고객이 다운스트림 애플리케이션에 원하는 읽기 처리량을 지원하기 위해 수시로 데이터를 여러 스트림으로 팬아웃해야 했습니다. AWS에서는 이를 불필요하고 번거로운 작업이라고 판단하여 고객의 부담을 없애기로 결정하였습니다. 고객은 향상된 팬아웃을 사용하여 검색한 데이터 양과 샤드당 등록된 고객 수를 기반으로 향상된 팬아웃 요금을 지불합니다.

회사는 온프레미스 데이터 센터와 AWS 클라우드 인프라를 위한 하이브리드 클라우드 구조를 가지고 있습니다. 이 회사는 Amazon S3에 모든 로그를 백업하면서 가장 자주 액세스하는 로그만 로컬에서 캐시된 데이터로 사용할 수 있는 웹 로그 보관 솔루션을 구축하려고 합니다.

다음 중 이 사용 사례에 권장하는 솔루션은 무엇입니까?

AWS Volume Gateway - 캐시된 볼륨을 사용하여 가장 자주 액세스하는 로그를 로컬에 저장하여 짧은 지연 시간 액세스를 제공하는 동시에 전체 볼륨을 Amazon S3 서비스 버킷에 저장

AWS Storage Gateway는 사실상 무제한의 클라우드 스토리지에 대한 온프레미스 액세스 권한을 제공하는 하이브리드 클라우드 스토리지 서비스입니다. Storage Gateway는 iSCSI, SMB 및 NFS와 같은 표준 스토리지 프로토콜 세트를 제공하므로 기존 애플리케이션을 다시 작성하지 않고 AWS 스토리지를 사용할 수 있습니다. Amazon 클라우드 스토리지 서비스에 데이터를 안전하고 안정적으로 저장하면서 자주 액세스하는 데이터는 온프레미스에 캐싱하여 지연 시간이 짧은 성능을 제공합니다. Storage Gateway는 변경된 데이터만 전송하고 데이터를 압축하여 AWS로의 데이터 전송을 최적화합니다. Storage Gateway는 Amazon S3 및 Amazon FSx for Windows File Server 클라우드 스토리지와 기본적으로 통합하여 데이터를 클라우드 내에서 처리할 수 있고, AWS Identity and Access Management(IAM)와 통합하여 서비스 및 리소스에 대한 액세스 관리를 안전하게 보호할 수 있으며, AWS Key Management Service(KMS)와 통합하여 클라우드에 저장된 데이터를 암호화하고, Amazon CloudWatch와 통합하여 모니터링 기능을 제공하고, AWS CloudTrail과 통합하여 계정 활동을 로깅할 수 있습니다

회사에는 하루 24시간 연중무휴로 대용량 데이터를 처리하는 Linux 및 Windows EC2 인스턴스로 구성된 클라우드 아키텍처가 있습니다. 시스템의 고가용성을 보장하기 위해 Solutions Architect는 모든 인스턴스의 메모리 및 디스크 사용률 메트릭을 모니터링할 수 있는 솔루션을 만들어야 합니다.

다음 중 구현하기에 가장 적합한 모니터링 솔루션은 무엇입니까?

메모리 및 디스크 사용 데이터를 수집하는 모든 EC2 인스턴스에 CloudWatch 에이전트를 설치합니다. Amazon CloudWatch 콘솔에서 사용자 지정 지표를 봅니다.

Amazon CloudWatch는 Amazon Web Services(AWS) 리소스 및 AWS에서 실행되는 애플리케이션을 실시간으로 모니터링합니다. CloudWatch를 사용하여 리소스 및 애플리케이션에 대해 측정할 수 있는 변수인 지표를 수집하고 추적할 수 있습니다.

CloudWatch 홈페이지에는 사용 중인 모든 AWS 서비스에 관한 지표가 자동으로 표시됩니다. 사용자 지정 대시보드를 추가로 생성해 사용자 지정 애플리케이션에 대한 지표를 표시하고, 선택한 지표의 사용자 지정 집합을 표시할 수 있습니다.

지표를 감시해 알림을 보내거나 임계값을 위반한 경우 모니터링 중인 리소스를 자동으로 변경하는 경보를 생성할 수 있습니다. 예를 들면, Amazon EC2 인스턴스의 CPU 사용량과 디스크 읽기 및 쓰기를 모니터링한 다음에 증가한 로드를 처리하려면 추가 인스턴스를 시작해야 하는지 여부를 해당 데이터로 결정할 수 있습니다. 또한 이러한 데이터를 사용하여 잘 사용되지 않는 인스턴스를 중지할 수도 있습니다.

CloudWatch를 사용하면 시스템 전체의 리소스 사용률, 애플리케이션 성능, 운영 상태를 파악할 수 있습니다.

AWS는 Amazon EC2를 모니터링하는 데 사용할 수 있는 다양한 도구를 제공합니다. 이들 도구 중에는 모니터링을 자동으로 수행하도록 구성할 수 있는 도구도 있지만, 수동 작업이 필요한 도구도 있습니다.

참고 : CloudWatch 모니터링 스크립트는 더 이상 사용되지 않습니다. CloudWatch 에이전트를 사용하여 지표와 로그를 수집하는 것이 좋습니다.

통합 CloudWatch 에이전트를 사용하면 다음을 수행할 수 있습니다.

- 운영 체제 전반에 걸쳐 Amazon EC2 인스턴스에서 내부 시스템 수준 지표를 수집할 수 있습니다. 지표에는 EC2 인스턴스 지표뿐만 아니라 인게스트 지표도 포함될 수 있습니다. 수집할 수 있는 추가 지표는 CloudWatch 에이전트가 수집하는 지표에 나열되어 있습니다.

- 온프레미스 서버로부터 시스템 수준 지표를 수집합니다. 여기에는 AWS가 관리하지 않는 서버뿐만 아니라 하이브리드 환경의 서버도 포함될 수 있습니다.

- StatsD 및 collectd 프로토콜을 사용하여 애플리케이션 또는 서비스에서 사용자 지정 지표를 검색할 수 있습니다. StatsD는 Windows Server가 실행되는 서버와 Linux 서버에서 모두 지원되며, collectd는 Linux 서버에서만 지원됩니다.

- Linux 또는 Windows Server를 실행하는 Amazon EC2 인스턴스 및 온프레미스 서버에서 로그를 수집할 수 있습니다.

Amazon CloudWatch에는 CPU 사용률, 네트워크 사용률, 디스크 성능 및 디스크 읽기/쓰기 모니터링에 사용할 수 있는 Amazon EC2 지표가 있습니다. 아래 항목을 모니터링해야 하는 경우 CloudWatch 에이전트를 사용하여 사용자 지정 메트릭을 준비해야 합니다.

- 메모리 활용도

- 디스크 스왑 활용

- 디스크 공간 활용

- 페이지 파일 활용

- 로그 수집

회사에 기본 연결된 75GB SSD 인스턴스 스토어 지원 볼륨이 있는 실행 중인 m5ad.large EC2 인스턴스가 있습니다. 종료한 다음 인스턴스를 시작합니다. 이전에 연결된 볼륨에 저장한 데이터를 더 이상 사용할 수 없음을 확인했습니다.

이것의 원인은 무엇입니까?

EC2 인스턴스는 사용 기간이 짧고 인스턴스 수명 동안만 사용되는 인스턴스 스토어 볼륨을 사용하고 있었습니다.

인스턴스 스토어는 인스턴스에 블록 수준의 임시 스토리지를 제공합니다. 스토리지는 호스트 컴퓨터에 물리적으로 연결된 디스크에 위치합니다. 인스턴스 스토어는 버퍼, 캐시, scratch 데이터 및 기타 임시 콘텐츠와 같이 자주 변경되는 정보의 임시 스토리지나 로드가 분산된 웹 서버 풀과 같은 여러 인스턴스상에서 복제되는 데이터에 가장 적합합니다.

실행 시에만 인스턴스에 대한 인스턴스 스토어 볼륨을 지정할 수 있습니다. 하나의 인스턴스에서 인스턴스 스토어 볼륨을 분리하고 다른 인스턴스에 연결할 수 없습니다.

인스턴스 스토리지의 데이터는 관련 인스턴스의 수명 기간 동안만 지속됩니다. 인스턴스가 재부팅(의도적 또는 의도적이지 않게)되면 인스턴스 스토어의 데이터는 유지됩니다. 그러나 다음 상황에서는 인스턴스 스토어의 데이터가 손실됩니다.

- 기본 디스크 드라이브 오류

- 인스턴스가 중지됨

- 인스턴스가 최대 절전 모드로 전환됨

- 인스턴스가 종료됨

그러므로 중요한 장기 데이터의 경우 인스턴스 스토어에 의존하지 마세요. 오히려 Amazon S3, Amazon EBS 또는 Amazon EFS 등 내구성이 뛰어난 데이터 스토리지를 사용하는 것이 좋습니다.

인스턴스를 중지하거나 최대 절전 모드로 전환하거나 종료하면 인스턴스 스토어의 모든 스토리지 블록이 리셋됩니다. 따라서 다른 인스턴스의 인스턴스 스토어를 통해 데이터를 액세스할 수 없습니다.

인스턴스에서 AMI를 생성한 경우 해당 인스턴스 스토어 볼륨의 데이터는 보존되지 않고 이 AMI를 실행한 인스턴스용 인스턴스 스토어 볼륨에 존재하지 않습니다.

인스턴스 유형을 변경하면 인스턴스 스토어가 새 인스턴스 유형에 연결되지 않습니다.

회사에는 Amazon EC2에서 실행되는 비디오 트랜스코딩 애플리케이션이 있습니다. 각 EC2 인스턴스는 대기열을 폴링하여 트랜스코딩해야 하는 비디오를 찾은 다음 트랜스코딩 프로세스를 실행합니다. 이 프로세스가 중단되면 대기열 시스템을 기반으로 하는 다른 인스턴스에 의해 비디오가 트랜스코딩됩니다. 이 애플리케이션에는 트랜스코딩해야 하는 많은 비디오 백로그가 있습니다. 관리자는 EC2 인스턴스를 더 추가하여 이 백로그를 줄이고자 하지만 이러한 인스턴스는 백로그가 줄어들 때까지만 필요합니다.

이 시나리오에서 어떤 유형의 Amazon EC2 인스턴스를 사용하는 것이 가장 비용 효율적인 유형입니까?

스팟 인스턴스

애플리케이션의 트랜스코딩 프로세스를 보강하기 위해 기본 서버가 아니라 예비 컴퓨팅 리소스로 사용할 인스턴스가 필요합니다. 이러한 인스턴스는 백로그가 크게 감소한 후에도 종료되어야 합니다. 또한 시나리오에서는 현재 프로세스가 중단되면 대기열 시스템을 기반으로 하는 다른 인스턴스에서 비디오를 트랜스코딩할 수 있다고 언급합니다. 즉, 스팟 가격이 설정된 최고 가격보다 높을 때 스팟 인스턴스가 종료되는 경우와 같이 애플리케이션이 EC2 인스턴스의 예기치 않은 종료를 정상적으로 처리할 수 있습니다. 따라서 Amazon EC2 스팟 인스턴스는 이 시나리오에 가장 적합하고 비용 효율적인 옵션입니다.

Amazon EC2 스팟 인스턴스는 온디맨드 가격에 비해 대폭 할인된 가격으로 사용할 수 있는 AWS 클라우드의 예비 컴퓨팅 용량입니다. EC2 스팟을 사용하면 AWS 클라우드에서 비용을 최적화하고 동일한 예산으로 애플리케이션 처리량을 최대 10배까지 확장할 수 있습니다. EC2 인스턴스를 시작할 때 스팟을 선택하기만 하면 온디맨드 가격을 최대 90%까지 절약할 수 있습니다. 온디맨드 인스턴스와 스팟 인스턴스의 유일한 차이점은 EC2에 다시 용량이 필요할 때 2분 알림으로 스팟 인스턴스가 EC2에 의해 중단될 수 있다는 것입니다.

회사는 EBS 스토리지 볼륨(io1)이 비용의 90%를 차지하고 나머지 10% 비용이 EC2 인스턴스에 기인할 수 있다는 사실을 알게 되었습니다. CloudWatch 지표는 EC2 인스턴스와 EBS 볼륨 모두 활용도가 낮다고 보고합니다. CloudWatch 지표는 EBS 볼륨에 가끔 I/O 버스트가 있음을 보여줍니다. 전체 인프라는 AWS CloudFormation에서 관리합니다.

비용 절감을 위해 제안할 수 있는 것은 무엇입니까?

Amazon EC2 인스턴스 EBS 볼륨을 gp2로 변환합니다.

Amazon EBS는 다음의 볼륨 유형을 제공하고 이러한 볼륨 유형은 성능 특성과 가격이 다르므로 애플리케이션의 필요에 맞게 스토리지 성능과 비용을 조정할 수 있습니다.

SSD(Solid-State Drive) — 주요 성능 특성이 IOPS인 작은 I/O 크기의 읽기/쓰기 작업을 자주 처리하는 트랜잭션 워크로드에 최적화되어 있습니다. SSD 지원 볼륨 유형에는 다음이 포함됩니다.

- 범용 SSD 볼륨 : 범용 SSD(gp2 및 gp3) 볼륨은 SSD(Solid-State Drive)로 지원됩니다. 다양한 트랜잭션 워크로드를 위한 가격과 성능의 균형을 유지합니다. 여기에는 가상 데스크톱, 중간 크기의 단일 인스턴스 데이터베이스, 지연 시간에 민감한 대화형 애플리케이션, 개발 및 테스트 환경, 부팅 볼륨이 포함됩니다. 대부분의 워크로드에 이 볼륨을 사용하는 것이 좋습니다.

- Provisioned IOPS SSD 볼륨 : 프로비저닝된 IOPS SSD 볼륨은 SSD(Solid-State Drive)로 지원됩니다. 짧은 지연 시간이 필요한 중요하고 IOPS 집약적이며 처리량 집약적 워크로드를 위해 설계된 최고 성능의 Amazon EBS 스토리지 볼륨입니다.

Amazon EBS는 3가지 유형의 프로비저닝된 IOPS SSD 볼륨을 제공합니다.

1. 프로비저닝된 IOPS SSD(io2) 볼륨

2. 프로비저닝된 IOPS SSD(io2) Block Express 볼륨

3. 프로비저닝된 IOPS SSD(io1) 볼륨

HDD(Hard Disk Drive) — 주요 성능 특성이 처리량인 대규모 스트리밍 워크로드에 최적화되어 있습니다. HDD 지원 볼륨 유형에는 처리량 최적화 HDD 및 콜드 HDD 볼륨이 포함됩니다.

범용 SSD(gp2) 볼륨은 광범위한 워크로드에 이상적인 비용 효율적인 스토리지를 제공합니다. 이러한 볼륨은 한 자릿수 밀리초의 대기 시간과 확장된 기간 동안 3,000 IOPS로 버스트하는 기능을 제공합니다. 최소 100IOPS(33.33GiB 이하)에서 최대 16,000IOPS(5,334GiB 이상) 사이에서 기준 성능은 볼륨 크기 GiB당 3IOPS로 선형 확장됩니다. AWS는 99% 가동 시간의 프로비저닝된 성능을 제공하도록 gp2 볼륨을 설계합니다. gp2 볼륨의 크기 범위는 1GiB에서 16TiB입니다.

따라서 gp2는 io1보다 비용 효율적이고 필요할 때 성능을 높일 수 있으므로 올바른 선택입니다.

Linux EC2 인스턴스의 ASG(Auto Scaling 그룹)에는 CloudWatch에서 기본 모니터링이 활성화된 Amazon FSx for OpenZFS 파일 시스템이 있습니다. Solutions Architect는 ASG에서 호스팅되는 레거시 웹 애플리케이션을 로드하는 데 오랜 시간이 걸린다는 사실을 알게 되었습니다. 인스턴스를 확인한 후, 아키텍트는 서버가 이미 높은 메모리 사용량을 가지고 있음에도 불구하고 ASG가 더 많은 인스턴스를 시작하지 않는다는 것을 알아차렸습니다.

다음 중 이 문제를 해결하기 위해 아키텍트가 구현해야 하는 옵션은 무엇입니까?

CloudWatch 통합 에이전트를 EC2 인스턴스에 설치합니다. CloudWatch 에이전트 구성으로 AWS Systems Manager Parameter Store에서 사용자 지정 파라미터를 설정하여 메모리 사용량 백분율에 대한 집계 지표를 생성합니다. 집계된 지표를 기반으로 Auto Scaling 그룹을 확장합니다.

통합 CloudWatch 에이전트를 사용하면 다음을 수행할 수 있습니다.

- 운영 체제 전반에 걸쳐 Amazon EC2 인스턴스에서 내부 시스템 수준 지표를 수집할 수 있습니다. 지표에는 EC2 인스턴스 지표뿐만 아니라 인게스트 지표도 포함될 수 있습니다.

- Linux 또는 Windows Server를 실행하는 Amazon EC2 인스턴스 및 온프레미스 서버에서 로그를 수집할 수 있습니다.

시나리오의 전제는 EC2 서버의 메모리 사용량이 높지만 이 특정 지표는 기본적으로 Auto Scaling 그룹에서 추적하지 않기 때문에 확장 활동이 트리거되지 않는다는 것입니다. 기본적으로 CloudWatch는 메모리 사용량을 모니터링하지 않고 CPU 사용률, 네트워크 사용률, 디스크 성능 및 디스크 읽기/쓰기만 모니터링합니다.

이것이 Auto Scaling Group에서 조정 활동에 대한 트리거로 사용할 사용자 지정 지표(메모리 사용량)를 수집하고 모니터링하기 위해 EC2 인스턴스에 CloudWatch 에이전트를 설치해야 하는 이유입니다.

AWS Systems Manager의 기능인 Parameter Store는 구성 데이터 관리 및 암호 관리를 위한 안전한 계층적 스토리지를 제공합니다. 암호, 데이터베이스 문자열, Amazon Machine Image(AMI) ID, 라이선스 코드와 같은 데이터를 파라미터 값으로 저장할 수 있습니다. 값을 일반 텍스트 또는 암호화된 데이터로 저장할 수 있습니다. 파라미터를 생성할 때 지정한 고유 이름을 사용하여 스크립트, 명령, SSM 문서, 구성 및 자동화 워크플로에서 Systems Manager 파라미터를 참조할 수 있습니다.

최근에 인턴 개발자가 새로 생성된 RDS 데이터베이스를 잘못 구성하여 프로덕션 중단이 발생했습니다.

모든 AWS 사용자가 사용할 수 있도록 RDS 특정 모범 사례를 재사용 가능한 인프라 템플릿에 통합하려면 어떻게 해야 합니까?

CloudFormation을 사용하여 RDS 데이터베이스를 관리합니다.

AWS CloudFormation은 클라우드 환경에서 AWS 및 타사 애플리케이션 리소스를 모델링하고 프로비저닝할 수 있는 공통 언어를 제공합니다. AWS CloudFormation을 사용하면 프로그래밍 언어 또는 간단한 텍스트 파일을 사용하여 모든 리전 및 계정에서 애플리케이션에 필요한 모든 리소스를 자동화되고 안전한 방식으로 모델링하고 프로비저닝할 수 있습니다. 이를 통해 AWS 및 타사 리소스에 대한 단일 정보 소스를 얻을 수 있습니다.

CloudFormation을 사용하면 인프라를 코드로 유지하고 구성 매개변수에 대해 회사 주변의 모범 사례를 재사용할 수 있습니다.

시스템 관리자가 프라이빗 호스팅 영역을 생성하고 이를 Virtual Private Cloud(VPC)와 연결했습니다. 그러나 프라이빗 호스팅 영역에 대한 DNS 쿼리는 확인되지 않은 상태로 남아 있습니다.

프라이빗 호스팅 영역을 작동시키기 위해 구성할 Amazon VPC 옵션은 무엇입니까?

프라이빗 호스팅 영역에 대해 DNS 호스트 이름 및 DNS 확인 활성화

DNS 호스트 이름 및 DNS 확인은 프라이빗 호스팅 영역에 대한 필수 설정입니다. 프라이빗 호스팅 영역에 대한 DNS 쿼리는 Amazon 제공 VPC DNS 서버에서만 확인할 수 있습니다. 따라서 프라이빗 호스팅 영역이 작동하려면 이러한 옵션을 활성화해야 합니다.

DNS 호스트 이름: Amazon VPC 마법사를 사용하여 생성되지 않은 기본이 아닌 가상 프라이빗 클라우드의 경우 이 옵션은 기본적으로 비활성화되어 있습니다. 도메인에 대한 프라이빗 호스팅 영역을 생성하고 DNS 호스트 이름을 활성화하지 않고 해당 영역에 레코드를 생성하면 프라이빗 호스팅 영역이 활성화되지 않습니다. 프라이빗 호스팅 영역을 사용하려면 이 옵션을 활성화해야 합니다.

DNS 확인: 프라이빗 호스팅 영역은 VPC DNS 서버의 DNS 쿼리만 수락합니다. VPC DNS 서버의 IP 주소는 VPC IPv4 네트워크 범위의 기본에 2를 더한 예약된 IP 주소입니다. DNS 확인을 활성화하면 VPC DNS 서버를 DNS 확인을 수행하기 위한 확인자로 사용할 수 있습니다. DHCP 옵션 세트에서 사용자 지정 DNS 서버를 사용하고 프라이빗 호스팅 영역을 사용하지 않는 경우 이 옵션을 비활성화된 상태로 유지합니다.

다중 AZ 배포 구성에서 ECS 클러스터 및 RDS를 사용하는 온라인 상거래 플랫폼이 AWS에서 호스팅됩니다. 애플리케이션은 복잡한 읽기 및 쓰기 데이터베이스 작업을 처리하기 위해 RDS 인스턴스를 많이 사용하고 있습니다. 시스템의 안정성, 가용성 및 성능을 유지하려면 각 프로세스에서 사용하는 CPU 대역폭 및 총 메모리의 백분율을 포함하여 DB 인스턴스의 여러 프로세스 또는 스레드가 CPU를 사용하는 방식을 면밀히 모니터링해야 합니다.

다음 중 데이터베이스를 적절히 모니터링하는 데 가장 적합한 솔루션은 무엇입니까?

RDS에서 향상된 모니터링(Enhanced Monitoring)을 활성화합니다.

Amazon RDS는 DB 인스턴스가 실행되는 운영 체제(OS)에 대한 측정치를 실시간으로 제공합니다. 콘솔에서 RDS DB 인스턴스에 대한 모든 시스템 지표 및 프로세스 정보를 볼 수 있습니다. 각 인스턴스에 대해 모니터링할 지표를 관리하고 요구 사항에 따라 대시보드를 사용자 지정할 수 있습니다.

RDS는 지표를 확장 모니터링에서 Amazon CloudWatch Logs 계정으로 전달합니다. CloudWatch Logs에서 CloudWatch에서 지표 필터를 생성하고 CloudWatch 대시보드에 그래프를 표시할 수 있습니다. 또한 선택한 모니터링 시스템에서 CloudWatch Logs의 Enhanced Monitoring JSON 출력을 사용할 수 있습니다.

CloudWatch와 Enhanced Monitoring 메트릭 간에는 특정 차이점이 있습니다. CloudWatch는 DB 인스턴스의 하이퍼바이저에서 CPU 사용률에 대한 지표를 수집하고 Enhanced Monitoring은 인스턴스의 에이전트에서 지표를 수집합니다. 결과적으로 하이퍼바이저 계층이 소량의 작업을 수행하기 때문에 측정값 간의 차이를 찾을 수 있습니다. 따라서 이 시나리오에서는 RDS에서 Enhanced Monitoring을 활성화하는 것이 정답입니다.

개발자가 샘플 Amazon S3 버킷 정책을 다운로드하여 새로운 전사적 액세스 정책을 기반으로 변경했습니다. 그는 이 버킷 정책을 이해하는 데 도움을 요청했습니다.

{
"Version": "2012-10-17",
"Id": "S3PolicyId1",
"Statement": [
{
"Sid": "IPAllow",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::examplebucket/*",
"Condition": {
"IpAddress": {"aws:SourceIp": "54.240.143.0/24"},
"NotIpAddress": {"aws:SourceIp": "54.240.143.188/32"}
}
}
]
}

다음 중 주어진 정책에 대한 올바른 설명은 무엇입니까?

하나의 IP 주소를 제외한 전체 CIDR에 S3 버킷에 액세스할 수 있는 권한을 부여합니다.

정책을 생성하고 IAM 자격 증명(사용자, 사용자 그룹 또는 역할) 또는 AWS 리소스에 연결하여 AWS에서 액세스를 관리합니다. 정책은 자격 증명 또는 리소스와 연결될 때 권한을 정의하는 AWS의 객체입니다. AWS는 IAM 보안 주체(사용자 또는 역할)가 요청할 때 이러한 정책을 평가합니다. 정책의 권한은 요청의 허용 여부를 결정합니다. 대부분의 정책은 AWS에 JSON 문서로 저장됩니다. AWS는 자격 증명 기반 정책, 리소스 기반 정책, 권한 경계, AWS Organizations SCP, ACL 및 세션 정책의 6가지 유형의 정책을 지원합니다.

버킷 정책을 한 번에 한 단계씩 분석해 보겠습니다.

스니펫 "Effect": "Allow"는 허용 효과를 의미합니다.

스니펫 "Principal": "*"는 모든 Principal을 의미합니다.

"Action": "s3:*" 스니펫은 모든 S3 API를 의미합니다.

"Resource": "arn:aws:s3:::examplebucket/*" 스니펫은 리소스가 버킷 examplebucket 및 해당 콘텐츠가 될 수 있음을 의미합니다.

지정된 버킷 정책의 마지막 스니펫: "Condition": { "IpAddress": {"aws:SourceIp": "54.240.143.0/24"}, "NotIpAddress": {"aws:SourceIp": "54.240.143.188 /32"} } 이 스니펫은 소스 IP가 CIDR 블록 "54.240.143.0/24"(== 54.240.143.0 - 54.240.143.255)에 있으면 examplebucket과 해당 콘텐츠에 액세스할 수 있음을 의미합니다.

그러나 소스 IP는 CIDR "54.240.143.188/32"(== 1 IP, 54.240.143.188/32) 차단됩니다.

즉, 하나의 IP 주소가 examplebucket 및 해당 콘텐츠에 액세스하지 못하도록 명시적으로 차단됩니다.

AWS 계정 루트 사용자를 생성할 때 따라야 하는 보안 권장 사항은 무엇입니까? (2개 선택)

AWS 계정 루트 사용자 계정에 대해 MFA(Multi Factor Authentication) 활성화합니다.

AWS 계정 루트 사용자에 대한 강력한 암호를 생성합니다.

다음은 AWS 계정 루트 사용자를 생성할 때의 몇 가지 모범 사례입니다.

1) 강력한 암호를 사용하여 AWS Management 콘솔에 대한 계정 수준 액세스를 보호합니다.

2) AWS 계정 루트 사용자 암호 또는 액세스 키를 누구와도 공유하지 마십시오.

3) AWS 계정 루트 사용자에 대한 액세스 키가 있는 경우 삭제합니다. 보관해야 하는 경우 액세스 키를 정기적으로 교체(변경)합니다. 액세스 키를 암호화하여 Amazon S3에 저장하면 안 됩니다.

4) AWS 계정 루트 사용자에 대한 액세스 키가 아직 없는 경우 꼭 필요한 경우가 아니면 생성하지 마십시오.

5) AWS 계정 루트 사용자 계정에서 AWS MFA(다단계 인증)를 활성화합니다.

AWS 리소스를 보호하려면 AWS Identity and Access Management(IAM)에 대한 다음 모범 사례를 참고합니다.

- 임시 보안 인증을 사용하여 AWS에 액세스하려면 인간 사용자가 ID 공급자와의 페더레이션을 사용하도록 요구합니다.

- AWS에 액세스하려면 워크로드에 IAM 역할이 있는 임시 자격 증명을 사용하도록 요구합니다.

- 다중 인증(MFA) 필요

- 장기 보안 인증이 필요한 사용 사례의 경우 정기적으로 액세스 키 교체

- 루트 사용자 보안 인증을 보호하고 일상적인 작업에 사용하지 마세요.

- 최소 권한 적용

- AWS 관리형 정책으로 시작하고 최소 권한을 향해 나아갑니다.

- IAM 액세스 분석기를 사용하여 액세스 활동을 기반으로 최소 권한 정책 생성

- 사용하지 않는 사용자, 역할, 권한, 정책 및 보안 인증은 정기적으로 검토하고 제거합니다.

- IAM 정책의 조건을 사용하여 액세스 추가 제한

- IAM Access Analyzer를 사용하여 리소스에 대한 퍼블릭 및 크로스 계정 액세스 확인

- IAM Access Analyzer를 사용하여 IAM 정책을 검증하여 안전하고 기능적인 권한을 보장합니다.

- 여러 계정에 권한 가드레일 설정

- 권한 경계를 사용하여 계정 내에서 권한 관리 위임

회사의 컴퓨터 비전 연구원은 EC2 인스턴스에서 실행되는 독점 알고리즘에 대한 I/O 바인딩 프로세스를 최적화하려고 합니다. 이상적인 스토리지는 결과를 Amazon S3에 다시 업로드하기 전에 임시 스토리지 공간에서 파일 처리를 수행할 때 고성능 IOPS를 촉진합니다.

다음 AWS 스토리지 옵션 중 가장 성능이 뛰어나고 비용 최적인 옵션은 무엇입니까?

스토리지 옵션으로 인스턴스 스토어와 함께 EC2 인스턴스를 사용합니다.

하나 이상의 인스턴스 스토어 볼륨으로 구성된 인스턴스 스토어는 블록 디바이스로 표시됩니다. 인스턴스 스토어의 크기는 물론 사용 가능한 디바이스의 수는 인스턴스 유형에 따라 다릅니다.

일부 인스턴스 유형은 NVMe 또는 SATA 기반 SSD(반도체 드라이브)를 사용하여 높은 임의 I/O 성능을 제공합니다. 이는 대기 시간이 매우 짧은 스토리지가 필요할 때 좋은 옵션이지만 인스턴스가 종료될 때 데이터를 유지할 필요가 없거나 내결함성 아키텍처를 활용할 수 있습니다.

인스턴스 스토어는 높은 임의 I/O 성능을 제공하므로 임시 저장 공간 역할을 할 수 있으며 이러한 볼륨은 인스턴스 사용 비용의 일부로 포함됩니다.

회사는 매일 다른 소스로부터 반구조화 및 구조화 데이터를 수신하고 있습니다. Solutions Architect는 빅 데이터 처리 프레임워크를 사용하여 방대한 양의 데이터를 분석하고 다양한 비즈니스 인텔리전스 도구와 표준 SQL 쿼리를 사용하여 액세스할 계획입니다.

다음 중 이 요구 사항을 충족하는 가장 고성능의 솔루션을 제공하는 것은 무엇입니까?

Amazon EMR 클러스터를 생성하고 처리된 데이터를 Amazon Redshift에 저장합니다.

Amazon EMR은 Apache Spark, Apache Hive 및 Presto와 같은 오픈 소스 프레임워크를 사용하여 페타바이트급 데이터 처리, 대화식 분석 및 기계 학습을 위한 업계 최고의 클라우드 빅 데이터 솔루션입니다.

빅 데이터 분석 수행

통계 알고리즘 및 예측 모델을 사용하여 대규모 데이터 처리 및 가정 분석을 실행하여 숨겨진 패턴, 상관 관계, 시장 동향 및 고객 선호도를 밝혀냅니다.

확장 가능한 데이터 파이프라인 구축

다양한 소스에서 데이터를 추출하고 대규모로 처리하여 애플리케이션과 사용자가 사용할 수 있도록 합니다.

실시간 데이터 스트림 처리

스트리밍 데이터 소스의 이벤트를 실시간으로 분석하여 장기 실행, 고가용성, 내결함성 스트리밍 데이터 파이프라인을 생성합니다.

데이터 과학 및 기계 학습 채택 가속화

Apache Spark MLlib, TensorFlow 및 Apache MXNet과 같은 오픈 소스 기계 학습 프레임워크를 사용하여 데이터를 분석합니다. 대규모 모델 훈련, 분석 및 보고를 위해 Amazon SageMaker Studio에 연결합니다.

Amazon Redshift는 SQL을 사용하여 여러 데이터 웨어하우스, 운영 데이터베이스 및 데이터 레이크에서 정형 데이터 및 반정형 데이터를 분석하고 AWS가 설계한 하드웨어 및 기계 학습을 사용해 어떤 규모에서든 최고의 가격 대비 성능을 지원합니다.

시나리오의 핵심 문구는 데이터를 분석하기 위한 "빅 데이터 처리 프레임워크"와 "다양한 비즈니스 인텔리전스 도구 및 표준 SQL 쿼리"입니다. 빅 데이터 처리 프레임워크를 활용하려면 Amazon EMR을 사용해야 합니다. 클러스터는 데이터 변환(ETL)을 수행하고 분석 및 비즈니스 인텔리전스 애플리케이션을 위해 처리된 데이터를 Amazon Redshift로 로드합니다.

회사는 Application Load Balancer 뒤에 있는 EC2 인스턴스의 Auto Scaling 그룹에서 웹 애플리케이션을 호스팅하고 있습니다. 최근에 Solutions Architect는 애플리케이션에 대한 일련의 SQL 주입 시도와 사이트 간 스크립팅 공격을 식별하여 프로덕션 데이터에 부정적인 영향을 미쳤습니다.

다음 중 이러한 종류의 공격을 완화하기 위해 아키텍트가 구현해야 하는 것은 무엇입니까?

AWS Web Application Firewall(WAF)에서 SQL 삽입 및 교차 사이트 스크립팅 공격을 차단하는 보안 규칙을 설정합니다. 그리고 규칙을 Application Load Balancer에 연결합니다.

AWS WAF는 가용성에 영향을 주거나, 보안을 위협하거나, 리소스를 과도하게 사용하는 일반적인 웹 공격으로부터 웹 애플리케이션이나 API를 보호하는 데 도움이 되는 웹 애플리케이션 방화벽입니다. AWS WAF에서는 SQL 주입 또는 사이트 간 스크립팅과 같은 일반적인 공격 패턴을 차단하는 보안 규칙 및 사용자가 정의한 특정 트래픽 패턴을 필터링하는 규칙을 생성하도록 지원하여 애플리케이션에 트래픽이 도달하는 방법을 제어할 수 있습니다. 특정 트래픽 패턴을 필터링하는 규칙을 사용자 정의할 수도 있습니다. AWS 또는 AWS Marketplace Seller에서 관리하는 사전 구성된 규칙 집합인 AWS WAF의 관리 규칙을 사용하여 OWASP Top 10 보안 위험 및 과도한 리소스를 소비하거나 메트릭을 왜곡하거나 다운타임을 유발할 수 있는 자동화된 봇과 같은 문제를 신속하게 해결할 수 있습니다. 이러한 규칙은 새 문제가 나타나면 정기적으로 업데이트됩니다. AWS WAF에는 보안 규칙의 생성, 배포 및 유지보수를 자동화하는 데 사용할 수 있는 모든 기능을 갖춘 API가 포함되어 있습니다.

CDN 솔루션의 일부인 Amazon CloudFront, EC2에서 실행되는 웹 서버 또는 오리진 서버의 전방에 배치된 Application Load Balancer, REST API용 Amazon API Gateway, 또는 GraphQL API용 AWS AppSync에 AWS WAF를 배포할 수 있습니다. AWS WAF를 사용하면 사용하는 것에 대해서만 비용을 지불하고 가격은 배포한 규칙 수와 애플리케이션이 수신하는 웹 요청 수에 따라 결정됩니다.

가장 단순한 수준에서 AWS WAF에서는 다음 동작 중 하나를 선택할 수 있습니다.

1. 지정한 요청을 제외한 모든 요청 허용— Amazon CloudFront, Amazon API Gateway, Application Load Balancer, AWS AppSync 또는 Amazon Cognito에서 공용 웹 사이트의 콘텐츠를 제공하지만 공격자의 요청을 차단하려는 경우에도 유용합니다.

2. 지정한 요청을 제외한 모든 요청 차단— 웹 요청의 속성 (예: 웹 사이트를 탐색하는 데 사용하는 IP 주소) 으로 사용자를 쉽게 식별할 수 있는 제한된 웹 사이트의 콘텐츠를 제공하려는 경우에 유용합니다.

3. 기준과 일치하는 요청 수— 카운트 작업을 사용하면 처리 방식을 수정하지 않고도 웹 트래픽을 추적할 수 있습니다. 이를 일반 모니터링과 새 웹 요청 처리 규칙을 테스트하는 데 사용할 수 있습니다. 웹 요청의 새 속성을 기반으로 요청을 허용하거나 차단하려면 먼저 구성하면 됩니다.AWS WAF해당 속성과 일치하는 요청을 계산할 수 있습니다. 이렇게 하면 새 허용 또는 차단 동작을 구현하기 전에 새 구성 설정을 확인할 수 있습니다.

3. 실행CAPTCHA기준과 일치하는 요청을 확인합니다.— 구현할 수 있습니다CAPTCHA요청을 제어하여 보호된 리소스에 대한 봇 트래픽을 줄이는 데 도움이 됩니다.

회사는 스마트 장치의 주요 메트릭을 측정하기 위해 가정에 마스터 센서를 배포할 계획입니다. 이러한 장치에 대한 조정 명령을 제공하기 위해 회사는 센서의 키를 기반으로 정렬된 데이터를 지원하고 높은 처리량 메시지(초당 수천 개의 메시지)를 유지하는 스트리밍 시스템을 원합니다.

다음 중 이 사례에 권장하는 AWS 서비스는 무엇입니까?

Amazon Kinesis Data Streams (KDS)

Amazon Kinesis Data Streams(KDS)는 확장성과 내구성이 뛰어난 실시간 데이터 스트리밍 서비스입니다. KDS는 웹사이트 클릭스트림, 데이터베이스 이벤트 스트림, 금융 거래, 소셜 미디어 피드, IT 로그 및 위치 추적 이벤트와 같은 수십만 개의 소스에서 초당 기가바이트의 데이터를 지속적으로 캡처할 수 있습니다. Amazon Kinesis 데이터 스트림의 처리량은 데이터 스트림 내의 샤드 수를 늘려 제한 없이 확장할 수 있도록 설계되었습니다.

그러나 Amazon Kinesis Data Streams를 사용하는 동안 염두에 두어야 할 특정 제한이 있습니다.

Kinesis 데이터 스트림은 기본적으로 24시간부터 최대 8760시간(365일)까지의 레코드를 저장합니다.

한 레코드 내에서 데이터 Blob(Base64 인코딩 이전의 데이터 페이로드)의 최대 크기는 1MB입니다. 각 샤드는 초당 최대 1000개의 PUT 레코드를 지원할 수 있습니다.

여기서 Kinesis가 정답입니다. 메시지에 파티션 키를 제공하면 스트림이 샤딩된 경우에도 특정 센서에 대해 정렬된 메시지를 보장할 수 있기 때문입니다.

회사에서 네트워크 보안 감사를 수행할 계획입니다. 웹 애플리케이션은 수신 트래픽을 고르게 분산하기 위해 Application Load Balancer가 앞에 있는 EC2 인스턴스의 Auto Scaling 그룹에서 호스팅됩니다. Solutions Architect는 회사 클라우드 인프라의 보안 태세를 강화하고 리소스에 대한 DDoS 공격의 영향을 최소화하는 임무를 받았습니다.

다음 중 구현해야 하는 가장 효과적인 솔루션은 무엇입니까?

Amazon CloudFront 배포를 구성하고 Application Load Balancer를 오리진으로 설정합니다. AWS WAF 및 AWS Shield를 사용하여 속도 기반 웹 ACL 규칙을 생성하고 이를 Amazon CloudFront와 연결합니다.

AWS WAF는 가용성에 영향을 미치거나 보안을 손상시키거나 과도한 리소스를 소비할 수 있는 일반적인 웹 악용으로부터 웹 애플리케이션 또는 API를 보호하는 데 도움이 되는 웹 애플리케이션 방화벽입니다. AWS WAF를 사용하면 SQL 주입 또는 사이트 간 스크립팅과 같은 일반적인 공격 패턴을 차단하는 보안 규칙과 사용자가 정의한 특정 트래픽 패턴을 필터링하는 규칙을 생성할 수 있으므로 트래픽이 애플리케이션에 도달하는 방식을 제어할 수 있습니다. CDN 솔루션의 일부로 Amazon CloudFront에 AWS WAF를 배포할 수 있으며, EC2에서 실행되는 웹 서버나 오리진 서버의 전면에 있는 Application Load Balancer 또는 API용 Amazon API Gateway를 배포할 수 있습니다.

DDoS 공격을 탐지하고 완화하기 위해 AWS Shield와 함께 AWS WAF를 사용할 수 있습니다. AWS WAF는 트래픽 인라인을 검사하여 웹 애플리케이션 계층 DDoS 공격을 감지하고 완화하는 데 도움이 되는 웹 애플리케이션 방화벽입니다. 애플리케이션 계층 DDoS 공격은 잘 구성되었지만 악의적인 요청을 사용하여 완화를 회피하고 애플리케이션 리소스를 소비합니다. 공격 트래픽을 차단하기 위한 조건, 규칙 및 작업 집합이 포함된 사용자 지정 보안 규칙을 정의할 수 있습니다. 웹 ACL을 정의한 후 CloudFront 배포에 적용할 수 있으며 웹 ACL은 구성할 때 지정한 우선 순위에 따라 평가됩니다.

AWS WAF를 사용하면 CloudFront 배포 또는 Application Load Balancer에서 웹 ACL(액세스 제어 목록)을 구성하여 요청 서명을 기반으로 요청을 필터링하고 차단할 수 있습니다. 각 웹 ACL은 문자열 일치 또는 정규식 일치가 URI, 쿼리 문자열, HTTP 메서드 또는 헤더 키와 같은 하나 이상의 요청 속성과 일치하도록 구성할 수 있는 규칙으로 구성됩니다. 또한 AWS WAF의 비율 기반 규칙을 사용하여 규칙과 일치하는 요청이 사용자가 정의한 임계값을 초과할 때 불량 행위자의 IP 주소를 자동으로 차단할 수 있습니다. 문제가 되는 클라이언트 IP 주소의 요청은 403 Forbidden 오류 응답을 수신하고 요청 비율이 임계값 아래로 떨어질 때까지 차단된 상태로 유지됩니다. 이는 일반 웹 트래픽으로 위장한 HTTP 플러드 공격을 완화하는 데 유용합니다.

AWS Shield Advanced 보호의 일부로 속도 기반 규칙이 있는 웹 ACL을 추가하는 것이 좋습니다. 이러한 규칙은 잠재적인 DDoS 이벤트를 나타낼 수 있는 트래픽의 갑작스러운 급증에 대해 경고할 수 있습니다. 비율 기반 규칙은 5분 동안 모든 개별 주소에서 도착하는 요청을 계산합니다. 요청 수가 정의한 제한을 초과하면 규칙이 알림 보내기와 같은 작업을 트리거할 수 있습니다.

귀하는 SaaS(Software as a Service) 회사에서 Solutions Architect로 일하고 있으며 회사 고객을 위한 솔루션 설계를 돕습니다. 고객 중 하나는 은행이고 은행이 인터넷을 통해 외부 서비스에 액세스할 때 최대 2개의 퍼블릭 IP를 허용 목록에 추가해야 합니다.

고가용성을 유지하고 최대 10개의 인스턴스를 지원하며 은행의 요구 사항을 준수하기 위해 어떤 아키텍처 선택을 권장합니까?

Auto Scaling 그룹(ASG)과 함께 Network Load Balancer 사용

Network Load Balancer는 초당 수백만 개의 요청으로 확장되는 짧은 대기 시간 및 높은 처리량 워크로드와 관련된 사례에 가장 적합합니다. Network Load Balancer는 연결 수준(계층 4)에서 작동하여 IP 프로토콜 데이터를 기반으로 Amazon Virtual Private Cloud(Amazon VPC) 내 대상(Amazon EC2 인스턴스, 마이크로서비스 및 컨테이너)으로 연결을 라우팅합니다. Network Load Balancer는 OSI(Open Systems Interconnection) 모델의 네 번째 계층에서 작동합니다. 초당 수백만 개의 요청을 처리할 수 있습니다.

Network Load Balancer는 고정 IP를 공개 웹에 노출하므로 이러한 IP를 사용하여 예측 가능한 방식으로 애플리케이션에 연결할 수 있으며 ASG를 사용하여 Network Load Balancer 뒤에서 애플리케이션을 확장할 수 있습니다.

회사는 AWS Organizations를 사용하여 통합된 여러 AWS 계정을 사용하고 있습니다. 여러 S3 객체를 자신이 소유한 다른 AWS 계정에 속한 다른 S3 버킷에 복사하려고 합니다. Solutions Architect는 이 작업에 필요한 권한을 설정하고 대상 계정이 객체를 보낸 계정이 아니라 복사된 객체를 소유하도록 하라는 지시를 받았습니다.

Architect는 이 요구 사항을 어떻게 달성할 수 있습니까?

IAM 사용자 또는 역할이 한 계정의 원본 버킷에서 다른 계정의 대상 버킷으로 객체를 복사할 수 있도록 허용하는 IAM 고객 관리형 정책을 생성하여 S3에서 교차 계정 권한을 구성합니다. 그런 다음 계정 간에 객체를 복사하는 데 사용할 IAM 사용자 또는 역할에 정책을 연결합니다.

애플리케이션은 현재 단일 가용 영역(AZ)에 배포된 4개의 EC2 인스턴스(Application Load Balancer 뒤)에서 호스팅됩니다. 수용 가능한 수준의 최종 사용자 경험을 유지하려면 애플리케이션에서 항상 사용 가능한 최소 4개의 인스턴스가 필요합니다.

애플리케이션이 최소 비용으로 고가용성을 달성할 수 있도록 다음 중 어떤 것을 추천하시겠습니까?

3개의 가용 영역에 인스턴스를 배포합니다. 각 가용 영역에서 두 개의 인스턴스를 시작합니다.

올바른 옵션은 3개의 가용 영역에 인스턴스를 배포하고 각 가용 영역에서 2개의 인스턴스를 시작하는 것입니다. AZ 중 하나가 중단되더라도 여전히 4개의 인스턴스를 사용할 수 있으며 애플리케이션은 수용 가능한 수준의 최종 사용자 경험을 유지할 수 있습니다. 따라서 이 경우 단 6개의 인스턴스로 고가용성을 달성할 수 있습니다.

Solutions Architect는 관계형 데이터베이스를 설정하고 multi-region 장애를 완화하기 위한 재해 복구 계획을 수립해야 합니다. 이 솔루션에는 1초의 RPO(복구 시점 목표)와 1분 미만의 RTO(복구 시간 목표)가 필요합니다.

다음 중 이 요구 사항을 충족할 수 있는 AWS 서비스는 무엇입니까?

Amazon Aurora 글로벌 데이터베이스

Amazon Aurora는 서버리스 및 기계 학습 기반 애플리케이션의 구축을 위한 규모에 따른 성능 및 고가용성, 완전한 오픈 소스 MySQL 및 PostgreSQL 호환 버전과 광범위한 개발자 도구를 제공하는 현대적 관계형 데이터베이스 서비스입니다.

Aurora는 컴퓨팅 리소스에서 분리되고 데이터베이스 인스턴스당 최대 128TB까지 자동 확장되는 내결함성을 갖춘 자가 복구 분산 스토리지 시스템을 제공합니다. 대기 시간이 짧은 읽기 전용 복제본 최대 15개, 특정 시점으로의 복구, Amazon Simple Storage Service(Amazon S3)로의 지속적 백업, 3개 가용 영역(AZ)에 걸친 복제를 통해 뛰어난 성능과 가용성을 제공합니다.

또한 Amazon Aurora는 하드웨어 프로비저닝, 데이터베이스 설정, 패치 적용 및 백업과 같은 시간 소모적인 관리 태스크를 자동화하는 동시에 1/10의 비용으로 상용 데이터베이스의 보안, 가용성 및 안정성을 제공하는 완전관리형 서비스입니다.

Amazon Aurora Global Database는 전 세계적으로 분산된 애플리케이션을 위해 설계되었으며, 단일 Amazon Aurora 데이터베이스를 여러 AWS 리전으로 확장해 줍니다. 데이터베이스 성능에 어떠한 영향도 주지 않고 데이터를 복제하고, 각 리전에서 낮은 지연 시간으로 빠른 로컬 읽기를 지원하며, 리전 규모의 가동 중단 발생 시 재해 복구를 제공합니다.

재무, 여행 또는 게임 애플리케이션과 같이 전 세계에 분포한 중요 워크로드는 가용성 요구 사항이 엄격하며, 리전 규모의 가동 중단 시에도 문제가 없어야 합니다. 일반적으로 이러한 경우 성능, 가용성, 비용 및 데이터 무결성 사이에 상충 관계가 있었습니다. 글로벌 데이터베이스는 데이터베이스를 모두 활용하며 애플리케이션 워크로드를 처리할 수 있는 전용 인프라를 사용하여 1초 미만의 일반적인 지연 시간으로 스토리지 기반 복제를 사용합니다. 리전의 성능 저하 또는 가동 중단은 드문 일이지만, 보조 리전 중 하나가 1분 이내에 읽기 및 쓰기 기능으로 승격될 수 있습니다.

기본 리전에서 성능 저하 또는 가동 중지가 발생한 경우 보조 리전 중 하나를 승격하여 읽기/쓰기 책임을 맡길 수 있습니다. Aurora 클러스터는 리전이 완전히 가동 중지되는 경우에도 1분 이내에 재해 복구가 가능합니다. 이로써 애플리케이션에 효율적인 1초의 Recovery Point Objective(RPO) 및 1분 미만의 Recovery Time Objective(RTO)를 제공하여, 글로벌 비즈니스 연속성 계획의 탄탄한 기반을 제공합니다.

현재 테이프 백업 솔루션을 사용하여 애플리케이션 데이터를 온프레미스에 저장하고 있습니다. 클라우드 스토리지 서비스를 이용해 1년에 1~2회 정도 접근할 수 있는 백업 데이터를 최대 10년간 보존할 계획입니다.

다음 중 이 솔루션을 구현하는 가장 비용 효율적인 옵션은 무엇입니까?

AWS Storage Gateway를 사용하여 데이터를 Amazon S3 Glacier Deep Archive에 직접 백업합니다.

테이프 게이트웨이는 가상 미디어 체인저, 가상 테이프 드라이브 및 가상 테이프로 구성된 iSCSI 가상 테이프 라이브러리(VTL) 인터페이스를 백업 애플리케이션에 제공합니다. 가상 테이프는 Amazon S3에 저장되며 Amazon S3 Glacier 또는 Amazon S3 Glacier Deep Archive에 아카이브될 수 있습니다.

S3 Glacier Deep Archive는 최저 비용의 스토리지를 제공합니다. 연 1회 미만으로 액세스되고 비동기식으로 검색되는 수명이 긴 아카이브 데이터의 경우 S3 Glacier Flexible Retrieval 대비 최대 75%까지 비용을 낮출 수 있습니다. S3 Glacier Deep Archive는 매월 GB당 0.00099 USD(TB당 약 1 USD)로 클라우드에서 가장 저렴한 스토리지를 제공합니다. 온프레미스 테이프에서 데이터를 저장 및 유지 관리하거나 오프사이트에서 데이터를 보관하는 것보다 훨씬 낮은 가격으로 이용할 수 있습니다. S3 Glacier Deep Archive는 비용 효율적이고 관리하기 쉬운 테이프의 대안입니다. 고객 요구 사항과 규정 준수 요구 사항을 충족하기 위해 데이터 집합을 7~10년 이상 보관하는 금융 서비스, 의료, 미디어, 엔터테인먼트, 공공 부문의 고객을 위해 설계되었습니다. S3 Glacier Deep Archive는 특정 연도에 물리적으로 분리된 여러 AWS 가용 영역에서 데이터를 중복 저장하여 99.999999999%(9 11개)의 데이터 내구성과 99.99%의 가용성을 지원하도록 설계되었습니다.

회사의 비즈니스에는 2개의 AWS 계정이 있으며 모든 리소스는 us-west-2 리전에서 프로비저닝됩니다. 개발자는 인스턴스가 us-west-2 리전의 동일한 가용 영역에 있도록 두 AWS 계정 각각에서 EC2 인스턴스를 시작하려고 합니다. 각 AWS 계정에서 인스턴스를 시작하는 동안 동일한 기본 서브넷(us-west-2a)을 선택한 후에도 개발자는 가용 영역이 여전히 다르다는 것을 알아차립니다.

다음 중 이 문제를 해결하려면 어떻게 해야 합니까?

AZ ID를 사용하여 두 AWS 계정에서 가용 영역을 고유하게 식별합니다.

가용 영역은 리전 코드와 문자 식별자로 표시됩니다. 예: us-west-2a. 리전의 가용 영역에 걸쳐 리소스가 배포될 수 있도록 각 AWS 계정의 코드에 가용 영역을 독립적으로 매핑합니다. 예를 들어 us-east-1a 계정의 AWS 가용 영역은 다른 us-east-1a 계정에 대한 AWS와 물리적 위치가 동일하지 않을 수 있습니다.

계정에 대해 가용 영역을 조정하려면 가용 영역에 대한 고유하고 일관된 식별자인 AZ ID를 사용해야 합니다. 예를 들어, use1-az1은 us-east-1 리전의 AZ ID이고, 모든 AWS 계정에서 물리적 위치가 동일합니다. 계정의 AZ ID를 보고 다른 계정의 리소스와 관련된 리소스의 물리적 위치를 확인할 수 있습니다. 예를 들어, AZ ID가 use1-az2인 가용 영역의 서브넷을 다른 계정과 공유하면 이 서브넷은 AZ ID가 use1-az2인 가용 영역의 계정에서 사용할 수 있습니다.

AWS Management 콘솔을 통해 EC2 대시보드의 서비스 상태 섹션으로 이동하여 AZ ID를 볼 수 있습니다.

EC2 인스턴스에서 시작된 인메모리 데이터베이스가 있고 데이터베이스의 인메모리 상태를 잃지 않고 EC2 인스턴스를 중지하고 시작할 수 있기를 원합니다.

aws연습 문제

티스토리툴바