본문 바로가기
AWS/SAA 준비

AWS SAA 합격으로 가는 길 #6: [CloudWatch] 마스터하기

by Pacloud 2024. 8. 19.
반응형

안녕하세요, AWS SAA(Solution Architect Associate) 자격증을 준비하시는 여러분!

저는 넥스트클라우드에서 SA로 활동하고 있는 손유림이라고 합니다. 😊

 

문제는 세 가지 단계를 거치며 풀어나갈 거예요:

 

  1. 문제의 요구사항 분석하기
  2. 관련 AWS 서비스 생각하기
  3. 선택지 분석하기

 

자, 그럼 첫 번째 문제부터 살펴볼까요?

문제

개발 팀은 성능 개선 도우미가 활성화된 MySQL DB 인스턴스용 범용 Amazon RDS에서 매월 리소스 집약적인 테스트를 실행합니다.

테스트는 한 달에 한 번 48시간 동안 진행되며 데이터베이스를 사용하는 유일한 프로세스입니다.

팀은 DB 인스턴스의 컴퓨팅 및 메모리 속성을 줄이지 않고 테스트 실행 비용을 줄이려고 합니다.

이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?

선택지

1. 테스트가 완료되면 DB 인스턴스를 중지합니다. 필요한 경우 DB 인스턴스를 다시 시작합니다.

2. DB 인스턴스와 함께 Auto Scaling 정책을 사용하여 테스트가 완료되면 자동으로 조정합니다.

3. 테스트가 완료되면 스냅샷을 생성합니다. 필요한 경우 DB 인스턴스를 종료하고 스냅샷을 복원합니다.

4. 테스트가 완료되면 DB 인스턴스를 저용량 인스턴스로 수정한다. 필요한 경우 DB 인스턴스를 다시 수정합니다.

요구사항에 맞는 서비스

1. 매월 한 번, 48시간 동안 리소스 집약적인 테스트를 실행

  • Amazon RDS (Relational Database Service) Reserved Instances : 장기간 사용할 데이터베이스 인스턴스를 예약함으로써 비용을 절감할 수 있는 옵션을 제공합니다. 매월 반복되는 테스트에 대해 인스턴스를 예약하여 On-Demand 요금보다 낮은 비용으로 서비스를 이용할 수 있습니다.

2. DB 인스턴스의 컴퓨팅 및 메모리 속성을 줄이지 않고 테스트 실행 비용 줄임

  • Amazon RDS Stop/Start : 필요하지 않은 기간 동안 데이터베이스 인스턴스를 중지(stop)할 수 있는 기능을 제공합니다. 테스트가 없는 기간 동안 인스턴스를 중지하고, 테스트가 시작되기 전에 다시 시작하여 비용을 절감할 수 있습니다.
  • Amazon RDS Snapshots : 특정 시점의 데이터베이스 상태를 저장하고 필요할 때 복원할 수 있습니다. 테스트 종료 후 스냅샷을 생성하고 인스턴스를 중지하거나 삭제함으로써 불필요한 비용을 절감할 수 있습니다. 다음 테스트 전에 스냅샷을 복원하여 원래 상태로 돌아갈 수 있습니다.

최적의 정답 선택하기

선택지 1번은 “테스트가 완료되면 DB 인스턴스를 중지합니다. 필요한 경우 DB 인스턴스를 다시 시작합니다.”입니다.

→ 선택지가 정답이 아닌 이유는 인스턴스를 중지하는 동안 비용을 줄일 수 있지만, 인스턴스를 중지하고 다시 시작하는 과정에서의 관리 복잡성도 고려해야 합니다.

 

선택지 2번은 “DB 인스턴스와 함께 Auto Scaling 정책을 사용하여 테스트가 완료되면 자동으로 조정합니다.”입니다.

→ 선택지가 정답이 아닌 이유는 Auto Scaling 정책은 컴퓨팅 및 메모리 리소스를 자동으로 조정할 수 없으므로, 테스트 실행 비용을 줄이는 데 적합하지 않기 때문입니다. 또한, 테스트 후 자동으로 리소스를 조정할 방법이 없기 때문에 문제의 요구사항을 제대로 충족하지 못합니다.

 

선택지 3번은 “테스트가 완료되면 스냅샷을 생성합니다. 필요한 경우 DB 인스턴스를 종료하고 스냅샷을 복원합니다.”입니다.

→ 이 선택지는 테스트가 완료된 후 비용을 절감할 수 있는 가장 효과적인 방법입니다. 인스턴스를 종료함으로써 불필요한 리소스 비용이 발생하지 않으며, 스냅샷을 통해 데이터 손실 없이 환경을 복원할 수 있습니다. 

 

선택지 4번은 “테스트가 완료되면 DB 인스턴스를 저용량 인스턴스로 수정한다. 필요한 경우 DB 인스턴스를 다시 수정합니다.”입니다.

→ 선택지가 정답이 아닌 이유는 인스턴스를 저용량 인스턴스로 수정하는 것은 비용 절감에 도움이 될 수 있지만, 인스턴스를 자주 변경하는 것은 복잡성과 다운타임을 증가시킬 수 있기 때문입니다. 테스트 시점에 맞추어 인스턴스를 수정하는 것도 시간 소모가 발생할 수 있어, 효율적이지 않습니다.

 

 

문제에 대한 정답은 선택지 3번입니다!

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

더보기

첫 번째 과정은 “문제의 요구사항 분석하기”입니다.

이 문제에서는 2가지의 요구사항이 존재해요. 

 

1. 매월 한 번, 48시간 동안 리소스 집약적인 테스트를 실행

2. DB 인스턴스의 컴퓨팅 및 메모리 속성을 줄이지 않고 테스트 실행 비용 줄임 

 

두 번째 과정은 “요구사항과 관련된 AWS 서비스 생각하기”입니다.

1. 매월 한 번, 48시간 동안 리소스 집약적인 테스트를 실행

  • Amazon RDS (Relational Database Service) Reserved Instances : 장기간 사용할 데이터베이스 인스턴스를 예약함으로써 비용을 절감할 수 있는 옵션을 제공합니다. 매월 반복되는 테스트에 대해 인스턴스를 예약하여 On-Demand 요금보다 낮은 비용으로 서비스를 이용할 수 있습니다.

2. DB 인스턴스의 컴퓨팅 및 메모리 속성을 줄이지 않고 테스트 실행 비용 줄임 

  • Amazon RDS Stop/Start : 필요하지 않은 기간 동안 데이터베이스 인스턴스를 중지(stop)할 수 있는 기능을 제공합니다. 테스트가 없는 기간 동안 인스턴스를 중지하고, 테스트가 시작되기 전에 다시 시작하여 비용을 절감할 수 있습니다.
  • Amazon RDS Snapshots : 특정 시점의 데이터베이스 상태를 저장하고 필요할 때 복원할 수 있습니다. 테스트 종료 후 스냅샷을 생성하고 인스턴스를 중지하거나 삭제함으로써 불필요한 비용을 절감할 수 있습니다. 다음 테스트 전에 스냅샷을 복원하여 원래 상태로 돌아갈 수 있습니다.

마지막 과정은 “위의 정보들을 토대로 정답 선택하기”입니다.

선택지 1번은 “테스트가 완료되면 DB 인스턴스를 중지합니다. 필요한 경우 DB 인스턴스를 다시 시작합니다.”입니다.

 

  • Amazon RDS Stop/Start: Amazon RDS는 데이터베이스 인스턴스를 필요하지 않을 때 중지할 수 있는 기능을 제공합니다. 중지된 인스턴스는 스토리지 비용 외에는 요금이 발생하지 않으며, 필요할 때 인스턴스를 다시 시작할 수 있습니다.

이 선택지가 정답이 아닌 이유는 인스턴스를 중지하는 동안 비용을 줄일 수 있지만, 인스턴스를 중지하고 다시 시작하는 과정에서의 관리 복잡성도 고려해야 하기 때문입니다.

 

선택지 2번은 “DB 인스턴스와 함께 Auto Scaling 정책을 사용하여 테스트가 완료되면 자동으로 조정합니다.”입니다.

 

  • Amazon RDS Auto Scaling: Amazon RDS에서 Auto Scaling은 주로 스토리지 용량에 대한 자동 확장에 중점을 두고 있으며, 컴퓨팅 및 메모리 리소스에 대한 자동 확장은 지원되지 않습니다. 이 기능은 특정 사용 사례에서 유용할 수 있지만, 현재 문제의 요구사항에는 적합하지 않습니다.

이 선택지가 정답이 아닌 이유는 Auto Scaling 정책은 컴퓨팅 및 메모리 리소스를 자동으로 조정할 수 없으므로, 테스트 실행 비용을 줄이는 데 적합하지 않기 때문입니다. 또한, 테스트 후 자동으로 리소스를 조정할 방법이 없기 때문에 문제의 요구사항을 제대로 충족하지 못합니다.

 

선택지 3번은 “테스트가 완료되면 스냅샷을 생성합니다. 필요한 경우 DB 인스턴스를 종료하고 스냅샷을 복원합니다.”입니다.

 

  • Amazon RDS Snapshots: RDS 스냅샷은 데이터베이스의 특정 시점 상태를 저장하고, 필요할 때 이를 복원할 수 있는 기능을 제공합니다. 테스트가 완료된 후 인스턴스를 종료하면 인스턴스 운영 비용을 줄일 수 있으며, 다음 테스트 시 스냅샷을 복원하여 동일한 환경에서 테스트를 재개할 수 있습니다.

이 선택지가 테스트가 완료된 후 비용을 절감할 수 있는 가장 효과적인 방법입니다. 인스턴스를 종료함으로써 불필요한 리소스 비용이 발생하지 않으며, 스냅샷을 통해 데이터 손실 없이 환경을 복원할 수 있습니다. 

 

선택지 4번은 “테스트가 완료되면 DB 인스턴스를 저용량 인스턴스로 수정한다. 필요한 경우 DB 인스턴스를 다시 수정합니다.”입니다.

 

  • Amazon RDS Instance Modification: Amazon RDS는 인스턴스 유형을 변경할 수 있는 기능을 제공합니다. 이를 통해 더 낮은 리소스를 사용하는 인스턴스로 전환하여 비용을 절감할 수 있습니다. 그러나 이 과정에서 다운타임이 발생할 수 있으며, 인스턴스를 다시 고성능으로 변경하는 과정에서도 추가적인 관리가 필요합니다.

이 선택지가 정답이 아닌 이유는 인스턴스를 저용량 인스턴스로 수정하는 것은 비용 절감에 도움이 될 수 있지만, 인스턴스를 자주 변경하는 것은 복잡성과 다운타임을 증가시킬 수 있기 때문입니다. 테스트 시점에 맞추어 인스턴스를 수정하는 것도 시간 소모가 발생할 수 있어, 효율적이지 않습니다.

 

 

이어서 두 번째 문제 살펴볼게요.

문제

회사에서 새 애플리케이션을 출시하고 Amazon CloudWatch 대시보드에 애플리케이션 지표를 표시합니다.

회사의 제품 관리자는 이 대시보드에 정기적으로 액세스해야 합니다.

제품 관리자에게 AWS 계정이 없습니다.

솔루션 설계자는 최소 권한 원칙에 따라 제품 관리자에게 액세스 권한을 제공해야 합니다.

이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

선택지

1. CloudWatch 콘솔에서 대시보드를 공유합니다. 제품 관리자의 이메일 주소를 입력하고 공유 단계를 완료합니다. 제품 관리자에게 대시보드에 대한 공유 가능한 링크를 제공합니다.

2. 제품 관리자 전용 IAM 사용자를 생성합니다. CloudWatchReadOnlyAccess AWS 관리형 정책을 사용자에게 연결합니다. 새 로그인 자격 증명을 제품 관리자와 공유하십시오. 올바른 대시보드의 브라우저 URL을 제품 관리자와 공유하십시오.

3. 회사 직원을 위한 IAM 사용자를 생성합니다. ViewOnlyAccess AWS 관리형 정책을 IAM 사용자에게 연결합니다. 새 로그인 자격 증명을 제품 관리자와 공유하십시오. 제품 관리자에게 CloudWatch 콘솔로 이동하여 대시보드 섹션에서 이름으로 대시보드를 찾도록 요청하십시오.

4. 퍼블릭 서브넷에 배스천 서버를 배포합니다. 제품 관리자가 대시보드에 액세스해야 하는 경우 서버를 시작하고 RDP 자격 증명을 공유합니다. 배스천 서버에서 브라우저가 대시보드를 볼 수 있는 적절한 권한이 있는 캐시된 AWS 자격 증명으로 대시보드 URL을 열도록 구성되어 있는지 확인합니다.

요구사항에 맞는 서비스

1. Amazon CloudWatch 대시보드에 애플리케이션 지표를 표시

    • Amazon CloudWatch : AWS 리소스와 애플리케이션을 모니터링하기 위한 서비스로, 지표 수집, 로그 파일 모니터링, 알림 설정 등을 제공합니다. CloudWatch 대시보드를 사용하여 애플리케이션의 실시간 및 과거 성능을 시각적으로 확인할 수 있습니다. CloudWatch 대시보드는 특정 사용자에게 읽기 전용 권한을 부여하여 애플리케이션 지표를 모니터링할 수 있어요.

2. 제품 관리자에게 AWS 계정이 없으므로 최소 권한 원칙에 따라 액세스 권한을 제공해야 함

  • 최소 권한 원칙에 따라 권한을 제공해야 함
    • Amazon CloudWatch : 콘솔에서 대시보드를 직접 공유할 수 있습니다. 링크를 제품 관리자에게 안전하게 전달하면, 제품 관리자는 AWS 계정 없이도 해당 링크를 통해 CloudWatch 대시보드에 접근이 가능해요. 

최적의 정답 선택하기

선택지 1번은 “CloudWatch 콘솔에서 대시보드를 공유합니다. 제품 관리자의 이메일 주소를 입력하고 공유 단계를 완료합니다. 제품 관리자에게 대시보드에 대한 공유 가능한 링크를 제공합니다.”입니다.

→ 이 선택지는 제품 관리자가 AWS 계정 없이도 대시보드에 접근할 수 있게 하며, 최소 권한 원칙을 준수하면서 문제의 요구사항을 충족시킵니다. 

 

선택지 2번은 “제품 관리자 전용 IAM 사용자를 생성합니다. CloudWatchReadOnlyAccess AWS 관리형 정책을 사용자에게 연결합니다. 새 로그인 자격 증명을 제품 관리자와 공유하십시오. 올바른 대시보드의 브라우저 URL을 제품 관리자와 공유하십시오.”입니다.

→ 선택지가 정답이 아닌 이유는 새로운 IAM 사용자를 생성해야 하므로 제품 관리자가 AWS 계정이 없다는 문제의 요구사항에 맞지 않기 때문입니다. 또한, 새 계정을 만들고 자격 증명을 관리해야 하는 번거로움이 있습니다.

 

선택지 3번은 “회사 직원을 위한 IAM 사용자를 생성합니다. ViewOnlyAccess AWS 관리형 정책을 IAM 사용자에게 연결합니다. 새 로그인 자격 증명을 제품 관리자와 공유하십시오. 제품 관리자에게 CloudWatch 콘솔로 이동하여 대시보드 섹션에서 이름으로 대시보드를 찾도록 요청하십시오.”입니다.

→ 선택지가 정답이 아닌 이유는 ViewOnlyAccess 정책은 불필요하게 광범위한 권한을 부여하며, 최소 권한 원칙을 위배할 수 있기 때문입니다. 또한, 새 계정을 생성하는 방식이 문제의 요구사항과 일치하지 않습니다.

 

선택지 4번은 “퍼블릭 서브넷에 배스천 서버를 배포합니다. 제품 관리자가 대시보드에 액세스해야 하는 경우 서버를 시작하고 RDP 자격 증명을 공유합니다. 배스천 서버에서 브라우저가 대시보드를 볼 수 있는 적절한 권한이 있는 캐시된 AWS 자격 증명으로 대시보드 URL을 열도록 구성되어 있는지 확인합니다.”입니다.

→ 선택지가 정답이 아닌 이유는 지나치게 복잡하고 보안 위험이 있기 때문입니다. 제품 관리자가 단순히 CloudWatch 대시보드에 접근하기 위해 배스천 서버를 사용하는 것은 비효율적이며, 최소 권한 원칙에도 맞지 않습니다. 

 

 

문제에 대한 정답은 선택지 1번입니다!

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

더보기

첫 번째 과정은 “문제의 요구사항 분석하기”입니다.

이 문제에서는 2가지의 요구사항이 존재해요. 

 

1. Amazon CloudWatch 대시보드에 애플리케이션 지표를 표시

2. 제품 관리자에게 AWS 계정이 없으므로 최소 권한 원칙에 따라 권한을 제공해야 함

 

"최소 권한 원칙"

→ 최소 권한 원칙은 정보 보안의 핵심 개념으로, 사용자나 시스템 프로세스에게 필요한 최소한의 권한만을 부여하는 것을 의미합니다. 이를 통해 실수나 악의적인 행위로 인한 피해를 줄이고, 보안 침해가 발생하더라도 그 영향을 제한할 수 있어요. 

 

두 번째 과정은 “요구사항과 관련된 AWS 서비스 생각하기”입니다.

1. Amazon CloudWatch 대시보드에 애플리케이션 지표를 표시

  • Amazon CloudWatch : AWS 리소스와 애플리케이션을 모니터링하기 위한 서비스로, 지표 수집, 로그 파일 모니터링, 알림 설정 등을 제공합니다. CloudWatch 대시보드를 사용하여 애플리케이션의 실시간 및 과거 성능을 시각적으로 확인할 수 있습니다. CloudWatch 대시보드는 특정 사용자에게 읽기 전용 권한을 부여하여 애플리케이션 지표를 모니터링할 수 있어요.
  •  

2. 제품 관리자에게 AWS 계정이 없으므로 최소 권한 원칙에 따라 액세스 권한을 제공해야 함

  • 최소 권한 원칙에 따라 권한을 제공해야 함
    • Amazon CloudWatch : 콘솔에서 대시보드를 직접 공유할 수 있습니다. 링크를 제품 관리자에게 안전하게 전달하면, 제품 관리자는 AWS 계정 없이도 해당 링크를 통해 CloudWatch 대시보드에 직접 접근할 수 있습니다. 
    • 대시보드를 공유할 때 대시보드를 볼 수 있는 사용자를 지정
      • 단일 대시보드를 공유하고 대시보드를 볼 수 있는 사용자의 이메일 주소를 최대 5개 지정할 수 있어요. 이러한 각 사용자는 대시보드를 보기 위해 입력해야 하는 고유한 암호를 생성해요.
      • 링크가 있는 사람은 누구나 대시보드를 볼 수 있도록 단일 대시보드를 공개적으로 공유합니다.
      • 계정의 모든 CloudWatch 대시보드를 공유하고 대시보드 액세스를 위한 서드 파티 통합 인증(SSO) 공급자를 지정해요. 이 SSO 공급자 목록의 멤버인 모든 사용자는 계정의 모든 대시보드에 액세스할 수 있어요.
    • CloudWatch 콘솔에 접속한 후, 공유하고자 하는 대시보드를 선택합니다. 그 다음 대시보드 공유 옵션을 선택하고, 제품 관리자의 이메일 주소를 입력합니다. 공유 설정을 완료하면 시스템에서 공유 가능한 링크를 생성할 수 있어요. 이 링크를 제품 관리자에게 안전하게 전달하면, 제품 관리자는 AWS 계정 없이도 해당 링크를 통해 CloudWatch 대시보드에 접근이 가능해요. 
 

마지막 과정은 “위의 정보들을 토대로 정답 선택하기”입니다.

선택지 1번은 “CloudWatch 콘솔에서 대시보드를 공유합니다. 제품 관리자의 이메일 주소를 입력하고 공유 단계를 완료합니다. 제품 관리자에게 대시보드에 대한 공유 가능한 링크를 제공합니다.”입니다.

 

  • Amazon CloudWatch : AWS 리소스와 애플리케이션을 모니터링하는 서비스로, 지표 수집, 로그 파일 모니터링, 알림 설정 등을 제공합니다. CloudWatch 대시보드를 생성하여 애플리케이션의 성능 지표를 시각화할 수 있습니다.
  • CloudWatch 대시보드 공유: CloudWatch 대시보드는 외부 사용자와 공유할 수 있습니다. 이 기능을 통해 AWS 계정이 없는 사용자에게도 대시보드를 볼 수 있는 링크를 제공할 수 있습니다. 

이 선택지는 제품 관리자가 AWS 계정 없이도 대시보드에 접근할 수 있게 하며, 최소 권한 원칙을 준수하면서 문제의 요구사항을 충족시킵니다. 

 

선택지 2번은 “제품 관리자 전용 IAM 사용자를 생성합니다. CloudWatchReadOnlyAccess AWS 관리형 정책을 사용자에게 연결합니다. 새 로그인 자격 증명을 제품 관리자와 공유하십시오. 올바른 대시보드의 브라우저 URL을 제품 관리자와 공유하십시오.”입니다.

 

  • AWS IAM (Identity and Access Management) : AWS 리소스에 대한 액세스를 안전하게 관리하는 서비스로, 사용자와 권한을 생성 및 관리할 수 있습니다. IAM 정책을 사용하여 특정 사용자에게 필요한 권한만 부여할 수 있습니다.
  • CloudWatchReadOnlyAccess 관리형 정책: 이 정책은 사용자가 CloudWatch의 모든 지표와 대시보드를 읽기 전용으로 접근할 수 있도록 허용합니다.

이 선택지가 정답이 아닌 이유는 새로운 IAM 사용자를 생성해야 하므로 제품 관리자가 AWS 계정이 없다는 문제의 요구사항에 맞지 않기 때문입니다. 또한, 새 계정을 만들고 자격 증명을 관리해야 하는 번거로움이 있습니다.

 

선택지 3번은 “회사 직원을 위한 IAM 사용자를 생성합니다. ViewOnlyAccess AWS 관리형 정책을 IAM 사용자에게 연결합니다. 새 로그인 자격 증명을 제품 관리자와 공유하십시오. 제품 관리자에게 CloudWatch 콘솔로 이동하여 대시보드 섹션에서 이름으로 대시보드를 찾도록 요청하십시오.”입니다.

 

  • AWS IAM (Identity and Access Management) : AWS 리소스에 대한 접근 권한을 관리할 수 있는 서비스입니다.
  • ViewOnlyAccess 관리형 정책: 이 정책은 사용자가 AWS 리소스에 대해 광범위한 읽기 전용 접근 권한을 가지도록 합니다. 그러나 이는 CloudWatch 대시보드뿐만 아니라 다른 AWS 서비스에도 접근을 허용할 수 있어 최소 권한 원칙에 맞지 않을 수 있습니다.

이 선택지가 정답이 아닌 이유는 ViewOnlyAccess 정책은 불필요하게 광범위한 권한을 부여하며, 최소 권한 원칙을 위배할 수 있기 때문입니다. 또한, 새 계정을 생성하는 방식이 문제의 요구사항과 일치하지 않습니다.

 

선택지 4번은 “퍼블릭 서브넷에 배스천 서버를 배포합니다. 제품 관리자가 대시보드에 액세스해야 하는 경우 서버를 시작하고 RDP 자격 증명을 공유합니다. 배스천 서버에서 브라우저가 대시보드를 볼 수 있는 적절한 권한이 있는 캐시된 AWS 자격 증명으로 대시보드 URL을 열도록 구성되어 있는지 확인합니다.”입니다.

 

  • Amazon EC2와 배스천 서버 : Amazon EC2는 가상 서버를 제공하는 서비스로, AWS 클라우드에서 배포할 수 있습니다.
    배스천 서버는 퍼블릭 서브넷에 위치한 서버로, 보안 액세스 지점 역할을 합니다.
  • RDP 자격 증명: 원격 데스크톱 프로토콜(RDP)을 통해 서버에 접속할 수 있는 자격 증명입니다. 원격 데스크톱 프로토콜은 사용자가 다른 컴퓨터에 원격으로 연결하여 그래픽 사용자 인터페이스를 통해 해당 컴퓨터를 제어할 수 있게 해줍니다. 

이 선택지가 정답이 아닌 이유는 지나치게 복잡하고 보안 위험이 있기 때문입니다. 제품 관리자가 단순히 CloudWatch 대시보드에 접근하기 위해 배스천 서버를 사용하는 것은 비효율적이며, 최소 권한 원칙에도 맞지 않습니다. 

 

 

마지막 문제 살펴볼게요.

문제

한 회사가 최근 애플리케이션 마이그레이션 이니셔티브를 지원하기 위해 AWS MSP(Managed Service Provider) 파트너와 계약을 체결했습니다.

솔루션 설계자는 기존 AWS 계정의 Amazon Machine Image(AMI)를 MSP 파트너의 AWS 계정과 공유해야 합니다.

AMI는 Amazon Elastic Block Store(Amazon EBS)에서 지원하며 AWS Key Management Service(AWS KMS) 고객 관리형 키를 사용하여 EBS 볼륨 스냅샷을 암호화합니다.

솔루션 설계자가 AMI를 MSP 파트너의 AWS 계정과 공유할 수 있는 가장 안전한 방법은 무엇입니까?

선택지

1. 암호화된 AMI와 스냅샷을 공개적으로 사용 가능하게 만드십시오. MSP 파트너의 AWS 계정이 키를 사용할 수 있도록 키 정책을 수정합니다.

2. AMI의 launchPermission 속성을 수정합니다. MSP 파트너의 AWS 계정과만 AMI를 공유합니다. MSP 파트너의 AWS 계정이 키를 사용할 수 있도록 키 정책을 수정합니다.

3. AMI의 launchPermission 속성을 수정합니다. MSP 파트너의 AWS 계정과만 AMI를 공유합니다. 암호화를 위해 MSP 파트너가 소유한 새 KMS 키를 신뢰하도록 키 정책을 수정합니다.

4. 소스 계정에서 MSP 파트너의 AWS 계정에 있는 Amazon S3 버킷으로 AMI를 내보내고 MSP 파트너가 소유한 새 KMS 키로 S3 버킷을 암호화합니다. MSP 파트너의 AWS 계정에서 AMI를 복사하고 시작합니다.

요구사항에 맞는 서비스

1. Amazon Machine Image(AMI)를 MSP 파트너의 AWS 계정과 공유

  • Amazon EC2 (Elastic Compute Cloud) : 클라우드에서 가상 서버를 제공하는 서비스입니다. AMI는 EC2 인스턴스를 생성하는 데 필요한 템플릿으로, 운영 체제, 애플리케이션 서버, 애플리케이션 등의 구성 요소를 포함합니다. AMI는 EC2 인스턴스를 빠르게 배포하기 위한 필수 요소이며, 이를 특정 AWS 계정과 안전하게 공유할 수 있습니다. 공유는 launchPermission 속성을 통해 특정 AWS 계정으로 제한할 수 있으며, 이는 보안을 강화하는 데 도움이 됩니다.
  • Amazon EBS (Elastic Block Store) : EC2 인스턴스에 사용되는 블록 스토리지 서비스입니다. EBS는 높은 성능과 가용성을 제공하며, EBS 볼륨을 암호화하여 데이터 보안을 강화할 수 있습니다. AMI는 EBS를 지원하여 EC2 인스턴스를 신속하게 시작할 수 있도록 합니다. EBS는 AMI의 루트 디바이스로 작동하며, 이를 다른 AWS 계정과 안전하게 공유하려면 해당 볼륨을 지원하는 정책이 필요합니다.

2. EBS 볼륨 스냅샷은 AWS KMS 고객 관리형 키로 암호화

  • AWS KMS (Key Management Service) : AWS 리소스를 암호화하기 위해 사용되는 키를 생성하고 관리할 수 있는 서비스입니다. KMS는 고객 관리형 키(CMK)를 통해 사용자가 직접 키를 관리하고, 필요에 따라 키의 사용 권한을 다른 AWS 계정에 부여할 수 있습니다. 이를 통해 암호화된 EBS 스냅샷을 특정 계정과 안전하게 공유할 수 있으며, 키 정책을 통해 액세스 권한을 세밀하게 제어할 수 있습니다.
    • Amazon EC2와 KMS 통합 : EC2에서 사용되는 EBS 볼륨은 KMS로 암호화할 수 있습니다. 이때 생성된 스냅샷은 해당 KMS 키에 의해 보호되며, 이 스냅샷을 다른 계정과 공유하려면 KMS 키에 대한 접근 권한을 설정해야 합니다. 이를 통해 데이터가 안전하게 보호되면서도 공유가 가능합니다.
  • IAM (Identity and Access Management) : AWS 리소스에 대한 접근 권한을 관리할 수 있는 서비스로, 최소 권한 원칙을 적용하여 보안을 강화할 수 있습니다. IAM 정책을 사용하여 MSP 파트너에게 AMI와 관련된 리소스에 대한 접근 권한을 부여할 수 있으며, 필요에 따라 권한을 제한할 수 있습니다. 또한, KMS 키와 EBS 스냅샷에 대한 접근 권한을 명확하게 제어하여 보안을 유지할 수 있습니다.
    •  

최적의 정답 선택하기

선택지 1번은 “암호화된 AMI와 스냅샷을 공개적으로 사용 가능하게 만드십시오. MSP 파트너의 AWS 계정이 키를 사용할 수 있도록 키 정책을 수정합니다.”입니다.

→ 선택지가 정답이 아닌 이유는 AMI와 스냅샷을 공개적으로 공유하는 것은 보안 위험이 크며, 특히 민감한 데이터가 포함된 경우 매우 부적절하기 때문입니다. AWS에서는 가능한 모든 경우에 보안을 최우선으로 해야 하므로, 이 방법은 문제의 요구사항에 부합하지 않습니다. 공개 설정은 불필요한 보안 위협을 초래하며, 기업의 데이터 보호 정책에도 위배될 수 있습니다.

 

선택지 2번은 “AMI의 launchPermission 속성을 수정합니다. MSP 파트너의 AWS 계정과만 AMI를 공유합니다. MSP 파트너의 AWS 계정이 키를 사용할 수 있도록 키 정책을 수정합니다.”입니다.

→ 이 선택지는 AMI와 관련된 리소스에 대한 접근 권한을 특정 계정으로 제한하며, 안전하게 AMI를 공유할 수 있도록 합니다. 특히, KMS 키를 통해 암호화된 데이터를 안전하게 보호하면서도, 필요한 경우에만 접근을 허용하도록 설계할 수 있습니다. 이를 통해 데이터 유출의 위험을 최소화하면서도 MSP 파트너가 필요한 작업을 수행할 수 있습니다. 

 

선택지 3번은 "AMI의 launchPermission 속성을 수정합니다. MSP 파트너의 AWS 계정과만 AMI를 공유합니다. 암호화를 위해 MSP 파트너가 소유한 새 KMS 키를 신뢰하도록 키 정책을 수정합니다.”입니다.

→ 선택지가 정답이 아닌 이유는  불필요하게 복잡하며, 기존의 KMS 키를 사용하는 것이 더 안전하고 효율적이기 때문입니다. 새 KMS 키를 도입하는 것은 추가적인 설정과 관리 부담을 야기하며, 데이터 관리의 일관성을 저해할 수 있습니다. 또한, 기존 키가 이미 충분히 안전하게 보호되고 있을 때, 새로운 키를 도입하는 것은 보안상 이점보다는 관리 복잡성을 증가시킬 가능성이 높습니다.

 

선택지 4번은 “소스 계정에서 MSP 파트너의 AWS 계정에 있는 Amazon S3 버킷으로 AMI를 내보내고 MSP 파트너가 소유한 새 KMS 키로 S3 버킷을 암호화합니다. MSP 파트너의 AWS 계정에서 AMI를 복사하고 시작합니다.”입니다.

→ 선택지가 정답이 아닌 이유는  지나치게 복잡하고, 데이터 보안 위험이 증가하며, 비효율적이기 때문입니다. AMI를 직접적으로 공유하는 방법에 비해 이 방법은 추가적인 보안 위험과 운영 오버헤드를 발생시킵니다. 데이터 전송 과정에서 발생할 수 있는 문제들을 고려할 때, S3 버킷으로의 데이터 이동은 불필요한 위험을 초래할 수 있습니다.

 

 

문제에 대한 정답은 선택지 2번입니다!

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

더보기

첫 번째 과정은 “문제의 요구사항 분석하기”입니다.

이 문제에서는 2가지의 요구사항이 존재해요. 

 

1. Amazon Machine Image(AMI)를 MSP 파트너의 AWS 계정과 공유

  • AMI는 Amazon EBS에서 지원

2. EBS 볼륨 스냅샷은 AWS KMS 고객 관리형 키로 암호화

  • 가장 안전한 방법으로 AMI 공유 필요

 

두 번째 과정은 “요구사항과 관련된 AWS 서비스 생각하기”입니다. 

1. Amazon Machine Image(AMI)를 MSP 파트너의 AWS 계정과 공유

  • Amazon EC2 (Elastic Compute Cloud) : 클라우드에서 가상 서버를 제공하는 서비스입니다. AMI는 EC2 인스턴스를 생성하는 데 필요한 템플릿으로, 운영 체제, 애플리케이션 서버, 애플리케이션 등의 구성 요소를 포함합니다. AMI는 EC2 인스턴스를 빠르게 배포하기 위한 필수 요소이며, 이를 특정 AWS 계정과 안전하게 공유할 수 있습니다. 공유는 launchPermission 속성을 통해 특정 AWS 계정으로 제한할 수 있으며, 이는 보안을 강화하는 데 도움이 됩니다.
  • Amazon EBS (Elastic Block Store) : EC2 인스턴스에 사용되는 블록 스토리지 서비스입니다. EBS는 높은 성능과 가용성을 제공하며, EBS 볼륨을 암호화하여 데이터 보안을 강화할 수 있습니다. AMI는 EBS를 지원하여 EC2 인스턴스를 신속하게 시작할 수 있도록 합니다. EBS는 AMI의 루트 디바이스로 작동하며, 이를 다른 AWS 계정과 안전하게 공유하려면 해당 볼륨을 지원하는 정책이 필요합니다.
  • Amazon Machine Image (AMI) : 주로 Amazon EC2 인스턴스를 생성하는 데 필요한 모든 정보를 담고 있는 템플릿입니다. AMI는 운영 체제(OS), 애플리케이션 서버, 애플리케이션 소프트웨어 및 해당 소프트웨어의 실행에 필요한 설정을 포함하는 이미지를 제공합니다. 이를 통해 사용자는 일관된 환경을 유지하면서 여러 인스턴스를 신속하게 시작할 수 있습니다.
    • AMI의 주요 구성 요소
      • 루트 볼륨 템플릿: AMI는 인스턴스의 루트 볼륨에 대한 템플릿을 제공합니다. 이 템플릿에는 운영 체제와 애플리케이션이 설치된 디스크 이미지가 포함되어 있습니다. 이 루트 볼륨은 Amazon Elastic Block Store (EBS) 스냅샷 또는 인스턴스 저장소 볼륨으로 제공됩니다.
      • 인스턴스 시작 권한 (Launch Permissions): AMI의 인스턴스를 시작할 수 있는 AWS 계정을 정의합니다. AMI를 특정 AWS 계정과 공유하거나, 여러 계정과 공유하거나, 공용으로 설정하여 모든 AWS 사용자가 사용할 수 있게 할 수 있습니다.
      • 블록 디바이스 매핑 (Block Device Mapping): AMI가 인스턴스를 시작할 때 추가적으로 연결될 EBS 볼륨이나 인스턴스 스토리지를 정의합니다. 이를 통해 인스턴스가 시작될 때 어떤 볼륨이 연결될지를 결정할 수 있습니다.

2. EBS 볼륨 스냅샷은 AWS KMS 고객 관리형 키로 암호화

  • AWS KMS (Key Management Service) : AWS 리소스를 암호화하기 위해 사용되는 키를 생성하고 관리할 수 있는 서비스입니다. KMS는 고객 관리형 키(CMK)를 통해 사용자가 직접 키를 관리하고, 필요에 따라 키의 사용 권한을 다른 AWS 계정에 부여할 수 있습니다. 이를 통해 암호화된 EBS 스냅샷을 특정 계정과 안전하게 공유할 수 있으며, 키 정책을 통해 액세스 권한을 세밀하게 제어할 수 있습니다.
    • Amazon EC2와 KMS 통합 : EC2에서 사용되는 EBS 볼륨은 KMS로 암호화할 수 있습니다. 이때 생성된 스냅샷은 해당 KMS 키에 의해 보호되며, 이 스냅샷을 다른 계정과 공유하려면 KMS 키에 대한 접근 권한을 설정해야 합니다. 이를 통해 데이터가 안전하게 보호되면서도 공유가 가능합니다.
  • IAM (Identity and Access Management) : AWS 리소스에 대한 접근 권한을 관리할 수 있는 서비스로, 최소 권한 원칙을 적용하여 보안을 강화할 수 있습니다. IAM 정책을 사용하여 MSP 파트너에게 AMI와 관련된 리소스에 대한 접근 권한을 부여할 수 있으며, 필요에 따라 권한을 제한할 수 있습니다. 또한, KMS 키와 EBS 스냅샷에 대한 접근 권한을 명확하게 제어하여 보안을 유지할 수 있습니다.

마지막 과정은 “위의 정보들을 토대로 정답 선택하기”입니다.

선택지 1번은 “암호화된 AMI와 스냅샷을 공개적으로 사용 가능하게 만드십시오. MSP 파트너의 AWS 계정이 키를 사용할 수 있도록 키 정책을 수정합니다.”입니다.

 

  • Amazon Machine Image (AMI) : 운영 체제(OS), 애플리케이션 서버, 애플리케이션 소프트웨어 및 해당 소프트웨어의 실행에 필요한 설정을 포함하는 이미지를 제공합니다. 이를 통해 사용자는 일관된 환경을 유지하면서 여러 인스턴스를 신속하게 시작할 수 있습니다.

이 선택지가 정답이 아닌 이유는 AMI와 스냅샷을 공개적으로 공유하는 것은 보안 위험이 크며, 특히 민감한 데이터가 포함된 경우 매우 부적절하기 때문입니다. AWS에서는 가능한 모든 경우에 보안을 최우선으로 해야 하므로, 이 방법은 문제의 요구사항에 부합하지 않습니다. 공개 설정은 불필요한 보안 위협을 초래하며, 기업의 데이터 보호 정책에도 위배될 수 있습니다.

 

선택지 2번은 “AMI의 launchPermission 속성을 수정합니다. MSP 파트너의 AWS 계정과만 AMI를 공유합니다. MSP 파트너의 AWS 계정이 키를 사용할 수 있도록 키 정책을 수정합니다.”입니다.

 

  • Amazon Machine Image (AMI) : 운영 체제(OS), 애플리케이션 서버, 애플리케이션 소프트웨어 및 해당 소프트웨어의 실행에 필요한 설정을 포함하는 이미지를 제공합니다. 이를 통해 사용자는 일관된 환경을 유지하면서 여러 인스턴스를 신속하게 시작할 수 있습니다.
  • AWS KMS :  암호화 키를 관리하는 서비스로, KMS 키를 사용하여 암호화된 EBS 스냅샷에 대한 접근 권한을 제어할 수 있습니다. KMS 키 정책을 수정하여 MSP 파트너가 이 키를 사용할 수 있도록 허용함으로써, 암호화된 데이터를 안전하게 공유할 수 있습니다.

이 선택지는 AMI와 관련된 리소스에 대한 접근 권한을 특정 계정으로 제한하며, 안전하게 AMI를 공유할 수 있도록 합니다. 특히, KMS 키를 통해 암호화된 데이터를 안전하게 보호하면서도, 필요한 경우에만 접근을 허용하도록 설계할 수 있습니다. 이를 통해 데이터 유출의 위험을 최소화하면서도 MSP 파트너가 필요한 작업을 수행할 수 있습니다.

 

선택지 3번은 "AMI의 launchPermission 속성을 수정합니다. MSP 파트너의 AWS 계정과만 AMI를 공유합니다. 암호화를 위해 MSP 파트너가 소유한 새 KMS 키를 신뢰하도록 키 정책을 수정합니다.”입니다.

 

  • Amazon Machine Image (AMI) : 운영 체제(OS), 애플리케이션 서버, 애플리케이션 소프트웨어 및 해당 소프트웨어의 실행에 필요한 설정을 포함하는 이미지를 제공합니다. 이를 통해 사용자는 일관된 환경을 유지하면서 여러 인스턴스를 신속하게 시작할 수 있습니다.
  • AWS KMS : KMS 키의 정책을 수정하여 MSP 파트너가 소유한 새로운 KMS 키를 사용하도록 설정할 수 있습니다. 기존의 KMS 키 대신, MSP 파트너가 소유한 새로운 KMS 키를 사용하는 것은 보안적으로 유효하지만, 불필요한 복잡성을 초래할 수 있습니다. 특히, 관리해야 할 키의 수가 증가하면 보안 관리가 더 어려워질 수 있습니다.

이 선택지가 정답이 아닌 이유는  불필요하게 복잡하며, 기존의 KMS 키를 사용하는 것이 더 안전하고 효율적이기 때문입니다. 새 KMS 키를 도입하는 것은 추가적인 설정과 관리 부담을 야기하며, 데이터 관리의 일관성을 저해할 수 있습니다. 또한, 기존 키가 이미 충분히 안전하게 보호되고 있을 때, 새로운 키를 도입하는 것은 보안상 이점보다는 관리 복잡성을 증가시킬 가능성이 높습니다.

 

선택지 4번은 “소스 계정에서 MSP 파트너의 AWS 계정에 있는 Amazon S3 버킷으로 AMI를 내보내고 MSP 파트너가 소유한 새 KMS 키로 S3 버킷을 암호화합니다. MSP 파트너의 AWS 계정에서 AMI를 복사하고 시작합니다.”입니다.

 

  • Amazon S3 : 데이터를 저장할 수 있는 객체 스토리지 서비스로, 데이터를 암호화하여 저장할 수 있습니다. AMI를 S3 버킷으로 내보내는 과정은 데이터 전송 중의 보안 위험을 포함할 수 있습니다.
  • AWS KMS : S3 버킷의 데이터를 암호화하기 위해 KMS 키를 사용할 수 있으며, MSP 파트너가 소유한 KMS 키를 사용할 수 있습니다. AMI를 S3 버킷으로 내보내는 것은 복잡한 과정이며, 데이터 이동 중 보안 위험이 증가할 수 있습니다. 또한, S3로 데이터를 이동하는 것은 추가적인 절차와 시간이 필요합니다.

이 선택지가 정답이 아닌 이유는 지나치게 복잡하고, 데이터 보안 위험이 증가하며, 비효율적이기 때문입니다. AMI를 직접적으로 공유하는 방법에 비해 이 방법은 추가적인 보안 위험과 운영 오버헤드를 발생시킵니다. 데이터 전송 과정에서 발생할 수 있는 문제들을 고려할 때, S3 버킷으로의 데이터 이동은 불필요한 위험을 초래할 수 있습니다.

 

 

여러분, 벌써 월요일 아침입니다. 주말은 잘 쉬셨나요?

꾸준히 하는 것도 중요하지만 잘 쉬는 것도 중요하답니다 ㅎㅎ!

오늘 하루는 또 어떻게 흘러갈지는 아무도 모르지만, 좋은 하루가 되길 바라요.

이번 주도 열정과 노력으로 가득 채워 목표를 향해 한 걸음 더 나아가길!

오늘 글이 유익하셨길 바라며, 다음에는 또 다른 문제로 찾아뵙겠습니다.

 

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

저작자표시

'AWS > SAA 준비' 카테고리의 다른 글

AWS SAA 합격으로 가는 길 #8  (0) 2024.08.26
AWS SAA 합격으로 가는 길 #7: [EC2 인스턴스] 마스터하기  (0) 2024.08.23
AWS SAA 합격으로 가는 길 #5: [CloudFront] 마스터하기  (0) 2024.08.16
AWS SAA 합격으로 가는 길 #4: [S3 데이터보호] 마스터하기  (1) 2024.08.12
AWS SAA 합격으로 가는 길 #3: [Windows 파일 공유] 마스터하기  (0) 2024.08.07

관련글

티스토리툴바