✅ 인프라 관리 부담 감소 (offload to AWS) ✅ 자동 확장 (Auto Scaling) ✅ 사용한 만큼만 과금 (Pay-per-Use) ✅ 빠른 개발 및 배포 속도
❌ 오답 해설
보기
내용
왜 틀렸는가
A. Application deployment and management are not required.
앱 배포 및 관리는 여전히 개발자의 역할
❌ 코드 배포는 여전히 필요함 (Lambda 함수 업로드 등)
B. Application security will be fully managed by AWS.
AWS는 인프라 보안만 책임짐
❌ 애플리케이션 보안은 여전히 고객 책임
C. Monitoring and logging are not needed.
서버리스에서도 CloudWatch 등으로 모니터링 가능
❌ 여전히 모니터링과 로깅 필요
🧠 핵심 개념 요약
구분
설명
관리 주체
인프라 → AWS, 코드 → 사용자
요금 모델
사용한 만큼(Pay-as-you-go)
확장성
자동 확장 (Auto Scaling 내장)
운영 부담
최소화 (No server provisioning)
📊 시각 요약 (Mermaid)
```mermaid
flowchart LR
A[👨💻 Developer] -->|Writes code only| B[⚙️ AWS Lambda]
B -->|Executes automatically| C[☁️ AWS Infrastructure]
C --> D[📈 Auto Scaling, Monitoring, Maintenance]
D --> E[✅ No Server Management Required]
```
📗 한 줄 요약
☁️ 서버리스의 가장 큰 장점은 인프라 관리가 필요 없다는 것! 개발자는 코드 실행과 비즈니스 로직에만 집중하면 됩니다.
📘 Q282.
Which of the following is the customer’s responsibility under the AWS shared responsibility model? (Choose two)
다음 중 AWS 공유 책임 모델에 따른 고객의 책임은 무엇입니까? (2개 선택)
✅ 정답: C, D
C. Maintain the configuration of guest operating systems and applications
D. Manage decisions involving encryption options
💡 정답 해설
AWS 공유 책임 모델에서는 보안(Security) 과 컴플라이언스(Compliance) 에 대해 AWS와 고객이 각각 나누어 책임을 집니다.
🔸 AWS의 책임 (Security of the Cloud)
“클라우드 자체의 보안”
항목
설명
인프라 보안
데이터센터, 서버, 스토리지, 네트워크 장비 등
물리적 보안
출입 통제, 전력, 냉각, 하드웨어 유지보수
가용성 관리
리전·AZ 관리, 하이퍼바이저 보안
🔹 고객의 책임 (Security in the Cloud)
“클라우드 내부의 보안”
항목
설명
게스트 OS 관리
패치, 보안 설정, 방화벽 규칙
애플리케이션 보안
접근 제어, 암호화 키 관리
데이터 암호화
서버 측/클라이언트 측 암호화 선택
네트워크 설정
VPC, 서브넷, 보안 그룹 구성
🧠 각 보기 해석 및 평가
보기
설명
정답 여부
A. Maintain the configuration of infrastructure devices
인프라 장비(서버, 네트워크 장치)는 AWS가 관리
❌
B. Maintain patching and updates within hardware infrastructure
하드웨어 패치는 AWS 책임
❌
C. Maintain the configuration of guest operating systems and applications
EC2 OS 설정, 보안 업데이트, 애플리케이션 구성은 고객 책임
✅
D. Manage decisions involving encryption options
어떤 암호화 방식(KMS, SSE, CSE)을 쓸지 결정하는 것은 고객 책임
✅
E. Maintain infrastructure hardware
물리적 장비 관리(서버, 스토리지)는 AWS 책임
❌
🧩 핵심 개념 정리표
구분
책임 주체
주요 예시
AWS 책임
Security of the Cloud
하드웨어, 데이터센터, 물리 보안
고객 책임
Security in the Cloud
OS 패치, 데이터 암호화, 접근 제어
📊 시각 요약 (Mermaid)
```mermaid
flowchart TD
A[☁️ AWS Responsibility] --> B[🔒 Data Center Security]
A --> C[🧱 Network Infrastructure Protection]
A --> D[🧰 Hardware Maintenance]
E[👩💻 Customer Responsibility] --> F[💾 OS & App Configuration]
E --> G[🔐 Encryption Management]
E --> H[🧑💼 Access Control & IAM Policies]
```
Which AWS services or features provide high availability and low latency by enabling failover across different AWS Regions? (Choose two)
다양한 AWS 리전에서 장애 조치를 활성화하여 고가용성과 짧은 지연 시간을 제공하는 AWS 서비스는 무엇입니까? (2개 선택)
✅ 정답
A. Amazon Route 53 D. AWS Global Accelerator
💡 정답 해설
선택지
설명
A. Amazon Route 53
글로벌 DNS 서비스로, 헬스 체크(Health Check) 기능을 통해 리전 간 Failover Routing이 가능합니다. 예를 들어 한 리전이 장애 시 자동으로 다른 리전으로 트래픽을 전환할 수 있습니다. 🌍
D. AWS Global Accelerator
AWS 글로벌 네트워크를 기반으로 사용자의 요청을 가장 가까운 엣지 로케이션(Edge Location) 으로 라우팅하여 지연 시간(Latency) 을 줄이고, 여러 리전에 걸쳐 고가용성을 제공합니다. 🚀
❌ 오답 해설
보기
설명
왜 틀렸는가
B. Network Load Balancer
단일 리전 내에서 동작하며, 리전 간 Failover 불가능
❌ 리전 간 트래픽 관리 불가
C. Amazon S3 Transfer Acceleration
S3 업로드 속도를 높이는 기능 (CloudFront Edge 사용)
❌ Failover 목적이 아님
E. Application Load Balancer
단일 리전 내의 여러 AZ(가용영역) 간 트래픽 분산
❌ Cross-Region 지원 불가
🌐 시각 요약 (Mermaid)
```mermaid
flowchart LR
subgraph Region1["🌏 AWS Region A"]
A1[EC2/ALB]
end
subgraph Region2["🌏 AWS Region B"]
A2[EC2/ALB]
end
user[👤 User] -->|DNS Failover| R53[🧭 Amazon Route 53]
R53 -->|Primary| A1
R53 -->|Failover| A2
user -->|Optimized Path| GA[🚀 AWS Global Accelerator]
GA --> A1
GA --> A2
```
📗 한 줄 요약
🌍 Route 53 = 장애 감지 후 리전 간 Failover ⚡ Global Accelerator = AWS 글로벌 네트워크를 통한 저지연 트래픽 전송
📘 Q209.
Which of the following is a way to use Amazon EC2 Auto Scaling groups to scale capacity in the AWS Cloud?
다음 중 Amazon EC2 Auto Scaling 그룹을 사용하여 AWS 클라우드에서 용량을 확장하는 방법은 무엇입니까?
✅ 정답: A. Scale the number of EC2 instances in or out automatically, based on demand.
💡 정답 해설
Amazon EC2 Auto Scaling은 워크로드 수요(Demand)에 따라 EC2 인스턴스의 개수를 자동으로 조절하는 서비스입니다. 이를 통해 비용 효율성과 가용성을 동시에 확보할 수 있습니다.
개념
설명
Scale Out
수요 증가 시 EC2 인스턴스 수를 자동으로 추가
Scale In
수요 감소 시 EC2 인스턴스 수를 자동으로 제거
정책 기반 스케일링 (Policy-based Scaling)
CloudWatch 지표(CPU, 메모리 등)에 따라 자동으로 트리거
예측 스케일링 (Predictive Scaling)
과거 트래픽 패턴을 학습해 향후 수요를 미리 예측
❌ 오답 해설
보기
설명
왜 틀렸는가
B. Use serverless EC2 instances.
EC2는 서버리스 아키텍처가 아님 (Lambda가 서버리스)
❌ 개념 오류
C. Scale the size of EC2 instances up or down automatically.
EC2 Auto Scaling은 “인스턴스 개수”를 조정, 크기(instance type) 변경은 수동 조정 필요
❌ 틀린 개념
D. Transfer unused CPU resources between EC2 instances.
A. Scale the number of EC2 instances in or out automatically, based on demand.
📗 한 줄 요약
🧩 EC2 Auto Scaling = 수요에 따라 EC2 인스턴스 “개수”를 자동으로 조정하여 가용성과 비용 효율을 극대화한다. 🚀
📘 Q226.
A company is hosting an application in the AWS Cloud. The company wants to verify that underlying AWS services and general AWS infrastructure are operating normally. Which combination of AWS services can the company use to gather the required information? (Choose two)
AWS 클라우드에서 애플리케이션을 운영 중인 회사가, AWS 인프라와 서비스가 정상적으로 동작 중인지 확인하려고 합니다. 어떤 AWS 서비스 조합을 사용해야 할까요? (2개 선택)
✅ 정답
A. AWS Personal Health Dashboard D. AWS Service Health Dashboard
```mermaid
flowchart TD
subgraph AWS["🌐 AWS Infrastructure"]
S1["🗺️ AWS Global Region Health\n(Service Health Dashboard)"]
S2["📢 Account-specific Health\n(Personal Health Dashboard)"]
end
user["👤 Cloud Administrator"]
user -->|🔍 상태 확인| S1
user -->|📩 개인화 알림| S2
```
📗 한 줄 요약
🔍 Service Health Dashboard → 전체 AWS 서비스의 공용 상태 확인 🧭 Personal Health Dashboard → 내 계정 리소스에 영향을 주는 이벤트 확인
📘 Q227.
A company needs to migrate a PostgreSQL database from on-premises to Amazon RDS. Which AWS service or tool should the company use to meet this requirement?
회사는 PostgreSQL 데이터베이스를 온프레미스에서 Amazon RDS로 마이그레이션해야 합니다. 이 요구 사항을 충족하기 위해 어떤 AWS 서비스를 사용해야 합니까?
✅ 정답: C. AWS Database Migration Service (AWS DMS)
💡 정답 해설
항목
설명
AWS DMS (Database Migration Service)
데이터베이스를 온프레미스 → AWS (RDS, Aurora, EC2 등) 으로 쉽고 빠르게 마이그레이션할 수 있도록 지원합니다.
지원 대상
Oracle, MySQL, PostgreSQL, MariaDB, SQL Server, MongoDB 등
특징
- 다운타임 최소화 - 실시간 데이터 복제 가능 - 동일 엔진 간 마이그레이션(예: PostgreSQL → PostgreSQL) 뿐만 아니라 이기종 간 마이그레이션(예: Oracle → Aurora PostgreSQL)도 가능
보조 도구
스키마가 다른 경우에는 AWS Schema Conversion Tool (SCT) 을 함께 사용하여 구조를 변환
❌ 오답 해설
보기
설명
왜 틀렸는가
A. Cloud Adoption Readiness Tool
클라우드 도입 준비 상태를 평가하는 설문형 도구
❌ 마이그레이션 수행용 아님
B. AWS Migration Hub
여러 마이그레이션 작업(DMS, Application Migration 등)의 진행 현황을 한 곳에서 추적하는 서비스
❌ 자체적으로 데이터 이동 불가
D. AWS Application Migration Service (MGN)
전체 서버(애플리케이션 포함) 를 클라우드로 이전할 때 사용
❌ DB만 옮길 때는 DMS가 적합
🧠 핵심 요약
구분
설명
서비스명
AWS Database Migration Service (DMS)
주요 용도
데이터베이스 이관 및 실시간 복제
장점
최소한의 다운타임으로 데이터 이전 가능
함께 사용하는 도구
AWS Schema Conversion Tool (SCT)
📊 시각 요약 (Mermaid)
flowchart LR A["🏢 On-premises<br>PostgreSQL DB"] -->|Data Migration| B["☁️ AWS DMS"] B --> C["🗄️ Amazon RDS for PostgreSQL"] note right of B:: "Minimal downtime\nContinuous data replication"
📗 한 줄 요약
🧩 AWS DMS = 온프레미스 DB를 AWS RDS나 Aurora로 마이그레이션할 때 사용하는 핵심 서비스 (다운타임 최소화 + 실시간 복제 지원)
📘 Q232.
What can a user accomplish using AWS CloudTrail?
사용자는 AWS CloudTrail을 사용하여 무엇을 수행할 수 있습니까?
✅ 정답: B. Record API calls made to AWS services.
AWS 서비스에 대한 모든 API 호출을 기록한다.
💡 정답 해설
항목
설명
AWS CloudTrail
AWS 계정 내에서 발생하는 모든 API 호출(Activity Logging) 을 추적하고 저장하는 서비스입니다.
기록 대상
콘솔, SDK, CLI, 서비스 간 통신 등 AWS API를 호출하는 모든 작업
로그 저장 위치
기본적으로 S3 버킷에 저장되며, CloudWatch Logs 또는 EventBridge 로도 연동 가능
주요 목적
🕵️♂️ 감사(Audit), 🧩 보안 분석(Security Analysis), ⚙️ 문제 해결(Troubleshooting)
예시 로그 항목
사용자 ID, 시간, 원본 IP, 호출된 서비스/액션(API), 요청 파라미터, 응답 코드 등
❌ 오답 해설
보기
설명
왜 틀렸는가
A. Generate an IAM user credentials report.
IAM 사용자 자격 보고서는 IAM 자체 기능
❌ CloudTrail은 IAM 리포트를 생성하지 않음
C. Assess the compliance of AWS resource configurations with policies and guidelines.
이는 AWS Config 의 기능 (규칙 기반 준수 검사)
❌ CloudTrail은 단순히 “기록(Log)”만 함
D. Ensure EC2 instances are patched with the latest security updates.
이는 AWS Systems Manager Patch Manager 기능
❌ CloudTrail은 패치 상태를 관리하지 않음
🧠 핵심 요약
항목
설명
서비스명
AWS CloudTrail
역할
AWS 계정 내 API 호출 이력 추적 및 저장
로그 저장 위치
Amazon S3, CloudWatch Logs, EventBridge
주요 용도
감사, 보안 모니터링, 운영 분석
📊 시각 요약 (Mermaid)
```mermaid
flowchart LR
A[👤 User or Service] -->|API Call| B[☁️ AWS CloudTrail]
B --> C[🗄️ S3 Bucket<br>Log Archive]
B --> D[📈 CloudWatch Logs<br>for Analysis]
B --> E[🚨 EventBridge<br>for Real-time Alerts]
```
📗 한 줄 요약
🧩 AWS CloudTrail = AWS API 호출 내역을 모두 기록하여 보안 감사 및 변경 추적을 가능하게 하는 서비스.
📘 Q233.
A company is planning to host its workloads on AWS. Which AWS service requires the company to update and patch the guest operating system?
한 회사가 AWS에서 워크로드를 호스팅하려고 합니다. 회사에서 게스트 운영체제(Guest OS) 를 업데이트하고 패치해야 하는 AWS 서비스는 무엇입니까?
✅ 정답: C. Amazon EC2
💡 정답 해설
항목
설명
Amazon EC2 (Elastic Compute Cloud)
EC2는 가상 서버(Instance)로, 고객이 운영체제(OS) 수준의 완전한 제어권을 가집니다.
책임 범위
AWS는 하이퍼바이저, 물리적 호스트, 네트워크 인프라를 관리하지만, 고객은 인스턴스 내부의 OS, 패치, 애플리케이션 보안 설정을 직접 관리해야 합니다.
즉, 고객 책임 항목
🔹 운영체제 패치 및 업데이트 🔹 방화벽 및 보안 그룹 설정 🔹 소프트웨어 및 라이브러리 관리
❌ 오답 해설
보기
설명
왜 오답인가
A. Amazon DynamoDB
완전관리형 NoSQL 데이터베이스 서비스
❌ AWS가 전체 인프라 및 OS를 관리함
B. Amazon S3
완전관리형 객체 스토리지 서비스
❌ 고객이 OS에 접근하거나 패치할 수 없음
D. Amazon Aurora
완전관리형 관계형 DB 서비스 (RDS 기반)
❌ 데이터베이스 엔진과 OS는 AWS가 자동 관리
🧠 핵심 개념 — Shared Responsibility Model
구분
AWS 책임
고객 책임
AWS
물리적 인프라, 하이퍼바이저, 네트워크, 스토리지, 보안 패치 관리
-
고객 (EC2 사용 시)
OS 업데이트, 패치, 방화벽 설정, 애플리케이션 보안
✅ 직접 수행 필요
📊 시각 요약 (Mermaid)
```mermaid
flowchart TD
subgraph AWS["☁️ AWS Responsibility"]
A1[🏗️ 하드웨어 관리]
A2[🧩 하이퍼바이저]
A3[🌐 네트워크 및 스토리지]
end
subgraph User["👤 Customer Responsibility (EC2)"]
B1[💻 OS 패치 및 업데이트]
B2[🛡️ 방화벽 및 보안 설정]
B3[📦 애플리케이션 관리]
end
```
📗 한 줄 요약
🧩 Amazon EC2는 고객이 게스트 OS를 직접 관리하고 패치해야 하는 서비스이다. (AWS는 인프라를, 고객은 인스턴스 내부 환경을 관리한다.)
📘 Q234.
Which AWS service or feature will search for and identify AWS resources that are shared externally?
외부에서 공유되는 AWS 리소스를 검색하고 식별하는 서비스 또는 기능은 무엇입니까?
✅ 정답: C. AWS IAM Access Analyzer
💡 정답 해설
항목
설명
AWS IAM Access Analyzer
AWS 계정 내 리소스(예: S3 버킷, KMS 키, IAM 역할 등)가 조직 외부(또는 다른 계정) 에 의해 접근 가능한지를 자동으로 분석하고 보고하는 서비스
핵심 기능
- 외부 공유 리소스 탐지 - 신뢰 정책(Trust Policy) 기반 분석 - 외부 계정, 퍼블릭 액세스, 교차 계정 공유 식별
지원 리소스 예시
S3, KMS, IAM Role, Lambda Layer, SQS, SNS 등
결과
“이 리소스가 외부 계정과 공유 중인지” 여부를 알려주며, 보안 감사 및 규정 준수(Compliance) 에 매우 중요함
❌ 오답 해설
보기
설명
왜 틀렸는가
A. Amazon OpenSearch Service
검색 및 로그 분석(Elasticsearch 기반) 서비스
❌ 보안 또는 접근 분석 기능 없음
B. AWS Control Tower
다계정 구조를 자동화해 거버넌스를 제공하는 서비스
❌ 리소스 외부 공유 탐지는 수행하지 않음
D. AWS Fargate
서버리스 컨테이너 실행 서비스
❌ 접근 제어 및 공유 탐지 기능 없음
🧠 핵심 요약
항목
내용
서비스명
AWS IAM Access Analyzer
기능
외부에 노출된 리소스 자동 탐지 및 보고
주요 대상
S3 버킷, KMS 키, IAM Role, Lambda Layer 등
활용 목적
보안 감사, 규정 준수, 데이터 유출 예방
📊 시각 요약 (Mermaid)
```mermaid
flowchart LR
A["🏢 내 AWS 계정"]
A -->|"🤝 Trust Policy"| B["🌍 외부 계정 또는 퍼블릭 접근"]
A --> C["🧠 IAM Access Analyzer"]
C -->|"🔍 Detection & Report"| D["📋 외부 공유 리소스 식별\n(S3, IAM Role, KMS 등)"]
```
💡 구성요소 설명
구성요소
설명
🏢 내 AWS 계정
AWS 리소스를 소유하고 있는 계정 (S3, IAM Role, KMS 등)
🤝 Trust Policy
외부 계정 또는 퍼블릭 접근 권한을 부여하는 정책
🧠 IAM Access Analyzer
외부 접근 가능한 리소스를 자동으로 분석
📋 리포트 결과
감지된 외부 공유 리소스를 목록화하고 보고
📗 한 줄 요약
🕵️♂️ IAM Access Analyzer는 외부 계정이나 퍼블릭에 공유된 AWS 리소스를 자동으로 탐지·보고하는 보안 분석 도구입니다.
📘 Q243.
Which maintenance task is the customer’s responsibility, according to the AWS shared responsibility model?
AWS 공유 책임 모델에 따르면 고객의 책임에 해당하는 유지 관리 작업은 무엇입니까?
✅ 정답: D. Amazon EC2 updates and security patches
💡 정답 해설
항목
설명
공유 책임 모델 (Shared Responsibility Model)
AWS와 고객 간의 보안 및 유지관리 책임을 명확히 구분하는 모델
AWS 책임 (Security of the Cloud)
물리적 인프라, 하드웨어, 네트워크, 하이퍼바이저 등 클라우드 자체의 보안 유지
고객 책임 (Security in the Cloud)
운영체제(OS) 관리, 애플리케이션 보안, IAM 설정, 데이터 암호화, 패치 관리 등
따라서 EC2 인스턴스 내의 OS 업데이트와 보안 패치는 고객이 수행해야 함
❌ 오답 해설
보기
설명
이유
A. Physical connectivity among Availability Zones
가용 영역 간 물리적 네트워크 연결
❌ AWS 책임 (물리 인프라 관리)
B. Network switch maintenance
스위치, 라우터 등 네트워크 장비 유지보수
❌ AWS 책임
C. Hardware updates and firmware patches
서버 및 하드웨어 펌웨어 업데이트
❌ AWS 책임
D. Amazon EC2 updates and security patches
EC2 내부의 운영체제 및 애플리케이션 패치
✅ 고객 책임
🧠 핵심 개념 요약
구분
AWS 책임 (of the Cloud)
고객 책임 (in the Cloud)
하드웨어, 데이터센터
✅
❌
네트워크, 하이퍼바이저
✅
❌
운영체제 (EC2 Guest OS)
❌
✅
애플리케이션 코드
❌
✅
IAM 정책 및 권한
❌
✅
데이터 암호화 설정
❌
✅
📊 시각 요약 (Mermaid)
```mermaid
flowchart LR
subgraph AWS["☁️ AWS Responsibility (of the Cloud)"]
A1[🏗️ 데이터센터 보안]
A2[🌐 네트워크 인프라]
A3[🧩 하이퍼바이저 및 하드웨어]
end
subgraph Customer["👤 Customer Responsibility (in the Cloud)"]
B1[💻 EC2 OS 업데이트 및 보안 패치]
B2[🛡️ IAM 및 권한 관리]
B3[🔐 데이터 암호화 및 접근 제어]
end
```
📗 한 줄 요약
☁️ AWS는 인프라를 책임지고, 👤 고객은 EC2 인스턴스 내 OS 및 애플리케이션의 보안 패치를 책임진다.
📘 Q246.
A company that has AWS Enterprise Support is launching a new version of a popular product in 2 months. The company expects a large increase in traffic to its website. The website is hosted on Amazon EC2 instances. Which action should the company take to assess its readiness to scale for this launch?
AWS Enterprise Support를 보유하고 있는 회사가 2개월 내 신제품 버전을 출시할 예정이며, 트래픽 급증에 대비해 확장 준비 상태를 평가해야 합니다. 어떤 조치를 취해야 할까요?
✅ 정답: B. Use AWS Infrastructure Event Management (IEM) support
💡 정답 해설
항목
설명
AWS Infrastructure Event Management (IEM)
AWS Enterprise Support 또는 Business Support 고객에게 제공되는 사전 준비 및 확장 지원 서비스입니다.
주요 기능
- 대규모 이벤트(런칭, 세일, 방송 등)에 대비한 아키텍처 검토 및 용량 계획 지원 - AWS 전문가와 협업하여 성능 테스트, 리스크 식별, 대응 계획 수립 - 트래픽 급증 시 안정적인 인프라 유지 보장
활용 시점
이벤트 1~2개월 전에 AWS Support에 요청하여 준비 시작
❌ 오답 해설
보기
설명
왜 틀렸는가
A. Replace the EC2 instances with AWS Lambda functions.
Lambda는 서버리스 아키텍처지만, 단순히 EC2를 교체하는 것은 확장성 준비가 아님
❌ 문제는 “사전 확장성 평가”이지 “서버리스 전환”이 아님
C. Submit a request on AWS Marketplace to monitor the event.
Marketplace는 서드파티 솔루션 구매 플랫폼
❌ AWS 모니터링 서비스 아님
D. Review the coverage reports in the AWS Cost Management console.
비용 및 예산 리포트용
❌ 성능 및 확장성 평가와 무관
🧠 핵심 개념 요약
구분
내용
서비스 이름
AWS Infrastructure Event Management (IEM)
제공 대상
Enterprise / Business Support 플랜 고객
주요 목적
대규모 이벤트를 위한 사전 아키텍처 검토 및 용량 계획
주요 지원
확장성 테스트, 장애 대응 시나리오, 전문가 협업
결과
안정적 확장 및 중단 없는 서비스 유지
📊 시각 요약 (Mermaid)
```mermaid
flowchart TD
A["🏢 Company (Enterprise Support)"]
--> B["📈 신제품 출시 & 트래픽 급증 예상"]
--> C["🤝 AWS Infrastructure Event Management (IEM)"]
--> D["🧠 아키텍처 검토 및 확장성 평가"]
--> E["✅ 안정적 서비스 운영 및 확장 보장"]
```
📗 한 줄 요약
🚀 AWS IEM은 대규모 이벤트(런칭, 세일, 캠페인 등)에 대비한 확장성 준비 및 아키텍처 검토를 제공하는 Enterprise Support 전용 서비스입니다.
📘 Q247.
A company wants to launch multiple workloads on AWS. Each workload is related to a different business unit. The company wants to separate and track costs for each business unit. Which solution will meet these requirements with the LEAST operational overhead?
회사가 여러 워크로드를 AWS에서 운영하려고 합니다. 각 워크로드는 서로 다른 사업부에 속해 있으며, 각 사업부별로 비용을 구분하고 추적하려고 합니다. 최소한의 운영 부담으로 이를 달성하려면 어떤 방법이 가장 좋을까요?
✅ 정답: A. Use AWS Organizations and create one account for each business unit.
💡 정답 해설
항목
설명
AWS Organizations
여러 AWS 계정을 중앙에서 관리하고 통합 청구(Consolidated Billing)를 제공하는 서비스
구현 방법
- 각 사업부별로 별도 AWS 계정 생성 - AWS Organizations를 통해 모든 계정을 연결 및 관리 - 비용은 각 계정별로 자동 분리되어 추적 가능
장점
- 운영 오버헤드 최소화 (자동 비용 분리) - 보안 및 권한 관리 용이 (Service Control Policy) - 비용 통합 결제로 할인 혜택(Volume Discount)까지 가능
결과
사업부별 비용 가시성 확보 + 중앙 집중 관리 + 자동화된 청구 구조 완성
❌ 오답 해설
보기
설명
왜 틀렸는가
B. Use a spreadsheet to control owners and cost.
엑셀 등 수동 방식으로 비용 관리
❌ 자동화 X, 오류 위험 높음
C. Use an Amazon DynamoDB table to record costs.
DynamoDB에 직접 비용 데이터 저장
❌ 수동 관리, 유지보수 비용 증가
D. Use AWS Billing console to assign owners.
AWS Billing 콘솔은 소유자 지정 기능 없음
❌ 계정 단위 구분 불가
🧠 핵심 개념 요약
항목
설명
서비스
AWS Organizations
핵심 기능
계정 통합 관리, 정책 제어, 비용 통합 청구
비용 추적 방식
계정 단위별 분리 추적 (Business Unit 단위 가능)
장점
자동화, 단순성, 확장성, 보안 관리 강화
📊 시각 요약 (Mermaid)
```mermaid
flowchart TD
A[🏢 Company] --> B[🧩 AWS Organizations]
B --> C1[💼 Account 1 - Marketing BU]
B --> C2[💼 Account 2 - Finance BU]
B --> C3[💼 Account 3 - R&D BU]
B --> D[💰 Consolidated Billing Dashboard]
```
📗 한 줄 요약
🧾 AWS Organizations를 사용해 사업부별로 계정을 분리하면, 자동으로 비용이 구분되고, 운영 오버헤드를 최소화할 수 있습니다.