안녕하세요! 넥스트클라우드의 테크니컬 트레이너 김유림입니다. 😊
벌써 1월의 마지막 월요일이 되었습니다. 꾸준히 공부하시는 여러분을 응원합니다.
문제는 세 가지 단계를 거치며 풀어가겠습니다.
1. 문제의 요구사항 분석하기
2. 관련 AWS 서비스 생각하기
3. 선택지 분석하기
바로 문제 풀이 시작합니다.
문제1
회사는 AWS Organizations의 조직을 사용하여 애플리케이션이 포함된 AWS 계정을 관리합니다. 회사는 조직 내에 전용 모니터링 회원 계정을 설정합니다. 회사는 Amazon CloudWatch를 사용하여 계정 전체의 관측 가능성 데이터를 쿼리하고 시각화하려고 합니다.
어떤 솔루션이 이러한 요구 사항을 충족합니까?
선택지
A. 모니터링 계정에 대해 CloudWatch 교차 계정 관찰 기능을 활성화합니다. 모니터링 계정에서 제공하는 AWS CloudFormation 템플릿을 각 AWS 계정에 배포하여 모니터링 계정과 데이터를 공유합니다.
B. 조직 루트 조직 단위(OU) 아래의 모니터링 계정에서 CloudWatch에 대한 액세스를 제공하도록 서비스 제어 정책(SCP)을 설정합니다.
C. 모니터링 계정에 새 IAM 사용자를 구성합니다. 각 AWS 계정에서 계정의 CloudWatch 데이터를 쿼리하고 시각화할 수 있도록 IAM 정책을 구성합니다. 새 IAM 사용자에게 새 IAM 정책을 연결합니다.
D. 모니터링 계정에 새 IAM 사용자를 생성합니다. 각 AWS 계정에서 교차 계정 IAM 정책을 생성합니다. IAM 정책을 새 IAM 사용자에게 연결합니다.
풀이
CloudWatch 교차 계정 관찰 기능은 여러 계정의 지표, 로그, 추적을 중앙 모니터링 계정에서 통합 조회할 수 있게 해주는 표준 기능입니다. 모니터링 계정에서 싱크를 설정하고, 제공되는 CloudFormation 템플릿을 사용해 소스 계정들을 연결하는 방식이 가장 효율적이고 권장되는 솔루션입니다.
정답 : A
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- AWS Organizations 내에서 모니터링 전용 계정 운영 필요
- 여러 회원 계정의 관측 가능성 데이터(Metrics, Logs, Traces)를 중앙에서 쿼리 및 시각화
- 표준화된 기능을 통해 효율적으로 계정 간 데이터 공유 설정
2. 관련 AWS 서비스 생각하기
- CloudWatch 교차 계정 관찰 : AWS Organizations와 통합되어 여러 계정의 CloudWatch 데이터를 단일 모니터링 계정에서 집계하고 시각화할 수 있는 기능입니다. 모니터링 계정과 소스 계정 간의 연결을 자동으로 설정하며, CloudFormation 스택을 통해 필요한 IAM 역할과 권한을 자동 구성합니다.
- AWS CloudFormation : 인프라를 코드로 관리하는 서비스로, 교차 계정 관찰 기능에서 제공하는 템플릿을 각 소스 계정에 배포하면 모니터링 계정과의 데이터 공유에 필요한 리소스와 권한이 자동으로 생성됩니다. 이를 통해 수동 설정 없이 일관된 구성을 보장합니다.
- Service Control Policy : Organizations에서 계정 또는 OU에 적용하는 권한 경계로, 계정이 수행할 수 있는 작업을 제한합니다. 그러나 SCP는 액세스를 허용하는 것이 아니라 제한하는 용도이며, 교차 계정 데이터 공유를 직접 설정하지는 못합니다.
3. 선택지 분석하기
A. 모니터링 계정에 대해 CloudWatch 교차 계정 관찰 기능을 활성화합니다. 모니터링 계정에서 제공하는 AWS CloudFormation 템플릿을 각 AWS 계정에 배포하여 모니터링 계정과 데이터를 공유합니다.
→ CloudWatch의 기본 제공 교차 계정 기능을 활용하며, CloudFormation을 통한 대규모 배포를 제안하고 있으므로 요구사항을 가장 정확하게 충족합니다.
B. 조직 루트 조직 단위(OU) 아래의 모니터링 계정에서 CloudWatch에 대한 액세스를 제공하도록 서비스 제어 정책(SCP)을 설정합니다.
→ SCP는 최대 허용 권한을 정의할 뿐, 실제로 계정 간의 데이터를 연결하거나 모니터링 기능을 활성화하는 구성 요소가 아닙니다.
C. 모니터링 계정에 새 IAM 사용자를 구성합니다. 각 AWS 계정에서 계정의 CloudWatch 데이터를 쿼리하고 시각화할 수 있도록 IAM 정책을 구성합니다. 새 IAM 사용자에게 새 IAM 정책을 연결합니다.
→ IAM 사용자는 특정 계정에 종속되며, 수많은 계정의 데이터를 쿼리하기 위해 매번 정책을 수동으로 연결하는 방식은 관리 효율성이 매우 낮습니다.
D. 모니터링 계정에 새 IAM 사용자를 생성합니다. 각 AWS 계정에서 교차 계정 IAM 정책을 생성합니다. IAM 정책을 새 IAM 사용자에게 연결합니다.
→ C와 마찬가지로 수동 관리에 가깝고 CloudWatch의 전용 교차 계정 관찰 기능을 활용하지 않는 비표준 방식입니다.
이어서 다음 문제입니다.
문제2
회사에서 온프레미스 레거시 애플리케이션을 AWS로 마이그레이션하려고 합니다. 애플리케이션은 온프레미스 ERP(전사적 자원 관리) 시스템에서 고객 주문 파일을 수집합니다. 그런 다음 애플리케이션은 파일을 SFTP 서버에 업로드합니다. 애플리케이션은 매시간 주문 파일을 확인하는 예약된 작업을 사용합니다.
회사에는 이미 온프레미스 네트워크에 연결된 AWS 계정이 있습니다. AWS의 새로운 애플리케이션은 기존 ERP 시스템과의 통합을 지원해야 합니다. 새로운 애플리케이션은 안전하고 탄력적이어야 하며 SFTP 프로토콜을 사용하여 ERP 시스템의 주문을 즉시 처리해야 합니다.
어떤 솔루션이 이러한 요구 사항을 충족합니까?
선택지
A. 두 개의 가용 영역에 AWS Transfer Family SFTP 인터넷 연결 서버를 생성합니다. Amazon S3 스토리지를 사용하세요. 주문 파일을 처리하는 AWS Lambda 함수를 생성합니다. S3 이벤트 알림을 사용하여 s3:ObjectCreated:* 이벤트를 Lambda 함수로 보냅니다.
B. 하나의 가용 영역에 AWS Transfer Family SFTP 인터넷 연결 서버를 생성합니다. Amazon Elastic File System(Amazon EFS) 스토리지를 사용합니다. 주문 파일을 처리하는 AWS Lambda 함수를 생성합니다. Transfer Family 관리형 워크플로를 사용하여 Lambda 함수를 호출합니다.
C. 두 개의 가용 영역에 AWS Transfer Family SFTP 내부 서버를 생성합니다. Amazon Elastic File System(Amazon EFS) 스토리지를 사용합니다. 주문 파일을 처리하기 위해 AWS Step Functions 상태 머신을 생성합니다. Amazon EventBridge Scheduler를 사용하면 상태 시스템을 호출하여 Amazon EFS에서 주문 파일을 주기적으로 확인할 수 있 습니다.
D. 두 개의 가용 영역에 AWS Transfer Family SFTP 내부 서버를 생성합니다. Amazon S3 스토리지를 사용하세요. 주문 파일을 처리하는 AWS Lambda 함수를 생성합니다. Transfer Family 관리형 워크플로를 사용하여 Lambda 함수를 호출합니다.
풀이
이 문제는 온프레미스 ERP 시스템과 안전하게 연결되는 SFTP 환경을 구축하고 고가용성과 즉각적인 데이터 처리를 보장하는 것이 핵심입니다. AWS Transfer Family 내부 서버는 사설 네트워크 통합과 고가용성을 제공하며, 관리형 워크플로와 Lambda 연계는 파일 업로드 후 즉시 처리를 가능하게 합니다.
정답 : D
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 온프레미스 ERP 시스템과 연동된 애플리케이션으로부터 SFTP 방식의 주문 파일 수신
- 파일이 업로드되는 즉시 주문 데이터를 처리
- 보안성과 가용성을 고려한 AWS 관리형 서비스 기반의 구성 필요
2. 관련 AWS 서비스 생각하기
- AWS Transfer Family : SFTP, FTPS, FTP 프로토콜을 지원하는 완전 관리형 파일 전송 서비스입니다. 인터넷 연결 서버는 공개 엔드포인트를 제공하고, 내부 서버는 VPC 내부에서만 접근 가능하여 온프레미스 네트워크와 Direct Connect 또는 VPN으로 안전하게 연결할 수 있습니다. 다중 AZ 배포로 고가용성을 제공합니다.
- Transfer Family 관리형 워크플로 : 파일이 업로드될 때 자동으로 트리거되어 사전 정의된 단계를 실행하는 기능입니다. Lambda 함수 호출, 파일 복사, 태깅, 삭제 등의 작업을 즉시 수행할 수 있어 실시간 처리에 적합하며, 별도의 스케줄러나 폴링이 필요 없습니다.
- Amazon S3 : 무제한 확장 가능한 객체 스토리지로, 내구성이 99.999999999%이며 버전 관리, 암호화, 수명 주기 정책 등 다양한 기능을 제공합니다. Transfer Family와 네이티브 통합되어 SFTP 업로드 파일을 직접 저장할 수 있으며, EFS보다 비용 효율적이고 관리가 간단합니다.
- Amazon EFS : 완전 관리형 네트워크 파일 시스템으로, 여러 EC2 인스턴스가 동시에 마운트할 수 있습니다. 그러나 Transfer Family에서 파일 업로드 시 자동 트리거 기능이 제한적이며, S3보다 비용이 높고 이 시나리오에서는 불필요한 기능입니다.
3. 선택지 분석하기
A. 두 개의 가용 영역에 AWS Transfer Family SFTP 인터넷 연결 서버를 생성합니다. Amazon S3 스토리지를 사용하세요. 주문 파일을 처리하는 AWS Lambda 함수를 생성합니다. S3 이벤트 알림을 사용하여 s3:ObjectCreated:* 이벤트를 Lambda 함수로 보냅니다.
→ 인터넷 연결 서버는 공용 엔드포인트를 사용하므로 온프레미스 네트워크와의 사설 연동 및 보안 요구사항에 부적합합니다.
B. 하나의 가용 영역에 AWS Transfer Family SFTP 인터넷 연결 서버를 생성합니다. Amazon Elastic File System(Amazon EFS) 스토리지를 사용합니다. 주문 파일을 처리하는 AWS Lambda 함수를 생성합니다. Transfer Family 관리형 워크플로를 사용하여 Lambda 함수를 호출합니다.
→ 단일 가용 영역 구성은 장애 시 서비스 중단 가능성이 있어 탄력성과 고가용성 요구사항에 부적합합니다.
C. 두 개의 가용 영역에 AWS Transfer Family SFTP 내부 서버를 생성합니다. Amazon Elastic File System(Amazon EFS) 스토리지를 사용합니다. 주문 파일을 처리하기 위해 AWS Step Functions 상태 머신을 생성합니다. Amazon EventBridge Scheduler를 사용하면 상태 시스템을 호출하여 Amazon EFS에서 주문 파일을 주기적으로 확인할 수 있 습니다.
→ 스케줄러 기반 주기적 확인 방식은 파일 업로드 즉시 처리가 어려워 실시간 처리 요구사항에 부적합합니다.
D. 두 개의 가용 영역에 AWS Transfer Family SFTP 내부 서버를 생성합니다. Amazon S3 스토리지를 사용하세요. 주문 파일을 처리하는 AWS Lambda 함수를 생성합니다. Transfer Family 관리형 워크플로를 사용하여 Lambda 함수를 호출합니다.
→ 내부 서버를 통한 사설 연동과 관리형 워크플로는 즉시 처리가 가능하고, 보안성과 탄력성이 있어 적절한 선택지입니다.
마지막 문제 살펴보겠습니다.
문제3
회사는 AWS Organizations를 사용하여 여러 AWS 계정 내에서 워크로드를 실행합니다. 태깅 정책은 회사에서 태그를 생성할 때 부서 태그를 AWS 리소스에 추가합니다.
회계 팀은 Amazon EC2 소비에 대한 지출을 결정해야 합니다. 회계 팀은 AWS 계정과 관계없이 비용을 담당하는 부서를 결정해야 합니다. 회계 팀은 조직 내 모든 AWS 계정에 대해 AWS Cost Explorer에 액세스할 수 있으며 Cost Explorer의 모든 보고서에 액세스해야 합니다.
운영상 가장 효율적인 방식으로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
선택지
A. 조직 관리 계정 청구 콘솔에서 부서라는 사용자 정의 비용 할당 태그를 활성화합니다. 비용 탐색기에서 태그 이름별로 그룹화하여 하나의 비용 보고서를 생성하고 EC2별로 필터링합니다.
B. Organizations 마스터 계정 결제 콘솔에서 부서라는 AWS 정의 비용 할당 태그를 활성화합니다. 비용 탐색기에서 태그 이름별로 그룹화하여 하나의 비용 보고서를 생성하고 EC2별로 필터링합니다.
C. 조직 회원 계정 청구 콘솔에서 부서라는 사용자 정의 비용 할당 태그를 활성화합니다. 비용 탐색기에서 태그 이름별로 그룹화하여 하나의 비용 보고서를 생성하고 EC2별로 필터링합니다.
D. Organizations 회원 계정 결제 콘솔에서 부서라는 AWS 정의 비용 할당 태그를 활성화합니다. 비용 탐색기에서 태그 이름별로 그룹화하여 하나의 비용 보고서를 생성하고 EC2별로 필 터링합니다.
풀이
사용자가 만든 'Department' 태그를 비용 분석에 쓰려면, 조직 관리 계정(Management Account)의 결제 콘솔에서 '사용자 정의 비용 할당 태그'로 활성화해야 합니다. 이를 통해 조직 내 모든 계정의 비용 데이터에 태그가 적용되며, Cost Explorer에서 해당 태그를 기준으로 그룹화하여 부서별 EC2 비용을 한 번에 파악할 수 있습니다.
정답 : A
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- AWS Organizations 환경에서 모든 계정의 비용을 통합 관리해야 함
- 사용자가 생성한 '부서(Department)' 태그를 기준으로 비용을 분류해야 함
- 운영 효율성을 위해 중앙(관리 계정)에서 설정을 제어하고 전체 데이터를 조회해야 함
2. 관련 AWS 서비스 생각하기
- AWS Organizations : 여러 AWS 계정을 중앙에서 관리하는 서비스로, 관리 계정(master account)과 회원 계정(member account)으로 구성되며, 통합 결제 기능을 통해 모든 계정의 비용을 관리 계정에서 일괄 관리합니다.
- 태그 정책 : AWS Organizations에서 리소스 태깅 규칙을 중앙에서 정의하고 적용하는 기능으로, 문제에서 언급된 부서 태그는 이러한 정책을 통해 생성된 사용자 정의 태그가 부여됩니다.
- 비용 할당 태그 : AWS 리소스에 부여된 태그를 기반으로 비용을 추적하고 분류하는 기능으로, 사용자 정의 태그와 AWS 생성 태그로 구분되며, 사용자가 직접 생성한 태그는 사용자 정의 비용 할당 태그로 분류됩니다.
- AWS Cost Explorer : 비용 및 사용량 데이터를 시각화하고 분석하는 도구로, 태그별, 서비스별, 계정별 등 다양한 기준으로 그룹화하여 비용 보고서를 생성할 수 있으며, Organizations 환경에서는 관리 계정에서 모든 회원 계정의 비용을 통합하여 조회할 수 있습니다.
- 사용자 정의 비용 할당 태그 활성화 : 관리 계정의 청구 콘솔에서 활성화해야 하며, 활성화 후 최대 24시간 후부터 Cost Explorer에서 해당 태그 기준으로 비용 데이터를 조회할 수 있습니다.
3. 선택지 분석하기
A. 조직 관리 계정 청구 콘솔에서 부서라는 사용자 정의 비용 할당 태그를 활성화합니다. 비용 탐색기에서 태그 이름별로 그룹화하여 하나의 비용 보고서를 생성하고 EC2별로 필터링합니다.
→ 관리 계정에서 사용자 정의 태그를 활성화하고 통합 분석을 수행하므로 가장 적절하고 효율적인 솔루션입니다.
B. Organizations 마스터 계정 결제 콘솔에서 부서라는 AWS 정의 비용 할당 태그를 활성화합니다. 비용 탐색기에서 태그 이름별로 그룹화하여 하나의 비용 보고서를 생성하고 EC2별로 필터링합니다.
→ 사용자가 생성한 부서 태그는 AWS 정의 태그가 아닌 사용자 정의 태그입니다.
C. 조직 회원 계정 청구 콘솔에서 부서라는 사용자 정의 비용 할당 태그를 활성화합니다. 비용 탐색기에서 태그 이름별로 그룹화하여 하나의 비용 보고서를 생성하고 EC2별로 필터링합니다.
→ 비용 할당 태그는 회원 계정이 아닌 관리 계정에서만 활성화할 수 있으며, 회원 계정에서는 조직 전체 비용을 관리할 수 없습니다.
D. Organizations 회원 계정 결제 콘솔에서 부서라는 AWS 정의 비용 할당 태그를 활성화합니다. 비용 탐색기에서 태그 이름별로 그룹화하여 하나의 비용 보고서를 생성하고 EC2별로 필터링합니다.
→ 회원 계정에서는 비용 할당 태그를 활성화할 수 없고, 부서 태그는 AWS 정의 태그가 아닌 사용자 정의 태그입니다.
그럼 저희는 또 금요일에 뵙겠습니다! 오늘도 고생 많으셨습니다. 😊
'AWS > SAA 준비' 카테고리의 다른 글
| AWS SAA 합격으로 가는 길 #154 (0) | 2026.01.30 |
|---|---|
| AWS SAA 합격으로 가는 길 #152 (0) | 2026.01.23 |
| AWS SAA 합격으로 가는 길 #151 (0) | 2026.01.19 |
| AWS SAA 합격으로 가는 길 #150 (1) | 2026.01.16 |
| AWS SAA 합격으로 가는 길 #149 (0) | 2026.01.12 |