안녕하세요! 넥스트클라우드의 SA 손유림입니다. 😊
이 순간을 놓치지 말고 최선을 다해봅시다. 다 같이 화이팅!
문제는 세 가지 단계를 거치며 풀어 나갈 거예요.
1. 문제의 요구사항 분석하기
2. 관련 AWS 서비스 생각하기
3. 선택지 분석하기
바로 문제 풀이 해볼까요?
문제1
회사는 고객이 재무 정보를 검색할 수 있도록 고객에게 API 인터페이스를 제공합니다. 회사는 연중 사용량이 가장 많은 시간에 더 많은 수의 요청을 예상합니다. 회사는 API가 고객 만족을 보장하기 위해 낮은 대기 시간으로 일관되게 응답하도록 요구합니다. 회사는 API에 컴퓨팅 호스트를 제공해야 합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
선택지
A. Application Load Balancer 및 Amazon Elastic Container Service(Amazon ECS)를 사용합니다.
B. 프로비저닝된 동시성과 함께 Amazon API Gateway 및 AWS Lambda 함수를 사용합니다.
C. Application Load Balancer 및 Amazon Elastic Kubernetes Service(Amazon EKS) 클러스터를 사용합니다.
D. 예약된 동시성과 함께 Amazon API Gateway 및 AWS Lambda 함수를 사용합니다.
풀이
Amazon API Gateway와 AWS Lambda는 서버리스 아키텍처로 인프라 관리가 불필요하며, 프로비저닝된 동시성(Provisioned Concurrency)은 Lambda 인스턴스를 미리 초기화하여 콜드 스타트를 제거하고 일관된 낮은 대기 시간을 보장합니다. 자동 확장으로 트래픽 급증에도 대응할 수 있어 운영 오버헤드가 최소화됩니다.
정답 : B
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- API가 고객 만족을 보장하고 낮은 대기 시간으로 일관되게 응답
- API에 컴퓨팅 호스트를 제공
2. 관련 AWS 서비스 생각하기
Amazon API Gateway는 API를 빌드, 배포 및 관리할 수 있는 완전 관리형 서비스입니다. API Gateway를 사용하면 AWS 서비스뿐만 아니라 온프레미스 리소스와도 API를 통합할 수 있습니다. API Gateway는 API 요청을 라우팅, 트래픽 제어, 인증, 모니터링 등의 기능을 제공합니다.
AWS Lambda는 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행할 수 있는 서버리스 컴퓨팅 서비스입니다. Lambda 함수는 이벤트에 의해 자동으로 실행되며, 요청에 따라 자동으로 확장됩니다. 프로비저닝된 동시성은 Lambda 함수의 동시 실행을 준비하는 기능으로, 트래픽 급증 시에도 지연 없이 함수를 호출할 수 있습니다.
3. 선택지 분석하기
A. Application Load Balancer 및 Amazon Elastic Container Service(Amazon ECS)를 사용합니다.
→ ECS는 컨테이너 관리, 클러스터 용량 계획, 스케일링 설정 등 운영 부담이 있으며, ALB와의 통합도 추가 구성이 필요합니다.
B. 프로비저닝된 동시성과 함께 Amazon API Gateway 및 AWS Lambda 함수를 사용합니다.
→ API Gateway와 Lambda의 프로비저닝된 동시성은 콜드 스타트를 제거하여 일관된 낮은 대기 시간을 보장하며, 완전 관리형으로 운영 오버헤드가 최소입니다.
C. Application Load Balancer 및 Amazon Elastic Kubernetes Service(Amazon EKS) 클러스터를 사용합니다.
→ EKS는 쿠버네티스 클러스터 관리, 노드 프로비저닝, 업그레이드 등 운영 복잡도가 가장 높아 요구사항에 부적합합니다.
D. 예약된 동시성과 함께 Amazon API Gateway 및 AWS Lambda 함수를 사용합니다.
→ 예약된 동시성(Reserved Concurrency)은 최대 동시 실행 수를 제한하는 기능으로, 콜드 스타트를 방지하지 못하며 일관된 낮은 대기 시간을 보장하지 않습니다.
이어서 다음 문제입니다.
문제2
회사는 데이터를 Amazon S3 버킷에 PDF 형식으로 저장합니다. 회사는 모든 신규 및 기존 데이터를 Amazon S3에 7년 동안 보관해야 한다는 법적 요구 사항을 따라야 합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
선택지
A. S3 버킷에 대한 S3 버전 관리 기능을 켭니다. 7년 후 데이터를 삭제하도록 S3 수명 주기를 구성합니다. 모든 S3 객체에 대한 MFA(Multi-Factor Authentication) 삭제를 구성합니다.
B. S3 버킷에 대한 거버넌스 보존 모드로 S3 객체 잠금을 켭니다. 7년 후에 만료되도록 보존 기간을 설정합니다. 모든 기존 개체를 다시 복사하여 기존 데이터를 준수하도록 합니다.
C. S3 버킷에 대해 규정 준수 보존 모드로 S3 객체 잠금을 켭니다. 7년 후에 만료되도록 보존 기간을 설정합니다. 모든 기존 개체를 다시 복사하여 기존 데이터를 준수하도록 합니다.
D. S3 버킷에 대해 규정 준수 보존 모드로 S3 객체 잠금을 켭니다. 7년 후에 만료되도록 보존 기간을 설정합니다. S3 배치 작업을 사용하여 기존 데이터를 규정에 맞게 가져옵니다.
풀이
S3 객체 잠금의 규정 준수 보존 모드는 보존 기간 동안 누구도 객체를 삭제하거나 수정할 수 없어 법적 요구사항을 충족합니다. S3 배치 작업을 사용하면 대량의 기존 객체에 객체 잠금 설정을 자동으로 적용할 수 있어 수동 복사 없이 운영 오버헤드를 최소화합니다.
정답 : D
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- PDF 데이터를 7년 동안 Amazon S3에 보관
- 최소한의 운영 오버헤드로 요구사항을 충족
2. 관련 AWS 서비스 생각하기
Amazon S3는 데이터를 저장하기 위한 객체 스토리지 서비스입니다. S3는 데이터의 높은 내구성, 가용성 및 보안성을 제공합니다.
S3 객체 잠금은 객체를 의도치 않게 덮어쓰거나 삭제하는 것을 방지하는 기능입니다. 규정 준수 보존 모드는 S3 객체 잠금의 가장 엄격한 보호 수준으로, 보존 기간 동안 어떤 사용자도 객체를 덮어쓰거나 삭제할 수 없습니다. S3 배치 작업은 기존 객체와 새 객체에 동일한 보존 설정을 적용할 수 있는 기능입니다. 이를 통해 기존 데이터를 규정에 맞게 가져올 수 있습니다. 객체 메타데이터를 업데이트하는 S3 배치 작업은 작업 시간과 비용을 크게 줄일 수 있습니다.
3. 선택지 분석하기
A. S3 버킷에 대한 S3 버전 관리 기능을 켭니다. 7년 후 데이터를 삭제하도록 S3 수명 주기를 구성합니다. 모든 S3 객체에 대한 MFA(Multi-Factor Authentication) 삭제를 구성합니다.
→ 버전 관리와 MFA 삭제는 실수 방지에 도움이 되지만, 관리자 권한이 있으면 삭제 가능하므로 법적 요구사항의 불변성을 보장하지 못합니다.
B. S3 버킷에 대한 거버넌스 보존 모드로 S3 객체 잠금을 켭니다. 7년 후에 만료되도록 보존 기간을 설정합니다. 모든 기존 개체를 다시 복사하여 기존 데이터를 준수하도록 합니다.
→ 거버넌스 모드는 특정 권한을 가진 사용자가 보존 기간을 우회할 수 있어 법적 요구사항을 완전히 충족하지 못하며, 수동 복사는 운영 부담이 큽니다.
C. S3 버킷에 대해 규정 준수 보존 모드로 S3 객체 잠금을 켭니다. 7년 후에 만료되도록 보존 기간을 설정합니다. 모든 기존 개체를 다시 복사하여 기존 데이터를 준수하도록 합니다.
→ 규정 준수 모드는 올바르지만, 모든 기존 객체를 수동으로 복사하는 것은 스토리지 비용이 2배로 증가하고 시간과 노력이 많이 소요됩니다.
D. S3 버킷에 대해 규정 준수 보존 모드로 S3 객체 잠금을 켭니다. 7년 후에 만료되도록 보존 기간을 설정합니다. S3 배치 작업을 사용하여 기존 데이터를 규정에 맞게 가져옵니다.
→ 규정 준수 모드로 불변성을 보장하고, S3 배치 작업으로 기존 객체에 자동으로 객체 잠금을 적용하여 복사 없이 최소 운영 오버헤드로 요구사항을 충족합니다.
마지막 문제 살펴볼게요.
문제3
솔루션 설계자는 스토리지 비용을 최적화해야 합니다. 솔루션 설계자는 더 이상 액세스하지 않거나 거의 액세스하지 않는 Amazon S3 버킷을 식별해야 합니다. 최소한의 운영 오버헤드로 이 목표를 달성할 수 있는 솔루션은 무엇입니까?
선택지
A. 고급 활동 메트릭에 대한 S3 Storage Lens 대시보드를 사용하여 버킷 액세스 패턴을 분석합니다.
B. AWS Management Console에서 S3 대시보드를 사용하여 버킷 액세스 패턴을 분석합니다.
C. 버킷에 대한 Amazon CloudWatch BucketSizeBytes 지표를 켭니다. Amazon Athena에서 메트릭 데이터를 사용하여 버킷 액세스 패턴을 분석합니다.
D. S3 객체 모니터링을 위해 AWS CloudTrail을 켭니다. Amazon CloudWatch Logs와 통합된 CloudTrail 로그를 사용하여 버킷 액세스 패턴을 분석합니다.
풀이
Amazon S3 Storage Lens는 조직 전체의 S3 사용 패턴과 활동 메트릭을 자동으로 수집하고 시각화하는 완전관리형 분석 솔루션입니다. 고급 활동 메트릭을 활성화하면 버킷별 액세스 빈도, 검색 패턴 등을 대시보드에서 확인할 수 있어 별도의 구성 없이 최소 운영 오버헤드로 거의 액세스하지 않는 버킷을 식별할 수 있습니다.
정답 : A
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 스토리지 비용 최적화 필요
- 거의 액세스하지 않는 S3 버킷 식별 필요
2. 관련 AWS 서비스 생각하기
Amazon S3 Storage Lens는 S3 버킷의 사용량 및 활동에 대한 메트릭을 수집하고 시각화하는 분석 솔루션입니다. Storage Lens는 버킷 수준, 계정 수준 및 조직 수준에서 메트릭을 제공합니다. 고급 메트릭으로는 객체 수준 작업, 데이터 전송, 활동 메트릭 등이 있습니다. Storage Lens는 이러한 고급 메트릭과 트렌드를 시각화하여 스토리지 최적화에 도움을 줍니다.
Amazon CloudWatch는 AWS 리소스 및 애플리케이션에 대한 모니터링 및 관찰력을 제공하는 서비스입니다. CloudWatch 메트릭을 사용하여 리소스 사용량과 운영 상태를 추적할 수 있습니다. 하지만 S3 버킷의 상세 액세스 패턴 분석에는 한계가 있습니다.
AWS CloudTrail은 AWS 계정의 활동을 기록하는 서비스입니다. CloudTrail 로그를 분석하여 S3 버킷 액세스 패턴을 모니터링할 수 있지만, 액세스 패턴 분석을 위한 최선의 방법은 아닙니다.
3. 선택지 분석하기
A. 고급 활동 메트릭에 대한 S3 Storage Lens 대시보드를 사용하여 버킷 액세스 패턴을 분석합니다.
→ S3 Storage Lens의 고급 활동 메트릭은 버킷별 액세스 빈도, 다운로드 바이트 수 등을 자동 수집하고 대시보드로 시각화하여 최소 운영 오버헤드로 비활성 버킷을 식별할 수 있습니다.
B. AWS Management Console에서 S3 대시보드를 사용하여 버킷 액세스 패턴을 분석합니다.
→ 기본 S3 대시보드는 스토리지 크기와 객체 수만 표시하며, 액세스 빈도나 패턴에 대한 정보를 제공하지 않습니다.
C. 버킷에 대한 Amazon CloudWatch BucketSizeBytes 지표를 켭니다. Amazon Athena에서 메트릭 데이터를 사용하여 버킷 액세스 패턴을 분석합니다.
→ BucketSizeBytes는 버킷 크기만 측정하며 액세스 패턴과 무관하고, Athena로 분석하려면 별도 쿼리 작성과 데이터 처리가 필요하여 운영 오버헤드가 큽니다.
D. S3 객체 모니터링을 위해 AWS CloudTrail을 켭니다. Amazon CloudWatch Logs와 통합된 CloudTrail 로그를 사용하여 버킷 액세스 패턴을 분석합니다.
→ CloudTrail 로그를 활성화하고 CloudWatch Logs와 통합한 뒤 로그를 분석하는 것은 복잡하고 비용이 높으며, Storage Lens보다 운영 오버헤드가 훨씬 큽니다.
감사합니다. 다음 글에서 만나요! 😊
'AWS > SAA 준비' 카테고리의 다른 글
| AWS SAA 합격으로 가는 길 #129 (0) | 2025.10.31 |
|---|---|
| AWS SAA 합격으로 가는 길 #128 (0) | 2025.10.27 |
| AWS SAA 합격으로 가는 길 #126 (0) | 2025.10.20 |
| AWS SAA 합격으로 가는 길 #125 (0) | 2025.10.17 |
| AWS SAA 합격으로 가는 길 #124 (0) | 2025.10.13 |
