AWS SAA 합격으로 가는 길 #146

안녕하세요! 넥스트클라우드의 EduOps 백종훈입니다.
2025년 새해 첫 SAA 포스팅으로 인사드립니다.
새해를 맞아 많이 바쁘시겠지만, 새로운 마음가짐으로 자격증 취득에 도전해보시는 건 어떨까요?
오늘도 함께 공부하며 힘차게 시작해봅시다!

 

 

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

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

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

3. 선택지 분석하기

 

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

---

문제1

회사에는 다양한 AWS 리전의 여러 AWS 계정에 분산된 프로덕션 워크로드가 있습니다. 이 회사는 AWS Cost Explorer를 사용하여 비용과 사용량을 지속적으로 모니터링합니다. 회사는 워크로드의 비용 및 사용 지출이 비정상적일 때 알림을 받기를 원합니다. 이러한 요구 사항을 충족하는 단계 조합은 무엇입니까? (2개 선택)

 

선택지

A. 프로덕션 워크로드가 실행 중인 AWS 계정에서 AWS Cost Management 콘솔의 Cost Explorer를 사용하여 연결된 계정 예산을 생성합니다.

B. 프로덕션 워크로드가 실행 중인 AWS 계정에서 AWS Cost Management 콘솔의 AWS Cost Anomaly Detection을 사용하여 연결된 계정 모니터를 생성합니다.

C. 프로덕션 워크로드가 실행 중인 AWS 계정에서 AWS 비용 관리 콘솔의 비용 이상 탐지를 사용하여 비용 및 사용 보고서를 생성합니다. D. 보고서를 작성하고 이메일 메시지를 보내 매주 회사에 알립니다.

E. 필요한 임계값으로 구독을 생성하고 주간 요약을 사용하여 회사에 알립니다.

---

풀이

회사에는 다양한 AWS 리전의 여러 AWS 계정에 분산된 프로덕션 워크로드가 있습니다. 이 회사는 AWS Cost Explorer를 사용하여 비용과 사용량을 지속적으로 모니터링합니다. 회사는 워크로드의 비용 및 사용 지출이 비정상적일 때 알림을 받기를 원합니다.

 

정답 : B,E

 

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

---

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

• 다양한 AWS 리전의 여러 AWS 계정에 분산된 프로덕션 워크로드 모니터링
• 비용 및 사용량 지출이 비정상적일 때 능동적인 알림 수신
• 여러 계정에 걸친 통합 모니터링 필요

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

• AWS Cost Explorer: AWS 비용 및 사용량을 시각화하고 분석할 수 있는 도구입니다. 서비스 및 계정 전반에 걸쳐 비용을 모니터링하고 예측할 수 있습니다.
• AWS Cost Anomaly Detection: AWS 계정의 비용 및 사용량 패턴을 머신러닝으로 학습하고 이상 현상이 탐지되면 즉시 알림을 보내는 고급 기능입니다. AWS 계정 간에 비용과 사용량을 통합하여 모니터링하고 이상 현상을 자동으로 감지할 수 있습니다. 임계값 설정을 통해 민감도를 조절할 수 있으며, 구독 기능으로 이메일 또는 SNS를 통한 알림을 받을 수 있습니다.

3. 선택지 분석하기

A. 프로덕션 워크로드가 실행 중인 AWS 계정에서 AWS Cost Management 콘솔의 Cost Explorer를 사용하여 연결된 계정 예산을 생성합니다.

→ 예산은 사전 정의된 임계값을 초과할 때만 알림을 제공하므로, 비정상적인 사용량 패턴 변화를 감지하기 어렵습니다.

 

B. 프로덕션 워크로드가 실행 중인 AWS 계정에서 AWS Cost Management 콘솔의 AWS Cost Anomaly Detection을 사용하여 연결된 계정 모니터를 생성합니다.

→ 연결된 계정 모니터를 생성하여 모든 계정의 비용 및 사용량 이상 현상을 머신러닝으로 감지하고 능동적으로 알림을 받을 수 있습니다.

 

C. 프로덕션 워크로드가 실행 중인 AWS 계정에서 AWS 비용 관리 콘솔의 비용 이상 탐지를 사용하여 비용 및 사용 보고서를 생성합니다.

→ 비용 및 사용 보고서는 데이터를 저장하고 분석하기 위한 것으로, 능동적인 이상 현상 감지 및 알림 기능은 제공하지 않습니다.

 

D. 보고서를 작성하고 이메일 메시지를 보내 매주 회사에 알립니다.

→ 주간 이메일 요약은 사후 보고일 뿐 실시간 이상 현상 감지가 불가능하므로 요구사항을 충족하지 못합니다.

 

E. 필요한 임계값으로 구독을 생성하고 주간 요약을 사용하여 회사에 알립니다.

→ Cost Anomaly Detection의 구독 기능으로 임계값을 설정하고 이상 현상 발생 시 즉시 알림을 받을 수 있습니다.

---

 

이어서 다음 문제입니다.

---

문제2

회사에서 필요한 인프라를 수동으로 프로비저닝하여 새 웹 사이트의 인프라 프로토타입을 만들고 있습니다. 이 인프라에는 Auto Scaling 그룹, Application Load Balancer 및 Amazon RDS 데이터베이스가 포함됩니다. 구성이 철저히 검증된 후 회사는 자동화된 방식으로 두 가용 영역에서 개발 및 프로덕션 사용을 위한 인프라를 즉시 배포할 수 있는 기능을 원합니다.

이러한 요구 사항을 충족하기 위해 솔루션 설계자는 무엇을 권장해야 합니까?

 

선택지

A. AWS Systems Manager를 사용하여 두 가용 영역에서 프로토타입 인프라를 복제하고 프로비저닝합니다.

B. 프로토타입 인프라를 가이드로 사용하여 인프라를 템플릿으로 정의합니다. AWS CloudFormation으로 인프라를 배포하십시오.

C. AWS Config를 사용하여 프로토타입 인프라에서 사용되는 리소스 인벤토리를 기록합니다. AWS Config를 사용하여 프로토타입 인프라를 두 개의 가용 영역에 배포합니다.

D. AWS Elastic Beanstalk를 사용하고 프로토타입 인프라에 대한 자동 참조를 사용하도록 구성하여 2개의 가용 영역에 새 환경을 자동으로 배포합니다.

---

풀이

이 문제는 검증된 인프라 프로토타입을 Infrastructure as Code(IaC) 방식으로 자동화하여 개발 및 프로덕션 환경에 일관되게 배포하는 것이 핵심입니다. AWS CloudFormation은 인프라를 코드로 정의하고 반복 가능한 방식으로 배포할 수 있는 최적의 서비스입니다.

 

정답 : B

 

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

---

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

• 인프라 프로토타입 생성 및 검증 후 자동화된 방식으로 개발 및 프로덕션 인프라 배포
• Auto Scaling 그룹, ALB, RDS를 포함한 복잡한 인프라 구성
• 두 가용 영역에 배포
• 즉시 배포 가능한 자동화 솔루션 필요

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

• AWS CloudFormation: 인프라를 코드로 정의하고 자동화된 방식으로 프로비저닝하는 서비스입니다. YAML 또는 JSON 형식의 템플릿 파일을 사용하여 리소스를 선언적으로 정의할 수 있으며, 이를 통해 일관되고 반복 가능한 방식으로 인프라를 배포할 수 있습니다. 템플릿 파라미터를 통해 가용 영역, 인스턴스 타입, 환경(개발/프로덕션) 등을 동적으로 조정할 수 있습니다. 스택 개념을 통해 여러 리소스를 하나의 단위로 관리하고, 롤백 기능으로 배포 실패 시 안전하게 이전 상태로 복구할 수 있습니다. 한 번 정의된 템플릿으로 개발, 스테이징, 프로덕션 환경을 쉽게 생성 및 관리할 수 있습니다.

3. 선택지 분석하기

A. AWS Systems Manager를 사용하여 두 가용 영역에서 프로토타입 인프라를 복제하고 프로비저닝합니다.

→ Systems Manager는 운영 관리, 패치 관리, 자동화 실행을 목적으로 하므로 복잡한 인프라 프로비저닝에는 적합하지 않습니다.

 

B. 프로토타입 인프라를 가이드로 사용하여 인프라를 템플릿으로 정의합니다. AWS CloudFormation으로 인프라를 배포하십시오.

→ 프로토타입 인프라를 기반으로 CloudFormation 템플릿을 작성하면 자동화된 방식으로 개발, 프로덕션 환경을 두 가용 영역에 일관되고 반복 가능하게 배포할 수 있습니다.

 

C. AWS Config를 사용하여 프로토타입 인프라에서 사용되는 리소스 인벤토리를 기록합니다. AWS Config를 사용하여 프로토타입 인프라를 두 개의 가용 영역에 배포합니다.

→ AWS Config는 리소스 구성 변경 추적 및 컴플라이언스 검사를 위한 서비스로, 인프라 프로비저닝 기능은 제공하지 않습니다.

 

D. AWS Elastic Beanstalk를 사용하고 프로토타입 인프라에 대한 자동 참조를 사용하도록 구성하여 2개의 가용 영역에 새 환경을 자동으로 배포합니다.

→ Elastic Beanstalk는 웹 애플리케이션 배포에 특화된 PaaS 서비스로, 요구사항인 Auto Scaling, ALB, RDS를 포함한 다양한 리소스의 세밀한 제어와 배포에는 제한적입니다.

 

---

 

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

---

문제3

미디어 회사는 온프레미스에서 사용자 활동 데이터를 수집하고 분석합니다. 회사는 이 기능을 AWS로 마이그레이션하려고 합니다. 사용자 활동 데이터 저장소는 계속해서 성장하여 크기가 페타바이트가 될 것입니다. 회사는 SQL을 사용하여 기존 데이터 및 새 데이터의 온디맨드 분석을 용이하게 하는 고가용성 데이터 수집 솔루션을 구축해야 합니다.

최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

선택지

A. 활동 데이터를 Amazon Kinesis 데이터 스트림으로 보냅니다. 데이터를 Amazon S3 버킷으로 전달하도록 스트림을 구성합니다.

B. 활동 데이터를 Amazon Kinesis Data Firehose 전송 스트림으로 보냅니다. 데이터를 Amazon Redshift 클러스터로 전달하도록 스트림을 구성합니다.

C. 활동 데이터를 Amazon S3 버킷에 배치합니다. 데이터가 S3 버킷에 도착하면 데이터에서 AWS Lambda 함수를 실행하도록 Amazon S3를 구성합니다.

D. 여러 가용 영역에 분산된 Amazon EC2 인스턴스에서 수집 서비스를 생성합니다. 데이터를 Amazon RDS 다중 AZ 데이터베이스로 전달하도록 서비스를 구성합니다.

---

풀이

이 문제는 페타바이트 규모의 스트리밍 데이터를 수집하고 SQL 기반 분석을 지원하는 고가용성 솔루션을 최소 운영 오버헤드로 구축하는 것이 핵심입니다. Kinesis Data Firehose와 Amazon Redshift를 결합하면 완전 관리형 데이터 수집 및 분석 파이프라인을 구축할 수 있습니다.

 

정답 : B

 

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

---

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

• 사용자 활동 데이터 수집 및 분석 기능을 AWS로 마이그레이션
• 페타바이트 규모의 데이터 저장소 처리
• SQL을 사용한 온디맨드 분석 지원
• 고가용성 및 최소 운영 오버헤드
• 실시간 또는 준실시간 데이터 수집 필요

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

• Amazon Kinesis Data Firehose: 대규모 스트리밍 데이터를 Amazon S3, Amazon Redshift, Amazon OpenSearch Service 등에 안전하게 전달하는 완전 관리형 서비스입니다. 실시간으로 데이터를 수집하고 자동으로 배치 처리하여 전송하므로 데이터 처리 지연이 최소화됩니다. 데이터 변환, 압축, 암호화 기능을 내장하고 있으며, 서버 프로비저닝이나 관리가 필요 없어 운영 오버헤드가 최소화됩니다. 자동 확장 기능으로 데이터 처리량 변화에 유연하게 대응합니다.
• Amazon Redshift: 클라우드 기반 페타바이트 규모 데이터 웨어하우스로, 대규모 데이터에 대한 고성능 분석을 지원합니다. 표준 SQL과 기존 BI 도구를 사용하여 데이터를 효율적으로 분석할 수 있습니다. 컬럼 기반 스토리지와 병렬 처리로 복잡한 쿼리도 빠르게 실행됩니다. 완전 관리형 서비스로 백업, 패치, 모니터링이 자동화되어 운영 부담이 줄어듭니다.

두 서비스를 결합하면 고가용성의 완전 관리형 데이터 수집 및 분석 솔루션을 구축할 수 있으며, 운영 오버헤드가 최소화됩니다.

3. 선택지 분석하기

A. 활동 데이터를 Amazon Kinesis 데이터 스트림으로 보냅니다. 데이터를 Amazon S3 버킷으로 전달하도록 스트림을 구성합니다.

→ Kinesis Data Streams는 실시간 스트리밍 처리에 적합하지만, S3만으로는 SQL 기반 온디맨드 분석이 어렵고 별도의 분석 솔루션(Athena 등)이 필요합니다. 또한 페타바이트 규모 데이터의 효율적인 쿼리 성능을 보장하기 어렵습니다.

 

B. 활동 데이터를 Amazon Kinesis Data Firehose 전송 스트림으로 보냅니다. 데이터를 Amazon Redshift 클러스터로 전달하도록 스트림을 구성합니다.

→ Kinesis Data Firehose로 데이터를 수집하고 Amazon Redshift로 직접 전달하면 SQL 기반 분석이 가능한 고가용성의 완전 관리형 솔루션을 구축할 수 있습니다. 페타바이트 규모의 데이터도 효율적으로 처리 가능합니다.

 

C. 활동 데이터를 Amazon S3 버킷에 배치합니다. 데이터가 S3 버킷에 도착하면 데이터에서 AWS Lambda 함수를 실행하도록 Amazon S3를 구성합니다.

→ Lambda 기반 처리는 커스텀 로직 구현으로 운영 오버헤드가 크며, SQL 기반 분석을 위한 별도 데이터 웨어하우스 솔루션이 필요합니다. 페타바이트 규모 데이터 처리에는 적합하지 않습니다.

 

D. 여러 가용 영역에 분산된 Amazon EC2 인스턴스에서 수집 서비스를 생성합니다. 데이터를 Amazon RDS 다중 AZ 데이터베이스로 전달하도록 서비스를 구성합니다.

→ EC2 기반 커스텀 솔루션은 서버 관리, 확장, 모니터링 등 운영 오버헤드가 매우 크며, RDS는 페타바이트 규모의 분석 워크로드에 적합하지 않습니다.

---

첫 시작이 중요합니다! 꺾이지 않게 3문제씩 천천히 같이 도전해봐요! 다음 글에서 뵙겠습니다!