본문 바로가기
AWS/SAA 준비

AWS SAA 합격으로 가는 길 #216

by Pacloud 2026. 10. 23.
반응형

 

안녕하세요! 넥스트클라우드의 테크니컬 트레이너 김서윤입니다. ❄️

오늘은 서리가 내리기 시작한다는 절기, 상강입니다! 이름처럼 아침 공기가 부쩍 차가워져 이불 밖으로 나오기가 쉽지 않은 계절인데요, 따뜻하게 챙겨 입으시고 금요일의 마지막 집중력을 모아 세 문제 함께 풀어 보시면 좋겠습니다. 오늘은 민감한 데이터에 특정 서비스만 접근하도록 막는 방법, 갑작스러운 CPU 급증에 대비하는 확장 전략, 그리고 인프라 변경 사항을 자동으로 추적하고 감사하는 방법을 다룹니다. 그럼 시작하겠습니다! 😊

 

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

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

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

3. 선택지 분석하기

 

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

문제1

한 회사가 AWS에서 새로운 애플리케이션을 개발하고 있습니다. 애플리케이션은 Amazon Elastic Container Service(Amazon ECS) 클러스터, 애플리케이션용 자산이 포함된 Amazon S3 버킷, 애플리케이션용 데이터 세트가 포함된 MySQL용 Amazon RDS 데이터베이스로 구성됩니다. 데이터 세트에는 민감한 정보가 포함되어 있습니다. 회사는 ECS 클러스터만 RDS for MySQL 데이터베이스의 데이터와 S3 버킷의 데이터에 액세스할 수 있도록 하려고 합니다.

 

어떤 솔루션이 이러한 요구 사항을 충족합니까?

 

선택지

A. 새로운 AWS Key Management Service(AWS KMS) 고객 관리형 키를 생성하여 S3 버킷과 RDS for MySQL 데이터베이스를 모두 암호화합니다. KMS 키 정책에 ECS 작업 실행 역할에 대한 암호화 및 암호 해독 권한이 포함되어 있는지 확인하십시오.

B. AWS KMS(AWS Key Management Service) AWS 관리형 키를 생성하여 S3 버킷과 RDS for MySQL 데이터베이스를 모두 암호화합니다. S3 버킷 정책이 ECS 작업 실행 역할을 사용자로 지정하는지 확인하세요.

C. 버킷 액세스를 ECS 작업 실행 역할로 제한하는 S3 버킷 정책을 생성합니다. MySQL용 Amazon RDS에 대한 VPC 엔드포인트를 생성합니다. ECS 클러스터가 작업을 생성할 서브넷에서만 액세스를 허용하도록 RDS for MySQL 보안 그룹을 업데이트합니다.

D. Amazon RDS for MySQL에 대한 VPC 엔드포인트를 생성합니다. ECS 클러스터가 작업을 생성할 서브넷에서만 액세스를 허용하도록 RDS for MySQL 보안 그룹을 업데이트합니다. Amazon S3용 VPC 엔드포인트를 생성합니다. S3 VPC 엔드포인트에서만 액세스를 허용하도록 S3 버킷 정책을 업데이트합니다.

풀이

데이터에 접근할 수 있는 경로 자체를 ECS 클러스터 쪽으로 좁히는 것이 핵심입니다. RDS 보안 그룹은 ECS 작업이 실행되는 서브넷에서 오는 연결만 허용하고, S3 버킷 정책은 VPC 엔드포인트를 거친 요청만 허용하면 두 데이터 저장소 모두 ECS 클러스터가 있는 네트워크에서만 접근할 수 있습니다.

 

정답 : D

 

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

더보기

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

  • 민감한 정보가 포함된 데이터 세트의 보호
  • ECS 클러스터만 RDS 데이터에 접근하도록 하는 제한
  • ECS 클러스터만 S3 버킷 데이터에 접근하도록 하는 제한

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

  • Amazon VPC(Virtual Private Cloud) : AWS 안에 논리적으로 격리된 사용자만의 가상 네트워크를 만드는 서비스입니다. 서브넷과 라우팅 테이블, 게이트웨이를 직접 구성해 리소스가 어떤 경로로 통신할지 정할 수 있고, 여러 보안 기능으로 트래픽을 세밀하게 제어할 수 있습니다. 네트워크 경로와 접근 허용 범위를 함께 설계하면 특정 리소스만 데이터에 접근하도록 만들 수 있습니다. 하나의 리전 안에서 여러 가용 영역(AZ)에 걸쳐 서브넷을 나누어 만들 수 있습니다.
    • VPC 엔드포인트 : 인터넷 게이트웨이나 NAT 장치를 거치지 않고 VPC 안에서 AWS 서비스에 비공개로 연결하는 기능입니다. Amazon S3와 Amazon DynamoDB는 라우팅 테이블에 경로를 추가하는 게이트웨이 엔드포인트를, 그 밖의 여러 서비스는 서브넷에 네트워크 인터페이스를 만드는 인터페이스 엔드포인트를 사용합니다.
    • 보안 그룹(Security Group) : 리소스에 연결해 허용할 인바운드와 아웃바운드 트래픽을 정하는 가상 방화벽입니다. 허용할 출발지를 특정 CIDR 범위나 다른 보안 그룹으로 지정해, 정해진 곳에서 오는 연결만 받아들이도록 할 수 있습니다.
  • Amazon S3(Simple Storage Service) : 데이터를 객체 단위로 저장하는 완전관리형 객체 스토리지 서비스입니다. 버킷과 객체는 기본적으로 비공개로 만들어지며, 버킷 정책과 IAM 정책으로 누가 어떤 조건에서 접근할 수 있는지를 세밀하게 정할 수 있습니다. 버킷 정책에는 요청자뿐 아니라 요청이 들어온 경로 같은 조건도 지정할 수 있어 네트워크 수준의 접근 제한에 활용됩니다. 정책은 명시적으로 거부한 내용이 허용보다 우선 적용됩니다.
    • 버킷 정책의 VPC 엔드포인트 조건 : 버킷 정책에 특정 VPC 엔드포인트를 조건으로 지정하면, 그 엔드포인트를 거쳐 들어온 요청만 허용하고 다른 경로의 요청은 거부할 수 있습니다.
  • Amazon RDS(Relational Database Service) : MySQL, PostgreSQL 같은 관계형 데이터베이스를 AWS가 대신 운영해 주는 관리형 데이터베이스 서비스입니다. DB 인스턴스는 VPC 안의 서브넷에 배치되고, 연결된 보안 그룹이 어떤 출발지에서 데이터베이스 포트로 접속할 수 있는지를 결정합니다. 그래서 데이터베이스에 접근할 수 있는 대상을 좁히려면 보안 그룹 규칙을 필요한 범위로만 열어 두는 것이 기본입니다.
  • AWS KMS(Key Management Service) : 데이터를 암호화하는 키를 만들고 관리하는 완전관리형 서비스입니다. 고객 관리형 키는 사용자가 직접 만들고 키 정책을 수정할 수 있으며, AWS 관리형 키는 각 서비스가 대신 만들어 관리하므로 사용자가 생성하거나 키 정책을 바꿀 수 없습니다. 저장 데이터 암호화는 디스크나 객체가 유출되었을 때를 대비하는 보호 수단으로, 정상적인 접속 경로로 들어온 요청을 막는 접근 제어와는 역할이 다릅니다.

3. 선택지 분석하기

A. 새로운 AWS Key Management Service(AWS KMS) 고객 관리형 키를 생성하여 S3 버킷과 RDS for MySQL 데이터베이스를 모두 암호화합니다. KMS 키 정책에 ECS 작업 실행 역할에 대한 암호화 및 암호 해독 권한이 포함되어 있는지 확인하십시오.

→ 저장 데이터 암호화만으로는 접속 대상을 제한하지 못합니다.

 

B. AWS KMS(AWS Key Management Service) AWS 관리형 키를 생성하여 S3 버킷과 RDS for MySQL 데이터베이스를 모두 암호화합니다. S3 버킷 정책이 ECS 작업 실행 역할을 사용자로 지정하는지 확인하세요.

→ AWS 관리형 키는 직접 생성·정책 조정이 불가하고 DB 접근 제한도 안 됩니다.

 

C. 버킷 액세스를 ECS 작업 실행 역할로 제한하는 S3 버킷 정책을 생성합니다. MySQL용 Amazon RDS에 대한 VPC 엔드포인트를 생성합니다. ECS 클러스터가 작업을 생성할 서브넷에서만 액세스를 허용하도록 RDS for MySQL 보안 그룹을 업데이트합니다.

→ 작업 실행 역할은 앱의 S3 접근 제한 기준으로 맞지 않습니다.

 

D. Amazon RDS for MySQL에 대한 VPC 엔드포인트를 생성합니다. ECS 클러스터가 작업을 생성할 서브넷에서만 액세스를 허용하도록 RDS for MySQL 보안 그룹을 업데이트합니다. Amazon S3용 VPC 엔드포인트를 생성합니다. S3 VPC 엔드포인트에서만 액세스를 허용하도록 S3 버킷 정책을 업데이트합니다.

→ 보안 그룹과 버킷 정책으로 접근 경로를 ECS 쪽으로 좁히는 표준 방식입니다.

 

이어서 다음 문제입니다.

문제2

회사에는 온프레미스에서 실행되는 웹 애플리케이션이 있습니다. 피크 시간 동안 애플리케이션에 대기 시간 문제가 발생합니다. 지연 문제는 매달 두 번씩 발생합니다. 대기 시간 문제가 시작되면 애플리케이션의 CPU 사용률이 즉시 정상 수치의 10배로 증가합니다. 회사는 지연 시간을 개선하기 위해 애플리케이션을 AWS로 마이그레이션하려고 합니다. 또한 회사는 애플리케이션 수요가 증가하면 애플리케이션을 자동으로 확장하려고 합니다. 회사는 애플리케이션 배포를 위해 AWS Elastic Beanstalk를 사용할 예정입니다.

 

어떤 솔루션이 이러한 요구 사항을 충족합니까?

 

선택지

A. 무제한 모드에서 성능 순간 확장이 가능한 인스턴스를 사용하도록 Elastic Beanstalk 환경을 구성합니다. 요청에 따라 확장되도록 환경을 구성합니다.

B. 컴퓨팅 최적화 인스턴스를 사용하도록 Elastic Beanstalk 환경을 구성합니다. 요청에 따라 확장되도록 환경을 구성합니다.

C. 컴퓨팅 최적화 인스턴스를 사용하도록 Elastic Beanstalk 환경을 구성합니다. 일정에 따라 확장되도록 환경을 구성합니다.

D. 무제한 모드에서 성능 순간 확장이 가능한 인스턴스를 사용하도록 Elastic Beanstalk 환경을 구성합니다. 예측 지표를 확장하도록 환경을 구성합니다.

풀이

CPU 사용률이 순식간에 10배로 뛰므로, 확장이 끝나기 전의 공백을 버틸 수단과 급증에 미리 대비하는 확장 방식이 함께 필요합니다. 무제한 모드의 버스트 가능 인스턴스는 갑작스러운 CPU 급증을 곧바로 받아 내고, 예측 조정은 과거 패턴을 바탕으로 수요가 늘기 전에 용량을 준비해 지연 시간을 줄여 줍니다.

 

정답 : D

 

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

더보기

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

  • 한 달에 두 번 CPU 사용률이 순간적으로 10배 증가하는 패턴
  • 피크 시간대의 지연 시간 개선
  • 수요 증가에 따른 자동 확장
  • AWS Elastic Beanstalk 기반 배포

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

  • AWS Elastic Beanstalk : 애플리케이션 코드만 올리면 실행에 필요한 인스턴스와 로드 밸런서, Auto Scaling 그룹 같은 인프라를 자동으로 구성해 주는 서비스입니다. 용량 조정, 상태 모니터링, 배포 관리 같은 운영 작업을 대신 처리해 주므로 개발자는 애플리케이션 개발에 집중할 수 있습니다. 환경 설정에서 인스턴스 유형과 확장 방식을 고를 수 있으며, 내부적으로는 Amazon EC2 Auto Scaling을 사용해 인스턴스 수를 조정합니다.
  • Amazon EC2(Elastic Compute Cloud) 인스턴스 유형 : Amazon EC2는 클라우드에서 가상 서버를 만들어 쓰는 컴퓨팅 서비스이며, 용도에 따라 CPU와 메모리 비율이 다른 여러 인스턴스 유형을 제공합니다. 워크로드의 평소 사용량과 순간적인 급증 정도를 함께 고려해 유형을 고르면 성능과 비용의 균형을 맞출 수 있습니다. 인스턴스 유형은 범용, 컴퓨팅 최적화, 메모리 최적화처럼 용도별 계열로 나뉘며, 같은 계열 안에서도 크기를 골라 성능을 조절할 수 있습니다.
    • 버스트 가능 성능 인스턴스 : T 계열처럼 평소에는 기준 수준의 CPU를 쓰다가 필요할 때 그 이상으로 순간 확장할 수 있는 인스턴스입니다. 무제한 모드를 사용하면 쌓아 둔 크레딧이 부족해도 높은 CPU 성능을 계속 낼 수 있으며, 기준을 넘어 사용한 만큼 추가 요금이 부과됩니다.
    • 컴퓨팅 최적화 인스턴스 : C 계열처럼 높은 CPU 성능을 꾸준히 제공하는 인스턴스로, 계산량이 일정하게 많은 작업에 적합합니다.
  • Amazon EC2 Auto Scaling : 조건에 따라 EC2 인스턴스 수를 자동으로 늘리거나 줄여 주는 서비스입니다. 여러 가용 영역(AZ)에 인스턴스를 분산하고 비정상 인스턴스를 교체해 가용성을 유지하며, 어떤 방식으로 확장할지를 정책으로 선택할 수 있습니다. 새 인스턴스가 준비되기까지는 시간이 걸리므로, 급격한 수요 증가에는 확장 방식의 선택이 중요합니다. 최소, 최대, 원하는 용량을 정해 두면 그 범위 안에서 인스턴스 수가 조정됩니다.
    • 동적 조정 : CPU 사용률이나 요청 수 같은 지표가 기준을 넘으면 그때 인스턴스를 늘리는 방식입니다. 수요 변화에 반응해 확장하므로, 급격한 증가에는 확장이 끝날 때까지 시간이 걸릴 수 있습니다.
    • 예약 조정 : 정해 둔 날짜와 시간에 맞춰 용량을 바꾸는 방식으로, 수요가 늘어나는 시점이 명확할 때 유용합니다.
    • 예측 조정 : 과거의 지표 기록을 분석해 앞으로의 수요를 예측하고, 수요가 늘기 전에 미리 용량을 확보하는 방식입니다. 반복되는 패턴이 있는 워크로드에서 확장 지연을 줄여 줍니다.

3. 선택지 분석하기

A. 무제한 모드에서 성능 순간 확장이 가능한 인스턴스를 사용하도록 Elastic Beanstalk 환경을 구성합니다. 요청에 따라 확장되도록 환경을 구성합니다.

→ 급증 후에야 확장이 시작되어 그 사이 지연이 생길 수 있습니다.

 

B. 컴퓨팅 최적화 인스턴스를 사용하도록 Elastic Beanstalk 환경을 구성합니다. 요청에 따라 확장되도록 환경을 구성합니다.

→ 평소 고성능 비용을 부담하면서도 급증 이후에야 확장됩니다.

 

C. 컴퓨팅 최적화 인스턴스를 사용하도록 Elastic Beanstalk 환경을 구성합니다. 일정에 따라 확장되도록 환경을 구성합니다.

→ 정해진 일정으로만 확장해 수요 기반 자동 확장이 되지 않습니다.

 

D. 무제한 모드에서 성능 순간 확장이 가능한 인스턴스를 사용하도록 Elastic Beanstalk 환경을 구성합니다. 예측 지표를 확장하도록 환경을 구성합니다.

→ 버스트로 급증을 받고 예측 조정으로 미리 용량을 확보하는 방식입니다.

 

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

문제3

회사는 전 세계에 고객을 두고 있습니다. 회사는 자동화를 사용하여 시스템과 네트워크 인프라를 보호하기를 원합니다. 회사의 보안 팀은 인프라에 대한 모든 증분 변경 사항을 추적하고 감사할 수 있어야 합니다.

 

어떤 솔루션이 이러한 요구 사항을 충족합니까?

 

선택지

A. AWS Organizations를 사용하여 인프라를 설정하십시오. AWS Config를 사용하여 변경 사항을 추적하세요.

B. AWS CloudFormation을 사용하여 인프라를 설정하십시오. AWS Config를 사용하여 변경 사항을 추적하세요.

C. AWS Organizations를 사용하여 인프라를 설정합니다. AWS Service Catalog를 사용하여 변경 사항을 추적합니다.

D. AWS CloudFormation을 사용하여 인프라를 설정하십시오. AWS Service Catalog를 사용하여 변경 사항을 추적합니다.

풀이

인프라를 자동으로 구성하는 수단과 구성 변경을 계속 기록하는 수단이 함께 필요합니다. AWS CloudFormation으로 인프라를 코드로 정의해 자동으로 배포하고, AWS Config로 리소스 구성의 변경 이력을 기록하면 보안 팀이 모든 증분 변경 사항을 추적하고 감사할 수 있습니다.

 

정답 : B

 

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

더보기

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

  • 자동화를 통한 시스템 및 네트워크 인프라 구성
  • 인프라에 대한 모든 증분 변경 사항의 추적
  • 보안 팀의 변경 이력 감사

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

  • AWS CloudFormation : 인프라를 코드로 정의해 자동으로 만들고 관리하는 서비스입니다. 필요한 리소스와 설정을 템플릿 파일에 적어 두면 CloudFormation이 순서에 맞게 리소스를 만들어 주고, 템플릿을 고치면 변경된 부분만 반영합니다. 같은 템플릿으로 여러 환경과 리전에 동일한 인프라를 반복해서 배포할 수 있어, 사람이 직접 설정하며 생기는 실수를 줄이고 일관된 보안 구성을 유지하는 데 도움이 됩니다.
  • AWS Config : AWS 리소스의 구성 상태를 계속 기록하고 평가하는 서비스입니다. 리소스가 언제 어떻게 바뀌었는지를 구성 항목으로 남겨 두므로, 특정 시점의 구성을 되짚어 보거나 변경 이력을 감사하는 데 활용할 수 있습니다. 규칙을 정해 두면 리소스가 사내 보안 기준을 지키고 있는지 자동으로 평가하고, 기준을 벗어난 리소스를 찾아 알려 줍니다. 여러 계정과 리전의 정보를 한곳에 모아 볼 수도 있습니다.
  • AWS Organizations : 여러 AWS 계정을 하나의 조직으로 묶어 중앙에서 관리하는 서비스입니다. 계정을 조직 단위로 나누어 관리하고, 서비스 제어 정책으로 회원 계정에서 사용할 수 있는 권한의 범위를 제한할 수 있습니다. 통합 결제도 제공해 여러 계정의 비용을 한곳에서 관리할 수 있지만, 계정을 관리하는 서비스이므로 개별 인프라 리소스를 만들어 주는 도구는 아닙니다. 새 계정도 조직 안에서 바로 만들 수 있습니다.
  • AWS Service Catalog : 조직에서 승인한 인프라 구성을 제품 형태로 등록해 두고, 사용자가 그 목록에서 골라 배포하도록 하는 서비스입니다. 관리자가 미리 검증한 템플릿만 사용하게 해 표준을 지키도록 돕고, 사용자에게는 셀프 서비스 방식의 배포 환경을 제공합니다. 배포할 수 있는 대상을 관리하는 데 목적이 있어, 리소스 구성의 세부 변경 이력을 기록하고 감사하는 용도와는 다릅니다. 제품은 버전별로 관리됩니다.

3. 선택지 분석하기

A. AWS Organizations를 사용하여 인프라를 설정하십시오. AWS Config를 사용하여 변경 사항을 추적하세요.

→ 계정 관리 서비스로는 인프라를 자동으로 구성할 수 없습니다.

 

B. AWS CloudFormation을 사용하여 인프라를 설정하십시오. AWS Config를 사용하여 변경 사항을 추적하세요.

→ 코드로 자동 배포하고 구성 변경 이력을 기록하는 표준 방식입니다.

 

C. AWS Organizations를 사용하여 인프라를 설정합니다. AWS Service Catalog를 사용하여 변경 사항을 추적합니다.

→ 자동 구성과 변경 이력 기록 모두를 충족하기 어렵습니다.

 

D. AWS CloudFormation을 사용하여 인프라를 설정하십시오. AWS Service Catalog를 사용하여 변경 사항을 추적합니다.

→ Service Catalog는 배포 관리용이라 변경 이력을 기록하지 않습니다.

 

오늘 세 문제는 "보호하고, 대비하고, 기록하는 것"으로 정리할 수 있습니다. 첫 번째 문제에서는 암호화와 접근 제어가 서로 다른 역할이라는 점을, 두 번째 문제에서는 동적·예약·예측 조정이 각각 어떤 상황에 맞는지를 비교해 두시면 좋겠습니다. 세 번째 문제처럼 구성 변경의 추적과 감사가 나오면 AWS Config를 가장 먼저 떠올려 보세요. 쌀쌀해진 주말, 따뜻하게 보내시고 월요일에 또 만나요! 😊

저작자표시 (새창열림)

'AWS > SAA 준비' 카테고리의 다른 글

AWS SAA 합격으로 가는 길 #217  (0) 2026.10.26
AWS SAA 합격으로 가는 길 #215  (0) 2026.10.19
AWS SAA 합격으로 가는 길 #214  (0) 2026.10.16
AWS SAA 합격으로 가는 길 #213  (0) 2026.10.12
AWS SAA 합격으로 가는 길 #212  (0) 2026.10.09

관련글

티스토리툴바