본문 바로가기
AWS/SAA 준비

AWS SAA 합격으로 가는 길 #164

by Pacloud 2026. 3. 13.
반응형

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

 

 

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

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

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

3. 선택지 분석하기

 

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

문제1

한 회사가 Application Load Balancer를 사용하여 3개 AWS 리전에 애플리케이션을 배포하고 있습니다. Amazon Route 53은 이러한 지역 간에 트래픽을 분산하는 데 사용됩니다.

솔루션 아키텍트는 MOST 고성능 경험을 제공하기 위해 어떤 Route 53 구성을 사용해야 합니까?

 

선택지

A. 대기 시간 정책이 포함된 A 레코드를 생성합니다.

B. 지리적 위치 정책을 사용하여 A 레코드를 만듭니다.

C. 장애 조치 정책을 사용하여 CNAME 레코드를 생성합니다.

D. 지리 근접 정책을 사용하여 CNAME 레코드를 생성합니다.

풀이

최고 성능 경험을 위해서는 사용자와 가장 가까운 리전으로 트래픽을 보내야 하며, 이를 위해 네트워크 지연 시간(latency)을 기준으로 라우팅하는 정책이 적합합니다. ALB는 IP 주소를 반환하므로 CNAME이 아닌 A 레코드를 사용해야 합니다.

 

정답 : A

 

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

더보기

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

  • 3개 리전에 ALB로 배포된 애플리케이션 간 Route 53 트래픽 분산
  • 가장 높은 성능(MOST 고성능) 경험 제공이 목표
  • 적절한 레코드 타입(A 또는 CNAME)과 라우팅 정책 선택

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

  • AWS Route 53 : AWS에서 제공하는 완전관리형 DNS(Domain Name System) 서비스로, 도메인 등록부터 DNS 쿼리 해석까지 모두 처리합니다. 총 7가지 라우팅 정책(단순, 가중치, 지연 시간, 장애 조치, 지리적 위치, 지리 근접, 다중값)을 지원해 트래픽을 다양한 기준으로 분산할 수 있습니다. Health Check 기능을 통해 엔드포인트 상태를 주기적으로 모니터링하고, 장애 발생 시 자동으로 정상 리소스로 트래픽을 전환하는 고가용성을 제공합니다. AWS 서비스(ALB, CloudFront, S3 등)와 긴밀하게 통합되며, Alias 레코드를 통해 AWS 리소스를 도메인에 직접 연결할 수 있어 별도 IP 관리가 필요 없습니다.

3. 선택지 분석하기

A. 대기 시간 정책이 포함된 A 레코드를 생성합니다.

→ 대기 시간 정책은 네트워크 속도를 기준으로 최적의 리전을 선택하며 A 레코드는 이름 풀이 속도가 가장 빨라 고성능 요구 사항에 가장 부합합니다.

 

B. 지리적 위치 정책을 사용하여 A 레코드를 만듭니다.

→ 지리적 위치 정책은 사용자의 실제 거주 국가나 대륙을 기준으로 접속지를 정하며 실제 네트워크 전송 속도와는 차이가 생길 수 있습니다.

 

C. 장애 조치 정책을 사용하여 CNAME 레코드를 생성합니다.

→ 장애 조치 정책은 기본 서버가 멈췄을 때 예비 서버로 넘겨주는 고가용성 기능일 뿐 평상시의 성능을 극대화하는 용도가 아닙니다.

 

D. 지리 근접 정책을 사용하여 CNAME 레코드를 생성합니다.

→ 지리 근접 정책은 지도상의 거리를 기준으로 트래픽을 분산하며 이를 조정하기 위해서는 복잡한 바이어스 설정이 추가로 필요합니다.

 

이어서 다음 문제입니다.

문제2

회사에는 us-west-2 지역에 애플리케이션이 배포된 여러 AWS 계정이 있습니다. 애플리케이션 로그는 각 계정의 Amazon S3 버킷 내에 저장됩니다. 회사는 단일 S3 버킷을 사용하는 중앙 집중식 로그 분석 솔루션을 구축하려고 합니다. 로그는 us-west-2를 벗어나면 안 되며, 회사는 최소한의 운영 오버헤드를 원합니다.

이러한 요구 사항을 충족하고 가장 비용 효율적인 솔루션은 무엇입니까?

 

선택지

A. 애플리케이션 S3 버킷 중 하나에서 중앙 집중식 S3 버킷으로 객체를 복사하는 S3 수명 주기 정책을 생성합니다.

B. S3 동일 리전 복제를 사용하여 S3 버킷의 로그를 us-west-2의 다른 S3 버킷으로 복제합니다. 로그 분석을 위해 이 S3 버킷을 사용하세요.

C. 매일 PutObject API 작업을 사용하여 버킷의 전체 콘텐츠를 us-west-2의 다른 S3 버킷에 복사하는 스크립트를 작성합니다. 로그 분석을 위해 이 S3 버킷을 사용하세요.

D. 로그가 S3 버킷(s3:ObjectCreated:* 이벤트)으로 전달될 때마다 트리거되는 AWS Lambda 함수를 이러한 계정에 작성합니다. us-west-2의 다른 S3 버킷에 로그를 복사합니다. 로그 분석을 위해 이 S3 버킷을 사용하세요.

풀이

이 문제는 여러 AWS 계정에 분산된 S3 애플리케이션 로그를 us-west-2 리전 내에서 단일 S3 버킷으로 중앙화하면서 운영 오버헤드와 비용을 최소화하는 것이 핵심입니다. 수명 주기 정책은 버킷 간 복사를 지원하지 않고, 스크립트나 Lambda 방식은 코드 관리와 오류 대응이 필요합니다.

 

정답 : B

 

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

더보기

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

  • 여러 AWS 계정의 S3 로그를 하나의 중앙 S3 버킷으로 통합
  • 로그는 us-west-2 리전 내에서만 상주
  • 운영 오버헤드와 비용을 최소화

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

  • Amazon S3 : 객체 스토리지 서비스로, 이미지/동영상/로그/백업 등 모든 형태의 비정형 데이터를 무제한에 가깝게 저장할 수 있습니다. 데이터는 리전 내 여러 가용 영역에 자동 복제되어 99.999999999%(11 nine) 내구성을 보장합니다. 스토리지 클래스(Standard, IA, Glacier 등)를 통해 접근 빈도에 따라 비용을 최적화할 수 있으며, 버킷 정책, IAM, ACL, 퍼블릭 액세스 차단 설정을 통해 세밀한 접근 제어가 가능합니다. 또한 정적 웹사이트 호스팅, S3 Event Notification을 통한 Lambda 트리거, CloudFront와의 연동 등 다양한 AWS 서비스와 긴밀하게 통합됩니다.
  • AWS Lambda : 서버를 직접 프로비저닝하거나 관리할 필요 없이 코드를 실행할 수 있는 서버리스 컴퓨팅 서비스입니다. S3 업로드, API Gateway 호출, DynamoDB 스트림, SQS 메시지 등 다양한 AWS 이벤트를 트리거로 코드를 자동 실행하며, 실행 시간과 요청 수에 따라 과금되어 유휴 시간에 비용이 발생하지 않습니다. 최대 15분간 실행 가능하며, 메모리는 128MB에서 10GB까지 설정할 수 있고 Python, Node.js, Java, Go 등 다양한 런타임을 지원합니다. Auto Scaling이 자동으로 처리되어 초당 수천 건의 요청도 별도 설정 없이 처리할 수 있어 트래픽 변동이 큰 워크로드에 특히 적합합니다.

3. 선택지 분석하기

A. 애플리케이션 S3 버킷 중 하나에서 중앙 집중식 S3 버킷으로 객체를 복사하는 S3 수명 주기 정책을 생성합니다.

→ S3 수명 주기 정책은 객체 이동이나 삭제 용도로 사용되며 버킷 간 복사를 지원하지 않습니다.

 

B. S3 동일 리전 복제를 사용하여 S3 버킷의 로그를 us-west-2의 다른 S3 버킷으로 복제합니다. 로그 분석을 위해 이 S3 버킷을 사용하세요.

→ 동일 리전 내에서 로그를 자동 복제하는 관리형 기능으로 추가 인프라 없이 운영 오버헤드가 가장 낮습니다.

 

C. 매일 PutObject API 작업을 사용하여 버킷의 전체 콘텐츠를 us-west-2의 다른 S3 버킷에 복사하는 스크립트를 작성합니다. 로그 분석을 위해 이 S3 버킷을 사용하세요.

→ 스크립트 작성과 스케줄 관리, 실패 처리까지 직접 운영해야 하므로 관리 부담이 큽니다.

 

D. 로그가 S3 버킷(s3:ObjectCreated:* 이벤트)으로 전달될 때마다 트리거되는 AWS Lambda 함수를 이러한 계정에 작성합니다. us-west-2의 다른 S3 버킷에 로그를 복사합니다. 로그 분석을 위해 이 S3 버킷을 사용하세요.

→ Lambda 함수 관리와 실행 비용이 발생하며 최소 운영 오버헤드 요구사항에 적합하지 않습니다.

 

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

문제3

회사에는 로컬 데이터 센터 내에 Docker 컨테이너를 활용하는 애플리케이션이 있습니다. 애플리케이션은 컨테이너 인스턴스가 활용하는 해당 호스트의 볼륨에 영구 데이터를 저장하는 컨테이너 호스트에서 작동합니다.

회사는 서버나 스토리지 인프라 관리를 피하기 위해 이 애플리케이션을 완전 관리형 서비스로 마이그레이션하는 것을 목표로 하고 있습니다.

이러한 요구 사항에 맞는 솔루션은 무엇입니까?

 

선택지

A. 자체 관리형 노드를 사용하는 Amazon Elastic Kubernetes Service(Amazon EKS)를 활용합니다. Amazon EC2 인스턴스에 연결된 Amazon Elastic Block Store (Amazon EBS) 볼륨을 설정합니다. EBS 볼륨을 컨테이너 내에 탑재된 영구 볼륨으로 활용합니다.

B. AWS Fargate 시작 유형을 사용하여 Amazon Elastic Container Service(Amazon ECS)를 사용합니다. Amazon Elastic File System(Amazon EFS) 볼륨을 설정합니다. EFS 볼륨을 컨테이너 내에 탑재된 영구 스토리지 볼륨으로 포함합니다.

C. AWS Fargate 시작 유형과 함께 Amazon Elastic Container Service(Amazon ECS)를 활용합니다. Amazon S3 버킷을 생성하고 S3 버킷을 컨테이너 내에 탑재된 영구 스토리지 볼륨으로 매핑합니다.

D. Amazon EC2 시작 유형과 함께 Amazon Elastic Container Service(Amazon ECS)를 사용하십시오. Amazon Elastic File System(Amazon EFS) 볼륨을 설정합니다. EFS 볼륨을 컨테이너 내에 탑재된 영구 스토리지 볼륨으로 추가합니다.

풀이

이 문제는 서버 및 스토리지 인프라 관리를 완전히 피하면서 컨테이너 애플리케이션에 영구 스토리지를 제공하는 완전 관리형 환경으로 마이그레이션하는 것이 핵심입니다. EKS 자체 관리형 노드나 ECS EC2 시작 유형은 서버 관리가 필요하고, EBS는 Fargate에서 사용할 수 없으며, S3는 컨테이너 볼륨으로 마운트하는 파일 시스템 용도가 아닙니다.

 

정답 : B

 

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

더보기

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

  • 서버 및 스토리지 인프라 관리 부담 최소화
  • 컨테이너 기반 애플리케이션을 완전 관리형 서비스로 운영
  • 컨테이너에서 영구 데이터 저장 가능

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

  • Amazon Elastic Kubernetes Service(EKS) : 완전 관리형 Kubernetes 서비스로, CloudWatch, Auto Scaling Groups, IAM과 같은 핵심 AWS 서비스와 통합되어 컨테이너화된 애플리케이션의 모니터링, 확장 및 로드 밸런싱을 원활하게 지원합니다. 오픈소스 Kubernetes를 그대로 사용하므로 온프레미스나 타 클라우드와의 이식성이 높고, 멀티 클러스터 환경에서도 일관된 운영이 가능합니다.
  • Amazon Elastic Container Service(ECS) : 컨테이너 애플리케이션을 쉽게 배포, 관리 및 확대할 수 있도록 도와주는 완전 관리형 컨테이너 오케스트레이션 서비스입니다. Kubernetes보다 학습 곡선이 낮고 AWS 네이티브 서비스(ALB, IAM, CloudWatch 등)와 더욱 긴밀하게 통합되어 AWS 중심 환경에서 빠르게 컨테이너를 운영하기에 적합합니다.
  • AWS Fargate : 서버나 클러스터를 직접 관리하지 않고 컨테이너를 실행할 수 있는 서버리스 컴퓨팅 서비스입니다. ECS 및 EKS 모두와 호환되며, EC2 인스턴스를 직접 프로비저닝할 필요 없이 컨테이너 단위로 CPU와 메모리를 지정해 사용한 만큼만 과금됩니다.
  • Amazon Elastic File System(EFS) : 완전 관리형 네트워크 파일 시스템 서비스입니다. 여러 EC2 인스턴스나 컨테이너가 동시에 동일한 파일 시스템에 접근할 수 있는 공유 스토리지로, 데이터가 늘어날수록 자동으로 용량이 확장되어 별도의 용량 계획이 필요 없습니다.

3. 선택지 분석하기

A. 자체 관리형 노드를 사용하는 Amazon Elastic Kubernetes Service(Amazon EKS)를 활용합니다. Amazon EC2 인스턴스에 연결된 Amazon Elastic Block Store (Amazon EBS) 볼륨을 설정합니다. EBS 볼륨을 컨테이너 내에 탑재된 영구 볼륨으로 활용합니다.

→ EKS 자체 관리형 노드와 EC2, EBS를 직접 운영해야 하므로 완전 관리형 요구사항에 부합하지 않습니다.

 

B. AWS Fargate 시작 유형을 사용하여 Amazon Elastic Container Service(Amazon ECS)를 사용합니다. Amazon Elastic File System(Amazon EFS) 볼륨을 설정합니다. EFS 볼륨을 컨테이너 내에 탑재된 영구 스토리지 볼륨으로 포함합니다.

→ 서버 관리 없이 컨테이너 실행이 가능하며 Fargate에서 지원되는 영구 스토리지를 제공하는 적절한 선택지입니다.

 

C. AWS Fargate 시작 유형과 함께 Amazon Elastic Container Service(Amazon ECS)를 활용합니다. Amazon S3 버킷을 생성하고 S3 버킷을 컨테이너 내에 탑재된 영구 스토리지 볼륨으로 매핑합니다.

→ S3는 파일 시스템이 아니며 컨테이너에 영구 볼륨 형태로 직접 마운트할 수 없습니다.

 

D. Amazon EC2 시작 유형과 함께 Amazon Elastic Container Service(Amazon ECS)를 사용하십시오. Amazon Elastic File System(Amazon EFS) 볼륨을 설정합니다. EFS 볼륨을 컨테이너 내에 탑재된 영구 스토리지 볼륨으로 추가합니다.

→ EC2 인스턴스를 직접 관리해야 하므로 서버 인프라 관리 요구사항을 충족하지 않습니다.

 

유독 중요한 개념들이 많이 나온 하루입니다!

특히 마지막 문제는 자주 사용하지 않는 서비스라서 개념이 헷갈릴 수 있으니 확실하게 확인하시는 걸 권장드립니다.

저희는 또 월요일에 뵙겠습니다! 즐거운 주말 되세요!

저작자표시 (새창열림)

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

AWS SAA 합격으로 가는 길 #166  (0) 2026.03.20
AWS SAA 합격으로 가는 길 #165  (1) 2026.03.16
AWS SAA 합격으로 가는 길 #163  (0) 2026.03.09
AWS SAA 합격으로 가는 길 #162  (0) 2026.03.06
AWS SAA 합격으로 가는 길 #161  (1) 2026.03.02

관련글

티스토리툴바