AWS SAA 합격으로 가는 길 #70

안녕하세요, NxtCloud SA 백종훈입니다. AWS SAA 자격증 준비를 위한 실전 문제 풀이를 진행하겠습니다. 문제를 함께 다루며 AWS 서비스에 대한 이해도를 높이는 시간이 되길 바랍니다.

 

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

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

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

3. 선택지 분석하기

 

바로 문제 풀이 해보겠습니다!

---

문제1

회사에서 기존 온프레미스 모놀리식 애플리케이션을 AWS로 마이그레이션하려고 합니다. 회사는 프런트엔드 코드와 백엔드 코드를 최대한 많이 유지하려고 합니다. 그러나 회사는 응용 프로 그램을 더 작은 응용 프로그램으로 나누기를 원합니다. 다른 팀이 각 애플리케이션을 관리합니다. 이 회사는 운영 오버헤드를 최소화하는 확장성이 뛰어난 솔루션이 필요합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

선택지

A. AWS Lambda에서 애플리케이션을 호스팅합니다. 애플리케이션을 Amazon API Gateway와 통합합니다.

B. AWS Amplify로 애플리케이션을 호스팅합니다. AWS Lambda와 통합된 Amazon API Gateway API에 애플리케이션을 연결합니다.

C. Amazon EC2 인스턴스에서 애플리케이션을 호스팅합니다. Auto Scaling 그룹의 EC2 인스턴스를 대상으로 하는 Application Load Balancer를 설정합니다.

D. Amazon Elastic Container Service(Amazon ECS)에서 애플리케이션을 호스팅합니다. Amazon ECS를 대상으로 하는 Application Load Balancer를 설정합니다.

 

풀이

기존 온프레미스 애플리케이션을 마이크로서비스로 분할하여 AWS로 마이그레이션하려는 상황입니다. 최대한 기존 코드를 유지하면서 애플리케이션을 운영 오버헤드가 적은 확장성 높은 환경에서 실행하는 것이 목표입니다.

 

정답 : D

 

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

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

• 온프레미스 모놀리식 애플리케이션을 AWS로 마이그레이션 
• 프런트엔드/백엔드 코드 최대한 유지 
• 애플리케이션을 마이크로서비스 형태로 분할 
• 운영 오버헤드 최소화하며 확장성 있는 솔루션 필요

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

• Amazon EC2(Elastic Compute Cloud)는 AWS에서 가상 서버(인스턴스)를 프로비저닝하고 실행할 수 있는 기본 컴퓨팅 서비스입니다. EC2 인스턴스에 직접 애플리케이션을 호스팅할 수 있지만, 수동 프로비저닝과 관리가 필요하므로 운영 오버헤드가 크고 확장성에 제한이 있습니다.
• AWS Lambda는 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행할 수 있는 서버리스 컴퓨팅 서비스입니다. 이벤트 중심으로 자동 확장되며 사용한 만큼만 비용을 지불하므로 운영 오버헤드가 최소화됩니다. 그러나 기존 애플리케이션 코드를 Lambda 함수로 재작성해야 하는 단점이 있습니다.
• Amazon ECS(Elastic Container Service)는 Docker 컨테이너를 실행하고 관리할 수 있는 완전관리형 컨테이너 오케스트레이션 서비스입니다. 애플리케이션을 컨테이너화하여 마이크로서비스로 분할할 수 있으며, Auto Scaling 기능을 통해 확장성을 확보할 수 있습니다. 기존 애플리케이션을 컨테이너화하는 작업은 필요하지만 코드 자체를 수정할 필요는 없습니다.
• Amazon API Gateway는 API를 생성, 게시, 유지관리, 모니터링 및 보안을 적용할 수 있는 서비스입니다. 마이크로서비스 기반 애플리케이션에서 서로 다른 컴포넌트 간의 통신을 중개합니다.

3. 선택지 분석하기

A. AWS Lambda에서 애플리케이션을 호스팅합니다. 애플리케이션을 Amazon API Gateway와 통합합니다.

→ Lambda는 서버리스 아키텍처로 운영 오버헤드가 최소화되지만, 기존 코드를 그대로 유지하기 어려운 단점이 있습니다.

 

B. AWS Amplify로 애플리케이션을 호스팅합니다. AWS Lambda와 통합된 Amazon API Gateway API에 애플리케이션을 연결합니다.

→ Amplify는 주로 웹/모바일 프런트엔드 개발에 활용되며, 백엔드 마이크로서비스까지 포함하지는 않습니다.

 

C. Amazon EC2 인스턴스에서 애플리케이션을 호스팅합니다. Auto Scaling 그룹의 EC2 인스턴스를 대상으로 하는 Application Load Balancer를 설정합니다.

→ EC2 인스턴스에서 애플리케이션을 직접 호스팅하면 운영 오버헤드가 증가하고, 모놀리식 아키텍처를 완전히 벗어나기 어렵습니다.

 

D. Amazon Elastic Container Service(Amazon ECS)에서 애플리케이션을 호스팅합니다. Amazon ECS를 대상으로 하는 Application Load Balancer를 설정합니다.

→ ECS를 사용하면 기존 애플리케이션을 컨테이너화하여 마이크로서비스로 분할할 수 있으며, 자동 확장 및 로드 밸런싱을 통해 운영 오버헤드를 최소화하고 확장성을 확보할 수 있습니다.

 

이어서 다음 문제입니다.

---

문제2

솔루션 설계자는 회사의 스토리지 비용을 줄이기 위해 솔루션을 구현해야 합니다. 회사의 모든 데이터는 Amazon S3 Standard 스토리지 클래스에 있습니다. 회사는 모든 데이터를 최소 25 년 동안 보관해야 합니다. 가장 최근 2년 간의 데이터는 가용성이 높고 즉시 검색할 수 있어야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

선택지

A. S3 수명 주기 정책을 설정하여 객체를 S3 Glacier Deep Archive로 즉시 전환하십시오.

B. 2년 후 객체를 S3 Glacier Deep Archive로 전환하도록 S3 수명 주기 정책을 설정합니다.

C. S3 Intelligent-Tiering을 사용합니다. 보관 옵션을 활성화하여 데이터가 S3 Glacier Deep Archive에 보관되도록 합니다.

D. 객체를 S3 One Zone-Infrequent Access(S3 One Zone-IA)로 즉시 전환하고 2년 후에 S3 Glacier Deep Archive로 전환하도록 S3 수명 주기 정책을 설정합니다.

---

풀이

회사의 모든 데이터를 오랜 기간 보관해야 하지만, 최신 데이터는 높은 가용성과 검색 성능이 필요합니다. 가장 효과적인 방법은 S3 스토리지 클래스 간 데이터 전환을 활용하는 것입니다.

 

정답 : B

 

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

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

• 모든 데이터 최소 25년 보관 
• 최근 2년 데이터는 높은 가용성, 즉시 검색 가능해야 함

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

• Amazon S3(Simple Storage Service)는 AWS의 객체 스토리지 서비스로, 다양한 스토리지 클래스를 제공하여 비용 효율성과 액세스 패턴에 따라 적절한 스토리지를 선택할 수 있습니다.
• S3 Standard는 일반적인 용도로 설계된 스토리지 클래스로, 높은 가용성과 내구성, 빠른 데이터 액세스 성능을 제공합니다. 최근 2년 데이터에 적합합니다.
• S3 Glacier Deep Archive는 장기 아카이브 스토리지 클래스로, 매우 낮은 스토리지 비용을 제공하지만 데이터 검색 시간이 오래 걸립니다. 오래된 데이터를 저렴하게 보관하는 데 적합합니다.
• S3 Intelligent-Tiering은 객체의 액세스 패턴을 모니터링하여 자동으로 가장 적절한 스토리지 클래스로 전환해줍니다. S3 Standard와 S3 Glacier Deep Archive 사이에서 이동되며, 스토리지 비용을 절감할 수 있습니다.
• S3 수명 주기 정책을 통해 사용자가 직접 객체의 수명 주기 동안 다른 스토리지 클래스로 전환할 수 있습니다. 시간 기반 또는 객체 크기 기반 규칙을 설정할 수 있습니다.

3. 선택지 분석하기

A. S3 수명 주기 정책을 설정하여 객체를 S3 Glacier Deep Archive로 즉시 전환하십시오.

→ 최근 2년 데이터에 대한 고가용성 및 즉시 검색 요구사항을 만족하지 못합니다.

 

B. 2년 후 객체를 S3 Glacier Deep Archive로 전환하도록 S3 수명 주기 정책을 설정합니다.

→ 최근 2년 데이터는 S3 Standard에 유지되어 고가용성과 즉시 검색 성능을 제공하고, 2년이 지난 데이터는 S3 Glacier Deep Archive로 이동하여 장기 보관 비용을 절감할 수 있습니다.

 

C. S3 Intelligent-Tiering을 사용합니다. 보관 옵션을 활성화하여 데이터가 S3 Glacier Deep Archive에 보관되도록 합니다.

→ Intelligent-Tiering은 액세스 패턴에 따라 자동으로 스토리지 클래스를 전환하므로 요구사항을 완벽히 제어할 수 없습니다.

 

D. 객체를 S3 One Zone-Infrequent Access(S3 One Zone-IA)로 즉시 전환하고 2년 후에 S3 Glacier Deep Archive로 전환하도록 S3 수명 주기 정책을 설정합니다.

→ One Zone-IA는 Reduced Redundancy를 사용하므로 데이터 내구성이 낮아집니다.

 

마지막 문제 살펴볼게요.

---

문제3

회사에서 데이터를 Amazon S3 버킷으로 이동할 계획입니다. 데이터는 S3 버킷에 저장될 때 암호화되어야 합니다. 또한 암호화 키는 매년 자동으로 순환되어야 합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

선택지

A. 데이터를 S3 버킷으로 이동합니다. Amazon S3 관리형 암호화 키(SSE-S3)로 서버 측 암호화를 사용합니다. SSE-S3 암호화 키의 기본 제공 키 회전 동작을 사용합니다.

B. AWS Key Management Service(AWS KMS) 고객 관리형 키를 생성합니다. 자동 키 순환을 활성화합니다. 고객 관리형 KMS 키를 사용하도록 S3 버킷의 기본 암호화 동작을 설 정합니다. 데이터를 S3 버킷으로 이동합니다.

C. AWS Key Management Service(AWS KMS) 고객 관리형 키를 생성합니다. 고객 관리형 KMS 키를 사용하도록 S3 버킷의 기본 암호화 동작을 설정합니다. 데이터를 S3 버킷으 로 이동합니다. 매년 KMS 키를 수동으로 교체합니다.

D. 데이터를 S3 버킷으로 이동하기 전에 고객 키 자료로 데이터를 암호화합니다. 키 자료 없이 AWS Key Management Service(AWS KMS) 키를 생성합니다. 고객 키 자료를 KMS 키로 가져옵니다. 자동 키 순환을 활성화합니다.

 

 

풀이

S3 버킷에 저장된 데이터는 기본적으로 암호화되지 않으므로, 데이터 암호화와 주기적 키 교체를 위해서는 고객 관리형 KMS 키를 사용해야 합니다. KMS의 자동 키 순환 기능을 활성화하면 최소 운영 오버헤드로 요구사항을 충족할 수 있습니다.

 

정답 : B

 

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

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

• S3 버킷에 저장될 데이터는 암호화되어야 함 
• 암호화 키는 매년 자동으로 순환(교체)되어야 함 
• 운영 오버헤드 최소화

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

• SSE-S3(서버 측 암호화): AWS 관리형 키를 사용하여 S3에서 데이터를 암호화합니다. 키 관리 및 교체가 불가능합니다. 
• SSE-KMS(서버 측 암호화): AWS KMS 서비스의 고객 관리형 키를 사용하여 S3에서 데이터를 암호화합니다. 키 관리와 자동 키 순환이 가능합니다. 
• 클라이언트 측 암호화: 업로드 전에 고객이 데이터를 암호화하고 암호화된 데이터를 S3에 전송합니다. 고객이 전적으로 키 관리를 담당합니다..

 

3. 선택지 분석하기

A. 데이터를 S3 버킷으로 이동합니다. Amazon S3 관리형 암호화 키(SSE-S3)로 서버 측 암호화를 사용합니다. SSE-S3 암호화 키의 기본 제공 키 회전 동작을 사용합니다.

→ SSE-S3는 AWS 관리형 키로, 사용자가 제어할 수 없으므로 매년 키 교체 요구사항을 만족하지 못합니다.

 

B. AWS Key Management Service(AWS KMS) 고객 관리형 키를 생성합니다. 자동 키 순환을 활성화합니다. 고객 관리형 KMS 키를 사용하도록 S3 버킷의 기본 암호화 동작을 설정합니다. 데이터를 S3 버킷으로 이동합니다.

→ 고객 관리형 KMS 키를 사용하여 데이터를 암호화하고, 자동 키 순환을 활성화하면 매년 키가 자동으로 교체되므로 요구사항을 충족하며 운영 오버헤드도 최소화됩니다.

 

C. AWS Key Management Service(AWS KMS) 고객 관리형 키를 생성합니다. 고객 관리형 KMS 키를 사용하도록 S3 버킷의 기본 암호화 동작을 설정합니다. 데이터를 S3 버킷으로 이동합니다. 매년 KMS 키를 수동으로 교체합니다.

→ 수동 키 교체로 인해 운영 오버헤드가 발생합니다.

 

D. 데이터를 S3 버킷으로 이동하기 전에 고객 키 자료로 데이터를 암호화합니다. 키 자료 없이 AWS Key Management Service(AWS KMS) 키를 생성합니다. 고객 키 자료를 KMS 키로 가져옵니다. 자동 키 순환을 활성화합니다.

→ 클라이언트 측 데이터 암호화는 성능 저하를 초래할 수 있습니다. 또한 키 자료를 안전하게 관리해야 하는 부담이 있습니다.

 

 

감사합니다