AWS SAA 합격으로 가는 길 #192

안녕하세요! 넥스트클라우드의 테크니컬 트레이너 김유림입니다. 😊

7월도 어느덧 하순으로 접어들며 여름의 한가운데를 지나고 있네요.

주말을 앞둔 금요일, 상쾌한 마음으로 한 주를 잘 마무리해 볼까요?

 

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

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

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

3. 선택지 분석하기

 

바로 문제 풀이 시작합니다.

---

문제1

회사는 민감한 데이터를 Amazon S3에 저장합니다. 솔루션 설계자는 암호화 솔루션을 만들어야 합니다. 회사는 암호화해야 하는 모든 데이터에 대해 최소한의 노력으로 암호화 키를 생성, 순환 및 비활성화할 수 있는 사용자의 능력을 완전히 제어해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

 

선택지

A. Amazon S3 관리형 암호화 키(SSE-S3)와 함께 기본 서버 측 암호화를 사용하여 민감한 데이터를 저장합니다.
B. AWS Key Management Service(AWS KMS)를 사용하여 고객 관리형 키를 생성합니다. AWS KMS 키(SSE-KMS)로 서버 측 암호화를 사용하여 S3 객체를 암호화하려면 새 키를 사용합니다.
C. AWS Key Management Service(AWS KMS)를 사용하여 AWS 관리형 키를 생성합니다. AWS KMS 키(SSE-KMS)로 서버 측 암호화를 사용하여 S3 객체를 암호화하려면 새 키를 사용합니다.
D. S3 객체를 Amazon EC2 인스턴스로 다운로드합니다. 고객 관리 키를 사용하여 객체를 암호화합니다. 암호화된 객체를 Amazon S3에 다시 업로드합니다.

---

풀이

암호화 키의 생성, 순환, 비활성화를 사용자가 완전히 제어하는 것이 핵심입니다. AWS KMS의 고객 관리형 키는 사용자가 직접 키를 만들고 순환 주기와 비활성화를 자유롭게 관리할 수 있으며, 이를 SSE-KMS 방식으로 S3에 적용하면 최소한의 노력으로 요구 사항을 충족합니다.

 

정답 : B

 

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

---

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

• S3에 저장되는 민감한 데이터의 암호화
• 암호화 키의 생성, 순환, 비활성화를 사용자가 완전히 제어
• 키 관리를 최소한의 노력으로 수행
• 서버 측 암호화 기반의 솔루션

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

• AWS KMS (Key Management Service) : 데이터를 암호화하는 데 사용하는 암호화 키를 안전하게 생성하고 관리하는 완전관리형 서비스입니다. 다른 AWS 서비스와 연동하여 데이터를 손쉽게 암호화할 수 있으며, 키에 대한 접근 권한을 정책으로 세밀하게 통제할 수 있습니다. 관리 주체에 따라 키 유형이 나뉩니다.
  
  • 고객 관리형 키(Customer Managed Key) : 사용자가 직접 생성하고 소유하는 키로, 키 정책 설정과 자동 순환, 비활성화, 삭제까지 전 과정을 사용자가 완전히 제어할 수 있습니다. 규정 준수나 세밀한 키 관리가 필요한 경우에 적합합니다.
  • AWS 관리형 키(AWS Managed Key) : AWS가 특정 서비스를 위해 자동으로 생성하고 관리하는 키입니다. 사용이 편리하지만 순환 주기나 비활성화 같은 세부 동작을 사용자가 직접 제어할 수 없습니다.
• Amazon S3 서버 측 암호화 (SSE) : S3가 객체를 저장하는 시점에 자동으로 암호화하고 읽을 때 복호화하는 기능입니다. 사용하는 키의 관리 방식에 따라 여러 유형으로 구분됩니다.
  
  • SSE-S3 : S3가 암호화 키를 직접 관리하는 방식으로, 사용자가 키를 별도로 제어할 수 없습니다.
  • SSE-KMS : AWS KMS의 키를 사용해 암호화하는 방식으로, 고객 관리형 키를 지정하면 키의 생성과 순환, 접근 제어를 세밀하게 관리할 수 있습니다.

3. 선택지 분석하기

A. Amazon S3 관리형 암호화 키(SSE-S3)와 함께 기본 서버 측 암호화를 사용하여 민감한 데이터를 저장합니다.
→ SSE-S3는 S3가 키를 직접 관리하여 사용이 간편하지만 사용자가 키의 순환이나 비활성화를 제어할 수 없으므로, 키를 완전히 통제하려는 요구 사항에는 적절치 않습니다.

B. AWS Key Management Service(AWS KMS)를 사용하여 고객 관리형 키를 생성합니다. AWS KMS 키(SSE-KMS)로 서버 측 암호화를 사용하여 S3 객체를 암호화하려면 새 키를 사용합니다.
→ 고객 관리형 키는 생성과 순환, 비활성화를 사용자가 완전히 제어할 수 있고 이를 SSE-KMS로 S3에 적용하므로, 최소한의 노력으로 요구 사항을 충족하기에 가장 적절한 방법입니다.

C. AWS Key Management Service(AWS KMS)를 사용하여 AWS 관리형 키를 생성합니다. AWS KMS 키(SSE-KMS)로 서버 측 암호화를 사용하여 S3 객체를 암호화하려면 새 키를 사용합니다.
→ AWS 관리형 키는 AWS가 대신 관리하여 사용자가 순환 주기나 비활성화를 직접 제어할 수 없으므로, 키를 완전히 통제하려는 요구 사항에는 부합하지 않습니다.

D. S3 객체를 Amazon EC2 인스턴스로 다운로드합니다. 고객 관리 키를 사용하여 객체를 암호화합니다. 암호화된 객체를 Amazon S3에 다시 업로드합니다.
→ 객체를 내려받아 직접 암호화한 뒤 다시 올리는 방식은 사람이 개입하는 반복 작업이 많아 운영 부담이 크므로, 최소한의 노력이라는 조건에는 적절치 않습니다.

---

 

이어서 다음 문제입니다.

---

문제2

한 회사는 Amazon EC2 인스턴스와 Amazon Elastic Block Store(Amazon EBS)를 사용하여 자체 관리형 데이터베이스를 실행합니다. 이 회사는 모든 EBS 볼륨에 걸쳐 350TB의 데이터를 보유하고 있습니다. 회사는 EBS 스냅샷을 매일 촬영하여 1개월간 보관합니다. 일일 변동률은 EBS 물량의 5%입니다. 새로운 규정으로 인해 회사는 월별 스냅샷을 7년 동안 보관해야 합니다. 회사는 새로운 규정을 준수하고 관리 노력을 최소화하면서 데이터를 사용할 수 있도록 백업 전략을 변경해야 합니다. 이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?

 

선택지

A. EBS 스냅샷 표준 계층에 일일 스냅샷을 1개월 동안 보관합니다. 보존 기간이 7년인 월별 스냅샷을 Amazon S3 Glacier Deep Archive에 복사합니다.
B. 현재 EBS 스냅샷 정책을 계속 유지합니다. 보존 기간이 7년인 Amazon EBS 스냅샷 아카이브로 월간 스냅샷을 이동하는 새 정책을 추가합니다.
C. EBS 스냅샷 표준 계층에 일일 스냅샷을 1개월 동안 보관합니다. 월별 스냅샷을 7년 동안 표준 계층에 유지합니다. 증분 스냅샷을 사용합니다.
D. EBS 스냅샷 표준 계층에 일일 스냅샷을 보관합니다. EBS 다이렉트 API를 사용하여 매달 모든 EBS 볼륨의 스냅샷을 찍습니다. Infrequent Access 계층의 Amazon S3 버킷에 스냅샷을 7년 동안 저장합니다.

---

풀이

장기 보관해야 하는 월별 스냅샷의 비용을 낮추면서 관리 노력을 최소화하는 것이 핵심입니다. EBS 스냅샷 아카이브는 오래 보관하는 스냅샷을 저렴하게 저장하는 계층이며, 수명 주기 정책으로 월간 스냅샷을 자동으로 이동시키면 사람의 개입 없이 비용 효율적으로 7년 보관 요건을 충족합니다.

 

정답 : B

 

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

---

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

• 일일 스냅샷은 1개월 보관하는 기존 백업 유지
• 월별 스냅샷을 7년 동안 장기 보관하도록 변경
• 관리 노력을 최소화하며 가장 비용 효율적인 저장 방식

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

• Amazon EBS (Elastic Block Store) : EC2 인스턴스에 연결하여 사용하는 블록 스토리지 서비스로, 데이터베이스나 파일 시스템처럼 지속적으로 읽고 쓰는 데이터를 저장하는 데 사용됩니다. 볼륨의 특정 시점 상태를 백업하기 위해 스냅샷 기능을 제공합니다.
  
  • EBS 스냅샷(Snapshot) : 볼륨의 특정 시점을 백업하는 기능으로, 변경된 부분만 저장하는 증분 방식으로 동작해 효율적입니다. 기본적으로 자주 접근하는 표준 계층에 저장됩니다.
  • EBS 스냅샷 아카이브(Snapshot Archive) : 오래 보관해야 하지만 자주 사용하지 않는 스냅샷을 위한 저비용 계층입니다. 표준 계층보다 훨씬 저렴하게 장기 보관할 수 있으며, 필요할 때 복원하여 사용할 수 있습니다. 장기 규정 준수 목적의 보관에 적합합니다.
• Amazon Data Lifecycle Manager : EBS 스냅샷의 생성, 보존, 계층 이동, 삭제를 정책으로 자동화하는 서비스입니다. 한 번 정책을 설정해 두면 정해진 일정에 따라 스냅샷이 자동으로 관리되므로, 사람이 수동으로 처리하는 노력을 크게 줄일 수 있습니다.

3. 선택지 분석하기

A. EBS 스냅샷 표준 계층에 일일 스냅샷을 1개월 동안 보관합니다. 보존 기간이 7년인 월별 스냅샷을 Amazon S3 Glacier Deep Archive에 복사합니다.
→ EBS 스냅샷을 S3 Glacier Deep Archive로 직접 복사하는 것은 기본으로 지원되는 방식이 아니어서 별도의 변환과 관리 작업이 필요하므로, 관리 노력을 최소화하려는 요구 사항에는 적절치 않습니다.

B. 현재 EBS 스냅샷 정책을 계속 유지합니다. 보존 기간이 7년인 Amazon EBS 스냅샷 아카이브로 월간 스냅샷을 이동하는 새 정책을 추가합니다.
→ 기존 일일 스냅샷 정책은 그대로 두고 월간 스냅샷만 저비용 아카이브 계층으로 자동 이동하므로, 비용을 낮추면서 관리 노력을 최소화하기에 가장 적절한 방법입니다.

C. EBS 스냅샷 표준 계층에 일일 스냅샷을 1개월 동안 보관합니다. 월별 스냅샷을 7년 동안 표준 계층에 유지합니다. 증분 스냅샷을 사용합니다.
→ 월별 스냅샷을 7년 내내 표준 계층에 두면 저비용 아카이브 계층을 활용하는 방식에 비해 저장 비용이 크게 늘어나므로, 비용 효율성 측면에서 적절치 않습니다.

D. EBS 스냅샷 표준 계층에 일일 스냅샷을 보관합니다. EBS 다이렉트 API를 사용하여 매달 모든 EBS 볼륨의 스냅샷을 찍습니다. Infrequent Access 계층의 Amazon S3 버킷에 스냅샷을 7년 동안 저장합니다.
→ EBS 다이렉트 API로 스냅샷을 직접 다뤄 S3에 저장하려면 별도의 개발과 운영이 필요해 관리 부담이 크므로, 관리 노력을 최소화하려는 조건에는 적절치 않습니다.

---

 

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

---

문제3

일기 예보 회사는 밀리초 미만의 대기 시간으로 수백 기가바이트의 데이터를 처리해야 합니다. 이 회사는 데이터 센터에 HPC(고성능 컴퓨팅) 환경을 보유하고 있으며 예측 기능을 확장하려고 합니다. 솔루션 설계자는 대량의 지속적인 처리량을 처리할 수 있는 고가용성 클라우드 스토리지 솔루션을 식별해야 합니다. 솔루션에 저장된 파일은 전체 데이터 세트에 동시에 액세스하고 처리하는 수천 개의 컴퓨팅 인스턴스에 액세스할 수 있어야 합니다. 솔루션 설계자는 이러한 요구 사항을 충족하기 위해 무엇을 해야 합니까?

 

선택지

A. Lustre 스크래치 파일 시스템에는 Amazon FSx를 사용하십시오.
B. Lustre 영구 파일 시스템에는 Amazon FSx를 사용하십시오.
C. 버스팅 처리량 모드와 함께 Amazon Elastic File System(Amazon EFS)을 사용합니다.
D. 프로비저닝된 처리량 모드와 함께 Amazon Elastic File System(Amazon EFS)을 사용합니다.

---

풀이

밀리초 미만의 지연과 대량의 지속적인 처리량, 그리고 고가용성을 동시에 만족하는 HPC용 스토리지가 핵심입니다. FSx for Lustre의 영구 파일 시스템은 초저지연과 높은 처리량을 제공하면서 데이터를 자동으로 복제해 내구성과 가용성을 확보하므로 요구 사항에 가장 적합합니다.

 

정답 : B

 

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

---

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

• 밀리초 미만의 매우 낮은 지연 시간으로 데이터 처리
• 대량의 지속적인 처리량이 필요한 HPC 워크로드
• 수천 개의 컴퓨팅 인스턴스가 동시에 접근
• 고가용성을 갖춘 클라우드 스토리지

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

• Amazon FSx for Lustre : 고성능 컴퓨팅(HPC), 머신러닝, 대규모 분석처럼 빠른 처리 속도가 필요한 작업을 위해 설계된 완전관리형 병렬 파일 시스템입니다. 밀리초 미만의 매우 낮은 지연 시간과 대단히 높은 처리량을 제공하며, 수많은 컴퓨팅 인스턴스가 하나의 데이터 세트에 동시에 접근하도록 지원합니다.
  
  • 스크래치 파일 시스템(Scratch) : 임시적인 단기 처리를 위한 유형으로 높은 성능을 제공하지만, 데이터를 여러 곳에 복제하지 않아 하드웨어 장애 시 데이터가 유실될 수 있어 내구성과 가용성이 낮습니다.
  • 영구 파일 시스템(Persistent) : 장기간 사용을 위한 유형으로, 데이터를 자동으로 복제하고 장애가 발생한 구성 요소를 자동으로 복구하여 높은 내구성과 가용성을 제공합니다. 지속적으로 유지되어야 하는 중요한 워크로드에 적합합니다.
• Amazon EFS (Elastic File System) : 여러 EC2 인스턴스가 동시에 공유하여 사용할 수 있는 완전관리형 파일 스토리지 서비스입니다. 용량이 자동으로 확장되고 관리가 편리하지만, HPC 환경에서 요구하는 밀리초 미만의 초저지연과 초고처리량 측면에서는 병렬 파일 시스템에 비해 성능이 낮은 편입니다.
  
  • 버스팅 처리량 모드 : 저장된 데이터 양에 비례해 처리량이 결정되며, 순간적으로 필요할 때 성능을 끌어올리는 방식입니다.
  • 프로비저닝된 처리량 모드 : 저장 용량과 무관하게 원하는 처리량을 미리 지정하는 방식으로, 일정한 성능이 필요할 때 사용합니다.

3. 선택지 분석하기

A. Lustre 스크래치 파일 시스템에는 Amazon FSx를 사용하십시오.
→ 스크래치 파일 시스템은 높은 성능을 제공하지만 데이터를 복제하지 않아 장애 시 유실 위험이 있으므로, 고가용성을 요구하는 조건에는 적절치 않습니다.

B. Lustre 영구 파일 시스템에는 Amazon FSx를 사용하십시오.
→ 영구 파일 시스템은 밀리초 미만의 지연과 높은 처리량을 제공하면서 데이터 복제로 고가용성까지 확보하므로, HPC 워크로드의 요구 사항을 충족하기에 가장 적절한 방법입니다.

C. 버스팅 처리량 모드와 함께 Amazon Elastic File System(Amazon EFS)을 사용합니다.
→ EFS는 편리한 공유 스토리지이지만 버스팅 모드는 지속적인 대량 처리량을 안정적으로 보장하기 어렵고 HPC의 초저지연 요건에도 미치지 못하므로 적절치 않습니다.

D. 프로비저닝된 처리량 모드와 함께 Amazon Elastic File System(Amazon EFS)을 사용합니다.
→ 프로비저닝 모드로 처리량을 높일 수는 있으나 EFS 자체가 병렬 파일 시스템만큼의 밀리초 미만 지연과 처리 성능을 제공하지 못하므로, HPC 요구 사항에는 적절치 않습니다.

---

 

오늘 세 문제는 데이터 암호화, 장기 백업, 그리고 고성능 스토리지까지 실무의 핵심 주제들을 두루 담았습니다.

무더운 여름 금요일, 한 주를 잘 마무리해 주셔서 감사합니다. 즐거운 주말 보내시고 다음 시간에 또 만나요! 😊