

안녕하세요! 넥스트클라우드의 테크니컬 트레이너 김서윤입니다. 🌻
금요일이에요! 다중 계정·네트워킹·거버넌스 주제로 세 문제 가볍게 풀어볼게요.
문제는 세 가지 단계를 거치며 풀어가겠습니다.
1. 문제의 요구사항 분석하기
2. 관련 AWS 서비스 생각하기
3. 선택지 분석하기
바로 문제 풀이 시작합니다.
문제1
회사는 각 워크로드에 대해 AWS 계정을 생성하여 워크로드를 격리하려고 합니다. 회사에는 워크로드에 대한 네트워킹 구성 요소를 중앙에서 관리하는 솔루션이 필요합니다. 또한 솔루션은 자동 보안 제어(가드레일)가 포함된 계정을 생성해야 합니다.
최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
선택지
A. AWS Control Tower를 사용하여 계정을 배포하십시오. 프라이빗 서브넷과 퍼블릭 서브넷이 있는 VPC가 있는 네트워킹 계정을 생성합니다. AWS Resource Access Manager(AWS RAM)를 사용하여 워크로드 계정과 서브넷을 공유합니다.
B. AWS Organizations를 사용하여 계정을 배포합니다. 프라이빗 서브넷과 퍼블릭 서브넷이 있는 VPC가 있는 네트워킹 계정을 만듭니다. AWS Resource Access Manager(AWS RAM)를 사용하여 워크로드 계정과 서브넷을 공유합니다.
C. AWS Control Tower를 사용하여 계정을 배포합니다. 각 워크로드 계정에 VPC를 배포합니다. 전송 게이트웨이 연결을 사용하여 검사 VPC를 통해 라우팅하도록 각 VPC를 구성합니다.
D. AWS Organizations를 사용하여 계정을 배포합니다. 각 워크로드 계정에 VPC를 배포합니다. 전송 게이트웨이 연결을 사용하여 검사 VPC를 통해 라우팅하도록 각 VPC를 구성합니다.
풀이
AWS Control Tower는 보안 가드레일이 자동 적용된 계정을 Account Factory로 생성합니다. 중앙 네트워킹 계정의 VPC 서브넷을 AWS RAM으로 워크로드 계정에 공유하면, 각 계정이 별도 VPC를 갖지 않아도 되어 운영 오버헤드가 가장 적습니다.
정답 : A
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 워크로드별 AWS 계정 격리.
- 네트워킹 구성 요소의 중앙 집중 관리.
- 자동 보안 제어(가드레일) 포함 계정 생성.
2. 관련 AWS 서비스 생각하기
- AWS Control Tower : 모범 사례 기반의 다중 계정 환경을 자동 구성하고 Account Factory로 새 계정 생성 시 가드레일(preventive/detective)을 자동 적용해 줍니다.
- AWS Resource Access Manager (RAM) : VPC 서브넷·Transit Gateway·라이선스 등 AWS 리소스를 계정 간에 공유할 수 있게 해주는 서비스로, 중앙 VPC 네트워킹 패턴에 핵심적으로 사용됩니다.
- AWS Organizations : 다중 계정 환경의 청구·정책을 중앙 관리하는 서비스로, Control Tower의 기반 인프라가 되지만 자체적으로 가드레일을 자동화하지는 않습니다.
- AWS Transit Gateway : 다중 VPC를 허브-스포크 형태로 연결하는 네트워크 트랜짓 허브입니다.
3. 선택지 분석하기
A. AWS Control Tower를 사용하여 계정을 배포하십시오. 프라이빗 서브넷과 퍼블릭 서브넷이 있는 VPC가 있는 네트워킹 계정을 생성합니다. AWS Resource Access Manager(AWS RAM)를 사용하여 워크로드 계정과 서브넷을 공유합니다.
→ Control Tower 가드레일 + RAM 중앙 네트워킹으로 운영 오버헤드를 최소화합니다.
B. AWS Organizations를 사용하여 계정을 배포합니다. 프라이빗 서브넷과 퍼블릭 서브넷이 있는 VPC가 있는 네트워킹 계정을 만듭니다. AWS Resource Access Manager(AWS RAM)를 사용하여 워크로드 계정과 서브넷을 공유합니다.
→ Organizations만으로는 가드레일 자동 적용이 어려워 추가 작업이 필요합니다.
C. AWS Control Tower를 사용하여 계정을 배포합니다. 각 워크로드 계정에 VPC를 배포합니다. 전송 게이트웨이 연결을 사용하여 검사 VPC를 통해 라우팅하도록 각 VPC를 구성합니다.
→ 계정마다 VPC를 두면 중앙 네트워킹 관리 요건과 거리가 있습니다.
D. AWS Organizations를 사용하여 계정을 배포합니다. 각 워크로드 계정에 VPC를 배포합니다. 전송 게이트웨이 연결을 사용하여 검사 VPC를 통해 라우팅하도록 각 VPC를 구성합니다.
→ 가드레일 자동화도 없고 VPC가 분산되어 운영 오버헤드가 큽니다.
이어서 다음 문제입니다.
문제2
회사는 퍼블릭 및 프라이빗 서브넷이 있는 VPC에서 애플리케이션을 실행합니다. VPC는 여러 가용 영역에 걸쳐 확장됩니다. 애플리케이션은 프라이빗 서브넷의 Amazon EC2 인스턴스에서 실행됩니다. 애플리케이션은 Amazon Simple Queue Service(Amazon SQS) 대기열을 사용합니다. 솔루션 설계자는 EC2 인스턴스와 SQS 대기열 간의 연결을 설정하기 위한 보안 솔루션을 설계해야 합니다.
이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
선택지
A. Amazon SQS용 인터페이스 VPC 엔드포인트를 구현합니다. 프라이빗 서브넷을 사용하도록 엔드포인트를 구성합니다. 프라이빗 서브넷에 있는 EC2 인스턴스의 트래픽을 허용하는 인바운드 액세스 규칙이 있는 보안 그룹을 엔드포인트에 추가합니다.
B. Amazon SQS용 인터페이스 VPC 엔드포인트를 구현합니다. 퍼블릭 서브넷을 사용하도록 엔드포인트를 구성합니다. 프라이빗 서브넷에 있는 EC2 인스턴스의 액세스를 허용하는 VPC 엔드포인트 정책을 인터페이스 엔드포인트에 연결합니다.
C. Amazon SQS용 인터페이스 VPC 엔드포인트를 구현합니다. 퍼블릭 서브넷을 사용하도록 엔드포인트를 구성합니다. 지정된 VPC 엔드포인트의 요청만 허용하는 인터페이스 VPC 엔드포인트에 Amazon SQS 액세스 정책을 연결합니다.
D. Amazon SQS용 게이트웨이 엔드포인트를 구현합니다. 프라이빗 서브넷에 NAT 게이트웨이를 추가합니다. SQS 대기열에 대한 액세스를 허용하는 EC2 인스턴스에 IAM 역할을 연결합니다.
풀이
Amazon SQS는 인터페이스 VPC 엔드포인트(AWS PrivateLink)만 지원하고 게이트웨이 엔드포인트는 제공하지 않습니다. 인터페이스 엔드포인트를 프라이빗 서브넷에 배치하고 EC2 인스턴스의 트래픽을 허용하는 보안 그룹을 적용하면 인터넷 노출 없이 SQS와 안전하게 통신할 수 있습니다.
정답 : A
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 프라이빗 서브넷 EC2 → SQS 비공개 연결.
- 인터넷 트래픽 노출 없이 안전한 접근 보장.
- 다중 AZ 환경에서 일관된 통신.
2. 관련 AWS 서비스 생각하기
- 인터페이스 VPC 엔드포인트(AWS PrivateLink) : ENI 형태로 VPC 서브넷에 배치되며, SQS·SNS·Secrets Manager 등 대부분의 AWS 서비스에 비공개로 접근할 수 있게 해줍니다. 보안 그룹으로 트래픽을 제어합니다.
- 게이트웨이 VPC 엔드포인트 : S3와 DynamoDB만 지원하는 라우팅 테이블 기반 엔드포인트로 SQS에는 사용할 수 없습니다.
- VPC 엔드포인트 정책 : 엔드포인트를 통해 어떤 작업·리소스에 접근할 수 있는지 제한하는 정책입니다.
- NAT 게이트웨이 : 프라이빗 서브넷에서 인터넷으로 나가는 통로를 제공하는 장치로 트래픽이 공용망을 거치게 됩니다.
3. 선택지 분석하기
A. Amazon SQS용 인터페이스 VPC 엔드포인트를 구현합니다. 프라이빗 서브넷을 사용하도록 엔드포인트를 구성합니다. 프라이빗 서브넷에 있는 EC2 인스턴스의 트래픽을 허용하는 인바운드 액세스 규칙이 있는 보안 그룹을 엔드포인트에 추가합니다.
→ 프라이빗 서브넷에 인터페이스 엔드포인트 + 보안 그룹으로 안전한 비공개 연결을 구성합니다.
B. Amazon SQS용 인터페이스 VPC 엔드포인트를 구현합니다. 퍼블릭 서브넷을 사용하도록 엔드포인트를 구성합니다. 프라이빗 서브넷에 있는 EC2 인스턴스의 액세스를 허용하는 VPC 엔드포인트 정책을 인터페이스 엔드포인트에 연결합니다.
→ 퍼블릭 서브넷 배치는 보안 요건에 맞지 않습니다.
C. Amazon SQS용 인터페이스 VPC 엔드포인트를 구현합니다. 퍼블릭 서브넷을 사용하도록 엔드포인트를 구성합니다. 지정된 VPC 엔드포인트의 요청만 허용하는 인터페이스 VPC 엔드포인트에 Amazon SQS 액세스 정책을 연결합니다.
→ 마찬가지로 퍼블릭 서브넷 배치는 비공개 통신 요구와 다릅니다.
D. Amazon SQS용 게이트웨이 엔드포인트를 구현합니다. 프라이빗 서브넷에 NAT 게이트웨이를 추가합니다. SQS 대기열에 대한 액세스를 허용하는 EC2 인스턴스에 IAM 역할을 연결합니다.
→ SQS는 게이트웨이 엔드포인트를 지원하지 않습니다.
마지막 문제 살펴보겠습니다.
문제3
개발 팀은 개발, 스테이징 및 프로덕션 환경에 여러 AWS 계정을 사용합니다. 팀원들은 활용도가 낮은 대규모 Amazon EC2 인스턴스를 출시해 왔습니다. 솔루션 아키텍트는 모든 계정에서 대규모 인스턴스가 시작되지 않도록 해야 합니다.
솔루션 설계자는 어떻게 최소한의 운영 오버헤드로 이 요구 사항을 충족할 수 있습니까?
선택지
A. 대규모 EC2 인스턴스의 시작을 거부하도록 IAM 정책을 업데이트하십시오. 모든 사용자에게 정책을 적용합니다.
B. AWS Resource Access Manager에서 대규모 EC2 인스턴스의 시작을 방지하는 리소스를 정의합니다.
C. 각 계정에 대규모 EC2 인스턴스의 시작을 거부하는 IAM 역할을 생성합니다. 개발자에게 IAM 그룹에 역할에 대한 액세스 권한을 부여합니다.
D. 기본 정책을 사용하여 마스터 계정의 AWS Organizations에 조직을 생성합니다. 대규모 EC2 인스턴스의 시작을 거부하는 서비스 제어 정책(SCP)을 생성하고 이를 AWS 계정에 적용합니다.
풀이
여러 계정에 일관된 제어를 적용하려면 AWS Organizations의 서비스 제어 정책(SCP)을 사용하는 것이 가장 효율적입니다. SCP는 조직 내 모든 계정·사용자가 수행할 수 있는 최대 권한을 제한하므로 ec2:RunInstances를 인스턴스 타입 조건으로 거부하면 대규모 인스턴스 시작을 원천 차단할 수 있습니다.
정답 : D
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 여러 AWS 계정에서 일관된 인스턴스 시작 제한.
- 활용도가 낮은 대규모 EC2 인스턴스 차단.
- 계정별 개별 설정 없이 운영 오버헤드 최소화.
2. 관련 AWS 서비스 생각하기
- AWS Organizations 서비스 제어 정책(SCP) : 조직 내 계정·OU 단위로 적용되는 권한 가드레일로, 특정 API 작업(예: ec2:RunInstances)을 조건과 함께 거부할 수 있어 다중 계정 환경의 중앙 통제에 사용됩니다.
- IAM 정책 : 사용자·그룹·역할에 적용되는 권한 정책으로, 각 계정에 개별 적용해야 하는 한계가 있어 다중 계정 전사 제어에는 비효율적입니다.
- AWS Resource Access Manager (RAM) : 리소스를 계정 간에 공유하는 서비스이며, 시작 권한 제어와는 무관합니다.
3. 선택지 분석하기
A. 대규모 EC2 인스턴스의 시작을 거부하도록 IAM 정책을 업데이트하십시오. 모든 사용자에게 정책을 적용합니다.
→ 계정마다 IAM 정책을 별도 관리해야 해 운영 부담이 큽니다.
B. AWS Resource Access Manager에서 대규모 EC2 인스턴스의 시작을 방지하는 리소스를 정의합니다.
→ RAM은 리소스 공유 서비스이며 권한 거부 기능이 없습니다.
C. 각 계정에 대규모 EC2 인스턴스의 시작을 거부하는 IAM 역할을 생성합니다. 개발자에게 IAM 그룹에 역할에 대한 액세스 권한을 부여합니다.
→ 역할로 차단해도 다른 IAM 자격증명으로 우회 가능해 완전한 차단이 어렵습니다.
D. 기본 정책을 사용하여 마스터 계정의 AWS Organizations에 조직을 생성합니다. 대규모 EC2 인스턴스의 시작을 거부하는 서비스 제어 정책(SCP)을 생성하고 이를 AWS 계정에 적용합니다.
→ SCP로 조직 전체에 한 번에 거부 정책을 적용해 운영 오버헤드를 최소화합니다.
오늘도 함께해 주셔서 감사합니다. 즐거운 주말 보내세요!
'AWS > SAA 준비' 카테고리의 다른 글
| AWS SAA 합격으로 가는 길 #189 (0) | 2026.07.10 |
|---|---|
| AWS SAA 합격으로 가는 길 #188 (0) | 2026.06.29 |
| AWS SAA 합격으로 가는 길 #186 (0) | 2026.06.22 |
| AWS SAA 합격으로 가는 길 #185 (1) | 2026.06.19 |
| AWS SAA 합격으로 가는 길 #184 (1) | 2026.06.15 |