본문 바로가기
AWS/SAA 준비

AWS SAA 합격으로 가는 길 #218

by Pacloud 2026. 10. 30.
반응형

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

10월의 마지막 금요일입니다! 거리마다 핼러윈 장식이 하나둘 보이고 내일이면 벌써 11월을 앞두게 되는데요, 이번 달도 꾸준히 함께해 주신 여러분께 감사한 마음을 담아 오늘의 세 문제를 준비했습니다. 오늘은 리전 밖에서 한 자릿수 밀리초의 지연 시간을 내는 방법, 여러 계정의 사용자 권한을 그룹 단위로 관리하는 방법, 그리고 EBS 볼륨 암호화 여부를 자동으로 점검하는 방법을 다룹니다. 그럼 시작하겠습니다! 😊

 

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

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

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

3. 선택지 분석하기

 

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

문제1

회사는 웹 애플리케이션을 온프레미스에서 AWS로 마이그레이션하려고 합니다. 이 회사는 eu-central-1 지역 근처에 위치하고 있습니다. 규정으로 인해 회사는 eu-central-1에서 일부 애플리케이션을 시작할 수 없습니다. 회사는 한 자릿수 밀리초의 지연 시간을 달성하려고 합니다.

 

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

 

선택지

A. eu-central-1에 애플리케이션을 배포합니다. 회사의 VPC를 eu-central-1에서 Amazon CloudFront의 엣지 위치로 확장합니다.

B. 회사의 VPC를 eu-central-1에서 선택한 로컬 영역으로 확장하여 AWS 로컬 영역에 애플리케이션을 배포합니다.

C. eu-central-1에 애플리케이션을 배포합니다. 회사의 VPC를 eu-central-1에서 Amazon CloudFront의 지역 엣지 캐시로 확장합니다.

D. 회사의 VPC를 eu-central-1에서 선택한 Wavelength Zone으로 확장하여 AWS Wavelength Zone에 애플리케이션을 배포합니다.

풀이

규정 때문에 리전 안에서는 애플리케이션을 실행할 수 없으면서, 사용자와 가까운 곳에서 한 자릿수 밀리초의 지연 시간을 내야 합니다. AWS 로컬 영역은 리전의 VPC를 확장해 대도시 가까이에 컴퓨팅 자원을 배치할 수 있는 인프라이므로, 리전 밖에서 애플리케이션을 실행하면서 낮은 지연 시간을 확보할 수 있습니다.

 

정답 : B

 

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

더보기

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

  • 규정으로 인해 eu-central-1 리전 안에서 실행할 수 없는 애플리케이션
  • 한 자릿수 밀리초 수준의 지연 시간 달성
  • 기존 VPC와 연결된 형태의 배포

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

  • AWS 로컬 영역(Local Zones) : 컴퓨팅, 스토리지, 데이터베이스 같은 AWS 서비스를 대도시나 산업 중심지 가까이에 배치한 인프라로, 상위 리전의 확장 형태로 운영됩니다. 리전의 VPC에 로컬 영역의 서브넷을 추가하는 방식으로 사용하므로 기존 네트워크 구성과 도구를 그대로 쓸 수 있습니다. 사용자와 물리적으로 가까운 곳에서 애플리케이션을 실행해 한 자릿수 밀리초의 지연 시간을 낼 수 있으며, 데이터를 특정 지역 안에 두어야 하는 요구에도 활용됩니다.
  • AWS Wavelength : 통신사의 5G 네트워크 안에 AWS 컴퓨팅과 스토리지 서비스를 배치한 인프라입니다. 모바일 기기에서 출발한 트래픽이 인터넷을 거치지 않고 통신사 네트워크 안에서 바로 애플리케이션에 닿기 때문에 매우 낮은 지연 시간을 낼 수 있습니다. 실시간 게임, 증강 현실, 자율 주행처럼 모바일 기기를 대상으로 하는 서비스에 맞춰져 있어, 일반적인 웹 애플리케이션을 특정 지역 가까이에 두는 용도와는 성격이 다릅니다.
  • Amazon CloudFront : 전 세계 엣지 로케이션에 콘텐츠를 캐싱해 사용자에게 빠르게 전달하는 콘텐츠 전송 네트워크(CDN, Content Delivery Network) 서비스입니다. 엣지 로케이션과 리전 사이에는 더 큰 캐시를 가진 리전별 엣지 캐시가 있어 원본 서버의 부담을 한 번 더 줄여 줍니다. 엣지 로케이션과 리전별 엣지 캐시는 콘텐츠를 캐싱하고 전달하는 시설이므로, VPC를 확장하거나 그 위에서 애플리케이션 서버를 실행할 수는 없습니다.

3. 선택지 분석하기

A. eu-central-1에 애플리케이션을 배포합니다. 회사의 VPC를 eu-central-1에서 Amazon CloudFront의 엣지 위치로 확장합니다.

→ 리전 배포 제약이 있고 CloudFront 엣지로는 VPC를 확장할 수 없습니다.

 

B. 회사의 VPC를 eu-central-1에서 선택한 로컬 영역으로 확장하여 AWS 로컬 영역에 애플리케이션을 배포합니다.

→ 로컬 영역으로 VPC를 확장해 리전 밖에서 낮은 지연을 내는 표준 방식입니다.

 

C. eu-central-1에 애플리케이션을 배포합니다. 회사의 VPC를 eu-central-1에서 Amazon CloudFront의 지역 엣지 캐시로 확장합니다.

→ 리전별 엣지 캐시는 캐싱 시설이라 VPC를 확장할 수 없습니다.

 

D. 회사의 VPC를 eu-central-1에서 선택한 Wavelength Zone으로 확장하여 AWS Wavelength Zone에 애플리케이션을 배포합니다.

→ 5G 모바일 대상 인프라라 일반 웹 애플리케이션 이전과는 맞지 않습니다.

 

이어서 다음 문제입니다.

문제2

회사는 AWS Organizations에서 AWS 계정을 관리합니다. AWS IAM Identity Center(AWS Single Sign-On) 및 AWS Control Tower가 계정에 대해 구성됩니다. 회사는 모든 계정에 걸쳐 여러 사용자 권한을 관리하려고 합니다. 권한은 여러 IAM 사용자가 사용하며 개발자 팀과 관리자 팀 간에 분배되어야 합니다. 각 팀에는 서로 다른 권한이 필요합니다. 회사는 두 팀 모두에 고용된 신규 사용자를 포함하는 솔루션을 원합니다.

 

최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

선택지

A. 각 계정에 대해 IAM Identity Center에서 개별 사용자를 생성합니다. IAM Identity Center에서 별도의 개발자 및 관리자 그룹을 생성합니다. 사용자를 적절한 그룹에 할당합니다. 세분화된 권한을 설정하려면 각 그룹에 대한 사용자 지정 IAM 정책을 생성하세요.

B. 각 계정에 대해 IAM ID 센터에서 개별 사용자를 생성합니다. IAM Identity Center에서 별도의 개발자 및 관리자 그룹을 생성합니다. 사용자를 적절한 그룹에 할당합니다. 세분화된 권한을 위해 필요에 따라 각 사용자에게 AWS 관리형 IAM 정책을 연결합니다.

C. IAM Identity Center에서 개별 사용자를 생성합니다. IAM Identity Center에서 새로운 개발자 및 관리자 그룹을 생성합니다. 각 그룹에 적합한 IAM 정책을 포함하는 새 권한 세트를 생성합니다. 적절한 계정에 새 그룹을 할당합니다. 새 그룹에 새 권한 집합을 할당합니다. 새로운 사용자가 고용되면 적절한 그룹에 추가하십시오.

D. IAM Identity Center에서 개별 사용자를 생성합니다. 각 사용자에 대한 적절한 IAM 정책을 포함하는 새 권한 세트를 생성합니다. 사용자를 적절한 계정에 할당합니다. 특정 계정 내에서 사용자에게 추가 IAM 권한을 부여합니다. 새로운 사용자가 고용되면 IAM Identity Center에 추가하고 계정에 할당합니다.

풀이

여러 계정에 걸친 권한을 팀 단위로 나누고, 새로 입사한 사용자에게도 손쉽게 권한을 줄 수 있어야 합니다. IAM Identity Center에서 팀별 그룹과 권한 세트를 만들어 계정에 할당해 두면, 신규 사용자는 그룹에 추가하기만 해도 필요한 모든 계정의 권한을 한 번에 받을 수 있어 운영 부담이 가장 적습니다.

 

정답 : C

 

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

더보기

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

  • 조직 내 모든 계정에 걸친 사용자 권한 관리
  • 개발자 팀과 관리자 팀에 서로 다른 권한 분배
  • 신규 사용자에 대한 손쉬운 권한 부여
  • 최소한의 운영 오버헤드

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

  • AWS IAM Identity Center(예전 명칭 AWS Single Sign-On) : 여러 AWS 계정과 애플리케이션에 대한 사용자 접근을 한곳에서 관리하는 서비스입니다. 사용자는 한 번 로그인해 자신에게 허용된 여러 계정에 접속할 수 있고, 관리자는 계정마다 사용자를 따로 만들 필요 없이 중앙에서 사용자와 그룹, 권한을 관리합니다. 자체 사용자 디렉터리를 쓰거나 기존의 외부 ID 공급자와 연동할 수 있습니다. AWS Organizations와 연동해 조직의 모든 계정을 대상으로 접근 권한을 할당할 수 있습니다.
    • 권한 세트(Permission Set) : 사용자나 그룹이 특정 계정에서 가질 권한을 IAM 정책으로 묶어 정의한 템플릿입니다. 권한 세트를 계정에 할당하면 그 계정에 해당 권한을 가진 역할이 자동으로 만들어지므로, 여러 계정의 권한을 일관되게 관리할 수 있습니다.
    • 그룹 : 같은 권한이 필요한 사용자를 묶는 단위입니다. 그룹에 계정과 권한 세트를 할당해 두면, 사용자를 그룹에 넣거나 빼는 것만으로 권한을 부여하거나 회수할 수 있습니다.
  • AWS Organizations : 여러 AWS 계정을 하나의 조직으로 묶어 중앙에서 관리하는 서비스입니다. 계정을 조직 단위로 나누어 정리하고, 서비스 제어 정책으로 회원 계정에서 사용할 수 있는 권한의 최대 범위를 정할 수 있습니다. 통합 결제로 모든 계정의 비용을 한곳에서 관리할 수 있으며, IAM Identity Center와 연동하면 조직의 모든 계정을 대상으로 사용자 접근을 관리할 수 있습니다.
  • AWS Control Tower : 모범 사례에 맞춘 여러 계정 환경을 자동으로 구성하고 관리해 주는 서비스입니다. AWS Organizations와 IAM Identity Center 같은 서비스를 바탕으로 기본 계정 구조와 보안 설정을 갖춘 랜딩 존을 만들어 주고, 가드레일이라 부르는 통제 규칙으로 계정들이 정책을 지키는지 점검합니다. 새 계정을 만들 때도 정해진 기준이 자동으로 적용되어 계정이 늘어나도 일관된 거버넌스를 유지할 수 있습니다.

3. 선택지 분석하기

A. 각 계정에 대해 IAM Identity Center에서 개별 사용자를 생성합니다. IAM Identity Center에서 별도의 개발자 및 관리자 그룹을 생성합니다. 사용자를 적절한 그룹에 할당합니다. 세분화된 권한을 설정하려면 각 그룹에 대한 사용자 지정 IAM 정책을 생성하세요.

→ 중앙에서 한 번 만들 사용자를 계정마다 만들어 관리 부담이 큽니다.

 

B. 각 계정에 대해 IAM ID 센터에서 개별 사용자를 생성합니다. IAM Identity Center에서 별도의 개발자 및 관리자 그룹을 생성합니다. 사용자를 적절한 그룹에 할당합니다. 세분화된 권한을 위해 필요에 따라 각 사용자에게 AWS 관리형 IAM 정책을 연결합니다.

→ 계정별 사용자와 사용자별 정책 연결로 운영 부담이 커집니다.

 

C. IAM Identity Center에서 개별 사용자를 생성합니다. IAM Identity Center에서 새로운 개발자 및 관리자 그룹을 생성합니다. 각 그룹에 적합한 IAM 정책을 포함하는 새 권한 세트를 생성합니다. 적절한 계정에 새 그룹을 할당합니다. 새 그룹에 새 권한 집합을 할당합니다. 새로운 사용자가 고용되면 적절한 그룹에 추가하십시오.

→ 팀별 그룹과 권한 세트로 신규 사용자도 그룹 추가만 하면 되는 표준 방식입니다.

 

D. IAM Identity Center에서 개별 사용자를 생성합니다. 각 사용자에 대한 적절한 IAM 정책을 포함하는 새 권한 세트를 생성합니다. 사용자를 적절한 계정에 할당합니다. 특정 계정 내에서 사용자에게 추가 IAM 권한을 부여합니다. 새로운 사용자가 고용되면 IAM Identity Center에 추가하고 계정에 할당합니다.

→ 사용자별 권한 세트와 계정별 권한 관리로 운영 부담이 큽니다.

 

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

문제3

한 회사에서 Amazon Elastic Block Store(Amazon EBS) 볼륨 암호화 전략을 표준화하려고 합니다. 또한 회사는 볼륨 암호화 검사를 수행하는 데 필요한 비용과 구성 노력을 최소화하려고 합니다.

 

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

 

선택지

A. EBS 볼륨을 설명하고 EBS 볼륨이 암호화되었는지 확인하는 API 호출을 작성합니다. Amazon EventBridge를 사용하여 API 호출을 실행하도록 AWS Lambda 함수를 예약합니다.

B. EBS 볼륨을 설명하고 EBS 볼륨이 암호화되었는지 확인하는 API 호출을 작성합니다. AWS Fargate 작업에서 API 호출을 실행합니다.

C. EBS 볼륨에서 태그를 사용해야 하는 AWS Identity and Access Management(IAM) 정책을 생성합니다. 적절하게 태그가 지정되지 않은 리소스를 표시하려면 AWS Cost Explorer를 사용하십시오. 태그가 지정되지 않은 리소스를 수동으로 암호화합니다.

D. Amazon EBS에 대한 AWS Config 규칙을 생성하여 볼륨이 암호화되었는지 평가하고 암호화되지 않은 경우 볼륨에 플래그를 지정합니다.

풀이

볼륨 암호화 여부를 직접 코드로 확인하는 대신, 이미 준비된 규칙으로 자동 평가하는 것이 구성 노력과 비용을 가장 줄이는 방법입니다. AWS Config의 관리형 규칙을 사용하면 EBS 볼륨의 암호화 여부를 계속 평가하고, 암호화되지 않은 볼륨을 규정 미준수로 표시해 한눈에 확인할 수 있습니다.

 

정답 : D

 

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

더보기

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

  • EBS 볼륨 암호화 전략의 표준화
  • 볼륨 암호화 여부의 지속적인 검사
  • 검사에 드는 비용과 구성 노력의 최소화

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

  • AWS Config : AWS 리소스의 구성 상태를 계속 기록하고, 정해 둔 규칙에 맞는지 자동으로 평가하는 서비스입니다. 리소스가 바뀔 때마다 변경 내용을 기록하므로 특정 시점의 구성을 되짚어 보거나 감사에 활용할 수 있습니다. AWS가 미리 만들어 둔 관리형 규칙을 고르기만 하면 바로 평가를 시작할 수 있고, 규칙을 벗어난 리소스는 규정 미준수로 표시되어 대시보드에서 바로 확인할 수 있습니다.
    • 관리형 규칙 : EBS 볼륨의 암호화 여부처럼 자주 쓰이는 점검 항목을 AWS가 미리 만들어 둔 규칙입니다. 코드를 작성하지 않고 몇 가지 설정만으로 사용할 수 있습니다.
  • Amazon EBS(Elastic Block Store) : Amazon EC2 인스턴스에 연결해 쓰는 블록 스토리지 서비스로, 운영체제와 애플리케이션 데이터를 저장하는 디스크 역할을 합니다. 볼륨 유형에 따라 성능과 단가가 달라지며, 필요에 따라 볼륨 크기와 성능을 운영 중에 조정할 수 있습니다. AWS KMS(Key Management Service) 키로 볼륨과 스냅샷을 암호화할 수 있고, 암호화와 복호화는 자동으로 처리되어 애플리케이션을 바꿀 필요가 없습니다.
    • 기본 암호화 : 리전 단위로 설정해 두면 그 리전에서 새로 만드는 모든 EBS 볼륨과 스냅샷이 자동으로 암호화되는 기능입니다. 이미 만들어진 암호화되지 않은 볼륨에는 적용되지 않습니다.
  • AWS Lambda : 서버를 관리하지 않고 코드를 실행하는 서버리스 컴퓨팅 서비스입니다. 이벤트가 발생하거나 정해진 일정이 되면 함수가 실행되고, 실행한 시간만큼만 요금이 부과됩니다. 원하는 점검 로직을 자유롭게 구현할 수 있지만, 코드 작성과 오류 처리, 결과 보고 방식까지 직접 만들고 유지해야 합니다. 요청량에 맞춰 자동으로 확장되므로 서버 용량을 미리 준비할 필요가 없고, Amazon EventBridge 같은 서비스와 연결해 주기적인 작업을 자동으로 실행할 수 있습니다.
  • Amazon EventBridge : AWS 서비스와 애플리케이션에서 발생하는 이벤트를 받아 규칙에 따라 다른 서비스로 전달하는 서버리스 이벤트 버스 서비스입니다. 특정 이벤트가 발생했을 때 작업을 실행하거나, 정해진 일정에 따라 AWS Lambda 함수 같은 대상을 주기적으로 호출할 수 있습니다. 여러 서비스를 느슨하게 연결해 이벤트 기반 자동화를 구성하는 데 널리 쓰입니다. 이벤트 패턴으로 필요한 이벤트만 골라 보낼 수 있습니다.

3. 선택지 분석하기

A. EBS 볼륨을 설명하고 EBS 볼륨이 암호화되었는지 확인하는 API 호출을 작성합니다. Amazon EventBridge를 사용하여 API 호출을 실행하도록 AWS Lambda 함수를 예약합니다.

→ 점검은 가능하지만 코드 작성·유지 부담이 있어 효율적이지 않습니다.

 

B. EBS 볼륨을 설명하고 EBS 볼륨이 암호화되었는지 확인하는 API 호출을 작성합니다. AWS Fargate 작업에서 API 호출을 실행합니다.

→ 코드에 컨테이너 구성과 실행 비용까지 더해져 최소화가 어렵습니다.

 

C. EBS 볼륨에서 태그를 사용해야 하는 AWS Identity and Access Management(IAM) 정책을 생성합니다. 적절하게 태그가 지정되지 않은 리소스를 표시하려면 AWS Cost Explorer를 사용하십시오. 태그가 지정되지 않은 리소스를 수동으로 암호화합니다.

→ 태그는 실제 암호화를 보장하지 않고 수동 작업도 많습니다.

 

D. Amazon EBS에 대한 AWS Config 규칙을 생성하여 볼륨이 암호화되었는지 평가하고 암호화되지 않은 경우 볼륨에 플래그를 지정합니다.

→ 관리형 규칙으로 코드 없이 암호화 여부를 계속 평가하는 표준 방식입니다.

 

오늘 세 문제와 함께 10월의 SAA 여정도 마무리되었습니다. 첫 번째 문제에서는 로컬 영역과 Wavelength, CloudFront 엣지의 차이를, 두 번째 문제에서는 IAM Identity Center의 그룹과 권한 세트를 묶어 쓰는 방식을 정리해 두시면 좋겠습니다. 세 번째 문제처럼 리소스가 기준을 지키는지 점검하는 문제가 나오면 AWS Config 규칙을 가장 먼저 떠올려 보세요. 한 달 동안 정말 수고 많으셨고, 11월에도 함께 달려 봐요! 😊

저작자표시 (새창열림)

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

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

관련글

티스토리툴바