AWS SAA 합격으로 가는 길 #96

안녕하세요! 넥스트클라우드의 SA 손유림입니다. 😊 요즘 SAA 준비하시는 분들 정말 많더라고요. 도움이 되었으면 해요.

 

문제는 세 가지 단계를 거치며 풀어 나갈 거예요.

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

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

3. 선택지 분석하기

 

바로 문제 풀이 해볼까요?

---

문제1

회사는 AWS 클라우드에 수백 개의 Amazon EC2 Linux 기반 인스턴스를 보유하고 있습니다. 시스템 관리자는 공유 SSH 키를 사용하여 인스턴스를 관리했습니다. 최근 감사 후 회사의 보안 팀은 모든 공유 키를 제거하도록 지시하고 있습니다. 솔루션 설계자는 EC2 인스턴스에 대한 보안 액세스를 제공하는 솔루션을 설계해야 합니다. 최소한의 관리 오버헤드로 이 요구 사항을 충족하는 솔루션은 무엇입니까?

 

선택지

A. AWS Systems Manager Session Manager를 사용하여 EC2 인스턴스에 연결합니다.

B. AWS Security Token Service(AWS STS)를 사용하여 온디맨드 방식으로 일회성 SSH 키를 생성합니다.

C. 배스천 인스턴스 집합에 대한 공유 SSH 액세스를 허용합니다. 배스천 인스턴스에서 SSH 액세스만 허용하도록 다른 모든 인스턴스를 구성합니다.

D. Amazon Cognito 사용자 지정 권한 부여자를 사용하여 사용자를 인증합니다. AWS Lambda 함수를 호출하여 임시 SSH 키를 생성합니다.

---

풀이

AWS Systems Manager Session Manager는 SSH 키 없이 EC2 인스턴스에 안전하게 액세스할 수 있는 완전 관리형 솔루션입니다. 이는 공유 SSH 키에 대한 보안 위험을 제거하고 최소한의 관리 오버헤드로 인스턴스에 대한 보안 액세스를 제공합니다.

정답 : A

 

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

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

• 공유 SSH 키를 제거하고 보안 액세스 제공

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

AWS Systems Manager는 AWS 리소스를 보기, 제어 및 자동화하기 위한 통합 인터페이스를 제공하는 완전 관리형 서비스입니다. Session Manager는 Systems Manager의 기능으로, SSH 키 없이 EC2 인스턴스에 안전하게 액세스할 수 있게 해줍니다. Systems Manager는 단일 인터페이스를 통해 여러 AWS 서비스와 통합되므로 관리 편의성이 뛰어납니다. 따라서 공유 SSH 키 제거 및 최소한의 관리 오버헤드라는 요구 사항을 모두 충족할 수 있습니다.

3. 선택지 분석하기

A. AWS Systems Manager Session Manager를 사용하여 EC2 인스턴스에 연결합니다.

→ Session Manager는 SSH 키 없이 안전하게 EC2에 접근할 수 있으며, 중앙 관리 및 감사 로그 기능까지 제공하므로 공유 키 제거와 최소한의 운영 오버헤드 요구를 모두 충족합니다.

 

B. AWS Security Token Service(AWS STS)를 사용하여 온디맨드 방식으로 일회성 SSH 키를 생성합니다.

→ SSH 키를 사용해야 하므로 요구사항을 충족하지 못합니다.

 

C. 배스천 인스턴스 집합에 대한 공유 SSH 액세스를 허용합니다. 배스천 인스턴스에서만 SSH 액세스가 가능하도록 다른 모든 인스턴스를 구성합니다.

→ 공유 SSH 키가 필요하므로 요구사항을 충족하지 못합니다.

 

D. Amazon Cognito를 사용하여 사용자를 인증합니다. AWS Lambda 함수를 호출하여 임시 SSH 키를 생성합니다.

→ SSH 키를 사용해야 하므로 요구사항을 충족하지 못합니다.

 

이어서 다음 문제입니다.

---

문제2

회사에서 Amazon Elastic Container Service(Amazon ECS) 클러스터에 배포된 새 애플리케이션을 시작하고 ECS 작업에 Fargate 시작 유형을 사용하고 있습니다. 회사는 실행 시 애플리케이션에 대한 높은 트래픽이 예상되기 때문에 CPU 및 메모리 사용량을 모니터링하고 있습니다. 그러나 회사는 활용도가 감소할 때 비용을 절감하기를 원합니다. 솔루션 설계자는 무엇을 추천해야 합니까?

 

선택지

A. Amazon EC2 Auto Scaling을 사용하여 이전 트래픽 패턴을 기반으로 특정 기간에 조정합니다.

B. AWS Lambda 함수를 사용하여 Amazon CloudWatch 경보를 트리거하는 메트릭 위반을 기반으로 Amazon ECS를 확장합니다.

C. 간단한 조정 정책과 함께 Amazon EC2 Auto Scaling을 사용하여 ECS 메트릭 위반이 Amazon CloudWatch 경보를 트리거할 때 조정합니다.

D. 대상 추적 정책과 함께 AWS Application Auto Scaling을 사용하여 ECS 메트릭 위반이 Amazon CloudWatch 경보를 트리거할 때 조정합니다.

---

풀이

AWS Fargate는 서버리스 컴퓨팅 플랫폼으로 EC2 인스턴스 프로비저닝 없이 컨테이너 작업을 실행할 수 있습니다. Fargate 작업을 자동으로 조정하려면 AWS Application Auto Scaling을 사용해야 합니다. 대상 추적 정책을 설정하면 CloudWatch 메트릭 값이 목표값을 유지하도록 작업 수를 자동으로 조정합니다. 이를 통해 CPU 및 메모리 사용량을 적절한 수준으로 유지하고 비용을 최적화할 수 있습니다.

정답 : D

 

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

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

• ECS Fargate 작업에서 실행되는 애플리케이션
• CPU 및 메모리 사용량 모니터링 및 비용 절감 필요

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

AWS Application Auto Scaling은 다양한 AWS 서비스 리소스의 확장을 자동화할 수 있는 완전 관리형 서비스입니다. ECS 서비스 및 Fargate 작업에 대해 대상 추적 스케일링 정책을 설정할 수 있습니다. 이 정책은 지정한 CloudWatch 메트릭(CPU 사용량, 메모리 사용량 등)이 설정한 목표값을 유지하도록 작업 수를 자동으로 조정합니다. 이를 통해 리소스 활용도를 높이고 과도한 프로비저닝을 방지하여 비용 절감 효과를 얻을 수 있습니다. Application Auto Scaling은 관리 오버헤드가 매우 작은 완전 관리형 서비스입니다.

3. 선택지 분석하기

A. Amazon EC2 Auto Scaling을 사용하여 이전 트래픽 패턴을 기반으로 특정 기간에 조정합니다.

→ Fargate는 EC2 인스턴스를 사용하지 않으므로 EC2 Auto Scaling을 적용할 수 없습니다.

 

B. AWS Lambda 함수를 사용하여 Amazon CloudWatch 경보를 트리거하는 메트릭 위반을 기반으로 Amazon ECS를 확장합니다.

→ Lambda 함수를 사용하여 수동으로 ECS 확장하는 것은 관리 오버헤드가 큽니다.

 

C. 간단한 조정 정책과 함께 Amazon EC2 Auto Scaling을 사용하여 ECS 메트릭 위반이 Amazon CloudWatch 경보를 트리거할 때 조정합니다.

→ Fargate에는 EC2 Auto Scaling을 사용할 수 없습니다.

 

D. 대상 추적 정책과 함께 AWS Application Auto Scaling을 사용하여 ECS 메트릭 위반이 Amazon CloudWatch 경보를 트리거할 때 조정합니다.

→ Fargate는 EC2 없이 컨테이너 단위로 확장되며, Application Auto Scaling을 통해 CPU·메모리 메트릭 기반으로 자동 확장/축소하여 성능과 비용을 효율적으로 관리할 수 있습니다.

 

마지막 문제 살펴볼게요.

---

문제3

회사에서 AWS에 웹 애플리케이션을 배포했습니다. 이 회사는 조정 요구 사항을 지원하기 위해 기본 DB 인스턴스와 5개의 읽기 전용 복제본을 사용하여 MySQL용 Amazon RDS에서 백 엔드 데이터베이스를 호스팅합니다. 읽기 전용 복제본은 기본 DB 인스턴스보다 1초 이상 뒤처져서는 안 됩니다. 데이터베이스는 정기적으로 예약된 저장 프로시저를 실행합니다. 웹 사이트의 트래픽이 증가함에 따라 복제본은 피크 로드 기간 동안 추가 지연을 경험합니다. 솔루션 설계자는 복제 지연을 최대한 줄여야 합니다. 솔루션 설계자는 애플리케이션 코드에 대한 변경을 최소화하고 지속적인 운영 오버헤드를 최소화해야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

선택지

A. 데이터베이스를 Amazon Aurora MySQL로 마이그레이션합니다. 읽기 전용 복제본을 Aurora 복제본으로 교체하고 Aurora Auto Scaling을 구성합니다. 저장 프로시저를 Aurora MySQL 기본 함수로 바꿉니다.

B. 데이터베이스 앞에 Redis 클러스터용 Amazon ElastiCache를 배포합니다. 응용 프로그램이 데이터베이스를 쿼리하기 전에 캐시를 확인하도록 응용 프로그램을 수정하십시오. 저장 프로시저를 AWS Lambda 함수로 바꿉니다.

C. 데이터베이스를 Amazon EC2 인스턴스에서 실행되는 MySQL 데이터베이스로 마이그레이션합니다. 모든 복제본 노드에 대해 컴퓨팅에 최적화된 대규모 EC2 인스턴스를 선택합니다. EC2 인스턴스에서 저장 프로시저를 유지합니다.

D. 데이터베이스를 Amazon DynamoDB로 마이그레이션합니다. 필요한 처리량을 지원하고 온디맨드 용량 확장을 구성하기 위해 많은 수의 RCU(읽기 용량 단위)를 프로비저닝합니다. 저장 프로시저를 DynamoDB 스트림으로 바꿉니다.

---

풀이

Amazon Aurora MySQL은 MySQL과 호환되는 클라우드 네이티브 관리형 데이터베이스 서비스입니다. Aurora는 내장된 복제 기능을 통해 읽기 전용 복제본을 빠르게 생성할 수 있고, Auto Scaling을 통해 읽기 워크로드에 맞게 자동으로 확장할 수 있습니다. 따라서 Aurora MySQL로 마이그레이션하면 복제 지연 문제를 해결하고 읽기 성능을 향상시킬 수 있습니다. 또한 애플리케이션 코드 변경이 거의 필요 없고 운영 오버헤드도 크게 줄어듭니다.

정답 : A  

 

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

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

• 웹 애플리케이션 트래픽 증가로 인한 데이터베이스 읽기 성능 문제
• 복제 지연 시간 최소화
• 애플리케이션 코드 변경 최소화 및 운영 오버헤드 최소화

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

Amazon Aurora는 AWS 클라우드 환경에 최적화된 클라우드 네이티브 관리형 데이터베이스 서비스입니다. Aurora는 MySQL 및 PostgreSQL과 호환되는 엔진을 제공하며, 기존 데이터베이스 엔진에 비해 훨씬 뛰어난 성능, 가용성, 내구성을 자랑합니다. Aurora는 데이터베이스 클러스터 아키텍처를 사용하며, 기본 인스턴스와 최대 15개의 읽기 전용 복제본으로 구성됩니다. 읽기 전용 복제본은 기본 인스턴스의 데이터 변경 내용을 거의 실시간으로 반영하므로 읽기 성능이 탁월합니다. 또한 Aurora Auto Scaling을 활성화하면 읽기 워크로드에 맞춰 읽기 전용 복제본의 개수를 자동으로 조정할 수 있습니다. Aurora는 완전 관리형 서비스이므로 운영 오버헤드가 매우 낮습니다.

3. 선택지 분석하기

A. 데이터베이스를 Amazon Aurora MySQL로 마이그레이션합니다. 읽기 전용 복제본을 Aurora 복제본으로 교체하고 Aurora Auto Scaling을 구성합니다. 저장 프로시저를 Aurora MySQL 기본 함수로 바꿉니다.

→ Aurora는 고성능 저지연 복제 기술을 제공하며, Auto Scaling으로 부하에 따라 복제본을 자동 조절할 수 있어 복제 지연 문제를 최소한의 코드 변경과 운영 오버헤드로 해결할 수 있습니다.

 

B. 데이터베이스 앞에 Redis 클러스터용 Amazon ElastiCache를 배포합니다. 응용 프로그램이 데이터베이스를 쿼리하기 전에 캐시를 확인하도록 응용 프로그램을 수정합니다. 저장 프로시저를 AWS Lambda 함수로 바꿉니다.

→ ElastiCache는 데이터베이스 자체의 성능을 개선하지 못하고, 애플리케이션 코드 변경이 필요합니다.

 

C. 데이터베이스를 Amazon EC2 인스턴스에서 실행되는 MySQL 데이터베이스로 마이그레이션합니다. 모든 복제본 노드에 대해 컴퓨팅에 최적화된 대규모 EC2 인스턴스를 선택합니다. EC2 인스턴스에서 저장 프로시저를 유지합니다.

→ 자체 관리형 MySQL로 마이그레이션하면 운영 오버헤드가 크고, 복제 지연 문제를 완전히 해결하기 어렵습니다.

 

D. 데이터베이스를 Amazon DynamoDB로 마이그레이션합니다. 필요한 처리량을 지원하고 온디맨드 용량 확장을 구성하기 위해 많은 수의 RCU(읽기 용량 단위)를 프로비저닝합니다. 저장 프로시저를 DynamoDB 스트림으로 바꿉니다.

→ DynamoDB로 마이그레이션하면 애플리케이션 코드를 대폭 수정해야 하고, 저장 프로시저 기능을 대체하기 어렵습니다.

 

여기까지 읽으셨다면 오늘 공부 정말 잘하신 거예요. 다음 글에서는 또 다른 문제로 찾아올게요.

감사합니다. 다음 글에서 만나요! 😊