AWS SAA 합격으로 가는 길 #202

안녕하세요! 넥스트클라우드의 테크니컬 트레이너 김유림입니다. 🍂

 

9월의 첫 금요일입니다! 아침저녁으로 부는 바람이 제법 선선해져서 책상 앞에 앉아 있기 좋은 계절이 돌아왔습니다. 

새로운 달의 첫 주는 앞으로의 한 달을 어떻게 채울지 그려 보기에 참 좋은 시기이지요. 

 

오늘 문제는 한 주의 마지막을 가볍게 정리하는 마음으로 함께 살펴보시죠. 그럼 시작하겠습니다! 😊

 

 

문제는 세 가지 단계를 거치며 풀어가겠습니다.

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

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

3. 선택지 분석하기

 

바로 문제 풀이 시작합니다.

---

문제1

회사에서 AWS Organizations를 사용합니다. 멤버 계정이 Compute Savings Plan을 구입했습니다. 멤버 계정 내부의 워크로드 변경으로 인해 해당 계정은 더 이상 Compute Savings Plan 약정의 전체 혜택을 받지 못합니다. 이 회사는 구매한 컴퓨팅 성능의 50% 미만을 사용합니다.

 

 

선택지

A. Compute Savings Plan을 구매한 멤버 계정의 계정 콘솔에 있는 청구 기본 설정 섹션에서 할인 공유를 켭니다.
B. 회사의 조직 관리 계정에 있는 계정 콘솔의 청구 기본 설정 섹션에서 할인 공유를 켭니다.
C. 다른 AWS 계정에서 Compute Savings Plan이 있는 계정으로 추가 컴퓨팅 워크로드를 마이그레이션합니다.
D. 예약 인스턴스 마켓플레이스에서 초과된 Savings Plan 약정을 판매합니다.

---

풀이

한 계정이 구매한 약정을 조직의 다른 계정 사용량에도 적용하려면 할인 공유를 켜야 합니다. 이 설정은 결제를 총괄하는 관리 계정의 청구 기본 설정에서만 다룰 수 있으므로, 관리 계정에서 켜 주면 남는 약정이 조직 전체의 적격 사용량에 적용됩니다.

 

정답 : B

 

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

---

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

• 멤버 계정이 구매한 Compute Savings Plan의 미사용 약정 해소
• 약정 혜택을 조직 내 다른 계정으로 확대 적용
• 설정을 변경할 수 있는 올바른 계정 주체의 확인
• 워크로드 이전 없이 기존 약정을 그대로 활용

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

• AWS Organizations : 여러 개의 AWS 계정을 하나의 조직으로 묶어 중앙에서 관리하는 계정 관리 서비스입니다. 조직에는 결제와 정책을 총괄하는 관리 계정 하나와 그 아래에 속한 여러 멤버 계정이 있으며, 부서나 환경별로 계정을 나누어 두고도 운영은 한곳에서 할 수 있습니다. 조직을 만들면 통합 결제가 기본으로 적용되어 모든 멤버 계정의 사용 요금이 관리 계정으로 합산되어 청구됩니다.
  • 관리 계정과 멤버 계정 : 결제 설정과 조직 전체에 적용되는 정책은 관리 계정에서만 다룰 수 있고, 멤버 계정은 자신에게 허용된 범위 안에서만 자원을 사용합니다.
• Savings Plans : 1년 또는 3년 동안 시간당 일정 금액만큼 사용하겠다고 약속하면 그 대가로 온디맨드 요금보다 낮은 단가를 적용받는 요금 약정 모델입니다. 약정한 금액은 실제로 그만큼 사용했는지와 관계없이 매시간 청구되므로, 사용량이 약정보다 적으면 그 차액만큼 혜택을 누리지 못하게 됩니다. 약정은 기간 중간에 취소하거나 환불받을 수 없다는 점도 함께 알아 두어야 합니다. 그래서 매달 꾸준히 발생하는 최소 사용량을 기준으로 약정 규모를 잡는 것이 일반적입니다.
  • Compute Savings Plans : 인스턴스 종류나 크기, 리전, 운영체제, 테넌시를 가리지 않고 Amazon EC2(Elastic Compute Cloud), AWS Fargate, AWS Lambda 사용량에 폭넓게 적용되는 가장 유연한 유형입니다.
  • EC2 Instance Savings Plans : 특정 리전의 특정 인스턴스 패밀리로 범위를 좁히는 대신 할인율을 더 크게 가져가는 유형입니다.
• 통합 결제와 할인 공유 (Consolidated Billing and Discount Sharing) : 조직에 속한 계정들의 사용량을 관리 계정이 한데 모아 계산하는 청구 방식이며, 청구 기본 설정에서 예약 인스턴스와 Savings Plans의 할인 공유를 켜고 끌 수 있습니다. 공유를 켜 두면 어느 계정이 약정을 구매했든 그 혜택이 조직 안의 적격한 사용량에 자동으로 적용되어, 한 계정에서 남는 약정이 다른 계정의 사용량을 덮어 주게 됩니다. 이 설정은 결제를 총괄하는 관리 계정의 청구 기본 설정에서만 변경할 수 있으며, 계정별로 공유 대상에 포함할지 여부도 함께 지정할 수 있습니다.

3. 선택지 분석하기

A. Compute Savings Plan을 구매한 멤버 계정의 계정 콘솔에 있는 청구 기본 설정 섹션에서 할인 공유를 켭니다.
→ 할인 공유는 조직 전체의 결제에 영향을 주는 설정이라 멤버 계정의 콘솔에서는 변경할 수 없으므로, 요구를 충족하기 어렵습니다.

B. 회사의 조직 관리 계정에 있는 계정 콘솔의 청구 기본 설정 섹션에서 할인 공유를 켭니다.
→ 결제를 총괄하는 관리 계정에서 공유를 켜면 남는 약정이 조직 내 다른 계정의 사용량에 그대로 적용되므로, 가장 적절한 방법입니다.

C. 다른 AWS 계정에서 Compute Savings Plan이 있는 계정으로 추가 컴퓨팅 워크로드를 마이그레이션합니다.
→ 약정을 채울 수는 있지만 애플리케이션을 실제로 옮기는 작업이 따르기 때문에, 설정 하나로 해결되는 방식보다 효율적이지 않습니다.

D. 예약 인스턴스 마켓플레이스에서 초과된 Savings Plan 약정을 판매합니다.
→ 마켓플레이스에서 거래할 수 있는 대상은 예약 인스턴스이며 Savings Plans 약정은 되팔 수 없으므로, 적절치 않습니다.

---

 

이어서 다음 문제입니다.

---

문제2

회사에서 고객을 위한 검색 카탈로그를 제공할 마이크로서비스 애플리케이션을 개발하고 있습니다. 회사는 REST API를 사용하여 애플리케이션의 프런트엔드를 사용자에게 제시해야 합니다. REST API는 회사가 프라이빗 VPC 서브넷의 컨테이너에서 호스팅하는 백엔드 서비스에 액세스해야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

선택지

A. Amazon API Gateway를 사용하여 WebSocket API를 설계합니다. 프라이빗 서브넷의 Amazon Elastic Container Service(Amazon ECS)에서 애플리케이션을 호스팅합니다. Amazon ECS에 액세스하기 위해 API Gateway용 프라이빗 VPC 링크를 생성합니다.
B. Amazon API Gateway를 사용하여 REST API를 설계합니다. 프라이빗 서브넷의 Amazon Elastic Container Service(Amazon ECS)에서 애플리케이션을 호스팅합니다. Amazon ECS에 액세스하기 위해 API Gateway용 프라이빗 VPC 링크를 생성합니다.
C. Amazon API Gateway를 사용하여 WebSocket API를 설계합니다. 프라이빗 서브넷의 Amazon Elastic Container Service(Amazon ECS)에서 애플리케이션을 호스팅합니다. Amazon ECS에 액세스하기 위해 API Gateway에 대한 보안 그룹을 생성합니다.
D. Amazon API Gateway를 사용하여 REST API를 설계합니다. 프라이빗 서브넷의 Amazon Elastic Container Service(Amazon ECS)에서 애플리케이션을 호스팅합니다. Amazon ECS에 액세스하기 위해 API Gateway에 대한 보안 그룹을 생성합니다.

---

풀이

사용자에게 노출할 인터페이스는 REST API여야 하고, 백엔드는 프라이빗 서브넷 안에 머물러야 합니다. API Gateway에서 REST API를 만들고 VPC 링크로 연결하면 컨테이너를 인터넷에 내놓지 않고도 요청을 전달할 수 있습니다.

 

정답 : B

 

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

---

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

• 사용자에게 제공할 프런트엔드 인터페이스로 REST API 사용
• 프라이빗 VPC 서브넷의 컨테이너 백엔드에 대한 접근
• 백엔드를 인터넷에 노출하지 않는 연결 방식
• 마이크로서비스 구조에 맞는 관리형 API 계층 확보

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

• Amazon API Gateway : 애플리케이션의 API를 만들고 게시하고 관리해 주는 완전관리형 서비스입니다. 서버를 직접 세우지 않아도 외부에서 호출할 수 있는 엔드포인트를 만들어 주고, 인증과 권한 부여, 요청 속도 제한, 캐싱, 호출 기록 같은 기능을 API 앞단에서 한꺼번에 처리해 줍니다. 트래픽이 늘어나면 자동으로 확장되며 호출한 횟수만큼 요금이 부과되는 구조입니다. 들어온 요청을 어느 백엔드로 넘길지는 통합 설정으로 지정하며, 대상에 따라 여러 연결 방식 중에서 고를 수 있습니다.
  
  • REST API : 요청을 보내면 응답이 돌아오고 연결이 끝나는 방식으로, 자원을 조회하거나 등록하는 일반적인 웹 서비스 인터페이스에 널리 쓰입니다.
  • WebSocket API : 연결을 계속 열어 두고 서버와 클라이언트가 서로 먼저 말을 걸 수 있는 방식으로, 채팅이나 실시간 알림처럼 양방향 통신이 필요할 때 사용합니다.
• VPC 링크 (VPC Link) : API Gateway가 인터넷을 거치지 않고 VPC 안의 프라이빗 리소스로 요청을 전달할 수 있게 이어 주는 통합 방식입니다. REST API에서는 VPC 안에 놓인 Network Load Balancer를 가리키도록 VPC 링크를 만들어 두면, API Gateway가 받은 요청이 그 경로를 통해 프라이빗 서브넷 안쪽으로 흘러갑니다. 덕분에 백엔드에 공인 IP를 붙이거나 인터넷 게이트웨이를 열어 두지 않아도 되어, 노출 범위를 좁게 유지한 채 API를 제공할 수 있습니다.
• Amazon ECS (Elastic Container Service) : 컨테이너를 배포하고 실행하며 상태를 관리해 주는 완전관리형 컨테이너 오케스트레이션 서비스입니다. 어떤 이미지를 몇 개나 띄울지 정의해 두면 서비스가 알아서 배치하고, 문제가 생긴 컨테이너를 교체하며 수를 늘리고 줄여 줍니다. 컨테이너를 프라이빗 서브넷에 두면 외부에서 직접 접근할 수 없으므로, 앞단에 로드 밸런서를 두고 그 경로로만 요청을 받도록 구성하는 방식이 일반적입니다. 실행 환경으로는 EC2 인스턴스를 직접 관리하는 방법과 서버 관리가 필요 없는 AWS Fargate 중에서 고를 수 있습니다.
  
  • 보안 그룹 (Security Group) : VPC 안의 리소스에 붙여 인바운드와 아웃바운드 트래픽을 허용할지 결정하는 가상 방화벽입니다. EC2 인스턴스나 로드 밸런서, 컨테이너의 네트워크 인터페이스처럼 VPC 안에 자리 잡은 대상에 연결해 사용하며, 허용 규칙만 적을 수 있고 상태를 기억해 응답 트래픽은 자동으로 통과시킵니다. VPC 밖에서 동작하는 관리형 서비스에는 직접 붙일 수 없으므로, 그런 서비스가 VPC 안쪽에 접근해야 할 때는 별도의 연결 수단을 마련해야 합니다.

3. 선택지 분석하기

A. Amazon API Gateway를 사용하여 WebSocket API를 설계합니다. 프라이빗 서브넷의 Amazon Elastic Container Service(Amazon ECS)에서 애플리케이션을 호스팅합니다. Amazon ECS에 액세스하기 위해 API Gateway용 프라이빗 VPC 링크를 생성합니다.
→ 백엔드 연결 방식은 알맞지만 앞단을 WebSocket API로 두어 요구된 REST API 형태와 맞지 않으므로, 적절치 않습니다.

B. Amazon API Gateway를 사용하여 REST API를 설계합니다. 프라이빗 서브넷의 Amazon Elastic Container Service(Amazon ECS)에서 애플리케이션을 호스팅합니다. Amazon ECS에 액세스하기 위해 API Gateway용 프라이빗 VPC 링크를 생성합니다.
→ 요구된 REST API로 프런트엔드를 제공하면서 VPC 링크로 프라이빗 서브넷의 컨테이너까지 안전하게 이어 주므로, 가장 적절한 방법입니다.

C. Amazon API Gateway를 사용하여 WebSocket API를 설계합니다. 프라이빗 서브넷의 Amazon Elastic Container Service(Amazon ECS)에서 애플리케이션을 호스팅합니다. Amazon ECS에 액세스하기 위해 API Gateway에 대한 보안 그룹을 생성합니다.
→ API 유형이 요구와 다를 뿐 아니라 보안 그룹만으로는 VPC 밖의 API Gateway를 안쪽 컨테이너에 이어 줄 수 없으므로, 요구를 충족하기 어렵습니다.

D. Amazon API Gateway를 사용하여 REST API를 설계합니다. 프라이빗 서브넷의 Amazon Elastic Container Service(Amazon ECS)에서 애플리케이션을 호스팅합니다. Amazon ECS에 액세스하기 위해 API Gateway에 대한 보안 그룹을 생성합니다.
→ API 유형은 알맞지만 보안 그룹은 VPC 안의 리소스에 붙이는 방화벽이라 API Gateway에 연결해 경로를 만들 수는 없으므로, 적절치 않습니다.

---

 

마지막 문제 살펴보겠습니다.

---

문제3

전자상거래 회사는 온프레미스 웨어하우스 솔루션과 통합된 AWS 클라우드에서 애플리케이션을 실행합니다. 이 회사는 Amazon Simple Notification Service(Amazon SNS)를 사용하여 주문 메시지를 온프레미스 HTTPS 엔드포인트로 보내 창고 애플리케이션이 주문을 처리할 수 있도록 합니다. 로컬 데이터 센터 팀에서 일부 주문 메시지가 수신되지 않은 것을 감지했습니다. 솔루션 설계자는 전달되지 않은 메시지를 보관하고 최대 14일 동안 메시지를 분석해야 합니다.

최소한의 개발 노력으로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

선택지

A. 보존 기간이 14일인 Amazon Kinesis Data Stream 대상이 있는 Amazon SNS 배달 못한 편지 대기열을 구성합니다.
B. 애플리케이션과 Amazon SNS 사이에 보존 기간이 14일인 Amazon Simple Queue Service(Amazon SQS) 대기열을 추가합니다.
C. 보존 기간이 14일인 Amazon Simple Queue Service(Amazon SQS) 대상이 있는 Amazon SNS 데드 레터 대기열을 구성합니다.
D. 보존 기간이 14일로 설정된 TTL 속성이 있는 Amazon DynamoDB 대상이 있는 Amazon SNS 데드 레터 대기열을 구성합니다.

---

풀이

전달에 실패한 메시지만 따로 모아 두었다가 나중에 열어 볼 수 있어야 하고 개발 부담은 적어야 합니다. SNS의 배달 못한 편지 대기열은 SQS 대기열을 지정하는 설정만으로 구성되고, SQS의 보존 기간을 14일로 늘리면 요구를 그대로 만족합니다.

 

정답 : C

 

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

---

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

• 온프레미스 엔드포인트로 전달되지 못한 메시지의 보관
• 최대 14일 동안 메시지를 열어 보고 분석할 수 있는 환경
• 최소한의 개발 노력으로 구성 가능한 방식
• 기존 SNS 기반 전달 구조의 유지

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

• Amazon SNS (Simple Notification Service) : 보내는 쪽과 받는 쪽을 느슨하게 이어 주는 게시-구독 방식의 완전관리형 메시징 서비스입니다. 발행자가 주제(Topic)에 메시지를 한 번 올리면 그 주제를 구독한 모든 대상에게 같은 메시지가 동시에 전달되며, 구독 대상으로는 HTTP와 HTTPS 엔드포인트, Amazon SQS 대기열, AWS Lambda 함수, 이메일, 문자 메시지 등을 지정할 수 있습니다. 전달에 실패하면 정해진 정책에 따라 여러 차례 재시도하고, 재시도를 모두 소진하면 그 메시지는 기본적으로 사라집니다.
  
  • 배달 못한 편지 대기열(Dead-Letter Queue) : 구독별로 지정해 두면 재시도 끝에 전달되지 못한 메시지를 버리지 않고 그 대기열에 담아 주는 기능이며, 대상으로 지정할 수 있는 것은 Amazon SQS 대기열입니다. 코드를 작성할 필요 없이 구독 설정에서 지정하는 것만으로 동작합니다.
• Amazon SQS (Simple Queue Service) : 메시지를 순서대로 쌓아 두었다가 받는 쪽이 가져갈 때까지 안전하게 보관해 주는 완전관리형 메시지 대기열 서비스입니다. 보내는 쪽과 받는 쪽이 동시에 켜져 있지 않아도 되기 때문에, 한쪽에 문제가 생겨도 메시지를 잃지 않고 나중에 처리할 수 있습니다. 메시지 보존 기간은 기본 4일이며 최소 1분에서 최대 14일까지 설정할 수 있고, 콘솔에서 대기열 안의 메시지를 직접 열어 내용을 확인하는 것도 가능합니다. 순서를 보장하지 않는 대신 처리량이 큰 표준 대기열과, 순서와 중복 제거를 보장하는 FIFO 대기열 중에서 고를 수 있습니다.
• Amazon Kinesis Data Streams : 클릭 기록이나 로그처럼 끊임없이 들어오는 데이터를 실시간으로 받아 여러 소비자가 함께 읽어 갈 수 있게 해 주는 스트리밍 데이터 서비스입니다. 데이터를 샤드 단위로 나누어 보관하며 기본 24시간에서 최대 365일까지 보존 기간을 늘릴 수 있습니다. 다만 데이터를 읽으려면 소비자 애플리케이션을 직접 만들어야 하므로, 단순히 실패한 메시지를 담아 두고 들여다보는 용도에는 준비할 것이 많은 편입니다.
• Amazon DynamoDB : 키를 기준으로 항목을 저장하고 조회하는 완전관리형 NoSQL 데이터베이스 서비스입니다. 규모가 커져도 일정한 응답 속도를 유지하며, TTL(Time to Live) 속성을 지정해 두면 정해진 시각이 지난 항목을 자동으로 지워 줍니다. 데이터를 넣으려면 애플리케이션이나 함수가 직접 쓰기를 수행해야 하므로, 다른 서비스가 실패한 메시지를 알아서 적재해 주는 방식과는 성격이 다릅니다.

3. 선택지 분석하기

A. 보존 기간이 14일인 Amazon Kinesis Data Stream 대상이 있는 Amazon SNS 배달 못한 편지 대기열을 구성합니다.
→ SNS의 배달 못한 편지 대기열 대상으로는 SQS 대기열만 지정할 수 있어 스트림을 바로 연결할 수 없으므로, 적절치 않습니다.

B. 애플리케이션과 Amazon SNS 사이에 보존 기간이 14일인 Amazon Simple Queue Service(Amazon SQS) 대기열을 추가합니다.
→ 메시지를 게시하기 전 구간에 대기열을 두는 구성이라 온프레미스 엔드포인트로 전달되지 못한 메시지를 따로 담아 두지는 못하므로, 요구를 충족하기 어렵습니다.

C. 보존 기간이 14일인 Amazon Simple Queue Service(Amazon SQS) 대상이 있는 Amazon SNS 데드 레터 대기열을 구성합니다.
→ 구독 설정만으로 실패한 메시지를 대기열에 모을 수 있고 보존 기간도 14일까지 늘릴 수 있어, 개발 노력을 가장 적게 들이면서 요구를 만족하는 가장 적절한 방법입니다.

D. 보존 기간이 14일로 설정된 TTL 속성이 있는 Amazon DynamoDB 대상이 있는 Amazon SNS 데드 레터 대기열을 구성합니다.
→ 배달 못한 편지 대기열의 대상으로 테이블을 지정할 수 없고 별도의 적재 로직을 만들어야 하므로, 최소한의 개발 노력이라는 조건과 맞지 않습니다.

---

 

오늘 문제들은 "설정 하나로 풀 수 있는 일을 굳이 만들지 말자"는 이야기로 이어져 있었습니다.

최소 운영이라는 점에서 이런 선택지는 늘 정답으로 많이 선택되니 실무에서도 꼭 잊지 말고 적용해보시면 좋을 것 같습니다.

 

9월의 첫 주말, 푹 쉬시고 다음 주에 다시 만나요! 😊