안녕하세요, 넥스트클라우드의 SA 백종훈입니다. 여러분! 벌써 개강을 앞두고 있네요. 개강 전 마지막 SAA 공부 포스팅을 준비했습니다.그럼 지금부터 SAA 핵심 내용을 함께 살펴볼까요?
문제는 세 가지 단계를 거치며 풀어 나갈 거예요.
1. 문제의 요구사항 분석하기
2. 관련 AWS 서비스 생각하기
3. 선택지 분석하기
바로 문제 풀이 해보겠습니다!
문제1
한 회사에 두 개의 Amazon EC2 인스턴스에서 호스팅되는 동적 웹 애플리케이션이 있습니다. 회사에는 SSL 종료를 수행하기 위해 각 인스턴스에 있는 자체 SSL 인증서가 있습니다. 최근 트래픽이 증가했으며 운영 팀은 SSL 암호화 및 암호 해독으로 인해 웹 서버의 컴퓨팅 용량이 최대 한도에 도달했다고 판단했습니다. 애플리케이션의 성능을 높이려면 솔루션 설계자가 무엇을 해야 합니까?
선택지
A. AWS Certificate Manager(ACM)를 사용하여 새 SSL 인증서를 생성합니다. 각 인스턴스에 ACM 인증서를 설치합니다.
B. Amazon S3 버킷 생성 SSL 인증서를 S3 버킷으로 마이그레이션합니다. SSL 종료를 위해 버킷을 참조하도록 EC2 인스턴스를 구성합니다.
C. 다른 EC2 인스턴스를 프록시 서버로 생성합니다. SSL 인증서를 새 인스턴스로 마이그레이션하고 기존 EC2 인스턴스에 직접 연결하도록 구성합니다.
D. SSL 인증서를 AWS Certificate Manager(ACM)로 가져옵니다. ACM의 SSL 인증서를 사용하는 HTTPS 리스너로 Application Load Balancer를 생성합니다.
풀이
Application Load Balancer와 AWS Certificate Manager(ACM)를 사용하는 것이 가장 적절한 솔루션입니다. Load Balancer는 SSL/TLS 종료 기능을 제공하여 백엔드 인스턴스의 암호화 부하를 줄여줍니다. ACM은 무료로 제공되는 SSL/TLS 인증서 서비스로, Load Balancer와 통합하여 손쉽게 HTTPS 리스너를 구성할 수 있습니다.
정답 : D
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 동적 웹 애플리케이션 호스팅
- 증가하는 트래픽으로 인한 웹 서버 과부하
- SSL 암호화/복호화 처리 부하로 인한 과부하
- 애플리케이션 성능 향상 필요
2. 관련 AWS 서비스 생각하기
- Application Load Balancer: 트래픽 부하 분산 및 SSL/TLS 종료 기능을 제공하는 관리형 로드 밸런서 서비스입니다. 백엔드 인스턴스의 암호화 부하를 줄여줍니다.
- AWS Certificate Manager(ACM): AWS가 제공하는 무료 SSL/TLS 인증서 서비스입니다. Load Balancer와 통합하여 손쉽게 HTTPS 리스너를 구성할 수 있습니다.
- AWS Auto Scaling: EC2 인스턴스 수를 자동으로 조정하여 애플리케이션의 가용성과 성능을 유지합니다.
3. 선택지 분석하기
A. AWS Certificate Manager(ACM)를 사용하여 새 SSL 인증서를 생성합니다. 각 인스턴스에 ACM 인증서를 설치합니다.
→ 새로운 ACM 인증서를 사용하더라도 SSL 처리 부하는 여전히 EC2 인스턴스에서 발생하므로 근본적인 해결책이 되지 못합니다.
B. Amazon S3 버킷 생성 SSL 인증서를 S3 버킷으로 마이그레이션합니다. SSL 종료를 위해 버킷을 참조하도록 EC2 인스턴스를 구성합니다.
→ S3 버킷은 SSL 종료 기능을 제공하지 않으므로 부적절한 해결책입니다.
C. 다른 EC2 인스턴스를 프록시 서버로 생성합니다. SSL 인증서를 새 인스턴스로 마이그레이션하고 기존 EC2 인스턴스에 직접 연결하도록 구성합니다.
→ 프록시 서버를 추가하더라도 SSL 처리 부하는 여전히 발생하므로 근본적인 해결책이 되지 못합니다. 또한 새로운 단일 실패 지점이 생기게 됩니다.
D. SSL 인증서를 AWS Certificate Manager(ACM)로 가져옵니다. ACM의 SSL 인증서를 사용하는 HTTPS 리스너로 Application Load Balancer를 생성합니다.
→ Load Balancer가 SSL/TLS 종료를 수행하여 백엔드 인스턴스의 부하를 줄여줍니다. ACM을 사용하면 SSL/TLS 인증서 관리를 간소화할 수 있습니다.
이어서 다음 문제입니다.
문제2
회사는 Application Load Balancer 뒤의 Amazon EC2 인스턴스에서 글로벌 웹 애플리케이션을 실행합니다. 애플리케이션은 Amazon Aurora에 데이터를 저장합니다. 회사는 재해 복 구 솔루션을 만들어야 하며 최대 30분의 다운타임과 잠재적인 데이터 손실을 허용할 수 있습니다. 솔루션은 기본 인프라가 정상일 때 부하를 처리할 필요가 없습니다. 솔루션 설계자는 이러한 요구 사항을 충족하기 위해 무엇을 해야 합니까?
선택지
A. 필요한 인프라 요소가 있는 애플리케이션을 배치합니다. Amazon Route 53을 사용하여 활성-수동 장애 조치를 구성합니다. 두 번째 AWS 리전에서 Aurora 복제본을 생성합니다.
B. 두 번째 AWS 리전에서 애플리케이션의 축소된 배포를 호스팅합니다. Amazon Route 53을 사용하여 활성-활성 장애 조치를 구성합니다. 두 번째 리전에서 Aurora 복제본을 생성합니 다.
C. 두 번째 AWS 리전에서 기본 인프라를 복제합니다. Amazon Route 53을 사용하여 활성-활성 장애 조치를 구성합니다. 최신 스냅샷에서 복원된 Aurora 데이터베이스를 생성합니다.
D. AWS Backup으로 데이터를 백업합니다. 백업을 사용하여 두 번째 AWS 리전에 필요한 인프라를 생성합니다. Amazon Route 53을 사용하여 활성-수동 장애 조치를 구성합니다. 두 번째 리전에서 Aurora 두 번째 기본 인스턴스를 생성합니다.
풀이
활성-수동 장애 조치 구성과 Aurora 복제본을 사용하는 솔루션이 가장 적절합니다. Route 53을 통해 기본 리전과 DR 리전 간의 장애 조치를 구성하고, Aurora 복제본을 사용하여 데이터 복제를 수행합니다. 이를 통해 정상 시에는 리소스 사용을 최소화하면서도 재해 발생 시 신속한 복구가 가능합니다.
정답 : A
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 글로벌 웹 애플리케이션 및 Aurora 데이터베이스 사용
- 재해 복구 솔루션 구축
- 최대 30분 다운타임 및 일부 데이터 손실 허용
- 정상 시에는 부하 처리 불필요
2. 관련 AWS 서비스 생각하기
- Amazon Route 53: DNS 웹 서비스로, 장애 조치 라우팅 정책을 사용하여 활성-활성 또는 활성-수동 장애 조치를 구현할 수 있습니다.
- Amazon Aurora: 완전 관리형 MySQL 및 PostgreSQL 호환 관계형 데이터베이스 서비스로, 데이터 복제 기능을 제공합니다.
- AWS Auto Scaling: EC2 인스턴스 수를 자동으로 조정하여 애플리케이션의 가용성과 성능을 유지합니다.
3. 선택지 분석하기
A. 필요한 인프라 요소가 있는 애플리케이션을 배치합니다. Amazon Route 53을 사용하여 활성-수동 장애 조치를 구성합니다. 두 번째 AWS 리전에서 Aurora 복제본을 생성합니다.
→ 요구사항을 모두 충족하는 솔루션입니다. 정상 시에는 기본 리전에서 작동하며, 재해 발생 시 Route 53을 통해 DR 리전으로 장애 조치하고 Aurora 복제본을 사용하여 신속하게 복구할 수 있습니다.
B. 두 번째 AWS 리전에서 애플리케이션의 축소된 배포를 호스팅합니다. Amazon Route 53을 사용하여 활성-활성 장애 조치를 구성합니다. 두 번째 리전에서 Aurora 복제본을 생성합니다.
→ 활성-활성 구성은 정상 시에도 두 번째 리전의 리소스를 유지해야 하므로 요구사항에 부합하지 않습니다.
C. 두 번째 AWS 리전에서 기본 인프라를 복제합니다. Amazon Route 53을 사용하여 활성-활성 장애 조치를 구성합니다. 최신 스냅샷에서 복원된 Aurora 데이터베이스를 생성합니다.
→ 활성-활성 구성은 정상 시에도 두 번째 리전의 리소스를 유지해야 하므로 요구사항에 부합하지 않습니다. 또한 Aurora 스냅샷 복원은 복제본보다 RPO가 높아 잠재적인 데이터 손실이 더 클 수 있습니다.
D. AWS Backup으로 데이터를 백업합니다. 백업을 사용하여 두 번째 AWS 리전에 필요한 인프라를 생성합니다. Amazon Route 53을 사용하여 활성-수동 장애 조치를 구성합니다. 두 번째 리전에서 Aurora 두 번째 기본 인스턴스를 생성합니다.
→ Backup을 사용하여 DR 리전에 인프라를 생성하는 것은 복잡하고 시간이 오래 걸릴 수 있습니다. 또한 Aurora 복제본 대신 두 번째 기본 인스턴스를 사용하면 데이터 복제가 이루어지지 않아 잠재적인 데이터 손실이 더 클 수 있습니다.
마지막 문제 살펴볼게요.
문제3
회사는 중요한 애플리케이션에 대한 애플리케이션 로그 파일을 10년 동안 보관해야 합니다. 애플리케이션 팀은 문제 해결을 위해 지난 달의 로그에 정기적으로 액세스하지만 한 달이 지난 로그 는 거의 액세스하지 않습니다. 애플리케이션은 매월 10TB 이상의 로그를 생성합니다. 이러한 요구 사항을 가장 비용 효율적으로 충족하는 스토리지 옵션은 무엇입니까?
선택지
A. Amazon S3에 로그를 저장합니다. AWS Backup을 사용하여 1개월 이상 된 로그를 S3 Glacier Deep Archive로 이동합니다.
B. 로그를 Amazon S3에 저장합니다. S3 수명 주기 정책을 사용하여 1개월 이상 된 로그를 S3 Glacier Deep Archive로 이동합니다.
C. Amazon CloudWatch Logs에 로그를 저장합니다. AWS Backup을 사용하여 1개월 이상 된 로그를 S3 Glacier Deep Archive로 이동합니다.
D. Amazon CloudWatch Logs에 로그를 저장합니다.
풀이
Amazon S3에 로그를 저장하고, S3 수명 주기 정책을 통해 1개월이 지난 로그를 S3 Glacier Deep Archive로 이동시키는 것이 가장 비용 효율적인 솔루션입니다. S3 Glacier Deep Archive는 장기 보관에 최적화된 초저렴한 스토리지로, 액세스 빈도가 낮은 오래된 로그 파일을 저장하기에 적합합니다.
정답 : B
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 애플리케이션 로그 파일 10년 보관 필요
- 최근 1개월 로그는 자주 액세스, 그 이후 로그는 거의 액세스하지 않음
- 매월 10TB 이상의 로그 생성
- 비용 효율성 극대화
2. 관련 AWS 서비스 생각하기
- Amazon S3: 높은 내구성과 가용성을 제공하는 객체 스토리지 서비스로, 대용량 로그 파일 저장에 적합합니다.
- Amazon S3 Glacier Deep Archive: 장기 보관에 최적화된 초저렴한 스토리지 클래스로, 액세스 빈도가 낮은 데이터를 비용 효율적으로 저장할 수 있습니다.
- Amazon CloudWatch Logs: AWS 리소스 및 애플리케이션 로그를 중앙에서 모니터링하고 저장할 수 있는 서비스로, 로그 데이터 수집에 적합합니다.
- AWS Backup: AWS 서비스 간 통합 백업 솔루션으로, 중앙 집중식 백업 및 복원 기능을 제공합니다. - S3 수명 주기 정책: 객체의 수명 주기에 따라 자동으로 스토리지 계층을 전환하거나 만료된 객체를 삭제할 수 있는 S3 기능입니다.
3. 선택지 분석하기
A. Amazon S3에 로그를 저장합니다. AWS Backup을 사용하여 1개월 이상 된 로그를 S3 Glacier Deep Archive로 이동합니다. → AWS Backup은 주기적인 백업 작업에 최적화되어 있으며, 오래된 로그를 S3 Glacier Deep Archive로 이동시키는 데는 S3 수명 주기 정책이 더 적합합니다.
B. 로그를 Amazon S3에 저장합니다. S3 수명 주기 정책을 사용하여 1개월 이상 된 로그를 S3 Glacier Deep Archive로 이동합니다.
→ 최근 1개월 로그는 S3에 저장되어 빠른 액세스가 가능하고, 그 이후의 로그는 S3 수명 주기 정책에 따라 자동으로 S3 Glacier Deep Archive로 이동하여 장기 보관 비용을 절감할 수 있습니다.
C. Amazon CloudWatch Logs에 로그를 저장합니다. AWS Backup을 사용하여 1개월 이상 된 로그를 S3 Glacier Deep Archive로 이동합니다.
→ CloudWatch Logs와 AWS Backup을 조합하는 것은 복잡하고 비효율적입니다. CloudWatch Logs에서 대량의 데이터(10TB/월)를 저장하는 것은 비용이 많이 들며, AWS Backup은 CloudWatch Logs에서 S3 Glacier Deep Archive로의 직접 이동을 최적으로 지원하지 않습니다.
D. Amazon CloudWatch Logs에 로그를 저장합니다.
→ CloudWatch Logs만 사용하는 것은 장기 보관(10년)과 대용량 데이터(매월 10TB 이상)에 비용 효율적이지 않습니다. CloudWatch Logs는 모니터링과 단기 로그 저장에는 좋지만, 장기 보관 시 S3 Glacier Deep Archive보다 훨씬 비싸며, 로그 보존 기간이 제한적입니다. 또한 오래된 로그에 대한 계층화 옵션이 없어 비용 최적화가 어렵습니다.
개강 후에도 틈틈이 복습하면 실력 향상에 큰 도움이 될 것입니다!!
'AWS > SAA 준비' 카테고리의 다른 글
| AWS SAA 합격으로 가는 길 #62 (0) | 2025.03.03 |
|---|---|
| AWS SAA 합격으로 가는 길 #60 (0) | 2025.02.24 |
| AWS SAA 합격으로 가는 길 #59 (1) | 2025.02.17 |
| AWS SAA 합격으로 가는 길 #58 (0) | 2025.02.14 |
| AWS SAA 합격으로 가는 길 #57 (0) | 2025.02.10 |