한 금융 서비스 회사에서 자사의 Amazon S3 버킷에 저장된 민감 데이터를 식별하려고 합니다. 또한 회사는 S3에 저장된 모든 데이터를 모니터링하여 악의적인 시도로부터 보호하고자 합니다.
솔루션 아키텍트의 관점에서 다음 중 주어진 요구 사항을 해결하는 데 도움이 될 만한 솔루션은 무엇입니까?
Amazon GuardDuty를 사용해 S3에 저장된 데이터에 대한 악의적인 시도를 모니터링하고, Amazon Macie를 사용해 S3에 저장된 민감 데이터를 식별한다.
Amazon GuardDuty는 여러분이 AWS 계정, 워크로드, Amazon S3에 저장된 데이터를 연속적으로 모니터링하고 보호할 수 있는 위협 탐지 기능을 제공합니다. GuardDuty는 여러분의 계정에서 생성된 연속적인 메타데이터 스트림 및 AWS CloudTrail 이벤트, Amazon VPC 플로우 로그, DNS 로그에서 발견된 네트워크 활동을 분석합니다. 또한 알려진 악성 IP 주소 및 이상 탐지, 더욱 정확하게 위협을 식별하기 위한 머신러닝 등 통합 위협 인텔리전스를 이용합니다.
Amazon Macie는 머신러닝과 패턴 매칭을 사용하여 Amazon S3에 있는 여러분의 민감한 데이터를 발견하고 보호하는 완벽히 관리되는 데이터 보안 및 데이터 프라이버시 서비스입니다. Macie는 이름, 주소, 신용카드 번호 등의 개인식별가능정보(PII) 등 점점 늘어가는 민감한 데이터 유형 목록을 자동으로 감지합니다. 또한 Amazon S3에 저장된 여러분의 데이터의 데이터 보안과 데이터 프라이버시에 대한 계속적인 가시성을 제공합니다.
회사에서 EC2 인스턴스와 별도의 영구 스토리지를 제공하는 EBS 볼륨에 비즈니스 크리티컬 데이터를 저장하려고 합니다. 개발 팀에서 테스트를 진행하던 중에 EC2 인스턴스를 종료하면 연결된 EBS 볼륨 또한 소실된다는 것을 발견했고, 이는 예상과 상반된 결과였습니다.
솔루션 아키텍트의 관점에서 이 문제를 어떻게 설명할 수 있습니까?
EBS 볼륨이 Amazon EC2 인스턴스의 루트 볼륨으로 설정되었다. 인스턴스를 종료하면 기본 동작에 의해 연결된 루트 볼륨도 함께 종료된다.
Amazon Elastic Block Store(EBS)는 모든 스케일에서 빠른 처리 속도와 트랜잭션 집약적 워크로드에 모두 적합하도록 Amazon Elastic Compute Cloud(EC2)와 함께 사용하도록 설계된 편리한 고성능 블록 스토리지 서비스입니다.
여러분이 인스턴스를 실행할 때 인스턴스를 부팅하는 데 사용되는 이미지가 루트 장치 볼륨에 포함되어 있습니다. 여러분은 Amazon EC2 인스턴스 스토어가 지원하는 AMI 또는 Amazon EBS가 지원하는 AMI 중에 선택할 수 있습니다.
기본값으로서, Amazon EBS가 지원하는 AMI의 루트 볼륨은 인스턴스가 종료되면 삭제됩니다. 여러분은 기본 거동을 변경하여 인스턴스가 종료된 후에도 볼륨이 지속되도록 할 수 있습니다. 볼륨이 부착된 인스턴스를 여러분이 종료한 후에도 루트 EBS 볼륨 이외의 볼륨은 가용성이 유지됩니다. 그러므로 이 선택지가 정답입니다.
사내 인프라팀은 리소스 분리를 위해 A, B, C, D, E라는 5개의 서로 다른 VPC를 운영하고 있습니다. 조직 개편으로 인해 인프라 팀에서는 모든 VPC를 상호 연결하려고 합니다. 이를 구축하기 위해 인프라 팀은 VPC A를 중심으로 하여 허브 앤 스포크(Hub and Spoke) 모델로 VPC A와 나머지 VPC에 대한 피어링 연결을 설정했습니다. 하지만 인프라 팀은 모든 VPC 간의 연결을 구성하는 데 실패했습니다.
솔루션 아키텍트의 관점에서 봤을 때, 다음 중 가장 리소스 효율적이고 확장 가능한 솔루션은 무엇입니까
전송 게이트웨이(Transit Gateway)로 VPC를 상호 연결한다.
트랜짓 게이트웨이는 가상 사설 클라우드(VPC)와 온프레미스 네트워크를 상호 연결할 수 있는 네트워크 트랜짓 허브입니다.
VPC 피어링(peering) 연결은 사설 IPv4 주소 또는 IPv6 주소를 이용하여 VPC 간의 트래픽을 라우팅할 수 있게 해주는 두 VPC 간의 네트워킹 연결입니다. 전이성 피어링(Transitive Peering)은 VPC 피어링 연결에 대해 작동하지 않습니다. 그러므로 VPC A와 VPC B 간(pcx-aaaabbbb), 그리고 VPC A와 VPC C 간(pcx-aaaacccc)에 VPC 피어링 연결이 있다면 VPC B와 VPC C 간에 VPC 피어링 연결이 없습니다. VPC 피어링을 사용하는 대신에 여러분은 네트워크 트랜짓 허브 역할을 하는 AWS 트랜짓 게이트웨이를 사용하여 VPC들을 상호 연결하거나 여러분의 VPC들을 온프레미스 네트워크와 연결할 수 있습니다. 그러므로 이것이 정답입니다.
한 금융 서비스 업체는 최근 AWS 리소스의 보안을 강화하기 위한 작업을 시작했으며 업체가 소유한 여러 AWS 계정에서 AWS Shield Advanced 기능을 활성화했습니다. 하지만 분석 결과, 회사에서 예상했던 것보다 훨씬 큰 비용이 발생한다는 사실을 발견했습니다.
다음 중 AWS Shield Advanced 서비스에서 예상치 못한 큰 비용이 발생한 근복적인 이유는 무엇입니까?
통합 결제가 활성화되지 않았다. 월 사용 요금이 한 번만 청구되도록 모든 AWS 계정을 하나의 통합 결제 조직 밑에 둬야 한다. -
여러분의 조직에 다수의 AWS 계정이 있다면 여러분은 AWS 관리 콘솔 또는 API를 사용하여 각각의 계정에서 개별적으로 구독을 활성화하여 다수의 AWS 계정들을 AWS Shield Advanced에 포함시킬 수 있습니다. AWS 계정들이 모두 하나의 통합 결제에 속해 있는 한, 여러분은 월 요금을 한 번만 결제하게 되며, 모든 AWS 계정과 그 계정들의 모든 리소스를 소유하게 됩니다.
한 전자 상거래 애플리케이션에서 데이터베이스로 Amazon Aurora 다중 AZ 배포를 사용하고 있습니다. 엔지니어링 팀은 성능 지표를 분석하던 중, 데이터베이스 읽기 작업이 잦은 I/O를 유발하고 데이터베이스 쓰기 요청의 지연 시간을 증가시킨다는 것을 발견했습니다.
Associate 레벨의 AWS 공인 솔루션 아키텍트로서 읽기 요청과 쓰기 요청을 분리할 수 있는 방안으로 제안할 만한 것은 무엇입니까?
읽기 전용 복제본을 구성하고 애플리케이션이 올바른 엔드포인트를 사용하도록 변경한다.
Amazon Aurora DB 클러스터는 하나 이상의 DB 인스턴스와 그러한 DB 인스턴스를 위해 데이터를 관리하는 클러스터 볼륨으로 구성되어 있습니다. Aurora 클러스터 볼륨은 다수의 가용 영역(AZ)에 걸쳐 있는 가상 데이터베이스 스토리지 볼륨이며 각각의 AZ에 DB 클러스터 데이터의 사본이 있습니다. 두 가지 유형의 DB 인스턴스가 Aurora DB 클러스터를 구성합니다.
기본(Primary) DB 인스턴스 - 읽기와 쓰기 작업을 지원하고 클러스터 볼륨에 대한 모든 데이터 수정 작업을 수행합니다. 모든 Aurora DB 클러스터에는 기본 DB 인스턴스가 1개씩 있습니다.
Aurora 레플리카 – 기본 DB 인스턴스와 동일한 스토리지 볼륨에 연결되고 읽기 작업만 지원합니다. 모든 Aurora DB 클러스터에는 기본 DB 인스턴스 이외에 최대 15개의 Aurora 레플리카가 있을 수 있습니다. 기본 DB 인스턴스를 사용할 수 없게 되면 Aurora는 자동으로 Aurora 레플리카로 페일오버(fail-over)가 됩니다. 여러분은 Aurora 레플리카에 페일오버 우선순위를 지정할 수 있습니다. Aurora 레플리카는 또한 기본 DB 인스턴스의 읽기 워크로드를 줄일 수도 있습니다.
Aurora 레플리카에는 두 가지 목적이 있습니다. 여러분은 레플리카에 쿼리를 보내어 애플리케이션을 위해 읽기 작업을 스케일링할 수 있습니다. 일반적으로는 클러스터의 읽기 엔드포인트에 연결하여 그렇게 합니다. 그렇게 하면 Aurora가 읽기 전용 연결에 관한 로드를 여러분이 클러스터에 가진 Aurora 레플리카의 수만큼 분산시킬 수 있습니다. Aurora 레플리카는 가용성 향상에도 도움을 줍니다. 만일 클러스터의 쓰기 인스턴스를 사용할 수 없게 되면 Aurora는 자동으로 읽기 인스턴스 중 하나가 새로운 쓰기 인스턴스로서 그 자리를 대체하도록 합니다.
Aurora를 위해 Multi-AZ 배포를 설정할 때 여러분은 다른 AZ에서 Aurora 레플리카 또는 읽기 노드를 생성할 수 있습니다.
여러분은 Aurora 클러스터의 읽기 전용 연결에 대해 읽기 엔드포인트를 사용할 수 있습니다. 이 엔드포인트는 로드 밸런싱 메커니즘을 사용하여 여러분의 클러스터가 쿼리 집약적인 워크로드를 처리할 수 있게 도와줍니다. 읽기 엔드포인트는 클러스터에서 보고 또는 기타 읽기 전용 작업을 하는 애플리케이션에 제공하는 엔드포인트입니다. 읽기 엔드포인트는 Aurora DB 클러스터 안에서 가용한 Aurora 레플리카에 대한 연결들에 로드 밸런싱을 합니다.