안녕하세요! 넥스트클라우드의 SA 백종훈입니다. ☺️
문제는 세 가지 단계를 거치며 풀어 나갈 거예요.
1. 문제의 요구사항 분석하기
2. 관련 AWS 서비스 생각하기
3. 선택지 분석하기
바로 문제 풀이 해볼까요?
문제1
회사에 Java 및 PHP 기반 웹 애플리케이션이 있습니다. 회사는 애플리케이션을 온프레미스에서 AWS로 옮길 계획입니다. 회사는 새로운 사이트 기능을 자주 테스트할 수 있는 능력이 필요합니다. 회사는 또한 최소한의 운영 오버헤드를 필요로 하는 가용성이 높고 관리되는 솔루션이 필요합니다.
이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
선택지
A. Amazon S3 버킷을 생성합니다. S3 버킷에서 정적 웹 호스팅을 활성화합니다. 정적 콘텐츠를 S3 버킷에 업로드합니다. AWS Lambda를 사용하여 모든 동적 콘텐츠를 처리합니다.
B. 웹 애플리케이션을 AWS Elastic Beanstalk 환경에 배포합니다. 기능 테스트를 위해 URL 스와핑을 사용하여 여러 Elastic Beanstalk 환경 간에 전환합니다.
C. Java 및 PHP로 구성된 Amazon EC2 인스턴스에 웹 애플리케이션을 배포합니다. Auto Scaling 그룹과 Application Load Balancer를 사용하여 웹 사이트의 가용성을 관리하십시오.
D. 웹 애플리케이션을 컨테이너화합니다. 웹 애플리케이션을 Amazon EC2 인스턴스에 배포합니다. AWS 로드 밸런서 컨트롤러를 사용하여 테스트용 새 사이트 기능이 포함된 컨테이너 간에 트래픽을 동적으로 라우팅합니다.
풀이
Java와 PHP 기반 웹 애플리케이션의 AWS 마이그레이션에서는 플랫폼 호환성, 배포 간소화, 그리고 새로운 기능의 안전한 테스트 환경이 중요합니다. AWS Elastic Beanstalk은 이 모든 요구사항을 만족하는 완전 관리형 플랫폼으로, URL 스와핑 기능을 통해 무중단으로 새로운 기능을 테스트하고 배포할 수 있습니다.
정답 : B
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- Java 및 PHP 기반 웹 애플리케이션의 AWS 마이그레이션
- 새로운 사이트 기능을 자주 테스트할 수 있는 능력 필요
- 최소한의 운영 오버헤드로 가용성이 높고 관리되는 솔루션
2. 관련 AWS 서비스 생각하기
- AWS Elastic Beanstalk는 Java, PHP, Node.js, Python, Ruby, .NET, Go 등 다양한 언어로 작성된 웹 애플리케이션을 쉽게 배포하고 관리할 수 있는 완전 관리형 PaaS 서비스입니다. 개발자는 애플리케이션 코드만 업로드하면 Elastic Beanstalk가 자동으로 용량 프로비저닝, 로드 밸런싱, Auto Scaling, 애플리케이션 상태 모니터링, 인스턴스 구성을 처리합니다. 특히 URL 스와핑 기능을 통해 두 개의 환경(예: 프로덕션, 스테이징) 간에 즉시 트래픽을 전환할 수 있어 새로운 기능을 안전하게 테스트하고 무중단 배포가 가능합니다. 이를 통해 운영 오버헤드를 최소화하면서도 높은 가용성을 보장할 수 있습니다.
3. 선택지 분석하기
A. Amazon S3 버킷을 생성합니다. S3 버킷에서 정적 웹 호스팅을 활성화합니다.
→ S3 정적 웹 호스팅은 정적 콘텐츠에만 적합하며, Java/PHP 애플리케이션의 동적 기능을 완전히 Lambda로 재작성하는 것은 현실적이지 않습니다.
B. 웹 애플리케이션을 AWS Elastic Beanstalk 환경에 배포합니다.
→ Elastic Beanstalk은 Java/PHP 애플리케이션을 완전 지원하며, URL 스와핑을 통해 여러 환경 간 즉시 전환이 가능해 기능 테스트에 최적입니다.
C. Java 및 PHP로 구성된 Amazon EC2 인스턴스에 웹 애플리케이션을 배포합니다.
→ EC2 직접 관리는 인스턴스 패치, 모니터링, 스케일링 등 운영 오버헤드가 크며, 새 기능 테스트를 위한 환경 전환이 복잡합니다.
D. 웹 애플리케이션을 컨테이너화합니다.
→ 컨테이너화와 AWS Load Balancer Controller 설정은 복잡하고 운영 오버헤드가 증가하며, Elastic Beanstalk 대비 관리 부담이 큽니다.
이어서 다음 문제입니다.
문제2
회사는 웹 사이트에서 Amazon CloudFront를 사용하고 있습니다. 회사는 CloudFront 배포에서 로깅을 활성화했으며 로그는 회사의 Amazon S3 버킷 중 하나에 저장됩니다. 회사는 로그에 대한 고급 분석을 수행하고 시각화를 구축해야 합니다.
솔루션 설계자는 이러한 요구 사항을 충족하기 위해 무엇을 해야 합니까?
선택지
A. Amazon Athena에서 표준 SQL 쿼리를 사용하여 S3 버킷의 CloudFront 로그를 분석합니다. AWS Glue로 결과를 시각화합니다.
B. Amazon Athena에서 표준 SQL 쿼리를 사용하여 S3 버킷의 CloudFront 로그를 분석합니다. Amazon QuickSight로 결과를 시각화합니다.
C. Amazon DynamoDB에서 표준 SQL 쿼리를 사용하여 S3 버킷의 CloudFront 로그를 분석합니다. AWS Glue로 결과를 시각화합니다.
D. Amazon DynamoDB에서 표준 SQL 쿼리를 사용하여 S3 버킷의 CloudFront 로그를 분석합니다. Amazon QuickSight로 결과를 시각화합니다.
풀이
S3에 저장된 CloudFront 로그 데이터의 고급 분석과 시각화를 위해서는 서버리스 쿼리 서비스인 Amazon Athena와 클라우드 네이티브 BI 도구인 Amazon QuickSight의 조합이 최적입니다. Athena는 S3 데이터를 직접 SQL로 쿼리할 수 있으며, QuickSight는 Athena 결과를 바탕으로 직관적인 대시보드와 시각화를 제공합니다.
정답 : B
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- CloudFront 로그가 S3 버킷에 저장됨
- 로그에 대한 고급 분석 수행 필요
- 분석 결과의 시각화 구축 필요
2. 관련 AWS 서비스 생각하기
- Amazon Athena는 표준 SQL을 사용하여 S3에 저장된 데이터를 직접 분석할 수 있는 대화형 쿼리 서비스입니다. 서버리스 방식으로 작동하며, 별도의 인프라 설정 없이 즉시 사용할 수 있습니다. CloudFront 액세스 로그는 구조화된 텍스트 파일 형태로 S3에 저장되므로, Athena에서 테이블을 정의하고 SQL 쿼리로 분석할 수 있습니다. Amazon QuickSight는 AWS의 완전 관리형 비즈니스 인텔리전스 서비스로, Athena를 포함한 다양한 데이터 소스와 연결하여 대화형 대시보드와 시각화를 생성할 수 있습니다. QuickSight는 클라우드 네이티브 설계로 확장성이 뛰어나며, 다양한 차트 유형, 필터링, 드릴다운 기능을 제공합니다.
3. 선택지 분석하기
A. Amazon Athena에서 표준 SQL 쿼리를 사용하여 S3 버킷의 CloudFront 로그를 분석합니다. AWS Glue로 결과를 시각화합니다.
→ Athena는 S3 로그 분석에 적합하지만, AWS Glue는 ETL 서비스로 시각화 기능이 제한적입니다.
B. Amazon Athena에서 표준 SQL 쿼리를 사용하여 S3 버킷의 CloudFront 로그를 분석합니다. Amazon QuickSight로 결과를 시각화합니다.
→ Athena로 S3 데이터를 SQL로 분석하고, QuickSight로 전문적인 시각화와 대시보드를 구축하는 최적의 조합입니다.
C. Amazon DynamoDB에서 표준 SQL 쿼리를 사용하여 S3 버킷의 CloudFront 로그를 분석합니다.
→ DynamoDB는 NoSQL 데이터베이스로 S3에 저장된 로그 파일을 직접 쿼리할 수 없으며, 표준 SQL을 지원하지 않습니다.
D. Amazon DynamoDB에서 표준 SQL 쿼리를 사용하여 S3 버킷의 CloudFront 로그를 분석합니다.
→ DynamoDB는 S3 로그 분석에 적합하지 않으며, 표준 SQL 쿼리를 지원하지 않습니다
마지막 문제 살펴볼게요.
문제3
회사에서 Amazon API Gateway 및 AWS Lambda를 사용하는 공개적으로 액세스 가능한 서버리스 애플리케이션을 실행하고 있습니다. 최근 애플리케이션의 트래픽이 봇넷의 사기성 요청으로 인해 급증했습니다.
승인되지 않은 사용자의 요청을 차단하기 위해 솔루션 설계자는 어떤 단계를 수행해야 합니까? (두 가지를 선택하세요.)
선택지
A. 정품 사용자에게만 공유되는 API 키로 사용량 계획을 생성합니다.
B. 사기성 IP 주소의 요청을 무시하도록 Lambda 함수 내에 논리를 통합합니다.
C. 악성 요청을 대상으로 하는 AWS WAF 규칙을 구현하고 이를 필터링하는 작업을 트리거합니다.
D. 기존 공개 API를 비공개 API로 전환합니다. DNS 레코드를 업데이트하여 사용자를 새 API 엔드포인트로 리디렉션합니다.
E. API에 액세스를 시도하는 각 사용자에 대해 IAM 역할을 생성합니다. 사용자는 API 호출 시 역할을 맡게 됩니다.
풀이
봇넷의 사기성 요청을 효과적으로 차단하려면 API 레벨에서의 인증 메커니즘과 네트워크 레벨에서의 보안 필터링이 모두 필요합니다. API Gateway의 API 키 기반 사용량 계획으로 정당한 사용자만 접근하도록 제한하고, AWS WAF로 악성 요청 패턴을 실시간으로 탐지하여 차단하는 것이 가장 효과적인 조합입니다.
정답 : A,C
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- API Gateway와 Lambda 기반 서버리스 애플리케이션
- 봇넷의 사기성 요청으로 인한 트래픽 급증
- 승인되지 않은 사용자의 요청 차단 필요
2. 관련 AWS 서비스 생각하기
- Amazon API Gateway의 사용량 계획과 API 키 기능을 통해 인증된 사용자만 API에 접근하도록 제한할 수 있습니다. API 키는 특정 클라이언트나 애플리케이션을 식별하는 고유한 문자열로, 정품 사용자에게만 배포하여 액세스를 제어할 수 있습니다. 사용량 계획에서는 API 키별로 요청 수 제한, 버스트 제한, 할당량을 설정할 수 있어 남용을 방지합니다. AWS WAF는 웹 애플리케이션 방화벽으로 악성 웹 트래픽을 실시간으로 필터링할 수 있습니다. 봇넷 공격, 알려진 악성 IP, 비정상적인 요청 패턴, SQL 인젝션 등을 탐지하고 차단하는 규칙을 설정할 수 있습니다. API Gateway와 WAF를 연동하면 API 레벨에서 보안 필터링이 적용됩니다.
3. 선택지 분석하기
A. 정품 사용자에게만 공유되는 API 키로 사용량 계획을 생성합니다.
→ API 키 기반 인증으로 정당한 사용자만 접근하도록 제한하고, 사용량 계획으로 요청 수를 제어하여 남용을 방지할 수 있습니다.
B. 사기성 IP 주소의 요청을 무시하도록 Lambda 함수 내에 논리를 통합합니다.
→ Lambda 함수 내에서 IP 필터링을 구현하면 모든 요청이 Lambda까지 도달하여 비용이 발생하고, 코드 복잡성과 유지보수 부담이 증가합니다.
C. 악성 요청을 대상으로 하는 AWS WAF 규칙을 구현하고 이를 필터링하는 작업을 트리거합니다.
→ WAF 규칙으로 봇넷 IP, 악성 요청 패턴, 비정상적인 트래픽을 API Gateway 레벨에서 사전 차단하여 효과적으로 보안을 강화할 수 있습니다.
D. 기존 공개 API를 비공개 API로 전환합니다.
→ 비공개 API로 전환하면 VPC 내에서만 접근 가능하므로 공개적으로 액세스 가능한 서비스 요구사항에 맞지 않습니다.
E. API에 액세스를 시도하는 각 사용자에 대해 IAM 역할을 생성합니다.
→ 각 사용자별로 IAM 역할을 생성하고 관리하는 것은 확장성이 떨어지고 운영 복잡성이 크게 증가합니다.
감사합니다. 다음 글에서 만나요!
'AWS > SAA 준비' 카테고리의 다른 글
| AWS SAA 합격으로 가는 길 #109 (2) | 2025.08.18 |
|---|---|
| AWS SAA 합격으로 가는 길 #108 (3) | 2025.08.11 |
| AWS SAA 합격으로 가는 길 #106 (5) | 2025.08.04 |
| AWS SAA 합격으로 가는 길 #105 (3) | 2025.08.01 |
| AWS SAA 합격으로 가는 길 #104 (2) | 2025.07.28 |
