AWS SAA 합격으로 가는 길 #193

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

어느덧 7월의 마지막 주가 밝았습니다! 🌴

월요일 아침, 상쾌한 마음으로 가볍게, 그러나 꼼꼼히 짚어보겠습니다!

 

 

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

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

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

3. 선택지 분석하기

 

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

---

문제1

회사는 재생성할 수 없는 많은 파일을 생성하는 애플리케이션에 대해 Amazon S3 스토리지 비용을 최적화해야 합니다. 각 파일은 약 5MB이며 Amazon S3 Standard 스토리지에 저장됩니다. 회사는 파일을 삭제하기 전에 해당 파일을 4년 동안 보관해야 합니다. 파일에 즉시 액세스할 수 있어야 합니다. 파일은 객체 생성 후 처음 30일 동안 자주 액세스되지만 처음 30일 이후에는 거의 액세스되지 않습니다. 이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?

 

선택지

A. 객체 생성 후 30일이 지나면 파일을 S3 Glacier Instant Retrieval로 이동하는 S3 수명 주기 정책을 생성합니다. 객체 생성 후 4년이 지나면 파일을 삭제합니다.
B. 객체 생성 후 30일이 지나면 파일을 S3 One Zone-Infrequent Access(S3 One Zone-IA)로 이동하는 S3 수명 주기 정책을 생성합니다. 객체 생성 후 4년이 지나면 파일을 삭제합니다.
C. 객체 생성 후 30일 후에 파일을 S3 Standard-Infrequent Access(S3 Standard-IA)로 이동하는 S3 수명 주기 정책을 생성합니다. 객체 생성 후 4년이 지나면 파일을 삭제합니다.
D. 객체 생성 후 30일이 지나면 S3 Standard-Infrequent Access(S3 Standard-IA)로 파일을 이동하는 S3 수명 주기 정책을 생성합니다. 객체 생성 후 4년이 지나면 파일을 S3 Glacier 유연한 검색으로 이동합니다.

---

풀이

재생성할 수 없는 파일을 즉시 접근 가능한 상태로 두면서 30일 이후의 저빈도 접근에 맞춰 비용을 낮추는 것이 핵심입니다. S3 Standard-IA는 여러 가용 영역에 복제되어 내구성이 높고 즉시 접근이 가능하면서 저장 비용이 저렴하므로, 30일 후 전환 후 4년 뒤 삭제하는 구성이 가장 비용 효율적입니다.

 

정답 : C

 

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

---

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

• 재생성이 불가능한 파일이므로 높은 내구성 필요
• 4년간 보관 후 삭제하는 수명 주기 관리
• 언제든 즉시 액세스가 가능해야 함
• 30일 이후 저빈도 접근에 맞춘 비용 최적화

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

• Amazon S3 (Simple Storage Service) : 객체를 버킷에 저장하는 오브젝트 스토리지 서비스로, 데이터의 액세스 빈도와 특성에 따라 여러 스토리지 클래스를 선택해 비용과 성능을 조절할 수 있습니다. 자주 쓰지 않는 데이터를 저비용 클래스로 옮기면 스토리지 비용을 크게 아낄 수 있습니다.
  
  • S3 Standard : 자주 액세스하는 데이터를 위한 기본 클래스로, 즉시 접근이 가능하지만 저장 비용은 가장 높은 편입니다.
  • S3 Standard-IA(Standard-Infrequent Access) : 자주 액세스하지는 않지만 필요할 때 즉시 접근해야 하는 데이터를 위한 클래스입니다. 여러 가용 영역에 복제되어 내구성이 높으면서 저장 비용은 Standard보다 저렴하며, 데이터를 읽을 때 검색 요금이 부과됩니다.
  • S3 One Zone-IA(One Zone-Infrequent Access) : 자주 액세스하지 않는 데이터를 단일 가용 영역(AZ)에만 저장하여 비용을 더 낮춘 클래스입니다. 여러 가용 영역에 복제하지 않으므로 해당 가용 영역에 장애가 생기면 데이터를 잃을 수 있습니다.
  • S3 Glacier Instant Retrieval : 거의 액세스하지 않는 아카이브 데이터를 즉시 검색할 수 있는 저비용 클래스입니다. 저장 비용은 낮지만 최소 보관 기간이 길고 검색 요금이 있어, 분기에 한 번 수준으로 접근이 매우 드문 데이터에 적합합니다.
  • S3 Glacier Flexible Retrieval(유연한 검색) : 접근 빈도가 극히 낮은 장기 아카이브용 클래스로 저장 비용이 매우 저렴하지만, 데이터를 꺼낼 때 수 분에서 수 시간이 걸려 즉시 접근이 어렵습니다.
• S3 수명 주기 정책 (Lifecycle Policy) : 객체를 일정 기간이 지나면 자동으로 다른 스토리지 클래스로 전환하거나 만료시켜 삭제하는 규칙입니다. 사람이 직접 개입하지 않아도 데이터의 나이에 따라 비용을 최적화할 수 있습니다.

3. 선택지 분석하기

A. 객체 생성 후 30일이 지나면 파일을 S3 Glacier Instant Retrieval로 이동하는 S3 수명 주기 정책을 생성합니다. 객체 생성 후 4년이 지나면 파일을 삭제합니다.
→ Glacier Instant Retrieval은 저장 비용은 더 낮지만 최소 보관 기간이 90일로 길고 검색 요금이 Standard-IA보다 비싸므로, 4년에 걸쳐 이따금이라도 즉시 접근이 필요한 이 데이터에는 검색 비용까지 고려하면 오히려 불리하여 적절치 않습니다.

B. 객체 생성 후 30일이 지나면 파일을 S3 One Zone-Infrequent Access(S3 One Zone-IA)로 이동하는 S3 수명 주기 정책을 생성합니다. 객체 생성 후 4년이 지나면 파일을 삭제합니다.
→ One Zone-IA는 저장 비용이 더 낮지만 단일 가용 영역에만 저장되어 장애 시 데이터가 유실될 수 있으므로, 재생성이 불가능한 파일에는 내구성 측면에서 적절치 않습니다.

C. 객체 생성 후 30일 후에 파일을 S3 Standard-Infrequent Access(S3 Standard-IA)로 이동하는 S3 수명 주기 정책을 생성합니다. 객체 생성 후 4년이 지나면 파일을 삭제합니다.
→ Standard-IA는 여러 가용 영역에 복제되어 내구성이 높고 즉시 접근이 가능하면서 저장 비용이 저렴하므로, 재생성 불가 파일을 저빈도 구간에 맞춰 비용 최적화하기에 가장 적절한 방법입니다.

D. 객체 생성 후 30일이 지나면 S3 Standard-Infrequent Access(S3 Standard-IA)로 파일을 이동하는 S3 수명 주기 정책을 생성합니다. 객체 생성 후 4년이 지나면 파일을 S3 Glacier 유연한 검색으로 이동합니다.
→ 4년이 지나면 파일을 삭제해야 하는데 Glacier 유연한 검색으로 옮기면 삭제 요건을 충족하지 못하고 저장 비용도 계속 발생하므로, 요구 사항에 부합하지 않습니다.

---

 

이어서 다음 문제입니다.

---

문제2

회사는 애플리케이션과 함께 Amazon Aurora PostgreSQL 프로비저닝 클러스터를 사용합니다. 애플리케이션의 최대 트래픽은 30분에서 몇 시간 동안 하루에 여러 번 발생합니다. 애플리케이션의 최대 트래픽을 처리하기 위해 데이터베이스 용량이 프로비저닝되었지만 피크가 아닌 시간 동안 데이터베이스에서 용량이 낭비되었습니다. 회사는 데이터베이스 비용을 절감하려고 합니다. 최소한의 운영 노력으로 이러한 요구 사항을 충족할 수 있는 솔루션은 무엇입니까?

 

선택지

A. 데이터베이스 활용도를 모니터링하려면 Amazon CloudWatch 경보를 설정하십시오. 트래픽 양에 따라 데이터베이스 용량을 확장하거나 축소합니다.
B. 데이터베이스를 Auto Scaling 그룹의 Amazon EC2 인스턴스로 마이그레이션합니다. 트래픽 양에 따라 인스턴스 수를 늘리거나 줄입니다.
C. 데이터베이스를 Amazon Aurora Serverless DB 클러스터로 마이그레이션하여 트래픽 양에 따라 용량을 확장하거나 축소합니다.
D. 매일 시작 시 필요한 데이터베이스 용량을 프로비저닝하도록 AWS Lambda 함수를 예약합니다. 하루가 끝날 때 용량을 줄이기 위해 다른 Lambda 기능을 예약하십시오.

---

풀이

하루에도 여러 번 짧게 몰리는 트래픽에 맞춰 용량을 자동으로 조절해 낭비를 없애되 운영 노력을 최소화하는 것이 핵심입니다. Aurora Serverless는 워크로드에 따라 용량을 자동으로 확장하고 축소하며 사용한 만큼만 요금이 부과되므로, 변동이 큰 트래픽에서 비용을 절감하기에 가장 적합합니다.

 

정답 : C

 

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

---

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

• 하루에 여러 번 짧게 발생하는 변동성 큰 피크 트래픽
• 피크가 아닌 시간의 프로비저닝 용량 낭비 제거
• 데이터베이스 비용 절감 및 최소한의 운영 노력 필요

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

• Amazon Aurora : MySQL 및 PostgreSQL과 호환되는 완전관리형 관계형 데이터베이스로, 높은 성능과 가용성을 제공합니다. 용량을 운영하는 방식에 따라 두 가지 형태로 나뉩니다.
  
  • 프로비저닝(Provisioned) 클러스터 : 미리 정해진 인스턴스 용량을 지속적으로 확보해 두는 방식입니다. 성능이 일정하게 유지되지만, 트래픽이 적은 시간에도 확보한 용량만큼 요금이 부과되어 사용량이 들쭉날쭉하면 비용이 낭비될 수 있습니다.
  • Aurora Serverless : 애플리케이션의 부하에 따라 데이터베이스 용량을 자동으로 확장하고 축소하는 방식입니다. 실제 사용한 용량에 대해서만 요금이 부과되며, 용량을 직접 조정할 필요가 없어 트래픽 변동이 크거나 예측하기 어려운 워크로드에서 비용과 운영 부담을 함께 줄일 수 있습니다.
• AWS Lambda : 서버를 관리하지 않고 코드를 실행하는 서버리스 컴퓨팅 서비스로, 일정에 맞춰 특정 작업을 자동으로 실행할 수 있습니다. 다만 수행할 동작을 코드로 직접 작성하고 예약과 오류 처리를 관리해야 하므로 운영 부담이 따르는 편입니다.

3. 선택지 분석하기

A. 데이터베이스 활용도를 모니터링하려면 Amazon CloudWatch 경보를 설정하십시오. 트래픽 양에 따라 데이터베이스 용량을 확장하거나 축소합니다.
→ CloudWatch 경보로 활용도를 감시할 수는 있으나 용량 조정을 위한 별도의 자동화나 수동 개입이 필요하여, 최소한의 운영 노력으로 충족하기에는 부담이 커 적절치 않습니다.

B. 데이터베이스를 Auto Scaling 그룹의 Amazon EC2 인스턴스로 마이그레이션합니다. 트래픽 양에 따라 인스턴스 수를 늘리거나 줄입니다.
→ 데이터베이스를 EC2로 옮기면 운영체제와 데이터베이스 엔진을 직접 관리해야 하고 상태를 가진 데이터베이스는 단순 인스턴스 증감으로 확장하기도 어려우므로, 운영 부담이 커 적절치 않습니다.

C. 데이터베이스를 Amazon Aurora Serverless DB 클러스터로 마이그레이션하여 트래픽 양에 따라 용량을 확장하거나 축소합니다.
→ Aurora Serverless는 부하에 따라 용량을 자동으로 조절하고 사용한 만큼만 과금되므로, 변동이 큰 트래픽에서 비용을 절감하면서 운영 노력을 최소화하기에 가장 적절한 방법입니다.

D. 매일 시작 시 필요한 데이터베이스 용량을 프로비저닝하도록 AWS Lambda 함수를 예약합니다. 하루가 끝날 때 용량을 줄이기 위해 다른 Lambda 기능을 예약하십시오.
→ Lambda로 용량을 예약 조정하려면 함수를 직접 작성하고 유지해야 할 뿐 아니라 하루에 여러 번 불규칙하게 발생하는 피크에는 정해진 일정으로 대응하기 어려우므로 적절치 않습니다.

---

 

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

---

문제3

회사에는 Auto Scaling 그룹의 Amazon EC2 인스턴스에서 실행되는 내부 애플리케이션이 있습니다. EC2 인스턴스는 컴퓨팅에 최적화되어 있으며 Amazon Elastic Block Store(Amazon EBS) 볼륨을 사용합니다. 회사는 EC2 인스턴스, Auto Scaling 그룹 및 EBS 볼륨 전반에 걸쳐 비용 최적화를 식별하려고 합니다. 가장 효율적인 운영 효율성으로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

선택지

A. 새로운 AWS 비용 및 사용 보고서를 생성합니다. EC2 인스턴스, Auto Scaling 그룹 및 EBS 볼륨에 대한 비용 권장 사항에 대한 보고서를 검색합니다.
B. 새로운 Amazon CloudWatch 결제 알림을 생성합니다. EC2 인스턴스, Auto Scaling 그룹 및 EBS 볼륨에 대한 비용 권장 사항에 대한 경고 상태를 확인하세요.
C. EC2 인스턴스, Auto Scaling 그룹 및 EBS 볼륨에 대한 비용 권장 사항을 위해 AWS Compute Optimizer를 구성합니다.
D. EC2 인스턴스에 대한 비용 권장 사항을 위해 AWS Compute Optimizer를 구성합니다. 새로운 AWS 비용 및 사용 보고서를 생성합니다. Auto Scaling 그룹 및 EBS 볼륨에 대한 비용 권장 사항에 대한 보고서를 검색합니다.

---

풀이

EC2 인스턴스, Auto Scaling 그룹, EBS 볼륨 전반의 리소스 크기를 분석해 비용 최적화 방안을 손쉽게 찾는 것이 핵심입니다. AWS Compute Optimizer는 이 리소스들의 사용 지표를 분석해 최적의 크기를 자동으로 권장하므로, 하나의 서비스로 최소한의 노력으로 요구 사항을 충족합니다.

 

정답 : C

 

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

---

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

• EC2 인스턴스, Auto Scaling 그룹, EBS 볼륨 전반의 비용 최적화
• 리소스 크기 조정을 위한 구체적 권장 사항 확보
• 수작업 분석을 줄인 자동화된 방식
• 가장 높은 운영 효율성으로 구현

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

• AWS Compute Optimizer : 리소스의 사용 지표를 머신러닝으로 분석하여 비용과 성능에 가장 알맞은 크기를 자동으로 권장하는 서비스입니다. Amazon EC2 인스턴스, Auto Scaling 그룹, Amazon EBS 볼륨, AWS Lambda 함수 등 여러 리소스 유형을 지원하며, 과도하게 크거나 부족하게 설정된 리소스를 식별해 조정 방안을 제시합니다. 별도의 분석 도구를 만들 필요 없이 활성화만으로 권장 사항을 받아볼 수 있어 운영 효율이 높습니다.
• AWS 비용 및 사용 보고서 (CUR, Cost and Usage Report) : 계정에서 발생한 비용과 사용량을 가장 상세하게 제공하는 보고서입니다. 요금 내역을 깊이 있게 분석할 수 있지만, 리소스 크기 조정에 대한 직접적인 권장 사항을 제공하지는 않아 사용자가 데이터를 직접 해석해야 합니다.
• Amazon CloudWatch : AWS 리소스와 애플리케이션의 지표를 모니터링하고 경보를 설정하는 서비스입니다. 결제 알림 기능으로 요금이 임계값을 넘으면 알려줄 수 있지만, 리소스별 크기 조정 권장 사항을 제시하지는 않습니다.

3. 선택지 분석하기

A. 새로운 AWS 비용 및 사용 보고서를 생성합니다. EC2 인스턴스, Auto Scaling 그룹 및 EBS 볼륨에 대한 비용 권장 사항에 대한 보고서를 검색합니다.
→ 비용 및 사용 보고서는 상세한 요금 내역을 제공하지만 리소스 크기 조정 권장 사항을 직접 제시하지 않아 사용자가 데이터를 해석해야 하므로, 운영 효율 측면에서 적절치 않습니다.

B. 새로운 Amazon CloudWatch 결제 알림을 생성합니다. EC2 인스턴스, Auto Scaling 그룹 및 EBS 볼륨에 대한 비용 권장 사항에 대한 경고 상태를 확인하세요.
→ CloudWatch 결제 알림은 요금이 임계값을 넘을 때 알려줄 뿐 리소스별 최적 크기를 권장하지 않으므로, 비용 최적화 방안을 식별하려는 요구 사항에는 적절치 않습니다.

C. EC2 인스턴스, Auto Scaling 그룹 및 EBS 볼륨에 대한 비용 권장 사항을 위해 AWS Compute Optimizer를 구성합니다.
→ Compute Optimizer는 EC2 인스턴스와 Auto Scaling 그룹, EBS 볼륨의 사용 지표를 분석해 최적 크기를 자동으로 권장하므로, 하나의 서비스로 세 리소스의 비용 최적화를 식별하기에 가장 적절한 방법입니다.

D. EC2 인스턴스에 대한 비용 권장 사항을 위해 AWS Compute Optimizer를 구성합니다. 새로운 AWS 비용 및 사용 보고서를 생성합니다. Auto Scaling 그룹 및 EBS 볼륨에 대한 비용 권장 사항에 대한 보고서를 검색합니다.
→ Compute Optimizer 하나로 세 리소스를 모두 다룰 수 있는데도 비용 및 사용 보고서를 추가로 병행하면 구성이 복잡해지고 수작업 분석이 늘어나므로, 운영 효율 측면에서 적절치 않습니다.

---

 

무더운 여름 월요일, 힘차게 한 주를 시작해 주셔서 고맙습니다. 

이번 한 주도 응원하겠습니다. 다음 시간에 또 만나요!