안녕하세요! 넥스트클라우드의 SA 손유림입니다. 😊
연휴 잘 쉬셨나요? 쉬었으니 이제 다시! 오늘도 3문제로 가볍게 시작해요!
문제는 세 가지 단계를 거치며 풀어 나갈 거예요.
1. 문제의 요구사항 분석하기
2. 관련 AWS 서비스 생각하기
3. 선택지 분석하기
바로 문제 풀이 해볼까요?
문제1
회사는 여러 벤더를 사용하여 Amazon S3 버킷에 저장된 디지털 자산을 배포합니다. 이 회사는 벤더 AWS 계정이 이러한 S3 버킷에서 객체를 다운로드하는 데 필요한 최소한의 액세스 권 한을 갖도록 하려고 합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
선택지
A. 익명의 읽기 권한과 모든 버킷을 나열할 수 있는 권한이 있는 버킷 정책을 설계합니다.
B. 사용자에게 읽기 전용 액세스 권한을 부여하는 버킷 정책을 설계합니다. IAM 엔터티를 보안 주체로 지정합니다.
C. IAM 역할에 대해 지정된 읽기 전용 액세스 정책이 있는 교차 계정 IAM 역할을 생성합니다.
D. 공급업체 사용자에게 읽기 전용 액세스 권한을 부여하는 사용자 정책 및 공급업체 사용자 그룹을 만듭니다.
풀이
회사가 여러 벤더에게 Amazon S3 버킷에 저장된 디지털 자산에 대한 읽기 전용 액세스 권한을 부여하되, 최소한의 운영 오버헤드로 이를 달성하기 위해서는 IAM 역할을 사용하는 것이 가장 적절합니다. IAM 역할은 AWS 리소스에 대한 권한 정책을 중앙에서 관리할 수 있어 개별 계정이나 사용자별로 관리할 필요가 없어 운영 오버헤드가 최소화됩니다.
정답 : C
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 다양한 벤더에게 S3 버킷에 저장된 디지털 자산에 대한 읽기 전용 액세스 권한 부여
- 최소한의 운영 오버헤드로 요구사항 충족
2. 관련 AWS 서비스 생각하기
AWS Identity and Access Management(IAM)는 AWS 리소스에 안전하게 액세스를 제어할 수 있는 웹 서비스입니다. IAM 역할은 특정 권한을 가진 AWS 자격 증명으로, EC2 인스턴스나 AWS 서비스에 역할을 수임하여 권한을 위임할 수 있습니다. IAM 역할은 임시 보안 인증 정보를 제공하므로 장기 액세스 키를 공유하거나 관리할 필요가 없습니다. 또한 역할 신뢰 정책을 통해 역할을 수임할 수 있는 보안 주체를 제어할 수 있습니다.
S3 버킷 정책은 Amazon S3 버킷 리소스에 액세스를 제한하는 리소스 기반 정책입니다. 이 정책을 통해 버킷과 버킷의 객체에 대한 액세스 권한을 IAM 역할, 사용자, 그룹 또는 AWS 계정에 부여할 수 있습니다.
3. 선택지 분석하기
A. 익명의 읽기 권한과 모든 버킷을 나열할 수 있는 권한이 있는 버킷 정책을 설계합니다.
→ 익명의 읽기 권한을 부여하면 버킷 객체를 누구나 읽을 수 있게 되어 보안 위험이 있습니다.
B. 사용자에게 읽기 전용 액세스 권한을 부여하는 버킷 정책을 설계합니다. IAM 엔터티를 보안 주체로 지정합니다.
→ IAM 엔터티(사용자 또는 그룹)에 직접 권한을 부여하면 개별 계정 관리가 필요해져 운영 오버헤드가 커집니다.
C. IAM 역할에 대해 지정된 읽기 전용 액세스 정책이 있는 교차 계정 IAM 역할을 생성합니다.
→ IAM 역할을 생성하고 역할에 정의된 정책을 통해 벤더 계정에 읽기 전용 액세스 권한을 부여하면 중앙 집중식으로 관리할 수 있어 운영 오버헤드가 최소화됩니다.
D. 공급업체 사용자에게 읽기 전용 액세스 권한을 부여하는 사용자 정책 및 공급업체 사용자 그룹을 만듭니다.
→ IAM 사용자와 그룹을 만들어 권한을 관리하는 것은 많은 벤더가 있을 경우 운영 부담이 커집니다.
이어서 다음 문제입니다.
문제2
회사는 AWS에서 애플리케이션을 실행합니다. 애플리케이션이 일관되지 않은 사용량을 수신합니다. 애플리케이션은 AWS Direct Connect를 사용하여 온프레미스 MySQL 호환 데이터베 이스에 연결합니다. 온프레미스 데이터베이스는 지속적으로 최소 2GiB의 메모리를 사용합니다. 회사는 온프레미스 데이터베이스를 관리형 AWS 서비스로 마이그레이션하려고 합니다. 회사는 자동 확장 기능을 사용하여 예기치 않은 작업 부하 증가를 관리하려고 합니다. 최소한의 관리 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
선택지
A. 기본 읽기 및 쓰기 용량 설정으로 Amazon DynamoDB 데이터베이스를 프로비저닝합니다.
B. 최소 용량이 1 Aurora 용량 단위(ACU)인 Amazon Aurora 데이터베이스를 프로비저닝합니다.
C. 최소 용량이 1 Aurora 용량 단위(ACU)인 Amazon Aurora Serverless v2 데이터베이스를 프로비저닝합니다.
D. 2GiB의 메모리로 Amazon RDS for MySQL 데이터베이스를 프로비저닝합니다.
풀이
이 회사는 자동 확장 기능을 통해 작업 부하 증가에 유연하게 대응할 수 있는 Amazon Aurora Serverless v2를 프로비저닝하는 것이 가장 적절합니다. Serverless 구성에서는 최소 ACU 설정만으로 초기 프로비저닝 규모를 작게 가져갈 수 있어 비용 효율적이면서도 필요 시 자동으로 확장됩니다.
정답 : C
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 온프레미스 MySQL 호환 데이터베이스를 AWS 관리형 서비스로 마이그레이션
- 자동 확장 기능을 통해 예기치 않은 부하 증가에 대응
- 최소한의 관리 오버헤드
2. 관련 AWS 서비스 생각하기
Amazon Aurora는 MySQL과 PostgreSQL 호환 관계형 데이터베이스 엔진을 클라우드에서 제공하는 완전관리형 데이터베이스 서비스입니다. Aurora는 빠른 성능, 고가용성, 내결함성, 자동 백업 및 복원 등의 기능을 제공합니다. Aurora 클러스터는 기본적으로 3개의 가용성 영역에 데이터를 복제하여 높은 내결함성을 제공합니다. Aurora 스토리지는 자동으로 확장되며, 읽기 전용 복제본을 추가하여 읽기 워크로드를 분산할 수 있습니다.
Amazon Aurora Serverless v2는 서버리스 Aurora 클러스터로, 워크로드에 따라 자동으로 컴퓨팅 용량을 확장하고 축소합니다. 사전 프로비저닝 없이 설정된 최소 Aurora 용량 단위(ACU) 크기로 시작하여 필요에 따라 자동으로 확장되므로 정적 프로비저닝 환경에 비해 비용을 크게 절감할 수 있고 관리 부담도 적습니다.
Amazon RDS는 관계형 데이터베이스를 클라우드에서 설치, 운영 및 확장할 수 있는 웹 서비스입니다. MySQL, PostgreSQL, Oracle, SQL Server 등 다양한 데이터베이스 엔진을 지원하며 고가용성, 백업, 모니터링 등의 기능을 제공합니다. 단, RDS에서는 수동으로 인스턴스 크기를 조정해야 하므로 자동 확장 기능은 없습니다.
3. 선택지 분석하기
A. 기본 읽기 및 쓰기 용량 설정으로 Amazon DynamoDB 데이터베이스를 프로비저닝합니다.
→ DynamoDB는 NoSQL 데이터베이스로 관계형 데이터에는 부적절합니다.
B. 최소 용량이 1 Aurora 용량 단위(ACU)인 Amazon Aurora 데이터베이스를 프로비저닝합니다.
→ Aurora 프로비저닝된 환경에서는 확장성에 제약이 있습니다.
C. 최소 용량이 1 Aurora 용량 단위(ACU)인 Amazon Aurora Serverless v2 데이터베이스를 프로비저닝합니다.
→ Aurora Serverless v2는 최소 ACU 설정만으로도 작은 규모의 초기 프로비저닝이 가능하고 자동 확장 기능이 있어 요구사항을 충족합니다.
D. 2GiB의 메모리로 Amazon RDS for MySQL 데이터베이스를 프로비저닝합니다.
→ RDS MySQL은 고정 프로비저닝 방식으로 자동 확장 기능이 없어 요구사항을 충족하지 못합니다.
마지막 문제 살펴볼게요.
문제3
회사는 PostgreSQL 단일 AZ DB 인스턴스용 Amazon RDS에 모든 주문을 저장하는 온라인 쇼핑 애플리케이션을 호스팅합니다. 경영진은 단일 실패 지점을 제거하기를 원하며 솔루션 설 계자에게 애플리케이션 코드를 변경하지 않고도 데이터베이스 다운타임을 최소화할 수 있는 접근 방식을 권장하도록 요청했습니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?
선택지
A. 데이터베이스 인스턴스를 수정하고 다중 AZ 옵션을 지정하여 기존 데이터베이스 인스턴스를 다중 AZ 배포로 변환합니다.
B. 새로운 RDS 다중 AZ 배포를 생성합니다. 현재 RDS 인스턴스의 스냅샷을 만들고 스냅샷으로 새 다중 AZ 배포를 복원합니다.
C. 다른 가용 영역에서 PostgreSQL 데이터베이스의 읽기 전용 복제본을 생성합니다. Amazon Route 53 가중 레코드 세트를 사용하여 데이터베이스 전체에 요청을 분산합니다.
D. 최소 그룹 크기가 2인 Amazon EC2 Auto Scaling 그룹에 RDS for PostgreSQL 데이터베이스를 배치합니다. Amazon Route 53 가중 레코드 세트를 사용하여 인스턴스 간에 요청을 분산합니다.
풀이
기존 단일 AZ RDS DB 인스턴스를 수정하여 다중 AZ 옵션을 지정하면 데이터베이스 다운타임을 최소화하면서 애플리케이션 코드를 변경하지 않고도 가용성을 향상시킬 수 있습니다. 이를 통해 단일 실패 지점 문제를 해결하고 고가용성을 제공할 수 있습니다.
정답 : A
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 단일 실패 지점 제거 및 애플리케이션 코드 변경 없이 데이터베이스 다운타임 최소화
2. 관련 AWS 서비스 생각하기
Amazon RDS는 관계형 데이터베이스를 운영하기 위한 웹 서비스로, MySQL, PostgreSQL, Oracle, SQL Server 등 다양한 데이터베이스 엔진을 지원합니다. RDS 다중 AZ(Multi-AZ) 배포는 두 개의 가용 영역에 주 인스턴스와 예비 복제본을 배치하여 높은 가용성을 제공합니다. 기본 인스턴스에 장애가 발생하면 예비 복제본이 자동으로 프로모션되어 새로운 기본 인스턴스가 됩니다. 다중 AZ 배포는 계획된 시스템 유지 관리 기간 중에도 가용성이 보장됩니다.
RDS는 기존 단일 AZ 인스턴스를 다중 AZ 배포로 변환하는 기능을 지원합니다. 변환 프로세스 중에는 잠시 동안 작은 중단이 발생하지만, 데이터베이스를 완전히 다시 빌드할 필요는 없습니다. 다중 AZ 배포로 전환하면 애플리케이션 코드를 수정할 필요 없이 데이터베이스 가용성을 높일 수 있습니다.
3. 선택지 분석하기
A. 데이터베이스 인스턴스를 수정하고 다중 AZ 옵션을 지정하여 기존 데이터베이스 인스턴스를 다중 AZ 배포로 변환합니다.
→ 기존 DB 인스턴스를 수정하여 다중 AZ 옵션을 설정하면 최소한의 다운타임으로 코드 변경 없이 가용성을 높일 수 있습니다.
B. 새로운 RDS 다중 AZ 배포를 생성합니다. 현재 RDS 인스턴스의 스냅샷을 만들고 스냅샷으로 새 다중 AZ 배포를 복원합니다.
→ 완전히 새로운 다중 AZ 배포를 생성하면 기존 DB의 스냅샷을 만들고 복원하는 과정이 필요해 다운타임이 길어집니다.
C. 다른 가용 영역에서 PostgreSQL 데이터베이스의 읽기 전용 복제본을 생성합니다. Amazon Route 53 가중 레코드 세트를 사용하여 데이터베이스 전체에 요청을 분산합니다.
→ 읽기 전용 복제본은 쿼리 부하 분산에는 도움이 되지만 단일 실패 지점 문제는 해결되지 않습니다.
D. 최소 그룹 크기가 2인 Amazon EC2 Auto Scaling 그룹에 RDS for PostgreSQL 데이터베이스를 배치합니다. Amazon Route 53 가중 레코드 세트를 사용하여 인스턴스 간에 요청을 분산합니다.
→ EC2 Auto Scaling 그룹에 데이터베이스를 배치하고 Route 53을 통해 부하를 분산하는 것은 다중 AZ 배포에 비해 관리가 더 복잡합니다.
감사합니다. 다음 글에서 만나요! 😊
'AWS > SAA 준비' 카테고리의 다른 글
AWS SAA 합격으로 가는 길 #124 (0) | 2025.10.13 |
---|---|
AWS SAA 합격으로 가는 길 #122 (1) | 2025.10.06 |
AWS SAA 합격으로 가는 길 #121 (1) | 2025.10.03 |
AWS SAA 합격으로 가는 길 #120 (0) | 2025.09.29 |
AWS SAA 합격으로 가는 길 #119 (0) | 2025.09.26 |