AWS SAA 합격으로 가는 길 #190

안녕하세요! 넥스트클라우드의 테크니컬 트레이너 김유림입니다. 😊

7월도 어느새 중순으로 접어들었습니다! 🌦️ 후텁지근한 날씨에 집중이 흐트러지기 쉬운 시기죠.

그래도 시원한 곳을 이동하시어 차분히 문제를 풀다 보면 어느새 실력이 한 뼘 자라 있을 겁니다. 그럼 시작해 볼까요?

 

 

문제는 세 가지 단계를 거치며 풀어가겠습니다.

1. 문제의 요구사항 분석하기

2. 관련 AWS 서비스 생각하기

3. 선택지 분석하기

 

바로 문제 풀이 시작합니다.

---

문제1

한 회사는 수많은 애플리케이션이 액세스하는 Amazon S3 버킷에서 데이터 레이크를 관리합니다. S3 버킷에는 각 애플리케이션에 대한 고유한 접두사가 포함되어 있습니다. 회사는 각 애플리케이션을 특정 접두사로 제한하고 각 접두사 아래의 개체를 세부적으로 제어하기를 원합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

선택지

A. 각 애플리케이션에 대한 전용 S3 액세스 포인트 및 액세스 포인트 정책을 생성합니다.
B. S3 배치 작업 작업을 생성하여 S3 버킷의 각 객체에 대한 ACL 권한을 설정합니다.
C. S3 버킷의 객체를 각 애플리케이션의 새 S3 버킷에 복제합니다. 접두사별로 복제 규칙을 만듭니다.
D. S3 버킷의 객체를 각 애플리케이션의 새 S3 버킷에 복제합니다. 각 애플리케이션에 대한 전용 S3 액세스 포인트를 생성합니다.

 

---

풀이

하나의 공유 버킷에서 애플리케이션마다 특정 접두사로 접근을 제한하고 세부 권한을 부여하는 것이 핵심입니다. S3 액세스 포인트는 애플리케이션별 전용 진입점에 고유한 정책을 붙여 접두사 단위로 접근을 제어하는 관리형 기능이므로, 데이터 복제나 객체별 설정 없이 최소한의 운영 오버헤드로 요구 사항을 충족합니다.

 

정답 : A

 

▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.

---

1.  문제의 요구사항 분석하기

• 여러 애플리케이션이 함께 사용하는 단일 S3 데이터 레이크 버킷
• 애플리케이션마다 지정된 접두사로만 접근하도록 제한
• 각 접두사 아래 객체에 대한 세부적인 권한 제어
• 최소한의 운영 오버헤드로 구현

2. 관련 AWS 서비스 생각하기

• Amazon S3 (Simple Storage Service) : 객체를 버킷이라는 컨테이너에 저장하는 오브젝트 스토리지 서비스로, 높은 내구성과 확장성을 제공하여 대규모 데이터 저장소로 널리 활용됩니다. 버킷 안에서는 객체 이름 앞에 붙는 접두사(prefix)를 사용해 폴더처럼 데이터를 논리적으로 구분할 수 있으며, 접근 권한은 버킷 정책이나 IAM 정책 등으로 관리합니다.
• S3 액세스 포인트 (Access Point) : 하나의 S3 버킷에 대해 애플리케이션이나 사용자별로 별도의 진입점(엔드포인트)을 만들고, 각 진입점마다 고유한 액세스 정책을 연결할 수 있는 기능입니다. 진입점 정책에서 특정 접두사로 접근 범위를 제한할 수 있어, 하나의 버킷 정책이 지나치게 복잡해지는 것을 막고 애플리케이션별 권한을 독립적으로 세밀하게 제어할 수 있습니다. 별도의 데이터 이동이나 복제가 필요 없는 관리형 방식이라 운영 부담이 매우 적습니다.
• S3 ACL (Access Control List) : 버킷이나 개별 객체 단위로 접근 권한을 부여하는 오래된 방식의 접근 제어 수단입니다. 객체마다 권한을 지정해야 하므로 객체 수가 많을 경우 설정과 유지에 큰 부담이 따르며, 접두사 단위의 일괄적이고 세밀한 제어에는 적합하지 않은 편입니다.

3. 선택지 분석하기

A. 각 애플리케이션에 대한 전용 S3 액세스 포인트 및 액세스 포인트 정책을 생성합니다.
→ S3 액세스 포인트는 애플리케이션별 진입점에 접두사를 제한하는 정책을 연결하여 세부 접근 제어를 제공하는 관리형 기능이므로, 데이터 이동 없이 최소한의 운영 오버헤드로 요구 사항을 충족하기에 가장 적절한 방법입니다.

B. S3 배치 작업 작업을 생성하여 S3 버킷의 각 객체에 대한 ACL 권한을 설정합니다.
→ 객체마다 ACL을 설정하는 방식은 데이터 레이크처럼 객체 수가 방대한 환경에서 설정과 유지 관리에 큰 부담이 따르고, 이후 추가되는 객체마다 반복 작업이 필요하여 운영 오버헤드가 크기에 적절치 않습니다.

C. S3 버킷의 객체를 각 애플리케이션의 새 S3 버킷에 복제합니다. 접두사별로 복제 규칙을 만듭니다.
→ 애플리케이션마다 별도 버킷으로 데이터를 복제하면 저장 비용이 중복되고 원본과의 동기화를 계속 관리해야 하므로, 접근 제어만 필요한 상황에 비해 불필요한 운영 부담이 크기에 적절치 않습니다.

D. S3 버킷의 객체를 각 애플리케이션의 새 S3 버킷에 복제합니다. 각 애플리케이션에 대한 전용 S3 액세스 포인트를 생성합니다.
→ 액세스 포인트를 활용하는 점은 유효하지만, 굳이 데이터를 새 버킷으로 복제하는 과정이 더해져 저장 비용과 관리 부담이 늘어나므로 최소한의 운영 오버헤드라는 조건에는 부합하지 않습니다.

---

 

이어서 다음 문제입니다.

---

문제2

회사는 하이브리드 네트워크 아키텍처를 설계해야 합니다. 회사의 워크로드는 현재 AWS 클라우드와 온프레미스 데이터 센터에 저장되어 있습니다. 워크로드의 통신에는 한 자릿수 지연 시간이 필요합니다. 회사는 AWS Transit Gateway를 사용하여 여러 VPC를 연결합니다. 이러한 요구 사항을 가장 비용 효율적으로 충족하는 단계 조합은 무엇입니까? (2개를 선택하세요.)

 

선택지

A. 각 VPC에 대한 AWS Site-to-Site VPN 연결을 설정합니다.
B. AWS Direct Connect 게이트웨이를 VPC에 연결된 전송 게이트웨이와 연결합니다.
C. AWS Direct Connect 게이트웨이에 대한 AWS Site-to-Site VPN 연결을 설정합니다.
D. AWS Direct Connect 연결을 설정합니다. Direct Connect 게이트웨이에 대한 VIF(전송 가상 인터페이스)를 생성합니다.
E. AWS Site-to-Site VPN 연결을 VPC에 연결된 전송 게이트웨이와 연결합니다.

---

풀이

온프레미스와 여러 VPC 간 통신에 한 자릿수 밀리초의 낮은 지연 시간이 필요한 것이 핵심입니다. 인터넷을 거치지 않는 전용 회선인 Direct Connect를 설정하고, Direct Connect 게이트웨이를 Transit Gateway와 연결하면 여러 VPC를 안정적이고 낮은 지연으로 묶을 수 있어 요구 사항을 비용 효율적으로 충족합니다.

 

정답 : B, D

 

▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.

---

1.  문제의 요구사항 분석하기

• AWS 클라우드와 온프레미스를 잇는 하이브리드 네트워크
• 워크로드 통신에 한 자릿수 밀리초 수준의 낮은 지연 시간 필요
• Transit Gateway로 연결된 여러 VPC와의 통합
• 가장 비용 효율적인 구성

2. 관련 AWS 서비스 생각하기

• AWS Direct Connect : 온프레미스 데이터 센터와 AWS를 전용 물리 회선으로 직접 연결하는 서비스입니다. 공용 인터넷을 거치지 않기 때문에 지연 시간이 일관되게 낮고 대역폭이 안정적이며, 낮고 일관된 지연 시간이 요구되는 워크로드에 적합합니다. 초기 연결 구성이 필요하지만 대량의 트래픽을 지속적으로 주고받을 경우 인터넷 기반 연결보다 비용 효율이 높습니다.
• AWS Direct Connect 게이트웨이 (Direct Connect Gateway) : 여러 리전이나 여러 VPC를 하나의 Direct Connect 연결과 묶어주는 글로벌 리소스입니다. Transit Gateway와 연결하면, 온프레미스에서 하나의 전용 회선을 통해 Transit Gateway에 연결된 여러 VPC로 한 번에 통신할 수 있어 구성을 단순하게 유지할 수 있습니다.
• AWS Transit Gateway : 여러 VPC와 온프레미스 네트워크를 중앙 허브 방식으로 연결하는 라우터 역할의 서비스입니다. VPC마다 개별적으로 연결을 구성하지 않아도 되어, 네트워크가 늘어나도 관리가 단순합니다. Direct Connect 게이트웨이와 연결할 때는 전송 가상 인터페이스(Transit VIF)를 통해 전용 회선과 이어집니다.
• AWS Site-to-Site VPN : 온프레미스와 AWS를 공용 인터넷 위에 암호화된 터널을 만들어 연결하는 방식입니다. 빠르고 저렴하게 구성할 수 있다는 장점이 있지만, 인터넷 경로를 이용하므로 지연 시간과 성능이 일정하게 보장되지 않아 한 자릿수 밀리초 수준의 낮은 지연이 필요한 워크로드에는 적합하지 않습니다.

3. 선택지 분석하기

A. 각 VPC에 대한 AWS Site-to-Site VPN 연결을 설정합니다.
→ Site-to-Site VPN은 공용 인터넷을 경유하여 지연 시간이 일정하지 않고, VPC마다 개별 연결을 구성해야 해 관리 부담도 늘어나므로 한 자릿수 지연이 필요한 요구 사항에는 적절치 않습니다.

B. AWS Direct Connect 게이트웨이를 VPC에 연결된 전송 게이트웨이와 연결합니다.
→ Direct Connect 게이트웨이를 Transit Gateway와 연결하면 하나의 전용 회선으로 여러 VPC와 낮은 지연으로 통신할 수 있어, 전용 회선 구성과 함께 요구 사항을 충족하기에 가장 적절한 방법입니다.

C. AWS Direct Connect 게이트웨이에 대한 AWS Site-to-Site VPN 연결을 설정합니다.
→ Direct Connect 게이트웨이를 언급하고 있으나 실제 연결 수단이 인터넷 기반 VPN이므로, 낮고 일관된 지연 시간을 보장하기 어려워 요구 사항에 부합하지 않습니다.

D. AWS Direct Connect 연결을 설정합니다. Direct Connect 게이트웨이에 대한 VIF(전송 가상 인터페이스)를 생성합니다.
→ 전용 회선인 Direct Connect 연결을 설정하고 전송 가상 인터페이스로 Direct Connect 게이트웨이에 연결하면 낮은 지연의 안정적인 경로가 완성되므로, 요구 사항을 충족하기에 가장 적절한 방법입니다.

E. AWS Site-to-Site VPN 연결을 VPC에 연결된 전송 게이트웨이와 연결합니다.
→ Transit Gateway와의 연동 방식 자체는 유효하지만 연결 수단이 인터넷 기반 VPN이라 지연 시간이 일정하지 않으므로, 한 자릿수 지연이 필요한 조건에는 적절치 않습니다.

---

 

마지막 문제 살펴보겠습니다.

---

문제3

한 회사는 보안 위험을 초래하는 리소스에 대한 정책을 식별하고 시행하기 위해 IT 인프라 맵을 구축하려고 합니다. 회사의 보안팀은 IT 인프라 맵의 데이터를 쿼리하고 보안 위험을 신속하게 식별할 수 있어야 합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

선택지

A. Amazon RDS를 사용하여 데이터를 저장하십시오. SQL을 사용하여 데이터를 쿼리하여 보안 위험을 식별합니다.
B. Amazon Neptune을 사용하여 데이터를 저장합니다. SPARQL을 사용하여 데이터를 쿼리하여 보안 위험을 식별합니다.
C. Amazon Redshift를 사용하여 데이터를 저장하십시오. SQL을 사용하여 데이터를 쿼리하여 보안 위험을 식별합니다.
D. Amazon DynamoDB를 사용하여 데이터를 저장합니다. PartiQL을 사용하여 데이터를 쿼리하여 보안 위험을 식별합니다.

---

풀이

리소스 간의 연결 관계로 이루어진 IT 인프라 맵을 저장하고, 그 관계를 따라가며 보안 위험을 신속히 쿼리하는 것이 핵심입니다. 개체와 개체 사이의 관계 탐색에 특화된 완전관리형 그래프 데이터베이스인 Amazon Neptune이 이러한 관계형 데이터를 표현하고 질의하기에 가장 적합합니다.

 

정답 : B

 

▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.

---

1.  문제의 요구사항 분석하기

• 리소스 간 연결 관계로 구성된 IT 인프라 맵 구축
• 관계를 따라가며 보안 위험을 신속하게 쿼리
• 보안팀이 손쉽게 데이터를 조회할 수 있는 구조
• 최소한의 운영 오버헤드로 구현

2. 관련 AWS 서비스 생각하기

• Amazon Neptune : 개체(노드)와 개체 사이의 관계(엣지)를 저장하고 탐색하는 데 특화된 완전관리형 그래프 데이터베이스입니다. 리소스들이 서로 어떻게 연결되어 있는지를 자연스럽게 표현할 수 있어, 복잡하게 얽힌 관계 데이터를 다루고 "무엇이 무엇과 연결되어 있는가"를 따라가는 질의에 강점을 보입니다. 관계 탐색을 위한 그래프 질의 언어를 지원하며, 완전관리형이므로 인프라 운영 부담이 적습니다.
  
  • SPARQL : RDF(Resource Description Framework) 형식으로 저장된 그래프 데이터를 질의하기 위한 표준 언어로, 개체 사이의 관계를 조건으로 지정하여 원하는 연결을 탐색할 수 있습니다.
• Amazon RDS (Relational Database Service) : 행과 열로 이루어진 표 형태의 데이터를 다루는 완전관리형 관계형 데이터베이스로, SQL로 데이터를 조회합니다. 정형화된 데이터 관리에는 뛰어나지만, 여러 단계에 걸친 복잡한 관계를 따라가려면 반복적인 조인이 필요해 관계 중심의 탐색에는 효율이 떨어지는 편입니다.
• Amazon Redshift : 대규모 데이터를 대상으로 집계와 분석 쿼리를 빠르게 수행하도록 설계된 완전관리형 데이터 웨어하우스입니다. 방대한 데이터의 통계 분석에는 적합한 서비스입니다.
  Amazon DynamoDB : 키를 기반으로 데이터를 빠르게 조회하는 완전관리형 NoSQL 데이터베이스입니다. 단순 조회와 대규모 처리에 강점이 있습니다.

3. 선택지 분석하기

A. Amazon RDS를 사용하여 데이터를 저장하십시오. SQL을 사용하여 데이터를 쿼리하여 보안 위험을 식별합니다.
→ 관계형 데이터베이스는 여러 단계의 관계를 탐색할 때 복잡한 조인이 반복되어 성능과 표현력이 떨어지므로, 관계 중심의 인프라 맵 질의에는 적절치 않습니다.

B. Amazon Neptune을 사용하여 데이터를 저장합니다. SPARQL을 사용하여 데이터를 쿼리하여 보안 위험을 식별합니다.
→ Neptune은 리소스 간 관계를 그래프로 자연스럽게 표현하고 관계를 따라가는 질의에 최적화된 완전관리형 서비스이므로, 인프라 맵을 구축하고 보안 위험을 신속히 식별하기에 가장 적절한 방법입니다.

C. Amazon Redshift를 사용하여 데이터를 저장하십시오. SQL을 사용하여 데이터를 쿼리하여 보안 위험을 식별합니다.
→ Redshift는 대규모 데이터의 집계와 분석에 특화된 데이터 웨어하우스로, 개체 간 관계를 탐색하는 용도와는 성격이 맞지 않아 적절치 않습니다.

D. Amazon DynamoDB를 사용하여 데이터를 저장합니다. PartiQL을 사용하여 데이터를 쿼리하여 보안 위험을 식별합니다.
→ DynamoDB는 키 기반의 빠른 조회에 강점이 있으나 여러 단계로 얽힌 관계를 따라가는 탐색에는 부적합하므로, 관계 중심의 인프라 맵 질의에는 적절치 않습니다.

---

 

오늘 세 문제는 접근 제어, 하이브리드 네트워크, 그리고 데이터베이스 선택까지 폭넓은 주제를 아울렀습니다.

익숙하지 않은 서비스라 할지라도, 각 서비스가 선정되는 대표적인 키워드가 존재하니 공식처럼 기억해주시면 좋을 것 같습니다.

금요일에 뵙겠습니다 😊