AWS SAA 합격으로 가는 길 #113

안녕하세요! 넥스트클라우드의 SA 김유림입니다.☺️

어느덧 여름이 지나가고 공식적인 가을이 찾아오고 있습니다. 공부를 하시는 여러분께도 시원한 결과가 찾아오기를 바랍니다!

 

문제는 세 가지 단계를 거치며 풀어 나가 보겠습니다!

1. 문제의 요구사항 분석하기

2. 관련 AWS 서비스 생각하기

3. 선택지 분석하기

 

바로 문제 풀이 해볼까요?

 

 

---

문제1

회사는 Amazon EC2 인스턴스와 Amazon Elastic Block Store(Amazon EBS) 볼륨을 사용하여 애플리케이션을 실행합니다. 회사는 규정 준수 요구 사항을 충족하기 위해 매일 각 EBS 볼륨에 대해 하나의 스냅샷을 생성합니다. 회사는 EBS 볼륨 스냅샷이 실수로 삭제되는 것을 방지하는 아키텍처를 구현하려고 합니다. 솔루션은 스토리지 관리자 사용자의 관리 권한을 변경해서는 안 됩니다. 최소한의 관리 노력으로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

선택지

A. 스냅샷 삭제 권한이 있는 IAM 역할을 생성합니다. 새 EC2 인스턴스에 역할을 연결합니다. 스냅샷을 삭제하려면 새 EC2 인스턴스에서 AWS CLI를 사용하세요.

B. 스냅샷 삭제를 거부하는 IAM 정책을 생성합니다. 스토리지 관리자 사용자에게 정책을 연결합니다.

C. 스냅샷에 태그를 추가합니다. 태그가 있는 EBS 스냅샷에 대해 휴지통에 보관 규칙을 만듭니다.

D. 삭제를 방지하기 위해 EBS 스냅샷을 잠급니다.

 

풀이

EBS 스냅샷을 실수로 삭제되지 않도록 하기 위해서는 EBS 스냅샷 잠금 기능을 활용하는 것이 가장 적절한 솔루션입니다. EBS 스냅샷을 잠그면 삭제나 수정이 불가능해져 실수로 삭제되는 것을 방지할 수 있습니다. 또한 스토리지 관리자의 권한을 변경할 필요 없이 구현할 수 있어 요구사항을 모두 충족합니다.

정답 : D

 

▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.

1.  문제의 요구사항 분석하기

• EBS 볼륨에 대해 매일 스냅샷 생성
• 실수로 EBS 볼륨 스냅샷이 삭제되는 것을 방지
• 스토리지 관리자 사용자의 권한 변경 없이 구현

2. 관련 AWS 서비스 생각하기

• Amazon EBS(Elastic Block Store)는 Amazon EC2 인스턴스에 영구적인 블록 스토리지 볼륨을 제공하는 서비스입니다. EBS 볼륨을 사용하면 EC2 인스턴스에 데이터를 영구적으로 저장할 수 있습니다. EBS 볼륨은 EC2 인스턴스와 독립적으로 존재하며, 인스턴스에 연결하거나 분리할 수 있습니다.
  • EBS 스냅샷은 지정된 시간의 EBS 볼륨 데이터를 백업하는 기능입니다. 스냅샷은 증분식으로 저장되어 스토리지 비용이 절감되며, 이 스냅샷을 사용하여 새로운 EBS 볼륨을 복원할 수 있습니다. EBS 스냅샷은 동일 AWS 리전 내에서 복사할 수 있고, 다른 리전으로 공유할 수도 있습니다.
  • EBS 스냅샷 잠금 기능은 실수로 인한 스냅샷 삭제를 방지합니다. 스냅샷을 잠그면 해당 스냅샷은 삭제되거나 수정될 수 없습니다. 스냅샷 잠금은 스냅샷 수명 주기 동안 유지되며, 필요에 따라 잠금을 해제할 수 있습니다.
• IAM(Identity and Access Management)은 AWS 리소스에 대한 액세스를 안전하게 제어할 수 있는 웹 서비스입니다. IAM을 통해 AWS 계정 내 사용자, 그룹 및 역할에 권한을 부여할 수 있습니다. IAM 정책을 사용하면 특정 AWS 리소스에 대한 액세스를 허용하거나 거부할 수 있습니다.

3. 선택지 분석하기

A. 스냅샷 삭제 권한이 있는 IAM 역할을 생성합니다. 새 EC2 인스턴스에 역할을 연결합니다. 스냅샷을 삭제하려면 새 EC2 인스턴스에서 AWS CLI를 사용하세요.

→ 스냅샷 삭제 권한이 있는 IAM 역할을 생성하고 새 EC2 인스턴스에 역할을 연결하여 스냅샷을 삭제하는 방식은 관리 복잡성을 높이고 보안 위험을 초래할 수 있습니다. 또한 실수로 삭제될 위험이 있어 요구사항에 부합하지 않습니다.

B. 스냅샷 삭제를 거부하는 IAM 정책을 생성합니다. 스토리지 관리자 사용자에게 정책을 연결합니다.

→ 스냅샷 삭제를 거부하는 IAM 정책을 스토리지 관리자 사용자에게 연결하는 방식은 요구사항에 부합하지 않습니다. 관리자 권한을 변경해서는 안 되기 때문입니다.

C. 스냅샷에 태그를 추가합니다. 태그가 있는 EBS 스냅샷에 대해 휴지통에 보관 규칙을 만듭니다.

→ EBS 스냅샷에 태그를 추가하고 태그가 있는 스냅샷에 대해 휴지통 보관 규칙을 만드는 것은 관리 오버헤드가 발생할 수 있습니다. 또한 스냅샷을 완전히 보호하지 못할 수 있어 요구사항을 충족하기 어렵습니다.

D. 삭제를 방지하기 위해 EBS 스냅샷을 잠급니다.

→ 삭제를 방지하기 위해 EBS 스냅샷을 잠그는 것이 가장 간단하고 효과적인 방법입니다. 스토리지 관리자의 권한을 변경할 필요가 없으며, 실수로 삭제되는 것을 완벽하게 방지할 수 있습니다.

 

 

이어서 다음 문제입니다.

---

문제2

회사의 IT 비용에 대한 최근 분석에서는 백업 비용을 줄여야 할 필요성이 강조되었습니다. 회사의 최고 정보 책임자는 온프레미스 백업 인프라를 단순화하고 물리적 백업 테이프 사용을 제거하여 비용을 절감하고자 합니다. 회사는 온프레미스 백업 애플리케이션 및 워크플로우에 대한 기존 투자를 보존해야 합니다. 솔루션 설계자는 무엇을 추천해야 합니까?

 

선택지

A. NFS 인터페이스를 사용하여 백업 애플리케이션과 연결하도록 AWS Storage Gateway를 설정합니다.

B. NFS 인터페이스를 사용하여 백업 애플리케이션과 연결하는 Amazon EFS 파일 시스템을 설정합니다.

C. iSCSI 인터페이스를 사용하여 백업 애플리케이션과 연결하는 Amazon EFS 파일 시스템을 설정합니다.

D. iSCSI-가상 테이프 라이브러리(VTL) 인터페이스를 사용하여 백업 애플리케이션과 연결하도록 AWS Storage Gateway를 설정합니다.

 

풀이

온프레미스 백업 인프라를 단순화하고 물리적 백업 테이프 사용을 제거하면서도 기존 투자를 보존하기 위해서는 AWS Storage Gateway의 iSCSI-가상 테이프 라이브러리(VTL) 인터페이스를 사용하여 온프레미스 백업 애플리케이션과 연결하는 것이 가장 적절한 솔루션입니다.

 

정답 : D

 

▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.

1.  문제의 요구사항 분석하기

• 백업 비용 절감을 위해 온프레미스 백업 인프라 단순화
• 물리적 백업 테이프 사용 제거
• 기존 온프레미스 백업 애플리케이션 및 워크플로우 투자 보존

2. 관련 AWS 서비스 생각하기

• AWS Storage Gateway는 온프레미스 환경과 AWS 스토리지 서비스 간의 브리지 역할을 하는 하이브리드 스토리지 서비스입니다. 스토리지 게이트웨이는 온프레미스 환경에서 실행되며, 클라우드 스토리지를 로컬 스토리지처럼 사용할 수 있게 해줍니다. 이 서비스는 세 가지 유형의 인터페이스를 제공합니다:
  • 파일 게이트웨이(File Gateway)는 NFS(Network File System) 및 SMB(Server Message Block) 프로토콜을 지원합니다. 이를 통해 온프레미스 환경에서 Amazon S3와 같은 클라우드 스토리지에 파일 데이터를 저장하고 액세스할 수 있습니다.
  • 볼륨 게이트웨이(Volume Gateway)는 iSCSI(Internet Small Computer System Interface) 블록 프로토콜을 지원합니다. 이를 통해 온프레미스 애플리케이션에서 Amazon EBS(Elastic Block Store) 볼륨에 저장된 데이터에 액세스할 수 있습니다.
  • 가상 테이프 라이브러리(Virtual Tape Library, VTL) 인터페이스는 백업 애플리케이션과 연동되어 가상 테이프를 클라우드 스토리지(예: Amazon S3)에 저장할 수 있게 해줍니다. 이를 통해 물리적 테이프 사용을 대체할 수 있습니다.
• VTL(Virtual Tape Library)은 온프레미스 백업 애플리케이션과 호환되므로 기존 백업 워크플로우와 투자를 그대로 유지할 수 있습니다. 또한 물리적 테이프 대신 클라우드 스토리지를 사용하여 비용을 절감할 수 있습니다.

3. 선택지 분석하기

 

A. NFS 인터페이스를 사용하여 백업 애플리케이션과 연결하도록 AWS Storage Gateway를 설정합니다.

→ NFS 인터페이스를 사용하여 백업 애플리케이션과 연결하도록 AWS Storage Gateway를 설정하는 방식은 파일 백업에는 적합하지만, 전통적인 백업 애플리케이션과는 호환되지 않습니다.

B. NFS 인터페이스를 사용하여 백업 애플리케이션과 연결하는 Amazon EFS 파일 시스템을 설정합니다.

→ NFS 인터페이스를 사용하여 백업 애플리케이션과 연결하는 Amazon EFS 파일 시스템을 설정하는 방식도 A와 마찬가지로 백업 애플리케이션과 호환되지 않습니다.

C. iSCSI 인터페이스를 사용하여 백업 애플리케이션과 연결하는 Amazon EFS 파일 시스템을 설정합니다.

→ iSCSI 인터페이스를 사용하여 백업 애플리케이션과 연결하는 Amazon EFS 파일 시스템을 설정하는 방식은 EFS가 파일 스토리지 서비스이므로 적절하지 않습니다.

D. iSCSI-가상 테이프 라이브러리(VTL) 인터페이스를 사용하여 백업 애플리케이션과 연결하도록 AWS Storage Gateway를 설정합니다.

→ iSCSI-가상 테이프 라이브러리(VTL) 인터페이스를 사용하여 백업 애플리케이션과 연결하도록 AWS Storage Gateway를 설정하는 것이 가장 적합한 솔루션입니다. 이렇게 하면 기존 백업 애플리케이션과 워크플로우를 그대로 사용할 수 있으며, 물리적 테이프 사용을 제거하고 백업 인프라를 간소화할 수 있습니다.

 

마지막 문제 살펴보겠습니다.

---

문제3

빠르게 성장하고 있는 음식 배달 서비스를 제공하는 회사가 있습니다. 성장으로 인해 회사의 주문 처리 시스템은 최대 트래픽 시간 동안 확장 문제를 겪고 있습니다. 현재 아키텍처에는 다음이 포함됩니다.

 

• Amazon EC2 Auto Scaling Amazon EC2 애플리케이션에서 주문을 수집하기 위해 그룹에서 실행되는 인스턴스 그룹
• Amazon EC2 Auto Scaling EC2 주문을 이행하기 위해 그룹에서 실행되는 다른 인스턴스 그룹

 

주문 수집 프로세스는 빠르게 진행되지만 주문 이행 프로세스는 더 오래 걸릴 수 있습니다. 스케일링 이벤트로 인해 데이터가 손실되어서는 안 됩니다. 솔루션 설계자는 주문 수집 프로세스와 주문 이행 프로세스가 트래픽이 가장 많은 시간에 적절하게 확장될 수 있는지 확인해야 합니다. 솔루션은 회사의 리소스 활용을 최적화해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

 

선택지

A. Amazon CloudWatch 지표를 활용하여 Auto Scaling 그룹에 있는 각 인스턴스의 CPU를 모니터링합니다. 최대 워크로드 값에 따라 각 Auto Scaling 그룹의 최소 용량을 구성합니다.

B. Amazon CloudWatch 지표를 사용하여 Auto Scaling 그룹에 있는 각 인스턴스의 CPU를 모니터링합니다. 요청 시 추가 Auto Scaling 그룹을 생성하는 Amazon Simple Notification Service(Amazon SNS) 주제를 호출하도록 CloudWatch 경보를 구성합니다.

C. 2개의 Amazon Simple Queue Service(Amazon SQS) 대기열을 프로비저닝합니다. 하나는 주문 수집용이고 다른 하나는 주문 이행용입니다. 각 대기열을 폴링하도록 EC2 인스턴스를 구성합니다. 대기열이 보내는 알림을 기반으로 Auto Scaling 그룹을 조정합니다.

D. 2개의 Amazon Simple Queue Service(Amazon SQS) 대기열을 프로비저닝합니다. 하나는 주문 수집용이고 다른 하나는 주문 이행용입니다. 각 대기열을 폴링하도록 EC2 인스턴스를 구성합니다. 인스턴스 계산당 백로그를 기반으로 지표를 만듭니다. 이 지표를 기반으로 Auto Scaling 그룹을 조정합니다.

 

풀이

주문 수집 프로세스와 주문 이행 프로세스를 분리하고, 각각의 프로세스에 대해 Amazon SQS 대기열을 별도로 프로비저닝해야 합니다. 각 대기열을 폴링하도록 EC2 인스턴스를 구성한 후, 대기열의 메시지 백로그를 기반으로 지표를 만들어 Auto Scaling 그룹을 조정하는 것이 가장 적절한 솔루션입니다. 이렇게 하면 각 프로세스의 확장성을 보장하고 데이터 손실을 방지하면서 AWS 리소스 활용을 최적화할 수 있습니다.

 

정답 : D

 

▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.

1.  문제의 요구사항 분석하기

• 주문 수집 프로세스와 주문 이행 프로세스의 확장성 보장
• 데이터 손실 방지
• AWS 리소스 활용 최적화

2. 관련 AWS 서비스 생각하기

• Amazon SQS(Simple Queue Service)는 분산 애플리케이션에서 메시지를 안전하게 전송하고 처리할 수 있는 완전관리형 메시지 대기열 서비스입니다. SQS는 메시지 배치, 중복 메시지 제거, 지연 큐 등의 기능을 제공하여 데이터 손실을 방지하고 메시지 처리 순서를 보장합니다. 또한 SQS는 자동으로 확장되므로 높은 처리량과 가용성을 제공합니다.
• Amazon EC2 Auto Scaling은 애플리케이션 트래픽에 따라 EC2 인스턴스 수를 자동으로 조정하여 확장성과 가용성을 보장하는 서비스입니다. Auto Scaling은 다양한 측정치(예: CPU 사용률, 네트워크 트래픽, 대기열 백로그 등)를 기반으로 스케일링 정책을 설정할 수 있습니다. 또한 최소/최대 인스턴스 수를 지정하여 비용을 제어할 수 있습니다.
• Amazon CloudWatch는 AWS 리소스와 애플리케이션의 모니터링 및 관찰을 제공하는 서비스입니다. CloudWatch를 통해 수집된 모니터링 데이터를 기반으로 경보를 설정하고 자동화된 작업을 트리거할 수 있습니다.

3. 선택지 분석하기

A. Amazon CloudWatch 지표를 활용하여 Auto Scaling 그룹에 있는 각 인스턴스의 CPU를 모니터링합니다. 최대 워크로드 값에 따라 각 Auto Scaling 그룹의 최소 용량을 구성합니다.

→ Auto Scaling 그룹 내 각 인스턴스의 CPU 사용률을 모니터링하고, 최대 워크로드 값에 따라 각 그룹의 최소 용량을 구성하는 방식은 주문 수집과 주문 이행 프로세스를 분리하지 않아 확장성 문제를 해결하기 어렵습니다.

B. Amazon CloudWatch 지표를 사용하여 Auto Scaling 그룹에 있는 각 인스턴스의 CPU를 모니터링합니다. 요청 시 추가 Auto Scaling 그룹을 생성하는 Amazon Simple Notification Service(Amazon SNS) 주제를 호출하도록 CloudWatch 경보를 구성합니다.

→ Auto Scaling 그룹 내 각 인스턴스의 CPU 사용률을 모니터링하고, CloudWatch 경보를 구성하여 요청 시 추가 Auto Scaling 그룹을 생성하는 방식도 프로세스 분리가 되어 있지 않아 적절하지 않습니다.

C. 두 개의 Amazon Simple Queue Service(Amazon SQS) 대기열을 프로비저닝합니다. 하나는 주문 수집용이고 다른 하나는 주문 이행용입니다. 각 대기열을 폴링하도록 EC2 인스턴스를 구성합니다. 대기열이 보내는 알림을 기반으로 Auto Scaling 그룹을 조정합니다.

→ 주문 수집과 주문 이행을 위한 별도의 SQS 대기열을 프로비저닝하고, 각 대기열을 폴링하도록 EC2 인스턴스를 구성하며, 대기열 알림을 기반으로 Auto Scaling 그룹을 조정하는 방식은 프로세스 분리와 확장성 측면에서 적절하지만, 대기열 알림만으로는 정확한 스케일링 결정이 어려울 수 있습니다.

D. 2개의 Amazon Simple Queue Service(Amazon SQS) 대기열을 프로비저닝합니다. 하나는 주문 수집용이고 다른 하나는 주문 이행용입니다. 각 대기열을 폴링하도록 EC2 인스턴스를 구성합니다. 인스턴스 계산당 백로그를 기반으로 지표를 만듭니다. 이 지표를 기반으로 Auto Scaling 그룹을 조정합니다.

→ 주문 수집과 주문 이행을 위한 별도의 SQS 대기열을 프로비저닝하고, 각 대기열을 폴링하도록 EC2 인스턴스를 구성한 후, 인스턴스 계산당 백로그를 기반으로 지표를 만들어 Auto Scaling 그룹을 조정하는 것이 가장 적절한 솔루션입니다. 이렇게 하면 각 프로세스의 확장성을 보장하고 데이터 손실을 방지하면서, 리소스 활용을 최적화할 수 있습니다.

 

감사합니다. 다음 글에서 만나요.🙂