[AWS] AWS Solutions Architect Associate (3)

Question #17

한 회사가 새로운 비즈니스 애플리케이션을 구현하고 있다.

이 애플리케이션은 두 개의 Amazon EC2 인스턴스에서 실행되고 문서 저장을 위해 Amazon S3 버킷을 사용한다.

EC2 인스턴스가 S3 버킷에 액세스하기 위해 어떠한 솔루션을 제공해야 하는가?

지문

1. S3 버킷에 대한 액세스를 허용하는 IAM 역할을 만듭니다. 역할을 EC2 인스턴스에 연결합니다.
2. S3 버킷에 대한 액세스를 허용하는 IAM 정책을 만듭니다. 정책을 EC2 인스턴스에 연결합니다.
3. S3 버킷에 대한 액세스를 허용하는 IAM 그룹을 만듭니다. 그룹을 EC2 인스턴스에 연결합니다.
4. S3 버킷에 대한 액세스를 허용하는 IAM 사용자를 만듭니다. 사용자 계정을 EC2 인스턴스에 연결합니다.

풀이

문제 풀이 접기/펼치기

1. IAM 역할은 EC2 인스턴스에 권한을 부여하는 가장 안전한 방법으로 액세스 키를 EC2 인스턴스에 저장할 필요가 없어 유출 위험이 없으며, 동일한 역할을 여러 EC2 인스턴스에 연결할 수 있기에 확정성이 좋다.
2. IAM 정책은 EC2 인스턴스에 직접 연결할 수 없으며, 정책은 역할/사용자/그룹애 연결해야 한다.
3. IAM 그룹은 사용자만 포함할 수 있으며, 그룹은 사용자 관리용으로 리소스 접근 제어용이 아니다.
4. 사용자 액세스 키를 EC2에 저장하는 것은 보안 위험이 크며, 키 유출 시 대응이 어렵고 주기적인 키 순환이 필요하기에 적합하지 않다.

Question #18

애플리케이션 개발팀은 큰 이미지를 더 작고 압축된 이미지로 변환하는 마이크로서비스를 설계하고 있다.

사용자가 웹 인터페이스를 통해 이미지를 업로드하면, 마이크로서비스는 이미지를 Amazon S3 버킷에 저장하du AWS Lambda 함수로 이미지를 처리하여 압축하고, 압축된 형태로 이미지를 다른 S3 버킷에 저장해야 한다.

솔루션 아키텍트는 내구성이 있고 stateless 구성 요소를 사용하여 이미지를 자동으로 처리하는 솔루션을 설계해야 한다.

해당 요구 사항을 충족하는 작업의 조합은 무엇인가? (두 가지 선택)

지문

1. Amazon Simple Queue Service(Amazon SQS) 대기열을 만듭니다. 이미지가 S3 버킷에 업로드되면 SQS 대기열에 알림을 보내도록 S3 버킷을 구성합니다.
2. Lambda 함수를 구성하여 Amazon Simple Queue Service(Amazon SQS) 대기열을 호출 소스로 사용합니다. SQS 메시지가 성공적으로 처리되면 대기열에서 메시지를 삭제합니다.
3. Lambda 함수를 구성하여 S3 버킷에서 새 업로드를 모니터링합니다. 업로드된 이미지가 감지되면 파일 이름을 메모리의 텍스트 파일에 쓰고 텍스트 파일을 사용하여 처리된 이미지를 추적합니다.
4. Amazon EC2 인스턴스를 시작하여 Amazon Simple Queue Service(Amazon SQS) 대기열을 모니터링합니다. 대기열에 항목이 추가되면 EC2 인스턴스의 텍스트 파일에 파일 이름을 기록하고 Lambda 함수를 호출합니다.
5. Amazon EventBridge(Amazon CloudWatch Events) 이벤트를 구성하여 S3 버킷을 모니터링합니다. 이미지가 업로드되면 Amazon Ample Notification Service(Amazon SNS) 토픽에 알림을 보내 추가 처리를 위해 애플리케이션 소유자의 이메일 주소를 입력합니다.

풀이

문제 풀이 접기/펼치기

1. S3 이벤트 알림을 SQS로 전송함으로써, Lambda 장애 시에도 메시지가 대기열에 보존되어< 내구성이 보장된다. (SQS는 메시지 최대 14일 보관)

   • Amazon S3 Event Notification

     • 객체 업로드 시 SQS/SNS/Lambda 등에 실시간 알림

   • Amazon SQS

     • 메시지 큐 서비스로 내구성 보장

     • Lambda와 직접 연동 가능 (이벤트 소스로 사용)

2. Lambda는 SQS 메시지를 소비한 후 즉시 삭제하므로, 상태를 유지하지 않아 Stateless 요구 사항에 적합하다.

   • AWS Lambda

     • Stateless tlfgod ghksrud

     • S3/SQS 등 다양한 트리거 지원

3. Lambda는 임시 스토리지만을 제공하며, 실행 환경이 재사용되더라도 메모리 내용은 보장되지 않고, 동시성 처리 시 여러 Lambda 인스턴스가 생성되면 파일 내용과 불일치가 발생할 수 있다. (Stateful, 메모리 내용 소멸에 따른 내구성 없음)
4. EC2는 상태 유지(Stateful)가 기본이므로, 인스턴스 장애 시 처리 상태 복구가 불가능하며, 텍스트 파일 사용 시 디스크 공간 관리, 백업 등 추가 오버헤드가 발생한다. (Stateful, 서버리스 X)
5. SNS 토픽이 이메일만 전송하면 자동화 흐름이 끊기며, 관리가자 수동으로 Lambda를 트리거해야 하므로 실시간 처리가 불가능하다.

다른 조합의 문제점

조합	결함
A(1) + C(3)	C의 메모리 파일로 Stateless 위반
A(1) + D(4)	D의 EC2로 서버리스 원칙 위반
B(2) + E(5)	E의 수동 개입 필요
C(3) + D(4)	상태 저장 + 서버 관리로 최악의 조합

Question #19

한 회사에 AWS에 배포된 3계층 웹 애플리케이션이 있다.

웹 서버는 VPC의 퍼블릭 서브넷에 배포되며, 애플리케이션 서버와 데이터베이스 서버는 동일한 VPC의 프라이빗 서브넷에 배포된다.

이 회사는 검사 VPC에 AWS Marketplace의 타사 가상 방화벽 어플라이언스를 배포했다.

이 어플라이언스는 IP 패킷을 허용할 수 있는 IP 인터페이스로 구성되어 있다.

솔루션 아키텍트는 트래픽이 웹 서버에 도달하기 전에 애플리케이션에 대한 모든 트래픽을 검사하기 위해 웹 애플리케이션을 어플라이언스와 통합해야 한다.

해당 요구 사항을 가장 적은 운영 오버헤드로 충족하는 것은 무엇인가?

지문

1. 패킷 검사를 위해 트래픽을 어플라이언스로 라우팅하기 위해 애플리케이션의 VPC의 공개 서브넷에 네트워크 로드 밸런서를 생성합니다.
2. 패킷 검사를 위해 트래픽을 어플라이언스로 라우팅하기 위해 애플리케이션 VPC의 공개 서브넷에 애플리케이션 부하 분산 장치를 생성합니다.
3. 검사 VPC에 트랜싯 게이트웨이를 배포하고, 트랜싯 게이트웨이를 통해 들어오는 패킷을 라우팅하기 위한 경로 테이블을 구성합니다.
4. 검사 VPC에 게이트웨이 로드 밸런서를 배포합니다. 게이트웨이 로드 밸런서 엔드포인트를 생성하여 들어오는 패킷을 수신하고 어플라이언스로 패킷을 전달합니다.

풀이

문제 풀이 접기/펼치기

GWLB

게이트웨이 로드 밸런서

NLB

네트워크 로드 밸런서

ALB

애플리케이션 로드 밸런서

TGW

Transit Gateway (트랜싯 게이트웨이)

1. NLB는 트래픽 미러링 기능이 없어 별도의 VPC Traffic Mirroring 설정이 필요하다.
2. ALB는 L7 계층에서만 작동하며, IP 패킷 검사가 불가능하다.
3. TGW는 교차 VPC 라우팅 전용으로, 단일 VPC 내부 트래픽 제어에는 과도한 서비스이다.

4. GWLB는 L4 계층에서 작동하며, 들어오는 트래픽을 자동으로 방화벽 어플라이언스로 전달하며 어플라이언스의 확장/축소를 자동으로 처리하여 최소의 운영 오버헤드 요구사항에 적합하다.

   • 게이트웨이 로드 밸런서

     • L4 계층에서 작동하며, 들어오는 트래픽을 자동으로 방화벽 어플라이언스로 전달

     • 완전관리형 서비스로, NLB/ALB와 달리 GWLB는 방화벽/IDS/IPS와 같은 타사 보안 어플라이언스와의 통합에 최적화되어 있음

     • 어플라이언스의 확장/축소를 자동으로 처리함

     • VPC 라우팅 테이블만 수정하면 되며, 복잡한 트래픽 미러링 설정이 필요 없음

Question #20

한 회사가 동일한 AWS 지역의 테스트 환경에 대량의 프로덕션 데이터를 복제하는 기능을 개선하고자 한다.

데이터는 Amazon Elastic Block Store(Amazon EBS) 볼륨의 Amazon EC2 인스턴스에 저장된다.

복제된 데이터에 대한 수정 사항은 프로덕션 환경에 영향을 미치지 않아야 하며, 이 데이터에 액세스하는 소프트웨어는 지속적으로 높은 I/O 성능¹이 필요하다.

솔루션 아키텍트는 프로덕션 데이터를 테스트 환경에 복제하는 데 필요한 시간을 최소화해야하는데, 이러한 요구 사항에 충족하는 것은?

지문

1. 프로덕션 EBS 볼륨의 EBS 스냅샷을 찍습니다. 테스트 환경에서 EC2 인스턴스 스토어 볼륨으로 스냅샷을 복원합니다.
2. EBS Multi-Attach 기능을 사용하도록 프로덕션 EBS 볼륨을 구성합니다. 프로덕션 EBS 볼륨의 EBS 스냅샷을 찍습니다. 프로덕션 EBS 볼륨을 테스트 환경의 EC2 인스턴스에 연결합니다.
3. 프로덕션 EBS 볼륨의 EBS 스냅샷을 찍습니다. 새 EBS 볼륨을 만들고 초기화합니다. 프로덕션 EBS 스냅샷에서 볼륨을 복원하기 전에 테스트 환경에서 새 EBS 볼륨을 EC2 인스턴스에 연결합니다.
4. 프로덕션 EBS 볼륨의 EBS 스냅샷을 찍습니다. EBS 스냅샷에서 EBS 빠른 스냅샷 복원 기능을 켭니다. 스냅샷을 새 EBS 볼륨으로 복원합니다. 테스트 환경에서 새 EBS 볼륨을 EC2 인스턴스에 연결합니다.

풀이

문제 풀이 접기/펼치기

1. EC2 인스턴스 스토어는 휘발성으로 인스턴스 종료 시 데이터가 소실되기 때문에 지속적인 I/O 성능 요구 사항에 맞지 않는다.
2. EBS Multi-Attach를 사용하여 동일 볼륨을 프로덕션/테스트 환경에 동시에 연결할 경우 데이터 오염 가능성이 생길수 있으며, 테스트 수정 사항이 프로덕션에 영향이 없어야 하기 때문에 적합하지 않다.
3. FSR(빠른 스냅샷 복원 기능)이 없을 시 첫 액세스 시 Lazy Loading이 발생할 수 있으며, 초기 I/O 성능이 FSR 대비 60% 낮다.

4. FSR을 활성화하여 스냅샷 복원 시간을 단축시키고 고성능 I/O를 보장하며, 새 EBS 볼륨에 데이터를 복제하므로 프로덕션에 영향을 미치지 않는다.

   • EBS FSR (빠른 스냅샷 복원)

     • 초고속 복원으로 모든 데이터 블록을 즉시 사용 가능함

     • 복원 직후 풀 성능을 제공하며 일반 스냅샷 대비 3배 빠른 첫 액세스가 가능

     • 스냅샷 당 활성화/비활성화 별도로 설정하는 유연한 관리가 가능함

     • gp3, io1, io2 볼륨을 지원하여 호환성이 좋음

참고 사이트

ExamTopics

AWS Documentation

---

1. Input / Output 성능 ↩︎