AWS SAA 합격으로 가는 길 #194

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

어느덧 7월의 마지막 날, 금요일입니다! 이번 한 달도 성실히 달려오신 여러분, 정말 고생 많으셨습니다.

매일 조금씩 쌓아 온 노력이 어느새 합격이라는 결실로 이어질 거예요. 그럼 시작하겠습니다! 😊

 

 

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

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

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

3. 선택지 분석하기

 

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

---

문제1

AWS Organizations를 사용하는 회사는 30개의 서로 다른 AWS 계정에서 150개의 애플리케이션을 실행합니다. 회사는 AWS 비용 및 사용 보고서를 사용하여 마스터 계정에 새 보고서를 생성했습니다. 보고서는 데이터 수집 계정의 버킷에 복제된 Amazon S3 버킷으로 전달됩니다. 회사의 고위 경영진은 이번 달 초부터 매일 NAT 게이트웨이 비용을 제공하는 사용자 정의 대시보드를 확인하려고 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

 

선택지

A. 요청된 테이블 시각적 개체가 포함된 Amazon QuickSight 대시보드를 공유하십시오. AWS DataSync를 사용하여 새 보고서를 쿼리하도록 QuickSight를 구성합니다.
B. 요청된 테이블 시각적 개체가 포함된 Amazon QuickSight 대시보드를 공유합니다. Amazon Athena를 사용하여 새 보고서를 쿼리하도록 QuickSight를 구성합니다.
C. 요청된 테이블 시각적 개체가 포함된 Amazon CloudWatch 대시보드를 공유합니다. AWS DataSync를 사용하여 새 보고서를 쿼리하도록 CloudWatch를 구성합니다.
D. 요청된 테이블 시각적 개체가 포함된 Amazon CloudWatch 대시보드를 공유합니다. Amazon Athena를 사용하여 새 보고서를 쿼리하도록 CloudWatch를 구성합니다.

---

풀이

S3에 전달된 비용 및 사용 보고서(CUR)를 바탕으로 매일의 NAT 게이트웨이 비용을 보여주는 맞춤 대시보드를 만드는 것이 핵심입니다. Amazon Athena가 S3의 보고서를 표준 SQL로 쿼리하고 Amazon QuickSight가 그 결과를 표 형태 대시보드로 시각화해 공유하므로, 요구 사항을 가장 적절히 충족합니다.

 

정답 : B

 

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

---

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

• 마스터 계정에서 생성되어 S3 버킷으로 전달되는 비용 및 사용 보고서(CUR)
• 이번 달 초부터 매일의 NAT 게이트웨이 비용 확인
• 경영진이 열람하는 사용자 정의 대시보드 공유
• 원하는 표(테이블) 형태로 시각화

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

• AWS 비용 및 사용 보고서 (CUR, Cost and Usage Report) : 계정과 조직에서 발생한 비용과 사용량을 시간, 서비스, 리소스 단위로 가장 상세하게 제공하는 보고서입니다. 지정한 S3 버킷으로 주기적으로 전달되며, 내용이 방대하고 세밀하기 때문에 파일을 그대로 열어 보기보다 쿼리 도구와 연동해 원하는 항목만 뽑아 분석하는 방식으로 활용합니다.
• Amazon Athena : S3에 저장된 데이터를 표준 SQL로 직접 쿼리할 수 있는 서버리스 대화형 쿼리 서비스입니다. 별도의 서버나 클러스터를 구성할 필요 없이 S3에 놓인 CUR 같은 데이터를 곧바로 조회할 수 있으며, 실제 스캔한 데이터 양에 대해서만 요금이 부과되어 특정 비용 항목을 추려내는 분석에 적합합니다.
• Amazon QuickSight : 데이터를 표와 그래프 등 시각적 대시보드로 구성해 공유하는 완전관리형 BI(비즈니스 인텔리전스) 서비스입니다. Athena를 비롯한 다양한 데이터 소스에 연결해 대시보드를 만들 수 있어, 경영진이 원하는 형태의 비용 표를 구성하고 손쉽게 공유하는 데 적합합니다.
• AWS DataSync : 온프레미스 스토리지와 AWS 스토리지 사이에서 대량의 데이터를 빠르고 안전하게 옮기는 데이터 전송 서비스입니다. 데이터를 이동시키는 것이 목적이며, 저장된 보고서를 쿼리하거나 대시보드 데이터 소스로 조회하는 기능은 제공하지 않습니다.
• Amazon CloudWatch : AWS 리소스와 애플리케이션의 지표를 모니터링하고 대시보드로 표시하는 서비스입니다. 지표와 로그 기반 모니터링에 특화되어 있어, S3에 저장된 CUR 파일을 SQL로 쿼리해 원하는 표로 구성하고 공유하는 용도와는 성격이 다릅니다.

3. 선택지 분석하기

A. 요청된 테이블 시각적 개체가 포함된 Amazon QuickSight 대시보드를 공유하십시오. AWS DataSync를 사용하여 새 보고서를 쿼리하도록 QuickSight를 구성합니다.
→ QuickSight로 대시보드를 공유하는 방향은 맞지만 DataSync는 데이터를 옮기는 전송 도구일 뿐 보고서를 쿼리하는 기능이 없어 QuickSight의 데이터 소스로 삼기에 부적절하므로, 적절치 않습니다.

B. 요청된 테이블 시각적 개체가 포함된 Amazon QuickSight 대시보드를 공유합니다. Amazon Athena를 사용하여 새 보고서를 쿼리하도록 QuickSight를 구성합니다.
→ Athena가 S3의 CUR를 SQL로 쿼리하고 QuickSight가 그 결과를 표 형태 대시보드로 시각화해 공유하므로, 매일의 NAT 게이트웨이 비용을 맞춤 대시보드로 제공하기에 가장 적절한 방법입니다.

C. 요청된 테이블 시각적 개체가 포함된 Amazon CloudWatch 대시보드를 공유합니다. AWS DataSync를 사용하여 새 보고서를 쿼리하도록 CloudWatch를 구성합니다.
→ CloudWatch는 S3의 보고서를 쿼리하는 도구가 아니고 DataSync 역시 전송 전용이므로, 두 서비스 모두 요구되는 비용 대시보드 구성에는 맞지 않아 적절치 않습니다.

D. 요청된 테이블 시각적 개체가 포함된 Amazon CloudWatch 대시보드를 공유합니다. Amazon Athena를 사용하여 새 보고서를 쿼리하도록 CloudWatch를 구성합니다.
→ Athena로 보고서를 쿼리하는 점은 방향이 맞지만, CloudWatch 대시보드는 CloudWatch 지표를 표시하는 도구라 Athena 쿼리 결과를 데이터 소스로 받아 표로 구성하는 방식과는 맞지 않으므로, 이 조합으로는 요구되는 대시보드를 만들기 어렵습니다.

---

 

이어서 다음 문제입니다.

---

문제2

회사에는 AWS CloudFormation 스택이 명령문에 인라인 정책 또는 "*"를 포함하는 AWS Identity and Access Management(IAM) 리소스를 배포하지 못하도록 방지하는 솔루션이 필요합니다. 또한 솔루션은 퍼블릭 IP 주소를 사용하는 Amazon EC2 인스턴스 배포를 금지해야 합니다. 회사는 AWS Organizations의 조직에서 AWS Control Tower를 활성화했습니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

 

선택지

A. AWS Control Tower 사전 제어를 사용하여 퍼블릭 IP 주소 및 향상된 액세스 또는 "*"가 포함된 인라인 정책이 포함된 EC2 인스턴스 배포를 차단합니다.
B. AWS Control Tower 탐지 제어를 사용하여 퍼블릭 IP 주소 및 향상된 액세스 또는 "*"가 포함된 인라인 정책을 사용하여 EC2 인스턴스의 배포를 차단합니다.
C. AWS Config를 사용하여 EC2 및 IAM 규정 준수에 대한 규칙을 생성합니다. 규정을 준수하지 않는 리소스를 삭제하기 위해 AWS Systems Manager Session Manager 자동화를 실행하도록 규칙을 구성합니다.
D. 서비스 제어 정책(SCP)을 사용하여 조치로 인해 규정이 준수되지 않는 경우 EC2 인스턴스 및 IAM 리소스에 대한 조치를 차단합니다.

---

풀이

규정을 위반하는 IAM 리소스와 퍼블릭 IP EC2가 CloudFormation으로 배포되는 것 자체를 사전에 막는 것이 핵심입니다. AWS Control Tower 사전 제어는 리소스가 프로비저닝되기 전에 CloudFormation 템플릿을 검사해 위반 리소스의 배포를 차단하므로, 요구 사항을 가장 적절히 충족합니다.

 

정답 : A

 

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

---

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

• CloudFormation으로 배포되는 IAM 리소스에서 인라인 정책이나 "*" 사용 방지
• 퍼블릭 IP 주소를 사용하는 EC2 인스턴스 배포 금지
• 배포된 뒤 조치가 아니라 배포 자체를 사전에 예방
• 이미 활성화된 Control Tower 환경을 활용

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

• AWS Control Tower : 여러 AWS 계정을 모범 사례에 맞춰 설정하고 거버넌스를 적용하는 서비스입니다. 계정의 규정 준수를 강제하는 "제어(가드레일)"를 제공하며, 동작 시점과 방식에 따라 여러 유형으로 나뉩니다.
  
  • 사전 제어(Proactive control) : 리소스가 생성되기 전에 CloudFormation 템플릿을 검사하여, 규정을 위반하는 리소스가 프로비저닝되지 못하도록 배포 단계에서 차단합니다.
  • 탐지 제어(Detective control) : 이미 배포된 리소스가 규정을 준수하는지 AWS Config로 감지해 위반 여부를 보고합니다. 상태를 알려줄 뿐 배포 자체를 막지는 않습니다.
  • 예방 제어(Preventive control) : 서비스 제어 정책(SCP)을 기반으로 특정 작업(API) 자체를 허용하거나 거부합니다.
• 서비스 제어 정책 (SCP, Service Control Policy) : AWS Organizations에서 계정이 가질 수 있는 권한의 최대 한도를 정하는 정책입니다. 특정 API 작업을 조직 차원에서 거부할 수 있지만, CloudFormation 템플릿 속성 값처럼 리소스 구성의 세부 사항까지 세밀하게 검사하기는 어렵습니다.
• AWS Config : AWS 리소스의 구성 변경을 기록하고 규칙에 따라 준수 여부를 평가하는 서비스입니다. 이미 배포된 리소스의 규정 위반을 탐지하는 데 초점이 있어, 배포 이후의 사후 점검과 대응에 활용됩니다.

3. 선택지 분석하기

A. AWS Control Tower 사전 제어를 사용하여 퍼블릭 IP 주소 및 향상된 액세스 또는 "*"가 포함된 인라인 정책이 포함된 EC2 인스턴스 배포를 차단합니다.
→ 사전 제어는 리소스가 프로비저닝되기 전에 CloudFormation 템플릿을 검사해 위반 리소스의 배포를 원천 차단하므로, 배포 자체를 방지하려는 요구 사항에 가장 적절한 방법입니다.

B. AWS Control Tower 탐지 제어를 사용하여 퍼블릭 IP 주소 및 향상된 액세스 또는 "*"가 포함된 인라인 정책을 사용하여 EC2 인스턴스의 배포를 차단합니다.
→ 탐지 제어는 이미 배포된 리소스의 위반 여부를 감지해 보고할 뿐 배포 자체를 막지는 못하므로, 배포를 사전에 방지하려는 요구 사항에는 적절치 않습니다.

C. AWS Config를 사용하여 EC2 및 IAM 규정 준수에 대한 규칙을 생성합니다. 규정을 준수하지 않는 리소스를 삭제하기 위해 AWS Systems Manager Session Manager 자동화를 실행하도록 규칙을 구성합니다.
→ 리소스를 배포한 뒤에 탐지하고 삭제하는 사후 대응 방식이라 배포를 사전에 막지 못하고 구성도 복잡해지므로, 요구 사항에 적절치 않습니다.

D. 서비스 제어 정책(SCP)을 사용하여 조치로 인해 규정이 준수되지 않는 경우 EC2 인스턴스 및 IAM 리소스에 대한 조치를 차단합니다.
→ SCP는 특정 작업을 거부할 수 있으나 인라인 정책 포함 여부 같은 CloudFormation 리소스의 세부 속성까지 검사하기는 어려워, 요구 사항을 정확히 충족하기 어렵습니다.

---

 

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

---

문제3

회사에는 전 세계 20,000개 이상의 소매점 위치에 배포된 클라이언트에게 서비스를 제공하는 애플리케이션이 있습니다. 애플리케이션은 포트 443에서 HTTPS를 통해 노출되는 백엔드 웹 서비스로 구성됩니다. 애플리케이션은 ALB(Application Load Balancer) 뒤의 Amazon EC2 인스턴스에서 호스팅됩니다. 소매점은 공용 인터넷을 통해 웹 애플리케이션과 통신합니다. 회사는 각 소매점에서 현지 ISP가 할당한 IP 주소를 등록할 수 있도록 허용합니다. 회사 보안팀에서는 소매점에서 등록한 IP 주소로만 접속을 제한하여 애플리케이션 엔드포인트의 보안을 강화할 것을 권장합니다. 솔루션 설계자는 이러한 요구 사항을 충족하기 위해 무엇을 해야 합니까?

 

선택지

A. AWS WAF 웹 ACL을 ALB와 연결합니다. ALB의 IP 규칙 세트를 사용하여 트래픽을 필터링합니다. 등록된 IP 주소를 포함하도록 규칙의 IP 주소를 업데이트합니다.
B. AWS Firewall Manager를 배포하여 ALConfigure 방화벽 규칙을 관리하여 AL로의 트래픽을 제한합니다. 등록된 IP 주소를 포함하도록 방화벽 규칙을 수정합니다.
C. Amazon DynamoDB 테이블에 IP 주소를 저장합니다. ALB에서 AWS Lambda 인증 기능을 구성하여 수신 요청이 등록된 IP 주소에서 오는지 확인합니다.
D. ALB의 공용 인터페이스가 포함된 서브넷에서 네트워크 ACL을 구성합니다. 등록된 각 IP 주소에 대한 항목으로 네트워크 ACL의 수신 규칙을 업데이트합니다.

---

풀이

2만여 개 소매점이 등록한 IP 주소에서 오는 요청만 허용하도록 ALB 앞단에서 필터링하는 것이 핵심입니다. AWS WAF 웹 ACL을 ALB에 연결하고 IP 세트에 등록된 주소를 담아 필터링하면, 대규모 IP 목록도 유연하게 관리하며 허용 접근을 제한할 수 있어 가장 적절합니다.

 

정답 : A

 

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

---

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

• ALB 뒤 EC2에서 호스팅되는 HTTPS(443) 웹 애플리케이션
• 각 소매점이 등록한 IP 주소에서 오는 요청만 허용
• 2만여 개에 이르는 대규모 IP 허용 목록 관리
• 애플리케이션 엔드포인트의 보안 강화

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

• AWS WAF (Web Application Firewall) : ALB, CloudFront, API Gateway 같은 엔드포인트에 연결해 들어오는 HTTP(S) 요청을 규칙에 따라 허용하거나 차단하는 웹 애플리케이션 방화벽입니다. 규칙을 담은 웹 ACL(Access Control List)을 리소스에 연결하며, IP 세트(IP set)에 IP 주소나 대역을 등록해 특정 출처만 허용하도록 구성할 수 있습니다. IP 세트 하나에는 최대 1만 개의 항목을 담을 수 있고, 그 이상이 필요하면 여러 IP 세트와 규칙으로 나누어 관리하며 목록 갱신도 유연합니다.
• 네트워크 ACL (Network ACL) : 서브넷 경계에서 IP와 포트를 기준으로 인바운드·아웃바운드 트래픽을 제어하는 상태 비저장 방화벽입니다. 규칙 수에 제한이 있어(기본 20개, 최대 40개) 수천에서 수만 개에 이르는 IP 주소를 개별 항목으로 등록해 관리하기에는 적합하지 않습니다.
• AWS Firewall Manager : AWS Organizations 전반에서 WAF 규칙이나 보안 그룹 같은 방화벽 정책을 중앙에서 일괄 관리하는 서비스입니다. 여러 계정과 리소스에 정책을 배포하고 준수를 유지하는 역할에 가까우며, 단일 리소스의 트래픽을 직접 필터링하는 도구는 아닙니다.

3. 선택지 분석하기

A. AWS WAF 웹 ACL을 ALB와 연결합니다. ALB의 IP 규칙 세트를 사용하여 트래픽을 필터링합니다. 등록된 IP 주소를 포함하도록 규칙의 IP 주소를 업데이트합니다.
→ WAF 웹 ACL을 ALB에 연결하고 IP 세트에 등록된 주소만 허용하도록 갱신하면, 2만여 개에 이르는 IP도 여러 IP 세트로 나누어 유연하게 관리하며 접근을 제한할 수 있으므로, 엔드포인트 보안을 강화하기에 가장 적절한 방법입니다.

B. AWS Firewall Manager를 배포하여 ALConfigure 방화벽 규칙을 관리하여 AL로의 트래픽을 제한합니다. 등록된 IP 주소를 포함하도록 방화벽 규칙을 수정합니다.
→ Firewall Manager는 조직 차원에서 방화벽 정책을 중앙 관리하는 도구로, 단일 ALB의 IP 필터링을 직접 수행하는 용도로는 과하거나 직접적이지 않아 적절치 않습니다.

C. Amazon DynamoDB 테이블에 IP 주소를 저장합니다. ALB에서 AWS Lambda 인증 기능을 구성하여 수신 요청이 등록된 IP 주소에서 오는지 확인합니다.
→ 요청마다 Lambda로 IP를 조회해 검증하는 맞춤 구현은 개발과 운영 부담이 크고 지연도 늘어나며, ALB는 이러한 Lambda 인증 방식을 기본 지원하지도 않아 관리형 WAF보다 효율적이지 않습니다.

D. ALB의 공용 인터페이스가 포함된 서브넷에서 네트워크 ACL을 구성합니다. 등록된 각 IP 주소에 대한 항목으로 네트워크 ACL의 수신 규칙을 업데이트합니다.
→ 네트워크 ACL은 규칙 수 제한 때문에 2만여 개에 이르는 IP 주소를 개별 항목으로 등록할 수 없으므로, 대규모 허용 목록을 관리하려는 요구 사항을 충족하기 어렵습니다.

---

 

무더웠던 7월의 마지막 날, 한 달을 잘 마무리해 주셔서 고맙습니다. 

편안한 주말 보내시고 8월도 열심히 달려봅시다. 🏃