[AWS] Official Practice Question Set 1~10

AWS Skill Builder의 1~10번을 풀면서 기억해둘 포인트를 간단히 정리해본다.

 

1. 단일 가용영역(Availability Zone) 애플리케이션의 가용성 높이기

[단일 AZ + 가용성 향상 → Multi-AZ Auto Scaling + Load Balancer]

웹 애플리케이션은 Network Load Balancer를 통해 2개의 Amazon EC2 인스턴스에서 실행된다. EC2 인스턴스는 단일 가용 영역에 있다. 아키텍처의 가용성을 높이려면 Solutions Architect는 무엇을 해야 하는가?

 

C. EC2 인스턴스를 여러 가용 영역 전반으로 확장되는 Auto Scaling 그룹에 배치한다. Auto Scaling 그룹을 Network Load Balancer의 대상으로 지정한다.

정답입니다. 이 솔루션은 EC2 인스턴스를 여러 가용 영역으로 확장하고 추가 용량이 필요할 때 자동으로 용량을 추가합니다.

 

Key Point

현재 문제의 가장 큰 위험은 EC2가 하나의 가용 영역에만 존재한다는 점이다. 해당 AZ에 장애가 발생하면 두 인스턴스가 모두 영향을 받을 수 있다.

따라서 인스턴스를 여러 AZ에 분산하고, Auto Scaling Group으로 필요한 인스턴스 수를 유지하도록 구성해야 한다. NLB는 이 인스턴스들로 트래픽을 분산한다.

 

가용성 문제에서는 단순히 인스턴스 수를 늘리는 것보다 장애 도메인(AZ)을 분리했는지를 먼저 확인한다.

 

가용영역

AWS는 거대한 상용 데이터센터를 운영하는 클라우드 서비스이기 때문에 하나의 AZ(ap-northeast-2a) 건물 안에 수많은 회사와 개인의 서버가 함께 들어서 있다. 다만 가상화 기술(VPC, IAM 등)을 통해 논리적으로 완벽하게 격리되어 있으므로 같은 AZ를 쓴다고 해서 다른 사람이 내 데이터에 접근하거나 볼 수는 없다.

 

2. 임시 데이터 + 높은 랜덤 IOPS에 맞는 스토리지

[임시 데이터 + 40,000 Random IOPS + 비용 효율성 → Instance Store]

한 미디어 회사에서 그래픽 렌더링용 애플리케이션을 새로 설계하고 있다. 애플리케이션은 프레임 렌더링 후 삭제되는 임시 데이터를 저장할 최대 400GB의 스토리지를 필요로 한다. 이 애플리케이션에서 렌더링을 수행하려면 약 40,000의 랜덤 IOPS가 필요하다.

이 렌더링 애플리케이션에 적합한 가장 비용 효율적인 스토리지 옵션은 무엇인가?

 

D. 인스토어 스토어 스토리지를 사용하는 스토리지 최적화 Amazon EC2 인스턴스

정답입니다. 스토리지 최적화 인스턴스는 로컬 스토리지의 대규모 데이터 집합에 대한 높은 순차적 읽기 및 쓰기 액세스를 필요로 하는 워크로드를 위해 설계되었습니다. 이러한 인스턴스는 지연 시간이 짧은 수만 번의 랜덤 IOPS를 애플리케이션에 제공하도록 최적화되어 있습니다. 인스턴스 스토어에는 추가 비용이 들지 않습니다.

 

Key Point

이 문제에서는 성능만 충족하는지가 아니라 임시 데이터와 비용 효율성을 함께 봐야 한다.

• Instance Store: 인스턴스 로컬 스토리지. 높은 IOPS가 필요하고 데이터 영속성이 필요하지 않을 때 적합하다.
• EBS io1/io2: 높은 IOPS는 제공할 수 있지만 영속 스토리지에 대한 추가 비용을 지불해야 한다.
• S3: 객체 스토리지(파일 저장)이므로 렌더링 중 디스크를 직접 빠르게 반복 읽기/쓰기하는 워크로드와 성격이 다르다.
• st1: 높은 랜덤 IOPS보다 대용량 순차 처리량에 초점을 둔 HDD 스토리지다.

임시 데이터 + 높은 랜덤 IOPS라면 영속성을 위해 비용을 추가하는 EBS보다 Instance Store를 먼저 검토한다.

 

3. Direct Connect 장애 조치 구성

[온프레미스 ↔ 여러 VPC + Direct Connect 기존 사용 + Active-Failover + 비용 효율성 → Site-to-Site VPN 백업]

Solutions Architect는 온프레미스 데이터 센터의 워크로드를 여러 Amazon VPC와 연결해야 한다. VPC는 AWS Transit Gateway를 통해 중앙 집중식으로 연결되어야 한다. VPC는 활성 장애 조치 구성을 사용하여 데이터 센터에 1GB 이상 연결되어야 한다. 현재 AWS Direct Connect 링크 하나만 연결을 설정하는 데 사용되고 있다. 워크로드를 연결하는 가장 비용 효율적인 방법은 무엇인가?

 

D. 기존 Direct Connect 전용 링크를 활성 연결로 사용한다. AWS Site-to-Site VPN 연결을 장애 조치 연결로 추가한다.

정답입니다. Direct Connect 링크를 사용하여 온프레미스 데이터 센터에서 하나 이상의 VPC로의 전용 연결을 설정할 수 있습니다. Site-to-Site VPN 연결은 온프레미스 데이터 센터에서 Amazon VPC로의 액세스를 제공합니다. Site-to-Site VPN 연결을 Direct Connect 전용 링크의 장애 조치로 사용할 수 있습니다. 따라서 이 솔루션이 가장 비용 효율적입니다.

Key Point

여러 VPC는 Transit Gateway를 중심으로 연결하고, 온프레미스와 AWS 사이의 주 연결은 이미 존재하는 Direct Connect를 그대로 사용한다.

 

여기서 필요한 것은 두 번째 주 회선이 아니라 장애 시 사용할 백업 경로다. Direct Connect를 하나 더 구축하는 대신 Site-to-Site VPN을 장애 조치 경로로 추가하면 요구사항을 만족하면서 비용을 줄일 수 있다.

• Site-to-Site VPN: 네트워크 ↔ 네트워크 연결
• Client VPN: 개별 사용자/노트북 ↔ AWS 연결

기존 Direct Connect가 있고 비용 효율적인 장애 조치가 필요하면 Direct Connect + Site-to-Site VPN 조합을 검토한다.

 

 

 

여기서 Direct Connect가 끊기면 AWS 쪽 전체 연결이 끊길 수 있다. 따라서 백업으로 Site-to-Site VPN을 하나 더 둔다.

 

 

4. DocumentDB와 IAM의 역할 구분

[ IAM은 AWS 리소스 작업 제어 / DocumentDB 접속 인증은 DB 계정 사용]

회사에서 데이터베이스에 Amazon DocumentDB(MongoDB 호환)를 사용한다. 이 회사에서는 데이터베이스 액세스를 관리하는 데 AWS Identity and Access Management(AWS IAM)를 사용하려고 한다. 회사에서는 인증 프로세스를 간소화하고자 한다.

다음 중 이러한 요구 사항을 충족하는 솔루션은 무엇인가?

 

C. IAM 정책을 사용하여 Amazon DocumentDB와 관련된 AWS 수준 작업을 제어한다. 데이터베이스 사용자 이름과 암호를 사용하여 Amazon DocumentDB 데이터베이스에 연결한다.

정답입니다. IAM 정책은 권한과 액세스 제어를 정의하는 문서입니다. Amazon DocumentDB는 완전관리형 네이티브 JSON 도큐먼트 데이터베이스입니다. Amazon DocumentDB를 사용하면 인프라를 관리하지 않고도 중요한 문서 워크로드를 규모에 맞게 운영할 수 있습니다. IAM 정책을 사용하여 Amazon DocumentDB와 관련된 AWS 수준 작업을 관리할 수 있습니다. AWS 수준 작업의 예로는 클러스터 만들기 또는 수정이 있습니다. Amazon DocumentDB 데이터베이스에 연결하고 작업을 수행하려면 기존 방식 인증을 사용해야 합니다. 기존 인증 방법으로는 데이터베이스 사용자 이름과 암호 등이 있습니다.

 

D. Amazon DocumentDB에서 자동으로 암호를 업데이트하는 IAM 정책을 구현하여 기존 방식 인증의 필요성을 없앤다.

IAM 정책을 사용하여 Amazon DocumentDB에서 직접 데이터베이스 암호를 관리하거나 업데이트할 수 없습니다

 

Key Point

IAM이 모든 종류의 인증을 대신하는 것은 아니다. 이 문제에서는 권한의 계층을 구분하는 것이 중요하다.

• IAM: DocumentDB 클러스터 생성, 수정 등 AWS 리소스 수준 작업 제어
• DB 사용자 이름/암호: 실제 DocumentDB에 접속하는 데이터베이스 인증

AWS 리소스를 누가 관리할 수 있는가와 DB 내부에 누가 로그인할 수 있는가는 서로 다른 인증, 권한 영역으로 본다.

 

 

5. Scale-In 중 장기 요청 보호하기

[ ALB + Auto Scaling Scale-In + 긴 요청 + 5xx 방지 → Deregistration Delay]

애플리케이션은 Application Load Balancer 기반의 Amazon EC2 인스턴스에서 실행된다. 인스턴스는 여러 가용 영역의 Amazon EC2 Auto Scaling 그룹에서 실행된다. 복잡한 보고서의 경우 애플리케이션이 요청에 응답하는 데 최대 15분이 걸릴 수 있다. Solutions Architect는 축소 이벤트 중에 보고서 요청이 진행 중 사용자에게 HTTP 5xx 오류가 발생할 수 있다는 점을 우려하고 있다.

인스턴스 종료 전에 사용자 요청이 완료되도록 하려면 Solutions Architect는 어떻게 해야 하는가?

 

B. 대상 인스턴스 그룹의 등록 취소 지연 (deregistration delay)의 제한 시간을 900초보다 크게 늘린다.

 

A. Auto Scaling 그룹의 휴지 기간(Cooldown)을 가장 오래 걸리는 응답에 필요한 시간보다 길게 늘린다.

 

Key Point

Auto Scaling이 인스턴스를 축소할 때 요청을 처리 중인 인스턴스를 바로 제거하면 사용자 요청이 중간에 끊길 수 있다.

Deregistration Delay는 Target Group에서 인스턴스를 제거할 때

1. 해당 인스턴스로 새 요청을 보내지 않고
2. 이미 처리 중인 요청이 끝날 시간을 제공한 뒤
3. 인스턴스를 제거하도록 한다.

15분은 900초이므로 최대 요청 시간보다 충분히 긴 deregistration delay가 필요하다.

반면 Cooldown은 한 번의 스케일링 이후 다음 스케일링 판단까지 기다리는 시간으로 진행 중인 요청 자체를 보호하는 기능은 아니다.

Scale-In 시 기존 연결/요청 보호가 핵심이면 Cooldown이 아니라 Deregistration Delay를 본다.

 

 

6. Pilot Light와 Warm Standby 구분

[DR(Disaster Recovery) 환경을 미리 준비하되 평소 대부분 비활성 → Pilot Light]

한 회사에서 Solutions Architect에게 기존 온프레미스 애플리케이션에 대한 파일럿 라이트 재해 복구(DR) 전략을 구현하도록 요청한다. 애플리케이션은 독립적으로 실행되며 데이터베이스에 액세스할 필요가 없다.

다음 중 파일럿 라이트 DR 전략을 구현하는 솔루션은 무엇인가?

 

C. Amazon EC2 인스턴스를 사용하여 AWS에 애플리케이션 호스팅 환경을 다시 생성하고 EC2 인스턴스를 중지한다. 온프레미스 애플리케이션에 장애가 발생하면 중지된 EC2 인스턴스를 시작하고 애플리케이션 트래픽 전체를 AWS 클라우드에서 실행 중인 EC2 인스턴스로 전달한다.

정답입니다. 파일럿 라이트 DR 전략이 맞습니다. 이 솔루션은 AWS 리전에 기존 애플리케이션 호스팅 환경을 다시 생성하고, 대부분의(또는 전체) 리소스를 비활성 상태로 두며, 테스트 중이나 DR 장애 조치가 필요한 경우에만 리소스를 사용합니다. RPO와 RTO는 보통 10분 정도입니다.

 

D. Amazon EC2 인스턴스를 사용하여 AWS에 애플리케이션 호스팅 환경을 다시 생성한다. 애플리케이션 트래픽의 10%를 AWS 클라우드에서 실행 중인 EC2 인스턴스로 전달한다. 온프레미스 애플리케이션에 장애가 발생하면 애플리케이션 트래픽 전체를 AWS 클라우드에서 실행 중인 EC2 인스턴스로 전달한다.

오답입니다. 이 답은 웜 스탠바이 DR 전략입니다.

 

Key Point

AWS에 애플리케이션 호스팅 환경을 다시 생성한다는 것은 온프레미스 애플리케이션이 실행될 수 있는 비상용 환경을 AWS에 미리 준비한다는 의미다.

• Pilot Light: 복구 환경을 준비해두지만 평소에는 대부분의 리소스를 중지한다. 장애 발생 시 시작, 확장한다.
• Warm Standby: 축소된 AWS 환경이 평소에도 실행 중이며 일부 트래픽을 처리할 수 있다.

따라서 평소 AWS EC2 중지는 Pilot Light, 평소에도 10% 트래픽 처리는 Warm Standby를 의미한다.

DR 유형은 장애가 없을 때 AWS 환경이 어느 정도 실행되고 있는지를 기준으로 구분한다.

 

7. RDS 스토리지 gp2, gp3, Provisioned IOPS 비교

[작은 용량 + 1,000 IOPS + 비용 효율성 → gp3 기본 성능 활용]

회사에서 Amazon EC2 기반 MariaDB 데이터베이스를 Amazon RDS로 전환하고 있다. 회사는 자사의 CPU 및 메모리 요구 사항을 충족할 데이터베이스 인스턴스 유형을 이미 파악했다. 데이터베이스는 현재 40GiB의 스토리지 용량과 1,000IOPS를 제공한다.

다음 중 Amazon RDS for MariaDB 인스턴스의 스토리지 구성으로 가장 비용 효과적인 것은 무엇인가?

 

D. RDS 인스턴스에 50GiB의 범용 SSD(gp3) 스토리지를 프로비저닝한다.

정답입니다. 범용 SSD(gp3)는 볼륨에 관계없이 3,000IOPS를 추가 비용 없이 지원합니다.

 

C. RDS 인스턴스에 334GiB의 범용 SSD(gp2) 스토리지를 프로비저닝한다.

오답입니다. gp2는 용량이 커질수록 IOPS가 늘어나는 구조라서, 1,000 IOPS를 확보하려고 필요 이상으로 용량을 크게 잡아야 해.

즉 실제 데이터는 40GiB밖에 없는데 334GiB를 결제해야 함. 그래서 낭비지.

 

B. RDS 인스턴스에 1,000IOPS인 50GiB의 프로비저닝된 IOPS 스토리지를 프로비저닝한다.

= RDS에 50GiB 용량의 "Provisioned IOPS 스토리지"를 붙이고, 그 스토리지의 성능을 1000 IOPS로 지정한다

오답입니다. Provisioned IOPS는 용량뿐 아니라 지정한 IOPS 성능에도 비용이 붙으므로, 기본 gp3 성능으로 요구사항을 충족할 수 있다면 gp3가 더 저렴하다.

 

Key Point

필요한 것은 약 40GiB의 공간과 1000 IOPS다. gp3는 작은 용량에서도 문제에서 요구한 IOPS를 기본 성능으로 충족할 수 있으므로, 필요한 용량만 확보하면 된다.

반면

• gp2: IOPS가 용량에 연동되므로 1,000 IOPS를 맞추기 위해 필요 이상의 저장공간을 프로비저닝해야 한다.
• Provisioned IOPS: 필요한 IOPS를 직접 지정할 수 있지만, 기본 gp3 성능으로 충분한 상황에서 추가 성능 비용을 지불하는 것은 비효율적이다.

여기서 프로비저닝은 필요한 자원을 미리 지정하고 할당하는 것을 의미한다.

성능 요구사항을 만족하는 선택지가 여러 개라면 필요 이상의 용량이나 성능을 구매하게 되는지까지 비교해야 한다.

 

8. 여러 VPC의 중앙 집중식 연결과 딥 패킷 검사

[ 다수 VPC + 중앙 집중식 라우팅 + 트래픽 분리 + Deep Packet Inspection → Transit Gateway + Network Firewall]

Solutions Architect가 중앙 집중화되고 확장 가능한 솔루션을 통해 Amazon VPC 10개를 상호 연결해야 한다. VPC 중 5개는 VPC 10개 전체에 완전히 연결되어야 한다. VPC 중 5개는 VPC의 일부에만 연결해야 한다. 또한 모든 VPC는 인터넷을 출입하는 네트워크 트래픽 및 VPC 간 네트워크 트래픽을 대상으로 딥 패킷 검사를 수행해야 한다.

다음 중 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇인가?

 

A. AWS Transit Gateway를 사용하여 VPC를 상호 연결한다. 네트워크 트래픽 딥 패킷 검사에 AWS Network Firewall을 사용한다.

정답입니다. Transit Gateway는 허브 앤 스포크 설계를 제공하여 여러 Amazon VPC와 온프레미스 네트워크를 연결합니다. Transit Gateway는 여러 라우팅 테이블을 사용하여 네트워크 트래픽 흐름을 분할할 수 있습니다. Network Firewall은 네트워크 트래픽 딥 패킷 검사에 사용할 수 있는 방화벽입니다. 이 솔루션은 최소한의 운영 오버헤드로 요구 사항을 충족합니다.

 

Key Point

VPC가 10개라면 VPC Peering을 일대일로 계속 추가하는 방식은 연결 수와 라우팅 관리가 복잡해진다. Transit Gateway는 여러 VPC를 중앙 허브에 연결하고 라우팅 테이블을 통해 네트워크 간 통신 범위를 나눌 수 있다.

 

또한 문제에서 요구하는 것은 웹 요청 필터링이 아니라 네트워크 트래픽에 대한 딥 패킷 검사이므로 AWS Network Firewall이 적합하다.

• Transit Gateway: 다수 VPC를 중앙 집중식으로 연결
• VPC Peering: 두 VPC 간 직접 연결 (각각의 VPC 피어링 연결이 Amazon VPC 두 개만 연결할 수 있기 때문에 이 솔루션은 확장할 수 없다.)
• Network Firewall: 네트워크 트래픽 검사
• AWS WAF: 웹 애플리케이션 계층의 HTTP(S) 요청 필터링

다수 VPC + 중앙 라우팅은 Transit Gateway, 네트워크 레벨 검사는 Network Firewall로 역할을 분리한다.

 

9. Windows 공유 파일 스토리지와 Active Directory

[Windows + SMB + Active Directory + 공유 디렉터리 → FSx for Windows File Server]

회사가 Amazon EC2에서 다양한 프로덕션 애플리케이션을 실행하는 여러 Windows 파일 서버를 호스팅한다. 회사에서는 Amazon WorkSpaces도 사용한다. Solutions Architect가 스토리지 전략을 만들어야 한다. 스토리지 전략은 AWS에 데이터를 저장하는 사용자와 파일 서버를 위해 개인 파일과 공유 디렉터리를 중복 저장해야 한다. Solutions Architect는 솔루션을 회사의 기존 Active Directory와 통합하고자 한다.

 

[문제 요약]

회사는 AWS에서 Windows 파일 서버 여러 대를 쓰고 있고, 사용자들은 개인 파일 + 팀 공유 폴더를 사용하고 있다. 그리고 권한 관리는 이미 회사의 Active Directory(AD) 로 하고 있다.

-> 이 파일들을 AWS에서 안정적으로 저장하면서도 기존 AD 계정/그룹 권한을 그대로 쓰고 싶다.

 

C. Amazon FSx for Windows File Server를 사용하여 여러 네트워크 파일 공유를 만든다. 기존 Active Directory 사용자 및 그룹을 사용하여 공유를 관리한다. 기본 제공 유틸리티를 사용하여 공유를 탑재한다.

 

Key Point

이 문제는 일반적인 파일 저장이 아니라 Windows 사용자가 기존 AD 권한 체계를 유지하면서 네트워크 공유 폴더를 사용하는 환경을 요구한다.

Amazon FSx for Windows File Server는 Windows 기반 관리형 파일 스토리지로

• SMB 기반 파일 공유
• 기존 Active Directory 사용자/그룹으로 접근 권한 관리
• Windows EC2 및 WorkSpaces에서 네트워크 드라이브처럼 사용

이 가능하다.

비슷해 보이는 서비스와 비교하면

• EBS + DFS: 개별 EC2에 블록 스토리지를 붙이고 DFS까지 직접 운영해야 한다.
• S3 File Gateway: S3 객체 스토리지를 파일 프로토콜로 연결하는 게이트웨이 방식이다.
• EFS: NFS 중심의 파일 시스템으로 Windows 네이티브 파일 공유 요구와 맞지 않는다.
• FSx for Windows File Server: Windows, SMB, AD 요구를 직접 만족한다.

Windows + SMB + AD 조합이 보이면 FSx for Windows File Server를 우선 검토한다.

 

 

10. DynamoDB 읽기 지연 개선과 캐시 선택

[DynamoDB 읽기 지연 + 읽기 일관성 불필요 + 최소 운영 오버헤드 → DAX]

Solutions Architect가 REST API를 노출하기 위해 Amazon API Gateway 엔드포인트를 포함한 웹 애플리케이션 아키텍처를 설계 중이다. 이 Solutions Architect는 서비스를 처리하는 데는 AWS Lambda를, 데이터베이스에는 Amazon DynamoDB를 사용한다. 사용자가 데이터 로드 시간이 느리다고 보고하기 때문에, Solutions Architect는 애플리케이션의 지연 시간을 개선하고자 한다. 애플리케이션에는 읽기 일관성이 필요하지 않다.

 

다음 중 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇인가?

 

D. 테이블에서 DynamoDB Accelerator(DAX)를 사용 설정한다.

 

Key Point

DAX는 DynamoDB 읽기 성능 향상을 위해 제공되는 DynamoDB 전용 인메모리 캐시다. 문제에서 중요한 조건은 단순히 캐시를 사용할 수 있느냐가 아니라 최소한의 운영 오버헤드다.

ElastiCache를 사용하면 Redis 또는 Memcached 캐시 계층을 별도로 구성하고 애플리케이션에서 캐시 조회, 저장 흐름을 직접 다뤄야 한다.

 

예를 들어 Redis를 추가하면 구조는 다음과 같이 바뀐다.

Lambda -> ElastiCache(Redis) -> Cache Miss 시 DynamoDB

 

반면 DAX는 DynamoDB 가속을 목적으로 설계되어 기존 DynamoDB 기반 구조의 변경 부담을 상대적으로 줄일 수 있다.

• ElastiCache for Redis/Valkey: 범용 Redis 계열 캐시
• ElastiCache for Memcached: 범용 Memcached 캐시
• DAX: DynamoDB 전용 캐시

DynamoDB + 읽기 성능 개선 + 최소 관리가 함께 나오면 DAX를 먼저 검토한다.