AWS SAA 합격으로 가는 길 #112

안녕하세요! 넥스트클라우드의 SA 백종훈입니다.☺️

 

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

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

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

3. 선택지 분석하기

 

바로 문제 풀이 해볼까요?

 

---

문제1

데이터 분석 회사에서 일괄 처리 시스템을 AWS로 마이그레이션하려고 합니다. 회사는 FTP를 통해 낮 동안 주기적으로 수천 개의 작은 데이터 파일을 받습니다. 온프레미스 일괄 작업은 밤새 데이터 파일을 처리합니다. 그러나 일괄 작업 실행을 완료하는 데 몇 시간이 걸립니다.

회사는 파일을 전송하는 FTP 클라이언트에 대한 최소한의 변경으로 수신 데이터 파일을 처리할 수 있는 AWS 솔루션을 원합니다. 솔루션은 파일이 성공적으로 처리된 수신 데이터 파일을 삭제해야 합니다. 각 파일을 처리하는 데 3~8분이 소요됩니다.

운영상 가장 효율적인 방식으로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

선택지

A. FTP 서버를 실행하는 Amazon EC2 인스턴스를 사용하여 수신 파일을 Amazon S3 Glacier Flexible Retrieval의 객체로 저장합니다. AWS Batch에서 작업 대기열을 구성합니다. Amazon EventBridge 규칙을 사용하여 S3 Glacier Flexible Retrieval에서 야간에 객체를 처리하는 작업을 호출합니다. 작업이 개체를 처리한 후 개체를 삭제합니다.

B. FTP 서버를 실행하는 Amazon EC2 인스턴스를 사용하여 수신 파일을 Amazon Elastic Block Store(Amazon EBS) 볼륨에 저장합니다. AWS Batch에서 작업 대기열을 구성합니다. Amazon EventBridge 규칙을 사용하여 야간에 EBS 볼륨에서 파일 프로세스를 호출합니다. 작업이 파일을 처리한 후 파일을 삭제합니다.

C. AWS Transfer Family를 사용하여 들어오는 파일을 Amazon Elastic Block Store(Amazon EBS) 볼륨에 저장할 FTP 서버를 생성합니다. AWS Batch에서 작업 대기열을 구성합니다. 각 파일이 도착하면 Amazon S3 이벤트 알림을 사용하여 AWS Batch에서 작업을 호출합니다. 작업이 파일을 처리한 후 파일을 삭제합니다.

D. AWS Transfer Family를 사용하여 Amazon S3 Standard에 수신 파일을 저장할 FTP 서버를 생성합니다. 파일을 처리하고 파일이 처리된 후 파일을 삭제하는 AWS Lambda 함수를 생성합니다. 파일이 도착하면 S3 이벤트 알림을 사용하여 람다 함수를 호출하십시오.

 

풀이

FTP 기반 배치 처리 시스템의 AWS 마이그레이션에서는 서버리스 아키텍처가 운영 효율성을 극대화합니다. AWS Transfer Family를 통해 기존 FTP 클라이언트와의 호환성을 유지하고, S3 이벤트 기반으로 Lambda 함수를 트리거하여 실시간 파일 처리를 구현하면 밤새 일괄 처리보다 훨씬 효율적인 시스템을 구축할 수 있습니다.

정답 : D

 

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

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

• FTP 기반 일괄 처리 시스템의 AWS 마이그레이션
• FTP 클라이언트의 최소한의 변경 요구
• 파일 처리 후 자동 삭제 필요
• 각 파일 처리 시간: 3~8분
• 운영 효율성 최대화

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

• AWS Transfer Family는 완전 관리형 파일 전송 서비스로 SFTP, FTPS, FTP 프로토콜을 지원하여 기존 클라이언트와의 호환성을 보장합니다. 별도의 FTP 서버 구축이나 관리가 불필요하므로 운영 오버헤드를 크게 줄일 수 있습니다. AWS Lambda는 3~8분 정도의 파일 처리 작업에 적합한 서버리스 컴퓨팅 서비스로, 15분의 최대 실행 시간 제한 내에서 충분히 처리 가능합니다. S3 이벤트 알림과 연동하면 파일 업로드 즉시 처리를 시작할 수 있어 기존의 밤새 일괄 처리 방식보다 훨씬 효율적입니다. 또한 Lambda는 사용한 만큼만 비용을 지불하므로 비용 효율성도 뛰어납니다. S3 Standard는 자주 액세스하는 데이터에 최적화되어 있어 실시간 파일 처리에 적합합니다.

3. 선택지 분석하기

A. FTP 서버를 실행하는 Amazon EC2 인스턴스를 사용하여 수신 파일을 Amazon S3 Glacier Flexible Retrieval의 객체로 저장합니다.

→ S3 Glacier는 장기 아카이브용 스토리지로 즉시 액세스가 불가능하며, 3~8분 내에 처리해야 하는 파일에는 부적합합니다.

B. FTP 서버를 실행하는 Amazon EC2 인스턴스를 사용하여 수신 파일을 Amazon EBS 볼륨에 저장합니다.

→ EC2와 EBS를 사용하는 방식은 서버 관리 오버헤드가 발생하며, 운영 효율성 측면에서 서버리스 솔루션보다 떨어집니다.

C. AWS Transfer Family를 사용하여 들어오는 파일을 Amazon EBS 볼륨에 저장할 FTP 서버를 생성합니다.

→ Transfer Family는 S3나 EFS를 백엔드로 사용하며, EBS 볼륨을 직접 지원하지 않습니다. 또한 논리적 오류도 있습니다.

D. AWS Transfer Family를 사용하여 Amazon S3 Standard에 수신 파일을 저장할 FTP 서버를 생성합니다.

→ 완전 서버리스 아키텍처로 운영 오버헤드가 최소화되며, 실시간 파일 처리를 통해 기존 일괄 처리보다 효율성이 크게 향상됩니다.

 

 

이어서 다음 문제입니다.

---

문제2

이미지 호스팅 회사는 객체를 Amazon S3 버킷에 저장합니다. 회사는 S3 버킷의 개체가 대중에게 우발적으로 노출되는 것을 방지하려고 합니다. 전체 AWS 계정의 모든 S3 객체는 비공개로 유지되어야 합니다.

이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

선택지

A. Amazon GuardDuty를 사용하여 S3 버킷 정책을 모니터링합니다. AWS Lambda 함수를 사용하여 객체를 공개하는 변경 사항을 수정하는 자동 수정 작업 규칙을 생성합니다.

B. AWS Trusted Advisor를 사용하여 공개적으로 액세스 가능한 S3 버킷을 찾습니다. 변경 사항이 감지되면 Trusted Advisor에서 이메일 알림을 구성합니다. 퍼블릭 액세스를 허용하는 경우 S3 버킷 정책을 수동으로 변경합니다.

C. AWS Resource Access Manager를 사용하여 공개적으로 액세스 가능한 S3 버킷을 찾습니다. 변경이 감지되면 Amazon Simple Notification Service(Amazon SNS)를 사용하여 AWS Lambda 함수를 호출합니다. 프로그래밍 방식으로 변경 사항을 수정하는 Lambda 함수를 배포합니다.

D. 계정 수준에서 S3 퍼블릭 액세스 차단 기능을 사용합니다. AWS Organizations를 사용하여 IAM 사용자가 설정을 변경하지 못하도록 하는 서비스 제어 정책(SCP)을 생성합니다. 계정에 SCP를 적용합니다.

 

풀이

S3 객체의 우발적인 퍼블릭 노출을 완전히 방지하려면 예방 중심의 접근법이 필요합니다. S3 퍼블릭 액세스 차단을 계정 레벨에서 활성화하고, AWS Organizations의 SCP를 통해 해당 설정을 변경할 수 없도록 강제하는 것이 가장 확실한 보안 전략입니다.

 

정답 : D

 

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

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

• S3 버킷 객체의 우발적인 퍼블릭 노출 완전 방지
• 전체 AWS 계정의 모든 S3 객체를 비공개로 유지
• 예방 중심의 확실한 보안 조치 필요

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

• Amazon S3 퍼블릭 액세스 차단은 S3 버킷과 객체에 대한 퍼블릭 액세스를 계정 또는 버킷 레벨에서 중앙집중식으로 관리할 수 있는 보안 기능입니다. 이 기능은 4가지 설정을 제공합니다: 새로운 ACL을 통한 퍼블릭 액세스 차단, 모든 ACL을 통한 퍼블릭 액세스 차단, 새로운 퍼블릭 버킷 정책 차단, 퍼블릭 및 교차 계정 액세스 차단입니다. AWS Organizations의 서비스 제어 정책(SCP)은 조직 내 계정이 수행할 수 있는 작업에 대한 중앙집중식 제어를 제공합니다. SCP는 거부 목록 방식으로 작동하여 특정 AWS 서비스나 작업을 차단할 수 있으며, 심지어 루트 사용자도 SCP에서 거부된 작업은 수행할 수 없습니다. 이 두 기능을 결합하면 S3 퍼블릭 액세스에 대한 철벽같은 방어막을 구축할 수 있습니다.

3. 선택지 분석하기

 

A. Amazon GuardDuty를 사용하여 S3 버킷 정책을 모니터링합니다.

→ GuardDuty는 위협 탐지 서비스로 사후 대응 방식이며, 퍼블릭 노출을 사전에 방지하지는 못합니다.

B. AWS Trusted Advisor를 사용하여 공개적으로 액세스 가능한 S3 버킷을 찾습니다.

→ Trusted Advisor는 모니터링과 알림만 제공하는 수동적 방식으로, 우발적 노출을 실시간으로 방지할 수 없습니다.

C. AWS Resource Access Manager를 사용하여 공개적으로 액세스 가능한 S3 버킷을 찾습니다.

→ RAM은 리소스 공유 관리 서비스로 퍼블릭 액세스 탐지와는 관련이 없으며, 사후 대응 방식입니다.

D. 계정 수준에서 S3 퍼블릭 액세스 차단 기능을 사용합니다.

→ 퍼블릭 액세스 차단으로 사전 방지하고, SCP로 설정 변경을 원천 봉쇄하여 가장 확실한 보안을 제공합니다.

 

마지막 문제 살펴볼게요.

---

문제3

한 회사에서 여러 프로덕션 애플리케이션을 호스팅합니다. 애플리케이션 중 하나는 여러 AWS 리전에서 Amazon EC2, AWS Lambda, Amazon RDS, Amazon Simple Notification Service(Amazon SNS) 및 Amazon Simple Queue Service(Amazon SQS)의 리소스로 구성됩니다. 모든 회사 리소스에는 "애플리케이션"이라는 태그 이름과 각 애플리케이션에 해당하는 값이 태그로 지정됩니다. 솔루션 설계자는 태그가 지정된 모든 구성 요소를 식별하기 위한 가장 빠른 솔루션을 제공해야 합니다.

어떤 솔루션이 이러한 요구 사항을 충족합니까?

 

선택지

A. AWS CloudTrail을 사용하여 애플리케이션 태그가 있는 리소스 목록을 생성합니다.

B. AWS CLI를 사용하여 모든 리전에서 각 서비스를 쿼리하여 태그가 지정된 구성 요소를 보고합니다.

C. Amazon CloudWatch Logs Insights에서 쿼리를 실행하여 애플리케이션 태그가 있는 구성 요소에 대해 보고합니다.

D. AWS Resource Groups Tag Editor로 쿼리를 실행하여 애플리케이션 태그를 사용하여 전역적으로 리소스에 대해 보고합니다.

 

풀이

다중 리전에 분산된 여러 AWS 서비스의 태그 기반 리소스 검색에는 AWS Resource Groups Tag Editor가 최적의 솔루션입니다. 이 도구는 전역적으로 모든 리전과 서비스를 대상으로 태그 기반 검색을 한 번에 수행할 수 있어, 수동으로 각 서비스와 리전을 개별 조회하는 것보다 훨씬 빠르고 효율적입니다.

 

정답 : D

 

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

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

• 다중 리전에 분산된 여러 AWS 서비스 리소스
• "애플리케이션" 태그로 분류된 모든 구성 요소 식별
• 가장 빠른 솔루션 필요
• EC2, Lambda, RDS, SNS, SQS 등 다양한 서비스 포함

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

• AWS Resource Groups Tag Editor는 태그 기반 리소스 관리를 위한 전문 도구로, AWS Management Console에서 제공됩니다. 이 도구의 핵심 장점은 전역적 검색 능력입니다. 모든 AWS 리전과 지원되는 모든 AWS 서비스를 대상으로 한 번의 쿼리로 태그 기반 리소스 검색이 가능합니다. 특정 태그 키와 값 조합으로 필터링할 수 있으며, 검색 결과는 서비스별, 리전별로 정리되어 표시됩니다. 또한 검색된 리소스에 대해 일괄적으로 태그를 추가하거나 수정할 수도 있어 리소스 관리 효율성을 크게 향상시킵니다. EC2, Lambda, RDS, SNS, SQS 등 문제에서 언급된 모든 서비스가 Tag Editor에서 지원됩니다.

3. 선택지 분석하기

A. AWS CloudTrail을 사용하여 애플리케이션 태그가 있는 리소스 목록을 생성합니다.

→ CloudTrail은 API 호출 로그를 제공하는 서비스로, 현재 존재하는 리소스의 태그 기반 검색에는 적합하지 않습니다.

B. AWS CLI를 사용하여 모든 리전에서 각 서비스를 쿼리하여 태그가 지정된 구성 요소를 보고합니다.

→ 수동으로 각 리전과 서비스를 개별 조회하는 방식은 시간이 오래 걸리고 복잡하며, 실수 가능성도 높습니다.

C. Amazon CloudWatch Logs Insights에서 쿼리를 실행하여 애플리케이션 태그가 있는 구성 요소에 대해 보고합니다.

→ CloudWatch Logs Insights는 로그 데이터 분석 도구로, 리소스 태그 정보 검색과는 관련이 없습니다.

D. AWS Resource Groups Tag Editor로 쿼리를 실행하여 애플리케이션 태그를 사용하여 전역적으로 리소스에 대해 보고합니다.

→ Tag Editor는 태그 기반 리소스 검색에 특화된 도구로, 전역적 검색을 통해 가장 빠르고 정확한 결과를 제공합니다.

 

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