안녕하세요! 넥스트클라우드의 SA 백종훈입니다. 😊
문제는 세 가지 단계를 거치며 풀어 나갈 거예요.
1. 문제의 요구사항 분석하기
2. 관련 AWS 서비스 생각하기
3. 선택지 분석하기
바로 문제 풀이 해볼까요?
문제1
회사에서 기존 3계층 웹 아키텍처의 비용을 줄이고자 합니다. 웹, 애플리케이션 및 데이터베이스 서버는 개발, 테스트 및 프로덕션 환경을 위해 Amazon EC2 인스턴스에서 실행됩니다. EC2 인스턴스는 사용량이 많은 시간에 평균 30%의 CPU 사용률을 보이고 사용량이 적은 시간에는 10%의 CPU 사용률을 보입니다. 프로덕션 EC2 인스턴스는 하루 24시간 실행됩니다. 개발 및 테스트 EC2 인스턴스는 매일 최소 8시간 동안 실행됩니다. 이 회사는 개발을 중지하고 사용하지 않는 EC2 인스턴스를 테스트 하기 위해 자동화를 구현할 계획입니다. 어떤 EC2 인스턴스 구매 솔루션이 회사의 요구 사항을 가장 비용 효율적으로 충족합니까?
선택지
A. 프로덕션 EC2 인스턴스에는 스팟 인스턴스를 사용하십시오. 개발 및 테스트 EC2 인스턴스에 예약 인스턴스를 사용합니다.
B. 프로덕션 EC2 인스턴스에 예약 인스턴스를 사용합니다. 개발 및 테스트 EC2 인스턴스에 온디맨드 인스턴스를 사용합니다.
C. 프로덕션 EC2 인스턴스에 스팟 블록을 사용합니다. 개발 및 테스트 EC2 인스턴스에 예약 인스턴스를 사용합니다.
D. 프로덕션 EC2 인스턴스에 온디맨드 인스턴스를 사용합니다. 개발 및 테스트 EC2 인스턴스에 스팟 블록을 사용합니다.
풀이
프로덕션 EC2 인스턴스는 지속적으로 실행되므로 예약 인스턴스를 사용하면 온디맨드 요금보다 비용을 절감할 수 있습니다. 개발 및 테스트 환경 인스턴스는 일정 기간만 실행되므로 예약 인스턴스보다는 온디맨드 인스턴스가 더 비용 효율적입니다.
정답 : B
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 기존 3계층 웹 아키텍처의 비용 절감 목표
- EC2 인스턴스 CPU 사용률: 사용량 많은 시간 30%, 적은 시간 10%
- 프로덕션 EC2 인스턴스는 24시간 실행, 개발/테스트는 최소 8시간 실행
- 개발/테스트 중지 시 EC2 인스턴스를 자동으로 중지하는 자동화 구현 계획
- 비용 효율적인 EC2 인스턴스 구매 솔루션 필요
2. 관련 AWS 서비스 생각하기
- 온디맨드 인스턴스: 시간당 요금을 지불하고 인스턴스를 사용하는 유연한 방식입니다. 실행 시간에 따라 비용이 발생하므로 단기간 사용에 적합합니다.
- 예약 인스턴스: 1년 또는 3년 기간 동안 사전에 인스턴스를 예약하고 할인된 시간당 요금을 지불합니다. 장기간 사용할 경우 비용 절감 효과가 있습니다.
- 스팟 인스턴스: 남은 EC2 용량을 활용하며 스팟 가격이 온디맨드 가격보다 저렴합니다. 하지만 인스턴스가 중단될 수 있어 일시적인 워크로드에 적합합니다.
- 스팟 블록: 지정된 시간 동안 스팟 인스턴스를 사용할 수 있게 해줍니다. 지정 기간이 끝나면 인스턴스가 자동으로 중단됩니다.
3. 선택지 분석하기
A. 프로덕션 EC2 인스턴스에는 스팟 인스턴스를 사용하십시오. 개발 및 테스트 EC2 인스턴스에 예약 인스턴스를 사용합니다.
→ 프로덕션 환경에서 스팟 인스턴스를 사용하면 중단 위험이 있어 적합하지 않습니다. 개발/테스트 환경은 단기간 실행되므로 예약 인스턴스보다는 온디맨드 인스턴스가 더 비용 효율적입니다.
B. 프로덕션 EC2 인스턴스에 예약 인스턴스를 사용합니다. 개발 및 테스트 EC2 인스턴스에 온디맨드 인스턴스를 사용합니다.
→프로덕션 EC2 인스턴스는 지속적으로 실행되므로 예약 인스턴스를 사용하면 온디맨드 요금보다 비용을 절감할 수 있습니다. 개발 및 테스트 환경 인스턴스는 일정 기간만 실행되므로 예약 인스턴스보다는 온디맨드 인스턴스가 더 비용 효율적입니다.
C. 프로덕션 EC2 인스턴스에 스팟 블록을 사용합니다. 개발 및 테스트 EC2 인스턴스에 예약 인스턴스를 사용합니다.
→ 프로덕션 환경에서 스팟 블록을 사용하면 중단 위험이 있어 적합하지 않습니다. 개발/테스트 환경은 단기간 실행되므로 예약 인스턴스보다는 온디맨드 인스턴스가 더 비용 효율적입니다.
D. 프로덕션 EC2 인스턴스에 온디맨드 인스턴스를 사용합니다. 개발 및 테스트 EC2 인스턴스에 스팟 블록을 사용합니다.
→ 프로덕션 환경은 지속적으로 실행되므로 예약 인스턴스가 온디맨드 인스턴스보다 더 비용 효율적입니다. 개발/테스트 환경은 단기간 실행되므로 스팟 블록보다는 온디맨드 인스턴스가 더 적합합니다.
이어서 다음 문제입니다.
문제2
회사에는 Amazon RDS의 데이터베이스에 목록을 저장하는 자동차 판매 웹 사이트가 있습니다. 자동차가 판매되면 웹사이트에서 목록을 제거하고 데이터를 여러 대상 시스템으로 전송해야 합니다. 솔루션 설계자는 어떤 디자인을 추천해야 합니까?
선택지
A. 대상이 소비할 Amazon Simple Queue Service(Amazon SQS) 대기열로 정보를 전송하도록 Amazon RDS의 데이터베이스가 업데이트될 때 트리거되는 AWS Lambda 함수 를 생성합니다.
B. 대상이 사용할 Amazon Simple Queue Service(Amazon SQS) FIFO 대기열에 정보를 전송하도록 Amazon RDS의 데이터베이스가 업데이트될 때 트리거되는 AWS Lambda 함수를 생성합니다.
C. RDS 이벤트 알림을 구독하고 여러 Amazon Simple Notification Service(Amazon SNS) 주제로 팬 아웃된 Amazon Simple Queue Service(Amazon SQS) 대기열을 보냅니다. AWS Lambda 함수를 사용하여 대상을 업데이트합니다.
D. RDS 이벤트 알림을 구독하고 여러 Amazon Simple Queue Service(Amazon SQS) 대기열로 팬 아웃된 Amazon Simple Notification Service(Amazon SNS) 주제를 보냅니다. AWS Lambda 함수를 사용하여 대상을 업데이트합니다.
풀이
Amazon RDS 데이터베이스의 변경 사항을 SQS 대기열로 전송하고, 대기열의 메시지를 소비하여 대상 시스템을 업데이트하는 것이 가장 적절한 솔루션입니다. SQS는 완전 관리형 서비스로 운영 오버헤드가 낮으며, 대기열은 메시지 버퍼링 및 분리 역할을 합니다. Lambda 함수를 사용하여 SQS 대기열에서 메시지를 읽고 대상 시스템에 전송하는 작업을 자동화할 수 있습니다.
정답 : A
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 자동차 판매 웹사이트에서 자동차가 판매되면 RDS 데이터베이스에서 목록 제거 및 데이터를 여러 대상 시스템으로 전송
- 데이터 전송을 자동화하는 디자인 필요
2. 관련 AWS 서비스 생각하기
- Amazon RDS: 관계형 데이터베이스를 클라우드에서 쉽게 설정, 운영 및 확장할 수 있는 관리형 서비스입니다.
- Amazon SQS: 완전관리형 메시지 대기열 서비스로, 분산 시스템 간 메시지 전달 및 버퍼링에 사용됩니다.
- AWS Lambda: 서버리스 컴퓨팅 서비스로, 코드를 실행하고 자동으로 모든 컴퓨팅 리소스를 관리합니다. 이벤트 기반으로 실행되어 데이터 처리 작업 자동화에 적합합니다.
- Amazon SNS: 완전관리형 게시-구독 메시징 서비스로, 메시지를 여러 대상으로 팬아웃할 수 있습니다.
3. 선택지 분석하기
A. 대상이 소비할 Amazon Simple Queue Service(Amazon SQS) 대기열로 정보를 전송하도록 Amazon RDS의 데이터베이스가 업데이트될 때 트리거되는 AWS Lambda 함수를 생성합니다.
→ RDS 데이터베이스 변경 사항을 SQS 대기열로 전송하고, Lambda 함수를 사용하여 대기열에서 메시지를 읽고 대상 시스템을 업데이트하는 아키텍처입니다. 완전관리형 서비스를 활용하여 운영 오버헤드를 줄이고 대기열을 통해 시스템을 분리하여 확장성과 탄력성을 확보할 수 있습니다.
B. 대상이 사용할 Amazon Simple Queue Service(Amazon SQS) FIFO 대기열에 정보를 전송하도록 Amazon RDS의 데이터베이스가 업데이트될 때 트리거되는 AWS Lambda 함수를 생성합니다.
→ FIFO 대기열은 메시지 순서를 보장하지만, 이 시나리오에서는 필요하지 않습니다. 불필요한 오버헤드가 발생할 수 있습니다.
C. RDS 이벤트 알림을 구독하고 여러 Amazon Simple Notification Service(Amazon SNS) 주제로 팬 아웃된 Amazon Simple Queue Service(Amazon SQS) 대기열을 보냅니다. AWS Lambda 함수를 사용하여 대상을 업데이트합니다.
→ SNS를 추가로 사용하면 불필요한 복잡성이 증가하고 비용이 발생합니다. 단일 SQS 대기열로도 충분히 요구사항을 충족할 수 있습니다.
D. RDS 이벤트 알림을 구독하고 여러 Amazon Simple Queue Service(Amazon SQS) 대기열로 팬 아웃된 Amazon Simple Notification Service(Amazon SNS) 주제를 보냅니다. AWS Lambda 함수를 사용하여 대상을 업데이트합니다.
→ 이 옵션도 SNS를 추가로 사용하여 불필요한 복잡성과 비용이 발생합니다. 단일 SQS 대기열로도 충분히 요구사항을 충족할 수 있습니다.
마지막 문제 살펴볼게요.
문제3
회사에서 기밀 데이터를 Amazon S3에 저장할 준비를 하고 있습니다. 규정 준수를 위해 데이터는 유휴 상태에서 암호화되어야 합니다. 감사 목적으로 암호화 키 사용을 기록해야 합니다. 키 는 매년 교체해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족하고 운영상 가장 효율적입니까?
선택지
A. 고객 제공 키를 사용한 서버 측 암호화(SSE-C)
B. Amazon S3 관리 키(SSE-S3)를 사용한 서버 측 암호화
C. 수동 교체가 있는 AWS KMS 키(SSE-KMS)를 사용한 서버 측 암호화
D. 자동 교체가 있는 AWS KMS 키(SSE-KMS)를 사용한 서버 측 암호화
풀이
AWS Key Management Service(AWS KMS)를 통해 관리되는 키와 자동 교체 기능을 사용하면 규정 준수를 보장하고 운영 오버헤드를 최소화할 수 있습니다. KMS는 FIPS 140-2 규격을 준수하는 하드웨어 보안 모듈을 사용하여 키를 보호하고, 감사 로그를 제공하여 키 사용을 추적할 수 있습니다. 자동 키 교체 기능을 사용하면 매년 새로운 키를 자동으로 생성하고 이전 키를 삭제하여 규정 준수를 보장합니다.
정답 : D
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 기밀 데이터를 Amazon S3에 저장 시 유휴 상태에서 암호화 필요 (규정 준수)
- 암호화 키 사용 기록 필요 (감사 목적)
- 키를 매년 교체해야 함
- 운영 효율성 고려
2. 관련 AWS 서비스 생각하기
- Amazon S3 서버 측 암호화 옵션:
- SSE-S3: Amazon S3 관리 키로 암호화 (AWS 관리형)
- SSE-KMS: AWS KMS 관리 키로 암호화 (고객 관리형, 감사 로그 제공, 키 회전 가능)
- SSE-C: 고객 제공 키로 암호화 (고객이 직접 키 관리)
- AWS Key Management Service (AWS KMS):
- 암호화 키 생성, 관리 및 사용에 대한 감사 추적을 제공하는 관리형 서비스
- 자동 키 교체 기능 제공
3. 선택지 분석하기
A. 고객 제공 키를 사용한 서버 측 암호화(SSE-C)
→ 고객이 직접 키를 관리해야 하므로 운영 오버헤드가 크고 규정 준수를 보장하기 어렵습니다.
B. Amazon S3 관리 키(SSE-S3)를 사용한 서버 측 암호화
→ AWS에서 키를 관리하므로 편리하지만, 고객이 직접 키 사용을 감사할 수 없고 키 교체 일정을 제어할 수 없습니다.
C. 수동 교체가 있는 AWS KMS 키(SSE-KMS)를 사용한 서버 측 암호화
→ KMS를 사용하면 키 사용을 감사할 수 있고 키 교체가 가능하지만, 수동 교체는 운영 오버헤드를 발생시킵니다.
D. 자동 교체가 있는 AWS KMS 키(SSE-KMS)를 사용한 서버 측 암호화
→ KMS를 사용하여 키 사용을 감사할 수 있고, 자동 키 교체 기능을 통해 매년 새로운 키를 자동으로 생성하여 규정 준수를 보장하면서도 운영 오버헤드를 최소화할 수 있습니다.
감사합니다!
'AWS > SAA 준비' 카테고리의 다른 글
| AWS SAA 합격으로 가는 길 #53 (0) | 2025.01.27 |
|---|---|
| AWS SAA 합격으로 가는 길 #52 (0) | 2025.01.24 |
| AWS SAA 합격으로 가는 길 #50 (1) | 2025.01.13 |
| AWS SAA 합격으로 가는 길 #49 (0) | 2025.01.10 |
| AWS SAA 합격으로 가는 길 #48 (0) | 2025.01.06 |