AWS SAA 합격으로 가는 길 #67

안녕하세요! NxtCloud SA 백종훈입니다.

AWS 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를 생성합니다.

 

풀이

SSL/TLS 인증서를 Application Load Balancer와 함께 사용하면 SSL 처리 부하를 Amazon EC2 인스턴스에서 벗어날 수 있습니다. SSL 종료를 Load Balancer에서 처리하므로 웹 서버의 컴퓨팅 리소스 부하를 줄일 수 있습니다. ACM(AWS Certificate Manager)에서 제공하는 SSL/TLS 인증서를 Load Balancer의 HTTPS 리스너에 사용하면 편리하게 구성할 수 있습니다.

 

정답 : D

 

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

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

• SSL 인증서 관리 및 교체 필요 
• 웹 서버의 SSL 처리 부하로 인한 성능 문제 해결

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

• AWS Certificate Manager(ACM): 관리형 SSL/TLS 인증서를 손쉽게 프로비저닝, 관리, 배포할 수 있는 서비스입니다. ACM 인증서를 AWS 서비스와 통합하여 사용할 수 있습니다.
• Amazon CloudFront: 글로벌 콘텐츠 전송 네트워크(CDN) 서비스로, 웹 애플리케이션의 정적 및 동적 컨텐츠를 빠르고 안전하게 전송합니다. SSL/TLS 인증서를 통해 엔드 투 엔드 암호화를 지원하며, SSL 종료 기능을 제공합니다. CloudFront는 SSL 처리 부하를 대신 처리하여 웹 서버의 부하를 줄일 수 있습니다.
• Amazon EC2 Auto Scaling: Auto Scaling 그룹에 정의된 조건에 따라 EC2 인스턴스 수를 자동으로 조정합니다. 애플리케이션의 가용성을 유지하면서 리소스 최적화를 도와줍니다.
• Elastic Load Balancing: 여러 가용 영역에 트래픽을 자동으로 분산하여 애플리케이션의 내결함성과 가용성을 높입니다. Application Load Balancer는 HTTP/HTTPS 트래픽 로드 밸런싱을 지원하며, SSL 종료 기능을 제공합니다.

3. 선택지 분석하기

A. AWS Certificate Manager(ACM)를 사용하여 새 SSL 인증서를 생성합니다. 각 인스턴스에 ACM 인증서를 설치합니다.

→ 새 인증서를 프로비저닝하고 인스턴스에 직접 설치해도 SSL 처리 부하 문제를 해결할 수 없습니다.

 

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를 생성합니다.

→ SSL 종료를 EC2 인스턴스에서 Application Load Balancer로 이전함으로써 웹 서버의 컴퓨팅 부하를 크게 줄일 수 있습니다. ALB가 클라이언트와의 HTTPS 연결을 처리하고, 백엔드 EC2 인스턴스로는 암호화되지 않은 HTTP 트래픽을 전송할 수 있어 EC2 인스턴스의 CPU 사용률을 절감할 수 있습니다.

 

이어서 다음 문제입니다.

---

문제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 두 번째 기본 인스턴스를 생성합니다.

---

풀이

요구사항을 충족하는 가장 적절한 방법은 다른 AWS 리전에 필요한 인프라 요소를 미리 프로비저닝하고, Route 53을 사용하여 활성-수동 장애 조치를 구성하는 것입니다. 또한 Aurora 복제본을 사용하면 데이터 동기화와 빠른 복구가 가능합니다.

 

정답 : A

 

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

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

• 최대 30분의 다운타임과 일부 데이터 손실 허용 
• 정상 상태에서는 복구 인프라가 부하를 처리할 필요 없음

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

• Amazon Route 53: AWS 클라우드의 DNS 웹 서비스로, 다양한 라우팅 정책을 제공합니다. 활성-활성 및 활성-수동 장애 조치 라우팅 정책을 통해 재해 복구 솔루션을 구축할 수 있습니다.
• Amazon Aurora: MySQL 및 PostgreSQL과 호환되는 완전 관리형 관계형 데이터베이스 서비스입니다. 다중 AZ 배포, Aurora 복제본, 백업 및 복원 기능을 통해 높은 가용성과 내구성을 제공합니다. 데이터 복제를 위해 Aurora 복제본을 다른 AWS 리전에 생성할 수 있습니다.
• AWS Backup: AWS 서비스 리소스와 온프레미스 리소스의 데이터를 중앙에서 백업하고 복원할 수 있는 완전 관리형 백업 서비스입니다. 백업을 통해 재해 복구 솔루션을 구축할 수 있지만, 애플리케이션 배포와 데이터 복제에는 적합하지 않습니다.
• AWS Auto Scaling: EC2 인스턴스의 수를 자동으로 조정하여 애플리케이션의 가용성을 유지하고 비용을 최적화합니다. 재해 복구 솔루션에 활용할 수 있지만, 주요 기능은 아닙니다.

3. 선택지 분석하기

A. 필요한 인프라 요소가 있는 애플리케이션을 배치합니다. Amazon Route 53을 사용하여 활성-수동 장애 조치를 구성합니다. 두 번째 AWS 리전에서 Aurora 복제본을 생성합니다.

→ 이 방식은 요구사항을 완벽하게 충족합니다. 두 번째 리전에 필요한 인프라를 미리 구축하여 신속한 장애 조치가 가능하고, 활성-수동 구성으로 평상시에는 복구 인프라가 부하를 처리하지 않습니다. Aurora 복제본을 통해 데이터가 지속적으로 동기화되어 30분 내의 복구 시간과 최소한의 데이터 손실 요구사항을 만족합니다.

 

B. 두 번째 AWS 리전에서 애플리케이션의 축소된 배포를 호스팅합니다. Amazon Route 53을 사용하여 활성-활성 장애 조치를 구성합니다. 두 번째 리전에서 Aurora 복제본을 생성합니다.

→ 활성-활성 장애 조치를 사용하면 복구 인프라도 부하를 처리해야 하므로 요구사항에 맞지 않습니다.

 

C. 두 번째 AWS 리전에서 기본 인프라를 복제합니다. Amazon Route 53을 사용하여 활성-활성 장애 조치를 구성합니다. 최신 스냅샷에서 복원된 Aurora 데이터베이스를 생성합니다.

→ 스냅샷 복원으로 인해 일부 데이터 손실이 발생할 수 있으며, 활성-활성 구성은 요구사항에 맞지 않습니다.

 

D. AWS Backup으로 데이터를 백업합니다. 백업을 사용하여 두 번째 AWS 리전에 필요한 인프라를 생성합니다. Amazon Route 53을 사용하여 활성-수동 장애 조치를 구성합니다. 두 번째 리전에서 Aurora 두 번째 기본 인스턴스를 생성합니다.

→ 백업으로 인프라를 생성하는 것은 시간이 오래 걸리며, 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 수명 주기 정책을 사용하여 1개월 이상 된 로그를 S3 Glacier Deep Archive로 이동합니다.

 

 

풀이

Auto Scaling 그룹의 대상 추적 정책을 사용하여 EC2 인스턴스의 CPU 사용률을 40% 수준으로 유지하도록 동적으로 확장하는 것이 정답입니다. 대상 추적 정책은 지정된 메트릭 값을 자동으로 추적하고 조정하여 원하는 CPU 사용률을 유지할 수 있습니다.

 

정답 : B

 

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

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

• 로그 파일을 10년 동안 보관해야 함 (장기 보관 필요)
• 지난 달 로그에는 정기적으로 액세스함 (최근 데이터는 빠른 액세스 필요)
• 한 달이 지난 로그는 거의 액세스하지 않음 (오래된 데이터는 자주 액세스하지 않음)
• 매월 10TB 이상의 로그 생성 (대용량 데이터 처리 필요)
• 가장 비용 효율적인 옵션을 찾아야 함 (비용 최적화가 중요)

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

• Amazon S3: 객체 스토리지 서비스로 확장성, 데이터 가용성, 보안 및 성능을 제공
  • S3 스토리지 클래스: Standard, Intelligent-Tiering, Standard-IA, One Zone-IA, Glacier, Glacier Deep Archive 등
  • S3 수명 주기 정책: 객체를 서로 다른 스토리지 클래스로 자동 전환 가능
• Amazon S3 Glacier Deep Archive: 가장 저렴한 S3 스토리지 클래스로, 거의 액세스하지 않는 데이터의 장기 보관에 적합
  • 검색 시간이 12-48시간으로 길지만, 보관 비용이 매우 저렴
• Amazon CloudWatch Logs: 로그 데이터를 중앙에서 수집, 모니터링, 저장 및 액세스할 수 있는 서비스
  • 기본적으로 로그 보존 기간이 제한적이며, 장기 보관에는 비용 효율적이지 않을 수 있음
• AWS Backup: AWS 서비스 전반에 걸쳐 데이터 백업을 중앙에서 관리하고 자동화하는 서비스
  • 백업 및 복원 작업을 단순화하지만, 스토리지 계층화에는 최적화되어 있지 않음

3. 선택지 분석하기

A. Amazon S3에 로그를 저장합니다. AWS Backup을 사용하여 1개월 이상 된 로그를 S3 Glacier Deep Archive로 이동합니다.

→ AWS Backup은 S3 객체의 스토리지 클래스 변경을 관리하는 데 최적화되어 있지 않습니다. AWS Backup은 주로 EC2, RDS, DynamoDB 등의 백업을 관리하는 서비스로, S3 객체의 스토리지 클래스 전환에는 S3 수명 주기 정책이 더 적합합니다.

 

B. 로그를 Amazon S3에 저장합니다. S3 수명 주기 정책을 사용하여 1개월 이상 된 로그를 S3 Glacier Deep Archive로 이동합니다.

→ 이 접근 방식은 요구사항을 가장 효과적으로 충족합니다. S3는 대용량 데이터 저장에 적합하며, S3 수명 주기 정책을 통해 로그 파일이 1개월이 지나면 자동으로 가장 저렴한 스토리지 클래스인 Glacier Deep Archive로 이동할 수 있습니다. 최근 로그는 빠르게 접근 가능하고, 오래된 로그는 비용 효율적으로 저장됩니다.

 

C. Amazon CloudWatch Logs에 로그를 저장합니다. AWS Backup을 사용하여 1개월 이상 된 로그를 S3 Glacier Deep Archive로 이동합니다.

→ CloudWatch Logs는 로그 데이터의 모니터링 및 분석에 좋지만, 매월 10TB 이상의 로그를 장기간 저장하는 것은 비용 효율적이지 않습니다. 또한 AWS Backup은 CloudWatch Logs에서 Glacier Deep Archive로 직접 데이터를 이동하는 기능이 제한적입니다.

 

D. Amazon CloudWatch Logs에 로그를 저장합니다. Amazon S3 수명 주기 정책을 사용하여 1개월 이상 된 로그를 S3 Glacier Deep Archive로 이동합니다.

→ 이 방식은 개념적 오류가 있습니다. S3 수명 주기 정책은 S3 내에 있는 객체에만 적용됩니다. CloudWatch Logs에 저장된 로그를 S3 수명 주기 정책을 통해 직접 Glacier Deep Archive로 이동할 수 없습니다. 먼저 CloudWatch Logs에서 S3로 로그를 내보내야 하는 추가 단계가 필요합니다.

 

오늘 준비한 AWS SAA 핵심 문제들은 여기까지입니다. 여러분의 AWS 아키텍처 이해도가 한층 더 깊어졌기를 바랍니다.

"지식에 투자하는 것이 가장 높은 이자를 가져다준다." - 벤자민 프랭클린