글의 출처 AWS SAA 합격으로 가는 길 #12
AWS SAA 합격으로 가는 길 #12
안녕하세요! 넥스트클라우드의 SA 백종훈입니다. 문제는 세 가지 단계를 거치며 풀어 나갈 거예요.1. 문제의 요구사항 분석하기2. 관련 AWS 서비스 생각하기3. 선택지 분석하기 바로 첫번째 문
pacloud.tistory.com
1. 문제의 요구사항 분석하기
2. 관련 AWS 서비스 생각하기
3. 선택지 분석하기
문제 1
회사에 산발적인 사용 패턴을 가진 웹 애플리케이션이 있습니다.
매달 초에는 사용량이 많고, 매주 초에는 보통 사용량이 있으며, 주중에는 예측할 수 없는 사용량이
있습니다. 이 애플리캐이션은 웹 서버와 데이터 센터 내에서 실행되는 MySQL 데이터베이스 서버로
구성됩니다. 이 회사는 애플리케이션을 AWS 클라우드로 이동하려고 하며 데이터베이스 수정이 필요
하지 않는 비용 효율적인 데이터베이스 플랫폼을 선택해야한다. 이러한 요구 사항을 충족하는 솔루
션은 무엇입니까?
선택지
A. Amazon DynamoDB
B. MySQL용 Amazon RDS
C. MySQL 호환 Amazon Serverless
D. Auto Scaling 그룹의 Aamzon EC2에 배포된 MySQL
정답
정답 : C
MySQL 호환 Amazon Aurora Serverless는 기존 MySQL 애플리케이션을 수정 없이 마이그레이션할
수 있으면 서도, 사용량에 따라 자동으로 확장 및 축소되는 특성을 가진다. 이는 산발적인 사용
패턴에 효과적으로 대응하며, 실제 사용량에 기반한 요금 체계로 비용 효율성도 제
단어 뜻
DynamoDB
빠르고 유연한 NoSQL 데이터베이스 서비스
Amazon RDS
관리가 쉬운 관계형 데이터베이스 서비스
Amazon Serverless
서버 관리 없이 애플리케이션을 실행할 수 있는 기술
Auto Scaling
트래픽에 따라 자동으로 서버 용량을 조절하는 서비스
EC2
클라우드에서 가상 서버를 생성하고 운영할 수 있는 서비스
문제의 요구사항 분석하기
1. 산발적인 사용 패턴에 대응할 수 있는 유연성
2. AWS 클라우드로 애플리케이션 이전
3. 비용 효율적인 데이터베이스 플랫폼 선택
4, 데이터베이스 수정이 필요하지 않음(기존 MySQL과 호환)
관련 AWS 서비스 생각하기
산발적인 사용 패턴에 대응할 수 있는 유연성
- Amazon Aurora Serverless : 자동으로 시작 및 종료되며 용량을 확장 또는 축소하는 온디맨드
자동 확장 구성이다. 예측할 수 없는 워크로드에 대응하여 자동으로 용량을 조정한다.
AWS 클라우트 애플리케이션 이전
- AWS Database Migration Service (DMS) : 기존 MySQL 데이터베이스를 Amazon Aurora Ser
verlss로 안전하고 효율적으로 마이그레이션할 수 있다. 마이그레이션 중 소스 데이터베이스를
계속 사용할 수 있어 다운타임을 최소화한다.
비용 효율적인 데이터베이스 플랫폼 선택
- Amazon Aurora Serverless : 실제 사용한 데이터베이스 용량에 대해서만 비용을 지불한다.
사용량이 적을 때는 비용이 절감되며, 필요할 때만 자동으로 확장되어 비용을 최적화한다.
데이터베이스 수정이 필요하지 않음(기존 MySQL과 호환)
- Amazon Aurora MySQL-Compatible Edition : MySQL과 완벽하게 호환되는 서버리스 데이터
베이스 옵션이다. 기존 MySQL 애플리케이션을 거의 또는 전혀 수정하지 않고 Aurora Serverle
ss로 마이그레이션할 수 있다.
선택지 분석하기
A. Amazon DynamoDB
-> MySQL과 호환되지 않아 애플리케이션 수정이 필요함
B. MySQL용 Amazon RDS
-> 자동 스케일링 기능이 제한적이고 항상 실행되어야 해서 비용 효율성이 낮음
C. MySQL 호환 Aamzon Aurora Serverless
-> MySQL 호환성, 자동 스케일링, 비용 효율성 모두 제공함
D. Auto Scaling 그룹의 Amazon EC2에 배포된 MySQL
-> 관리 부담이 크고 설정이 복잡하며 완전한 서버리스 솔루션이 아님
문제 2
회사는 여러 가용 영역에 걸쳐 Amazon EC2 Linux 인스턴스에서 애플리케이션을 실행합니다.
애플리케이션에는 고가용성 및 POSIX(Portable Operating System Interface)호환 스토리지 계층이
필요합니다.
스토리지 계층은 최대 데이터 내구성을 제공해야 하며, EC2 인스턴스 간에 공유 가능해야 합니다.
저장소 계층의 데이터는 처음 30일 동안 자주 액세스되고 그 이후에는 드물게 엑세스됩니다.
이러한 요구 사항을 가장 비용 효율적을 충족하는 솔루션은 무엇입니까?
선택지
A. Amazon S3 Standard 스토리지 클래스를 사용하십시오. S3 수명 주기 정책을 생성하여 자주
액세스하지 않는 데이터를 S3 Glacier로 이동합니다.
B. Amazon S3 Standard 스토리지 클래스를 사용합니다. S3 수명 주기 정책을 생성하여 자주 엑세스
하지 않는 데이터를 S3 Standard-Infrequent Access(S3 Standard-IA)로 이동합니다.
C.Amaozn Elastic File System(Amazon EFS) Standard 스토리지 클래스를 사용합니다. 자주 액세스
하지 않는 데이터를 EFS Standard-infrequent Access(EFS Standard-IA)로 이동하는 수명 주기 관리
정책을 만듭니다.
D. Amazon Elastic File System(Amazon EFS) One Zone 스토리지 클래스를 사용합니다. 자주 액세스
하지 않는 데이터를 EFS One Zone-Infrequent Access(EFS One Zone-IA)로 이동하는 수명 주기
관리 정책을 만듭니다.
정답
정답 : C
풀이
Amazon EFS Standard는 여러 가용 영역에 걸쳐 고가용성과 높은 내구성을 제공하며, POSIX 호환
파일 시스템으로 EC2 인스턴스 간 공유가 가능합니다. 30일 이후 자주 액세스하지 않는 데이터를
EFS Standard-IA로 이동하는 수명 주기 정책을 통해 비용 효율성도 확보할 수 있어, 주어진 요구
사항을 가장 잘 충족합니다.
문제의 요구사항 분석하기
1. 여러 가용 영역에 걸친 고가용성
2. POSIX 호환 스토리지 계층
3. 최대 데이터 내구성 제공
4. EC2 인스턴스 간 스토리지 공유 가능
5. 처음 30일은 자주 접근, 이후 드물게 접근하는 데이터 특성
6. 비용 효율적인 솔루션
관련 AWS 서비스 생각하기
여러 가용 영역에 걸친 고가용성 및 POSIX 호환 스토리지 계층
- Amazon Elastic File System (Amazon EFS) : 여러 가용 영역에 걸쳐 데이터를 자동으로 복제
하여 고가용성을 제공합니다. POSIX 호환 파일 시스템 인터페이스를 제공하여 Linux 기반
EC2 인스턴스에서 쉽게 사용할 수 있다.
최대 데이터 내구성 제공 및 EC2 인스턴스 간 스토리지 공유 가능
- Amazon EFS : 99.999999%의 내구성을 제공하며, 여러 EC2 인스턴스에서 동시에 마운트하여
데이터를 공유할 수 있다.
처음 30일은 자주 접근, 이후 드물게 접근하는 데이터 특성
- Amazon EFS 수명 주기 관리 : EFS Standard 스토리지 클래스와 EFS Standard-Infrequent
Access(EFS Standard-IA) 스토리지 클래스를 제공합니다. 수명 주기 정책을 설정하여 30일
이후 자주 접근하지 않는 파일을 자동으로 Standard-IA로 이동시킬 수 있다.
비용 효율적인 솔루션
- Amazon EFS 스토리지 클래스 : Standard 클래스는 자주 접근하는 데이터에, Standard-IA
클래스는 드물게 접근하는 데이터에 사용된다. 이를 통해 스토리지 비용을 최적화할 수 있다.
EC2 Linux 인스턴스에서 애플리케이션 실행
- Amazon EC2(Elastic Compute Cloud) : 여러 가용 영역에 걸쳐 Linux 인스턴스를 배포하여 애플리
케이션의 고가용성을 확보할 수 있다.
선택지 분석하기
A. Amazon S3 Standard 스토리지 클래스를 사용하십시오. S3 수명 주기 정책을 생성하여 자주
액세스하지 않는 데이터를 S3 Glacier로 이동합니다.
-> S3는 POSIX 호환이 아니며 EC2 인스턴스 간 직접 공유가 어렵다. Glacier는 접근 시간이 길어
"드물게 액세스"하는 데이터에도 부적합할 수 있다.
B. Amazon S3 Standard 스트리지 클래스를 사용합니다. S3 수명 주기 정책을 생성하여 자주 액세
스하지 않는 데이터를 S3 Standard-Infrequent Access(S3 Standard-IA)로 이동한다.
-> A와 마찬가지로 POSIX 호환 및 EC2 인스턴스 간 공유 요구사항을 충족하지 못한다. 다만 Stand
ard-IA는 Glacier보다접근성이 좋다.
C.Amazon Elestic File System(Amazon EFS) Standard 스토리지 클래스를 사용합니다. 자주 액세
스하지 않는 데이터를 EFS Standard-Infrequent Access(EFS Standard-IA)로 이동하는 수명 주기
관리 정책을 만듭니다.
-> POSIX 호환, 고가용성, 최대 데이터 내구성, EC2 인스턴스 간 공유 가능성, 비용 효율적인 스토
리지 관리 등 모든 요구사항을 충족합니다.
D. Amazon Elastic File System(Amazon EFS) One Zone 스토리지 클래스를 사용합니다. 자주
액세스하지 않는 데이터를 EFS One Zone-Infrequent Access(EFS One Zone-IA)로 이동하는
수명 주기 관리 정책을 만듭니다.
-> 단일 가용 영역 사용으로 고가용성과 최대 데이터 내구성 요구사항을 충족하지 못한다.
비용 효율적이지만 중요한 요구사항들을 만족시키지 못한다.
문제 3
솔루션 설계자는 소프트웨어 데모 환경을 위한 아키텍처를 설계하고 있습니다. 환경은 Application
Load Balancer(ALB) 뒤에 있는 Auto Scaling 그룹의 Amazon EC2 인스턴스에서 실행됩니다.
시스템은 근무 시간 동안 트래픽이 크게 증가하지만 주말에는 작동하지 않아도 됩니다.
수요에 맞게 시스템을 확장할 수 있도록 하기 위해 솔루션 설계자는 어떤 조치 조합을 취해야 합니까?
(두가지를 선택하세요)
선택지
A. AWS Auto Scaling을 사용하여 요청 속도에 따라 ALB 용량을 조정하십시오
B. AWS Auto Scaling 을 사용하여 VPC 인터넷 게이트웨이의 용량을 확장합니다.
C. 여러 AWS 지역에서 EC2 인스턴스를 시작하여 여러 지역에 로드를 분산합니다.
D. 대상 추적 조정 정책을 사용하여 인스턴스 CPU 사용률을 기반으로 Auto Scaling 그룹을 조정합니다.
E. 예약된 조정을 사용하여 Auto Scaling 그룹의 최소, 최대 및 원하는 용량을 주말동안 0으로 변경합니다
주의 시작 시 기본 값으로 되돌립니다.
정답
정답 : D,E
D는 CPU 사용률 기반의 대상 추적 조정 정책을 통해 근무 시간 중 트래픽 증가에 효과적으로 대응할
수 있게 해준다.
E는 주말에 시스템을 완전히 중지시켜 불필요한 비용을 절감할 수 있게 해준다.
이 두 옵션을 결합하면 평일의 변동하는 수요에 탄력적으로 대응하면서도 주말에는 비용을 최소화할
수 있어, 문제의 요구사항을 가장 잘 충족시킨다.
단어
Application Load Balancer(ALB)
웹 애플리케이션으로 돌아오는 트래픽을 여러 서버에 효율적으로 분산시키는 서비스
트래픽
네트워크나 웹 사이트를 통해 오가는 데이터의 양
VPC
클라우드 내에서 사용자가 정의하고 제어할 수 있는 가상의 독립된 네트워크 환경
문제의 요구사항 분석하기
1. 근무 시간 동안 트래픽 증가에 대응할 수 있는 확장성
2. 주말에는 시스템을 비활성화할 수 있는 유연성
3. Auto Scaling 그룹과 Application Load Balancer(ALB)를 활용한 아키텍처 설계
관련 AWS 서비스 생각하기
근무 시간 동안 트래픽 증가에 대응할 수 있는 확장성
- Amazon EC2 Auto Scaling : 트래픽 패턴에 따라 EC2 인스턴스의 수를 자동으로 조정합니다.
CPU 사용률이나 네트워크 트래픽과 같은 지표를 기반으로 인스턴스를 추가하거나 제거할 수 있다
주말에는 시스템을 비활성화할 수 있는 유연성
- Amazon EC2 Auto Scaling의 예약된 작업 : 특정 시간에 Auto Scaling 그룹의 크기를 조정하도록
예약할 수 있다. 이를 통해 주말에 인스턴스 수를 0으로 줄이고, 평일 시작 시 다시 증가시킬 수 있다.
Auto Scaling 그룹과 Application Load Balancer(ALB)를 활용한 아키텍처 설계
- Amazon EC2 Auto Scaling : Auto Scaling 그룹을 생성하여 EC2 인스턴스를 관리한다. 이는 애플리
케이션의 가용성을 유지하고 비용을 쵲거화하는 데 도움을 준다. - Application Load Balancer(ALB) : 들어오는 애플리케이션 트래픽을 여러 EC2 인스턴스로 분산시킵
니다. Auto Scaling 그룹과 통합되어 새로 추가된 인스턴스로 자동으로 트래픽을 라우팅합니다.
선택지 분석하기
A. AWS Auto Scaling을 사용하여 요청 속도에 따라 ALB 용량을 조정하십시오
- ALB는 자동으로 확장되므로 용량을 수동으로 조정할 필요가 없다.
B. AWS Auto Scaling을 사용하여 VPC 인터넷 게이트웨이의 용량을 확장합니다.
- VPC 인터넷 게이트웨이는 확장이 필요 없는 완전 관리형 서비스입닏.
C. 여러 AWS 지역에서 EC2 인스턴스를 시작하여 여러 지역에 로드를 분산합니다.
-> 여러 지역에 걸친 분산은 문제의 요구사항에 불필요한 복잡성만 증가시킨다.
D. 대상 추적 조정 정책을 사용하여 인스턴스 CPU 사용률을 기반으로 Auto Scaling 그룹을 조정합니다.
-> CPU 사용률 기반의 대상 추적 조정 정책은 근무 시간 동안의 트래픽 증가에 효과적으로 대응할 수 있다.
E. 예약된 조정을 사용하여 Auto Scaling 그룹의 최소, 최대 및 원하는 용량을 주말동안 0으로 변경합니다.
주의 시작 시 기본 값으로 되돌립니다.
-> 예약된 조정을 통해 주말에 시스템을 비활성화하고 평일에 다시 활성화할 수 있어 비용을 절감할 수
있습니다.
'AWS' 카테고리의 다른 글
| (SAA)합격 기원 14일 (0) | 2026.06.17 |
|---|---|
| (SAA)합격 기원 13일차 (0) | 2026.06.16 |
| (SAA) 합격 기원 11일차 (0) | 2026.06.11 |
| (SAA) 합격 기원 10일차 (0) | 2026.06.10 |
| (SAA) 합격 9일차 (0) | 2026.06.09 |