AWS 연습 문제

728x90

회사는 고해상도 이미지를 Amazon S3에 업로드하려고 합니다. 이미지 크기는 약 3GB입니다. 회사는 더 빠른 이미지 업로드를 위해 S3TA(S3 Transfer Acceleration)를 사용지만 S3TA로 인해 전송이 가속화되지 않은 것으로 나타났습니다.

이 시나리오에서 이 이미지 전송에 대한 요금과 관련하여 다음 중 옳은 것은 무엇입니까?

회사는 이미지 업로드에 대한 전송 비용을 지불할 필요가 없습니다.

인터넷에서 데이터를 전송할 때 S3 데이터 전송 요금은 없습니다. 또한 S3TA를 사용하면 가속화된 전송에 대해서만 비용을 지불합니다. 따라서 회사는 S3TA로 인해 가속화된 전송이 발생하지 않았기 때문에 이미지 업로드에 대한 전송 요금을 지불할 필요가 없습니다.

Amazon S3 Transfer Acceleration은 더 큰 객체의 장거리 전송을 위해 Amazon S3와의 콘텐츠 전송 속도를 50-500%까지 높일 수 있습니다. 광범위한 사용자가 있는 웹 또는 모바일 애플리케이션이 있거나 S3 버킷에서 멀리 떨어진 애플리케이션을 호스팅하는 고객은 인터넷을 통해 길고 가변적인 업로드 및 다운로드 속도를 경험할 수 있습니다. S3TA(S3 Transfer Acceleration)는 전송에 영향을 미칠 수 있는 인터넷 라우팅, 정체 및 속도의 가변성을 줄이고 원격 애플리케이션을 위해 S3까지의 거리를 논리적으로 단축합니다. S3TA는 Amazon CloudFront의 전 세계적으로 분산된 엣지 로케이션과 AWS 백본 네트워크를 통해 트래픽을 라우팅하고 네트워크 프로토콜 최적화를 사용하여 전송 성능을 향상시킵니다. S3 콘솔에서 몇 번의 클릭으로 S3TA를 켜고 위치에서 이점을 테스트할 수 있습니다. S3TA를 사용하면 가속화된 전송에 대해서만 비용을 지불합니다.

회사는 온프레미스 워크로드를 AWS로 마이그레이션할 계획입니다. 현재 아키텍처는 Windows 공유 파일 저장소를 사용하는 Microsoft SharePoint 서버로 구성됩니다. Solutions Architect는 가용성이 높고 액세스 제어 및 인증을 위해 Active Directory와 통합될 수 있는 클라우드 스토리지 솔루션을 사용해야 합니다.

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

Amazon FSx for Windows File Server를 사용하여 파일 시스템을 생성하고 AWS의 Active Directory 도메인에 조인합니다.

Amazon FSx for Windows File Server는 업계 표준 SMB(서비스 메시지 블록) 프로토콜을 통해 액세스할 수 있는 매우 안정적이고 확장 가능한 완전 관리형 파일 스토리지를 제공합니다. Windows Server에 구축되어 사용자 할당량, 최종 사용자 파일 복원 및 Microsoft Active Directory(AD) 통합과 같은 광범위한 관리 기능을 제공합니다.

Amazon FSx 는 Microsoft Active Directory (AD) 와 연동하여 기존 Microsoft Windows 환경과 통합합니다. Active Directory는 네트워크에 개체에 대한 정보를 저장하고 관리자와 사용자가 이 정보를 쉽게 찾고 사용할 수 있도록 하는 데 사용되는 Microsoft 디렉터리 서비스입니다. 이러한 개체에는 일반적으로 파일 서버, 네트워크 사용자 및 컴퓨터 계정과 같은 공유 리소스가 포함됩니다.

Amazon FSx를 사용하여 파일 시스템을 생성할 때 이를 Active Directory 도메인에 가입하여 사용자 인증 및 파일 및 폴더 수준 액세스 제어를 제공합니다. 그런 다음 사용자는 Active Directory의 기존 사용자 ID를 사용하여 자신을 인증하고 Amazon FSx 파일 시스템에 액세스할 수 있습니다. 사용자는 기존 ID를 사용하여 개별 파일 및 폴더에 대한 액세스를 제어할 수도 있습니다. 또한 수정 없이 기존 파일 및 폴더 및 이러한 항목의 ACL (보안 액세스 제어 목록) 구성을 Amazon FSx로 마이그레이션할 수 있습니다.

학교는 EC2 인스턴스에서 애플리케이션을 관리합니다. EC2 인스턴스가 시작되면 애플리케이션이 작동하는 데 필요한 모든 소프트웨어 라이브러리에 대한 메모리 공간을 구축하는 데 오랜 시간이 걸립니다. 학교는 필요할 때 즉시 분석을 시작할 수 있도록 인스턴스를 미리 예열된 상태로 유지하려고 합니다.

다음 중 어떤 솔루션을 추천하시겠습니까?

EC2 최대 절전 모드 사용

인스턴스를 최대 절전 모드로 전환하면 Amazon EC2에서 최대 절전 모드(디스크 일시 중단)를 수행하도록 운영 체제에 신호를 보냅니다. 최대 절전 모드는 인스턴스 메모리(RAM)의 내용을 Amazon Elastic Block Store(Amazon EBS) 루트 볼륨에 저장합니다. Amazon EC2는 인스턴스의 EBS 루트 볼륨과 연결된 모든 EBS 데이터 볼륨을 유지합니다. 인스턴스를 시작할 때:

- EBS 루트 볼륨이 이전 상태로 복원됩니다

- RAM 내용이 다시 로드됩니다

- 이전에 인스턴스에서 실행되었던 프로세스가 재개됩니다.

- 이전에 연결된 데이터 볼륨이 다시 연결되고, 인스턴스는 해당 인스턴스 ID를 유지합니다.

인스턴스에 대해 최대 절전 모드가 활성화되어 있고 최대 절전 모드 사전 조건을 충족하는 경우 인스턴스를 최대 절전 모드로 전환할 수 있습니다.

회사에 Fargate 시작 유형을 사용하여 Amazon ECS 클러스터에서 호스팅되는 OLTP(온라인 트랜잭션 처리) 애플리케이션이 있습니다. 프로덕션 웹 사이트의 데이터를 저장하는 Amazon RDS 데이터베이스가 있습니다. 데이터 분석팀은 모든 사용자 트랜잭션을 추적하고 감사하기 위해 데이터베이스에 대해 쿼리를 실행해야 합니다. 프로덕션 데이터베이스에 대한 이러한 쿼리 작업은 어떤 식으로든 애플리케이션 성능에 영향을 주어서는 안 됩니다.

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

프로덕션 데이터베이스의 새 Amazon RDS 읽기 전용 복제본을 설정합니다. 데이터 분석팀이 복제본에서 프로덕션 데이터를 쿼리하도록 지시합니다.

Amazon RDS 읽기 전용 복제본은 Amazon RDS 데이터베이스(DB) 인스턴스의 성능과 내구성을 높여줍니다. 읽기 전용 복제본을 사용하면 손쉽게 단일 DB 인스턴스의 용량 한도 이상으로 탄력적으로 스케일 아웃하여 읽기 중심의 데이터베이스 워크로드를 처리할 수 있습니다. 특정 소스 DB 인스턴스의 복제본을 여러 개 만들어 여러 데이터 사본이 요청하는 높은 애플리케이션 읽기 트래픽도 처리할 수 있습니다. 덕분에 전체 읽기 처리량이 향상됩니다. 필요한 경우 읽기 전용 복제본은 독립 실행형 DB 인스턴스로 승격될 수 있습니다. 읽기 전용 복제본은 Amazon RDS for MySQL, MariaDB, PostgreSQL, Oracle 및 SQL Server뿐만 아니라 Amazon Aurora에서도 사용할 수 있습니다.

MySQL, MariaDB, PostgreSQL, Oracle 및 SQL Server 데이터베이스 엔진의 경우, Amazon RDS에서 소스 DB 인스턴스의 스냅샷을 사용해 두 번째 DB 인스턴스를 생성합니다. 그런 다음 엔진의 기본 비동기식 복제 기능을 사용해 소스 DB 인스턴스가 변경될 때마다 읽기 전용 복제본을 업데이트합니다. 읽기 전용 복제본은 읽기 전용 연결만 가능한 DB 인스턴스 역할을 수행합니다. 애플리케이션을 읽기 전용 복제본에 연결하는 방법은 DB 인스턴스에 연결하는 방법과 동일합니다. Amazon RDS는 원본 DB 인스턴스의 모든 데이터베이스를 복제합니다.

애플리케이션에서 읽기 전용 복제본으로 읽기 쿼리를 라우팅하여 원본 DB 인스턴스의 로드를 줄일 수 있습니다. 읽기 전용 복제본을 사용하면 단일 DB 인스턴스 용량의 한도 이상으로 탄력적으로 스케일 아웃할 수 있어 읽기 중심의 데이터베이스 워크로드를 쉽게 처리할 수 있습니다. 읽기 전용 복제본이 기본 상태로 승격될 수 있으므로 샤딩 구현의 일부로 사용하기에 유용합니다.

회사는 최근 AWS 리소스의 보안을 개선하기 위한 정책을 시작했으며 회사가 소유한 여러 AWS 계정에서 AWS Shield Advanced를 활성화했습니다. 분석 결과 회사는 발생한 비용이 예상보다 훨씬 높다는 것을 발견했습니다.

다음 중 AWS Shield Advanced 서비스에 대한 예상치 못한 높은 비용의 근본적인 이유는 무엇입니까?

통합 결제가 활성화되지 않았습니다. 모든 AWS 계정은 월별 요금이 한 번만 청구되는 단일 통합 결제에 속해야 합니다.

AWS Shield Advanced는 보호 대상인 Amazon EC2, Elastic Load Balancing(ELB), Amazon CloudFront, AWS Global Accelerator 및 Route 53에서 실행되는 애플리케이션을 목표로 하는 더 정교하고 더 큰 규모의 공격에 대해 강화된 보호를 제공합니다. AWS Shield Advanced 보호는 네트워크 트래픽에 대한 상시 작동, 흐름 기반 모니터링과 적극적인 애플리케이션 모니터링을 통해 의심되는 DDoS 공격에 대한 거의 실시간 알림을 제공합니다. 또한 AWS Shield Advanced는 공격을 자동으로 완화하기 위해 첨단 공격 완화 및 라우팅 기법을 적용합니다. Business 또는 Enterprise 지원 고객은 연중무휴 24시간 Shield Response Team(SRT)과 협력하여 애플리케이션 계층 DDoS 공격을 관리 및 완화할 수 있습니다. 확장에 대한 DDoS 비용 보호 기능은 DDoS 공격으로 인해 보호 대상인 Amazon EC2, Elastic Load Balancing(ELB), Amazon CloudFront, AWS Global Accelerator 및 Amazon Route 53의 사용량이 급증하면서 발생한 요금으로부터 고객의 AWS 청구서를 보호합니다.

조직에서 여러 AWS 계정을 보유하고 있는 경우, AWS 관리 콘솔 또는 API를 사용하여 계정별로 AWS Shield Advanced를 사용하면 여러 AWS 계정을 구독할 수 있습니다. 모든 AWS 계정이 단일 통합 결제 계정에 포함되어 있고 모든 AWS 계정과 해당 계정의 모든 리소스를 소유한 경우에는 월별 요금을 한 번만 지불하면 됩니다.

AWS에서 클라우드 아키텍처를 설계하기 위해 DevOps 엔지니어가 채용되었습니다. 엔지니어는 Elastic Load Balancer와 여러 가용 영역에 배포된 EC2 인스턴스의 Auto Scaling 그룹으로 구성된 고가용성 내결함성 아키텍처를 개발할 계획입니다. 이것은 경로 기반 라우팅, 호스트 기반 라우팅 및 원격 프로시저 호출(gRPC)을 사용한 양방향 스트리밍이 필요한 온라인 계정 응용 프로그램에서 사용됩니다.

어떤 구성이 주어진 요구 사항을 충족합니까?

Auto-scaling 그룹 앞에 Application Load Balancer를 구성합니다. 프로토콜 버전으로 gRPC를 선택합니다.

Elastic Load Balancing(ELB)은 하나 이상의 가용 영역(AZ)에 있는 여러 대상 및 가상 어플라이언스에서 들어오는 애플리케이션 트래픽을 자동으로 분산합니다.

Elastic Load Balancing(ELB)은 4가지 유형의 로드 밸런서를 지원합니다. 애플리케이션 요구 사항에 따라 적절한 로드 밸런서를 선택할 수 있습니다. HTTP 요청을 로드 밸런싱해야 하는 경우 Application Load Balancer(ALB)를 사용하는 것이 좋습니다. 네트워크/전송 프로토콜(4계층 - TCP, UDP) 로드 밸런싱의 경우와 고도의 성능이 요구되거나 대기 시간이 낮아야 하는 애플리케이션의 경우에는 네트워크 로드 밸런서를 사용하는 것이 좋습니다. 애플리케이션이 Amazon Elastic Compute Cloud(Amazon EC2) Classic 네트워크 안에 구축된 경우 Classic Load Balancer를 사용해야 합니다. 서드 파티 가상 어플라이언스를 배포하고 실행해야 하는 경우 Gateway Load Balancer를 사용할 수 있습니다.

뛰어난 효율성과 다양한 프로그래밍 언어 지원 덕분에 gRPC는 마이크로서비스 통합 및 클라이언트-서버 통신에 널리 사용되는 옵션입니다. gRPC는 고성능 원격 프로시저 호출(RPC) 프레임워크로, 전송을 위한 HTTP/2 및 프로토콜 버퍼를 사용하여 인터페이스를 기술합니다.

애플리케이션에서 gRPC를 보다 쉽게 사용할 수 있도록 Application Load Balancer(ALB)는 HTTP/2 엔드 투 엔드를 지원하므로 단일 로드 밸런서를 통해 gRPC 서비스는 물론, gRPC 외 서비스도 함께 게시할 수 있습니다. 대상 그룹에 대한 gRPC 상태 검사 지원을 통해 Amazon Elastic Compute Cloud(EC2) 인스턴스 또는 IP 주소(예: AWS Fargate)를 gRPC 대상으로 사용할 수 있습니다. 이러한 방식으로 ALB를 사용하여 마이크로서비스 사이 또는 gRPC 지원 클라이언트와 서비스 사이에서 gRPC 트래픽을 종료 및 라우팅하고 로드 밸런싱할 수 있습니다.

ALB는 gRPC 호출을 검사하고 적절한 서비스로 라우팅하는 풍부한 콘텐츠 기반 라우팅 기능을 제공합니다. 특히, ALB는 gRPC 상태 코드, gRPC 요청 수에 대한 지표, gRPC 요청을 구분하는 액세스 로그 및 gRPC 특정 응답 헤더를 검사할 수 있는 상태 검사를 제공합니다. 또한 고정성, 다양한 로드 밸런싱 알고리즘 및 TLS 종료와 같은 기본 기능을 활용할 수도 있습니다.

DevOps 엔지니어가 EBS 볼륨 종료에 대한 기본 구성을 변경하려고 합니다. 기본적으로 EBS 지원 AMI에 대한 EC2 인스턴스의 루트 볼륨은 인스턴스가 종료될 때 삭제됩니다.

다음 중 인스턴스가 종료된 후에도 볼륨이 유지되도록 이 기본 동작을 변경하는 데 도움이 되는 옵션은 무엇입니까?

DeleteOnTermination 속성을 false로 설정

EC2 인스턴스는 인스턴스 스토어 지원 AMI 또는 Amazon EBS 지원 AMI에서 시작할 수 있습니다. 루트 디바이스에 Amazon EBS를 사용하는 인스턴스에는 Amazon EBS 볼륨이 자동으로 연결됩니다.

기본적으로 Amazon EBS에서 지원하는 AMI의 루트 볼륨은 인스턴스 종료 시 삭제됩니다. 인스턴스가 종료된 후에도 볼륨이 지속되도록 기본 동작을 변경할 수 있습니다. 기본 동작을 변경하려면 블록 디바이스 매핑을 사용하여 DeleteOnTermination 속성을 false로 설정합니다.

회사는 전 세계의 사용자에게 미디어 파일을 배포하는 파트너와 정적 콘텐츠를 공유합니다. 이 회사는 서버 비용을 줄이고 낮은 대기 시간으로 전 세계 고객에게 데이터를 안전하게 전달할 수 있는 방법을 찾고 있습니다.

가장 적합하고 비용 효율적인 아키텍처를 제공하려면 어떤 서비스 조합을 사용해야 합니까? (2개 선택)

Amazon CloudFront

Amazon S3

Amazon CloudFront는 개발자 친화적인 환경 내에서 짧은 지연 시간, 높은 전송 속도로 전 세계 고객에게 데이터, 비디오, 애플리케이션 및 API를 안전하게 제공하는 빠른 CDN(콘텐츠 전송 네트워크) 서비스입니다.

CloudFront는 AWS 글로벌 인프라 및 기타 AWS 서비스에 직접 연결된 물리적 위치인 AWS와 통합됩니다. CloudFront는 DDoS 완화를 위한 AWS Shield, 애플리케이션의 오리진인 Amazon S3, Elastic Load Balancing 또는 Amazon EC2, 고객 사용자와 더 가까운 곳에서 사용자 지정 코드를 실행하고 사용자 경험을 사용자 지정하기 위한 Lambda@Edge 등의 서비스와 원활하게 작동합니다. 마지막으로 Amazon S3, Amazon EC2 또는 Elastic Load Balancing과 같은 AWS 오리진을 사용하는 경우 이러한 서비스와 CloudFront 간에 전송되는 데이터에 대해 비용을 지불하지 않습니다.

Amazon S3는 인터넷 어디에서나 원하는 양의 데이터를 저장하고 검색하도록 구축된 객체 스토리지입니다. 매우 낮은 비용으로 내구성, 고가용성, 무한 확장성 데이터 스토리지 인프라를 제공하는 간단한 스토리지 서비스입니다.

사용자가 CloudFront와 함께 제공하는 콘텐츠를 요청하면 요청이 가까운 엣지 로케이션으로 라우팅됩니다. CloudFront에 요청된 파일의 캐시된 복사본이 있는 경우 CloudFront는 이를 사용자에게 전달하여 빠른(낮은 지연 시간) 응답을 제공합니다. 요청한 파일이 아직 캐시되지 않은 경우 CloudFront는 오리진(예: 콘텐츠를 저장한 S3 버킷)에서 파일을 검색합니다. 그런 다음 동일한 콘텐츠에 대한 다음 로컬 요청에 대해 이미 근처에 캐시되어 있으며 즉시 제공할 수 있습니다.

엣지 로케이션에서 콘텐츠를 캐싱함으로써 CloudFront는 S3 버킷의 부하를 줄이고 사용자가 콘텐츠를 요청할 때 더 빠른 응답을 보장합니다. 또한 CloudFront를 사용하여 콘텐츠로 데이터를 전송하는 것이 종종 S3에서 직접 파일을 제공하는 것보다 비용 효율적이며 S3에서 CloudFront로의 데이터 전송 요금이 없습니다. CloudFront에서 인터넷으로 제공되는 요금과 요청 요금만 지불하면 됩니다.

회사는 Amazon EC2 인스턴스의 Auto Scaling 그룹에서 사용자 지정 애플리케이션을 실행하고 있습니다. 그런데 스왑 공간이 부족하여 여러 인스턴스가 실패하고 있습니다. Solutions Architect는 문제를 해결하고 각 EC2 인스턴스의 사용 가능한 스왑 공간을 효과적으로 모니터링하라는 지시를 받았습니다.

다음 중 이 요구 사항을 충족하는 옵션은 무엇입니까?

각 인스턴스에 CloudWatch 에이전트를 설치하고 SwapUtilization 지표를 모니터링합니다.

Amazon CloudWatch는 AWS 클라우드 리소스와 AWS에서 실행되는 애플리케이션을 위한 모니터링 서비스입니다. Amazon CloudWatch를 사용하여 지표를 수집 및 추적하고 로그 파일을 수집 및 모니터링하고 경보를 설정할 수 있습니다. Amazon CloudWatch는 Amazon EC2 인스턴스, Amazon DynamoDB 테이블, Amazon RDS DB 인스턴스 같은 AWS 리소스뿐만 아니라 애플리케이션과 서비스에서 생성된 사용자 정의 지표 및 애플리케이션에서 생성된 모든 로그 파일을 모니터링할 수 있습니다. Amazon CloudWatch를 사용하여 시스템 전반의 리소스 사용률, 애플리케이션 성능, 운영 상태를 파악할 수 있습니다. 이러한 분석 정보를 사용하여 문제에 적절히 대응하고 애플리케이션 실행을 원활하게 유지할 수 있습니다.

CloudWatch 에이전트를 사용하여 Amazon EC2 인스턴스 및 온프레미스 서버에서 시스템 지표 및 로그 파일을 수집할 수 있습니다. 이 에이전트는 Windows Server와 Linux를 모두 지원하며 CPU당 코어와 같은 하위 리소스 지표를 포함하여 수집할 지표를 선택할 수 있습니다. 더 이상 사용되지 않는 모니터링 스크립트를 사용하는 대신 에이전트를 사용하여 지표와 로그를 수집하는 것이 좋습니다.

시나리오의 주요 요구 사항은 SwapUtilization 지표를 모니터링하는 것입니다. CloudWatch의 기본 지표를 사용하여 SwapUtilization 지표를 모니터링할 수 없습니다. 사용자 지정 지표를 모니터링하려면 EC2 인스턴스에 CloudWatch 에이전트를 설치해야 합니다. CloudWatch 에이전트를 설치한 후 이제 EC2 인스턴스의 시스템 지표 및 로그 파일을 수집할 수 있습니다.

관리자는 데이터 웨어하우스에 Redshift Cluster를 사용하는 온라인 분석 애플리케이션을 설계해야 합니다.

다음 서비스 중 Redshift 인스턴스의 모든 API 호출을 모니터링하고 감사 및 규정 준수 목적으로 보안 데이터를 제공할 수 있는 서비스는 무엇입니까?

AWS CloudTrail

AWS CloudTrail은 AWS 계정의 운영 및 위험 감사, 거버넌스 및 규정 준수를 활성화하는 데 도움이 되는 AWS 서비스입니다. 사용자, 역할 또는 AWS 서비스가 수행하는 작업은 CloudTrail에 이벤트로 기록됩니다. 이벤트에는 AWS Management Console, AWS Command Line Interface 및 AWS SDK, API에서 수행되는 작업들이 포함됩니다.

CloudTrail을 계정 생성 시 AWS 계정에서 사용할 수 있습니다. 활동이 AWS 계정에서 이루어지면 해당 활동이 CloudTrail 이벤트에 기록됩니다. 이벤트 기록으로 이동해서 CloudTrail 콘솔에서 손쉽게 최신 이벤트를 확인할 수 있습니다.

AWS 계정 활동에 대한 가시성은 보안 및 운영 모범 사례에서 중요한 측면입니다. CloudTrail을 사용하여 AWS 인프라 전반에서 계정 활동을 확인, 검색, 다운로드, 보관 및 응답할 수 있습니다. 누가 또는 무엇이 어떤 작업을 수행했는지, 어떤 리소스에 대해 조치가 취해졌는지, 언제 이벤트가 발생했는지, AWS 계정에서 활동 분석 및 응답에 도움이 되는 기타 세부 정보를 식별할 수 있습니다. 선택적으로 추적에서 AWS CloudTrail Insights를 활성화하여 비정상적인 활동을 식별하고 이에 대응할 수 있습니다.

API를 사용해 CloudTrail을 애플리케이션에 통합시킴으로써 조직에 대한 추적 생성을 자동화하고 생성한 추적 상태를 확인하며 사용자가 CloudTrail 이벤트를 확인하는 방법을 제어할 수 있습니다.

회사에서는 AWS Fargate 서버리스 컴퓨팅 엔진 및 Amazon Aurora와 함께 Amazon ECS 클러스터를 사용하여 온라인 플랫폼을 출시하려고 합니다. 앞으로 몇 주 동안 데이터베이스 읽기 쿼리가 크게 증가할 것으로 예상됩니다. Solutions Architect는 플랫폼의 확장성을 향상시키기 위해 데이터베이스 클러스터에 두 개의 읽기 전용 복제본을 두었습니다.

다음 중 Architect가 들어오는 모든 읽기 요청을 두 개의 읽기 전용 복제본에 균등하게 로드 밸런싱하기 위해 구현해야 하는 가장 적합한 구성은 무엇입니까?

Amazon Aurora 데이터베이스의 내장 리더 엔드포인트를 사용합니다.

Amazon Aurora(Aurora)는 MySQL 및 PostgreSQL과 호환되는 완전 관리형 관계형 데이터베이스 엔진입니다. MySQL 및 PostgreSQL이 이 고급 상용 데이터베이스의 속도와 안정성을 오픈 소스 데이터베이스의 단순성 및 비용 효율성과 어떻게 결합하는지 이미 알고 계실 것입니다. 오늘날 기존 MySQL 및 PostgreSQL 데이터베이스에 사용되는 코드, 도구 및 애플리케이션 모두 Aurora에서도 사용할 수 있습니다. 일부 워크로드의 경우 Aurora은 기존 애플리케이션을 거의 변경하지 않고도 MySQL의 처리량을 최대 5배, PostgreSQL의 처리량을 최대 3배 제공할 수 있습니다.

Aurora에는 고성능 스토리지 하위시스템이 포함됩니다. MySQL 및 PostgreSQL과 호환되는 데이터베이스 엔진은 빠른 분산형 스토리지를 활용하도록 사용자 지정됩니다. 기본 스토리지는 필요에 따라 자동으로 커집니다. Aurora 클러스터 볼륨 크기는 최대 128 tebibytes (TiB)까지 증가할 수 있습니다. Aurora는 또한 데이터베이스 구성 및 관리의 가장 어려운 측면 중 하나인 데이터베이스 클러스터링 및 복제를 자동화하고 표준화합니다.

Amazon Aurora는 일반적으로 단일 인스턴스 대신에 DB 인스턴스 클러스터와 관련됩니다. 각 연결은 특정 DB 인스턴스에서 처리합니다. Aurora 클러스터에 연결하면 지정한 호스트 이름과 포트가 엔드포인트라는 중간 핸들러를 가리킵니다. Aurora는 엔드포인트 메커니즘을 사용하여 이러한 연결을 추상화합니다. 따라서 일부 DB 인스턴스를 사용할 수 없을 때 모든 호스트 이름을 하드코딩하거나, 연결을 다시 라우팅하고 로드 밸런싱하기 위해 자체 로직을 작성할 필요가 없습니다.

특정 Aurora 작업의 경우 다른 인스턴스 또는 인스턴스 그룹이 다른 역할을 수행합니다. 예를 들어 기본 인스턴스는 모든 데이터 정의 언어(DDL) 및 데이터 조작 언어(DML) 문을 처리합니다. 최대 15개의 Aurora 복제본이 읽기 전용 쿼리 트래픽을 처리합니다.

엔드포인트를 사용하여 사용 사례에 따라 각 연결을 해당 인스턴스 또는 인스턴스 그룹에 매핑할 수 있습니다. 예를 들어 DDL 문을 수행하려면 기본 인스턴스인 어떤 인스턴스에나 연결하면 됩니다. 쿼리를 수행하려면 리더 엔드포인트에 연결하면 되며, Aurora가 모든 Aurora 복제본 간에 로드 밸런싱을 자동으로 수행합니다. 다른 용량 또는 구성의 DB 인스턴스가 있는 클러스터의 경우, DB 인스턴스의 다른 하위 집합과 연결된 사용자 지정 엔드포인트에 연결할 수 있습니다. 진단 또는 튜닝의 경우 특정 인스턴스 엔드포인트에 연결하여 특정 DB 인스턴스에 대한 세부 정보를 검토할 수 있습니다.

Aurora 엔드포인트 유형

엔드포인트는 호스트 주소와 포트를 포함하는 Aurora별 URL로 표시됩니다. Aurora DB 클러스터에서 제공하는 엔드포인트 유형은 다음과 같습니다.

클러스터 엔드포인트

Aurora DB 클러스터의 클러스터 엔드포인트(또는 라이터 엔드포인트)는 해당 DB 클러스터의 현재 기본 DB 인스턴스에 연결됩니다. 이 엔드포인트는 DDL 문 등의 쓰기 작업을 수행할 수 있는 유일한 엔드포인트입니다. 이 때문에 클러스터 엔드포인트는 클러스터를 처음 설정하거나 클러스터에 단일 DB 인스턴스만 포함된 경우에 연결하는 엔드포인트입니다.

리더 엔드포인트

Aurora DB 클러스터의 리더 엔드포인트는 DB 클러스터에 대한 읽기 전용 연결 시 로드 밸런싱을 지원합니다. 쿼리와 같은 읽기 작업에 리더 엔드포인트를 사용합니다. 이 엔드포인트는 읽기 전용 Aurora 복제본에서 이러한 문을 처리하여 기본 인스턴스에 대한 오버헤드를 줄입니다. 또한 클러스터가 클러스터의 Aurora 복제본 수에 비례하여 동시에 SELECT 쿼리를 처리할 수 있도록 용량을 확장할 수 있습니다. 각 Aurora DB 클러스터에는 리더 엔드포인트가 1개씩 있습니다.

클러스터에 하나 이상의 Aurora 복제본이 포함된 경우 리더 엔드포인트는 Aurora 복제본 사이의 각 연결 요청을 로드 밸런싱합니다. 이 경우 해당 세션의 SELECT과 같은 읽기 전용 문만 실행할 수 있습니다. 클러스터에 기본 인스턴스만 있고 Aurora 복제본이 없는 경우 리더 엔드포인트는 기본 인스턴스에 연결합니다. 이 경우 엔드포인트를 통해 쓰기 작업을 수행할 수 있습니다.

사용자 지정 엔드포인트

Aurora 클러스터의 사용자 지정 엔드포인트는 선택한 DB 인스턴스 집합을 나타냅니다. 엔드포인트에 연결하면 Aurora가 로드 밸런싱을 수행하고 그룹에서 연결을 처리할 인스턴스 중 하나를 선택합니다. 이 엔드포인트가 참조하는 인스턴스를 정의하고, 이 엔드포인트가 어떤 목적으로 사용되는지 결정합니다.

인스턴스 엔드포인트

인스턴스 엔드포인트는 Aurora 클러스터에 있는 특정 DB 인스턴스에 연결됩니다. DB 클러스터의 DB 인스턴스에는 각각 고유한 인스턴스 엔드포인트가 있습니다. 그러므로 DB 클러스터의 현재 기본 DB 인스턴스에 대해 인스턴스 엔드포인트 하나가 있고, DB 클러스터의 각 Aurora 복제본마다 인스턴스 엔드포인트 하나가 있습니다.

애플리케이션은 간단한 SQL 표현식을 사용하여 Amazon S3 버킷에 저장된 대용량 CSV 파일에서 데이터의 하위 집합을 검색해야 합니다. 쿼리는 Amazon S3 내에서 이루어지며 필요한 데이터만 반환해야 합니다.

다음 중 어떤 조치를 취해야 합니까?

버킷의 이름과 객체의 키를 기반으로 S3 Select 작업을 수행합니다.

다.

Amazon S3는 아래와 같이 버킷, 객체 키, 객체 메타데이터, 객체 태그 및 기타 여러 구성 요소로 구성됩니다.

키

객체에 할당한 이름입니다. 객체 키를 사용하여 객체를 검색합니다.

버전 ID

버킷 내에서 키와 버전 ID를 사용하여 각 객체를 고유하게 식별할 수 있습니다. 버전 ID는 버킷에 객체를 추가할 때 Amazon S3가 생성하는 문자열입니다.

값

저장하는 콘텐츠입니다.

객체 값은 임의의 바이트 시퀀스입니다. 객체 크기는 0TB 이상 5TB까지 가능합니다.

Metadata

객체 관련 정보를 저장하기 위한 이름-값 페어의 세트입니다. Amazon S3의 객체에 사용자 정의 메타데이터라고 하는 메타데이터를 지정할 수 있습니다. 또한 Amazon S3는 이러한 객체의 관리에 사용되는 시스템 메타데이터를 객체에 지정합니다.

하위 리소스

Amazon S3는 하위 리소스 메커니즘을 사용하여 객체 관련 추가 정보를 저장합니다. 하위 리소스는 객체에 종속되므로 항상 객체, 버킷 등의 다른 항목과 연결됩니다.

액세스 제어 정보

Amazon S3에 저장하는 객체에 대한 액세스를 제어할 수 있습니다. Amazon S3는 ACL(액세스 제어 목록), 버킷 정책 등의 리소스 기반 액세스 제어와 사용자 기반 액세스 제어를 모두 지원합니다.

Amazon S3 버킷 이름은 전역적으로 고유하며 네임스페이스는 모든 AWS 계정에서 공유됩니다.

Amazon S3 객체 태그는 스토리지를 분류하기 위해 객체 태깅에 사용되는 키 페어 값입니다.

S3 Select를 수행하여 버킷 이름과 객체 키를 기반으로 CSV 파일 내에서 필요한 데이터만 쿼리할 수 있습니다.

은행은 기업 고객을 위한 온프레미스 데이터 센터에서 매일 밤 10시부터 오전 3시까지 발생액, 대출 이자 및 기타 중요한 재무 계산의 꾸준한 워크로드를 정기적으로 처리하고 있습니다. 프로세스가 완료되면 결과가 Oracle General Ledger에 업로드되므로 처리가 지연되거나 중단되지 않아야 합니다. CTO는 비용 절감을 위해 IT 인프라를 AWS로 이전하기로 결정했습니다. 회사는 워크로드를 제대로 실행하기 위해 특정 가용 영역에서 컴퓨팅 용량을 예약해야 합니다.

재무 시스템을 위해 AWS에서 비용 효율적인 아키텍처를 구현하려면 어떻게 해야 합니까?

지정된 반복 일정에 항상 사용 가능한 컴퓨팅 용량을 제공하는 온디맨드 용량 예약을 사용합니다.

온디맨드 용량 예약을 사용하면 특정 가용 영역의 Amazon EC2 인스턴스에 대해 원하는 기간만큼 컴퓨팅 용량을 예약할 수 있습니다. 따라서 Savings Plans 또는 리전 예약 인스턴스에서 제공하는 결제 할인과는 별도로 용량 예약를 생성 및 관리할 수 있습니다.

용량 예약를 생성하면 필요할 때 언제든지 필요한 만큼 EC2 용량에 액세스할 수 있으며 유지할 수 있습니다. 1년 또는 3년 기간의 약정에 가입하지 않고도 언제든지 용량 예약을 생성할 수 있습니다. 용량을 사용할 수 있게 되며 계정에서 용량 예약이 프로비저닝되는 즉시 결제가 시작됩니다. 더는 필요하지 않은 경우 용량 예약을 취소하면 용량이 해제되고 요금 발생이 중지됩니다.

용량 예약을 생성할 때 다음을 지정합니다.

- 용량을 예약할 가용 영역입니다.

- 용량을 예약할 인스턴스 수입니다.

- 인스턴스 유형, 테넌시, platform/OS 등을 포함한 인스턴스 속성

용량 예약는 해당 속성과 일치하는 인스턴스에서만 사용할 수 있습니다. 기본적으로 속성과 일치하는 인스턴스를 실행하면 용량 예약이 자동으로 사용됩니다. 용량 예약의 속성과 일치하는 인스턴스를 실행하고 있지 않으면 속성과 일치하는 인스턴스를 시작할 때까지 사용되지 않은 상태로 유지됩니다.

또한 Savings Plan 및 리전 예약 인스턴스를 용량 예약와 함께 사용하여 청구 할인의 혜택을 누릴 수 있습니다. AWS는 용량 예약의 속성이 Savings Plan 또는 리전 예약 인스턴스의 속성과 일치하는 경우에 할인을 자동으로 적용합니다.

회사는 최근 AWS와 함께 하이브리드 클라우드 인프라를 채택했습니다. Solutions Architect의 작업 중 하나는 EC2 인스턴스와 데이터베이스 인스턴스에 대한 퍼블릭 서브넷과 프라이빗 서브넷이 모두 있는 VPC를 시작하는 것입니다.

다음 중 Amazon VPC 서브넷에 대한 설명으로 옳은 것은 무엇입니까? (2개 선택)

각 서브넷은 단일 가용 영역에 매핑됩니다.

생성하는 모든 서브넷은 VPC의 기본 라우팅 테이블과 자동으로 연결됩니다.

Amazon Virtual Private Cloud(Amazon VPC)를 이용하면 사용자가 정의한 가상 네트워크로 AWS 리소스를 시작할 수 있습니다. 이 가상 네트워크는 AWS의 확장 가능한 인프라를 사용한다는 이점과 함께 고객의 자체 데이터 센터에서 운영하는 기존 네트워크와 매우 유사합니다.

Virtual Private Cloud(VPC)는 사용자의 AWS 계정 전용 가상 네트워크입니다. VPC는 AWS 클라우드에서 다른 가상 네트워크와 논리적으로 분리되어 있습니다. VPC의 IP 주소 범위를 지정하고 서브넷과 게이트웨이를 추가하고 보안 그룹을 연결합니다.

서브넷은 VPC의 IP 주소 범위입니다. Amazon EC2 인스턴스와 같은 AWS 리소스를 서브넷으로 실행할 수 있습니다. 서브넷을 인터넷, 다른 VPC 및 자체 데이터 센터에 연결하고 라우팅 테이블을 사용하여 서브넷으로/서브넷에서 트래픽을 라우팅할 수 있습니다.

VPC는 리전의 모든 가용 영역에 걸쳐 있습니다. VPC를 생성한 후 각 가용 영역에 하나 이상의 서브넷을 추가할 수 있습니다. 서브넷을 생성할 때 VPC CIDR 블록의 하위 집합인 서브넷에 대한 CIDR 블록을 지정합니다. 각 서브넷은 완전히 하나의 가용 영역 내에 있어야 하며 여러 영역에 걸쳐 있을 수 없습니다. 가용 영역은 다른 가용 영역의 장애로부터 격리되도록 설계된 별개의 위치입니다. 별도의 가용 영역에서 인스턴스를 시작하여 단일 위치의 장애로부터 애플리케이션을 보호할 수 있습니다.

다음은 서브넷에 대해 기억해야 할 중요한 사항입니다.

- 각 서브넷은 단일 가용 영역에 매핑됩니다.

- 생성하는 모든 서브넷은 VPC의 기본 라우팅 테이블과 자동으로 연결됩니다.

- 서브넷의 트래픽이 인터넷 게이트웨이로 라우팅되는 경우 서브넷을 퍼블릭 서브넷이라고 합니다.

Solutions Architect는 SSH 연결을 통해 이 IP 주소(111.222.111.222)에서만 온디맨드 EC2 인스턴스에 액세스할 수 있는지 확인해야 합니다.

아래의 어떤 구성이 이 요구 사항을 충족합니까?

보안 그룹 인바운드 규칙: 프로토콜 – TCP. 포트 범위 – 22, 소스 111.222.111.222/32

보안 그룹은 EC2 인스턴스에 대한 수신 및 발신 트래픽을 제어하는 가상 방화벽 역할을 합니다. 인바운드 규칙은 인스턴스로 들어오는 트래픽을 제어하고 아웃바운드 규칙은 인스턴스에서 나가는 트래픽을 제어합니다. 인스턴스를 시작할 때 하나 이상의 보안 그룹을 지정할 수 있습니다. 보안 그룹을 지정하지 않을 경우 Amazon EC2에서 기본 보안 그룹이 사용됩니다. 연결된 인스턴스에서 트래픽을 주고 받을 수 있도록 하는 규칙을 각 보안 그룹에 추가할 수 있습니다. 언제든지 보안 그룹에 대한 규칙을 수정할 수 있습니다. 새 규칙 및 수정된 규칙은 보안 그룹에 연결된 모든 인스턴스에 자동으로 적용됩니다. Amazon EC2는 트래픽이 인스턴스에 도달하도록 허용할지 여부를 결정할 때 인스턴스와 연결된 모든 보안 그룹에서 모든 규칙을 평가합니다.

VPC에서 인스턴스를 시작할 때 최대 5개의 보안 그룹을 인스턴스에 할당할 수 있습니다. 보안 그룹은 서브넷 수준이 아니라 인스턴스 수준에서 작동합니다. 따라서 VPC의 서브넷에 있는 각 인스턴스를 서로 다른 보안 그룹 세트에 할당할 수 있습니다.

요구 사항은 전체 네트워크가 아닌 클라이언트의 개별 IP만 허용하는 것입니다. 따라서 적절한 CIDR 표기법을 사용해야 합니다. /32는 하나의 IP 주소를 나타내고 /0은 전체 네트워크를 나타냅니다. SSH 프로토콜은 TCP와 포트 22를 사용합니다.

한 전자 상거래 애플리케이션에 솔루션 아키텍트는 Amazon VPC의 모든 AWS 리소스가 각각의 서비스 한도를 초과하지 않도록 해야 합니다. 아키텍트는 AWS 모범 사례를 준수하는 리소스 프로비저닝에 대한 실시간 지침을 제공하는 시스템을 준비해야 합니다.

다음 중 이 작업을 충족하기 위해 사용하는 가장 적절한 서비스는 무엇입니까?

AWS Trusted Advisor

AWS Trusted Advisor는 지금까지 수많은 AWS 고객에게 제공된 AWS의 축적된 서비스 경험에서 얻은 유용한 모범 사례를 바탕으로 만들어진 애플리케이션입니다. Trusted Advisor는 사용자의 AWS 환경을 조사하고 비용 절감, 시스템 성능 향상 또는 보안 결함 제거를 위한 권장 사항을 제시합니다.

새로운 워크플로를 설정하거나, 애플리케이션을 개발하거나, 지속적인 개선의 일환으로 정기적으로 Trusted Advisor에서 제공하는 권장 사항을 활용하여 솔루션을 최적으로 프로비저닝할 수 있습니다.

Trusted Advisor에는 다음 5가지 범주에서 계속 확장되는 검사 목록이 포함되어 있습니다.

비용 최적화 – 사용되지 않는 유휴 리소스를 제거하거나 예약 용량을 약정하여 AWS에서 비용을 절약할 수 있는 방법을 확인합니다.

보안 – 결함을 없애고, 다양한 AWS 보안 기능을 사용하며, 권한을 점검하여 애플리케이션 보안을 개선합니다.

내결함성 – Auto Scaling, 상태 확인, 다중 AZ 및 백업 기능을 활용하여 AWS 애플리케이션의 가용성과 중복성을 높입니다.

성능 – 서비스 한도를 점검하고, 프로비저닝된 처리량을 활용하는지 확인하고, 과다 사용되는 인스턴스를 모니터링하여 서비스 성능을 개선합니다.

서비스 한도 – 서비스 한도의 80%가 넘는 서비스 사용량이 있는지 점검합니다. 값은 스냅샷을 기반으로 하므로 현재 사용량은 다를 수 있습니다. 한도 및 사용량에 변경 사항이 반영되는 데 최대 24시간이 걸릴 수 있습니다.

회사에서 Amazon RDS DB 인스턴스에 저장된 민감한 회계 데이터를 외부 감사자와 공유하려고 합니다. 감사자는 자체 AWS 계정을 갖고 있으며 자체 데이터베이스 사본이 필요합니다.

다음 중 감사자와 데이터베이스를 안전하게 공유하기 위해 권장하는 것은 무엇입니까?

데이터베이스의 암호화된 스냅샷을 생성하여 스냅샷을 공유하고, AWS Key Management Service(AWS KMS) 암호화 키에 대한 액세스를 허용합니다.

스냅샷에 액세스할 수 있도록 하려는 모든 계정과 스냅샷을 암호화하는 데 사용된 AWS Key Management Service(AWS KMS) 고객 마스터 키(CMK)를 공유할 수 있습니다. AWS KMS 키 정책에 다른 계정을 추가하여 AWS KMS CMK를 다른 AWS 계정과 공유할 수 있습니다.

데이터베이스의 암호화된 스냅샷을 만들면 주어진 사례에 필요한 대로 감사자에게 데이터베이스 사본이 제공됩니다.

Amazon RDS를 사용하면 다음 방법으로 수동 DB 스냅샷을 공유할 수 있습니다.

- 암호화되었거나 암호화되지 않은 수동 DB 스냅샷을 공유하면 권한이 있는 AWS 계정에서 해당 스냅샷을 복사할 수 있습니다.

- 암호화되지 않은 수동 DB 스냅샷을 공유하면 권한이 있는 AWS 계정에서 스냅샷의 복사본을 만든 후 복원하는 대신에 해당 스냅샷에서 DB 인스턴스를 직접 복원할 수 있습니다. 그러나 공유되고 동시에 암호화된 DB 스냅샷에서는 DB 인스턴스를 복원할 수 없습니다. 대신 DB 스냅샷의 사본을 만들어 거기에서 DB 인스턴스를 복원할 수 있습니다.

다른 AWS 계정이 사용자 계정에서 공유된 암호화된 DB 스냅샷을 복사하려면 스냅샷을 공유하는 계정에 스냅샷을 암호화한 AWS KMS key에 대한 액세스 권한이 있어야 합니다.

다른 AWS 계정 액세스를 KMS 키에 허용하려면 KMS 키의 키 정책을 업데이트합니다. KMS 키 정책에서 Principal(으)로 공유하고 있는 AWS 계정의 Amazon 리소스 이름(ARN)을 사용하여 업데이트합니다. 그런 다음 kms:CreateGrant 작업을 허용합니다.

AWS 계정에 사용자에게 KMS 키에 대한 액세스 권한을 부여한 후에 암호화된 스냅샷을 복사하려면 해당 AWS 계정에서 AWS Identity and Access Management (IAM) 역할 또는 사용자를 만들어야 합니다(아직 없는 경우). 또한 AWS 계정은 해당 IAM 역할 또는 사용자에게 KMS 키를 사용하여 암호화된 DB 스냅샷을 복사할 수 있도록 허용하는 IAM 정책도 연결해야 합니다. AWS KMS 보안 제약으로 인해 이 계정은 IAM 사용자여야 하며 루트 AWS 계정 자격 증명일 수 없습니다.

회사는 사람들이 암호화폐를 거래하고, 관리할 수 있는 온라인 플랫폼을 출시했습니다. 엄격한 IT 감사 요구 사항을 충족하려면 모든 AWS 리소스에 대한 각 API 호출을 적절하게 캡처하고 기록해야 합니다. VPC에서 CloudTrail을 사용하여 AWS 계정의 규정 준수, 운영 감사 및 위험 감사를 지원했습니다.

이 시나리오에서 CloudTrail은 생성하는 모든 로그를 어디에 저장합니까?

Amazon S3

AWS Cloudtrail은 사용자 활동 및 API 사용을 추적하여 감사, 보안 모니터링 및 운영 문제 해결을 지원합니다. CloudTrail은 AWS 인프라 전체에서 작업과 관련된 계정 활동을 로그하고 지속적으로 모니터링하고 보존하여 스토리지, 분석 및 해결 작업을 제어할 수 있도록 합니다.

CloudTrail은 규정 준수를 입증하고, 보안 태세를 개선하며, 리전 및 계정 전체의 활동 레코드를 통합하는 데 도움이 됩니다. CloudTrail은 사용자 계정에서 이루어진 작업을 기록함으로써 사용자 활동에 대한 가시성을 제공합니다. CloudTrail은 요청한 사람, 사용된 서비스, 수행된 작업, 작업의 파라미터, AWS 서비스에서 반환한 대응 요소를 비롯하여, 각 작업에 대한 중요 정보를 기록합니다. 이러한 정보는 AWS 리소스에 이루어진 변경 사항을 추적하고 운영 관련 문제를 해결하는 데 도움이 됩니다. CloudTrail은 내부 정책 및 규제 표준을 쉽게 준수하도록 해줍니다.

리전별 엔드포인트가 있는 서비스(EC2, RDS 등)에 대한 활동 정보는 작업이 이루어진 동일 리전에서 캡처되고 처리된 후, 사용자의 Amazon S3 버킷과 연결된 리전으로 전송됩니다. IAM and AWS Security Token Service(STS)와 같이 단일 엔드포인트가 있는 서비스에 대한 작업 정보는 엔드포인트가 위치한 리전에서 캡처되고, CloudTrail 추적이 구성된 리전에서 처리된 후, 사용자의 Amazon S3 버킷과 연결된 리전으로 전송됩니다.

전자 상거래 애플리케이션은 데이터베이스에 Amazon Aurora 다중 AZ 배포를 사용합니다. 성능 메트릭을 분석하는 동안 엔지니어링 팀은 데이터베이스 읽기가 높은 I/O를 유발하고 데이터베이스에 대한 쓰기 요청에 대기 시간을 추가한다는 것을 발견했습니다.

읽기 요청과 쓰기 요청을 분리하기 위해 무엇을 추천하시겠습니까?

읽기 전용 복제본을 설정하고 적절한 엔드포인트를 사용하도록 애플리케이션을 수정합니다.

Amazon Aurora DB cluster는 하나 이상의 DB 인스턴스와 이 DB 인스턴스의 데이터를 관리하는 클러스터 볼륨으로 구성됩니다. Aurora 클러스터 볼륨은 다중 가용 영역을 아우르는 가상 데이터베이스 스토리지 볼륨으로서, 각 가용 영역에는 DB 클러스터 데이터의 사본이 있습니다. Aurora DB 클러스터는 다음과 같이 두 가지 유형의 DB 인스턴스로 구성됩니다.

기본 DB 인스턴스 – 읽기 및 쓰기 작업을 지원하고, 클러스터 볼륨의 모든 데이터 수정을 실행합니다. Aurora DB 클러스터마다 기본 DB 인스턴스가 하나씩 있습니다.

Aurora 복제본 – 기본 DB 인스턴스와 동일한 스토리지 볼륨에 연결되며 읽기 작업만 지원합니다. 각 Aurora DB 클러스터는 기본 DB 인스턴스에 더해 최대 15개까지 Aurora 복제본을 구성할 수 있습니다. Aurora 복제본을 별도의 가용 영역에 배치하여 고가용성을 유지합니다. Aurora는 기본 DB 인스턴스를 사용할 수 없는 경우 자동으로 Aurora 복제본으로 장애 조치합니다. Aurora 복제본에 대해 장애 조치 우선 순위를 지정할 수 있습니다. 또한 Aurora 복제본은 기본 DB 인스턴스에서 읽기 워크로드를 오프로드할 수 있습니다.

Aurora 복제본에는 두 가지 주요 목적이 있습니다. 쿼리를 실행하여 애플리케이션에 대한 읽기 작업을 확장할 수 있습니다. 일반적으로 클러스터의 리더 엔드포인트에 연결하여 이를 수행합니다. 그런 식으로 Aurora는 클러스터에 있는 만큼의 Aurora 복제본에 읽기 전용 연결에 대한 로드를 분산할 수 있습니다. Aurora 복제본은 가용성을 높이는 데도 도움이 됩니다. 클러스터의 라이터 인스턴스를 사용할 수 없게 되면 Aurora는 리더 인스턴스 중 하나를 자동으로 승격하여 새 라이터 역할을 대신합니다.

Aurora에 대한 다중 AZ 배포를 설정하는 동안 다른 AZ에 Aurora replica 또는 reader node를 생성합니다.

Aurora 클러스터에 대한 읽기 전용 연결에 리더 엔드포인트를 사용합니다. 이 엔드포인트는 로드 밸런싱 메커니즘을 사용하여 클러스터가 쿼리 집약적인 워크로드를 처리하도록 돕습니다. 리더 엔드포인트는 클러스터에서 보고 또는 기타 읽기 전용 작업을 수행하는 애플리케이션에 제공하는 엔드포인트입니다. 리더 엔드포인트는 Aurora DB 클러스터에서 사용 가능한 Aurora 복제본에 대한 연결 로드 밸런싱을 수행합니다.

Solutions Architect는 AWS Lambda가 Asia Pacific(Seoul) 리전에서 buildupworks라는 Amazon DynamoDB 테이블에 액세스할 수 있도록 하는 서버리스 아키텍처를 설계했습니다. Lambda 함수에 연결된 IAM 정책은 테이블에 항목을 넣고 삭제할 수 있도록 허용합니다. buildupworks 테이블에서 두 가지 작업만 허용하고 다른 DynamoDB 테이블이 수정되지 않도록 정책을 업데이트해야 합니다.

다음 IAM 정책 중 이 요구 사항을 충족하고 최소 권한 부여 원칙을 따르는 것은 무엇입니까?

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "buildupworksTablePolicy",
"Effect": "Allow",
"Action": [
"dynamodb:PutItem",
"dynamodb:DeleteItem"
],
"Resource": "arn:aws:dynamodb:ap-northeast-2:120618981206:table/buildupworks"
}
]
}

모든 AWS 리소스는 AWS 계정이 소유하며 리소스를 생성하거나 액세스할 수 있는 권한은 권한 정책에 의해 관리됩니다. 계정 관리자는 권한 정책을 IAM 자격 증명(즉, 사용자, 그룹 및 역할)에 연결할 수 있으며, 일부 서비스(예: AWS Lambda)도 리소스에 대한 권한 정책 연결을 지원합니다.

DynamoDB에서 기본 리소스는 테이블입니다. DynamoDB는 추가 리소스 유형, 인덱스 및 스트림도 지원합니다. 그러나 기존 DynamoDB 테이블의 컨텍스트에서만 인덱스와 스트림을 생성할 수 있습니다. 이러한 리소스를 하위 리소스라고 합니다. 이러한 리소스 및 하위 리소스에는 고유한 Amazon 리소스 이름(ARN)이 연결되어 있습니다.

예를 들어 AWS 계정(123456789012)에는 Asia Pacific(Seoul)(ap-northeast-2) 리전에 Books라는 DynamoDB 테이블이 있습니다. Books 테이블의 ARN은 다음과 같습니다.

arn:aws:dynamodb:ap-northeast-2:123456789012:table/Books

정책은 자격 증명이나 리소스에 연결될 때 권한을 정의하는 엔터티입니다. IAM 정책과 역할을 사용하여 액세스를 제어함으로써 DynamoDB 테이블에 대한 액세스 권한을 Lambda 함수에 부여합니다

Lambda 함수를 사용하여 buildupworks라는 DynamoDB 테이블을 수정한다고 시나리오에 명시되어 있습니다. 하나의 테이블에만 액세스하면 되므로 IAM 정책의 리소스 요소에 해당 테이블을 표시해야 합니다. 또한 정책에서 생성될 효과 및 조치 요소를 지정해야 합니다.

음악 스트리밍 회사는 문서 모델을 저장할 키-값 저장소가 필요한 다중 계층 웹 응용 프로그램을 구축하고 있습니다. 각 모델은 밴드 ID, 앨범 ID, 곡 ID, 작곡가 ID, 가사 및 기타 데이터로 구성됩니다. 웹 계층은 AWS Fargate 시작 유형의 Amazon ECS 클러스터에서 호스팅됩니다.

다음 중 데이터베이스 계층에 가장 적합한 설정은 무엇입니까?

DynamoDB 테이블을 사용합니다.

DynamoDB는 모든 규모에서 빠르고 유연한 비관계형 데이터베이스입니다. DynamoDB를 통해 고객은 분산 데이터베이스를 운영하고 AWS로 확장하는 데 따른 관리 부담에서 벗어날 수 있으며, 하드웨어 프로비저닝, 설정 및 구성, 처리량 용량 계획, 복제, 소프트웨어 패치 또는 클러스터 확장에 대해서도 걱정할 필요가 없습니다.

DynamoDB에서는 사용자가 정의한 프라이머리 키를 사용하여 GET/PUT 작업을 지원합니다. 기본 키는 테이블 항목에 필요한 유일한 속성입니다. 사용자가 표를 생성할 때 기본 키를 명시하며, 이 기본 키가 각 항목을 고유하게 식별합니다. 또한, DynamoDB는 글로벌 보조 인덱스 및 로컬 보조 인덱스를 사용하여 기본이 아닌 키 속성을 쿼리할 수 있어 유연한 쿼리 기능을 이용할 수 있습니다.

프라이머리 키는 단일 속성 파티션 키 또는 복합 파티션-정렬 키 중 하나가 될 수 있습니다. 예를 들어 단일 속성 파티션 키는 UserID가 될 수 있습니다. 이러한 단일 속성 파티션 키를 사용하면 해당 사용자 ID와 관련된 항목의 데이터를 빠르게 읽고 쓸 수 있습니다.

DynamoDB는 복합 파티션-정렬 키를 파티션 키 요소 및 정렬 키 요소로 인덱싱합니다. 이 멀티-파트 키를 통해 첫 번째와 두 번째 요소 값 사이의 계층 구조가 유지됩니다. 예를 들어, 복합 파티션-정렬 키는 UserID(파티션)와 Timestamp(정렬)의 조합이 될 수 있습니다. 파티션 키 요소를 일정하게 유지함으로써 정렬 키 요소를 검색하여 항목을 찾을 수 있습니다. 예를 들어 Query API를 사용하여 일정 범위의 timestamp에 걸쳐 단일 UserID에 대한 모든 항목을 검색할 수 있습니다.

키-값 데이터베이스는 간단한 키-값 메소드를 사용하여 데이터를 저장하는 비관계형 데이터베이스 유형입니다. 키-값 데이터베이스는 키를 고유한 식별자로 사용하는 키-값 쌍의 집합으로 데이터를 저장합니다. 단순한 객체에서 복잡한 집합체에 이르기까지 무엇이든 키와 값이 될 수 있습니다. 키-값 데이터베이스는 파티셔닝이 가능하고 다른 유형의 데이터베이스로는 불가능한 범위까지 수평 확장을 가능하게 합니다. 기존 파티션의 용량이 차서 추가 저장 공간이 필요한 경우 Amazon DynamoDB는 테이블에 추가 파티션을 할당합니다.

다음 다이어그램은 DynamoDB에 키-값 쌍으로 저장된 데이터의 예를 보여줍니다.

회사는 AWS에서 호스팅되는 인기 있는 웹 애플리케이션을 보유하고 있습니다. 그들은 새로운 비즈니스를 위한 새로운 온라인 포털을 개발할 계획이며 새로운 온라인 포털을 위한 클라우드 아키텍처를 구현하고자 합니다. 그래서 최대 30,000IOPS를 지원할 수 있는 단일 EBS 볼륨이 필요한 단일 EC2 인스턴스에서 실행되는 관계형 데이터베이스로 시스템을 설계하기 시작했습니다.

이 시나리오에서 이 새로운 온라인 포털의 성능 요구 사항을 충족하기 위해 어떤 Amazon EBS 볼륨 유형을 사용할 수 있습니까?

EBS 프로비저닝된 IOPS SSD(io1)

Amazon EBS를 사용하면 스토리지 볼륨을 만들어 Amazon EC2 인스턴스에 연결할 수 있습니다. 볼륨을 연결한 후에는 해당 볼륨 위에 파일 시스템을 생성하거나, 데이터베이스를 실행하거나, 블록 스토리지를 사용하는 것과 같은 방식으로 사용할 수 있습니다. Amazon EBS 볼륨은 특정 가용 영역에 위치하며 여기에서 자동으로 복제되므로, 단일 구성 요소에 장애가 발생하더라도 안전하게 보호됩니다. 모든 EBS 볼륨 유형은 안정적인 스냅샷 기능을 제공하며 99.999%의 가용성을 제공하도록 설계되었습니다.

Amazon EBS는 워크로드에 대한 스토리지 성능과 비용을 최적화할 수 있는 다양한 옵션을 제공합니다. 이러한 옵션은 2개의 큰 카테고리로 나뉩니다. 데이터베이스 및 부트 볼륨과 같은 트랜잭션 워크로드를 위한 SSD 지원 스토리지(주로 IOPS가 성능을 좌우)와 MapReduce 및 로그 처리와 같은 처리량 집약적 워크로드를 위한 HDD 지원 스토리지(주로 초당 MB가 성능을 좌우)가 이에 해당합니다.

가장 뛰어난 성능을 자랑하는 io2 Block Express 볼륨은 클라우드에서 최초의 SAN을 지원합니다. Block Express는 고가의 온프레미스 SAN을 조달, 확장 및 유지 관리하는 수고와 비용을 들이지 않고도 가장 뛰어난 성능의 블록 스토리지를 제공하는 차세대 스토리지 서버 아키텍처입니다. Block Express에서 io2 볼륨을 실행하면 밀리초 이하의 대기 시간을 달성하고 최대 256,000 IOPS, 초당 4,000MB의 처리량 및 64TB의 용량을 지원하는 단일 io2 볼륨을 프로비저닝할 수 있습니다. 이 수치는 기존 io2 볼륨에 비해 성능, 처리량 및 용량 면에서 4배 더 높습니다. io2 Block Express 볼륨은 Oracle 데이터베이스, SAP HANA, Microsoft SQL Server, InterSystems 데이터베이스 및 SAS Analytics의 가장 크고 가장 I/O 집약적인 미션 크리티컬 배포에 적합합니다.

SSD 지원 볼륨은 대기 시간에 민감한 트랜잭션 워크로드를 위한 고성능의 프로비저닝된 IOPS SSD(io2와 io1)와 다양한 트랜잭션 데이터를 위해 가격과 성능의 균형을 맞춘 범용 SSD(gp3 및 gp2)를 포함합니다. HDD 지원 볼륨은 자주 액세스하고 처리량 집약적인 워크로드를 위한 처리량 최적화 HDD(st1)와 액세스 빈도가 낮은 데이터를 위한 최저비용 콜드 HDD(sc1)를 포함합니다.

탄력적 볼륨은 가동 중단이나 성능 저하 없이 용량을 동적으로 늘리고, 성능을 튜닝하며, 라이브 볼륨의 유형을 변경할 수 있는 Amazon EBS 기능입니다. 이 기능을 사용하면 손쉽게 배포를 적정 규모로 조정하고 성능 변경에 대응할 수 있습니다.

이 시나리오에는 IOPS 성능이 높은 관계형 데이터베이스에 대한 저장소 유형이 필요합니다. 이러한 시나리오에서는 HDD 볼륨 대신 SSD 볼륨을 사용하는 것이 더 적합합니다. SSD의 지배적인 성능 속성은 IOPS이고 HDD는 처리량입니다.

요구 사항은 30,000 IOPS이므로 EBS 유형의 프로비저닝된 IOPS SSD를 사용해야 합니다. 이는 미션 크리티컬한 저지연 워크로드에 대해 지속적인 성능을 제공합니다.

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

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

- 범용 SSD 볼륨

- Provisioned IOPS SSD 볼륨

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

Amazon EC2 Auto Scaling은 현재 사용 중인 AZ 중 인스턴스 수가 가장 많기 때문에 가용 영역(AZ) ap-northeast-2a에서 인스턴스를 종료해야 합니다. ap-northeast-2a에는 다음과 같이 4개의 인스턴스가 있습니다. 인스턴스 A는 가장 오래된 시작 템플릿, 인스턴스 B는 가장 오래된 시작 구성, 인스턴스 C는 최신 시작 구성, 인스턴스 D는 다음 청구 시간에 가장 가깝습니다.

다음 중 기본 종료 정책에 따라 종료되는 인스턴스는 무엇입니까?

인스턴스 B

기본 종료 정책은 종료할 인스턴스를 선택하기 전에 여러 종료 기준을 적용합니다. Amazon EC2 Auto Scaling이 인스턴스를 종료하면 먼저 인스턴스가 가장 많은 가용 영역을 확인하고 축소가 방지되지 않는 인스턴스를 최소 하나 이상 찾습니다. 선택한 가용 영역 내에서 다음과 같은 기본 종료 정책 동작이 적용됩니다.

1. 종료 대상 인스턴스 중 가장 오래된 시작 템플릿 또는 시작 구성을 사용하는 인스턴스가 있는지 확인합니다.

[시작 템플릿을 사용하는 오토 스케일링의 경우]

시작 구성을 사용하는 인스턴스가 없다면 인스턴스 중에서 가장 오래된 시작 템플릿을 사용하는 인스턴스가 있는지 확인합니다. Amazon EC2 Auto Scaling은 시작 템플릿을 사용하는 인스턴스를 종료하기 전에 시작 구성을 사용하는 인스턴스를 종료합니다.

[시작 구성을 사용하는 오토 스케일링의 경우]

이 중에서 가장 오래된 시작 구성을 사용하는 인스턴스가 있는지 확인합니다.

2. 앞선 기준을 적용한 후 종료할 비보호 인스턴스가 여러 개 있는 경우, 다음 결제 시간에 가장 근접한 인스턴스가 무엇인지 확인합니다. 다음번 결제 시간에 가장 근접한 비보호 인스턴스가 여러 개인 경우 이러한 인스턴스 중 하나를 임의로 종료합니다.

기본 종료 정책에 따라 온디맨드 및 스팟 인스턴스에 대한 모든 할당 전략에 첫 번째 우선 순위가 부여됩니다. 주어진 사용 사례에 대해 그러한 정보가 제공되지 않았기 때문에 이 기준은 무시할 수 있습니다. 다음 우선 순위는 시작 구성을 사용하는 인스턴스가 없는 한 가장 오래된 시작 템플릿이 있는 모든 인스턴스를 고려하는 것입니다. 따라서 이것은 인스턴스 A를 배제합니다. 다음으로 가장 오래된 시작 구성을 가진 모든 인스턴스를 고려해야 합니다. 이는 인스턴스 B가 종료 대상으로 선택되고 인스턴스 C도 최신 시작 구성을 가지고 있으므로 제외됨을 의미합니다. 다음 청구 시간에 가장 가까운 인스턴스 D는 이 기준이 우선 순위에서 마지막이므로 선택되지 않습니다.

미디어 회사에서 영화 제작자를 위한 비디오 공유 포털에 Amazon EC2, ELB 및 S3를 사용하고 있습니다. 회사는 게시 첫 3개월 동안만 자주 액세스하는 모든 고품질 비디오를 저장하기 위해 표준 S3 스토리지 클래스를 사용하고 있습니다.

S3 버킷에서 Glacier로 미디어 데이터를 자동으로 전송하거나 아카이브해야 하는 경우 어떻게 해야 합니까?

수명 주기 정책 사용

S3에서 수명 주기 정책을 생성하여 데이터를 Glacier로 자동 전송할 수 있습니다.

수명 주기 동안 객체가 비용 효율적으로 저장되도록 관리하려면 해당 Amazon S3 수명 주기를 구성합니다. S3 수명 주기 구성은 Amazon S3이 객체 그룹에 적용하는 작업을 정의하는 일련의 규칙입니다. 다음과 같은 두 가지 유형의 작업이 있습니다.

- 전환 작업 - 이 작업은 객체가 다른 스토리지 클래스로 전환되는 시기를 정의합니다. 예를 들어, 생성 후 30일이 지나면 객체를 S3 STANDARD-IA 스토리지 클래스로 전환하거나 생성 후 1년이 지나면 객체를 S3 Glacier Flexible Retrieval 스토리지 클래스에 아카이브하도록 선택할 수 있습니다. 수명 주기 전환 요청과 관련된 비용이 있습니다.

- 만료 작업 - 이 작업은 객체가 만료되는 시기를 정의합니다. Amazon S3에서 만료된 객체를 자동으로 삭제합니다. 수명 주기 만료 비용은 선택한 객체 만료 시점에 따라 달라집니다.

객체가 수명 주기 작업에 적합하게 되는 시점과 Amazon S3에서 객체를 이전하거나 만료하는 시점 사이에 지연이 있는 경우 객체가 수명 주기 작업에 적합한 상태가 되는 즉시 결제 변경 사항이 적용됩니다. 예를 들어 객체가 만료되도록 예약되어 있고 Amazon S3가 객체를 즉시 만료하지 않는 경우 만료 시간 이후에는 스토리지 요금이 부과되지 않습니다. 이 동작에 대한 한 가지 예외는 S3 Intelligent-Tiering 스토리지 클래스로 전환하는 수명 주기 규칙이 있는 경우입니다. 이 경우 객체가 S3 Intelligent-Tiering으로 전환될 때까지 결제 변경이 발생하지 않습니다.

수명 주기가 명확한 객체에 대해 S3 수명 주기 구성 규칙을 정의합니다. 예:

- 버킷에 주기적으로 로그를 업로드할 경우 애플리케이션에서는 이것을 한 주나 한 달 동안 필요로 할 수 있습니다. 그 이후에는 사용자가 이것을 삭제하고 싶을 것입니다.

- 일부 문서는 제한된 기간 동안 자주 액세스됩니다. 그 이후에는 문서가 가끔 액세스됩니다. 어느 시점이 되면 이러한 문서에 실시간으로 액세스할 필요가 없지만 조직 또는 규정에서 특정 기간 동안 해당 문서를 보관할 것을 요구할 수도 있습니다. 그 이후에는 사용자가 문서를 삭제할 수 있습니다.

- 어떤 유형의 데이터는 주로 아카이브의 목적으로 Amazon S3에 업로드할 수도 있습니다. 예를 들어, 디지털 미디어, 금융 및 의료 기록, 가공되지 않은 유전체 염기서열 데이터, 장기 데이터베이스 백업 파일, 그리고 규제 준수를 위해 보존해야 하는 데이터 등을 보관할 것입니다.

S3 수명 주기 구성 규칙을 사용하면 Amazon S3가 객체를 더 저렴한 스토리지 클래스로 전환하거나 아카이브하거나 삭제하도록 유도할 수 있습니다.

회사는 온프레미스 네트워크와 AWS 클라우드 모두에서 호스팅되는 리소스를 보유하고 있습니다. 회사 관리자는 모든 소프트웨어 설계자가 Active Directory에 저장된 온프레미스 자격 증명을 사용하여 두 환경의 리소스에 액세스하기를 원합니다.

이 시나리오에서 다음 중 이 요구 사항을 충족하는 데 사용할 수 있는 것은 무엇입니까?

Microsoft AD FS(Active Directory Federation Service)를 사용하여 SAML 2.0 기반 페더레이션을 설정합니다.

회사는 SAML(Security Assertion Markup Language)을 구현하는 Microsoft Active Directory를 사용하고 있으므로 AWS 클라우드에 대한 API 액세스를 위해 SAML 기반 페더레이션을 설정할 수 있습니다. 이러한 방식으로 온프레미스 네트워크의 로그인 자격 증명을 사용하여 AWS에 쉽게 연결할 수 있습니다.

AWS는 많은 자격 증명 공급자(IdP)가 사용하는 개방형 표준인 SAML 2.0(Security Assertion Markup Language 2.0)이라는 ID 페더레이션을 지원합니다. 이 기능은 페더레이션 통합 인증(SSO)을 활성화하므로 조직의 모든 구성원에 대해 IAM 사용자를 생성하지 않아도 사용자가 AWS Management Console에 로그인하거나 AWS API 작업을 호출할 수 있습니다. SAML을 사용함으로써 AWS로 연동을 구성하는 과정을 단순화할 수 있는데, 이는 사용자 지정 자격 증명 프록시 코드를 작성하는 대신 IdP의 서비스를 사용할 수 있기 때문입니다.

AWS 외부에서 사용자 자격 증명을 이미 관리하고 있다면, AWS 계정에서 IAM 사용자를 생성하는 대신 IAM 자격 증명 공급자를 사용할 수 있습니다. 자격 증명 공급자(IdP)를 사용하면 AWS 외부의 사용자 자격 증명을 관리할 수 있고 이 외부 사용자 자격 증명에 계정의 AWS 리소스에 대한 사용 권한을 부여할 수 있습니다. 기업 사용자 디렉터리처럼 조직 내에 이미 고유의 자격 증명 시스템이 있다면 이 방법이 유용합니다. 그 밖에 AWS 리소스에 액세스해야 하는 모바일 앱이나 웹 애플리케이션을 개발할 때도 효과적입니다.

IAM 자격 증명 공급자를 사용하면 사용자 지정 로그인 코드를 생성할 필요도, 고유한 사용자 자격 증명을 관리할 필요도 없습니다. IdP에서 이러한 작업을 대신 수행합니다. 외부 사용자는 Login with Amazon, Facebook 또는 Google과 같은 널리 알려진 IdP를 통해 로그인합니다. 이러한 외부 자격 증명에 계정의 AWS 리소스를 사용할 권한을 제공할 수 있습니다. IAM 자격 증명 공급자를 사용하면 애플리케이션에서 사용자 액세스 키 같은 장기 보안 자격 증명을 배포하거나 포함할 필요가 없으므로 AWS 계정을 안전하게 보호할 수 있습니다.

IdP를 사용하려면 IAM 자격 증명 공급자 엔터티를 생성하여 AWS 계정과 IdP 간에 신뢰 관계를 설정합니다. IAM은 OpenID Connect(OIDC) 또는 SAML 2.0(Security Assertion Markup Language 2.0)과 호환되는 IdP를 지원합니다.

회사에는 탄력적 IP 주소가 있는 2개의 온디맨드 EC2 인스턴스가 있는 VPC가 있습니다. EC2 인스턴스가 현재 인터넷을 통한 SSH 무차별 대입 공격을 받고 있다는 알림을 받았습니다. IT 보안 팀은 이러한 공격이 시작된 IP 주소를 식별했습니다. 팀이 보안 취약성을 영구적으로 수정하기 위해 AWS WAF, GuardDuty 및 AWS Shield Advanced를 설정하는 동안 이러한 공격을 중지하려면 임시 수정 사항을 즉시 구현해야 합니다.

다음 중 인스턴스에 대한 공격을 차단하는 가장 빠른 방법은 무엇입니까?

네트워크 액세스 제어 목록에서 IP 주소 차단

네트워크 액세스 제어 목록(ACL)은 서브넷 수준에서 특정 인바운드 또는 아웃바운드 트래픽을 허용하거나 거부합니다. VPC에 대한 기본 네트워크 ACL을 사용하거나 보안 그룹에 대한 규칙과 유사한 규칙을 사용하여 VPC에 대한 사용자 지정 네트워크 ACL을 생성하여 VPC에 보안 계층을 추가할 수 있습니다.

다음은 네트워크 ACL에 대해 알아야 할 기본 사항입니다.

- VPC는 수정 가능한 기본 네트워크 ACL과 함께 자동으로 제공됩니다. 기본적으로 모든 인바운드 및 아웃바운드 IPv4 트래픽을 허용하며, 해당되는 경우 IPv6 트래픽도 허용합니다.

- 사용자 지정 네트워크 ACL을 생성하여 서브넷과 연결할 수 있습니다. 기본적으로 각 사용자 지정 네트워크 ACL은 규칙을 추가하기 전에는 모든 인바운드 및 아웃바운드 트래픽을 거부합니다.

- VPC에 있는 각 서브넷을 네트워크 ACL과 연결해야 합니다. 서브넷을 네트워크 ACL에 명시적으로 연결하지 않을 경우, 서브넷은 기본 네트워크 ACL에 자동적으로 연결됩니다.

- 네트워크 ACL을 여러 서브넷과 연결할 수 있습니다. 그러나 서브넷은 한 번에 하나의 네트워크 ACL에만 연결할 수 있습니다. 네트워크 ACL을 서브넷과 연결하면 이전 연결은 제거됩니다.

- 네트워크 ACL에는 인바운드 규칙과 아웃바운드 규칙이 있습니다. 각 규칙에서는 트래픽을 허용하거나 거부할 수 있습니다. 각 규칙에는 1부터 32766까지 번호가 있습니다. 규칙은 트래픽 허용 또는 거부가 결정될 때 가장 낮은 번호의 규칙부터 순서대로 평가됩니다. 트래픽이 규칙과 일치하면 규칙이 적용되며 추가 규칙은 평가되지 않습니다. 필요한 경우 나중에 새 규칙을 삽입할 수 있도록 증분 방식으로(예: 10 또는 100 단위씩 증분) 규칙을 생성하여 시작하는 것이 좋습니다.

- 네트워크 ACL 규칙은 트래픽이 서브넷 내에서 라우팅될 때가 아니라 서브넷에 들어오고 나갈 때 평가됩니다.

- 네트워크 ACL은 상태 비저장입니다. 즉, 허용되는 인바운드 트래픽에 대한 응답은 아웃바운드 트래픽에 대한 규칙을 따르고, 그 반대의 경우에도 마찬가지입니다.

VPC당 네트워크 ACL 수 및 네트워크 ACL당 규칙 수에 대한 할당량(제한이라고도 함)이 있습니다.

이 시나리오는 보안 취약점을 해결하는 가장 빠른 방법이 필요하다고 명시하고 있습니다. 이 상황에서는 IT 보안 팀이 이미 문제가 되는 IP 주소 목록을 식별했으므로 네트워크 ACL을 사용하여 문제가 되는 IP 주소를 수동으로 차단할 수 있습니다. 또는 배스천 호스트를 설정할 수 있지만 이 옵션을 사용하면 배스천 호스트의 보안 구성을 구성해야 하므로 적절하게 설정하는 데 추가 시간이 필요합니다.

회사가 EC2 인스턴스 집합에서 호스팅되는 비디오 백업 서비스를 개발했습니다. EC2 인스턴스는 Application Load Balancer 뒤에 있으며 인스턴스는 스토리지에 EBS 볼륨을 사용하고 있습니다. 이 서비스는 인증된 사용자에게 비디오를 업로드한 다음 지정된 인스턴스에 연결된 EBS 볼륨에 저장할 수 있는 기능을 제공합니다. 베타 출시 첫날 사용자는 업로드한 동영상 백업에서 일부 동영상만 볼 수 있다고 불평하기 시작합니다. 사용자가 웹사이트에 로그인할 때마다 업로드된 비디오의 다른 하위 집합을 본다고 불평을 합니다.

다음 중 사용자가 업로드된 모든 동영상을 볼 수 있도록 하는 가장 최적의 솔루션은 무엇입니까? (2개 선택)

모든 EC2 인스턴스에 EFS를 탑재합니다. 모든 EBS 볼륨에서 EFS로 비디오를 복사하는 일회성 작업을 작성합니다. 비디오 저장에 EFS를 사용하도록 애플리케이션 수정합니다.

모든 EBS 볼륨에서 S3로 비디오를 복사하는 일회성 작업을 작성한 다음 비디오를 저장하기 위해 Amazon S3 standard을 사용하도록 애플리케이션을 수정합니다.

Amazon Elastic Block Store(EBS)는 모든 규모의 처리량 및 트랜잭션 집약적 워크로드 모두에 대해 Amazon Elastic Compute Cloud(EC2)와 함께 사용하도록 설계된 사용하기 쉬운 고성능 블록 스토리지 서비스입니다.

Amazon Elastic File System(Amazon EFS)은 AWS 클라우드 서비스 및 온프레미스 리소스와 함께 사용할 수 있는 간단하고 확장 가능한 완전 관리형 탄력적 NFS 파일 시스템을 제공합니다. 애플리케이션 중단 없이 페타바이트까지 온디맨드로 확장할 수 있도록 구축되었으며, 파일을 추가 및 제거할 때 자동으로 확장 및 축소되므로 성장을 수용하기 위해 용량을 프로비저닝하고 관리할 필요가 없습니다.

Amazon Simple Storage Service(Amazon S3)는 업계 최고의 확장성, 데이터 가용성, 보안 및 성능을 제공하는 객체 스토리지 서비스입니다.

EBS 볼륨은 EC2 인스턴스에 로컬로 연결되므로 업로드된 비디오는 특정 EC2 인스턴스에 연결됩니다. 사용자가 로그인할 때마다 다른 인스턴스로 이동하므로 동영상이 여러 EBS 볼륨에 분산됩니다. 올바른 솔루션은 S3 또는 EFS를 사용하여 사용자 비디오를 저장하는 것입니다.

비용을 절감하기 위해 관리자는 AWS 클라우드 인프라의 설정을 분석하고 검토하도록 지시했습니다. 또한 사용 중인 모든 AWS 리소스에 대해 회사에서 지불할 예상 금액도 제공해야 합니다.

이 시나리오에서 다음 중 비용이 발생하는 것은 무엇입니까? (2개 선택)

실행 중인 EC2 인스턴스

중지된 EC2 인스턴스에 연결된 EBS 볼륨

Amazon EC2가 AMI 인스턴스의 부팅 시퀀스를 시작하면 청구가 시작됩니다.

인스턴스가 pending, stopped, shutting-down, terminated되면 청구가 되지 않습니다. 인스턴스를 중지하면 중지된 인스턴스에 대한 시간당 사용량이나 데이터 전송 요금을 부과하지 않습니다.

그러나 AWS는 Amazon EBS 볼륨의 스토리지에 대해 요금을 부과합니다.

회사에는 프라이빗 서브넷에서 민감한 금융 데이터를 처리하는 사내 애플리케이션이 있습니다. 데이터가 EC2 작업자 인스턴스에서 처리된 후 다른 서비스에서 수집할 수 있도록 S3로 전달됩니다.

데이터가 퍼블릭 인터넷을 통과하지 않도록 이 솔루션을 어떻게 설계해야 합니까?

데이터를 S3로 보내는 해당 경로 항목과 함께 VPC 엔드포인트를 구성합니다.

이 시나리오에서 이해해야 하는 중요한 개념은 VPC와 S3 버킷이 더 큰 AWS 네트워크 내에 있다는 것입니다. 그러나 VPC에서 S3 버킷으로 들어오는 트래픽은 기본적으로 퍼블릭 인터넷을 통과합니다. 전송 중인 데이터를 더 잘 보호하기 위해 VPC에서 수신되는 트래픽이 퍼블릭 인터넷이 아닌 프라이빗 AWS 네트워크를 통과하도록 VPC 엔드포인트를 설정할 수 있습니다.

VPC 엔드포인트를 사용하면 인터넷 게이트웨이, NAT 장치, VPN 연결 또는 AWS Direct Connect 연결 없이 VPC를 PrivateLink에서 제공하는 지원되는 AWS 서비스 및 VPC 엔드포인트 서비스에 비공개로 연결할 수 있습니다. VPC의 인스턴스는 서비스의 리소스와 통신하기 위해 퍼블릭 IP 주소가 필요하지 않습니다. VPC와 다른 서비스 간의 트래픽은 Amazon 네트워크를 벗어나지 않습니다.

엔드포인트는 가상 장치입니다. 네트워크 트래픽에 대한 가용성 위험이나 대역폭 제약을 부과하지 않고 VPC의 인스턴스와 서비스 간의 통신을 허용하는 수평 확장, 중복 및 고가용성 VPC 구성 요소입니다.

한 회사에서 중앙 데이터 레이크에서 여러 AWS 계정에 있는 데이터를 쿼리하려고 합니다. 각 계정에는 비즈니스 기능에 고유한 데이터를 저장하는 자체 Amazon S3 버킷이 있습니다. 다른 계정의 사용자는 역할에 따라 데이터 레이크에 대한 액세스 권한을 부여받아야 합니다.

필요한 액세스 패턴을 충족하면서 오버헤드와 비용을 최소화하는 솔루션은 무엇입니까?

AWS Lake Formation을 사용하여 여러 계정의 데이터를 단일 계정으로 통합합니다.

AWS Lake Formation은 안전한 데이터 레이크를 며칠 만에 손쉽게 설정할 수 있도록 지원하는 서비스입니다. 데이터 레이크는 큐레이팅된 안전한 중앙 집중식 리포지토리로, 모든 데이터를 원래 형식 및 분석에 필요한 형식으로 저장합니다. 데이터 레이크를 사용하면 데이터 사일로를 없애고 다양한 유형의 분석을 조합하여 인사이트를 얻을 수 있으며, 이를 바탕으로 더 나은 비즈니스 결정을 내릴 수 있습니다.

데이터 레이크를 설정하고 관리하기 위해서는 수많은 복잡하고 시간 소모적인 수작업이 필요합니다. 이러한 작업에는 다양한 소스로부터 데이터 로딩, 해당 데이터 흐름 모니터링, 파티션 설정, 암호화 설정 및 키 관리, 변환 작업 정의 및 운영 모니터링, 열 기반 형식으로 데이터 재구성, 중복 데이터 제거, 링크된 레코드 매칭 등이 포함됩니다. 데이터가 데이터 레이크에 로드되면, 세분화된 액세스 권한을 데이터 집합에 부여하고 넓은 범위의 분석 및 기계 학습(ML) 도구 및 서비스에 걸쳐 시간에 따른 액세스를 감사해야 합니다.

Lake Formation으로 데이터 레이크를 생성하는 작업은 데이터 원본, 적용할 액세스 및 보안 정책을 정의하는 것 만큼이나 간단합니다. 그러면 Lake Formation이 데이터베이스 및 객체 스토리지의 데이터를 수집하고 카탈로그화한 후, 새로운 Amazon Simple Storage Service(S3) 데이터 레이크로 옮긴 다음, 기계 학습 알고리즘을 사용해 정리 및 분류하고, 열, 행, 셀 수준에서의 세분화된 제어를 사용해 민감한 데이터에 대한 액세스를 보호하도록 지원합니다. 이 과정이 마무리되면 사용자는 사용 가능한 데이터 세트 및 적절한 사용 방법이 설명된 중앙 집중식 데이터 카탈로그에 액세스할 수 있습니다. 그러면 Amazon Redshift, Amazon Athena, Amazon EMR for Apache Spark, Amazon QuickSight 등 선택한 분석 및 기계 학습 서비스에서 이러한 데이터 세트를 사용할 수 있습니다. Lake Formation은 AWS Glue에서 제공되는 기능을 기반으로 합니다.

Lake Formation은 데이터에 액세스하는 모든 사용자 및 서비스에 대해 테이블, 열, 행, 셀 수준에서 운영되는 액세스 제어를 정의하고 적용할 수 있는 단일 장소를 제공합니다. 정책은 일관되게 구현되므로 보안 서비스(예: AWS Identity and Access Management(IAM) 및 AWS Key Management Service(KMS)), 스토리지 서비스(예: S3), 분석 및 기계 학습 서비스(예: Redshift, Athena, AWS Glue 및 EMR for Apache Spark) 등에서 수동으로 구성할 필요가 없습니다. 이를 통해 서비스 간에 정책을 구성하는 노력을 줄이고 일관된 시행 및 준수를 제공합니다.

회사는 최근 ap-northeast-2 리전에서 실행되는 전자 상거래 애플리케이션을 출시했습니다. 이 리전에서는 항상 6개의 EC2 인스턴스가 실행되어야 합니다. 해당 리전에는 ap-northeast-2a, ap-northeast-2b 및 ap-northeast-2c의 3가지 가용 영역(AZ)을 사용할 수 있습니다.

다음 중 리전의 1개의 AZ를 사용할 수 없는 경우 100% 내결함성을 제공하는 배포는 무엇입니까? (2개 선택)

6개의 EC2 인스턴스가 있는 ap-northeast-2a, 6개의 EC2 인스턴스가 있는 ap-northeast-2b 및 EC2 인스턴스가 없는 ap-northeast-2c

3개의 EC2 인스턴스가 있는 ap-northeast-2a, 3개의 EC2 인스턴스가 있는 ap-northeast-2b 및 3개의 EC2 인스턴스가 있는 ap-northeast-2c

내결함성은 시스템을 구축하는 데 사용된 구성 요소 중 일부가 실패하더라도 시스템이 계속 작동할 수 있는 능력입니다. AWS에서 이는 서버 장애 또는 시스템 장애 발생 시 실행 중인 EC2 인스턴스 수가 시스템이 제대로 작동하는 데 필요한 최소 인스턴스 수 아래로 떨어지지 않아야 함을 의미합니다. 따라서 애플리케이션에 최소 6개의 인스턴스가 필요한 경우 가용 영역 중 하나에 중단이 발생하거나 서버 문제가 있는 경우에 대비하여 최소 6개의 인스턴스가 실행되고 있어야 합니다.

이 시나리오에서는 각 옵션에 대해 하나의 가용 영역을 사용할 수 없게 된 상황을 시뮬레이션하고 6개의 실행 중인 인스턴스가 있는지 확인해야 합니다.

Solutions Architect는 투표를 수집할 수 있는 모바일 애플리케이션을 배포해야 합니다. 전 세계 수백만 명의 사용자가 휴대폰을 사용하여 투표를 제출합니다. 이러한 투표는 실시간 순위에 대해 쿼리되는 확장성과 가용성이 높은 데이터 저장소에 수집되고 저장되어야 합니다.

다음 중 Architect가 이 요구 사항을 충족하기 위해 사용해야 하는 서비스 조합은 무엇입니까?

Amazon DynamoDB 및 AWS AppSync

AWS AppSync는 현대적인 웹 및 모바일 애플리케이션 구축을 간소화하는 서버리스 GraphQL 및 구독/게시 API 서비스입니다.

- AWS AppSync GraphQL API는 여러 데이터베이스, 마이크로서비스 및 API의 데이터를 안전하게 쿼리하거나 업데이트할 수 있는 단일의 엔드포인트를 제공하여 애플리케이션 개발을 간소화합니다.

- AWS AppSync 게시/구독 API를 사용하면 서버리스 WebSocket 연결을 통해 구독 API 클라이언트에 자동으로 데이터 업데이트를 게시하여 매력적인 실시간 경험을 간편하게 만들 수 있습니다.

DynamoDB는 실시간 표 작성에 사용할 수 있는 내구성, 확장성, 고가용성 데이터 저장소입니다. 또한 DynamoDB와 함께 AppSync를 사용하여 공유 데이터를 실시간으로 업데이트하는 협업 앱을 쉽게 구축할 수 있습니다. 간단한 코드 문으로 앱에 대한 데이터를 지정하기만 하면 AWS AppSync가 앱 데이터를 실시간으로 업데이트하는 데 필요한 모든 것을 관리합니다. 이렇게 하면 앱이 Amazon DynamoDB의 데이터에 액세스하거나, AWS Lambda 함수를 트리거하거나, Amazon Elasticsearch 쿼리를 실행하고, 이러한 서비스의 데이터를 결합하여 앱에 필요한 정확한 데이터를 제공할 수 있습니다.

Amazon Redshift는 주로 데이터 웨어하우스 및 OLAP(온라인 분석 처리)에 사용되므로 Amazon Redshift 및 AWS Mobile Hub는 올바르지 않습니다. 이 서비스를 이 시나리오에 사용할 수 있지만 DynamoDB는 더 나은 내구성과 확장성을 고려할 때 여전히 최고의 선택입니다.

이 시나리오에서는 Amazon Relational Database Service(RDS)와 Amazon MQ, Amazon Aurora 및 Amazon Cognito가 가능한 답변이지만 DynamoDB는 엔터프라이즈 웹 애플리케이션에 비해 복잡한 데이터 관계가 없는 단순한 모바일 앱에 훨씬 더 적합합니다. 시나리오에서는 모바일 앱이 전 세계에서 사용될 것이라고 명시되어 있기 때문에 전 세계적으로 지원할 수 있는 데이터 저장 서비스가 필요합니다. DynamoDB의 전역 테이블 기능을 사용하는 것과 비교하여 RDS 및 Aurora 데이터베이스 인스턴스에 대해 다중 지역 배포를 구현하는 것은 관리 오버헤드가 됩니다.

회사에서는 클라우드에 저장된 모든 데이터를 미사용 시 암호화해야 합니다. 이를 다른 AWS 서비스와 쉽게 통합하려면 생성된 키의 암호화를 완전히 제어하고 AWS KMS에서 키 구성 요소를 즉시 제거할 수 있는 기능이 있어야 합니다. 또한 AWS CloudTrail과 독립적으로 키 사용을 감사할 수 있어야 합니다.

다음 중 이 요구 사항을 충족하는 옵션은 무엇입니까?

AWS Key Management Service를 사용하여 사용자 지정 키 스토어(KMS custom key stores)에 CMK를 생성하고 추출 불가능한 키 구성 요소를 AWS CloudHSM에 저장합니다.

AWS AWS Key Management Service(KMS)는 암호화 작업에 사용되는 키를 쉽게 생성하고 제어할 수 있도록 지원하는 관리형 서비스입니다. 이 서비스는 고가용성 키 생성, 스토리지, 관리 및 감사 솔루션을 제공하므로, 이를 통해 자체 애플리케이션 내 데이터를 암호화 또는 디지털 방식으로 서명하거나, AWS 서비스 전체에서 데이터의 암호화를 제어할 수 있습니다.

AWS CloudHSM은 클러스터에 HSM(하드웨어 보안 모듈)을 제공합니다. 클러스터는 AWS CloudHSM이 동기화 상태로 유지하는 개별 HSM 모음입니다. 클러스터를 하나의 논리적 HSM으로 생각할 수 있습니다. 클러스터에서 하나의 HSM에 대해 과업 또는 작업을 수행하면 해당 클러스터의 다른 HSM이 자동으로 최신 상태로 유지됩니다.

AWS KMS는 AWS CloudHSM 클러스터에서 지원하는 사용자 지정 키 스토어를 지원합니다. 사용자 지정 키 스토어에서 AWS KMS key를 생성할 때 AWS KMS는 사용자가 보유하고 관리하는 AWS CloudHSM 클러스터에 추출이 불가능한 KMS 키용 키 구성 요소를 생성하여 저장합니다. 사용자 지정 키 스토어에서 KMS 키를 사용할 때 클러스터의 HSM에서 암호화 작업이 수행됩니다. 이 기능은 AWS KMS의 편의성 및 광범위한 통합 기능과 AWS 계정의 추가 AWS CloudHSM 클러스터 컨트롤을 하나로 결합합니다.

AWS KMS는 사용자 지정 키 스토어를 생성, 사용 및 관리할 수 있도록 전체 콘솔 및 API를 지원합니다. KMS 키를 사용하는 것과 동일한 방식으로 사용자 지정 키 스토어에서 KMS 키를 사용할 수 있습니다. 예를 들어 KMS 키를 사용해 데이터 키를 생성하고 데이터를 암호화할 수 있습니다. 또한 고객 관리형 KMS 키를 지원하는 AWS 서비스와 함께 사용자 지정 키 스토어에서 KMS 키를 사용할 수 있습니다.

사용자 지정 키 스토어란 무엇입니까?

키 스토어는 암호화 키를 저장하기에 안전한 장소입니다. AWS KMS의 기본 키 스토어는 저장하는 키를 생성 및 관리하는 방법도 지원합니다. 기본적으로 AWS KMS에서 생성한 AWS KMS key는 FIPS 140-2 검증을 거친 암호화 모듈인 하드웨어 보안 모듈(HSM)에서 생성되고 보호됩니다. KMS 키는 모듈을 암호화되지 않은 상태로 두지 않습니다.

그러나 HSM에 대한 더 많은 제어가 필요한 경우 소유하고 관리하는 AWS CloudHSM 클러스터에서 FIPS 140-2 레벨 3 HSM이 지원하는 사용자 지정 키 스토어를 생성할 수 있습니다.

사용자 지정 키 스토어는 AWS CloudHSM 클러스터에 연결된 AWS KMS 리소스입니다. 사용자가 사용자 지정 키 스토어에서 KMS 키를 생성하면 AWS KMS는 연결된 AWS CloudHSM 클러스터에 내보내기가 불가능하고 영구적인 256비트의 고급 암호화 표준(AES) 대칭 키를 생성합니다. 이 키 구성 요소는 HSM을 암호화되지 않은 상태로 두지 않습니다. 사용자 지정 키 스토어에서 KMS 키를 사용할 때 클러스터의 HSM에서 암호화 작업이 수행됩니다.

사용자 지정 키 스토어는 AWS KMS의 편리하고 포괄적인 키 관리 인터페이스와 AWS 계정의 AWS CloudHSM 클러스터가 제공하는 추가적인 컨트롤을 하나로 결합합니다. 이러한 통합 기능 덕분에 클러스터, HSM 및 백업 관리를 포함해 키 구성 요소를 저장하는 HSM에 대한 완벽한 제어권을 유지하면서도 AWS KMS에서 KMS 키를 생성, 관리 및 사용할 수 있습니다. AWS KMS 콘솔 및 API를 사용해 사용자 지정 키 스토어와 그 KMS 키를 관리할 수 있습니다. 또한 AWS CloudHSM 콘솔, API, 클라이언트 소프트웨어 및 연결 소프트웨어 라이브러리를 사용하여 연결 클러스터를 관리할 수도 있습니다.

사용자 지정 키 스토어가 필요할까요?

대부분의 사용자의 경우 FIPS 140-2 인증 암호화 모듈로 보호되는 기본 AWS KMS 키 스토어가 보안 요구 사항을 충족합니다. 유지 관리를 책임지는 계층을 추가하거나 추가 서비스에 의존할 필요가 없습니다.

하지만 조직이 다음 요구 사항을 가지고 있는 경우에는 사용자 지정 키 스토어를 생성하는 방법을 고려할 수 있습니다.

- 키 구성 요소는 공유 환경에 저장할 수 없습니다.

- 키 구성 요소는 독립적인 보조 감사 경로를 따라야 합니다.

- 키 구성 요소를 생성하고 저장하는 HSM은 FIPS 140-2 레벨 3에서 인증을 받아야 합니다.

사용자 지정 키 스토어는 어떻게 작동합니까?

각각의 사용자 지정 키 스토어는 AWS 계정의 AWS CloudHSM 클러스터와 연결됩니다. 사용자 지정 키 스토어를 클러스터에 연결할 때 AWS KMS는 이러한 연결을 지원하는 네트워크 인프라를 생성합니다. 그런 다음 클러스터의 전용 암호화 사용자 자격 증명을 사용하여 클러스터의 키 AWS CloudHSM 클라이언트에 로그인합니다.

사용자 지정 키 스토어는 AWS KMS에서, HSM 클러스터는 AWS CloudHSM에서 생성 및 관리합니다. AWS KMS 사용자 지정 키 스토어에서 AWS KMS keys을 생성하면 AWS KMS에서 KMS 키를 보고 관리합니다. 그러나 클러스터의 다른 키에서와 마찬가지로 AWS CloudHSM에서 키 구성 요소를 확인 및 관리할 수도 있습니다.

사용자 지정 키 스토어에서 AWS KMS가 생성한 키 구성 요소를 사용하여 대칭 암호화 KMS 키를 생성할 수 있습니다. 그런 다음 같은 기법을 사용하여 AWS KMS 키 스토어에서 KMS 키에 사용하는 사용자 지정 키 스토어에서 KMS 키를 확인 및 관리할 수 있습니다. IAM 및 키 정책을 통해 액세스를 제어하고 태그 및 별칭을 생성하며 KMS 키를 활성화 및 비활성화하고 키 삭제를 예약할 수 있습니다. 암호화 작업에서 KMS 키를 사용하고 AWS KMS를 통합한 AWS 서비스와 함께 이들을 사용할 수 있습니다.

뿐만 아니라 HSM 생성 및 삭제하고 백업을 관리하는 등 AWS CloudHSM 클러스터를 완벽하게 제어할 수 있습니다. AWS CloudHSM 클라이언트와 지원되는 소프트웨어 라이브러리를 사용하여 KMS 키를 위한 키 구성 요소를 확인, 감사 및 관리할 수 있습니다. 사용자 지정 키 스토어의 연결이 해제되어 있으면 AWS KMS가 사용자 지정 키 스토어에 액세스할 수 없기 때문에 사용자는 암호화 작업 시 사용자 지정 키 스토어의 KMS 키를 사용할 수 없습니다. 이러한 추가적인 제어 계층 덕분에 사용자 지정 키 스토어는 이를 필요로 하는 조직에게 강력한 솔루션이 될 수 있습니다.

- 2개의 CloudHSM 인스턴스 클러스터가 KMS에 연결되어 고객 제어 키 스토어 생성

요약 :

AWS KMS를 사용하면 다른 AWS 서비스와 통합하여 이러한 서비스에 저장하는 데이터를 암호화하고 이를 해독하는 키에 대한 액세스를 제어할 수 있습니다. AWS KMS에서 키 구성 요소를 즉시 제거하기 위해 사용자 지정 키 스토어를 사용할 수 있습니다. 각 사용자 지정 키 스토어는 AWS 계정의 AWS CloudHSM 클러스터와 연결되어 있습니다. 따라서 사용자 지정 키 스토어에서 AWS KMS CMK를 생성하면 AWS KMS는 사용자가 소유하고 관리하는 AWS CloudHSM 클러스터에서 CMK에 대한 추출 불가능한 키 구성 요소를 생성하고 저장합니다. 이는 AWS KMS 또는 AWS CloudTrail과 별도로 모든 키의 사용을 감사하려는 경우에도 적합합니다다

여기까지

AWS에서 호스팅되는 온라인 의료 시스템은 Amazon S3 버킷에 사용자의 민감한 개인 식별 정보(PII)를 저장합니다. 회사의 엄격한 규정 준수 및 규제 요구 사항을 준수하기 위해 마스터 키와 암호화되지 않은 데이터를 모두 AWS로 보내서는 안 됩니다.

사용해야 하는 S3 암호화 기술은 무엇입니까?

클라이언트 측 마스터 키로 S3 클라이언트 측 암호화를 사용합니다.

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

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

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

AWS KMS 관리형 고객 마스터 키를 사용하여 클라이언트 측 데이터 암호화를 활성화하는 경우 AWS KMS 고객 마스터 키 ID(CMK ID)를 AWS에 제공합니다. 반면에 클라이언트 측 데이터 암호화에 클라이언트 측 마스터 키를 사용하는 경우 클라이언트 측 마스터 키와 암호화되지 않은 데이터는 AWS로 전송되지 않습니다. 암호화 키를 분실하면 데이터를 해독할 수 없으므로 안전하게 관리하는 것이 중요합니다.

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

클라이언트 측 마스터 키를 사용한 클라이언트 측 암호화가 작동하는 방식은 다음과 같습니다.

객체를 업로드할 때 - Amazon S3 암호화 클라이언트에 클라이언트 측 루트 키를 제공합니다. 클라이언트에서는 임의로 생성하는 데이터 암호화 키를 암호화하기 위해서만 이 루트 키를 사용합니다.

다음 단계에서는 프로세스에 대해 설명합니다.

1. Amazon S3 암호화 클라이언트에서 일회용 대칭 암호화 키(즉 데이터 암호화 키 또는 데이터 키)를 로컬로 생성합니다. 또한 데이터 키를 사용하여 단일 Amazon S3 객체의 데이터를 암호화합니다. 클라이언트는 각 객체에 대한 개별 데이터 키를 생성합니다.

2. 클라이언트에서 사용자가 제공하는 루트 키를 사용하여 데이터 암호화 키를 암호화합니다. 클라이언트에서 암호화된 데이터 키 및 해당 구성 요소 설명을 객체 메타데이터의 일부로 업로드합니다. 클라이언트는 구성 요소 설명을 사용하여 어떤 클라이언트 측 루트 키를 암호화에 사용할지 결정합니다.

3. 그런 다음 클라이언트에서 기본적으로 암호화된 데이터를 Amazon S3에 업로드하고 암호화된 데이터 키를 객체 메타데이터(x-amz-meta-x-amz-key)로 Amazon S3에 저장합니다.

객체를 다운로드할 때 - 클라이언트가 먼저 Amazon S3에서 암호화된 객체를 다운로드합니다. 클라이언트에서 먼저 객체 메타데이터의 구성 요소 설명을 사용하여 데이터 키의 암호 복호화에 어떤 루트 키를 사용할지를 결정합니다. 클라이언트는 해당 루트 키를 사용하여 데이터 키를 복호화하고 나서 데이터 키를 사용하여 객체를 복호화합니다.

Solutions Architect는 EC2 인스턴스가 S3 및 Redshift와 같은 다양한 AWS 서비스에 액세스해야 하는 클라우드 인프라를 구축하고 있습니다. Architect는 또한 시스템 관리자가 변경 사항을 배포하고 테스트할 수 있도록 액세스 권한을 제공해야 합니다.

리소스에 대한 액세스가 보호되고 손상되지 않도록 하려면 어떤 구성을 사용해야 합니까? (2개 선택)

다단계 인증을 활성화합니다.

Amazon EC2 인스턴스에 IAM 역할을 할당합니다.

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

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

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

애플리케이션은 AWS 자격 증명으로 API 요청에 서명해야 합니다. 따라서 애플리케이션 개발자는 EC2 인스턴스에서 실행되는 인스턴스의 자격 증명을 관리할 전략을 수립해야 합니다. 예를 들어 AWS 자격 증명을 인스턴스에 안전하게 배포하여 다른 사용자로부터 보호하는 한편 해당 인스턴스의 애플리케이션이 자격 증명을 사용하여 요청에 서명하도록 할 수 있습니다. 그러나 각 인스턴스에 자격 증명을 안전하게 배포하기란 쉽지 않으며, 스팟 인스턴스와 같이 AWS에서 자동으로 생성하는 인스턴스 또는 Auto Scaling 그룹의 인스턴스에 대해서는 특히 어렵습니다. 또한 AWS 자격 증명을 교체할 때 각 인스턴스의 자격 증명을 업데이트할 수 있어야 합니다.

애플리케이션이 사용하는 보안 자격 증명을 직접 관리할 필요 없이 인스턴스의 애플리케이션에서 안전하게 API 요청을 전송할 수 있도록 IAM 역할을 설계했습니다. AWS 자격 증명을 생성하고 배포하는 대신 다음과 같이 IAM 역할을 사용하여 API 요청 전송 권한을 위임할 수 있습니다.

1. IAM 역할 생성.

2. 역할을 수행할 수 있는 계정 또는 AWS 서비스를 정의합니다.

3. 역할을 수행하면서 애플리케이션이 사용할 수 있는 API 작업 및 리소스를 정의합니다.

4. 인스턴스를 시작할 때 역할을 지정하거나, 기존 인스턴스에 역할을 연결합니다.

5. 애플리케이션에서 임시 자격 증명 세트를 검색하여 사용하도록 합니다.

예를 들어 IAM 역할을 사용하여 인스턴스에서 실행되며 Amazon S3의 버킷을 사용해야 하는 애플리케이션에 해당 권한을 부여할 수 있습니다. JSON 형식으로 정책을 생성하여 IAM 역할에 권한을 지정할 수 있습니다. 이 방법은 IAM 사용자를 대상으로 정책을 생성할 때와 비슷합니다. 역할을 변경하면 모든 인스턴스에 변경 내용이 전파됩니다.

다른 AWS 서비스에 액세스하려면 IAM 역할을 IAM 사용자가 아니라 EC2 인스턴스에 연결해야 합니다.

AWS MFA( 다중 요소 인증 )는 사용자 이름 및 암호 로그인 자격 증명 외에 두 번째 인증 요소가 필요한 AWS IAM(Identity and Access Management) 모범 사례입니다. AWS 계정 수준에서 그리고 계정에서 생성한 루트 및 IAM 사용자에 대해 MFA를 활성화할 수 있습니다.

회사의 소프트웨어 엔지니어링 인턴이 Amazon EC2 API를 통해 EC2 인스턴스를 프로비저닝하는 프로세스 흐름을 문서화하고 있습니다. 이러한 인스턴스는 HR 급여 데이터를 처리하는 내부 애플리케이션에 사용됩니다. 그는 부팅 볼륨으로 사용할 수 없는 볼륨 유형을 강조 표시하려고 합니다.

인스턴스를 생성하는 동안 부트 볼륨으로 사용할 수 없는 스토리지 볼륨 유형은 무엇이 있습니까? (2개 선택)

처리량 최적화 HDD(st1)

콜드 HDD(sc1)

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

범용 SSD 볼륨

Provisioned IOPS SSD 볼륨

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

처리량 최적화 HDD(st1) 및 Cold HDD(sc1) 볼륨 유형은 부팅 볼륨으로 사용할 수 없으므로 이 두 가지 옵션이 맞습니다.

Solutions Architect는 약 300명의 IAM 사용자로 구성된 회사의 AWS 계정을 관리하고 있습니다. Amazon S3 버킷에 대한 액세스를 제어하는 100명의 IAM 사용자 모두의 관련 권한을 변경해야 하는 새로운 회사 정책이 있습니다.

각 사용자에게 정책을 적용하는 시간 소모적인 작업을 피하기 위해 Solutions Architect는 무엇을 합니까?

새 IAM 그룹을 생성한 다음 S3 버킷에 액세스해야 하는 사용자를 추가합니다. 그런 다음 IAM 그룹에 정책을 적용합니다.

IAM 사용자 그룹은 IAM 사용자의 집합입니다. 사용자 그룹을 활용하면 다수의 사용자들에 대한 권한을 지정함으로써 해당 사용자들에 대한 권한을 더 쉽게 관리할 수 있습니다. 예를 들어, Admins라는 사용자 그룹이 있고 해당 사용자 그룹에 일반 관리자 권한을 부여할 수 있습니다. 해당 사용자 그룹의 모든 사용자는 자동으로 Admins 그룹 권한을 갖습니다. 관리자 권한을 필요로 하는 새로운 사용자가 조직에 들어올 경우 해당 사용자를 Admins 사용자 그룹에 추가하여 적절한 권한을 할당할 수 있습니다. 조직에서 직원의 업무가 바뀌면 해당 사용자의 권한을 편집하는 대신 이전 사용자 그룹에서 해당 사용자를 제거한 후 적절한 새 사용자 그룹에 추가하면 됩니다.

사용자 그룹의 모든 사용자가 정책의 권한을 받도록 아이덴티티 기반 정책을 사용자 그룹에 연결할 수 있습니다. 그룹은 인증이 아니라 권한과 관련이 있고 보안 주체는 인증된 IAM 엔터티이기 때문에 정책(예: 리소스 기반 정책)에서 사용자 그룹을 Principal로 식별할 수 없습니다.

다음은 사용자 그룹이 갖는 몇 가지 중요한 특징입니다.

- 한 사용자 그룹에 여러 사용자가 포함될 수 있으며 한 사용자가 다중 사용자 그룹에 속할 수 있습니다.

- 사용자 그룹은 중첩될 수 없습니다. 즉, 사용자 그룹은 사용자만 포함할 수 있으며 다른 그룹은 포함할 수 없습니다.

- AWS 계정의 모든 사용자를 자동으로 포함하는 기본 사용자 그룹은 없습니다. 이러한 사용자 그룹이 필요한 경우 하나 만들어 새로운 사용자를 각각 해당 그룹에 할당해야 합니다.

- 그룹 수, 사용자가 멤버가 될 수 있는 그룹 수와 같이 AWS 계정에 있는 IAM 리소스의 수와 크기는 제한되어 있습니다.

이 시나리오에서 가장 좋은 옵션은 IAM 그룹의 사용자 집합을 그룹화한 다음 Amazon S3 버킷에 대한 필수 액세스 권한이 있는 정책을 적용하는 것입니다. 이를 통해 IAM 사용자 100명마다 정책을 수동으로 추가하는 대신 사용자를 쉽게 추가, 제거 및 관리할 수 있습니다.

회사는 온프레미스 IT 인프라를 AWS 클라우드로 이전하려고 합니다. 이 회사는 애플리케이션 스택 전반에 걸쳐 여러 개의 장기 서버 바인딩 라이선스를 보유하고 있으며 CTO는 AWS로 이동하는 동안 이러한 라이선스를 계속 사용하기를 원합니다.

다음 중 가장 비용 효율적인 솔루션으로 추천할 수 있는 것은 무엇입니까?

EC2 전용 호스트 사용

전용 호스트를 사용하여 전용 물리적 서버에서 Amazon EC2 인스턴스를 시작할 수 있습니다. 전용 호스트는 인스턴스가 물리적 서버에 배치되는 방식에 대한 추가적인 가시성과 제어를 제공하며 시간이 지남에 따라 동일한 물리적 서버를 안정적으로 사용할 수 있습니다. 결과적으로 전용 호스트를 통해 Windows Server와 같은 기존 서버 바인딩 소프트웨어 라이선스를 사용하고 기업 규정 준수 및 규정 요구 사항을 해결할 수 있습니다.

IT 컨설턴트는 대형 금융 회사에서 일하고 있습니다. 컨설턴트의 역할은 개발 팀이 상태 비저장 웹 서버를 사용하여 고가용성 웹 애플리케이션을 구축하도록 돕는 것입니다.

이 시나리오에서 세션 상태 데이터를 저장하는 데 적합한 AWS 서비스는 무엇입니까? (2개 선택)

DynamoDB

ElastiCache

DynamoDB와 ElastiCache 모두에 세션 상태 데이터를 저장할 수 있습니다. 이러한 AWS 서비스는 고가용성 웹 애플리케이션을 구축하는 데 사용할 수 있는 키-값 쌍의 고성능 스토리지를 제공합니다.

개발팀이 ECS에 마이크로서비스를 배포했습니다. 애플리케이션 계층은 Application Load Balancer를 통해 정적 및 동적 콘텐츠를 모두 제공하는 Docker 컨테이너에 있습니다. 로드가 증가함에 따라 ECS 클러스터의 네트워크 사용량이 증가하고 있습니다. 개발팀은 네트워크 사용을 조사한 결과 90%가 애플리케이션의 정적 콘텐츠 배포로 인한 것임을 발견했습니다.

애플리케이션의 네트워크 사용량을 개선하고 비용을 절감하기 위해 무엇을 권장합니까?

Amazon S3를 통해 정적 콘텐츠 배포

Amazon S3를 사용하여 정적 웹 사이트를 호스팅할 수 있습니다. 정적 웹 사이트에서 개별 웹 페이지에는 정적 콘텐츠가 포함됩니다. 여기에는 클라이언트 측 스크립트가 포함될 수도 있습니다. Amazon S3에서 정적 웹 사이트를 호스팅하려면 웹 사이트 호스팅을 위해 Amazon S3 버킷을 구성한 다음 웹 사이트 콘텐츠를 버킷에 업로드합니다. 버킷을 정적 웹 사이트로 구성할 때 웹 사이트 호스팅을 활성화하고 권한을 설정하고 인덱스 문서를 생성 및 추가해야 합니다. 웹 사이트 요구 사항에 따라 리디렉션, 웹 트래픽 로깅 및 사용자 지정 오류 문서를 구성할 수도 있습니다.

S3를 통해 정적 콘텐츠를 배포하면 대부분의 네트워크 사용량을 S3로 오프로드하고 ECS에서 실행되는 애플리케이션을 확보할 수 있습니다.

회사는 중요한 기록을 온프레미스 스토리지 시스템에 저장합니다. 이러한 기록은 무기한 보관해야 하며 일단 저장되면 모든 유형의 수정으로부터 보호되어야 합니다. 규정 준수 규정에 따라 기록에는 세분화된 액세스 제어가 있어야 하며 각 데이터 액세스는 모든 수준에서 감사해야 합니다. 현재 웹 애플리케이션에서 액세스하지 못하는 오래된 레코드가 수백만 개 있으며 온프레미스 스토리지의 공간이 빠르게 부족합니다. Solutions Architect는 기존 기록을 AWS로 즉시 이동하고 계속해서 증가하는 새로운 기록을 지원하는 솔루션을 설계해야 합니다.

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

온프레미스 네트워크에서 AWS 클라우드로 기존 상태 레코드를 이동하도록 AWS DataSync를 설정합니다. 기존 및 새 레코드를 저장할 새 Amazon S3 버킷을 시작합니다. 버킷에서 데이터 이벤트 및 Amazon S3 객체 잠금으로 AWS CloudTrail을 활성화합니다.

AWS Storage Gateway는 거의 무제한의 클라우드 스토리지에 대한 온프레미스 액세스를 제공하는 하이브리드 클라우드 서비스 세트입니다. 고객은 Storage Gateway를 사용하여 AWS 클라우드 스토리지를 기존 온사이트 워크로드와 통합하여 스토리지 관리를 간소화하고 주요 하이브리드 클라우드 스토리지 사용 사례에 대한 비용을 절감할 수 있습니다. 여기에는 백업을 클라우드로 이동하고, 클라우드 스토리지가 지원하는 온프레미스 파일 공유를 사용하고, 온프레미스 애플리케이션을 위해 AWS의 데이터에 대한 짧은 지연 시간 액세스를 제공하는 것이 포함됩니다.

AWS DataSync는 온프레미스 스토리지 시스템과 AWS 스토리지 서비스 간, AWS 스토리지 서비스 간 데이터 이동을 간소화, 자동화 및 가속화하는 온라인 데이터 전송 서비스입니다. DataSync를 사용하여 활성 데이터 세트를 AWS로 마이그레이션하고, 데이터를 아카이브하여 온프레미스 스토리지 용량을 확보하고, 비즈니스 연속성을 위해 데이터를 AWS에 복제하거나, 분석 및 처리를 위해 데이터를 클라우드로 전송할 수 있습니다.

AWS Storage Gateway와 AWS DataSync는 모두 온프레미스 데이터 센터에서 AWS로 또는 그 반대로 데이터를 보낼 수 있습니다. 그러나 AWS Storage Gateway는 데이터를 복제하여 스토리지 서비스를 통합하는 데 더 적합하고 AWS DataSync는 데이터를 이동하거나 마이그레이션해야 하는 워크로드에 더 적합합니다.

또한 DataSync와 파일 게이트웨이의 조합을 사용하여 온프레미스 애플리케이션을 클라우드 스토리지에 원활하게 연결하면서 온프레미스 인프라를 최소화할 수 있습니다. AWS DataSync를 사용하면 AWS 스토리지 서비스로의 온라인 데이터 전송을 자동화하고 가속화할 수 있습니다. 파일 게이트웨이는 온프레미스 스토리지 시스템과 AWS 스토리지 서비스 간의 데이터 복제를 자동화하고 가속화하는 완전관리형 솔루션입니다.

AWS CloudTrail은 AWS 계정의 거버넌스, 규정 준수, 운영 및 위험 감사를 지원하는 AWS 서비스입니다. 사용자, 역할 또는 AWS 서비스가 수행한 작업은 CloudTrail에 이벤트로 기록됩니다. 이벤트에는 AWS Management Console, AWS Command Line Interface, AWS SDK 및 API에서 수행된 작업이 포함됩니다.

CloudTrail을 구성하는 이벤트에는 두 가지 유형이 있습니다.

- 관리 이벤트

- 데이터 이벤트

관리 이벤트는 AWS 계정의 리소스에서 수행되는 관리 작업에 대한 가시성을 제공합니다. 제어 평면 작업이라고도 합니다. 관리 이벤트에는 계정에서 발생하는 비 API 이벤트도 포함될 수 있습니다.

반면 데이터 이벤트는 리소스에서 또는 리소스 내에서 수행되는 리소스 작업에 대한 가시성을 제공합니다. 데이터 평면 작업이라고도 합니다. 고급 이벤트 선택기로 데이터 이벤트 로깅을 세부적으로 제어할 수 있습니다. 현재 Amazon S3 객체 수준 API 활동(예: GetObject, DeleteObject 및 PutObject API 작업), AWS Lambda 함수 실행 활동(Invoke API), DynamoDB 항목 작업 등과 같은 다양한 리소스 유형에 대한 데이터 이벤트를 기록할 수 있습니다.

S3 객체 잠금을 사용하면 WORM(Write-Once-Read-Many) 모델을 사용하여 객체를 저장할 수 있습니다. 객체 잠금을 사용하면 고정된 시간 동안 또는 무기한으로 객체가 삭제되거나 덮어쓰여지는 것을 방지할 수 있습니다. 객체 잠금을 사용하여 WORM 스토리지가 필요한 규정 요구 사항을 충족하거나 객체 변경 및 삭제에 대한 다른 보호 계층을 추가할 수 있습니다.

Amazon S3 리소스에서 사용자, 역할 또는 AWS 서비스가 수행한 작업을 기록하고 감사 및 규정 준수 목적으로 로그 기록을 유지할 수 있습니다. 이를 위해 서버 액세스 로깅, AWS CloudTrail 로깅 또는 둘의 조합을 사용할 수 있습니다. AWS는 Amazon S3 리소스에 대한 버킷 및 객체 수준 작업을 로깅하는 데 AWS CloudTrail을 사용할 것을 권장합니다.

회사에는 온라인 거래 애플리케이션과 개발팀이 있습니다. 개발팀은 회사의 현재 트래픽에 대처하고 비용 효율성을 달성할 수 있도록 EC2 인스턴스의 Auto Scaling 그룹을 만들었습니다. 그들은 Auto Scaling 그룹이 EC2 인스턴스의 수를 축소하기 전에 사전 정의된 매개변수 세트를 따르는 방식으로 작동하여 의도하지 않은 속도 저하 또는 비가용성으로부터 시스템을 보호하기를 원합니다.

다음 중 휴지 기간에 대한 설명으로 옳은 것은? (2개 선택)

이전 조정 정책이 적용되기 전에 Auto Scaling 그룹이 추가 EC2 인스턴스를 시작하거나 종료하지 않도록 합니다.

기본값은 300초입니다.

Amazon EC2 Auto Scaling은 종료 정책을 사용하여 축소 이벤트 중에 처음 종료할 인스턴스를 결정합니다. 종료 정책은 종료할 인스턴스를 선택할 때 Amazon EC2 Auto Scaling에서 사용하는 종료 기준을 정의합니다.

오토 스케일링은 기본 종료 정책을 사용하지만, 사용자는 원하는 경우 자신의 종료 기준에 따라 자체 종료 정책을 선택하거나 생성할 수 있습니다. 이렇게 하면 특정 애플리케이션 요구 사항에 따라 인스턴스가 종료될 수 있습니다.

또한 Amazon EC2 Auto Scaling은 인스턴스 축소 보호도 제공합니다. 이 기능을 사용하면 축소 이벤트 중에 인스턴스가 종료되지 않습니다. 오토 스케일링을 생성할 때 인스턴스 축소 보호를 활성화할 수 있으며 실행 중인 인스턴스의 설정을 변경할 수 있습니다. 기존 오토 스케일링에서 인스턴스 축소 보호를 활성화하면 그 이후에 시작된 모든 새 인스턴스에는 인스턴스 축소 보호 기능이 활성화되어 있습니다.

오토 스케일링은 인스턴스를 시작하거나 종료한 후 단순 조정 정책에 의해 시작된 추가 조정 활동이 시작되기 전에 휴지 기간이 끝날 때까지 기다립니다. 휴지 기간의 목적은 오토 스케일링이 이전 활동의 효과가 나타나기 전에 추가 인스턴스를 시작하거나 종료하는 것을 방지하는 것입니다.

예를 들어 CPU 사용률에 대한 간단한 조정 정책에서 두 개의 인스턴스를 시작하도록 권장한다고 가정합니다. Amazon EC2 Auto Scaling은 두 개의 인스턴스를 시작한 다음 휴지 기간이 끝날 때까지 조정 활동을 일시 중지합니다. 휴지 기간이 끝나면 단순 조정 정책에 의해 시작된 모든 조정 활동이 재개될 수 있습니다. CPU 사용률이 다시 경보 상한 임계값을 위반하면 오토 스케일링이 다시 확장되고 휴지 기간이 다시 적용됩니다. 그러나 두 개의 인스턴스로 지표 값을 다시 낮추기에 충분하면 그룹은 현재 크기로 유지됩니다.

Amazon EC2 Auto Scaling 콘솔에서 오토 스케일링을 처음 생성할 때는 기본 휴지 시간을 설정할 수 없습니다. 기본적으로 휴지 기간은 300초(5분)로 설정됩니다. 필요한 경우 그룹이 생성된 후 이를 업데이트할 수 있습니다.

Amazon EC2 Auto Scaling은 인스턴스 축소 보호를 제공합니다. 이 기능을 사용하면 축소 이벤트 중에 인스턴스가 종료되지 않습니다. 오토 스케일링을 생성할 때 인스턴스 축소 보호를 활성화할 수 있으며 실행 중인 인스턴스의 설정을 변경할 수 있습니다. 기존 오토 스케일링에서 인스턴스 축소 보호를 활성화하면 그 이후에 시작된 모든 새 인스턴스에는 인스턴스 축소 보호 기능이 활성화되어 있습니다.

회사에 지난 몇 달 동안 거의 사용되지 않은 기존 VPC가 있습니다. 비즈니스 관리자는 Solutions Architect에게 회사의 온프레미스 데이터 센터와 VPC를 통합하도록 지시했습니다. Architect는 수행할 작업 목록을 설명하고 가상 사설망(VPN) 연결에 대해 논의했습니다. 비즈니스 관리자는 엔지니어는 아니지만 VPN이 무엇이며 그 이점이 무엇인지 알고 싶어합니다.

AWS에서 VPN을 사용할 때의 주요 이점 중 하나는 무엇입니까?

VPN을 통해 IP 보안(IPSec) 또는 전송 계층 보안(TLS) 터널이 있는 안전한 비공개 세션을 사용하여 AWS 클라우드 리소스를 온프레미스 데이터 센터에 연결할 수 있습니다.

Amazon VPC는 원격 네트워크와 Amazon VPC 네트워크에서 실행되는 소프트웨어 VPN 어플라이언스 간에 VPN 연결을 생성하여 Amazon VPC 연결의 양쪽을 완전히 관리할 수 있는 유연성을 제공합니다. 이 옵션은 규정 준수를 위해 또는 현재 Amazon VPC의 VPN 솔루션에서 지원하지 않는 게이트웨이 디바이스를 활용하기 위해 VPN 연결의 양쪽 끝을 관리해야 하는 경우에 권장됩니다.

다음 VPN 연결 옵션을 사용하여 Amazon VPC를 원격 네트워크 및 사용자에 연결할 수 있습니다.

AWS Site-to-Site VPN

VPC와 원격 네트워크 사이에 IPsec VPN 연결을 생성할 수 있습니다. AWS 측 Site-to-Site VPN 연결에서 가상 프라이빗 게이트웨이 또는 Transit Gateway는 자동 장애 조치를 위한 2개의 VPN 엔드포인트(터널)를 제공합니다. Site-to-Site VPN 원격 연결 측에서 고객 게이트웨이 디바이스를 구성합니다.

AWS Client VPN

AWS Client VPN은 AWS 리소스와 온프레미스 네트워크에 안전하게 액세스할 수 있게 해주는 관리형 클라이언트 기반 VPN 서비스입니다. AWS Client VPN을 사용하여 사용자가 연결할 수 있는 엔드포인트를 구성하여 보안 TLS VPN 세션을 설정할 수 있습니다. 이렇게 하면 클라이언트가 OpenVPN 기반 VPN 클라이언트를 사용하여 어느 위치에서든 온프레미스 또는 AWS의 리소스에 액세스할 수 있습니다.

AWS VPN CloudHub

원격 네트워크가 두 개 이상인 경우(예: 여러 지사 사무실), 가상 프라이빗 게이트웨이를 통해 AWS Site-to-Site VPN 연결을 여러 개 만들고 이들 네트워크 사이의 통신을 활성화할 수 있습니다.

타사 소프트웨어 VPN 어플라이언스

서드 파티 소프트웨어 VPN 어플라이언스를 실행 중인 VPC에서 Amazon EC2 인스턴스를 사용하여 원격 네트워크에 대한 VPN 연결을 생성할 수 있습니다. AWS는 서드 파티 소프트웨어 VPN 어플라이언스를 제공하거나 유지 관리하지 않지만, 파트너와 오픈 소스 커뮤니티에서 제공하는 다양한 제품 중에서 선택할 수 있습니다.

VPN 연결을 사용하면 클라우드의 Amazon VPC에 연결할 수 있으며 IP 보안(IPSec) 또는 TLS(전송 계층 보안) 터널을 사용하여 안전한 비공개 세션을 설정할 수 있습니다.

클라우드 인프라 팀의 기술 리더는 자신이 구축 중인 웹 애플리케이션의 필수 AWS 리소스에 대해 소프트웨어 개발자의 자문을 받았습니다. 개발자는 인스턴스 스토어가 인스턴스가 종료될 때 데이터가 자동으로 삭제되는 임시 스토리지만 제공한다는 것을 알고 있습니다. 웹 애플리케이션의 데이터가 지속되도록 하려면 내구성 있는 블록 수준 스토리지 볼륨이 연결된 EC2 인스턴스에서 앱을 시작해야 합니다. 개발자는 EBS 볼륨을 사용해야 한다는 것을 알고 있지만 어떤 유형을 사용해야 하는지 잘 모릅니다.

이 시나리오에서 Amazon EBS 볼륨 유형과 해당 사용량에 대한 설명으로 옳은 것은?

프로비저닝된 IOPS 볼륨은 일관되고 지연 시간이 짧은 스토리지를 제공하며 대규모 관계형 또는 NoSQL 데이터베이스와 같은 I/O 집약적 애플리케이션을 위해 설계되었습니다.

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

- 범용 SSD 볼륨

범용(SSD)은 고객에게 기본 선택으로 권장되는 새로운 SSD 지원 범용 EBS 볼륨 유형입니다. 범용(SSD) 볼륨은 중소 규모 데이터베이스, 개발 및 테스트 환경, 부팅 볼륨을 포함한 광범위한 워크로드에 적합합니다.

- Provisioned IOPS SSD 볼륨

프로비저닝된 IOPS(SSD) 볼륨은 일관되고 대기 시간이 짧은 스토리지를 제공하며 대규모 관계형 또는 NoSQL 데이터베이스와 같은 I/O 집약적 애플리케이션을 위해 설계되었습니다. 마그네틱 볼륨은 모든 EBS 볼륨 유형 중 기가바이트당 비용이 가장 저렴합니다.

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

금융 데이터를 S3 버킷에 저장하는 온라인 주식 거래 애플리케이션에는 매월 오래된 데이터를 Glacier로 이동하는 수명 주기 정책이 있습니다. 언제든지 갑작스러운 감사가 발생할 수 있는 엄격한 규정 준수 요구 사항이 있으며 모든 상황에서 15분 이내에 필요한 데이터를 검색할 수 있어야 합니다. 관리자는 필요할 때 검색 용량을 사용할 수 있고 최대 150MB/s의 검색 처리량을 처리해야 한다고 지시했습니다.

위의 요구 사항을 충족하려면 다음 중 무엇을 해야 합니까? (2개 선택)

프로비저닝된 검색 용량을 구매합니다.

신속 검색을 사용하여 재무 데이터에 액세스합니다.

Amazon S3 Glacier (S3 Glacier) 는 저렴한 데이터 보관 및 장기 백업을 위한 안전하고 내구성 있는 서비스입니다.

S3 Glacier를 사용하면 몇 달, 몇 년 또는 수십 년 동안 데이터를 비용 효율적으로 저장할 수 있습니다. S3 Glacier 는 스토리지 운영 및 크기 조정하는 데 따른 관리 부담을 줄여서 용량 계획AWS, 하드웨어 프로비저닝, 데이터 복제, 하드웨어 장애 감지 및 복구 또는 시간이 많이 걸리는 하드웨어 마이그레이션에 대해 걱정할 필요가 없게 합니다.

Amazon Simple Storage Service (Amazon S3) 는 Amazon S3 Glacier 아카이브 스토리지 클래스도 세 개 제공합니다. 이러한 스토리지 클래스는 다양한 액세스 패턴 및 스토리지 기간에 맞게 설계되었습니다. 이들 스토리지 클래스는 다음과 같은 차이가 있습니다.

- S3 Glacier Instant Retrieval - 거의 액세스하지 않고 밀리초 단위로 검색해야 하는 데이터를 아카이브하는 데 사용합니다.

- S3 Glacier Flexible Retrieval (이전 S3 Glacier 스토리지 클래스) — 분 단위로 데이터의 일부를 검색해야 하는 아카이브에 사용합니다. S3 Glacier Flexible Retrieval 스토리지 클래스에 저장된 데이터는 신속 검색을 사용하여 최소 1~5분 이내에 액세스할 수 있습니다. 최대 5~12시간 내에 무료 대량 검색을 요청할 수 있습니다.

- S3 Glacier Deep Archive — 거의 액세스할 필요가 없는 데이터를 보관할 때 사용합니다. S3 Glacier Deep Archive 스토리지 클래스에 저장된 데이터의 기본 검색 시간은 12시간입니다.

아카이브를 가져오는 작업을 시작할 때는 액세스 시간과 비용 요건을 기준으로 다음 가져오기 옵션 중 한 가지를 지정할 수 있습니다.

1. 신속- 일부 아카이브의 하위 집합을 긴급하게 요청해야 하는 경우 S3 Glacier Flexible Retrieval 스토리지 클래스 또는 S3 Intelligent-Tiering Archive Access 계층에 저장된 데이터에 신속하게 액세스할 수 있습니다. 매우 큰 아카이브 (250MB 이상) 를 제외한 모든 경우, 신속 검색을 사용하여 액세스된 데이터는 일반적으로 1~5분 안에 사용할 수 있게 됩니다. 프로비저닝된 용량을 통해 필요할 때 신속 검색에 대한 검색 용량이 보장됩니다.

2. 표준— 표준 가져오기를 사용하면 몇 시간 내에 모든 아카이브에 액세스할 수 있습니다. 표준 검색은 보통 3-5시간 안에 완료됩니다. 검색 요청 시 검색 옵션을 지정하지 않을 경우 기본 옵션이 됩니다.

3. 대량- 벌크 가져오기는 가장 저렴한 S3 Glacier 검색 옵션으로, 페타바이트 단위의 대용량 데이터도 저렴하게 1일 동안 가져올 때 사용할 수 있습니다. 벌크 검색은 보통 5~12시간 안에 완료됩니다.

프로비저닝된 용량을 통해 필요할 때 신속 검색에 대한 검색 용량이 보장됩니다. 각 용량 단위로 5분마다 신속 검색을 최소 3회 수행할 수 있고, 최대 150MBps (초당 메가바이트) 의 검색 처리량이 제공됩니다.

워크로드에 몇 분 내로 데이터의 하위 집합에 대한 매우 안전하고 예측 가능한 액세스가 필요한 경우 프로비저닝된 검색 용량을 구입하는 것이 좋습니다. 프로비저닝된 검색 용량이 없더라도 비정상적으로 수요가 높지 않은 경우를 제외하면 Expedited 검색은 일반적으로 허용됩니다. 하지만 모든 상황에서 신속 검색에 액세스해야 하는 경우 프로비저닝된 검색 용량을 구매해야 합니다.

회사에 인사 부서용 VPC가 있고 재무 부서용으로 서로 다른 AWS 리전에 위치한 또 다른 VPC가 있습니다. Solutions Architect는 재무 부서가 인사 부서에 있는 모든 리소스에 액세스할 수 있도록 아키텍처를 재설계해야 하며 그 반대의 경우도 마찬가지입니다. 또한 IPS(침입 방지 시스템)는 활성 트래픽 흐름 검사와 취약점 악용을 차단하기 위해 통합되어야 합니다.

위의 요구 사항을 충족하기 위해 Solutions Architect가 설정해야 하는 AWS의 네트워크 아키텍처 설계는 무엇입니까?

AWS Transit Gateway를 시작하고 VPC 연결을 추가하여 모든 부서를 연결합니다. VPC 간에 이동하는 애플리케이션 트래픽을 보호하도록 AWS 네트워크 방화벽을 설정합니다.

Transit Gateway는 가상 사설 클라우드(VPC)와 온프레미스 네트워크를 상호 연결하는 데 사용할 수 있는 네트워크 전송 허브입니다. 클라우드 인프라가 전 세계적으로 확장됨에 따라 리전 간 피어링은 AWS 글로벌 인프라를 사용하여 전송 게이트웨이를 함께 연결합니다. 데이터는 자동으로 암호화되며 퍼블릭 인터넷을 통해 이동하지 않습니다.

Transit Gateway 연결은 패킷의 소스이자 대상입니다. 다음 리소스를 Transit Gateway에 연결할 수 있습니다.

- 하나 이상의 VPC

- 하나 이상의 VPN 연결

- 하나 이상의 AWS Direct Connect 게이트웨이

- 하나 이상의 Transit Gateway Connect 첨부 파일

- 하나 이상의 전송 게이트웨이 피어링 연결

AWS Transit Gateway는 VPC 서브넷 내에 탄력적 네트워크 인터페이스를 배포합니다. 그러면 Transit Gateway에서 이를 사용하여 선택한 서브넷과 주고받는 트래픽을 라우팅합니다. 각 가용 영역에 대해 하나 이상의 서브넷이 있어야 하며, 그러면 트래픽이 해당 영역의 모든 서브넷에 있는 리소스에 도달할 수 있습니다. 연결을 생성하는 동안 특정 가용 영역 내의 리소스는 동일한 영역 내에서 서브넷이 활성화된 경우에만 전송 게이트웨이에 도달할 수 있습니다. 서브넷 라우팅 테이블에 전송 게이트웨이에 대한 경로가 포함된 경우 전송 게이트웨이에 동일한 가용 영역의 서브넷에 연결이 있는 경우에만 트래픽이 전송 게이트웨이로 전달됩니다.

리전 내 피어링 연결이 지원됩니다. 리전마다 다른 Transit Gateway가 있을 수 있습니다.

AWS 네트워크 방화벽은 모든 Amazon Virtual Private Cloud(VPC)에 필수적인 네트워크 보호를 쉽게 배포할 수 있는 관리형 서비스입니다. 서비스는 클릭 몇 번으로 설정하고 네트워크 트래픽에 따라 자동으로 확장할 수 있으므로 인프라 배포 및 관리에 대해 걱정할 필요가 없습니다. AWS 네트워크 방화벽의 유연한 규칙 엔진을 사용하면 아웃바운드 SMB(서버 메시지 차단) 요청을 차단하여 악의적인 활동의 확산을 방지하는 등 네트워크 트래픽을 세밀하게 제어할 수 있는 방화벽 규칙을 정의할 수 있습니다.

AWS 네트워크 방화벽에는 일반적인 네트워크 위협으로부터 보호하는 기능이 포함되어 있습니다. AWS 네트워크 방화벽의 상태 저장 방화벽은 연결 추적 및 프로토콜 식별과 같은 트래픽 흐름의 컨텍스트를 통합하여 VPC가 무단 프로토콜을 사용하여 도메인에 액세스하는 것을 방지하는 등의 정책을 시행할 수 있습니다. AWS Network Firewall의 IPS(침입 방지 시스템)는 활성 트래픽 흐름 검사를 제공하므로 서명 기반 탐지를 사용하여 취약점 악용을 식별하고 차단할 수 있습니다. AWS 네트워크 방화벽은 알려진 잘못된 URL에 대한 트래픽을 중지하고 정규화된 도메인 이름을 모니터링할 수 있는 웹 필터링도 제공합니다.

회사의 VPC에 암호화되지 않은 EBS 스냅샷이 여러 개 있습니다. Solutions Architect는 암호화되지 않은 스냅샷에서 복원된 모든 새 EBS 볼륨이 자동으로 암호화되도록 해야 합니다.

이 요구 사항을 달성하려면 어떻게 해야 합니까?

AWS 리전에 대해 기본적으로 EBS 암호화 기능을 활성화합니다.

사용자의 AWS 계정을 구성하여 생성하는 새 EBS 볼륨 및 스냅샷 사본의 암호화를 적용할 수 있습니다. 예를 들어 Amazon EBS는 인스턴스 시작 시 생성된 EBS 볼륨과 암호화되지 않은 스냅샷에서 복사하는 스냅샷을 암호화합니다.

기본적으로 암호화는 기존 EBS 볼륨이나 스냅샷에 영향을 미치지 않습니다.

고려 사항

- 암호화 기본 제공은 리전별 설정입니다. 특정 기능에 대해 이 기능을 활성화하면 해당 리전의 개별 볼륨 또는 스냅샷에 대해 비활성화할 수 없습니다.

- 암호화 기본 제공을 활성화하면 인스턴스 유형이 EBS 암호화를 지원할 때에만 인스턴스를 시작할 수 있습니다. 자세한 내용은 지원되는 인스턴스 유형 섹션을 참조하세요.

- 스냅샷을 복사하고 새 KMS 키로 암호화하면 전체(비증분) 복사본이 생성됩니다. 이로 인해 추가 스토리지 비용이 발생합니다.

- AWS Server Migration Service(SMS)을 사용하여 서버를 마이그레이션할 때 기본적으로 암호화를 켜지 마세요. 기본적으로 암호화가 이미 설정되어 있고 델타 복제 오류가 발생하는 경우 이 기능을 해제하세요. 대신 복제 작업을 생성할 때 AMI 암호화를 활성화하세요.

암호화되지 않은 기존의 볼륨이나 스냅샷은 직접 암호화할 수 없습니다. 그러나 암호화되지 않은 볼륨이나 스냅샷에서 암호화된 볼륨 또는 스냅샷을 생성할 수 있습니다. 암호화를 기본적으로 활성화한 경우 Amazon EBS는 EBS 암호화에 대한 사용자의 기본 KMS 키를 사용하여 새로운 볼륨 또는 스냅샷을 자동으로 암호화합니다. 또는 개별 볼륨이나 스냅샷을 생성할 때 Amazon EBS 암호화의 기본 KMS 키나 대칭 고객 관리형 암호화 키를 사용하여 암호화를 사용 설정할 수 있습니다.

회사는 모든 AWS 리소스의 AWS API 호출 기록을 기록하여 클라우드 아키텍처의 운영 문제를 해결합니다. Solutions Architect는 AWS 리소스의 생성, 수정 및 삭제를 포함하여 환경의 리소스에 대한 가장 최근 변경 사항을 신속하게 식별할 수 있는 솔루션을 구현해야 합니다. 요구 사항 중 하나는 보안 문제를 방지하기 위해 생성된 로그 파일을 암호화해야 한다는 것입니다.

다음 중 암호화 구현에 가장 적합한 접근 방식은 무엇입니까?

기본 설정으로 CloudTrail 사용합니다.

CloudTrail을 계정 생성 시 AWS 계정에서 사용할 수 있습니다. 활동이 AWS 계정에서 이루어지면 해당 활동이 CloudTrail 이벤트에 기록됩니다. CloudTrail 콘솔에서 [이벤트 기록(Event history)]으로 이동해서 손쉽게 이벤트를 확인할 수 있습니다.

이벤트 기록을 통해 AWS 계정에서 이루어진 지난 90일간의 활동을 확인, 검색 및 다운로드할 수 있습니다. 또한 CloudTrail 추적을 생성하여 AWS 리소스의 변경 사항을 보관 및 분석하고 이에 대응할 수 있습니다. 추적은 지정한 Amazon S3 버킷에 이벤트를 전달할 수 있게 하는 구성입니다. 또한 Amazon CloudWatch Logs 및 Amazon EventBridge를 사용하여 추적의 이벤트를 전달하고 분석할 수도 있습니다. CloudTrail 콘솔, AWS CLI 또는 CloudTrail API를 사용하여 추적을 생성할 수 있습니다.

기본적으로 CloudTrai 이벤트 로그 파일은 Amazon S3 서버 측 암호화(SSE)를 사용하여 암호화합니다. 선택에 따라 AWS Key Management Service(AWS KMS) 키를 통해 로그 파일을 암호화할 수도 있습니다. 원하는 만큼 오래 버킷에 로그 파일을 저장할 수 있습니다. 또한 Amazon S3 수명 주기 규칙을 정의하여 로그 파일을 자동으로 보관하거나 삭제할 수도 있습니다. 로그 파일 전송 및 검증에 대한 알림을 원할 경우에는 Amazon SNS 알림을 설정할 수 있습니다.

회사는 트래픽이 특정 서버 리소스로 라우팅되는 지리적 영역의 크기를 동적으로 변경할 수 있는 기능을 원합니다.

이 기능을 달성하는 데 도움이 될 수 있는 Route 53의 기능은 무엇입니까?

지리 근접 라우팅 정책

Amazon Route 53은 지리 근접 라우팅을 사용하여 사용자와 리소스의 지리적 위치를 기반으로 트래픽을 리소스로 라우팅할 수 있습니다. 또는 바이어스라고 하는 값을 지정하여 해당 리소스로 라우팅하는 트래픽의 양을 늘리거나 줄일 수도 있습니다. 바이어스는 트래픽이 리소스로 라우팅되는 지리적 리전의 크기를 확장하거나 축소합니다.

지리 근접 라우팅을 사용하려면 Route 53 트래픽 흐름(traffic flow)을 사용해야 합니다. 리소스에 대한 지리 근접 규칙을 생성하고 각 규칙에 대해 다음 값 중 하나를 지정합니다.

- AWS 리소스를 사용하는 경우 리소스를 생성한 AWS 리전

- 비 AWS 리소스를 사용하는 경우 리소스의 위도와 경도

Route 53이 트래픽을 리소스로 라우팅하는 지리적 리전의 크기를 선택적으로 변경하려면 바이어스에 대해 해당하는 값을 지정합니다.

- Route 53이 트래픽을 리소스로 라우팅하는 지리적 리전의 크기를 확장하려면 바이어스에 대해 1~99의 양의 정수를 지정합니다. Route 53은 인접 리전의 크기를 축소합니다.

- Route 53이 트래픽을 리소스로 라우팅하는 지리적 리전의 크기를 확장합니다축소하려면 바이어스에 대해 1~99의 음의 바이어스를 지정합니다. Route 53은 인접 리전의 크기를 .

레코드를 생성할 때 라우팅 정책을 선택하게 되는데, 이는 Amazon Route 53이 쿼리에 응답하는 방식을 결정합니다.

- 단순 라우팅 정책(Simple routing policy) - 도메인에 대해 특정 기능을 수행하는 하나의 리소스만 있는 경우(예: example.com 웹 사이트의 콘텐츠를 제공하는 하나의 웹 서버)에 사용합니다. 단순 라우팅을 사용하여 프라이빗 호스팅 영역에서 레코드를 생성할 수 있습니다.

- 장애 조치 라우팅 정책(Failover routing policy) - 액티브-패시브 장애 조치를 구성하려는 경우에 사용합니다. 장애 조치 라우팅을 사용하여 프라이빗 호스팅 영역에서 레코드를 생성할 수 있습니다.

- 지리 위치 라우팅 정책(Geolocation routing policy) - 사용자의 위치에 기반하여 트래픽을 라우팅하려는 경우에 사용합니다. 지리적 위치 라우팅을 사용하여 프라이빗 호스팅 영역에서 레코드를 생성할 수 있습니다.

- 지리 근접 라우팅 정책(Geoproximity routing policy) - 리소스의 위치를 기반으로 트래픽을 라우팅하고 필요에 따라 한 위치의 리소스에서 다른 위치의 리소스로 트래픽을 보내려는 경우에 사용합니다.

- 지연 시간 라우팅 정책 - 여러 AWS 리전에 리소스가 있고 최상의 지연 시간을 제공하는 리전으로 트래픽을 라우팅하려는 경우에 사용합니다. 지연 시간 라우팅을 사용하여 프라이빗 호스팅 영역에서 레코드를 생성할 수 있습니다.

- IP 기반 라우팅 정책 - 사용자의 위치에 기반하여 트래픽을 라우팅하고 트래픽이 시작되는 IP 주소가 있는 경우에 사용합니다.

- 다중 응답 라우팅 정책(Multivalue answer routing policy) - Route 53이 DNS 쿼리에 무작위로 선택된 최대 8개의 정상 레코드로 응답하게 하려는 경우에 사용합니다. 다중 값 응답 라우팅을 사용하여 프라이빗 호스팅 영역에서 레코드를 생성할 수 있습니다.

- 가중치 기반 라우팅 정책(Weighted routing policy) - 사용자가 지정하는 비율에 따라 여러 리소스로 트래픽을 라우팅하려는 경우에 사용합니다. 가중치 라우팅을 사용하여 프라이빗 호스팅 영역에서 레코드를 생성할 수 있습니다.

회사에 온디맨드 EC2 인스턴스의 Auto Scaling 그룹에서 호스팅되는 CRM 애플리케이션이 있습니다. 애플리케이션은 오전 9시부터 오후 6시까지 근무 시간에 광범위하게 사용됩니다. 애플리케이션 사용자는 근무가 시작하는 시간 동안 응용 프로그램의 성능이 느리지만 몇 시간 후에는 정상적으로 작동한다고 불평하고 있습니다.

애플리케이션이 근무 시작 시간에 제대로 작동하도록 하려면 다음 중 무엇을 할 수 있습니까?

근무 시작 시간 전에 새 인스턴스를 시작하도록 Auto Scaling 그룹에 대한 예약된 조정 정책을 구성합니다.

예약된 조정을 사용하면 예측 가능한 부하 변화에 따라 조정 일정을 설정할 수 있습니다. 예를 들어, 매주 수요일에 웹 애플리케이션에 대한 트래픽이 증가하고 목요일까지 높은 상태로 유지되다가 금요일에 줄어들기 시작한다고 가정해 보겠습니다. Amazon EC2 Auto Scaling이 수요일에 용량을 늘리고 금요일에 용량을 줄이도록 일정을 구성할 수 있습니다.

예약된 조정을 사용하려면 예약된 작업을 생성합니다. 예약된 작업이 시간 및 날짜 함수에 따라 자동으로 수행됩니다. 예약된 작업을 생성할 때 크기 조정 활동이 발생할 시간, 조정 작업에 대한 원하는 용량, 최소 및 최대 용량을 새로 지정합니다. 규모를 한 번만 조정하거나 반복되는 일정으로 조정하도록 예약된 작업을 생성할 수 있습니다.

예약된 조정 구성하면 애플리케이션이 가장 많이 사용되는 시간전에 인스턴스가 이미 확장되어 사용 준비되어 있는지 확인할 수 있습니다.

Solutions Architect는 HTML, CSS 및 일부 Javascript 파일로 구성된 웹사이트를 호스팅하도록 지시받습니다. 웹 페이지에는 여러 고해상도 이미지가 표시됩니다. 웹사이트는 최적의 로딩 시간을 가져야 하고 높은 요청 비율에 응답할 수 있어야 합니다.

다음 아키텍처 중 가장 비용 효율적이고 가장 빠른 로딩 경험을 제공할 수 있는 아키텍처는 무엇입니까?

단일 버킷에 HTML, CSS, Javascript 및 이미지를 업로드합니다. 그런 다음 웹 사이트 호스팅을 활성화합니다. CloudFront 배포를 생성하고 S3 웹 사이트 엔드포인트에서 도메인을 가리킵니다.

Amazon Simple Storage Service(Amazon S3)는 업계 최고 수준의 확장성, 데이터 가용성, 보안 및 성능을 제공하는 객체 스토리지 서비스입니다. 고객은 규모와 업종에 관계없이 원히는 양의 데이터를 저장하고 보호하여 데이터 레이크, 클라우드 네이티브 애플리케이션 및 모바일 앱과 같은 거의 모든 사용 사례를 지원할 수 있습니다. 비용 효율적인 스토리지 클래스와 사용이 쉬운 관리 기능을 통해 비용을 최적화하고, 데이터를 정리하고, 세분화된 액세스 제어를 구성하여 특정 비즈니스, 조직 및 규정 준수 요구 사항을 충족할 수 있습니다.

Amazon CloudFront는 비즈니스 및 웹 애플리케이션 개발자에게 짧은 지연 시간과 빠른 데이터 전송 속도를 사용하여 콘텐츠를 간편하고 비용 효율적으로 배포할 방법을 제공합니다. 모든 AWS 인프라 서비스와 마찬가지로 Amazon CloudFront는 장기 약정 또는 최소 요금이 필요 없고 사용량에 따라 지불하는 셀프 서비스입니다. CloudFront를 사용하면 엣지 로케이션의 글로벌 네트워크를 사용해 최종 사용자에게 파일이 전송됩니다.

Amazon S3을 사용하여 정적 웹 사이트를 호스팅할 수 있습니다. 정적 웹 사이트에서 개별 웹 페이지는 정적 콘텐츠를 포함합니다. 클라이언트 측 스크립트를 포함할 수도 있습니다.

이와는 대조적으로, 동적 웹 사이트는 PHP, JSP 또는 ASP.NET 등 서버 측 스크립트를 포함한 서버 측 처리에 의존합니다. Amazon S3은 서버 측 스크립팅을 지원하지 않지만 AWS에는 동적 웹 사이트를 호스팅하기 위한 다른 리소스가 있습니다.

시나리오에서는 정적 콘텐츠만 다루므로 S3의 웹 호스팅 기능을 활용할 수 있습니다. 그런 다음 CloudFront와 통합하여 아키텍처를 더욱 개선할 수 있습니다. 이렇게 하면 사용자는 처음부터 구축한 웹 서버에서 호스팅하는 것보다 웹 페이지와 이미지를 더 빠르게 로드할 수 있습니다.

회사는 AWS를 사용하여 AI 개발 및 배포 프로젝트를 진행하고 있습니다. 이 솔루션은 딥 러닝 프레임워크를 지원할 뿐만 아니라 방대한 양의 데이터를 수집, 저장 및 관리하기 위해 고성능 컴퓨팅(HPC)이 필요합니다. 사용할 Linux EC2 인스턴스는 클라우드 기반 HPC 시스템에서 전통적으로 사용되는 TCP 전송보다 지연 시간이 짧고 처리량이 높아야 합니다. 또한 인스턴스 간 통신의 성능을 향상시켜야 하며 HPC가 네트워크 인터페이스 하드웨어와 직접 통신하여 대기 시간이 짧고 안정적인 전송 기능을 제공할 수 있도록 하는 OS 우회 기능을 포함해야 합니다.

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

각 Amazon EC2 인스턴스에 EFA(Elastic Fabric Adapter)를 연결하여 HPC(고성능 컴퓨팅)를 가속화합니다.

Elastic Fabric Adapter(EFA)는 Amazon EC2 인스턴스에 연결하여 고성능 컴퓨팅(HPC) 및 기계 학습 애플리케이션의 속도를 높일 수 있는 네트워크 디바이스입니다. EFA를 사용하면 AWS 클라우드가 제공하는 확장성, 유연성 및 탄력성으로 온프레미스 HPC 클러스터의 애플리케이션 성능을 달성할 수 있습니다.

EFA는 전통적으로 클라우드 기반 HPC 시스템에서 사용하는 TCP 전송보다 지연율이 낮고 일정하며 더 높은 처리량을 제공합니다. 또한 대규모 HPC 및 기계 학습 애플리케이션에서 중요한 인스턴스 간 통신 성능을 확장합니다. 이는 기존 AWS 네트워크 인프라에서 작업하도록 최적화되어 애플리케이션 요구량에 따라 크기를 변경합니다.

EFA는 Libfabric 1.7.0 이상과 통합되며 HPC 애플리케이션을 위한 Open MPI 3.1.3 이상 및 인텔 MPI 2019 업데이트 5와 기계 학습 애플리케이션을 위한 NCCL(Nvidia Collective Communications Library)을 지원합니다.

EFA는 추가 기능이 있는 ENA(Elastic Network Adapter)입니다. 따라서 추가적인 OS 우회 기능을 포함한 모든 ENA의 기능을 제공합니다. OS 우회는 HPC 및 기계 학습 애플리케이션이 네트워크 인터페이스 하드웨어와 직접 통신하도록 하는 액세스 모델로서 낮은 지연율과 신뢰성 높은 전송 기능을 제공합니다.

Elastic Network Adapter(ENA)는 VPC 네트워킹을 지원하는 데 필요한 기존 IP 네트워킹 기능을 제공합니다. EFA는 ENA와 동일한 모든 기존 IP 네트워킹 기능을 제공하는 것에 더해 OS 바이패스 기능도 지원합니다. OS 우회는 HPC 및 기계 학습 애플리케이션이 운영 체제 커널을 우회하여 EFA 디바이스와 직접 통신할 수 있도록 합니다.

Amazon EC2는 ENA(Elastic Network Adapter)를 통해 향상된 네트워킹을 제공합니다. 향상된 네트워킹을 사용하려면 필수 ENA 모듈을 설치하고 ENA 지원을 활성화해야 합니다.

로드 밸런서 뒤의 Amazon ECS 클러스터에서 실행되는 Docker 애플리케이션은 DynamoDB를 많이 사용하고 있습니다. 워크로드를 균등하게 분배하고 프로비저닝된 처리량을 효율적으로 사용하여 데이터베이스 성능을 개선하도록 지시합니다.

다음 중 DynamoDB 테이블에 구현하기 위해 고려하는 것은 무엇입니까?

각 항목에 대해 많은 수의 고유 값이 있는 파티션 키를 사용합니다.

테이블 기본 키의 파티션 키 부분은 테이블의 데이터가 저장되는 논리적 파티션을 결정합니다. 이는 기본 물리적 파티션에 영향을 줍니다. I/O 요청을 고르게 분산시키지 않는 파티션 키 설계는 '핫' 파티션을 발생시킬 수 있으며, 이는 제한을 발생시키고 프로비저닝된 I/O 용량을 비효율적으로 사용하게 되는 문제를 초래합니다.

테이블의 프로비저닝된 처리량의 최적 사용량은 개별 항목의 워크로드 패턴과 파티션 키 설계가 결정합니다. 이는 모든 파티션 키 값에 액세스하여 효율적인 처리량 수준을 달성해야 한다는 의미는 아닙니다. 또한 액세스된 파티션 키 값의 백분율이 높아야 한다는 의미도 아닙니다. 워크로드가 액세스 하는 고유 파티션 키 값이 많을 수록 요청이 여러 파티션 공간으로 더 많이 분산된다는 의미입니다. 일반적으로 총 파티션 키 값에 액세스한 파티션 키 값의 비율이 증가할수록 처리량을 보다 효율적으로 활용할 수 있습니다.

단일 테이블에 파티션 키 값의 수가 매우 적은 경우, 쓰기 작업을 더 많은 고유 파티션 값에 배포하는 것이 좋습니다. 다시 말해 전반적인 성능 저하를 야기하는 하나의 ‘핫’한(자주 요청되는) 파티션 키 값이 발생하지 않도록 기본 키 요소를 구성합니다.

복합 기본 키가 하나만 있는 테이블을 예로 들어 보겠습니다. 파티션 키는 항목의 생성 날짜를 나타내며 가장 가까운 날로 반올림됩니다. 정렬 키는 항목 식별자입니다. 지정된 날, 예를 들면 2014-07-09에 모든 새 항목이 동일한 파티션-키 값(및 상응하는 물리적 파티션)에 작성됩니다.

테이블이 단일 파티션에 꼭 맞으며(시간 경과에 따른 데이터 증가 고려) 애플리케이션의 읽기 및 쓰기 처리량 요구 사항이 단일 파티션의 읽기 및 쓰기 능력을 초과하지 않으면, 애플리케이션에 파티셔닝으로 인한 예상치 않은 제한(병목) 현상이 발생하지 않습니다.

Solutions Architect는 대규모 IT 컨설팅 회사에서 일하고 있습니다. 고객 중 한 명이 AWS에서 PDF, Word 문서, 고해상도 이미지 등과 같은 정적 콘텐츠를 호스팅하기 위한 내구성 있는 스토리지 서비스가 필요한 파일 공유 웹 애플리케이션을 시작하고 있습니다.

이 요구 사항을 충족하기 위해 어떤 유형의 스토리지 서비스를 사용해야 합니까?

Amazon S3

Amazon S3는 어디서나 원하는 양의 데이터를 저장하고 검색할 수 있도록 구축된 객체 스토리지입니다. 업계 최고 수준의 내구성, 가용성, 성능, 보안 및 거의 무제한의 확장성을 아주 저렴한 요금으로 제공하는 단순한 스토리지 서비스입니다.

Amazon S3는 언제든지 어디서나 원하는 양의 데이터를 저장하고 검색하는 데 사용할 수 있는 간편한 웹 서비스 인터페이스를 제공합니다. 이 서비스를 사용하면 클라우드 네이티브 스토리지를 사용하는 애플리케이션을 손쉽게 구축할 수 있습니다. Amazon S3는 확장성이 뛰어나고 사용한 만큼만 비용을 지불하므로 작은 규모에서 시작해 성능 또는 안정성 저하 없이 원하는 대로 애플리케이션을 확장할 수 있습니다.

또한, Amazon S3는 뛰어난 유연성을 제공하도록 설계되었습니다. 원하는 형식의 데이터를 원하는 만큼 저장하고, 동일한 데이터를 수백만 번 읽거나 비상 재해 복구 용도로만 사용하고, 간단한 FTP 애플리케이션 또는 Amazon.com 소매 웹 사이트와 같은 복잡한 웹 애플리케이션을 구축할 수 있습니다. Amazon S3를 사용하는 개발자는 데이터 저장 방법을 고민하기보다는 혁신에 집중할 수 있습니다.

이 시나리오에는 정적 콘텐츠를 위한 내구성 있는 저장소가 필요합니다. 이 두 키워드는 S3의 대표적인 특징을 나타냅니다.

회사는 최근에 서비스 워크로드를 처리하기 위해 새로운 부서를 만들었습니다. IT 팀은 이 새 부서에서 생성된 리소스를 격리하기 위해 사용자 지정 VPC를 생성하도록 요청받았습니다. 그들은 퍼블릭 서브넷과 인터넷 게이트웨이(IGW)를 설정했습니다. 그러나 새로 생성된 VPC에서 시작된 탄력적 IP로 Amazon EC2 인스턴스를 ping할 수 없습니다.

이 시나리오를 어떻게 해결할 수 있습니까? (2개 선택)

보안 그룹이 소스에서 ping을 허용하는지 확인합니다.

경로 테이블이 IGW로 구성되어 있는지 확인합니다.

IGW(인터넷 게이트웨이)는 VPC의 인스턴스와 인터넷 간의 통신을 허용하는 수평 확장, 중복 및 고가용성 VPC 구성 요소입니다. 인터넷 게이트웨이는 인터넷 라우팅 가능한 트래픽에 대한 VPC 라우팅 테이블의 대상을 제공하고 퍼블릭 IPv4 주소가 할당된 인스턴스에 대해 NAT(네트워크 주소 변환)를 수행하는 두 가지 용도로 사용됩니다. 인터넷 게이트웨이는 IPv4 및 IPv6 트래픽을 지원합니다.

VPC의 서브넷에 있는 인스턴스에 대해 인터넷 액세스를 활성화하려면 다음을 수행해야 합니다.

1. 인터넷 게이트웨이를 VPC에 연결합니다.

2. 인터넷 바인딩 트래픽을 인터넷 게이트웨이로 보내는 서브넷의 라우팅 테이블에 경로를 추가합니다.

3. 서브넷의 인스턴스에 전역적으로 고유한 IP 주소가 있는지 확인합니다.

4. 네트워크 액세스 제어 목록과 보안 그룹 규칙이 관련 트래픽이 인스턴스로 들어오고 나가는 것을 허용하는지 확인합니다.

라우팅 테이블에는 서브넷 또는 게이트웨이의 네트워크 트래픽이 전달되는 위치를 결정하는 데 사용되는 라우팅이라는 규칙 집합이 포함되어 있습니다. IGW를 생성한 후 라우팅 테이블이 업데이트되었는지 확인합니다. 또한 보안 그룹이 ping 요청에 대해 ICMP 프로토콜을 허용하는지 확인합니다.

보안 그룹은 하나 이상의 인스턴스에 대한 트래픽을 제어하는 가상 방화벽 역할을 합니다. 인스턴스를 시작할 때 하나 이상의 보안 그룹을 지정할 수 있습니다. 그렇지 않으면 AWS는 기본 보안 그룹을 사용합니다. 연결된 인스턴스와의 트래픽을 허용하는 규칙을 각 보안 그룹에 추가할 수 있습니다. 보안 그룹에 대한 규칙은 언제든지 수정할 수 있습니다. 새 규칙은 보안 그룹과 연결된 모든 인스턴스에 자동으로 적용됩니다. 트래픽이 인스턴스에 도달하도록 허용할지 여부를 결정하기 위해 인스턴스와 연결된 모든 보안 그룹의 모든 규칙이 평가됩니다.

다음은 보안 그룹 규칙의 특성입니다.

1. 기본적으로 보안 그룹은 모든 아웃바운드 트래픽을 허용합니다.

2. 보안 그룹 규칙은 항상 허용됩니다. 액세스를 거부하는 규칙을 만들 수 없습니다.

3. 보안 그룹은 스테이트풀(Stateful)입니다.

회사는 재무, 인사, 엔지니어링 및 기타 여러 부서와 같은 다양한 부서를 분리하기 위해 AWS에 여러 계정을 보유하고 있습니다. 회사의 보안 정책을 준수하기 위해 서비스 및 작업에 대한 특정 액세스를 적절하게 제어해야 한다는 요구 사항이 있습니다.

회사의 다중 계정 AWS 환경을 설정하는 가장 적합한 방법은 무엇입니까?

AWS Organizations 및 서비스 제어 정책을 사용하여 각 계정의 서비스를 제어합니다.

AWS Organizations는 AWS의 워크로드가 확장됨에 따라 환경을 중앙에서 관리하는 데 도움이 됩니다. 성장하는 스타트업이든, 대기업이든 관계없이, Organizations를 활용하면 새 계정을 생성하고 리소스를 할당하고, 모든 계정에 대해 단일 결제 방법을 설정하여 결제 과정을 간소화하고, 계정 그룹을 생성하여 워크플로를 구성하며 거버넌스를 위해 이러한 그룹에 정책을 적용할 수 있습니다. 또한, AWS Organizations는 다른 AWS 서비스에 통합되므로 중앙 구성, 보안 메커니즘 및 조직 내 계정에 걸쳐 공유되는 리소스를 정의할 수 있습니다.

AWS Organizations에서는 다음과 같은 기능을 수행할 수 있습니다.

- AWS 계정 생성 및 관리를 자동화하고, AWS CloudFormation Stacksets를 통해 리소스를 프로비저닝

- AWS 보안 서비스의 관리 및 정책을 통해 안전한 환경 유지

- AWS 서비스, 리소스 및 리전 액세스 관리

- 여러 AWS 계정에 대한 정책을 중앙에서 관리

- 규정 준수를 위한 환경 감사

- 통합 결제를 통해 비용 확인하고 관리

- 여러 계정에 걸쳐 AWS 서비스 구성

서비스 제어 정책(SCP)을 사용하면 조직의 계정 내 보안 주체(계정 루트, IAM 사용자 및 IAM 역할)에 액세스할 수 있는 AWS 서비스 작업을 제어할 수 있습니다. 계정의 보안 주체에 리소스에 대한 액세스 권한을 부여하기 위해서는 SCP가 필요하긴 하지만, 리소스에 액세스할 수 있는 계정의 보안 주체를 결정하는 유일한 제어 항목은 아닙니다. SCP가 연결되어 있는 계정 내 보안 주체의 실질적인 권한은 SCP에서 명시적으로 허용하는 권한과 해당 보안 주체에 연결된 권한에서 명시적으로 허용하는 권한의 교집합입니다. 예를 들어, 계정에 적용된 SCP에서 허용하는 유일한 작업이 Amazon EC2 작업이고, 동일한 AWS 계정 내 보안 주체의 권한이 EC2 작업 및 Amazon S3 작업을 모두 허용하는 경우, 보안 주체는 EC2 작업에만 액세스할 수 있습니다.

멤버 계정의 보안 주체(멤버 계정의 루트 사용자 포함)는 해당 계정에 적용된 SCP를 제거하거나 변경할 수 없습니다.

조직은 공간이 거의 없는 온프레미스 데이터 센터에 다양한 회사의 재무 기록을 저장하고 관리합니다. 경영진은 기존 기록을 모두 클라우드 스토리지 서비스로 옮기기로 결정했습니다. 미래의 모든 재무 기록도 클라우드에 저장됩니다. 추가 보안을 위해 모든 기록이 삭제되거나 덮어쓰여지지 않도록 해야 합니다.

위의 요구 사항을 충족하려면 다음 중 무엇을 해야 합니까?

AWS DataSync를 사용하여 데이터를 이동합니다. 모든 데이터를 Amazon S3에 저장하고 객체 잠금을 활성화합니다.

AWS DataSync는 AWS로의 데이터 마이그레이션과 온프레미스 스토리지, 엣지 로케이션, 다른 클라우드 및 AWS 스토리지 간의 데이터 이동을 간소화 및 가속화하는 온라인 데이터 이동 및 검색 서비스입니다.

AWS DataSync를 사용하면 데이터를 안전하고 빠르게 검색하고 이동할 수 있습니다. DataSync Discovery(평가판)를 사용하면 온프레미스 스토리지 사용률을 더 잘 이해하고 권장 사항을 바탕으로 비용 예측에 필요한 정보를 얻고 AWS로의 마이그레이션을 계획할 수 있습니다. 데이터 이동의 경우 DataSync를 사용하면 오픈 소스 도구를 통해 사용자 지정 솔루션을 구축하거나 비싼 상용 네트워크 가속화 소프트웨어 라이선스를 사용 및 관리할 필요 없이 수백만 개의 파일이 포함된 대규모 데이터 세트를 복사할 수 있습니다. DataSync를 사용하여 활성 데이터를 AWS로 마이그레이션하거나 데이터를 아카이브하여 온프레미스 스토리지 용량을 확보하거나 비즈니스 연속성을 위해 데이터를 AWS로 복제하거나 분석 및 처리를 위해 데이터를 클라우드로 전송할 수 있습니다.

AWS DataSync는 온라인 데이터 전송의 복잡성을 줄이고 비용을 절감하여 온프레미스, 엣지 또는 기타 클라우드 스토리지와 AWS 스토리지 서비스 간, 그리고 AWS 스토리지 서비스 간 데이터 세트 전송을 간소화합니다. DataSync는 표준 스토리지 프로토콜(NFS, SMB)을 사용하거나 HDFS 클라이언트로 또는 Amazon S3 API를 사용하여 기존 스토리지 시스템 및 데이터 소스에 연결합니다. 특별히 구축된 네트워크 프로토콜과 확장 아키텍처를 사용하여 스토리지 시스템 및 AWS 간 데이터 전송을 가속화합니다. DataSync는 자동으로 확장하여 파일 및 객체 이동, 데이터 전송 일정 예약, 전송 진행 상황 모니터링, 암호화, 데이터 전송 확인 및 문제에 대한 고객 알림을 처리합니다. DataSync를 통해 최소 약정 또는 선결제 금액 없이 복사된 데이터만큼만 지불하면 됩니다.

AWS DataSync 사용 사례

데이터 마이그레이션— 네트워크를 통해 활성 데이터 세트를 Amazon S3, 아마존 EFS, FSx for Windows File Server, Lustre용 FSx 또는 OpenZFS용 FSx로 빠르게 이동할 수 있습니다. DataSync 는 데이터를 손상 없이 안전하게 전송하여 즉시 사용할 수 있도록 하기 위해 자동 암호화 및 데이터 무결성 검증을 포함합니다.

콜드 데이터 아카이빙— 온프레미스 스토리지에 저장된 콜드 데이터를 S3 Glacier Flexible Retrieval 또는 S3 Glacier Deep Archive 등의 내구성 있고 안전한 장기 스토리지 클래스로 바로 이동합니다 이렇게 하면 온프레미스 스토리지 용량을 확보하고 레거시 시스템을 종료할 수 있습니다.

데이터 보호— Amazon S3 스토리지 클래스로 데이터를 이동하여 필요에 따라 가장 경제적인 스토리지 클래스를 선택합니다. 또한 Amazon EFS, 윈도우 파일 서버용 FSx, FSx for Lustre 또는 대기 파일 시스템의 경우 OpenZFS용 FSx로 데이터를 보낼 수도 있습니다.

적시에 클라우드 내 처리를 위한 데이터 이동— 데이터 내부 또는 외부로 데이터 이동AWS처리를 위해. 이러한 접근 방법은 많은 산업 분야에서 중요한 하이브리드 클라우드 워크플로우를 가속화할 수 있습니다. 이러한 워크플로우는 생명 과학 산업의 기계 학습, 미디어 및 엔터테인먼트 비디오 제작, 금융 서비스의 빅 데이터 분석 및 석유 및 가스 산업의 지진 연구를 포함합니다.

S3 객체 잠금을 사용하면 write-once-read-many(WORM) 모델을 사용하여 객체를 Amazon S3에 저장할 수 있습니다. S3 객체 잠금을 사용하면 일정한 시간 동안 또는 무기한으로 객체를 삭제하거나 덮어쓰지 않도록 할 수 있습니다.

회사는 기밀 재무 문서를 저장하기 위해 Amazon S3를 사용해야 합니다. 분기별 보고의 경우 3개월 후에 파일을 검색해야 합니다. 갑작스러운 감사의 경우 아카이브된 데이터에 액세스하여 즉시 제출해야 하는 경우가 있습니다.

비용 효율적인 방법으로 이 요구 사항을 충족하려면 S3 클래스 중 무엇을 선택해야 합니까?

Amazon S3 Standard - Infrequent Access

이 시나리오에서 요구 사항은 비용 효율적이고 아카이브된 데이터에 즉시 액세스하거나 검색할 수 있는 스토리지 옵션이 있어야 합니다. 비용 효율적인 옵션은 Amazon Glacier Deep Archive 및 Amazon S3 Standard-Infrequent Access(Standard - IA)입니다. 그러나 Amazon Glacier Deep Archive는 긴급 감사에 필요한 데이터의 빠른 검색을 위해 설계되지 않았습니다.

따라서 Amazon Glacier Deep Archive를 사용하는 것은 올바르지 않으며 가장 좋은 대답은 Amazon S3 Standard - Infrequent Access를 사용하는 것입니다.

S3 Standard-IA는 자주 액세스하지 않지만 필요할 때 빠르게 액세스해야 하는 데이터에 적합합니다. S3 Standard-IA는 S3 Standard의 뛰어난 내구성, 높은 처리량 및 짧은 대기 시간을 저렴한 GB당 스토리지 요금과 GB당 검색 요금으로 제공합니다. 저렴한 비용과 높은 성능의 조합을 제공하는 S3 Standard-IA는 장기 스토리지, 백업 및 재해 복구 파일용 데이터 스토어에 이상적입니다. S3 스토리지 클래스를 객체 수준에서 구성할 수 있으며 S3 Standard, S3 Intelligent-Tiering, S3 Standard-IA, S3 One Zone-IA 전반에 걸쳐 저장된 여러 객체가 단일 버킷에 포함될 수 있습니다. 또한 S3 수명 주기 정책을 사용하여 애플리케이션 변경 없이 자동으로 스토리지 클래스 간에 객체를 전환할 수 있습니다.

회사에는 미션 크리티컬 워크로드에 사용될 영구 블록 스토리지 볼륨이 필요합니다. 백업 데이터는 오브젝트 스토리지 서비스에 저장되며, 30일 후 데이터는 데이터 보관 스토리지 서비스에 저장됩니다.

위의 요구 사항을 충족하려면 어떻게 해야 합니까?

EC2 인스턴스에 EBS 볼륨을 연결합니다. Amazon S3를 사용하여 백업 데이터를 저장하고 수명 주기 정책을 구성하여 객체를 Amazon S3 Glacier로 전환합니다.

Amazon Elastic Block Store(Amazon EBS)는 EC2 인스턴스와 함께 사용할 블록 수준 스토리지 볼륨을 제공합니다. EBS 볼륨은 포맷되지 않은 원시 블록 장치처럼 작동합니다. 이러한 볼륨을 인스턴스의 디바이스로 탑재할 수 있습니다. 인스턴스에 연결된 EBS 볼륨은 인스턴스의 수명과 독립적으로 지속되는 스토리지 볼륨으로 노출됩니다. 이러한 볼륨 위에 파일 시스템을 만들거나 블록 장치(예: 하드 드라이브)를 사용하는 방식으로 사용할 수 있습니다. 인스턴스에 연결된 볼륨의 구성을 동적으로 변경할 수 있습니다.

빠르게 액세스해야 하고 장기적인 지속성이 필요한 데이터에는 Amazon EBS를 권장합니다. EBS 볼륨은 파일 시스템, 데이터베이스 또는 세부적인 업데이트와 포맷되지 않은 원시 블록 수준 스토리지에 대한 액세스가 필요한 모든 애플리케이션의 기본 스토리지로 사용하기에 특히 적합합니다. Amazon EBS는 임의 읽기 및 쓰기에 의존하는 데이터베이스 스타일 애플리케이션과 길고 지속적인 읽기 및 쓰기를 수행하는 처리량 집약적 애플리케이션 모두에 적합합니다.

S3 수명 주기 구성에서, 객체를 한 스토리지 클래스에서 다른 스토리지 클래스로 전환하여 스토리지 비용을 절약하도록 규칙을 정의할 수 있습니다. 객체의 액세스 패턴을 모르거나 시간이 지남에 따라 액세스 패턴이 변하면 자동 비용 절감을 위해 객체를 S3 Intelligent-Tiering 스토리지 클래스로 전환할 수 있습니다.

Amazon S3은 다음 다이어그램과 같이 스토리지 클래스 간 전환을 위한 폭포형(Waterfall) 모델을 지원합니다.

Amazon S3은 S3 수명 주기 구성을 사용하여 스토리지 클래스 간에 다음과 같은 수명 주기 전환을 지원합니다.

다음과 같이 전환할 수 있습니다.

1. S3 Standard 스토리지 클래스에서 다른 스토리지 클래스로 전환

2. S3 Standard-IA 스토리지 클래스에서 S3 Intelligent-Tiering, S3 One Zone-IA, S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval 또는 S3 Glacier Deep Archive 스토리지 클래스로 전환

3. S3 Intelligent-Tiering 스토리지 클래스에서 S3 One Zone-IA, S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval 또는 S3 Glacier Deep Archive 스토리지 클래스로 전환

4. S3 One Zone-IA 스토리지 클래스에서 S3 Glacier Flexible Retrieval 또는 S3 Glacier Deep Archive 스토리지 클래스로 전환

5. S3 Glacier Instant Retrieval 스토리지 클래스에서 S3 Glacier Flexible Retrieval 또는 S3 Glacier Deep Archive 스토리지 클래스로 전환

6. S3 Glacier Flexible Retrieval 스토리지 클래스에서 S3 Glacier Deep Archive 스토리지 클래스로 전환

7. S3 Glacier Deep Archive 스토리지 클래스에 대한 모든 스토리지 클래스로 전환

이 시나리오에서 이 솔루션을 구현하려면 세 가지 서비스가 필요합니다. 미션 크리티컬 워크로드는 영구 블록 스토리지 볼륨이 필요하며 이를 위해 설계된 서비스는 Amazon EBS 임을 의미합니다. 두 번째 워크로드에는 백업 데이터를 저장하기 위해 Amazon S3와 같은 객체 스토리지 서비스가 있어야 합니다. Amazon S3를 사용하면 S3 Standard에서 다른 스토리지 클래스로 수명 주기 정책을 구성할 수 있습니다. 마지막으로 Amazon S3 Glacier와 같은 아카이브 스토리지가 필요합니다.

애플리케이션은 여러 EBS 볼륨이 연결된 EC2 인스턴스에서 호스팅되며 Amazon Neptune을 데이터베이스로 사용합니다. 데이터 보안을 강화하기 위해 인스턴스에 연결된 모든 EBS 볼륨을 암호화하여 볼륨에 저장된 기밀 데이터를 보호했습니다.

다음 중 암호화된 Amazon Elastic Block Store 볼륨에 대한 설명으로 옳은 것은 무엇입니까? (2개 선택)

볼륨과 인스턴스 간에 이동하는 모든 데이터는 암호화됩니다.

스냅샷은 자동으로 암호화됩니다.

Amazon Elastic Block Store(Amazon EBS)는 EC2 인스턴스에 사용할 수 있는 블록 수준 스토리지 볼륨을 제공합니다. EBS 볼륨은 형식이 지정되지 않은 원시 블록 디바이스처럼 동작합니다. 이러한 볼륨을 인스턴스에 디바이스로 마운트할 수 있습니다. 인스턴스에 연결된 EBS 볼륨은 스토리지 볼륨으로 표시되며, 인스턴스 수명에 관계없이 지속됩니다. 이러한 볼륨 위에 파일 시스템을 생성하거나 하드 드라이브와 같은 블록 디바이스를 사용하는 것처럼 볼륨을 사용할 수 있습니다. 인스턴스에 연결된 볼륨의 구성을 동적으로 변경할 수 있습니다.

데이터에 빠르게 액세스하고 장기적으로 지속해야 하는 경우 Amazon EBS를 사용하는 것이 좋습니다. EBS 볼륨은 세분화된 업데이트가 필요하고 형식이 지정되지 않은 블록 수준의 원시 스토리지에 액세스해야 하는 파일 시스템, 데이터베이스 또는 애플리케이션의 기본 스토리지로 사용하기에 특히 적합합니다. Amazon EBS는 임의 읽기 및 쓰기에 의존하는 데이터베이스 스타일의 애플리케이션과 장시간의 지속적인 읽기 및 쓰기를 수행하는 처리량 집약적 애플리케이션에 모두 적합합니다.

EC2 인스턴스와 연결된 EBS 리소스를 위한 간단한 암호화 솔루션으로 Amazon EBS 암호화를 사용할 수 있습니다. Amazon EBS 암호화를 사용하면 자체 키 관리 인프라를 구축, 유지 관리 및 보호할 필요가 없습니다. Amazon EBS 암호화는 암호화된 볼륨 및 스냅샷을 생성할 때 AWS KMS keys를 사용합니다.

암호화 작업은 EC2 인스턴스를 호스팅하는 서버에서 진행되며, 인스턴스와 인스턴스에 연결된 EBS 스토리지 간 유휴 데이터 및 전송 중 데이터의 보안을 모두 보장합니다.

EC2 인스턴스의 부팅 및 데이터 볼륨을 모두 암호화할 수 있습니다.

암호화된 EBS 볼륨을 만들고 지원되는 인스턴스 유형에 이 볼륨을 연결하면 다음 유형의 데이터가 암호화됩니다.

- 볼륨 내부에 있는 데이터

- 볼륨과 인스턴스 사이에서 이동하는 모든 데이터

- 볼륨에서 생성된 모든 스냅샷

- 그런 스냅샷에서 생성된 모든 볼륨

뉴스 집계 회사는 법률 회사에서 은행, 소비자에 이르기까지 다양한 고객에게 수백 가지의 디지털 제품과 서비스를 제공합니다. 회사는 고객에게 제공된 클릭스트림 데이터 단위를 기준으로 고객에게 청구합니다. 회사는 규제된 산업에서 운영되기 때문에 7일 이내에 감사에 사용할 수 있는 동일한 주문 클릭스트림 데이터가 있어야 합니다.

다음 AWS 서비스 중 지정된 클릭스트림 데이터에 대해 동일한 순서로 청구 프로세스 및 감사 프로세스를 실행할 수 있는 기능을 제공하는 서비스는 무엇입니까?

AWS Kinesis Data Streams

Amazon Kinesis Data Streams(KDS)는 확장성과 내구성이 뛰어난 실시간 데이터 스트리밍 서비스입니다. KDS는 웹사이트 클릭스트림, 데이터베이스 이벤트 스트림, 금융 거래, 소셜 미디어 피드, IT 로그 및 위치 추적 이벤트와 같은 수십만 개의 소스에서 초당 기가바이트의 데이터를 지속적으로 캡처할 수 있습니다. 수집된 데이터는 실시간 대시보드, 실시간 이상 감지, 동적 가격 책정 등과 같은 실시간 분석 사례를 지원하기 위해 밀리초 단위로 제공됩니다.

Amazon Kinesis Data Streams를 사용하면 스트리밍 빅 데이터를 실시간으로 처리할 수 있습니다. 여러 Amazon Kinesis 애플리케이션에 동일한 순서로 레코드를 읽거나 재생하는 기능은 물론 레코드의 순서를 제공합니다. Amazon Kinesis 클라이언트 라이브러리(KCL)는 지정된 파티션 키에 대한 모든 레코드를 동일한 레코드 프로세서에 제공하므로 동일한 Amazon Kinesis 데이터 스트림에서 읽는 여러 애플리케이션을 더 쉽게 구축할 수 있습니다(예: 계산, 집계 및 필터링 수행) . Amazon Kinesis Data Streams는 몇 시간 후에 동일한 순서로 레코드를 소비해야 하는 경우에 권장됩니다.

예를 들어 결제 애플리케이션이 있고 결제 애플리케이션보다 몇 시간 뒤에 실행되는 감사 애플리케이션이 있는 경우가 이에 속합니다. Kinesis Data Streams는 데이터를 최대 365일간 저장하므로 결제 애플리케이션보다 최대 365일 뒤에 감사 애플리케이션을 실행할 수 있습니다.

사진 호스팅 서비스는 매달 50GB 이상의 크기로 전 세계에 다운로드되는 아름다운 이미지 모음을 게시합니다. 콘텐츠는 현재 EFS에서 호스팅되고 Elastic Load Balancing(ELB) 및 Amazon EC2 인스턴스에 의해 배포됩니다. 웹사이트는 매달 높은 로드와 매우 높은 네트워크 비용을 경험하고 있습니다.

애플리케이션 리팩터링을 강제하지 않고 네트워크 비용과 EC2 로드를 크게 줄이는 방법은 무엇입니까?

CloudFront 배포 생성

CloudFront 상호 접속 위치(POP 또는 엣지 로케이션이라고도 함)는 많이 사용되는 콘텐츠를 최종 사용자에게 빠르게 제공할 수 있도록 합니다. CloudFront에는 또한 리전 엣지 캐시가 있어 POP에 있을 정도로 많이 사용되는 콘텐츠가 아닌 경우에도 최종 사용자가 보다 많은 콘텐츠를 가까이에서 액세스할 수 있도록 하여 콘텐츠의 성능을 개선하는 데 도움을 줍니다.

리전 엣지 캐시는 모든 유형의 콘텐츠, 특히 시간이 지나면서 점차 사용되지 않게 되는 콘텐츠에 유용합니다. 이러한 콘텐츠의 예로는 동영상, 사진 또는 아트워크와 같은 사용자 생성 콘텐츠, 제품 사진 및 동영상과 같은 전자 상거래 자산, 갑자기 사용자가 많아질 수 있는 뉴스 및 이벤트 관련 콘텐츠 등이 있습니다.

주어진 사례의 경우 ELB 앞에 캐싱 계층을 추가하려면 CloudFront 배포를 생성해야 합니다. 해당 캐싱 레이어는 이미지 팩이 정적 파일이기 때문에 매우 효과적이므로 애플리케이션 리팩터링 없이도 네트워크 비용을 크게 절약할 수 있습니다.

회사에 Amazon SQS와 일련의 EC2 인스턴스를 활용하는 웹 기반 티켓팅 서비스가 있습니다. SQS 대기열의 메시지를 사용하는 EC2 인스턴스는 종단 간 처리량을 최대한 높게 유지하기 위해 최대한 자주 대기열을 폴링하도록 구성됩니다. Solutions Architect는 빡빡한 루프에서 대기열을 폴링하는 것이 불필요한 CPU 주기를 사용하여 빈 응답으로 인해 운영 비용이 증가한다는 사실을 알게 되었습니다.

이 시나리오에서 시스템을 보다 비용 효율적으로 만들기 위해 무엇을 해야 합니까?

ReceiveMessageWaitTimeSeconds를 0보다 큰 숫자로 설정하여 긴 폴링을 사용하도록 Amazon SQS를 구성합니다.

이 시나리오에서 애플리케이션은 단일 SQS 대기열에서 메시지를 폴링하는 EC2 인스턴스에 배포됩니다. Amazon SQS는 기본적으로 짧은 폴링을 사용하여 응답에 포함할 수 있는 메시지가 있는지 확인하기 위해 서버의 하위 집합(가중된 무작위 분포 기반)만 쿼리합니다. 짧은 폴링은 더 높은 처리량이 필요한 시나리오에서 작동합니다. 그러나 비용을 줄이기 위해 대신 긴 폴링을 사용하도록 대기열을 구성할 수도 있습니다.

ReceiveMessageWaitTimeSeconds는 Short 또는 Long 폴링을 사용하는지 여부를 결정하는 대기열 속성입니다. 기본적으로 값은 0이며 이는 짧은 폴링을 사용하고 있음을 의미합니다. 0보다 큰 값으로 설정하면 Long 폴링입니다.

Amazon SQS 대기열에서 메시지를 수신하기 위해 짧은 폴링 및 긴 폴링을 제공합니다. 기본적으로 대기열은 짧은 폴링을 사용합니다.

짧은 폴링 : ReceiveMessage요청은 서버의 하위 세트 (가중치 기반 무작위 배포 기준) 만을 쿼리하여 응답에 포함할 수 있는 메시지를 찾습니다. Amazon SQS 쿼리에서 메시지를 찾지 못한 경우에도 즉시 응답을 전송합니다.

긴 폴링 : ReceiveMessage요청은 모든 서버에 메시지를 쿼리합니다. Amazon SQS 하나 이상의 사용 가능한 메시지를 수집한 후 요청에 지정된 최대 메시지 수까지 응답을 보냅니다. Amazon SQS 폴링 대기 시간이 만료된 경우에만 빈 응답을 보냅니다.

긴 폴링은 다음과 같은 이점이 있습니다.

- 응답을 전송하기 전에 Amazon SQS가 대기열에서 메시지를 사용할 수 있을 때까지 를 대기시켜 빈 응답을 줄입니다. 연결 시간이 초과되지 않은 경우, ReceiveMessage 요청에 대한 응답은 하나 이상의 사용 가능한 메시지부터 ReceiveMessage 작업에 지정된 최대 메시지 개수까지 포함합니다. 드물지만 대기열에 여전히 메시지가 포함되어 있어도 빈 응답을 받을 수 있습니다. 특히 낮은 값을 지정하는 경우ReceiveMessageWaitTimeSeconds파라미터.

- 모든 (하위 세트가 아닌) Amazon SQS 서버를 쿼리하여 거짓의 빈 응답을 줄입니다.

- 사용 가능한 즉시 메시지를 반환합니다.

회사는 EC2, Auto Scaling 그룹, S3 및 SQS를 사용하여 AWS에서 분리된 애플리케이션을 가지고 있습니다. Solutions Architect는 EC2 인스턴스가 SQS 대기열의 메시지를 사용하고 대기열의 메시지 수에 따라 자동으로 확장 또는 축소되도록 아키텍처를 설계했습니다.

이 시나리오에서 다음 중 SQS에 대한 설명으로 옳지 않은 것은?

표준 대기열은 메시지 순서를 유지합니다.

Amazon Simple Queue Service(SQS)는 마이크로 서비스, 분산 시스템 및 서버리스 애플리케이션을 쉽게 분리하고 확장할 수 있도록 지원하는 완전관리형 메시지 대기열 서비스입니다. SQS는 메시지 중심 미들웨어를 관리하고 운영하는 데 따른 복잡성과 오버헤드를 없애고 개발자가 차별화 작업에 집중할 수 있도록 지원합니다. SQS를 사용하면 메시지 손실 위험을 감수하거나 다른 서비스를 가동할 필요 없이 소프트웨어 구성 요소 간에 모든 볼륨의 메시지를 전송, 저장 및 수신할 수 있습니다. AWS 관리 콘솔, 명령줄 인터페이스 또는 원하는 SDK, 3가지 간단한 명령을 사용하여 몇 분 만에 SQS를 시작할 수 있습니다.

SQS에서는 2가지 종류의 메시지 대기열을 제공합니다. 표준 대기열은 최대 처리량, 최선 노력 순서, 최소 1회 전달을 제공합니다. SQS FIFO 대기열은 메시지가 전송된 정확한 순서대로 정확히 한 번 처리되도록 설계되었습니다.

표준 대기열은 메시지 순서를 유지하기 위해 최선을 다하지만 메시지 사본이 두 개 이상 배달될 수 있습니다. 시스템에서 순서를 유지해야 하는 경우 FIFO(선입 선출) 대기열을 사용하거나 각 메시지에 순서 정보를 추가하여 메시지를 받았을 때 순서를 변경할 것을 권장합니다.

회사의 비즈니스 로직은 온프레미스 데이터 센터에서 실행되는 여러 마이크로서비스를 기반으로 합니다. 현재 MQTT 프로토콜을 지원하는 메시지 브로커를 사용하여 통신하고 있습니다. 회사는 애플리케이션 로직을 변경하지 않고 이러한 애플리케이션과 메시지 브로커를 AWS 클라우드로 마이그레이션하는 방법을 찾고 있습니다.

MQTT 프로토콜을 지원하는 관리형 메시지 브로커를 얻을 수 있는 기술은 무엇입니까?

Amazon MQ

Amazon MQ는 클라우드에서 메시지 브로커를 쉽게 설정하고 운영할 수 있도록 지원하는 Apache ActiveMQ 및 RabbitMQ용 관리형 메시지 브로커 서비스입니다. ActiveMQ 및 RabbitMQ 콘솔과 메시징용 업계 표준 API 및 프로토콜(JMS, NMS, AMQP 1.0 및 0.9.1, STOMP, MQTT, WebSocket 등)에 직접 액세스할 수 있습니다. 애플리케이션의 메시징 코드를 다시 작성할 필요가 없으므로 이러한 표준을 사용하는 메시지 브로커에서 Amazon MQ로 손쉽게 이전할 수 있습니다.

회사는 대부분의 온프레미스 데이터를 Amazon S3, Amazon EFS 및 Amazon FSx for Windows File Server로 쉽고 빠르고 비용 효율적으로 이동하려고 합니다.

다음 중 이러한 AWS 스토리지 서비스로의 온라인 데이터 전송을 자동화하고 가속화하는 데 가장 적합한 솔루션은 무엇입니까?

AWS DataSync를 사용하여 지정된 AWS 스토리지 서비스에 대한 온라인 데이터 전송을 자동화하고 가속화합니다.

AWS DataSync Discovery(평가판)는 온프레미스 스토리지 성능 및 사용률에 대한 가시성과 AWS 스토리지 서비스로 데이터를 마이그레이션할 때의 권장 사항을 제공합니다. 따라서 마이그레이션 계획 수립을 간소화하고 AWS로의 데이터 마이그레이션을 가속화하는 데 도움이 됩니다. DataSync Discovery를 사용하면 자동화된 데이터 수집 및 분석을 통해 온프레미스 스토리지 성능 및 용량 사용량을 더 잘 이해할 수 있습니다. 따라서 마이그레이션할 데이터를 빠르게 식별하고 생성된 권장 사항을 사용하여 성능 및 예산 요구 사항에 일치하는 AWS 스토리지 서비스를 선택할 수 있습니다.

온라인 데이터 전송의 경우 AWS DataSync는 온프레미스 스토리지, 엣지 로케이션 또는 다른 클라우드 및 AWS 스토리지 서비스 간과 여러 AWS 스토리지 서비스 간에 이루어지는 다량의 데이터 복사를 간소화, 자동화 및 가속화합니다. DataSync는 네트워크 파일 시스템(NFS) 공유, 서버 메시지 블록(SMB) 공유, Hadoop 분산 파일 시스템(HDFS), 자체 관리형 객체 스토리지, Google Cloud Storage, Azure Files, AWS Snowcone, Amazon Simple Storage Service(S3), Amazon Elastic File System(Amazon EFS) 파일 시스템, Amazon FSx for Windows File Server 파일 시스템, Amazon FSx for Lustre 파일 시스템, Amazon FSx for OpenZFS 파일 시스템 및 Amazon FSx for NetApp ONTAP 파일 시스템 간에 데이터를 복사할 수 있습니다.

AWS DataSync가 데이터 세트를 복사할 수 있는 속도는 데이터 크기, 소스 및 대상 스토리지에서 달성할 수 있는 I/O 대역폭, 사용 가능한 네트워크 대역폭 및 네트워크 상태에 따라 계산됩니다. 온프레미스 및 AWS 스토리지 서비스 간 데이터 전송의 경우 단일 DataSync 태스크로 10Gbps 네트워크 링크를 충분히 활용할 수 있습니다.

회사의 애플리케이션 일반 워크로드를 지원하기 위해 최소 2개의 EC2 인스턴스를 배포하고 최대 로드를 처리하기 위해 최대 6개의 EC2 인스턴스까지 자동으로 확장해야 합니다. 또한 미션 크리티컬 워크로드를 처리할 때는 가용성이 높고 내결함성이 있어야 합니다.

위의 요구 사항을 충족하려면 어떻게 해야 합니까?

EC2 인스턴스의 Auto Scaling 그룹을 생성하고 최소 용량을 4로, 최대 용량을 6으로 설정합니다. 가용 영역 A에 2개의 인스턴스를 배포하고 가용 영역 B에 다른 2개의 인스턴스를 배포합니다.

Amazon EC2 Auto Scaling을 사용하면 애플리케이션의 로드를 처리할 수 있는 정확한 수의 Amazon EC2 인스턴스를 유지할 수 있습니다. 오토 스케일링이라는 EC2 인스턴스 모음을 생성합니다. 각 오토 스케일링의 최소 인스턴스 수를 지정할 수 있으며, Amazon EC2 Auto Scaling에서는 그룹의 크기가 이 값 아래로 내려가지 않습니다. 각 오토 스케일링의 최대 인스턴스 수를 지정할 수 있으며, Amazon EC2 Auto Scaling에서는 그룹의 크기가 이 값을 넘지 않습니다. 원하는 용량을 지정한 경우 그룹을 생성한 다음에는 언제든지 Amazon EC2 Auto Scaling에서 해당 그룹에서 이만큼의 인스턴스를 보유할 수 있습니다. 조정 정책을 지정했다면 Amazon EC2 Auto Scaling에서는 애플리케이션의 늘어나거나 줄어드는 수요에 따라 인스턴스를 시작하거나 종료할 수 있습니다.

예를 들어, 다음 오토 스케일링의 경우 최소 인스턴스 수 1개, 원하는 인스턴스 용량 2개, 최대 인스턴스 수 4개가 됩니다. 사용자가 정의한 조정 정책에 따라 인스턴스 수가 최소 및 최대 인스턴스 수 내에서 지정하는 조건에 따라 조절됩니다.

애플리케이션에 대한 고가용성 및 내결함성 아키텍처를 달성하려면 모든 인스턴스를 서로 다른 가용 영역에 배포해야 합니다. 이렇게 하면 중단이 발생할 경우 리소스를 격리하는 데 도움이 됩니다. 내결함성을 달성하려면 서버 장애 또는 가용 영역 중단 시 시스템 성능 저하를 방지하기 위해 예비 리소스가 있어야 합니다. 내결함성 아키텍처를 사용하려면 일반적으로 필요한 것보다 추가 리소스를 실행하는 데 추가 비용이 필요합니다. 이는 미션 크리티컬 워크로드가 처리되도록 하기 위한 것입니다.

시나리오에서 일반 트래픽을 처리하려면 최소 2개의 인스턴스가 필요하므로 AZ 중단이 발생하더라도 항상 2개의 인스턴스를 실행해야 합니다. Auto Scaling 그룹을 사용하여 두 개 이상의 가용 영역에서 컴퓨팅 리소스를 자동으로 확장할 수 있습니다. 최소 용량은 4개 인스턴스, 최대 용량은 6개 인스턴스로 지정해야 합니다. 각 AZ에 2개의 인스턴스가 실행 중인 경우 AZ에 장애가 발생하더라도 시스템은 여전히 최소 2개의 인스턴스를 실행합니다.

현재 사내 Active Directory와 10대의 컴퓨터가 있습니다. 물리적 워크스테이션 조달 비용을 절감하기 위해 AWS의 가상 사설 클라우드에 신입 직원을 위한 가상 데스크톱을 배포하기로 결정했습니다. 새로운 클라우드 인프라는 AWS의 기존 보안 제어를 활용해야 하지만 여전히 온프레미스 네트워크와 통신할 수 있습니다.

이러한 요구 사항을 충족하기 위해 어떤 AWS 서비스 세트를 사용 해야 합니까?

AWS Directory Services, VPN connection, Amazon Workspaces

VPC와 온프레미스 네트워크를 연결하려면 VPN 연결이 필요합니다. 둘째, 온프레미스 Active Directory와 통합하려면 AWS Directory Services가 필요하고 마지막으로 Amazon Workspace를 사용하여 VPC에 필요한 가상 데스크톱을 생성해야 합니다.

Microsoft Active Directory용 AWS Directory Service, 즉 AWS Managed Microsoft Active Directory(AD)를 사용하면 디렉터리 인식 워크로드와 AWS 리소스에 AWS의 관리형 Active Directory(AD)를 활용할 수 있습니다. AWS Managed Microsoft AD는 실제 Microsoft AD에 구축되므로 기존 Active Directory의 데이터를 클라우드로 동기화하거나 복제할 필요가 없습니다. 표준 AD 관리 도구를 사용하여 Group Policy 및 SSO 등 AD의 기본 기능을 활용할 수 있습니다. AWS Managed Microsoft AD에서는 Amazon EC2와 Amazon RDS for SQL Server 인스턴스를 도메인에 손쉽게 조인하고, AD 사용자 및 그룹으로 Amazon WorkSpaces와 같은 AWS 최종 사용자 컴퓨팅(EUC)을 사용할 수 있습니다.

Amazon WorkSpaces는 관리형 보안 클라우드 데스크톱 서비스입니다. Amazon WorkSpaces를 사용하여 몇 분 만에 Windows, Amazon Linux 또는 Ubuntu Linux 데스크톱을 프로비저닝하고 신속하게 확장하여 전 세계 작업자에게 수천 개의 데스크톱을 제공할 수 있습니다. 시작한 WorkSpaces에 대해서만 월별 또는 시간별 요금을 지불하므로, 기존 데스크톱과 온프레미스 가상 데스크톱 인프라(VDI) 솔루션에 비해 비용을 절감할 수 있습니다. Amazon WorkSpaces를 사용하면 하드웨어 인벤토리, OS 버전 및 패치, VDI를 관리하는 복잡성을 제거하여 데스크톱 제공 전략을 간소화할 수 있습니다. Amazon WorkSpaces에서는 사용자가 언제 어디서나 지원되는 디바이스에서 액세스할 수 있는 빠르고 응답적인 데스크톱을 사용할 수 있습니다.

다음 VPN 연결 옵션을 사용하여 Amazon VPC를 원격 네트워크 및 사용자에 연결할 수 있습니다.

- AWS Site-to-Site VPN

- AWS Client VPN

- AWS VPN CloudHub

- 타사 소프트웨어 VPN 어플라이언스

회사에는 사용자 지정 Amazon 머신 이미지(AMI)의 일반 텍스트 파일에 액세스 키 ID와 보안 액세스 키를 모두 저장하는 애플리케이션 아키텍처가 있습니다. 이 AMI를 사용하여 생성된 EC2 인스턴스는 저장된 액세스 키를 사용하여 DynamoDB 테이블에 연결합니다.

솔루션 아키텍트는 현재 아키텍처를 보다 안전하게 만들기 위해 무엇을 해야 합니까?

AMI에 저장된 액세스 키를 제거합니다. DynamoDB 테이블에 액세스할 수 있는 권한이 있는 새 IAM 역할을 생성하고 이를 EC2 인스턴스에 할당합니다.

Amazon EC2 인스턴스에서 실행되는 애플리케이션에는 AWS API 요청에 AWS 보안 인증 정보가 포함되어 있어야 합니다. 개발자에게 Amazon EC2 인스턴스 내에서 직접 AWS 보안 인증 정보를 저장하고 해당 인스턴스의 애플리케이션에서 해당 보안 인증 정보를 사용하는 것을 허용하도록 했을 수 있습니다. 그러나 개발자는 그런 다음에 보안 인증 정보를 관리하고 각 인스턴스에 보안 인증 정보를 안전하게 전달해야 하며, 보안 인증 정보를 순환해야 할 때 각 Amazon EC2 인스턴스를 업데이트해야 할 것입니다. 이처럼 여기에는 많은 작업이 요구됩니다.

이렇게 하는 대신 IAM 역할을 사용하여 Amazon EC2 인스턴스에서 실행되는 애플리케이션에 대한 임시 보안 인증 정보를 관리할 수 있고 또 그렇게 해야 합니다. 역할을 사용할 때 Amazon EC2 인스턴스에 장기 보안 인증 정보(예: 사용자 이름과 암호 또는 액세스 키)를 배포하지 않아도 됩니다. 그 대신 역할은 애플리케이션에서 다른 AWS 리소스에 호출할 때 사용할 수 있는 임시 권한을 제공합니다. Amazon EC2 인스턴스를 시작할 때 인스턴스와 연결할 IAM 역할을 지정합니다. 그러면 이 인스턴스에서 실행되는 애플리케이션은 역할 제공 임시 자격 증명을 사용하여 API 요청에 서명할 수 있습니다.

회사에 AWS에서 실행되는 UAT 및 프로덕션 EC2 인스턴스가 있습니다. 그들은 UAT 인스턴스를 담당하는 직원이 보안 위험을 최소화하기 위해 프로덕션 인스턴스에 대한 작업에 액세스할 수 없도록 하려고 합니다.

다음 중 이것을 달성하는 가장 좋은 방법은 무엇입니까?

UAT 및 프로덕션 서버에서 태그를 정의하고 특정 태그에 대한 액세스를 허용하는 조건을 IAM 정책에 추가합니다.

이 시나리오에서 필요한 솔루션을 달성하는 가장 좋은 방법은 태그와 IAM 정책의 조합을 사용하는 것입니다. UAT 및 프로덕션 EC2 인스턴스에서 태그를 정의하고 특정 태그에 대한 액세스를 허용하는 조건을 IAM 정책에 추가할 수 있습니다.

고유 메타데이터를 태그의 형태로 각 리소스에 배정하면 인스턴스, 이미지 및 기타 Amazon EC2 리소스를 쉽게 관리할 수 있습니다. 태그를 사용하면 용도, 소유자 또는 환경을 기준으로 하는 등 AWS 리소스를 다양한 방식으로 분류할 수 있습니다. 이 기능은 동일 유형의 리소스가 많을 때 유용합니다. 지정한 태그에 따라 특정 리소스를 빠르게 식별할 수 있습니다.

기본적으로 IAM 사용자에게는 Amazon EC2 리소스를 생성 또는 수정하거나 Amazon EC2 API를 사용하여 작업을 수행할 권한이 없습니다. Amazon EC2 콘솔이나 CLI를 사용하더라도 마찬가지입니다. IAM 사용자에게 리소스 생성 또는 수정 및 작업 수행을 허용하려면 IAM 사용자에게 필요한 특정 리소스 및 API 작업을 사용할 권한을 부여하는 IAM 정책을 생성하고, 해당 권한을 필요로 하는 IAM 사용자 또는 그룹에게 정책을 연결해야 합니다.

보안 회사는 EC2 인스턴스를 사용하여 독점 애플리케이션을 실행합니다. 회사의 인프라 유지 관리 그룹은 EC2 인스턴스의 CPU 사용률이 특정 임계값을 위반할 때마다 이메일을 통해 알림을 받기를 원합니다.

다음 중 최소한의 개발 노력으로 솔루션을 구축하는 데 사용할 서비스는 무엇입니까? (2개 선택)

Amazon SNS

Amazon CloudWatch

Amazon SNS - Amazon Simple Notification Service(SNS)는 마이크로서비스, 분산 시스템 및 서버리스 애플리케이션을 분리할 수 있는 고가용성, 내구성, 보안, 완전 관리형 게시/구독 메시징 서비스입니다. Amazon SNS는 처리량이 많은 푸시 기반 다대다 메시징에 대한 주제를 제공합니다.

Amazon CloudWatch - Amazon CloudWatch는 DevOps 엔지니어, 개발자, SRE(사이트 안정성 엔지니어) 및 IT 관리자를 위해 구축된 모니터링 및 관찰 서비스입니다. CloudWatch는 애플리케이션을 모니터링하고, 시스템 전체의 성능 변화에 대응하고, 리소스 활용도를 최적화하고, 운영 상태에 대한 통합 보기를 얻을 수 있는 데이터와 실행 가능한 통찰력을 제공합니다. Amazon CloudWatch를 사용하면 AWS 클라우드 리소스와 AWS에서 실행하는 애플리케이션을 모니터링할 수 있습니다.

EC2 인스턴스가 특정 임계값을 위반할 때마다 CloudWatch 경보를 사용하여 SNS를 통해 이메일을 보낼 수 있습니다.

회사는 비프로덕션 환경에서 EC2 인스턴스를 호스팅하고 언제든지 중단될 수 있는 배치 로드를 처리하고 있습니다.

이 경우 EC2 인스턴스에 적용할 수 있는 최상의 인스턴스 구매 옵션은 무엇입니까?

스팟 인스턴스

Amazon EC2 스팟 인스턴스를 사용하면 AWS 클라우드에서 미사용 EC2 용량을 활용할 수 있습니다. 스팟 인스턴스는 온디맨드 요금과 비교하여 최대 90% 할인된 금액으로 제공됩니다. 빅 데이터, 컨테이너식 워크로드, CI/CD, 웹 서버, 고성능 컴퓨팅(HPC), 테스트 및 개발 워크로드 등 다양한 상태 비저장, 내결함성 또는 유연한 애플리케이션에 스팟 인스턴스를 사용할 수 있습니다. 스팟 인스턴스는 Auto Scaling, EMR, ECS, CloudFormation, Data Pipeline 및 AWS Batch와 같은 AWS 서비스와 긴밀하게 통합되므로, 스팟 인스턴스에서 실행되는 애플리케이션을 시작하고 유지 관리하는 방법을 선택할 수 있습니다.

그뿐 아니라 스팟 인스턴스를 온디맨드, RI 및 Savings Plans 인스턴스와 손쉽게 결합하여 성능과 함께 워크로드 비용을 더욱 최적화할 수 있습니다. AWS의 운영 규모 덕분에 스팟 인스턴스는 대규모 워크로드를 실행할 수 있는 규모와 비용 절감을 제공할 수 있습니다. 또한, EC2에서 2분 알림을 통해 용량을 되돌리는 경우 스팟 인스턴스를 하이버네이트, 중단 또는 종료할 수 있는 옵션이 제공됩니다. 최대 90%의 할인된 금액으로 이렇게 방대한 규모로 미사용 컴퓨팅 용량에 손쉽게 액세스할 수 있는 것은 AWS가 유일합니다.

스팟 인스턴스는 온디맨드 가격보다 저렴한 비용으로 제공되는 예비 EC2 용량을 사용하는 인스턴스입니다. 스팟 인스턴스는 큰 할인율로 미사용 EC2 인스턴스를 요청할 수 있게 해주므로 사용자는 Amazon EC2 비용을 대폭 낮출 수 있습니다. 스팟 인스턴스는의 시간당 가격을 스팟 가격이라고 합니다. 각 가용 영역 내 인스턴스 유형별 스팟 가격은 Amazon EC2에서 설정하며, 스팟 인스턴스의 장기적 공급 및 수요에 따라 점진적으로 조정됩니다. 용량을 사용할 수 있을 때마다 스팟 인스턴스가 실행됩니다.

스팟 인스턴스는 애플리케이션이 실행되는 시간을 유연하게 조정할 수 있고 애플리케이션을 중단할 수 있는 경우에 선택하는 비용 효율적인 방법입니다. 예를 들어 스팟 인스턴스는 데이터 분석, 배치 작업, 백그라운드 프로세싱 및 선택적 작업에 적합합니다.

스팟 인스턴스를 사용하려면 인스턴스 수, 인스턴스 유형, 가용 영역 및 인스턴스 시간당 지불할 최대 가격이 포함된 스팟 인스턴스 요청을 생성합니다. 최고 가격이 현재 스팟 가격을 초과하는 경우 Amazon EC2는 용량이 사용 가능한 경우 즉시 요청을 이행합니다. 그렇지 않으면 Amazon EC2는 요청이 이행될 수 있을 때까지 또는 사용자가 요청을 취소할 때까지 기다립니다.

개발 회사가 다른 AWS 리전에서 비용 효율적인 백업 솔루션을 만들었습니다. 애플리케이션이 웜 대기 모드에서 실행 중이며 전면에서 지원하는 ALB(Application Load Balancer)가 있습니다. 현재 장애 조치 프로세스는 수동이며 기본 ALB에 장애가 발생한 경우 다른 리전의 보조 ALB를 가리키도록 DNS 별칭 레코드를 업데이트해야 합니다.

여기에서 장애 조치 프로세스를 자동화하기 위해 무엇을 권장하시겠습니까?

Amazon Route 53 상태 확인 활성화

DNS 장애 조치를 통해 Route 53은 웹 사이트 중단을 감지하고 최종 사용자를 지정한 대체 위치 또는 백업 위치로 리디렉션할 수 있습니다. Route 53 DNS 장애 조치는 전 세계 여러 위치에서 애플리케이션 엔드포인트에 대한 인터넷 요청을 정기적으로 수행하는 상태 확인에 의존하여 애플리케이션의 각 엔드포인트가 작동하는지 여부를 확인합니다.

ELB 엔드포인트의 상태를 확인하는 것은 단일 IP 주소를 확인하는 것보다 더 복잡합니다. 예를 들어 애플리케이션이 EC2에서 제대로 실행되고 있지만 로드 밸런서 자체에 연결할 수 없는 경우에는 어떻게 됩니까? 또는 로드 밸런서와 EC2 인스턴스가 올바르게 작동하지만 코드의 버그로 인해 애플리케이션이 충돌하는 경우? 또는 다중 AZ ELB의 한 가용 영역에 있는 EC2 인스턴스에 문제가 발생하는 경우는 어떻습니까?

Route 53 DNS 장애 조치는 배후에서 ELB와 통합하여 이러한 모든 실패 시나리오를 처리합니다. 활성화되면 Route 53은 개별 ELB 노드에 대한 상태 확인을 자동으로 구성하고 관리합니다. Route 53은 또한 ELB가 수행하는 EC2 인스턴스 상태 확인을 활용합니다. EC2 인스턴스와 ELB의 상태 확인 결과를 결합하여 Route 53 DNS 장애 조치는 로드 밸런서의 상태와 그 뒤에 있는 EC2 인스턴스에서 실행되는 애플리케이션의 상태를 평가할 수 있습니다. 즉, 스택의 일부가 다운되면 Route 53이 장애를 감지하고 장애가 발생한 엔드포인트에서 트래픽을 라우팅합니다.

Route 53 DNS 장애 조치를 사용하면 전 세계 여러 AWS 리전에서 기본 애플리케이션을 동시에 실행하고 여러 리전에서 장애 조치를 수행할 수 있습니다. 최종 사용자는 애플리케이션에 가장 가까운(지연 시간 기준) 정상적인 리전으로 라우팅됩니다. Route 53은 애플리케이션을 사용할 수 없는 모든 리전을 서비스에서 자동으로 제거합니다. 리전 전체에 연결 또는 운영 문제가 있거나 애플리케이션이 해당 리전에서 중단되거나 ELB 또는 EC2 인스턴스가 중단되는 경우 엔드포인트를 서비스에서 제외합니다.

Solutions Architect는 신용 카드 결제 및 온라인 거래를 처리하는 3계층 웹 애플리케이션을 관리하고 있습니다. 정적 웹 페이지는 프런트 엔드 계층에서 사용되는 반면 애플리케이션 계층에는 장기 실행 프로세스를 처리하는 단일 Amazon EC2 인스턴스가 포함됩니다. 데이터는 MySQL 데이터베이스에 저장됩니다. Solutions Architect는 계층을 분리하여 고가용성 애플리케이션을 생성하도록 지시합니다.

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

모든 정적 자산과 웹 페이지를 Amazon S3로 이동합니다. 애플리케이션을 Amazon Elastic Container Service(Amazon ECS) 컨테이너로 다시 호스팅하고 Service Auto Scaling을 활성화합니다. 다중 AZ 배포 구성을 사용하여 데이터베이스를 Amazon RDS로 마이그레이션합니다.

Amazon Elastic Container Service(ECS)는 Docker 컨테이너를 지원하고 Amazon EC2 인스턴스의 관리형 클러스터에서 애플리케이션을 쉽게 실행할 수 있는 확장성이 뛰어난 고성능 컨테이너 관리 서비스입니다. Amazon ECS를 사용하면 자체 클러스터 관리 인프라를 설치, 운영 및 확장할 필요가 없으므로 컨테이너를 애플리케이션의 빌딩 블록으로 쉽게 사용할 수 있습니다. Amazon ECS를 사용하면 Docker 컨테이너를 사용하여 장기 실행 애플리케이션, 서비스 및 배치 프로세스를 예약할 수 있습니다. Amazon ECS는 애플리케이션 가용성을 유지하고 애플리케이션의 용량 요구 사항에 맞게 컨테이너를 확장하거나 축소할 수 있습니다.

시나리오의 요구 사항은 서비스를 분리하여 고가용성 아키텍처를 달성하는 것입니다. 이 요구 사항을 충족하려면 기존 설정을 각 AWS 서비스로 이동해야 합니다. 정적 자산의 경우 Amazon S3를 사용해야 합니다. 웹 애플리케이션에 Amazon ECS를 사용한 다음 다중 AZ 배포를 통해 데이터베이스를 Amazon RDS로 마이그레이션할 수 있습니다. 앱을 애플리케이션 통합 서비스와 분리하면 상호 운용성을 유지할 수 있지만 한 서비스에 장애가 발생하거나 워크로드가 급증하더라도 나머지 서비스에는 영향을 미치지 않습니다.

뉴스 네트워크는 Amazon S3를 사용하여 한국 전역의 보고팀에서 비디오 영상을 집계합니다. 뉴스 네트워크는 최근 미국과 아시아의 새로운 리전으로 확장되었습니다. 해외 지사의 기술 팀은 대상 S3 버킷에 대용량 비디오 파일을 업로드하는 데 상당한 지연이 있다고 보고했습니다.

다음 중 S3로의 파일 업로드 속도를 향상시키는 가장 비용 효율적인 옵션은 무엇입니까? (2개 선택)

대상 S3 버킷에 더 빠른 파일 업로드를 위해 멀티파트 업로드 합니다.

Amazon S3 Transfer Acceleration을 사용하여 대상 S3 버킷으로 더 빠른 파일을 업로드 합니다.

Amazon S3 Transfer Acceleration을 사용하면 클라이언트와 S3 버킷 간에 장거리에서 파일을 빠르고 쉽고 안전하게 전송할 수 있습니다. Transfer Acceleration은 Amazon CloudFront의 전 세계적으로 분산된 엣지 로케이션을 활용합니다. 데이터가 엣지 로케이션에 도착하면 데이터는 최적화된 네트워크 경로를 통해 Amazon S3로 라우팅됩니다.

멀티파트 업로드를 사용하면 단일 객체를 파트 세트로 업로드할 수 있습니다. 각 부분은 객체 데이터의 연속 부분입니다. 이러한 객체 부분을 독립적으로 어떤 순서로든 업로드할 수 있습니다. 어떤 부분의 전송이 실패하면 다른 부분에 영향을 주지 않고 해당 부분을 재전송할 수 있습니다. 객체의 모든 부분이 업로드되면 Amazon S3는 이러한 부분을 조합하고 객체를 생성합니다. 일반적으로 객체 크기가 100MB에 도달하면 단일 작업으로 객체를 업로드하는 대신 멀티파트 업로드 사용을 고려해야 합니다. 멀티파트 업로드는 향상된 처리량을 제공하므로 더 빠른 파일 업로드가 가능합니다.

728x90

'공부하기' 카테고리의 다른 글

즐거운 영어 공부 (56)	2024.06.25
AWS 연습 문제 (7)	2024.06.19
AWS 연습문제 (62)	2024.06.12
AWS 연습문제 (65)	2024.06.05
AWS 연습문제 (64)	2024.05.31

AWS 연습 문제

'공부하기' 카테고리의 다른 글

관련글

티스토리툴바