본문 바로가기
AWS/SAA 준비

AWS SAA 합격으로 가는 길 #23

by Pacloud 2024. 10. 4.
반응형

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

 

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

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

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

3. 선택지 분석하기

 

문제1

전자상거래 회사는 주문 처리 작업을 완료하기 위해 여러 서버리스 기능과 AWS 서비스를 포함하는 분산 애플리케이션을 구축하고 있습니다. 이러한 작업에는 워크플로의 일부로 수동 승인이 필요합니다. 솔루션 설계자는 주문 처리 애플리케이션을 위한 아키텍처를 설계해야 합니다. 솔루션은 여러 AWS Lambda 기능을 반응형 서버리스 애플리케이션으로 결합할 수 있어야 합니 다. 솔루션은 또한 Amazon EC2 인스턴스, 컨테이너 또는 온프레미스 서버에서 실행되는 데이터 및 서비스를 오케스트레이션해야 합니다.

최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

선택지

A. AWS Step Functions를 사용하여 애플리케이션을 구축하십시오.

B. AWS Glue 작업에서 모든 애플리케이션 구성 요소를 통합합니다.

C. Amazon Simple Queue Service(Amazon SQS)를 사용하여 애플리케이션을 구축합니다.

D. AWS Lambda 함수와 Amazon EventBridge 이벤트를 사용하여 애플리케이션을 구축합니다.

풀이

AWS Step Functions는 서버리스 함수와 다양한 AWS 서비스를 시각적 워크플로로 쉽게 조정할 수 있게 해주며, 수동 승인 단계를 포함한 복잡한 프로세스를 관리하는 데 적합합니다. 또한 최소한의 운영 오버헤드로 Lambda 함수, EC2 인스턴스, 컨테이너 및 온프레미스 서버와의 통합을 지원합니다.

정답 : A

 

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

더보기

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

  • 여러 서버리스 기능과 AWS 서비스를 포함하는 분산 애플리케이션 구축
  • 워크플로의 일부로 수동 승인 필요
  • 여러 AWS Lambda 기능을 반응형 서버리스 애플리케이션으로 결합
  • EC2 인스턴스, 컨테이너, 온프레미스 서버에서 실행되는 데이터 및 서비스 오케스트레이션
  • 최소한의 운영 오버헤드

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

  • 여러 서버리스 기능과 AWS 서비스를 포함하는 분산 애플리케이션 구축
    • AWS Step Functions: 복잡한 워크플로를 시각적으로 설계하고 실행할 수 있는 서버리스 워크플로 서비스입니다. 여러 Lambda 함수와 AWS 서비스를 쉽게 통합하고 오케스트레이션할 수 있습니다.
    • AWS Lambda: 서버리스 컴퓨팅 서비스로, 개별 기능을 구현하고 이벤트에 반응하여 실행할 수 있습니다.
    • Amazon API Gateway: RESTful API를 생성, 게시, 유지 관리, 모니터링 및 보안할 수 있는 완전관리형 서비스로, 서버리스 애플리케이션의 프론트엔드 역할을 할 수 있습니다.
  • 워크플로의 일부로 수동 승인 필요
    • AWS Step Functions: 인간의 승인이 필요한 작업을 워크플로에 포함시킬 수 있습니다. 승인 대기 상태를 만들고, 외부 시스템이나 사용자 인터페이스를 통해 승인을 처리할 수 있습니다.
    • Amazon Simple Notification Service (SNS): 승인 요청을 담당자에게 이메일이나 SMS로 보내는 데 사용할 수 있습니다.
  • EC2 인스턴스, 컨테이너, 온프레미스 서버에서 실행되는 데이터 및 서비스 오케스트레이션
    • AWS Step Functions: EC2, ECS, 온프레미스 서버에서 실행되는 작업을 통합하고 오케스트레이션할 수 있습니다.
    • AWS Lambda: EC2 인스턴스나 온프레미스 서버와 통신하여 작업을 수행하거나 데이터를 처리할 수 있습니다.
    • Amazon EventBridge: 다양한 소스의 이벤트를 수집하고 적절한 서비스로 라우팅할 수 있습니다.
  • 최소한의 운영 오버헤드
    • AWS Step Functions: 서버리스 서비스로, 인프라 관리가 필요 없어 운영 오버헤드를 최소화할 수 있습니다.
    • AWS Lambda: 서버리스 컴퓨팅 서비스로, 서버 관리나 확장성 관리가 필요 없어 운영 부담을 줄일 수 있습니다.
    • Amazon CloudWatch: 애플리케이션 모니터링을 자동화하여 운영 오버헤드를 줄일 수 있습니다.

3. 선택지 분석하기

A. AWS Step Functions를 사용하여 애플리케이션을 구축하십시오.

→ 모든 요구사항을 충족합니다. 서버리스 기능을 결합하고, 수동 승인을 포함한 복잡한 워크플로를 관리하며, EC2, 컨테이너, 온프레미스 서버와의 통합을 지원합니다. 또한 서버리스 아키텍처로 운영 오버헤드를 최소화합니다.

 

B. AWS Glue 작업에서 모든 애플리케이션 구성 요소를 통합합니다.

→ AWS Glue는 ETL(추출, 변환, 로드) 작업에 특화된 서비스로, 복잡한 애플리케이션 로직과 워크플로 관리, 수동 승인 프로세스 구현에는 적합하지 않습니다.

 

C. Amazon Simple Queue Service(Amazon SQS)를 사용하여 애플리케이션을 구축합니다.

→ SQS는 메시지 큐잉에 유용하지만, 복잡한 워크플로 관리와 수동 승인 프로세스 구현, 다양한 서비스 오케스트레이션에는 제한적입니다. 추가적인 개발이 필요하여 운영 오버헤드가 증가할 수 있습니다.

 

D. AWS Lambda 함수와 Amazon EventBridge 이벤트를 사용하여 애플리케이션을 구축합니다.

→ 서버리스 아키텍처를 구현할 수 있지만, 복잡한 워크플로 관리와 수동 승인 프로세스 구현, 다양한 서비스 오케스트레이션에 추가적인 개발이 필요합니다. Step Functions에 비해 복잡한 프로세스 관리가 어려울 수 있습니다.

 

이어서 다음 문제입니다.

문제2

금융 회사는 AWS에서 웹 애플리케이션을 호스팅합니다. 이 애플리케이션은 Amazon API Gateway 지역 API 엔드포인트를 사용하여 사용자에게 현재 주가를 검색할 수 있는 기능을 제공 합니다. 회사의 보안 팀은 API 요청 수가 증가한 것을 발견했습니다. 보안 팀은 HTTP 플러드 공격이 애플리케이션을 오프라인 상태로 만들 수 있다고 우려하고 있습니다.

솔루션 설계자는 이러한 유형의 공격으로부터 애플리케이션을 보호하기 위한 솔루션을 설계해야 합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

선택지

A. 최대 TTL이 24시간인 API Gateway 지역 API 엔드포인트 앞에 Amazon CloudFront 배포를 생성합니다.

B. 속도 기반 규칙을 사용하여 리전 AWS WAF 웹 ACL을 생성합니다. 웹 ACL을 API Gateway 단계와 연결합니다.

C. Amazon CloudWatch 지표를 사용하여 개수 지표를 모니터링하고 미리 정의된 속도에 도달하면 보안 팀에 알립니다.

D. API Gateway 지역 API 엔드포인트 앞에 Lambda@Edge를 사용하여 Amazon CloudFront 배포를 생성합니다 . 사전 정의된 속도를 초과하는 IP 주소의 요청을 차단하는 AWS Lambda 함수를 생성합니다.

풀이

이 방법은 HTTP 플러드 공격을 효과적으로 방어할 수 있습니다. AWS WAF의 속도 기반 규칙은 특정 IP 주소로부터의 과도한 요청을 차단할 수 있으며, API Gateway와 직접 통합됩니다. 또한 관리형 서비스로 운영 오버헤드가 최소화됩니다.

 

정답 : B

 

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

더보기

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

  • AWS에서 호스팅되는 웹 애플리케이션 보호
  • Amazon API Gateway 지역 API 엔드포인트 사용
  • HTTP 플러드 공격으로부터 보호
  • 최소한의 운영 오버헤드로 솔루션 구현

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

  • HTTP 플러드 공격으로부터 보호
    • AWS WAF (Web Application Firewall): 웹 애플리케이션을 보호하는 방화벽 서비스로, HTTP 및 HTTPS 요청을 모니터링하고 악의적인 트래픽을 차단할 수 있습니다. 속도 기반 규칙을 설정하여 특정 IP 주소로부터의 과도한 요청을 차단할 수 있습니다.
    • Amazon CloudFront: CDN(Content Delivery Network) 서비스로, DDoS 공격으로부터 보호하는 기능을 제공합니다. AWS Shield와 통합되어 있어 추가적인 보안 계층을 제공합니다.
    • AWS Shield: DDoS 공격으로부터 AWS 리소스를 보호하는 관리형 서비스입니다.
  • 최소한의 운영 오버헤드
    • AWS WAF: 완전 관리형 서비스로, 규칙 설정 후 자동으로 트래픽을 필터링합니다.
    • Amazon CloudFront: 완전 관리형 CDN 서비스로, 설정 후 자동으로 콘텐츠를 캐싱하고 배포합니다.
    • Amazon CloudWatch: AWS 리소스와 애플리케이션을 실시간으로 모니터링하는 서비스로, 자동화된 알림을 설정할 수 있습니다.
  • API Gateway 지역 API 엔드포인트 보호
    • AWS WAF: API Gateway와 직접 통합되어 API 엔드포인트를 보호할 수 있습니다.
    • Amazon CloudFront: API Gateway 앞에 배치하여 추가적인 보안 계층을 제공할 수 있습니다.

3. 선택지 분석하기

A. 최대 TTL이 24시간인 API Gateway 지역 API 엔드포인트 앞에 Amazon CloudFront 배포를 생성합니다.

→ CloudFront는 DDoS 보호 기능을 제공하지만, HTTP 플러드 공격에 대한 세밀한 제어가 부족할 수 있습니다. TTL 설정은 캐싱에 관련된 것으로, 보안과는 직접적인 관련이 없습니다.

 

B. 속도 기반 규칙을 사용하여 리전 AWS WAF 웹 ACL을 생성합니다. 웹 ACL을 API Gateway 단계와 연결합니다.

→ 이 방법은 HTTP 플러드 공격을 효과적으로 방어할 수 있습니다. AWS WAF의 속도 기반 규칙은 특정 IP 주소로부터의 과도한 요청을 차단할 수 있으며, API Gateway와 직접 통합됩니다. 또한 관리형 서비스로 운영 오버헤드가 최소화됩니다.

 

C. Amazon CloudWatch 지표를 사용하여 개수 지표를 모니터링하고 미리 정의된 속도에 도달하면 보안 팀에 알립니다.

→ 이 방법은 모니터링과 알림은 제공하지만, 실제로 공격을 방어하지는 않습니다. 또한 수동 개입이 필요하므로 운영 오버헤드가 증가할 수 있습니다.

 

D. API Gateway 지역 API 엔드포인트 앞에 Lambda@Edge를 사용하여 Amazon CloudFront 배포를 생성합니다 . 사전 정의된 속도를 초과하는 IP 주소의 요청을 차단하는 AWS Lambda 함수를 생성합니다.

→ 이 방법은 효과적일 수 있지만, Lambda 함수를 직접 관리해야 하므로 운영 오버헤드가 증가할 수 있습니다. 또한 Lambda@Edge는 글로벌 서비스로, 지역 API 엔드포인트에 적용하기에는 과도할 수 있습니다.

 

 

마지막 문제 살펴볼게요.

문제3

회사는 특정 지불 ID에 대한 메시지가 전송된 순서대로 수신되어야 하는 지불 처리 시스템을 사용합니다. 그렇지 않으면 결제가 잘못 처리될 수 있습니다. 솔루션 설계자는 이 요구 사항을 충족하기 위해 어떤 조치를 취해야 합니까? (두 가지를 선택하세요.)

 

선택지

A. 결제 ID를 파티션 키로 사용하여 Amazon DynamoDB 테이블에 메시지를 씁니다.

B. 결제 ID를 파티션 키로 사용하여 Amazon Kinesis 데이터 스트림에 메시지를 씁니다.

C. 결제 ID를 키로 사용하여 Amazon ElastiCache for Memcached 클러스터에 메시지를 씁니다.

D. Amazon Simple Queue Service(Amazon SQS) 대기열에 메시지를 씁니다. 결제 ID를 사용하도록 메시지 속성을 설정합니다.

E. Amazon Simple Queue Service(Amazon SQS) FIFO 대기열에 메시지를 씁니다. 결제 ID를 사용할 메시지 그룹을 설정합니다.

 

 

풀이

AWS Step Functions를 사용하여 워크플로를 구축하고 Lambda 함수를 호출하는 방식(D)이 정답인 이유는 이 방법이 이벤트 기반 아키텍처를 구현하면서도 서버리스 개념을 완전히 활용하고, 복잡한 워크플로를 쉽게 관리할 수 있게 해주기 때문입니다. 또한 Step Functions의 관리형 특성으로 인해 운영 오버헤드를 최소화할 수 있어, 문제의 모든 요구사항을 가장 잘 충족시킵니다.

정답 : B,E

 

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

더보기

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

  • 지불 처리 시스템에서 메시지 순서 보장 필요
  • 특정 지불 ID에 대한 메시지가 전송된 순서대로 수신되어야 함
  • 잘못된 순서로 처리될 경우 결제 오류 발생 가능성

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

  • 메시지 순서 보장
    • Amazon SQS FIFO (First-In-First-Out) 대기열: 메시지의 순서를 엄격하게 보존하며, 메시지 그룹 ID를 사용하여 특정 그룹 내에서의 순서를 보장할 수 있습니다.
    • Amazon Kinesis Data Streams: 같은 파티션 키를 가진 데이터의 순서를 보장합니다.
  • 데이터 저장 및 처리
    • Amazon DynamoDB: NoSQL 데이터베이스로, 고성능의 확장 가능한 데이터 저장소입니다. 하지만 메시지 순서 보장을 자체적으로 제공하지는 않습니다.
    • Amazon ElastiCache for Memcached: 인메모리 캐시 서비스로, 빠른 읽기/쓰기 성능을 제공하지만 메시지 순서를 보장하지는 않습니다.

3. 선택지 분석하기

A. 결제 ID를 파티션 키로 사용하여 Amazon DynamoDB 테이블에 메시지를 씁니다.

→ DynamoDB는 메시지 순서를 자체적으로 보장하지 않습니다. 따라서 이 방법은 요구사항을 충족하지 않습니다.

 

B. 결제 ID를 파티션 키로 사용하여 Amazon Kinesis 데이터 스트림에 메시지를 씁니다.

→ Kinesis Data Streams는 같은 파티션 키(이 경우 결제 ID)를 가진 데이터의 순서를 보장합니다. 이 방법은 요구사항을 충족합니다.

 

C. 결제 ID를 키로 사용하여 Amazon ElastiCache for Memcached 클러스터에 메시지를 씁니다.

→ ElastiCache for Memcached는 메시지 순서를 보장하지 않습니다. 따라서 이 방법은 요구사항을 충족하지 않습니다.

 

D. Amazon Simple Queue Service(Amazon SQS) 대기열에 메시지를 씁니다. 결제 ID를 사용하도록 메시지 속성을 설정합니다.

→ 일반 SQS 대기열은 메시지 순서를 보장하지 않습니다. 따라서 이 방법은 요구사항을 충족하지 않습니다.

 

E. Amazon Simple Queue Service(Amazon SQS) FIFO 대기열에 메시지를 씁니다. 결제 ID를 사용할 메시지 그룹을 설정합니다.

→ SQS FIFO 대기열은 메시지의 순서를 엄격하게 보존하며, 메시지 그룹 ID(이 경우 결제 ID)를 사용하여 특정 그룹 내에서의 순서를 보장합니다. 이 방법은 요구사항을 충족합니다.

 

 

 

"배움은 우연히 얻어지는 것이 아니라 열정을 가지고 갈구하고 부지런히 노력해야 얻을 수 있는 것이다." - 에비 에셔, 미국 교육자

 

저작자표시

'AWS > SAA 준비' 카테고리의 다른 글

AWS SAA 합격으로 가는 길 #25  (0) 2024.10.11
AWS SAA 합격으로 가는 길 #24  (0) 2024.10.07
AWS SAA 합격으로 가는 길 #22  (0) 2024.09.30
AWS SAA 합격으로 가는 길 #21  (0) 2024.09.27
AWS SAA 합격으로 가는 길 #20  (1) 2024.09.23

관련글

티스토리툴바