AWS 20주년과 서울 리전 10주년 축하드립니다!
#awssummitseoul
#aws20
#ww12asia5

AWS 20주년과 서울 리전 10주년 축하드립니다!
#awssummitseoul
#aws20
#ww12asia5

| 유형 | 설명 | 예시 |
| 수직적 확장 (Vertical Scaling) | 서버의 성능을 향상 (CPU, RAM 업그레이드) | EC2 인스턴스 타입을 t3.micro → t3.large 로 변경 |
| 수평적 확장 (Horizontal Scaling) | 서버 개수를 늘리거나 줄임 | Auto Scaling Group에서 인스턴스 수 조절 |
💡 탄력성(Elasticity)
→ 수요 변화에 따라 자동으로 리소스를 확장/축소하는 능력
→ AWS Auto Scaling, EC2 Auto Scaling 활용
| 유형 | 설명 | 특징 |
| 🧩 EC2 | 가상 인스턴스 | 자유도 높지만 관리 필요 |
| 🐳 컨테이너(ECS / EKS) | 애플리케이션을 컨테이너로 패키징 | 관리형 클러스터, 이식성 우수 |
| ⚡ 서버리스(Lambda) | 서버 관리 불필요 | 짧은 실행, 이벤트 기반 |
💬 상황에 따라 선택:
| 서비스 | 유형 | 특징 |
| 💾 Amazon RDS | 관계형 DB | Multi-AZ로 고가용성 |
| ⚡ Amazon Aurora | 클라우드 네이티브 RDB | 고성능, 자동 복제 |
| 🌐 Amazon DynamoDB | NoSQL | 짧은 지연 시간, 자동 확장 |
| 🧮 Amazon Redshift | 데이터 웨어하우스 | 대규모 분석용 |
| 서비스 | 역할 | 특징 |
| 🌍 Amazon CloudFront | 글로벌 캐시 CDN | 정적 콘텐츠 전송 |
| 💾 Amazon ElastiCache | 인메모리 캐시 | Redis / Memcached 지원 |
| ⚙️ DAX (DynamoDB Accelerator) | DynamoDB 캐시 | 밀리초 응답 시간 |
💡 캐싱은 DB 읽기 부하를 줄이고 응답속도 향상에 핵심 역할
| 서비스 | 기능 | 사용 목적 |
| 🌎 Amazon Route 53 | DNS 라우팅 | 가용성 및 트래픽 제어 |
| ⚡ AWS Global Accelerator | TCP/UDP 전송 가속 | 글로벌 성능 최적화 |
| 📦 AWS Transfer Family | 파일 전송 자동화 | SFTP/FTPS 지원, 서버 관리 불필요 |
💬 이점
| 유형 | 설명 | 예시 |
| 동기식(Synchronous) | 요청-응답 구조로 실시간 상호작용 필요 | ALB → EC2, API Gateway → Lambda |
| 비동기식(Asynchronous) | 메시지 큐로 구성요소 간 분리 | SQS, SNS, EventBridge |
💡 비동기 분리는 장애 시에도 시스템의 나머지 부분이 정상 동작 가능
| 서비스 | 역할 | 설명 |
| 📬 Amazon SQS | 메시지 큐 | 컴포넌트 간 비동기 통신 |
| 🔔 Amazon SNS | 알림/이벤트 브로커 | Fan-out 구조 가능 |
| 🧩 Amazon EventBridge | 이벤트 버스 | 서비스 간 이벤트 기반 통합 |
| 🌀 API Gateway | 마이크로서비스 API 통신 허브 | Lambda, Fargate 등과 연결 |

| 핵심 요소 | 주요 포인트 |
| 확장성 (Scalability) | Auto Scaling, SQS, Lambda 동시성 |
| 느슨한 결합 (Loose Coupling) | SQS, SNS, EventBridge, ALB |
| 복원력 (Resilience) | Multi-AZ, Read Replica, 캐시, 장애 격리 |
| 비용 최적화 | Auto Scaling, 서버리스, S3 Intelligent-Tiering |
시스템이 가능한 한 자주 서비스를 **“제공할 수 있는 상태”**를 유지하도록 설계하는 것
장애 발생 시에도 서비스가 중단되지 않고 계속 작동하는 설계
예기치 않은 재해(화재, 지진, 시스템 장애) 발생 시 시스템 복원 절차를 설계하는 것
| 항목 | 설명 |
| 🕒 RTO (Recovery Time Objective) | 서비스 중단 후 복원까지 허용되는 최대 시간 |
| 📅 RPO (Recovery Point Objective) | 데이터 손실 허용 가능한 최대 시간 (백업 주기 결정) |
| 전략 | 설명 | 비용 | 복구 속도 |
| 🧊 백업 & 복원 (Backup & Restore) | S3/Glacier에 백업, 필요 시 복원 | 💲 낮음 | 🕒 느림 |
| 🔥 파일럿 라이트 (Pilot Light) | 최소 구성만 유지, 필요 시 전체 확장 | 💲 중간 | ⚡ 보통 |
| 🌡️ 웜 스탠바이 (Warm Standby) | 축소된 형태의 운영 환경 유지 | 💲 중상 | ⚡ 빠름 |
| 💡 액티브-액티브 (Active-Active) | 모든 리전에서 동시에 운영 | 💲 높음 | ⚡⚡ 매우 빠름 |
| 계층 | 설명 |
| 🌐 Region (리전) | 지리적으로 독립된 AWS 인프라 단위 |
| 🧭 Availability Zone (AZ) | 리전 내 독립 전력/네트워크를 가진 데이터센터 |
| 🧱 Edge Location | CloudFront, Route 53 캐시를 위한 전 세계 엣지 노드 |
💡 Multi-AZ 배포는 AZ 장애 시 자동으로 다른 AZ로 장애 조치
💡 Multi-Region 배포는 리전 전체 장애 시 복구 가능 (Active-Passive / Active-Active)
| 서비스 | 기능 | 특징 |
| 💾 Amazon RDS (Multi-AZ) | 자동 장애 조치 | 가용성 중심 |
| ⚡ Aurora Global Database | 교차 리전 복제 | 빠른 복구 (1분 미만) |
| 🌐 DynamoDB Global Tables | 리전 간 실시간 동기화 | 내결함성 보장 |
| 🧩 RDS Proxy | DB 연결 풀링 및 Failover 단축 | 장애 조치 시간 66% 단축 |
| 서비스 | 역할 | 특징 |
| 🧱 Amazon S3 | 백업 및 아카이브 | 11 9s(99.999999999%) 내구성 |
| 💾 Amazon EFS / FSx | 파일 스토리지 | AZ 간 중복 저장 |
| 🧊 S3 Glacier | 장기 보관 | 저비용 백업 |
| 🧩 AWS Elastic Disaster Recovery (DRS) | 온프레미스 ↔ 클라우드 복구 자동화 | 레거시 지원 |
| 서비스 | 역할 | 설명 |
| 🛰️ Route 53 | DNS 기반 장애 조치 라우팅 | 지연 시간 / 장애 조치 / 가중치 라우팅 지원 |
| ⚡ Global Accelerator | TCP/UDP 네트워크 성능 가속 | 글로벌 사용자 연결 최적화 |
| 🔀 Transit Gateway | 여러 VPC 간 중앙 라우팅 허브 | 단일 장애 지점 제거 |
| 🔗 Direct Connect / VPN | 온프레미스 연결 | 고속, 안정적 네트워크 통신 |
| 서비스 | 기능 |
| 🌱 AWS CloudFormation | 인프라 자동 복구 및 프로비저닝 |
| ☁️ Elastic Beanstalk | 애플리케이션 자동 배포 및 확장 |
| 🐳 ECS / EKS (컨테이너) | 고가용성 컨테이너 오케스트레이션 |
| 🔄 OpsWorks / CodeDeploy | 구성 관리 및 자동 롤백 |
| 서비스 | 역할 |
| 👁️ Amazon CloudWatch | 지표 수집, 알람, 자동화 트리거 |
| 🔍 AWS X-Ray | 애플리케이션 요청 추적 (분산 추적) |
| 🧠 Amazon Inspector | 취약점 스캔 및 보안 진단 |
| 🤖 Amazon CodeGuru | 코드 품질 분석 및 성능 개선 |
| 🧩 Amazon EventBridge | 실시간 이벤트 기반 자동 대응 |
| 서비스 | 역할 | 사용 예시 |
| 🗣️ Amazon Polly | 텍스트 → 음성 변환 | 고객센터, 셀프 서비스 음성 안내 |
| 🧠 Amazon Comprehend | 자연어 분석 | IT 서비스 요청 자동 분류 |
💡 예시: Comprehend로 요청 카테고리 자동 분류 → Polly가 음성으로 안내 → Connect가 셀프 서비스 제공

| 항목 | 설명 |
| 고가용성(HA) | 장애 발생 시 빠르게 복구하는 시스템 |
| 내결함성(FT) | 장애 발생 중에도 중단 없이 작동 |
| 재해 복구(DR) | 대규모 장애 후 신속한 복원 전략 |
| RTO/RPO | 복구 목표 시간 및 데이터 손실 허용치 |
| 대표 서비스 | RDS Multi-AZ, Aurora Global DB, Route 53, Global Accelerator, DRS, CloudFormation |
고가용성과 내결함성은 AWS Well-Architected Framework의 “신뢰성(Reliability)” 핵심 원칙입니다.
아키텍처 설계 시 다음 3가지를 항상 체크하세요.
1️⃣ 단일 장애 지점 제거 (SPOF)
2️⃣ Multi-AZ / Multi-Region 설계
3️⃣ 자동화된 복구 프로세스 구성
| 항목 | 설명 |
| 🧠 용량 추측 불필요 | 필요한 만큼 자동 확장 / 축소 |
| 💰 비용 효율성 | 사용한 만큼만 지불 (Pay-as-you-go) |
| ⚙️ 자동화된 확장성 | Auto Scaling / Elastic Load Balancing |
| 🌎 글로벌 인프라 | 다중 AZ & 다중 리전 기반 복원력 |
| 구분 | 고가용성 (High Availability) | 내결함성 (Fault Tolerance) |
| 🧱 정의 | 장애 발생 시 빠르게 복구하여 서비스 지속 | 장애 발생 중에도 시스템이 중단 없이 동작 |
| ⏱ 중단 시간 | 약간의 중단 허용 | 무중단 (Zero downtime) |
| 💰 비용 | 중간 | 높음 |
| ⚙️ 예시 | Multi-AZ RDS, Auto Scaling, ALB | Active-Active Aurora Global DB |
| 계층 | 설명 |
| 🌐 Region | 지리적으로 분리된 AWS 데이터센터 그룹 |
| 🏢 Availability Zone (AZ) | 독립된 전원·네트워크를 가진 가용 단위 |
| 📍 Edge Location | CloudFront, Route 53 등 엣지 네트워크 |
💡 Multi-AZ + Multi-Region 설계는
서버, 스토리지, DB 장애에도 중단 없는 서비스를 제공하도록 돕습니다.
| 서비스 | 역할 |
| ⚖️ Elastic Load Balancing (ELB) | 여러 인스턴스 간 트래픽 분산 및 장애 감지 |
| 📈 Amazon EC2 Auto Scaling | 인스턴스 자동 추가/제거, 비정상 인스턴스 교체 |
| 🛰️ Route 53 (Failover Routing) | 리전 단위 장애 발생 시 다른 리전으로 트래픽 전환 |
| 🌍 AWS Global Accelerator | TCP/UDP 트래픽 지연 최소화 및 글로벌 복원력 향상 |
| 전략 | 설명 | 비용 💰 | 복구 속도 ⚡ |
| 🧊 백업 & 복원 | S3, Glacier에 백업 후 필요 시 복원 | 낮음 | 느림 |
| 🔥 파일럿 라이트 | 핵심 구성만 유지 후 필요 시 확장 | 중간 | 보통 |
| 🌡️ 웜 스탠바이 | 축소된 프로덕션 환경 유지 | 중상 | 빠름 |
| 💡 액티브-액티브 | 모든 리전 동시 운영 | 높음 | 매우 빠름 |
💡 RTO(복구시간목표) & RPO(복구시점목표)를 기준으로 선택해야 함.
| 서비스 | 내장 복원력 기능 | 사용 예시 |
| 💻 EC2 Auto Scaling | 인스턴스 자동 교체 / 증감 | 트래픽 급증 시 수평 확장 |
| ⚖️ Elastic Load Balancer | 트래픽 자동 분산 | 웹 서버 장애 시 자동 우회 |
| 🧾 RDS Multi-AZ | 자동 장애 조치(Failover) | DB 가용성 확보 |
| ⚡ Aurora Global DB | 교차 리전 복제 | 리전 장애 대비 |
| 📬 SQS / SNS / EventBridge | 비동기 메시징 | 서비스 간 결합도 최소화 |
| 🐳 ECS / Fargate | 자동 리스타트, 헬스체크 | 컨테이너 복원력 |
| 🧠 Lambda | 서버리스 확장성 | 짧은 처리 이벤트 기반 애플리케이션 |
| 유형 | 설명 | 예시 |
| ⚙️ Stateless (비상태) | 인스턴스 교체 시 데이터 의존 없음 | 웹 서버, Lambda 함수 |
| 💾 Stateful (상태 유지) | 인스턴스에 데이터 저장 | RDS, EFS, 세션 유지 |
💡 Stateless 아키텍처는 확장성과 복원력 측면에서 유리
💡 Stateful 컨테이너는 EFS, FSx 등 외부 스토리지 연결로 해결 가능
| 서비스 | 역할 | 특징 |
| 🧠 Amazon ElastiCache (Redis/Memcached) | 데이터 캐싱 | DB 쿼리 부하 감소 |
| ⚡ DynamoDB Accelerator (DAX) | NoSQL 캐시 | 밀리초 응답 시간 |
| 🧩 RDS Read Replica | 읽기 부하 분산 | 읽기 성능 향상 (복제 기반) |
💡 캐싱은 지연 시간 단축 + 비용 절감 + DB 부하 감소의 핵심 전략
| 서비스 | 기능 | 설명 |
| 👁️ Amazon CloudWatch | 지표 수집 & 알람 | 인스턴스/서비스 상태 모니터링 |
| 🕵️ AWS X-Ray | 분산 추적 | 요청 흐름 분석 및 병목 탐지 |
💡 CloudWatch 알람 + Auto Scaling 정책 = 자가 복구(Self-healing) 시스템 구축

| 핵심 주제 | 주요 포인트 |
| 확장성 (Scalability) | Auto Scaling, Load Balancing |
| 복원력 (Resilience) | Multi-AZ, Multi-Region, Self-Healing |
| 고가용성 (HA) | 장애 발생 시 빠른 복구 |
| 내결함성 (FT) | 장애 중에도 서비스 지속 |
| 재해 복구 (DR) | Backup & Restore, Pilot Light, Warm Standby |
| 모니터링 | CloudWatch, X-Ray |
| 비동기 분리 | SQS, SNS, EventBridge |
| 상태 관리 | Stateless 아키텍처 + EFS 통합 |
| 캐시 활용 | ElastiCache, DAX, Read Replica |
| [AWS SAA-C03] Domain 1 Review : AWS Certified Solutions Architect - Associate (0) | 2025.08.30 |
|---|
✅ 이 문제는 AWS Config의 대표적인 사용 목적(컴플라이언스 및 구성 변경 추적)을 정확히 묻고 있습니다.
A company has a compliance requirement to record and evaluate configuration changes,
as well as perform remediation actions on AWS resources.
Which AWS service should the company use?
한 회사에서는 구성 변경 사항을 기록하고 평가하며,
AWS 리소스에 대한 수정 조치를 수행해야 하는 규정 준수 요구 사항이 있습니다.
어떤 AWS 서비스를 사용해야 합니까?
AWS Config는 AWS 리소스의 구성 변경 사항(Configuration Changes) 을 추적하고
컴플라이언스(규정 준수) 상태를 자동으로 평가하며,
필요 시 자동 복구(Remediation) 도 수행할 수 있는 관리형 서비스입니다.
즉, “누가 어떤 리소스를 만들었는가?”가 아니라
“리소스의 설정이 어떻게 바뀌었는가?”를 추적하는 서비스입니다.
| 기능 | 설명 |
| 🔍 구성 변경 기록 (Configuration Recording) | EC2, S3, IAM 등 AWS 리소스의 속성 변경을 자동 기록 |
| 🧾 규정 준수 평가 (Compliance Evaluation) | 미리 정의된 규칙(예: 암호화 미적용, 퍼블릭 S3 등)에 따라 리소스 상태를 평가 |
| 🔁 자동 수정 (Remediation) | 비규정 상태(non-compliant) 리소스를 자동으로 수정 (예: Lambda 트리거) |
| 📜 구성 이력(Configuration History) & 스냅샷(Snapshot) | 시간에 따른 리소스 변경 내역을 S3에 저장 가능 |
| 📈 AWS Config Rules + Aggregator | 여러 계정/리전의 컴플라이언스 현황을 중앙집중식으로 관리 가능 |
| 서비스 | 주요 목적 | 차이점 |
| AWS Config | 리소스 구성 변경 추적 및 규정 준수 평가 | “리소스의 상태 변화” 를 감시 |
| AWS CloudTrail | API 호출 및 사용자 활동 추적 | “누가 언제 어떤 행동을 했는가” 를 기록 |
| AWS Trusted Advisor | 비용/보안/성능 모범 사례 점검 | 실시간 “조언” 제공, 자동 추적 기능은 제한적 |
| AWS Security Hub | 보안 상태 종합 대시보드 | AWS Config와 통합하여 보안 규정 준수 평가 강화 가능 |
| 상황 | 해결 방법 |
| S3 버킷이 퍼블릭 액세스로 변경됨 | AWS Config가 변경 탐지 후 경고 및 Lambda 트리거로 자동 수정 |
| EC2 인스턴스에서 암호화되지 않은 EBS 사용 | AWS Config Rule에서 비규정 상태로 감지하고 경고 |
구성 변경 추적, 규정 준수 평가, 자동 수정(remediation)이 필요한 경우
AWS Config를 사용해야 합니다.
✅ 이 문제는 AWS Well-Architected Framework의 5가지 기둥(pillars) 중에서 어떤 항목이 해당되는지를 묻는 전형적인 CLF-C02 / SAA-C03 공통 문제입니다.
A company is designing workloads in the AWS Cloud.
The company wants the workloads to perform their intended function correctly and consistently throughout their lifecycle.
회사는 AWS 클라우드에서 워크로드를 설계하고 있으며,
워크로드가 수명 주기 내내 의도된 기능을 올바르고 일관되게 수행하기를 원합니다.
➡ Which pillar of the AWS Well-Architected Framework does this goal represent?
**Reliability Pillar (안정성 기둥)**은
워크로드가 의도된 기능을 올바르게 수행하고,
장애가 발생하더라도 복구(resilience)와 일관성(consistency) 을 유지하도록 하는 것을 목표로 합니다.
즉, “시스템이 끊김 없이 신뢰성 있게 작동하도록 설계”하는 것이 핵심입니다.
| 구성 | 요소설명 |
| 🏗️ Foundations (기반) | 충분한 리소스 할당, IAM 권한 및 네트워크 설계 포함 |
| 🔁 Workload Architecture (워크로드 아키텍처) | 고가용성(HA)과 장애 허용성(Fault Tolerance)을 보장하는 설계 |
| 🔄 Change Management (변경 관리) | 시스템 변경 시에도 서비스 중단 없이 안정적으로 적용 |
| 🧱 Failure Recovery (장애 복구) | 장애 시 자동 복구(Auto Recovery) 또는 리전/존 단위 복원력 확보 |
| Pillar 핵심 | 목적 | 키워드 |
| 1️⃣ Operational Excellence (운영 우수성) | 운영 프로세스 자동화, 모니터링, 개선 | DevOps, 자동화, 관찰성 |
| 2️⃣ Security (보안) | 데이터 보호, IAM, 인프라 보안 강화 | 암호화, 최소 권한, 로깅 |
| 3️⃣ Reliability (안정성) | 장애 복구, 일관된 성능 유지 | 복원력, 장애 허용, 백업 |
| 4️⃣ Performance Efficiency (성능 효율성) | 컴퓨팅 자원의 효율적 사용 | 오토 스케일링, 적합한 리소스 크기 |
| 5️⃣ Cost Optimization (비용 최적화) | 비즈니스 가치를 극대화하면서 비용 최소화 | 리저브드 인스턴스, 사용량 기반 비용 관리 |
| 보기 | 설명 | 오답 이유 |
| A. Operational Excellence | 운영 프로세스 개선, 코드 배포, 자동화 관련 | 워크로드 안정성과 직접적 연관 없음 |
| B. Security | 데이터와 시스템 보호 중심 | “정확한 기능 수행”이 아니라 “보안 위험 관리”가 초점 |
| D. Performance Efficiency | 리소스 효율성 중심 | 성능 최적화와 관계 있지만, "일관성 있는 기능 수행"은 안정성 영역 |
워크로드가 의도된 기능을 올바르고 일관되게 수행하도록 설계하려면
Reliability (안정성) 기둥이 핵심입니다.
✅ 이 문제는 AWS 서비스 관리 도구 중 인터페이스 차이를 구분할 수 있는지를 묻는 기본형 문제입니다.
(AWS Certified Cloud Practitioner – CLF-C02 단골문제입니다.)
Which AWS service or tool provides users with a graphical interface that they can use to manage AWS services?
어떤 AWS 서비스 또는 도구가 사용자가 AWS 서비스를 관리할 수 있는
그래픽 인터페이스(GUI)를 제공합니까?
AWS Management Console은 웹 기반 그래픽 사용자 인터페이스(GUI) 로,
AWS의 모든 주요 서비스(EC2, S3, IAM, RDS 등)를 시각적으로 탐색하고 관리할 수 있는 도구입니다.
즉, AWS 서비스를 명령어 없이 마우스로 클릭해 조작할 수 있는 콘솔 환경입니다.
| 구분 | 도구 | 인터페이스 유형 | 주요 사용 방법 |
| 🟢 AWS Management Console | 그래픽 인터페이스 (GUI) | 웹 브라우저 | 시각적 조작, 초보자 친화적 |
| 🔵 AWS CLI (Command Line Interface) | 명령줄 인터페이스 (CLI) | 터미널/명령 프롬프트 | 스크립트 자동화, 빠른 대량 처리 가능 |
| 🟣 AWS SDKs (Software Development Kits) | 프로그래밍 인터페이스 (API) | Python, Java, Node.js 등 코드 내 통합 | 개발자용, 애플리케이션 통합 목적 |
| 🟠 AWS Copilot | CLI 기반 도구 | ECS/Fargate 앱 배포용 | 개발자용, CI/CD 파이프라인 통합 중심 |
| 도구 | 사용 예시 |
| Management Console | EC2 인스턴스를 생성하려고 콘솔에서 “Launch instance” 클릭 |
| AWS CLI | aws ec2 describe-instances 명령어로 인스턴스 목록 조회 |
| AWS SDK | Python boto3 코드로 S3 버킷 자동 생성 |
| AWS Copilot | CLI로 컨테이너 앱을 Fargate에 배포 (copilot app init) |
AWS 서비스를 그래픽(GUI) 으로 관리하고 싶다면
AWS Management Console을 사용해야 합니다.
✅ 이 문제는 AWS 데이터베이스 서비스 유형 구분 — 특히 RDS / Redshift / DynamoDB / Aurora의 차이를 묻는 기본 핵심 문제입니다.
(CL, SAA, DVA 시험에서 모두 자주 출제됩니다.)
Which AWS service is a fully managed NoSQL database service?
어떤 AWS 서비스가 완전 관리형(NoSQL) 데이터베이스 서비스입니까?
Amazon DynamoDB는 AWS의 대표적인 완전관리형(fully managed)
NoSQL 데이터베이스 서비스로, Key-Value 및 Document 기반 스토리지를 제공합니다.
즉, 서버 관리, 확장, 백업, 장애 복구를 AWS가 모두 관리하므로
사용자는 데이터 모델링과 쿼리 로직에만 집중할 수 있습니다.
| 항목 | 설명 |
| 💡 데이터 모델 | Key-Value & Document (JSON 구조 지원) |
| ⚙️ 서버 관리 | 완전 관리형 (사용자는 인스턴스 관리 불필요) |
| ⚡ 성능 | 밀리초 수준의 지연시간, 초당 수백만 요청 처리 가능 |
| 🚀 확장성 | Auto Scaling 기반 수평 확장 (seamless scaling) |
| 🔒 보안 | IAM 통합, KMS 암호화, VPC 엔드포인트 지원 |
| 🧭 사용 예시 | 게임 리더보드, IoT 센서 데이터, 세션 관리, 쇼핑카트 등 |
| 🔁 추가 기능 | DynamoDB Streams, Global Tables, On-Demand Backup |
| 서비스 | 유형 | 주요 용도 | 관리 수준 | 데이터 구조 |
| Amazon RDS | Relational (SQL) | MySQL, PostgreSQL 등 | 관리형, 인스턴스 기반 | 테이블/SQL |
| Amazon Aurora | Relational (SQL) | RDS보다 성능 향상형 | 완전관리형 (Aurora Serverless 지원) | 테이블/SQL |
| Amazon DynamoDB | NoSQL | Key-Value / Document 기반 | 완전관리형 (서버리스) | JSON-like |
| Amazon Redshift | Data Warehouse | 분석용 (OLAP) | 관리형 | Column-based |
🔸 SQL → RDS, Aurora
🔸 NoSQL → DynamoDB
🔸 분석용(DWH) → Redshift
완전관리형(fully managed) NoSQL DB 서비스 =
Amazon DynamoDB
✅ 이 문제는 EC2 인스턴스 구매 옵션(Purchasing Options) 의 특징을 이해하는 문제입니다.
AWS Certified Cloud Practitioner (CLF-C02)와 Solutions Architect Associate (SAA-C03) 시험에서 자주 출제되는 핵심 유형이에요.
A company needs to run an application on Amazon EC2 instances without interruption.
Which EC2 instance purchasing option will meet this requirement MOST cost-effectively?
회사는 중단 없이(Without interruption) Amazon EC2 인스턴스에서
애플리케이션을 실행해야 합니다.
어떤 EC2 구매 옵션이 가장 비용 효율적으로 이 요구사항을 충족할까요?
**Standard Reserved Instances (RI)**는
1년 또는 3년 동안 지속적인 사용(steady-state usage) 을 약정함으로써
On-Demand 대비 최대 72%까지 절감할 수 있는 비용 효율적인 옵션입니다.
이 문제에서 핵심 키워드는 👇
"without interruption" (= 항상 실행되어야 함)
→ 즉, 중단이 없어야 하는 상시 워크로드
→ 따라서 Reserved Instance (RI) 가 정답입니다.
| 구매 옵션 | 설명 | 비용 절감률 (대비) | 중단 가능성 | 주요 사용 사례 |
| On-Demand | 사용한 만큼 지불 (Pay-as-you-go) | 기준 (0%) | ❌ 없음 | 예측 불가능한 워크로드 |
| Standard Reserved Instances | 1년/3년 약정, 고정된 유형 | ✅ 최대 72% 절감 | ❌ 없음 | 항상 실행되는 애플리케이션 |
| Convertible Reserved Instances | RI 변경 가능 (인스턴스 타입 변경 허용) | ✅ 최대 66% 절감 | ❌ 없음 | 장기적이지만 워크로드 변경 가능성 있을 때 |
| Spot Instances | 미사용 EC2 용량 입찰 방식 | 💰 최대 90% 절감 | ⚠️ 중단 가능 | 비중요 백그라운드 작업, Batch, AI 트레이닝 |
| 조건 | 해당 옵션 |
| ❗ 항상 실행(중단 없음) | Reserved Instance |
| 💰 비용 절감 최대화 | Standard RI |
| 🔁 변경 유연성 필요 | Convertible RI |
| ⚡ 단기/불규칙적 워크로드 | On-Demand |
| 🧪 테스트/일시적 작업 | Spot Instance |
중단 없이 항상 실행되어야 하고
가장 비용 효율적인 옵션은
Standard Reserved Instance 입니다.
| [AWS CLF-C02] Q501 ~ Q600 오답노트 5EA (0) | 2025.10.22 |
|---|---|
| [AWS CLF-C02] Q401 ~ Q500 오답노트 13EA (0) | 2025.10.19 |
| [AWS CLF-C02] Q301 ~ Q400 오답노트 6EA (0) | 2025.10.18 |
| [AWS CLF-C02] Q251 ~ Q300 오답노트 2EA (0) | 2025.10.16 |
| [AWS CLF-C02] Q201 ~ Q250 오답노트 10EA (0) | 2025.10.14 |
✅ 이 문제는 온프레미스의 MariaDB 데이터베이스를 AWS로 이전할 때,
운영 오버헤드(Operational Overhead) 가 가장 적은 서비스를 묻고 있습니다.
A company has a MariaDB database on premises.
The company wants to move the data to the AWS Cloud.
Which AWS service will host this database with the LEAST amount of operational overhead?
회사는 온프레미스 MariaDB를 AWS로 이전하려고 합니다.
이 데이터베이스를 가장 적은 운영 부담으로 호스팅할 수 있는 AWS 서비스는 무엇입니까?
Amazon RDS는 AWS에서 제공하는 완전관리형 관계형 데이터베이스 서비스로,
데이터베이스의 프로비저닝, 패치, 백업, 복제, 장애 조치 등을 자동화하여
운영자의 부담을 최소화합니다.
| 항목 | 설명 |
| 🧩 지원 엔진 | MySQL, MariaDB, PostgreSQL, Oracle, SQL Server, Aurora |
| ⚙️ 관리 자동화 | OS/DB 패치, 백업, 스냅샷, 장애 조치(Auto Failover) 자동 수행 |
| 💾 고가용성 구성 | Multi-AZ 배포로 장애 시 자동 장애조치(Failover) |
| 🔄 확장성 | 수직(인스턴스 크기) + 수평(읽기 전용 복제본) 확장 |
| 💡 통합 서비스 | CloudWatch, IAM, KMS, Secrets Manager와 통합 |
| 🕒 운영 오버헤드 | 매우 낮음 (Fully Managed) |

| 보기 | 설명 | 오답 이유 |
| B. Amazon Neptune | 그래프 DB 서비스 (소셜 그래프, 관계형 노드 분석 등) | ❌ 관계형 DB 아님 |
| C. Amazon S3 | 객체 스토리지 서비스 | ❌ 데이터베이스로 사용 불가 |
| D. Amazon DynamoDB | NoSQL 키-값 DB 서비스 | ❌ 관계형 SQL DB가 아님 |
| 항목 | 선택 이유 |
| ✅ MariaDB 호환 | RDS는 MariaDB 엔진을 완벽히 지원 |
| ✅ 운영 자동화 | 백업, 패치, 모니터링 자동화 |
| ✅ 관리 부담 최소화 | DBA 개입 최소화 (Managed Service) |
☁️ Amazon RDS for MariaDB는 자동 백업, 모니터링, 패치, 장애조치를 지원하는
완전관리형(fully managed) 관계형 데이터베이스 서비스로,
운영 오버헤드가 가장 적은 AWS 선택지입니다.
Which statements accurately describe the relationships among components of AWS global infrastructure? (Choose two)
AWS 글로벌 인프라 구성 요소 간의 관계를 정확히 설명한 것은 무엇입니까?
(2개 선택)
AWS 글로벌 인프라(Global Infrastructure)는 다음과 같은 계층 구조로 구성됩니다.
🌍 AWS Global Infrastructure
├── 🌎 Region (리전)
│ ├── 🏢 Availability Zone (가용 영역)
│ └── 🗄️ Local Zone (로컬 영역)
└── 🌐 Edge Location (엣지 로케이션)
✔️ 정답
✔️ 정답
예시 📍
| ap-northeast-2 (서울) | 4개 |
| us-east-1 (버지니아) | 6개 |
| ap-southeast-1 (싱가포르) | 3개 |
→ 즉, AZ > Region
| 보기 | 설명 | 오답 이유 |
| A. There are more AWS Regions than Availability Zones. | 리전은 AZ보다 적음 | ❌ 반대 관계 |
| C. An edge location is an Availability Zone. | 엣지 로케이션은 CDN용 | ❌ 서로 다른 개념 |
| D. There are more AWS Regions than edge locations. | 엣지 로케이션은 전 세계 수백 개 | ❌ 반대 관계 |

| 정답 | 이유 |
| B. There are more edge locations than AWS Regions. | 엣지 로케이션은 리전보다 훨씬 많음 |
| E. There are more Availability Zones than AWS Regions. | 한 리전에 AZ가 여러 개 존재 |
🌎 Region < Availability Zone < Edge Location (in quantity)
즉, 엣지 로케이션이 가장 많고, 그다음은 AZ, 마지막은 Region입니다.
✅ 이 문제는 웹 애플리케이션의 인바운드 트래픽을 필터링 및 제어해야 할 때
어떤 AWS 보안 서비스를 사용해야 하는지를 묻고 있습니다.
A company is hosting a web application on Amazon EC2 instances.
The company wants to implement custom conditions to filter and control inbound web traffic.
회사가 Amazon EC2 인스턴스에서 웹 애플리케이션을 호스팅하고 있으며,
인바운드 웹 트래픽을 사용자 지정 조건(Custom Conditions) 으로 필터링 및 제어하고자 합니다.
AWS WAF는 웹 애플리케이션을 보호하기 위한 방화벽 서비스로,
HTTP/HTTPS 트래픽을 사용자 정의 조건(Custom Rules) 으로 필터링할 수 있습니다.
| 기능 | 설명 |
| ⚙️ 트래픽 필터링 | IP, 쿼리 문자열, URI, HTTP 헤더 등 조건 기반 필터링 |
| 🧩 규칙 기반 보안 | SQL Injection, XSS, 악성 요청 등을 자동 차단 |
| 🔄 통합 서비스 | ALB, CloudFront, API Gateway, App Runner와 통합 가능 |
| 📊 모니터링 | CloudWatch를 통한 트래픽 로깅 및 분석 |
| 💡 Custom Rule 가능 | 특정 국가, IP, 경로 기반 허용/차단 조건 정의 가능 |

| 보기 | 설명 | 오답 이유 |
| A. Amazon GuardDuty | 위협 탐지 서비스 (비정상 API 활동 탐지) | ❌ 트래픽 필터링 기능 없음 |
| C. Amazon Macie | S3 내 민감한 데이터 자동 식별 서비스 | ❌ 웹 트래픽 제어와 무관 |
| D. AWS Shield | DDoS 공격 방어 서비스 | ❌ WAF처럼 세밀한 사용자 지정 조건 불가 (Layer 3/4 중심) |
| 서비스 | 주요 목적 | 트래픽 제어 가능 여부 |
| WAF | 웹 트래픽 필터링 및 룰 기반 제어 | ✅ |
| Shield | DDoS 보호 | ⚠️ (제한적) |
| GuardDuty | 비정상 활동 탐지 | ❌ |
| Macie | 데이터 보안(민감정보 탐지) | ❌ |
🌐 AWS WAF는 HTTP/HTTPS 요청에 대해 커스텀 룰을 적용해
SQL Injection, XSS, IP 필터링 등 인바운드 웹 트래픽을 제어하는 방화벽 서비스입니다.
✅ 이 문제는 AWS Support Plan 중에서 API 호출을 통한 AWS Support 연동이 가능한 최소 비용 플랜을 묻는 문제입니다.
A new AWS user needs to interact with AWS Support by using API calls.
Which AWS Support plan will meet this requirement MOST cost-effectively?
새로운 AWS 사용자가 API 호출을 사용하여 AWS Support와 상호 작용하려 합니다.
어떤 Support Plan이 이 요구사항을 가장 비용 효율적으로 충족할까요?
| Support Plan | 요약 | AWS Support API 접근 가능 여부 | 가격 |
| Basic Support | 기본 지원 (Billing, Documentation, Forums) | ❌ 불가능 | 무료 |
| Developer Support | 개발자용 기술 지원, API 연동 가능 | ✅ 가능 | $29/월부터 |
| Business Support | 프로덕션 워크로드 지원, 24x7 전화/채팅 지원 | ✅ 가능 | $100/월부터 |
| Enterprise Support | 대규모 기업용, TAM 배정 | ✅ 가능 | $15,000/월부터 |
| 항목 | 설명 |
| 💬 기술 지원 채널 | 이메일 기반 기술 지원 (Business/Enterprise만 전화/채팅 포함) |
| 🕒 응답 시간 (Response Time) | 일반 기술 문의 24시간 이내 |
| 🔧 AWS Support API | AWS Support Center의 Case, Severity, Status 등 API로 관리 가능 |
| 🧠 Best Practice 가이드 | AWS 서비스 구성 관련 모범 사례 제공 |
| 🧰 Trusted Advisor | 기본 7개 핵심 항목 검사 가능 (비용 최적화, 보안 등) |
| 보기 | 설명 | 오답 이유 |
| A. AWS Basic Support | 문서, 포럼, Billing 문의만 가능 | ❌ Support API 미지원 |
| C. AWS Business Support | 프로덕션 환경용, 전화/채팅 가능 | ✅ 되지만 비용 비효율적 |
| D. AWS Enterprise Support | 대기업 전용, TAM 포함 | ✅ 되지만 가장 비쌈 |
AWS Support API를 사용하면 프로그래밍 방식으로 지원 케이스를 조회/생성 가능:
이 기능은 Developer Support 이상 플랜이 필요합니다.
💡 AWS Support API를 사용하려면 최소 Developer Support 플랜이 필요하며,
이 플랜이 가장 저렴하게(API 연동 포함) 요구사항을 충족합니다.
✅ 이 문제는 AWS CloudTrail의 핵심 개념을 묻는 전형적인 문제입니다.
A company needs an event history of which AWS resources the company has created.
Which AWS service will provide this information?
회사는 회사에서 만든 AWS 리소스에 대한 이벤트 내역이 필요합니다.
어떤 AWS 서비스가 이 정보를 제공합니까?
AWS CloudTrail은 AWS 계정 내에서 발생하는 모든 API 호출 및 이벤트 활동을 기록하는 서비스입니다.
즉, 누가 언제 어떤 리소스를 만들었고 (예: EC2, S3, IAM 등)
어떤 작업(예: Create, Delete, Modify)을 수행했는지 이벤트 히스토리(Event History) 형태로 제공합니다.
| 기능 | 설명 |
| 🗂 이벤트 기록 (Event History) | AWS 리소스 생성, 수정, 삭제 등의 API 호출 기록 제공 |
| 🔐 보안 감사(Audit) 및 컴플라이언스(Compliance) | 누가 어떤 행동을 했는지 추적 가능 — 내부 감사 및 규제 준수에 활용 |
| 📜 로그 저장 | CloudTrail 로그를 Amazon S3에 저장하거나 CloudWatch Logs로 전송 가능 |
| 🕵️ AWS Management Console, CLI, SDK 호출 모두 기록 | 웹 콘솔이든 API든 관계없이 모든 호출이 추적됨 |
| 보기 | 서비스 | 설명 |
| A. Amazon CloudWatch | 모니터링 서비스 | 성능 지표(메트릭), 로그, 알람 등을 모니터링하지만 리소스 생성 내역은 기록하지 않음 |
| C. Amazon Aurora | RDS 기반 DB 서비스 | 데이터베이스 관리용, 이벤트 히스토리와 무관 |
| D. Amazon EventBridge | 이벤트 버스 서비스 | 실시간 이벤트 통합 및 자동화 트리거용. 이력 저장 서비스가 아님 |
| 항목 | CloudTrail | CloudWatch | EventBridge |
| 기록 목적 | 이벤트 및 API 활동 기록 | 지표와 로그 모니터링 | 이벤트 기반 자동화 트리거 |
| 주 데이터 유형 | API 호출 로그 | 메트릭 & 로그 | 이벤트 스트림 |
| 사용 예시 | 누가 EC2를 삭제했는가? | CPU 사용률 90% 이상 경고 | S3에 파일 업로드 시 Lambda 실행 |
AWS 리소스 생성/삭제/수정 등 이벤트 이력(Event History) 을 추적하려면
AWS CloudTrail을 사용합니다.
| [AWS CLF-C02] Q601 ~ Q719 오답노트 5EA (0) | 2025.10.24 |
|---|---|
| [AWS CLF-C02] Q401 ~ Q500 오답노트 13EA (0) | 2025.10.19 |
| [AWS CLF-C02] Q301 ~ Q400 오답노트 6EA (0) | 2025.10.18 |
| [AWS CLF-C02] Q251 ~ Q300 오답노트 2EA (0) | 2025.10.16 |
| [AWS CLF-C02] Q201 ~ Q250 오답노트 10EA (0) | 2025.10.14 |
Which statements represent the cost-effectiveness of the AWS Cloud? (Choose two)
AWS 클라우드의 비용 효율성을 나타내는 설명은 무엇입니까? (2개 선택)
📊 예시:
👉 즉, “고정비를 변동비로 전환”함으로써 초기 투자 부담 없이 클라우드 도입이 가능합니다.
📉 효과:
🏷️ 실제로 AWS는 2006년 이후 100회 이상 공식적으로 가격을 인하했습니다.
| 보기 | 설명 | 오답 |
| B. Users can deploy all over the world in minutes. | 이는 민첩성(Agility) 관련 이점이지 비용 효율성과 직접 관련 없음 | ❌ |
| C. AWS offers increased speed and agility. | 속도 향상은 운영 효율성 측면이지 비용 절감과는 별개 | ❌ |
| D. AWS is responsible for patching the infrastructure. | AWS가 인프라 보안을 담당하는 것은 보안(Shared Responsibility Model) 개념 | ❌ |
| 핵심 | 개념설명 |
| CapEx → OpEx 전환 | 초기 투자 없이 필요한 만큼만 사용 후 지불 |
| 규모의 경제 (Economies of Scale) | AWS의 대규모 인프라 운영으로 낮은 단가 실현 |
| 사용량 기반 과금 (Pay-as-you-go) | 유휴 리소스 제거 및 낭비 최소화 |
```mermaid
flowchart LR
A["🏢 On-Premises"] -->|"💰 CapEx - 서버 구매 및 유지비"| B["💸 높은 고정비"]
C["☁️ AWS Cloud"] -->|"⚙️ OpEx - 사용한 만큼 지불 (Pay-as-you-go)"| D["💵 변동비 + 효율적 비용"]
D -->|"📉 규모의 경제로 지속적 가격 인하"| E["🚀 비용 효율 향상"]
```

☁️ AWS의 비용 효율성 핵심은 “CapEx → OpEx 전환” + “규모의 경제(Economies of Scale)”
A company needs to consolidate the billing for multiple AWS accounts.
여러 AWS 계정의 결제를 통합해야 한다면 어떤 서비스를 사용해야 할까요?
AWS Organizations는 여러 AWS 계정을 중앙에서 관리하고,
청구서 통합(Consolidated Billing) 및 정책 제어(Service Control Policies, SCPs) 를 수행할 수 있는 서비스입니다.
| 기능 | 설명 |
| 🧾 Consolidated Billing (통합 청구) | 여러 AWS 계정을 하나의 “Payer Account(결제 계정)” 아래 묶어 단일 청구서로 관리 가능 |
| 💰 비용 절감 효과 (Savings) | 모든 계정의 사용량이 합산되어 볼륨 할인과 Savings Plan/RI 할인을 함께 적용받음 |
| 🔒 Policy Control (SCP) | 멤버 계정이 수행할 수 있는 서비스나 리소스를 조직 단위로 제한 가능 |
| 🧑💼 조직 구조 관리 | OU(Organizational Units)를 사용해 부서, 팀, 프로젝트별 계정 그룹화 가능 |
| ⚙️ 자동 계정 생성 및 초대 | 새로운 계정을 자동으로 생성하거나 기존 계정을 조직에 초대 가능 |
| 계정 | EC2 사용료 | 합산 할인율 | 총 비용 |
| A (개발팀) | $100 | ||
| B (운영팀) | $200 | ✅ 10% 할인 적용 (300달러 단위) | 💵 $270 |
| 총합 | $300 | 통합 청구 + 할인 적용 | ✅ 더 적은 총 비용 |
즉, 개별 계정이 아닌 조직 전체 사용량을 기준으로 할인율이 적용되어
비용 효율성이 증가합니다.
| 보기 | 설명 | 오답 이유 |
| A. AWS Trusted Advisor | 보안, 비용, 성능, 서비스 한도 관련 권장사항 제공 | ❌ 결제 통합 기능 없음 |
| C. AWS Budgets | 예산 한도 및 초과 시 알림 설정 기능 제공 | ❌ “알림” 기능이지, 결제 통합은 불가 |
| D. AWS Service Catalog | 승인된 서비스 템플릿을 카탈로그 형태로 배포 | ❌ 결제 관리와 무관 |
```mermaid
flowchart TD
A["👩💼 Management / Payer Account"] -->|"🧾 Consolidated Billing"| B["👥 Linked Accounts"]
B -->|"📊 Usage Data + 💸 Discounts"| C["💰 Single Combined Invoice"]
A -->|"🛡️ Apply SCPs"| D["🔒 Control Policies"]
```

💼 여러 AWS 계정의 청구를 통합하려면 AWS Organizations의 Consolidated Billing 기능을 사용합니다.
VPC 내에서 EC2 인스턴스 간 트래픽 제어를 위한 AWS 네이티브 보안 리소스를 묻는 문제입니다.
Which AWS service or feature will meet this requirement?
특정 EC2 인스턴스 간의 네트워크 트래픽을 제어하기 위한 AWS 기본 보안 기능은 무엇입니까?
| 항목 | 설명 |
| 적용 수준 | 인스턴스 수준 (Instance Level) |
| 상태 저장(Stateful) | 요청이 허용되면 응답 트래픽은 자동 허용 |
| 규칙 방향 | Inbound (수신) / Outbound (송신) 트래픽 제어 가능 |
| 기본 동작 | 모든 트래픽 거부(Deny All) 후 명시적으로 허용(Allow Only) |
| 적용 대상 | EC2, RDS, Lambda ENI, ALB 등 ENI(Elastic Network Interface) 기반 리소스 |
| 예시 | 특정 EC2 인스턴스끼리만 SSH(22번 포트) 통신 허용 |
회사가 VPC 안에 EC2 인스턴스 10개를 실행 중이고,
이 중 웹 서버(EC2-1) 와 DB 서버(EC2-2) 사이에만 통신을 허용하고 싶을 때:
✅ 이렇게 하면 DB 인스턴스는 지정된 웹 서버 SG에서 오는 요청만 수락합니다.
| 보기 | 설명 | 오답 이유 |
| A. Network ACLs | 서브넷 단위(Subnet-level) 트래픽 제어, Stateless 방식 | ❌ 인스턴스 간 세부 제어 불가능 |
| B. AWS WAF | 웹 애플리케이션 계층(7계층)에서 HTTP/HTTPS 요청 필터링 | ❌ EC2 간 내부 네트워크 제어와 무관 |
| C. Amazon GuardDuty | 위협 탐지(Threat Detection) 서비스로, 트래픽 제어 불가능 | ❌ 모니터링 용도일 뿐 제어 불가 |
| D. Security groups | ✅ 인스턴스 수준에서 트래픽 제어 (정답) | ✅ |
```mermaid
flowchart LR
A["💻 EC2-1 - Web Server"] -->|"✅ Allow Port 3306"| B["🗄️ EC2-2 - DB Server"]
A -.->|"🚫 Other Ports Denied"| B
subgraph VPC ["🌐 VPC"]
A
B
end
Note["🔒 Security Group - Instance-level, Stateful, Allow-based Rules"]
```

🛡️ EC2 인스턴스 간 트래픽 제어는 보안 그룹(Security Group) 으로 수행하며, 이는 인스턴스 수준의 상태 저장형 방화벽입니다.
Which AWS service should the company use to meet these requirements?
전 세계 사용자에게 웹사이트를 빠르고 효율적으로 전달하려면 어떤 서비스를 사용해야 할까요?
Amazon CloudFront는 AWS의 글로벌 콘텐츠 전송 네트워크(CDN, Content Delivery Network) 서비스입니다.
전 세계 600개 이상의 Edge Location(엣지 로케이션) 을 통해 콘텐츠를 캐싱하고,
사용자에게 가장 가까운 위치에서 데이터를 전송함으로써 지연시간(Latency) 을 최소화합니다.
| 기능 | 설명 |
| 🌍 글로벌 엣지 네트워크 제공 | 사용자와 가장 가까운 Edge Location에서 콘텐츠 제공 |
| ⚡ 낮은 지연시간 (Low Latency) | EC2/S3의 원본 데이터를 전 세계 캐시 서버에 분산 저장 |
| 🔒 보안 강화 | AWS Shield, WAF, SSL/TLS 통합 지원 |
| 💸 비용 절감 | 캐싱을 통해 원본 서버(EC2/S3)에 대한 요청 감소 → 네트워크 비용 절감 |
| 🧠 자동 확장성 | 트래픽 급증 시 자동으로 Edge 서버 리소스 확장 |
회사는 EC2 인스턴스에서 웹사이트를 호스팅 중
CloudFront를 구성하여 전 세계 엣지 로케이션에 캐싱하면 지연이 크게 감소합니다.

📍 요약:
사용자는 가까운 Edge Location을 통해 콘텐츠를 받기 때문에
서울, 뉴욕, 런던 어디서 접속하든 빠른 속도로 웹사이트가 표시됩니다.
| 보기 | 설명 | 오답 이유 |
| A. Amazon Route 53 | DNS 서비스로 도메인 트래픽을 라우팅함 | ❌ 전송 지연 최소화 목적(CDN)이 아님 |
| C. Elastic Load Balancing (ELB) | 리전 내 EC2 인스턴스 간 트래픽 분산 | ❌ 글로벌 사용자에게는 한계 있음 |
| D. AWS Lambda | 서버리스 컴퓨팅 서비스 | ❌ 웹 콘텐츠 전송 및 캐싱 기능 없음 |
| 항목 | 설명 |
| 🌍 전 세계 커버리지 | 글로벌 엣지 네트워크로 사용자와 물리적 거리 최소화 |
| 🚀 성능 향상 | 데이터 전송 속도 개선, 지연시간 감소 |
| 💰 비용 절감 | 원본 서버 부하 및 데이터 전송 비용 절감 |
| 🔒 보안 강화 | DDoS 보호(AWS Shield), HTTPS 통신, WAF 통합 |
⚡ 전 세계 사용자에게 빠르고 안전하게 웹사이트를 전달하려면 Amazon CloudFront (CDN) 를 사용하세요.
Which AWS service should the company use to identify who accessed an AWS service and what action was performed?
AWS CloudTrail은 계정 내에서 발생한 모든 API 호출(Activity Logs) 을 기록하는 감사(Audit) 서비스입니다.
즉,
“누가 (Who)”,
“언제 (When)”,
“어디서 (Where)”,
“무엇을 (What)”
했는지를 모두 추적할 수 있습니다.
| 기능 | 설명 |
| 🧾 API 호출 기록 | AWS Management Console, CLI, SDK, 또는 다른 서비스에서 발생한 모든 API 호출을 기록 |
| 👤 사용자 식별 | 어떤 IAM 사용자, 역할(Role), 또는 서비스가 요청을 수행했는지 확인 가능 |
| 🕓 시간별 이벤트 추적 | 특정 시간대(Time Window) 동안의 모든 활동 로그를 검색 가능 |
| 💾 로그 저장 | CloudTrail 로그는 S3 버킷에 자동 저장 가능 |
| 🔍 이상 활동 감지 | CloudTrail Insights를 통해 비정상적 API 호출 패턴 탐지 |
| 🔒 보안 감사 및 컴플라이언스 | PCI-DSS, ISO 27001 등 규정 준수를 위한 로그 증적 확보 가능 |
회사가 “어제 누가 S3 버킷을 삭제했는지” 확인해야 한다면?
{
"eventVersion": "1.05",
"userIdentity": {
"type": "IAMUser",
"userName": "admin-user"
},
"eventTime": "2025-10-18T09:33:12Z",
"eventSource": "s3.amazonaws.com",
"eventName": "DeleteBucket",
"sourceIPAddress": "203.0.113.45"
}
위 로그에서 누가(userName), 언제(eventTime), 어떤 서비스(eventSource) 에서
어떤 행동(eventName) 을 수행했는지를 알 수 있습니다.
| 보기 | 설명 | 오답 이유 |
| A. Amazon CloudWatch | 성능 모니터링 및 메트릭 수집 서비스 | ❌ API 호출 기록 불가 (리소스 상태만 모니터링) |
| C. AWS Security Hub | 보안 상태 종합 관리 대시보드 | ❌ CloudTrail, GuardDuty 등에서 받은 데이터를 종합 분석 |
| D. Amazon Inspector | 애플리케이션 취약점 및 보안 평가 서비스 | ❌ API 활동 추적 기능 없음 |
```mermaid
flowchart TD
A["👤 IAM User / Role"] -->|API Call| B["🧠 AWS CloudTrail"]
B --> C["📦 S3 Log Storage"]
B --> D["🔍 Event History Console"]
D --> E["👁️ Identify who, when, and what action was taken"]
```

🕵️♂️ AWS CloudTrail은 “누가 언제 무엇을 했는지”를 기록하는 감사 및 보안 추적 서비스입니다.
여러 VPC 및 온프레미스 네트워크를 효율적으로 연결하고, 피어링 관계를 단순화하기 위한 AWS 네트워크 서비스를 묻고 있습니다.
Which AWS service can the company use as a cloud router to simplify peering relationships?
여러 VPC와 온프레미스 네트워크를 연결하고 라우팅을 단순화하기 위해 사용할 수 있는 AWS 서비스는 무엇입니까?
AWS Transit Gateway는 여러 VPC, 온프레미스 네트워크, VPN 연결을
하나의 중앙 허브(Cloud Router) 를 통해 연결하는 서비스입니다.
기존의 VPC Peering(1:1 연결) 은 복잡한 Full Mesh 구조를 만들어 관리가 어려웠지만,
Transit Gateway를 사용하면 모든 네트워크가 하나의 허브를 통해 간단히 통신할 수 있습니다.
| 기능 | 설명 |
| 🌐 중앙 라우팅 허브 역할 | 여러 VPC, Direct Connect, VPN을 하나의 게이트웨이로 연결 |
| 🔁 Full Mesh 단순화 | VPC 간 개별 피어링(Peering) 설정 없이 중앙에서 관리 |
| 🧭 라우팅 정책 통합 관리 | 트래픽 라우팅 테이블을 중앙에서 제어 가능 |
| 🔒 보안 제어 및 분리 가능 | 부서별/환경별 라우팅 테이블 분리 운영 가능 |
| 🚀 확장성(Scalability) | 수천 개의 VPC를 연결 가능 (AWS Network Manager 통합 지원) |
기존의 VPC Peering 방식은 복잡한 N² 구조를 가지지만,
Transit Gateway를 사용하면 중앙 허브 형태로 간결하게 연결됩니다.

회사가 여러 부서(VPC)를 운영하며 온프레미스 데이터센터와 연결할 때,
| 기능 | 설명 | 오답 이유 |
| A. AWS Direct Connect | 온프레미스 ↔ AWS 간 전용 네트워크 연결 | ❌ 피어링 단순화 기능 없음 |
| C. Amazon Connect | 고객센터용 클라우드 콜센터 서비스 | ❌ 네트워크와 무관 |
| D. Amazon Route 53 | DNS 관리 및 도메인 라우팅 서비스 | ❌ 네트워크 피어링이나 라우팅 허브 기능 없음 |
🔄 여러 VPC와 온프레미스 네트워크를 하나의 중앙 허브로 연결하려면 AWS Transit Gateway를 사용합니다 — “Cloud Router” 역할을 수행합니다.
온프레미스 시스템에 대한 저지연(로우 레이턴시) 접근과 데이터 상주(Data Residency) 요구사항을 동시에 충족해야 하는 상황을 묻고 있습니다.
Which AWS service should the company use to design a solution that meets these requirements?
“로우 레이턴시(저지연) + 데이터 상주(데이터가 회사 내에 머무를 것)”
👉 어떤 AWS 서비스를 사용해야 할까요?
AWS Outposts는 AWS 인프라, 서비스, API, 툴을
고객의 온프레미스 데이터센터 또는 로컬 환경에 물리적으로 설치하여
AWS 클라우드와 동일한 경험을 제공하는 하이브리드 클라우드 솔루션입니다.
즉,
“온프레미스에서 AWS를 그대로 사용하는 서비스” 입니다.
| 항목 | 설명 |
| ⚙️ 온프레미스 설치형 AWS 인프라 | AWS에서 제공하는 하드웨어 랙을 고객 데이터센터에 직접 설치 |
| 🔁 AWS와 완전 통합 | EC2, EBS, ECS, EKS, RDS 등 AWS 리소스를 로컬에서 실행 |
| ⚡ 로우 레이턴시(Local Processing) | AWS 리전을 거치지 않고 온프레미스 내부에서 요청 처리 |
| 🧭 데이터 상주(Residency) | 데이터가 물리적으로 고객 환경에 저장됨 (규제 및 보안 요구 충족) |
| ☁️ 하이브리드 아키텍처 구성 가능 | Outposts ↔ AWS 리전 간 네트워킹 및 백업 연동 가능 |

📍 결과:
| 시나리오 | Outposts 사용 이유 |
| 🏭 제조/금융/공공기관 | 데이터가 물리적으로 회사 내부에 있어야 하는 경우 (보안/규제) |
| ⚡ 실시간 산업 제어 시스템 | 밀리초(ms) 단위의 저지연 처리가 필요한 경우 |
| 🏥 헬스케어 데이터 저장 | 데이터 상주법(Data Residency Compliance) 준수 필요 시 |
| 🌩️ 하이브리드 배포 | 일부 워크로드는 클라우드, 일부는 온프레미스에 유지 |
| 보기 | 설명 | 오답 이유 |
| A. AWS Wavelength | 5G 엣지 컴퓨팅용 인프라 (통신사 네트워크 내 배치) | ❌ 이동통신 엣지용, 데이터 상주 요건과 무관 |
| B. AWS Transit Gateway | 여러 VPC 및 온프레미스 네트워크를 연결 | ❌ 네트워크 라우팅 용도이지 로우 레이턴시 처리 불가 |
| C. AWS Ground Station | 위성 데이터 송수신 서비스 | ❌ 온프레미스와 무관, 위성 통신용 서비스 |
🧩 AWS Outposts = AWS 인프라를 온프레미스에 직접 설치하여
저지연 처리와 데이터 상주 규제 준수를 동시에 만족시키는 하이브리드 클라우드 솔루션.
Amazon CloudFront에 유입되는 악성 HTTP/HTTPS 요청을 감시하고 차단하는 서비스를 묻는 문제입니다.
Which AWS service should the company use to monitor and block malicious HTTP and HTTPS requests that its Amazon CloudFront distributions receive?
CloudFront로 들어오는 악성 요청(HTTP/HTTPS)을 탐지하고 차단하기 위해 어떤 서비스를 사용해야 할까요?
AWS WAF(Web Application Firewall) 는
웹 애플리케이션 계층(Layer 7) 의 공격으로부터
HTTP 및 HTTPS 트래픽을 필터링, 모니터링, 차단하는 보안 서비스입니다.
| 기능 | 설명 |
| 🛡️ 요청 필터링 (Request Filtering) | IP 주소, HTTP 헤더, URI 경로, 쿼리 문자열 등을 기준으로 트래픽 제어 |
| 🚫 공격 차단 (Attack Protection) | SQL Injection, XSS, HTTP Flood, Bot 등 웹 기반 공격 방어 |
| 🌐 CloudFront / ALB / API Gateway 통합 | CloudFront 배포, ALB, API Gateway, AppSync와 통합 가능 |
| 📊 실시간 모니터링 | CloudWatch Metrics 및 AWS WAF Console에서 트래픽 분석 |
| 🔄 Managed Rules 지원 | AWS 및 보안 파트너가 제공하는 사전 정의된 보안 룰 세트 사용 가능 |

한 회사의 웹사이트가 DDoS나 SQL Injection 공격을 받는다면?
| 보기 | 설명 | 오답 이유 |
| A. Amazon GuardDuty | AWS 계정 및 네트워크 활동을 기반으로 위협 탐지 (ML 기반 이상징후 탐지) | ❌ 네트워크 전체 보안 감시용, HTTP 요청 단위 차단 불가 |
| B. Amazon Inspector | EC2, ECR의 취약점(Vulnerability) 스캔 서비스 | ❌ 트래픽 필터링 기능 없음 |
| D. Amazon Detective | GuardDuty나 CloudTrail 로그를 분석하여 원인 파악 | ❌ 사후 분석용, 실시간 차단 불가 |
🧩 AWS WAF는 CloudFront, ALB, API Gateway에 연결되어
악성 HTTP/HTTPS 요청을 탐지·차단하는 웹 방화벽(Web Application Firewall) 서비스입니다.
“외부 ID 공급자(IdP)를 사용하는 회사가, 별도의 자격 증명 없이 AWS에 접근할 수 있도록 하는 서비스”를 묻고 있습니다.
A company uses a third-party identity provider (IdP).
Which AWS service will meet this requirement?
회사에서 외부 IdP(예: Azure AD, Okta, Google Workspace 등)를 사용 중이며,
직원들이 별도의 로그인 자격 증명 없이 AWS 리소스에 접근할 수 있도록 해야 합니다.
Amazon Cognito는 사용자 인증(Authentication), 권한 부여(Authorization),
그리고 사용자 관리(User Management)를 제공하는 ID 관리 서비스입니다.
특히,
즉,
“AWS 리소스 접근 시 새로운 로그인 정보 없이 기존 계정으로 인증할 수 있다”
👉 바로 Cognito Federated Identity 기능입니다.
| 구성 요소 | 설명 |
| User Pool | 사용자의 등록, 로그인, 인증을 처리하는 사용자 디렉터리 |
| Identity Pool (Federated Identities) | 외부 IdP(Azure AD, SAML, Google 등)를 연결하여 AWS 자격 증명 발급 |

요약:
외부 IdP → Cognito → AWS STS → AWS 리소스 접근
회사가 Google Workspace 를 사용 중이라면,
Cognito를 통해 Google 계정으로 AWS 서비스 로그인 가능.
→ 별도의 IAM 유저 생성 불필요
→ 기존 ID 관리 체계를 그대로 유지
| 보기 | 설명 | 오답 이유 |
| A. AWS Directory Service | Active Directory(AD) 기반 인증 서비스 | ❌ 자체 AD 통합용, 외부 IdP 연동 목적과 다름 |
| C. AWS IAM Identity Center (SSO) | AWS 계정 간 SSO 및 IdP 연동 지원 | ⚠️ 사실상 이 서비스도 가능하지만, 문제에서는 직원용 로그인 및 외부 IdP 통합 → Cognito가 핵심 |
| D. AWS Resource Access Manager (RAM) | AWS 리소스 공유 서비스 | ❌ 인증 관련 아님 |
🔐 Amazon Cognito는 외부 IdP(Azure AD, Google, Okta 등)와 연동하여
별도의 AWS 자격 증명 없이 기존 계정으로 로그인 가능하게 해주는 서비스입니다.
“반복 가능하고 일관된 인프라 구성(Highly Repeatable Infrastructure Configurations)”을 가능하게 하는 AWS 서비스를 묻고 있습니다.
Which AWS service gives users the ability to deploy highly repeatable infrastructure configurations?
반복적이고 예측 가능한 방식으로 인프라를 배포하려면 어떤 AWS 서비스를 사용해야 할까요?
AWS CloudFormation은 인프라를 코드로 관리 (IaC, Infrastructure as Code) 할 수 있는 서비스입니다.
즉, YAML 또는 JSON 템플릿을 통해 AWS 리소스를 반복적이고 일관되게 배포할 수 있습니다.
| 개념 | 설명 |
| 📄 템플릿(Template) | EC2, VPC, S3, RDS 등 리소스 정의를 코드로 기술 |
| 🧱 스택(Stack) | 템플릿을 실행해 실제로 생성된 리소스 묶음 |
| 🔁 반복 가능성(Repeatability) | 동일한 템플릿으로 여러 환경(Dev/Test/Prod)을 일관되게 배포 가능 |
| 💥 자동 롤백 | 배포 실패 시 이전 상태로 자동 복구 |
| 🔐 버전 관리 및 협업 가능 | GitHub 등과 연동하여 IaC 파이프라인 구축 가능 |
AWSTemplateFormatVersion: '2010-09-09'
Description: Simple EC2 instance template
Resources:
MyEC2Instance:
Type: AWS::EC2::Instance
Properties:
InstanceType: t3.micro
ImageId: ami-0abcdef1234567890
Tags:
- Key: Name
Value: MyCFNInstance
➡️ 위 템플릿을 실행하면 동일한 EC2 인스턴스를 여러 번 반복적으로 배포 가능합니다.
개발팀, 테스트팀, 운영팀이 동일한 아키텍처를 각각의 환경에 구축해야 할 때
CloudFormation 템플릿 하나로 Dev/Test/Prod 환경을 쉽게 복제 가능
| 보기 | 설명 | 오답 이유 |
| B. AWS CodeDeploy | 애플리케이션 배포 자동화 서비스 | ❌ 인프라 구성 관리가 아닌 애플리케이션 배포 목적 |
| C. AWS CodeBuild | 애플리케이션 빌드 및 테스트 자동화 서비스 | ❌ CI/CD 빌드 파이프라인 용도 |
| D. AWS Systems Manager | EC2 및 하이브리드 환경 관리 서비스 | ❌ 인프라 생성/배포가 아닌 운영 관리 목적 |
🧩 AWS CloudFormation은 인프라를 코드(YAML/JSON)로 정의하여
반복적이고 자동화된 방식으로 AWS 리소스를 일관되게 배포할 수 있게 해주는 서비스입니다.
음성 통화(Voice Calls) 및 웹 채팅(Web Chat) 기능을 활용한 고객 서비스 제공에 적합한 AWS 서비스를 묻고 있습니다.
A company needs to provide customer service by using voice calls and web chat features.
Which AWS service should the company use to meet these requirements?
음성 통화 및 웹 채팅 기능으로 고객 상담 서비스를 제공해야 합니다.
어떤 AWS 서비스를 사용해야 할까요?
Amazon Connect는 클라우드 기반 컨택 센터(Contact Center) 서비스로,
음성 통화, 채팅, 상담 워크플로우를 손쉽게 구성할 수 있는 AWS 서비스입니다.
즉, 고객이 전화나 채팅으로 문의할 때 상담원과 연결해주는
콜센터 솔루션을 AWS에서 완전관리형(fully managed) 형태로 제공합니다.
| 기능 | 설명 |
| ☎️ 음성 통화 (Voice Calls) | 고객이 웹사이트나 앱을 통해 상담원과 직접 통화 가능 |
| 💬 웹 채팅 (Web Chat) | 실시간 웹 채팅 기능으로 고객 문의 대응 가능 |
| 🤖 Amazon Lex 연동 | AI 챗봇을 통한 자동화된 고객 응답 지원 |
| 📞 컨택 루팅(Contact Routing) | 고객의 요청 유형, 우선순위, 상담원 스킬 기반 자동 연결 |
| 📊 분석 기능 | Amazon Kinesis, QuickSight 등과 연동하여 상담 데이터 분석 가능 |
| 🧠 AI/ML 기반 인사이트 | Amazon Transcribe, Comprehend와 연동하여 감정 분석 및 대화 요약 가능 |

예를 들어, 온라인 쇼핑몰에서 고객이
“배송이 지연되었어요” 라고 채팅하거나 전화를 걸면,
Amazon Connect가 Amazon Lex를 통해 자동 응답 후,
필요 시 상담원에게 연결합니다.
| 보기 | 설명 | 오답 이유 |
| A. Amazon Aurora | 고성능 관계형 데이터베이스 서비스 | ❌ 고객 상담 기능과 관련 없음 |
| C. Amazon WorkSpaces | 가상 데스크톱 서비스 | ❌ 내부 직원용 원격 근무 환경 제공용 |
| D. AWS Organizations | 다중 계정 관리 서비스 | ❌ 고객 서비스 기능과 무관 |
🎧 Amazon Connect는 AWS의 클라우드 기반 컨택 센터(Contact Center) 서비스로,
음성 통화·웹 채팅·AI 챗봇 통합 기능을 통해
고객 지원(Customer Service) 을 쉽고 빠르게 구축할 수 있습니다.
VPC 내에서 서브넷(subnet) 수준의 방화벽 역할을 하는 기능을 묻고 있습니다.
Which AWS tool or feature acts as a VPC firewall at the subnet level?
서브넷 수준에서 VPC 방화벽 역할을 하는 AWS 도구 또는 기능은 무엇입니까?
Network ACL은 서브넷(Subnet) 수준에서 트래픽을 제어하는 방화벽 역할을 합니다.
| 항목 | Network ACL (NACL) | Security Group (보안 그룹) |
| 적용 수준 | 서브넷(Subnet) 수준 | 인스턴스(EC2) 수준 |
| 상태 저장 여부 | ❌ 비상태 저장 (Stateless) → Inbound/Outbound 규칙 모두 설정 필요 | ✅ 상태 저장 (Stateful) → 한쪽만 설정해도 반대 방향 자동 허용 |
| 규칙 평가 방식 | 번호 순서대로(낮은 번호 우선) 평가 | 모든 규칙이 동시에 평가됨 |
| 허용/거부 | 허용(Allow) + 거부(Deny) 모두 가능 | 허용(Allow)만 가능 |
| 기본 설정 | 모든 트래픽 허용 | 모든 트래픽 거부 |

회사가 VPC 내 Public Subnet과 Private Subnet 간 통신을 제한하려고 할 때
Network ACL을 설정하여 특정 포트(예: 22, 80) 만 허용하고 나머지는 차단할 수 있습니다.
| 보기 | 설명 | 오답 이유 |
| A. Security group | 인스턴스 수준의 가상 방화벽 | ❌ 서브넷 단위가 아니라 인스턴스 단위 |
| C. Traffic Mirroring | 네트워크 트래픽 복제 기능 | ❌ 보안 모니터링용, 방화벽 아님 |
| D. Internet gateway | VPC와 인터넷 연결 게이트웨이 | ❌ 방화벽 기능이 없음 |
🧱 Network ACL은 서브넷 단위의 방화벽으로,
인바운드/아웃바운드 트래픽을 허용 또는 거부 규칙으로 제어하는
비상태(stateless) 보안 레이어입니다.
모놀리식(monolithic) 애플리케이션을 마이크로서비스(MSA) 로 분리해 AWS로 이전하는 전략을 묻고 있습니다.
A company is planning to migrate a monolithic application to AWS.
The company wants to modernize the application by splitting it into microservices.
Which migration strategy should the company use?
회사는 모놀리식 애플리케이션을 AWS로 마이그레이션할 계획이며,
이를 마이크로서비스 아키텍처로 현대화(modernize) 하려고 합니다.
어떤 마이그레이션 전략을 사용해야 할까요?
Refactor (또는 Re-architect) 는 애플리케이션 아키텍처를 근본적으로 재설계하여
클라우드 네이티브 기능과 확장성을 극대화하는 가장 현대적인 마이그레이션 전략입니다.
| 항목 | 설명 |
| 🎯 목적 | 기존 애플리케이션의 구조와 코드를 변경하여 클라우드 최적화 |
| 🧩 예시 | 모놀리식 앱 → 마이크로서비스 아키텍처 (MSA) 로 전환 |
| ⚙️ 적용 서비스 예시 | Amazon ECS / EKS / Lambda / API Gateway / DynamoDB 등 |
| 💪 장점 | 확장성(Scalability), 탄력성(Elasticity), 비용 효율성, 배포 자동화 |
| ⏳ 단점 | 높은 개발 리소스와 시간이 필요 (코드 변경 많음) |

| 보기 | 설명 | 오답 이유 |
| A. Rehost (재호스팅) | “Lift & Shift” 방식 — 코드를 변경하지 않고 AWS로 옮김 | ❌ 현대화나 MSA 분리 불가능 |
| B. Repurchase (환매) | SaaS 솔루션으로 교체 (예: CRM → Salesforce) | ❌ 자체 애플리케이션 코드 유지 불가 |
| C. Replatform (플랫폼 교체) | 일부 수정만 하여 클라우드로 이전 (예: DB를 RDS로 변경) | ❌ 아키텍처 변경이 아닌 최소 수정 수준 |
| ✅ D. Refactor (리팩터링) | 애플리케이션 구조를 완전히 재설계하여 마이크로서비스로 전환 | ✅ 현대화(modernization) 목적에 가장 적합 |
| 전략 | 설명 | 코드 수정 정도 |
| 1️⃣ Rehost | Lift & Shift – 코드 변경 없이 AWS로 이동 | 🔹 낮음 |
| 2️⃣ Replatform | 일부 구성 수정 후 이동 (DB, 미들웨어 교체 등) | 🔸 보통 |
| 3️⃣ Repurchase | SaaS로 전환 (예: ERP → Workday) | 🔸 보통 |
| 4️⃣ Refactor / Re-architect | 아키텍처 변경 (모놀리식 → MSA) | 🔺 높음 |
| 5️⃣ Retire | 사용하지 않는 애플리케이션 종료 | ❌ |
| 6️⃣ Retain | 온프레미스에 유지 | ❌ |
| 7️⃣ Relocate | VMware → AWS (VM 수준 이전) | 🔹 낮음 |
🧠 Refactor는 모놀리식 애플리케이션을 마이크로서비스 아키텍처(MSA) 로 재설계하여
AWS의 클라우드 네이티브 기능을 최대한 활용하는 현대화 전략입니다.
| [AWS CLF-C02] Q601 ~ Q719 오답노트 5EA (0) | 2025.10.24 |
|---|---|
| [AWS CLF-C02] Q501 ~ Q600 오답노트 5EA (0) | 2025.10.22 |
| [AWS CLF-C02] Q301 ~ Q400 오답노트 6EA (0) | 2025.10.18 |
| [AWS CLF-C02] Q251 ~ Q300 오답노트 2EA (0) | 2025.10.16 |
| [AWS CLF-C02] Q201 ~ Q250 오답노트 10EA (0) | 2025.10.14 |
Which options are AWS Cloud Adoption Framework (AWS CAF) cloud transformation journey recommendations? (Choose two)
AWS CAF(Cloud Adoption Framework) 클라우드 전환 여정 권장 사항은 어떤 단계입니까? (2개 선택)
AWS CAF는 조직이 클라우드로 성공적으로 전환(Cloud Transformation) 하도록 돕기 위한 전략적 프레임워크입니다.
즉, 단순히 기술 이전(migration)만이 아니라 조직, 인력, 거버넌스, 비즈니스 프로세스 전반을 고려합니다.
| 단계 | 주요 목적 | 주요 활동 |
| 1️⃣ Envision Phase (구상 단계) | 비즈니스 목표를 명확히 정의 | - 클라우드 전환의 비전 수립 - 비즈니스 가치 정의 - 리더십 참여 확보 |
| 2️⃣ Align Phase (정렬 단계) | 조직·기술·프로세스를 전환 목표에 맞춤 | - 조직 역량과 클라우드 목표를 정렬 - Cloud Operating Model 정의 - 거버넌스와 역할 분담 설정 |
| 3️⃣ Launch/Mobilize Phase (실행 준비 단계) | 실제 마이그레이션 실행 준비 | - 클라우드 센터 오브 엑설런스(CCoE) 구성 - 초기 워크로드 이전 - 보안/운영 기반 강화 |
| 보기 | 설명 | 비고 |
| C. Assess phase | AWS CAF의 공식 단계가 아님. (기존 CAF 2.x 버전에서는 일부 사용) | ❌ |
| D. Mobilize phase | CAF 단계가 아니라 AWS Migration Acceleration Program (MAP) 단계임 | ❌ |
| E. Migrate and modernize phase | 역시 MAP 모델의 단계 (Mobilize → Migrate & Modernize) | ❌ |
| 구분 | CAF 단계 | 목적 |
| 1️⃣ | Envision | 목표 설정, 비즈니스 가치 식별 |
| 2️⃣ | Align | 조직 및 운영 정렬 |
| 3️⃣ | Launch/Mobilize | 실행 기반 준비 및 초기 이전 |
```mermaid
flowchart LR
A[🏁 Envision Phase<br>비전 수립 및 목표 정의] --> B[⚙️ Align Phase<br>조직·운영 모델 정렬]
B --> C[🚀 Launch/Mobilize Phase<br>실행 기반 및 초기 마이그레이션]
```

AWS CAF의 3단계는 다음과 같습니다:
Envision → Align → Launch (또는 Mobilize)
즉, **“비전을 정립하고 → 조직을 정렬하고 → 실행 준비를 하는 과정”**입니다.
☁️ AWS CAF의 핵심 전환 단계는 Envision → Align → Launch
즉, “비전 정립 → 정렬 → 실행” 의 순서로 클라우드 전환이 이루어집니다.
Amazon EC2 인스턴스 접속 방식을 묻는 대표적인 기초 실무형 문제
A company launched an Amazon EC2 instance with the latest Amazon Linux 2 AMI.
Which actions can a system administrator take to connect to the EC2 instance? (Choose two)
Amazon Linux 2 AMI로 생성된 EC2 인스턴스에 접속하기 위한 방법은 무엇입니까? (2개 선택)
| 보기 | 설명 | 오답 이유 |
| B. Use a Remote Desktop Protocol (RDP) connection. | RDP는 Windows 인스턴스용 접속 방식 | ❌ Amazon Linux에는 해당 안 됨 |
| C. Use AWS Batch. | 배치 처리를 위한 서비스 (컴퓨팅 잡 실행용) | ❌ 접속과 관련 없음 |
| E. Use Amazon Connect. | 콜센터용 클라우드 서비스 | ❌ EC2 접속과 무관 |
| 구분 | 접속 방식 | 사용 조건 |
| EC2 Instance Connect | 브라우저 기반 SSH | 22번 포트 열림, 패키지 설치 |
| Session Manager | 브라우저 기반 세션 | 포트 불필요, SSM Agent 필요 |
| RDP | GUI 원격 접속 | Windows 전용 |
| SSH (CLI) | 키페어 기반 접속 | 22번 포트 열림 |
```mermaid
flowchart TD
A["👩💻 Admin"] -->|🔐 EC2 Instance Connect| B["🐧 Amazon Linux 2 EC2"]
A -->|🧩 SSM Session Manager| B
B -.-> C["🪟 RDP - Windows Only ❌"]
```

☁️ Amazon Linux 2 EC2 인스턴스는
EC2 Instance Connect 또는 SSM Session Manager로 접속할 수 있습니다 —
SSH 포트 유무에 따라 적절히 선택!
AWS Well-Architected Framework 중 Sustainability Pillar (지속 가능성 기둥) 의 핵심 원칙을 묻는 문제입니다.
최근 시험에서 자주 등장하는 유형
Which design principles should a company apply to AWS Cloud workloads to maximize sustainability and minimize environmental impact? (Choose two)
AWS 클라우드 워크로드의 지속 가능성을 극대화하고 환경적 영향을 최소화하기 위한 설계 원칙은 무엇입니까? (2개 선택)
AWS Sustainability Pillar 의 목표는
“최소한의 리소스로 최대의 성능을 달성하여 탄소 배출량과 낭비를 줄이는 것”
입니다 🌱
즉, 효율을 극대화하고, 중복 리소스 및 불필요한 작업을 줄이는 것이 핵심이에요.
📈 → 더 높은 리소스 효율성과 낮은 전력 소비로 지속 가능성 향상
♻️ → 재작업을 줄여 불필요한 컴퓨팅, 스토리지 사용, 네트워크 부하 감소
| 보기 | 설명 | 이유 |
| B. Minimize utilization of Amazon EC2 instances | 리소스를 적게 쓰는 게 아니라, 효율적으로 쓰는 것이 중요 | ❌ EC2를 무조건 줄이면 성능 저하 및 낭비 발생 가능 |
| C. Minimize usage of managed services | 관리형 서비스는 효율을 높여 오히려 탄소 절감을 도와줌 | ❌ 잘못된 접근 |
| D. Force frequent application reinstallations by users | 재설치 과정이 오히려 에너지 낭비 | ❌ 비효율적, 지속 가능성과 반대 |
| 원칙 | 설명 |
| 1️⃣ Region 선택 최적화 | 에너지 효율이 높은 리전 선택 (예: 재생 에너지 비율 높은 리전) |
| 2️⃣ 리소스 활용률 극대화 | Idle 상태 최소화, 오토스케일링 적용 |
| 3️⃣ 고효율 서비스 사용 | Serverless, Managed Service 활용 |
| 4️⃣ 데이터 이동 최소화 | 전송 에너지 절감 |
| 5️⃣ 아키텍처 효율적 설계 | 캐싱, 압축, 병렬 처리 최적화 |
| 6️⃣ 재작업 최소화 | 자동화로 불필요한 재처리 방지 |
```mermaid
flowchart LR
A[🌱 Sustainable Design] --> B[📈 Maximize Resource Utilization]
A --> C[🔁 Reduce Rework & Redundant Tasks]
B --> D[⚙️ Auto Scaling, Right-Sizing]
C --> E[🧩 Automation, Caching]
```

♻️ AWS 지속 가능성의 핵심은
**“적게 쓰는 것”이 아니라, “효율적으로 쓰는 것”**입니다.
In which ways does the AWS Cloud offer lower total cost of ownership (TCO) of computing resources than on-premises data centers? (Choose two)
AWS 클라우드는 어떤 방식으로 온프레미스 데이터 센터보다 컴퓨팅 리소스의 총 소유 비용(TCO)을 낮추나요? (2개 선택)
AWS는 비용 구조 혁신(Cost Model Innovation) 을 통해
온프레미스 대비 TCO(총소유비용, Total Cost of Ownership) 를 획기적으로 낮출 수 있습니다.
그 핵심은 다음 두 가지입니다 👇
📈 효과:
📊 예시:
| 보기 | 설명 | 이유 |
| B. AWS is designed for high availability | 고가용성(HA)은 성능/가용성 이점이지 TCO 절감 요인 아님 | ❌ |
| C. AWS eliminates the need for on-premises IT staff | 인력 감축은 보조적 효과일 수 있으나 TCO 절감의 직접 원리 아님 | ❌ |
| E. AWS offers a single pricing model for EC2 | EC2는 여러 가격 모델 (On-Demand, Spot, Reserved, Savings Plans) 을 제공 | ❌ |
| AWS 비용 절감 메커니즘 | 설명 |
| Pay-as-you-go | 사용한 만큼만 지불, CapEx → OpEx 구조 전환 |
| Economies of scale | AWS 대규모 운영을 통한 지속적 가격 인하 |
| Auto Scaling | 수요에 맞게 자동 확장/축소로 낭비 방지 |
| Managed Services | 유지보수 부담 및 인력 비용 감소 |
```mermaid
flowchart LR
A["💰 On-Premises"] -->|"💵 CapEx - 서버 구매 및 유지비"| C["💸 높은 TCO"]
B["☁️ AWS Cloud"] -->|"⚙️ Pay-as-you-go + 규모의 경제"| D["📉 낮은 TCO"]
```

☁️ AWS의 낮은 TCO 비결 = 초기투자 제거 + 규모의 경제 기반 지속적 가격 인하
Amazon CloudFront의 핵심 기능을 묻는 대표적인 AWS 서비스 구분 문제입니다.
CloudFront, Route 53, ALB(로드 밸런서) 등의 기능을 혼동하지 않도록 정확히 구분해야 합니다.
What does Amazon CloudFront provide?
Amazon CloudFront는 무엇을 제공합니까?
전 세계 사용자에게 짧은 지연시간(low latency) 과 보안성 높은 콘텐츠 전송을 제공합니다.
| 기능 | 설명 |
| 콘텐츠 캐싱(Content Caching) | 엣지 로케이션에 정적/동적 콘텐츠를 저장하여 지연시간 단축 |
| 보안 강화(Security) | AWS Shield, WAF, SSL/TLS 통합 지원 |
| 글로벌 분산 전송(Global Distribution) | 100개 이상의 엣지 로케이션에서 콘텐츠 제공 |
| 통합 보호 | S3, ALB, EC2, API Gateway 등과 직접 통합되어 콘텐츠 배포 |
| Low Latency + High Transfer Speed | 사용자 위치 기반 자동 라우팅으로 빠른 응답 제공 |
| 시나리오 | 설명 |
| 🎬 미디어 스트리밍 | 전 세계에 고화질 비디오를 빠르게 전송 (예: YouTube, Netflix 스타일) |
| 🧑💻 정적 웹사이트 배포 | S3 + CloudFront 조합으로 빠른 웹사이트 제공 |
| 🔐 보안 강화된 API 전송 | API Gateway + CloudFront로 HTTPS 기반 전송 |
| 🌍 글로벌 사용자 대상 앱 | 지리적으로 분산된 사용자에게 최소 대기시간 제공 |
| 보기 | 설명 | 오답 이유 |
| A. Automatic scaling for all resources | 모든 리소스(EC2, RDS 등)에 대해 자동 확장 기능 제공 | 🔸 CloudFront는 콘텐츠 전송 가속화 서비스(CDN) 로, EC2나 ECS 같은 컴퓨팅 리소스를 자동 확장하지 않습니다. 🔸 자동 확장(Auto Scaling) 은 EC2 Auto Scaling 혹은 ECS Service Auto Scaling 이 담당합니다. |
| C. Manage traffic globally (routing types) | 트래픽을 전 세계적으로 라우팅(지연시간, 지리적, 가중치 기반 등) | 🔸 글로벌 트래픽 라우팅은 Amazon Route 53 (DNS 서비스) 의 역할입니다. 🔸 Route 53은 DNS 질의 기반으로 가장 빠른 리전 또는 리소스로 트래픽을 유도하지만, CloudFront는 콘텐츠 캐싱 및 전송 가속화 역할만 수행합니다. |
| D. Automatic distribution across EC2, containers, Lambda | EC2, 컨테이너, Lambda 등으로 자동 트래픽 분산 | 🔸 트래픽 분산(로드 밸런싱)은 Elastic Load Balancer (ALB/NLB) 가 담당합니다. 🔸 CloudFront는 사용자 → 엣지 로케이션 → 오리진(S3, ALB, EC2) 형태로 전달할 뿐, 오리진 내부의 트래픽 분산 기능은 수행하지 않습니다. |
| 서비스 | 주요 역할 | 키워드 |
| CloudFront | 전 세계 콘텐츠 전송 가속 (CDN) | Low latency, Edge Location |
| Route 53 | DNS 기반 라우팅 | Domain, Latency routing, Failover |
| ELB (ALB/NLB) | 애플리케이션 트래픽 분산 | Target group, Load balancing |
| Global Accelerator | TCP/UDP 최적화 네트워킹 | Anycast IP, Static IP |
| 서비스 | 주요 역할 | 핵심 키워드 |
| CloudFront | 전 세계 콘텐츠 전송 가속화 | 🌎 CDN, Edge Location, Caching |
| Route 53 | 글로벌 DNS 기반 트래픽 라우팅 | 🧭 Latency / Geo / Weighted Routing |
| ELB (ALB/NLB) | 애플리케이션 트래픽 분산 | ⚖️ Target Group, Load Balancing |
| Auto Scaling | EC2 등 컴퓨팅 리소스 자동 확장 | 📈 Scale-out / Scale-in |
```mermaid
flowchart LR
A["🌐 Origin - S3 / EC2 / ALB"] -->|"🧠 Cached Copy"| B["🌎 CloudFront Edge Location"]
B -->|"🌍 Content Delivery"| C["👤 Global Users"]
B -.->|"⚡ Low Latency + 🔒 SSL Security"| C
```

🚀 Amazon CloudFront = 빠르고 안전한 글로벌 콘텐츠 전송 네트워크 (CDN)
AWS Cloud Adoption Framework (AWS CAF) 의 6가지 관점(perspectives) 중
Governance 관점에 해당하는 기능(capabilities)을 묻는 문제입니다.
Which AWS Cloud Adoption Framework (AWS CAF) capabilities belong to the governance perspective? (Choose two)
거버넌스 관점에 속하는 AWS Cloud Adoption Framework(AWS CAF) 기능은 무엇입니까? (2개 선택)
AWS CAF는 조직이 클라우드 도입(Cloud Adoption)을 체계적으로 계획하고 실행할 수 있도록
6가지 관점(perspective)으로 나누어 제시하는 프레임워크입니다.
| 관점 (Perspective) | 주요 목표 | 대표 Capabilities (핵심 기능) |
| Business (비즈니스) | 비즈니스 전략 정렬 및 재무 효과 분석 | IT Investment Portfolio Management, Business Case Development |
| People (인적자원) | 인력, 기술, 문화 변화 관리 | Workforce Transformation, Training and Readiness |
| Governance (거버넌스) | 위험, 정책, 포트폴리오 관리 및 프로젝트 통제 | ✅ Program & Project Management, ✅ Risk Management, Portfolio Management |
| Platform (플랫폼) | 클라우드 인프라 설계 및 운영 | Infrastructure, Application, Data Architecture |
| Security (보안) | 보안, 규정 준수, 데이터 보호 | Identity & Access Management, Threat Detection, Incident Response |
| Operations (운영) | IT 서비스 모니터링 및 운영 효율화 | Service Monitoring, Incident Management, Change Management |
Governance 관점은 조직이 클라우드 환경에서
책임, 위험, 의사결정, 프로젝트 수행을 체계적으로 관리하도록 돕는 역할을 합니다.
| Capability | 설명 |
| Program and Project Management | 클라우드 도입 프로젝트를 체계적으로 계획, 실행, 모니터링 |
| Risk Management | 클라우드 도입 시 발생할 수 있는 위험(비용, 일정, 규제 등)을 평가 및 대응 |
| Portfolio Management | IT 자산 및 서비스의 전체 포트폴리오를 관리하고 ROI를 극대화 |
| 보기 | 설명 | 이유 |
| B. Product management | 제품 기능 및 시장 요구를 관리하는 활동 | ❌ Business Perspective에 가깝습니다 |
| C. Portfolio management | 일부 Governance에도 연관되지만, 여기서는 Program/Project & Risk 관리가 더 명확한 정답 | |
| E. Event management | IT 운영상의 이벤트(장애, 변경) 관리 | ❌ Operations Perspective 소속 |
```mermaid
flowchart LR
A["🏛️ Governance Perspective"] --> B["📋 Program & Project Management"]
A --> C["⚖️ Risk Management"]
A --> D["💼 Portfolio Management"]
```

💡 설명
🧭 AWS CAF의 Governance 관점 = 프로젝트 관리와 위험 관리로 클라우드 도입의 방향과 통제를 확립하는 단계
| [AWS CLF-C02] Q501 ~ Q600 오답노트 5EA (0) | 2025.10.22 |
|---|---|
| [AWS CLF-C02] Q401 ~ Q500 오답노트 13EA (0) | 2025.10.19 |
| [AWS CLF-C02] Q251 ~ Q300 오답노트 2EA (0) | 2025.10.16 |
| [AWS CLF-C02] Q201 ~ Q250 오답노트 10EA (0) | 2025.10.14 |
| [AWS CLF-C02] Q151 ~ Q200 오답노트 7EA (0) | 2025.10.14 |
What is a benefit of using AWS serverless computing?
AWS 서버리스 컴퓨팅을 사용하면 어떤 이점이 있습니까?
인프라 관리가 AWS로 오프로드됩니다.
| 항목 | 설명 |
| 서버리스(Serverless) | 사용자는 서버를 직접 관리하지 않고, 코드 실행에만 집중할 수 있는 클라우드 컴퓨팅 모델입니다. |
| 핵심 개념 | - AWS가 인프라(서버 프로비저닝, 확장, 패치, 유지보수)를 자동으로 관리 - 사용자는 비즈니스 로직(코드)만 작성하면 됨 |
| 대표 서비스 | 🔹 AWS Lambda 🔹 Amazon API Gateway 🔹 AWS Fargate (컨테이너용 서버리스) 🔹 Amazon EventBridge, Step Functions |
| 이점 (Benefit) | ✅ 인프라 관리 부담 감소 (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
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]
```

☁️ 서버리스의 가장 큰 장점은 인프라 관리가 필요 없다는 것!
개발자는 코드 실행과 비즈니스 로직에만 집중하면 됩니다.
Which of the following is the customer’s responsibility under the AWS shared responsibility model? (Choose two)
다음 중 AWS 공유 책임 모델에 따른 고객의 책임은 무엇입니까?
(2개 선택)
AWS 공유 책임 모델에서는
보안(Security) 과 컴플라이언스(Compliance) 에 대해
AWS와 고객이 각각 나누어 책임을 집니다.
“클라우드 자체의 보안”
| 항목 | 설명 |
| 인프라 보안 | 데이터센터, 서버, 스토리지, 네트워크 장비 등 |
| 물리적 보안 | 출입 통제, 전력, 냉각, 하드웨어 유지보수 |
| 가용성 관리 | 리전·AZ 관리, 하이퍼바이저 보안 |
“클라우드 내부의 보안”
| 항목 | 설명 |
| 게스트 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
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]
```

☁️ AWS는 클라우드 인프라를 보호하고,
👩💻 고객은 클라우드 내부의 설정·데이터·암호화를 관리합니다.
| [AWS CLF-C02] Q401 ~ Q500 오답노트 13EA (0) | 2025.10.19 |
|---|---|
| [AWS CLF-C02] Q301 ~ Q400 오답노트 6EA (0) | 2025.10.18 |
| [AWS CLF-C02] Q201 ~ Q250 오답노트 10EA (0) | 2025.10.14 |
| [AWS CLF-C02] Q151 ~ Q200 오답노트 7EA (0) | 2025.10.14 |
| [AWS CLF-C02] Q101 ~ Q150 오답노트 7EA (0) | 2025.10.10 |
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
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 글로벌 네트워크를 통한 저지연 트래픽 전송
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 클라우드에서 용량을 확장하는 방법은 무엇입니까?
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. | 인스턴스 간 CPU 공유 불가능 | ❌ AWS는 자원 격리 모델을 유지함 |
| 구분 | 내용 |
| 서비스명 | Amazon EC2 Auto Scaling |
| 주요 기능 | EC2 인스턴스의 수량 자동 조정 (in/out) |
| 트리거 기준 | CPU 사용률, 요청 수, 네트워크 트래픽 등 CloudWatch 지표 |
| 이점 | 고가용성(HA) + 비용 최적화(비수기 자동 축소) |
```mermaid
flowchart LR
A[📈 수요 증가] -->|트래픽 증가| B[Auto Scaling Group]
B -->|Scale Out| C[EC2 인스턴스 추가]
A2[📉 수요 감소] -->|트래픽 감소| B2[Auto Scaling Group]
B2 -->|Scale In| D[EC2 인스턴스 감소]
```

A. Scale the number of EC2 instances in or out automatically, based on demand.
🧩 EC2 Auto Scaling = 수요에 따라 EC2 인스턴스 “개수”를 자동으로 조정하여 가용성과 비용 효율을 극대화한다. 🚀
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
| 서비스 | 역할 | 특징 |
| A. AWS Personal Health Dashboard (PHD) | 고객의 특정 리소스에 영향을 주는 AWS 서비스 상태를 표시 | 로그인 후 개인화된 영향 보고서 제공, CloudWatch 알림 연동 가능 |
| D. AWS Service Health Dashboard (SHD) | 전체 AWS 리전의 공용 서비스 상태를 실시간으로 표시 | AWS 전반적인 장애 여부 파악 가능 (status.aws.amazon.com) |
이 두 가지는 함께 사용하여
| 보기 | 설명 | 왜 오답인가 |
| B. AWS Systems Manager | EC2 인스턴스 및 하이브리드 서버 관리용 | ❌ AWS 인프라 상태 확인 목적이 아님 |
| C. AWS Trusted Advisor | 비용, 보안, 성능 관련 권장사항 제공 | ❌ 서비스 상태 확인과 무관 |
| E. AWS Service Catalog | 사내 표준 서비스 카탈로그 관리용 | ❌ 모니터링 기능 아님 |
```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 → 내 계정 리소스에 영향을 주는 이벤트 확인
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 서비스를 사용해야 합니까?
| 항목 | 설명 |
| 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) |
🧩 AWS DMS = 온프레미스 DB를 AWS RDS나 Aurora로 마이그레이션할 때 사용하는 핵심 서비스 (다운타임 최소화 + 실시간 복제 지원)
What can a user accomplish using AWS CloudTrail?
사용자는 AWS CloudTrail을 사용하여 무엇을 수행할 수 있습니까?
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
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 호출 내역을 모두 기록하여 보안 감사 및 변경 추적을 가능하게 하는 서비스.
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 서비스는 무엇입니까?
| 항목 | 설명 |
| 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가 자동 관리 |
| 구분 | AWS 책임 | 고객 책임 |
| AWS | 물리적 인프라, 하이퍼바이저, 네트워크, 스토리지, 보안 패치 관리 | - |
| 고객 (EC2 사용 시) | OS 업데이트, 패치, 방화벽 설정, 애플리케이션 보안 | ✅ 직접 수행 필요 |
```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는 인프라를, 고객은 인스턴스 내부 환경을 관리한다.)
Which AWS service or feature will search for and identify AWS resources that are shared externally?
외부에서 공유되는 AWS 리소스를 검색하고 식별하는 서비스 또는 기능은 무엇입니까?
| 항목 | 설명 |
| 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
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 리소스를 자동으로 탐지·보고하는 보안 분석 도구입니다.
Which maintenance task is the customer’s responsibility, according to the AWS shared responsibility model?
AWS 공유 책임 모델에 따르면 고객의 책임에 해당하는 유지 관리 작업은 무엇입니까?
| 항목 | 설명 |
| 공유 책임 모델 (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
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 및 애플리케이션의 보안 패치를 책임진다.
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개월 내 신제품 버전을 출시할 예정이며,
트래픽 급증에 대비해 확장 준비 상태를 평가해야 합니다.
어떤 조치를 취해야 할까요?
| 항목 | 설명 |
| 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
flowchart TD
A["🏢 Company (Enterprise Support)"]
--> B["📈 신제품 출시 & 트래픽 급증 예상"]
--> C["🤝 AWS Infrastructure Event Management (IEM)"]
--> D["🧠 아키텍처 검토 및 확장성 평가"]
--> E["✅ 안정적 서비스 운영 및 확장 보장"]
```

🚀 AWS IEM은 대규모 이벤트(런칭, 세일, 캠페인 등)에 대비한 확장성 준비 및 아키텍처 검토를 제공하는 Enterprise Support 전용 서비스입니다.
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에서 운영하려고 합니다.
각 워크로드는 서로 다른 사업부에 속해 있으며,
각 사업부별로 비용을 구분하고 추적하려고 합니다.
최소한의 운영 부담으로 이를 달성하려면 어떤 방법이 가장 좋을까요?
| 항목 | 설명 |
| 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
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를 사용해 사업부별로 계정을 분리하면,
자동으로 비용이 구분되고, 운영 오버헤드를 최소화할 수 있습니다.
| [AWS CLF-C02] Q301 ~ Q400 오답노트 6EA (0) | 2025.10.18 |
|---|---|
| [AWS CLF-C02] Q251 ~ Q300 오답노트 2EA (0) | 2025.10.16 |
| [AWS CLF-C02] Q151 ~ Q200 오답노트 7EA (0) | 2025.10.14 |
| [AWS CLF-C02] Q101 ~ Q150 오답노트 7EA (0) | 2025.10.10 |
| [AWS CLF-C02] Q051 ~ Q100 오답노트 5EA (0) | 2025.10.09 |
DD
| [AWS CLF-C02] Q251 ~ Q300 오답노트 2EA (0) | 2025.10.16 |
|---|---|
| [AWS CLF-C02] Q201 ~ Q250 오답노트 10EA (0) | 2025.10.14 |
| [AWS CLF-C02] Q101 ~ Q150 오답노트 7EA (0) | 2025.10.10 |
| [AWS CLF-C02] Q051 ~ Q100 오답노트 5EA (0) | 2025.10.09 |
| [AWS CLF-C02] Q001 ~ Q050 오답노트 6EA (0) | 2025.10.09 |
Which tasks are the customer’s responsibility, according to the AWS shared responsibility model? (Choose two)
AWS 공유 책임 모델에 따르면 고객의 책임은 무엇입니까? (2개 선택)
B. Perform client-side data encryption
C. Configure IAM credentials
| 선택지 | 설명 |
| B. Perform client-side data encryption | 고객은 데이터 암호화 방식(서버 측, 클라이언트 측, 키 관리 등) 을 직접 선택하고 설정해야 합니다. 즉, 클라이언트 측 암호화(Client-side encryption) 은 고객의 책임입니다. 🔐 |
| C. Configure IAM credentials | IAM 사용자, 그룹, 역할, 정책 설정 및 MFA(다중 인증) 활성화는 모두 고객의 책임입니다. 👤 |
| 보기 | 설명 | 이유 |
| A. Establish the global infrastructure | AWS의 전 세계 데이터센터, 리전, AZ 구축은 AWS가 관리합니다. | ❌ AWS 책임 |
| D. Secure edge locations | CloudFront 같은 엣지 로케이션 보안은 AWS가 담당합니다. | ❌ AWS 책임 |
| E. Patch Amazon RDS DB instances | Amazon RDS는 관리형 서비스(Managed Service) 로, DB 엔진 패치는 AWS가 수행합니다. |
❌ AWS 책임 |
```mermaid
flowchart TD
A["☁️ AWS Responsibility<br>(Security of the Cloud)"] -->|🏗️ 데이터센터, 네트워크, 하드웨어| B["🏢 물리적 보안 & 글로벌 인프라"]
A --> C["🌎 리전, AZ, 엣지 로케이션 관리"]
D["👤 Customer Responsibility<br>(Security in the Cloud)"] -->|🔒 리소스 보안| E["🔑 IAM 설정, 접근 제어, 암호화"]
D -->|💾 데이터 관리| F["🗄️ 클라이언트 측 암호화, 백업, 보안 그룹 구성"]
```

| 구분 | 책임 | 주체 예시 |
| Security of the Cloud | AWS | 리전, AZ, 엣지 로케이션, 하드웨어, 네트워크 |
| Security in the Cloud | 고객 | IAM, 데이터 암호화, 보안 그룹, 애플리케이션 설정 |
AWS는 “클라우드의 보안”을,
고객은 “클라우드 안의 보안”을 책임진다.
즉, IAM과 데이터 암호화는 고객의 몫입니다. 🔒
A developer has been hired by a large company and needs AWS credentials.
Which are security best practices that should be followed? (Choose two)
개발자가 대기업에 새로 입사했으며 AWS 자격 증명이 필요합니다.
어떤 보안 모범 사례를 따라야 합니까? (2개 선택)
A. Grant the developer access to only the AWS resources needed to perform the job.
E. Ensure the account password policy requires a minimum length.
| A. Grant the developer access to only the AWS resources needed to perform the job. | 최소 권한의 원칙(Principle of Least Privilege) — 사용자가 자신의 업무에 필요한 최소한의 리소스에만 접근하도록 IAM 정책을 구성해야 합니다. 👤 |
| E. Ensure the account password policy requires a minimum length. | 강력한 비밀번호 정책(Password Policy) 설정은 IAM 보안의 기본입니다. 최소 길이, 숫자·특수문자 포함 등을 요구해야 합니다. 🔒 |
| B. Share the AWS account root user credentials with the developer. | 루트 계정은 절대 공유하지 않음. MFA를 적용하고 비상시에만 사용해야 함. | ❌ 심각한 보안 위반 |
| C. Add the developer to the administrator’s group. | 관리 권한(AdministratorAccess)은 너무 광범위함. 최소 권한 원칙에 어긋남. | ❌ 잘못된 권한 부여 |
| D. Configure password policy that prevents password changes. | 사용자가 주기적으로 비밀번호를 변경할 수 있어야 함. | ❌ 보안 유연성 결여 |
| 🧱 루트 계정 최소화 | 루트 계정은 오직 결제나 초기 설정용으로만 사용 |
| 🔑 IAM 사용자/역할(Role) 사용 | 개별 IAM 사용자 생성, 필요시 역할 기반 접근 부여 |
| ⚙️ 최소 권한 부여 (Least Privilege) | 업무 수행에 꼭 필요한 권한만 부여 |
| 🔒 MFA(Multi-Factor Authentication) | 루트 계정 및 중요 IAM 사용자에 다중 인증 적용 |
| 🔐 비밀번호 정책 설정 | 최소 길이, 복잡도, 주기적 변경 등 적용 |
| 📊 CloudTrail 활성화 | 모든 IAM/API 활동 로깅 및 감사 추적 유지 |
```mermaid
flowchart TD
A[🔐 IAM Best Practices] --> B[🧱 Root 계정 제한 사용]
A --> C[⚙️ 최소 권한 원칙 적용]
A --> D[🔑 MFA 설정]
A --> E[📏 비밀번호 정책 설정]
A --> F[🧩 IAM Role 및 개별 사용자 생성]
```

IAM 보안의 기본 원칙:
“최소 권한(Least Privilege)” + “강력한 암호 정책(Strong Password Policy)” = 안전한 AWS 계정 🔒
A company has a compute workload that is steady, predictable, and uninterruptible.
Which Amazon EC2 instance purchasing options meet these requirements MOST cost-effectively? (Choose two)
한 회사는 안정적이고 예측 가능하며 중단될 수 없는 컴퓨팅 워크로드를 가지고 있습니다.
이러한 요구사항을 가장 비용 효율적으로 충족하는 EC2 구매 옵션은 무엇입니까? (2개 선택)
B. Reserved Instances
D. Savings Plans
| B. Reserved Instances (RI) | 1년 또는 3년 약정을 통해 EC2 인스턴스를 예약 구매함으로써 On-Demand 대비 최대 72% 절감 가능 | ✔ 장기적이고 예측 가능한 워크로드에 이상적 |
| D. Savings Plans | 1년 또는 3년 약정으로 일정 금액의 컴퓨팅 사용량(commitment)을 약속하고, AWS가 자동으로 가장 저렴한 요금으로 적용 | ✔ 유연성 높음 — EC2, Fargate, Lambda에도 적용 가능 |
| A. On-Demand Instances | 필요할 때 즉시 사용 가능, 약정 없음 | ❌ 장기 사용 시 가장 비쌈 |
| C. Spot Instances | 미사용 EC2 용량을 경매식으로 구매, 90% 저렴 | ❌ 예측 불가, 언제든 중단 가능 — “uninterruptible” 조건에 맞지 않음 |
| E. Dedicated Hosts | 전용 물리 서버 제공 (BYOL 환경 등) | ❌ 보안·규정 준수에는 적합하지만 비용 효율성 낮음 |
| On-Demand | 없음 | 💸 0% | 매우 높음 | 일시적/불규칙적 |
| Reserved Instances (RI) | 1년 / 3년 | 💰 최대 72% | 중간 | 예측 가능, 고정된 워크로드 |
| Savings Plans | 1년 / 3년 | 💰 최대 72% | 매우 높음 | 예측 가능, 유연한 환경 |
| Spot Instances | 없음 | 💰 최대 90% | 낮음 | 비핵심, 중단 가능 작업 |
| Dedicated Hosts | 1년 / 3년 | 💰 낮음 | 제한적 | 규정 준수 / 라이선스 필요 환경 |
```mermaid
graph TD
A[💻 워크로드 특성<br>Steady, Predictable, Uninterruptible] --> B[🏷️ Reserved Instances<br>1~3년 약정, 고정 워크로드에 적합]
A --> C[💡 Savings Plans<br>유연한 약정 기반 할인, 서비스 간 자동 적용]
B -.->|최대 72% 절감| D[💰 Cost Efficient]
C -.->|Flexible + Predictable| D
```

예측 가능한 장기 워크로드에는
💡 “Reserved Instances + Savings Plans” 조합이 가장 경제적이다.
A company wants to migrate its on-premises workloads to the AWS Cloud.
The company wants to separate workloads for chargeback to different departments.
Which AWS services or features will meet these requirements? (Choose two)
회사는 온프레미스 워크로드를 AWS 클라우드로 마이그레이션하려고 합니다.
각 부서별로 워크로드를 분리하고 비용을 부서별로 배분(Chargeback)하려고 합니다.
어떤 AWS 서비스/기능을 사용해야 할까요? (2개 선택)
B. Consolidated Billing
E. Multiple AWS Accounts
| B. Consolidated Billing | AWS Organizations 기능 중 하나로, 여러 계정을 하나의 결제 계정(Payer Account) 아래 통합하여 관리합니다. 각 부서(Linked Account)별 비용 추적 및 비용 절감(볼륨 할인) 효과를 동시에 얻을 수 있습니다. 💰 |
| E. Multiple AWS Accounts | 부서나 프로젝트별로 별도의 계정(Account) 을 생성하면, 리소스와 과금이 명확히 분리되어 Chargeback(비용 배분) 이 용이합니다. 🧩 |
| A. Placement groups | EC2 인스턴스 간 물리적 배치 전략(Cluster, Spread, Partition)을 지정하는 기능 | ❌ 비용이나 부서 분리와 무관 |
| C. Edge locations | CloudFront 콘텐츠 전송을 위한 전 세계 CDN 노드 | ❌ 비용 관리와 무관 |
| D. AWS Config | 리소스 구성을 추적하고 규정 준수 여부를 평가하는 서비스 | ❌ 비용 관리 목적이 아님 |
| AWS Organizations | 여러 AWS 계정을 중앙에서 생성·관리·통제할 수 있는 서비스 |
| Consolidated Billing | 여러 계정의 결제를 통합 관리하면서, 각 계정별로 비용 보고 및 분석 가능 |
| Linked Account 구조 | 루트 계정(Payer Account) + 부서별 연결 계정(Linked Accounts) 구성 |
| Chargeback | 실제 리소스 사용량 기반으로 부서별 비용을 내부 회계에 반영하는 절차 |
```mermaid
flowchart TD
A["🏢 회사 계정 구조"] --> B["🧾 Payer Account<br>Consolidated Billing"]
B --> C["📂 Dept A Account<br>R&D"]
B --> D["📂 Dept B Account<br>Marketing"]
B --> E["📂 Dept C Account<br>Finance"]
B -.-> F["💰 비용 통합 관리 및 청구 보고"]
```

부서별로 비용을 분리하려면
Multiple AWS Accounts + Consolidated Billing (AWS Organizations) 조합이 정답입니다. 🧾
Which options are AWS Cloud Adoption Framework (AWS CAF) security perspective capabilities? (Choose two)
AWS Cloud Adoption Framework(AWS CAF) 보안 관점(Security Perspective)에서 제공하는 기능은 무엇입니까?
(2개 선택)
C. Incident Response
D. Infrastructure Protection
| 선택지 | 설명 |
| C. Incident Response | 보안 사고 발생 시 감지, 대응, 복구 절차를 정의하는 능력입니다. AWS에서는 Amazon GuardDuty, AWS CloudTrail, AWS Security Hub 등을 통해 자동화된 사고 대응을 수행합니다. ⚡ |
| D. Infrastructure Protection | 네트워크, 컴퓨팅, 스토리지, 데이터 계층에서 보안 제어(방화벽, 접근 제어, 암호화 등) 를 구현하는 능력입니다. VPC 보안 그룹, WAF, Shield, NACL 등이 여기에 해당합니다. 🛡️ |
| 보기 | 설명 | 왜 틀렸는가 |
| A. Observability | 운영(Operations Perspective)에 속하는 개념으로, 모니터링과 로깅을 의미합니다. | ❌ 보안 관점 아님 |
| B. Incident and Problem Management | 운영(Operations Perspective) 영역에 포함됨. 문제 관리와 재발 방지 중심 | ❌ 운영 관점 |
| E. Availability and Continuity | 비즈니스 관점(Business Perspective) — 고가용성, 재해 복구 계획 수립 관련 | ❌ 보안이 아닌 비즈니스 연속성 영역 |
| Perspective | 주요 목적 | 주요 Capabilities 예시 |
| Business | 비즈니스 가치 창출, ROI 분석 | IT 재무 관리, 포트폴리오 관리 |
| People | 인재 및 조직 변화 관리 | 리더십 개발, 인재 역량 강화 |
| Governance | 위험 관리 및 규정 준수 | 비용 관리, 정책 및 표준화 |
| Platform | 기술적 기반 구축 | 인프라 자동화, 애플리케이션 포트폴리오 |
| Security | 보안, 규정 준수, 위험 완화 | Incident Response, Infrastructure Protection, Identity & Access Management, Detection |
| Operations | IT 서비스 관리 및 지속적 운영 | 모니터링, 이벤트 관리, 변경 관리 |
```mermaid
flowchart TD
A[🔒 AWS CAF Security Perspective] --> B[🛡️ Infrastructure Protection]
A --> C[🚨 Incident Response]
A --> D[👤 Identity & Access Management]
A --> E[🧠 Detection]
```

AWS CAF의 보안(Security) 관점은 인프라 보호 + 사고 대응 중심이다.
즉, “예방(Protect) + 대응(Respond)” 이 핵심 키워드 🔐
Which AWS services can a company use to achieve a loosely coupled architecture? (Choose two)
느슨하게 결합된 아키텍처를 달성하기 위해 사용할 수 있는 AWS 서비스는 무엇입니까? (2개 선택)
E. AWS Step Functions
| 선택지 | 설명 |
| B. Amazon Simple Queue Service (SQS) | 비동기 메시지 큐 서비스로, 애플리케이션 구성 요소 간의 직접 연결을 제거하여 서비스 간 의존성을 낮추는(Decoupling) 데 핵심적입니다. 📨 |
| E. AWS Step Functions | 서버리스 워크플로우 오케스트레이션 서비스로, 여러 AWS 서비스(Lambda, ECS 등)의 실행 순서를 제어하여 느슨하게 연결된 상태로 구성요소 간 흐름을 관리할 수 있습니다. 🔄 |
| 보기 | 설명 | 왜 틀렸는가 |
| A. Amazon WorkSpaces | 가상 데스크톱(VDI) 서비스 | ❌ 애플리케이션 아키텍처와 무관 |
| C. Amazon Connect | 클라우드 기반 콜센터(Contact Center) 서비스 | ❌ 서비스 간 결합과 관련 없음 |
| D. AWS Trusted Advisor | 비용, 보안, 성능 등 모범 사례 점검 도구 | ❌ 아키텍처 결합도와 무관 |
| 개념 | 설명 |
| Loosely Coupled | 구성 요소들이 독립적으로 작동하여 한 부분의 오류가 전체 시스템에 영향을 주지 않음 |
| Tightly Coupled | 구성 요소가 밀접하게 연결되어 하나의 장애가 전체 시스템에 영향을 줌 |
| AWS 서비스 예시 | SQS (비동기 메시징), SNS (Publish/Subscribe), EventBridge, Step Functions 등 |
```mermaid
flowchart LR
A["🟢 Producer Service"] -->|📤 메시지 전송| B["📦 Amazon SQS Queue"]
B -->|📥 메시지 수신| C["🔵 Consumer Service"]
C -->|🎯 오케스트레이션| D["🧩 AWS Step Functions"]
D --> E["⚙️ Lambda / ECS 등 워크로드"]
```

B. Amazon Simple Queue Service (Amazon SQS)
E. AWS Step Functions
SQS는 서비스 간 비동기 통신으로 결합도를 낮추고,
Step Functions는 여러 워크플로를 느슨하게 연결하여 안정적 오케스트레이션을 제공합니다. 🚀
Which option is a customer responsibility under the AWS shared responsibility model?
AWS 공동 책임 모델에서 고객의 책임에 해당하는 것은 무엇입니까?
AWS와 고객은 각각 클라우드 보안의 다른 측면을 책임집니다.
이를 “Security of the Cloud” (AWS의 책임) vs “Security in the Cloud” (고객의 책임) 으로 구분합니다.
| 구분 | 설명 | 책임 주체 |
| Security of the Cloud | AWS가 클라우드 인프라 자체의 보안을 관리함 (데이터센터, 하드웨어, 네트워크 등) | 🟦 AWS |
| Security in the Cloud | 고객이 클라우드 위에 배포하는 데이터, 애플리케이션, OS 보안 등을 관리함 | 🟩 고객 |
| 보기 | 설명 | 이유 |
| A. Maintenance of underlying hardware of Amazon EC2 instances | 물리적 서버 유지보수 | ❌ AWS의 책임 |
| C. Physical security of data centers | 데이터센터 접근 제어, 전력, 냉각 등 물리적 인프라 보안 | ❌ AWS의 책임 |
| D. Maintenance of VPC components | VPC는 고객이 구성하지만, 기본 인프라는 AWS가 관리 | ❌ VPC 인프라 자체는 AWS 관리, 단 설정은 고객이 관리 |
```mermaid
flowchart LR
A[AWS 책임] --> B[🔒 Security of the Cloud<br>물리적 인프라, 네트워크, 하드웨어]
A2[고객 책임] --> C[🧩 Security in the Cloud<br>데이터, 애플리케이션, IAM, 암호화]
```

AWS는 클라우드 자체를 보호(Security of the Cloud),
고객은 클라우드 내 자산을 보호(Security in the Cloud) 한다. 💡
| [AWS CLF-C02] Q251 ~ Q300 오답노트 2EA (0) | 2025.10.16 |
|---|---|
| [AWS CLF-C02] Q201 ~ Q250 오답노트 10EA (0) | 2025.10.14 |
| [AWS CLF-C02] Q151 ~ Q200 오답노트 7EA (0) | 2025.10.14 |
| [AWS CLF-C02] Q051 ~ Q100 오답노트 5EA (0) | 2025.10.09 |
| [AWS CLF-C02] Q001 ~ Q050 오답노트 6EA (0) | 2025.10.09 |
Amazon EC2 인스턴스에 대해 재해 복구(Disaster Recovery) 기능을 제공하는 AWS 서비스 또는 기능은 무엇입니까?
(2개 선택)
B. EC2 Amazon Machine Images (AMIs)
C. Amazon Elastic Block Store (EBS) snapshots
| 선택지 | 설명 |
| B. EC2 Amazon Machine Images (AMIs) | EC2 인스턴스 구성을 이미지로 저장하는 기능. OS, 애플리케이션, 설정 등을 포함하여 언제든 동일한 인스턴스를 복원 가능. |
| C. Amazon Elastic Block Store (EBS) snapshots | EC2에 연결된 EBS 볼륨을 백업하는 기능. 스냅샷을 S3에 저장하여 데이터 손실 시 복원 가능. |
🧠 즉, AMI는 인스턴스 자체를 복제해 복구하고,
EBS Snapshot은 데이터 디스크를 백업해 복구합니다.
| 보기 | 설명 | 왜 틀렸는가 |
| A. EC2 Reserved Instances | 장기 예약 인스턴스로 비용 절감용 | 복구 기능 아님 ❌ |
| D. AWS Shield | DDoS 공격 방어용 서비스 | 복구(backup/restore)와 무관 ❌ |
| E. Amazon GuardDuty | 위협 탐지 서비스 | 복원 기능 없음 ❌ |
```mermaid
flowchart TD
A[💻 EC2 Instance] --> B[🖼️ Create AMI Image]
A --> C[📦 EBS Volume]
C --> D[📸 Take EBS Snapshot]
B --> E[☁️ Backup stored in S3]
D --> E
E --> F[🔄 Restore to new EC2 instance when needed]
```

| 기능 | 목적 | 주요 사용 시점 |
| AMI (Amazon Machine Image) | 인스턴스 전체 복제/재생성 | 시스템 장애, 새 리전 복구 |
| EBS Snapshot | 데이터 볼륨 백업 | 주기적 백업, DR 복원 |
| S3 Cross-Region Copy | 지역 간 백업 복제 | 다중 리전 DR 구성 |
EC2 재해 복구의 기본은 AMI + EBS Snapshot
→ 시스템 이미지 복원 + 데이터 복원 조합이 완벽한 DR 전략! 💪
AWS 클라우드 서비스에 대한 통합 결제(Consolidated Billing) 의 장점은 무엇입니까?
(2개 선택)
A. Volume discounts
C. One bill for multiple accounts
| 선택지 | 설명 |
| A. Volume discounts (볼륨 할인) | 여러 계정의 사용량을 합산해 계산하기 때문에, 총 사용량이 커질수록 더 높은 할인 혜택을 받음 (예: S3, EC2, 데이터 전송 등) |
| C. One bill for multiple accounts (여러 계정에 대한 단일 청구서) | 여러 AWS 계정을 한 조직으로 묶어 하나의 청구서로 비용을 관리 가능 — 회계 및 결제 관리 간소화 |
| 보기 | 설명 | 왜 틀렸는가 |
| B. A minimal additional fee for use | 통합 결제는 무료 기능 | 추가 요금 없음 ❌ |
| D. Installment payment options | AWS는 할부 결제 옵션 없음 | ❌ |
| E. Custom cost and usage budget creation | 이는 AWS Budgets 기능에 해당 | 통합 결제와 별개 ❌ |
```mermaid
flowchart TD
A1[👥 여러 AWS 계정] --> B1[🏢 AWS Organizations]
B1 --> C1[💳 Consolidated Billing]
C1 --> D1[🧾 하나의 청구서로 통합 관리]
C1 --> E1[💰 합산 사용량 기준으로 Volume Discount 적용]
```

| 항목 | 설명 |
| 🔹 서비스 | AWS Organizations → Consolidated Billing 기능 |
| 🔹 주요 장점 | ① 단일 청구서 관리 ② 볼륨 할인 공유 |
| 🔹 추가 비용 | 없음 (Free Feature) |
| 🔹 연계 기능 | AWS Budgets, Cost Explorer, Cost Anomaly Detection |
“통합 결제(Consolidated Billing)”은
여러 계정을 묶어 한 번에 결제하고,
전체 사용량 기준으로 볼륨 할인 혜택을 받는 무료 기능입니다. 💳💰
AWS 클라우드로 이전했을 때 얻을 수 있는 이점(advantages) 은 무엇입니까?
(2개 선택)
B. The ability to use the pay-as-you-go model.
D. No longer having to guess what capacity will be required.
| 선택지 | 설명 |
| B. The ability to use the pay-as-you-go model | AWS의 핵심 결제 방식으로, 사용한 만큼만 비용을 지불(pay-as-you-go) 합니다. 초기 하드웨어 투자비용(CAPEX)이 필요 없습니다. 💰 |
| D. No longer having to guess what capacity will be required | AWS는 Auto Scaling 및 On-Demand 모델을 통해 수요에 맞춰 자동으로 용량 조정이 가능하므로, 기존처럼 인프라 용량을 미리 예측할 필요가 없습니다. ⚙️ |
| 보기 | 왜 틀렸는가 설명 |
| A. Turn over all security responsibility to AWS | ❌ AWS는 공유 책임 모델(Shared Responsibility Model) 에 따라 보안 책임을 고객과 분담합니다. AWS가 전부 맡지 않음. |
| C. Full control over physical infrastructure | ❌ 클라우드 사용자는 물리적 인프라에 접근할 수 없음. AWS가 관리합니다. |
| E. No longer worrying about users access controls | ❌ IAM 등 사용자 접근 권한 관리는 여전히 고객의 책임입니다. |
```mermaid
flowchart TD
A["🏢 On-Premise 환경"] -->|🚚 Migration| B["☁️ AWS Cloud"]
B --> C1["💳 Pay-as-you-go<br>요금제 모델"]
B --> C2["⚙️ Elastic Capacity<br>탄력적 용량"]
C1 --> D1["💰 비용 효율성<br>(Cost Optimization)"]
C2 --> D2["📈 탄력적 확장<br>(Scalability)"]
```

| 항목 | 내용 |
| 💰 비용 효율성 | 사용량 기반 과금(pay-as-you-go), 초기 투자비용 없음 |
| ⚙️ 유연성 & 확장성 | 자동 확장, 수요 기반 자원 조정 |
| 🚀 민첩성(Agility) | 빠른 배포 및 프로비저닝 |
| 🔒 보안 | AWS와 고객의 공유 책임 모델에 따라 분담 |
AWS 클라우드의 가장 큰 장점은
“비용 효율성(Pay-as-you-go)” + “유연한 확장성(Elastic Capacity)” 입니다. 🌩️
AWS 클라우드 컴퓨팅은 기업이 비용을 절감하는 데 어떻게 도움을 주나요?
(2개 선택)
B. AWS enables capacity to be adjusted on demand
E. AWS eliminates many of the costs of building and maintaining on-premises data centers
| 선택지 | 설명 |
| B. AWS enables capacity to be adjusted on demand | 클라우드는 수요에 맞춰 자원을 즉시 확장/축소(Elasticity) 할 수 있습니다. 즉, 불필요한 리소스를 유지하지 않아 낭비되는 비용을 절약할 수 있습니다. ⚙️ |
| E. AWS eliminates many of the costs of building and maintaining on-premises data centers | 기업은 물리적 서버, 냉각 장치, 보안, 전력, 인프라 유지보수 등에 대한 CapEx(자본적 지출) 을 제거하고, OpEx(운영비용) 구조로 전환할 수 있습니다. 💰 |
| 보기 | 왜 틀렸는가 설명 |
| A. Same prices in every Region | ❌ AWS는 지역(Region)에 따라 서비스 비용이 다름. (예: 서울 리전 vs 버지니아 리전) |
| C. Discounts for idle EC2s | ❌ EC2 인스턴스가 유휴 상태일 때는 할인 없음. 오히려 계속 비용 발생. |
| D. No data transfer cost to the Internet | ❌ AWS → Internet으로 나가는 아웃바운드 트래픽은 요금 부과됨. (단, AWS 내 전송은 일부 무료) |
```mermaid
flowchart TD
A[🏢 On-Premises Data Center] -->|🚚 Migration| B[☁️ AWS Cloud]
B --> C1[⚙️ On-Demand Capacity Scaling]
B --> C2[💰 No Upfront Hardware Costs]
C1 --> D1[📉 Pay only for what you use]
C2 --> D2[🏗️ Remove CapEx, use OpEx]
```

| 항목 | 내용 |
| 💡 비용 구조 변화 | CAPEX → OPEX (선투자 → 사용량 기반 지출) |
| ⚙️ 탄력적 확장(Elasticity) | 필요한 만큼만 사용, 불필요한 리소스 제거 |
| 💳 요금제 모델 | Pay-as-you-go (사용한 만큼 지불) |
| 🏗️ 온프레미스 제거 효과 | 데이터센터 구축·유지보수 비용 절감 |
AWS는 탄력적 확장(On-Demand Capacity) 과
온프레미스 제거(CapEx 절감) 를 통해
기업의 비용 효율성(Cost Efficiency) 을 극대화합니다. 🚀
AWS 서비스를 사용할 때, AWS가 책임지는 영역은 무엇입니까?
AWS와 고객은 보안 책임을 공유(Shared Responsibility) 합니다.
AWS는 클라우드 “안의” 보안(Security of the Cloud) 을,
고객은 클라우드 “내의” 보안(Security in the Cloud) 을 담당합니다.
| 영역 | 설명 |
| 🏗️ 물리적 보안 (Physical Security) | 데이터센터 출입 통제, 감시 시스템, 전력 공급, 냉각 등 |
| 🌎 환경적 제어 (Environmental Controls) | 화재 감지, 냉각, 전력 이중화 등 인프라 유지 |
| 🧱 하드웨어 및 네트워크 인프라 관리 | 서버, 스토리지, 네트워크 장비 유지 및 보안 |
| 🧩 하이퍼바이저 및 물리적 호스트 관리 | EC2, EBS, RDS 등을 구동하는 인프라 계층 운영 |
| 영역 | 설명 |
| 👤 IAM 사용자 및 권한 관리 | 사용자, 그룹, 역할, 정책 생성 및 MFA 설정 |
| 🔒 보안 그룹 / 네트워크 ACL 설정 | 인바운드·아웃바운드 트래픽 제어 |
| 💻 OS 및 애플리케이션 패치 적용 | EC2 인스턴스의 OS, DB, 미들웨어 업데이트 |
| 📦 데이터 암호화 및 백업 | S3, RDS, DynamoDB 등 데이터 암호화 관리 |
| 보기 | 설명 | 이유 |
| A. Management of IAM user permissions | IAM은 고객이 직접 관리 | ❌ 고객 책임 |
| B. Creation of security group rules | 네트워크 접근 제어도 고객 설정 | ❌ 고객 책임 |
| D. Application of EC2 OS patches | OS는 EC2 사용자 영역 | ❌ 고객 책임 |
```mermaid
flowchart TD
A["☁️ AWS Responsibility<br>(Security of the Cloud)"] -->|🏗️ 데이터센터, 하드웨어, 네트워크| B["🏢 물리적 & 환경적 제어"]
A -->|🧱 인프라 계층| C["⚙️ 하이퍼바이저 및 인프라 유지"]
D["👤 Customer Responsibility<br>(Security in the Cloud)"] -->|🔒 리소스 보안| E["🧰 IAM, 보안 그룹, 패치 관리"]
D -->|💾 데이터 관리| F["🗄️ 암호화 및 백업"]
```

AWS는 “클라우드 자체의 보안(Security of the Cloud)” 을 담당하고,
사용자는 “클라우드 내부의 보안(Security in the Cloud)” 을 관리해야 합니다. 🔒
| [AWS CLF-C02] Q251 ~ Q300 오답노트 2EA (0) | 2025.10.16 |
|---|---|
| [AWS CLF-C02] Q201 ~ Q250 오답노트 10EA (0) | 2025.10.14 |
| [AWS CLF-C02] Q151 ~ Q200 오답노트 7EA (0) | 2025.10.14 |
| [AWS CLF-C02] Q101 ~ Q150 오답노트 7EA (0) | 2025.10.10 |
| [AWS CLF-C02] Q001 ~ Q050 오답노트 6EA (0) | 2025.10.09 |
| A. Amazon S3 버킷을 사용자별로 생성 | 각 사용자가 직접 S3 버킷을 마운트 | 관리 복잡성 높고, 로컬 캐싱 없음 → 비효율적 ❌ |
| C. Amazon WorkSpaces + WorkDocs | 클라우드 기반 가상 데스크탑 & 문서 협업 서비스 | 단순 파일 저장/공유 시 오버엔지니어링 ❌ |
| D. EC2 + EBS 공유 | EBS를 EC2에 연결해 네트워크 공유 | EBS는 인스턴스 전용 스토리지로 여러 사용자 공유 불가 ❌ |
| 로컬 접근 속도 | ✅ 빠름 (캐시) | ❌ 느림 | ⚙️ 제한적 | ⚙️ 제한적 |
| AWS 확장성 | ✅ 자동 확장 | ✅ 자동 확장 | ⚙️ 문서 중심 | ⚙️ 제한적 |
| 운영 효율성 | ✅ 가장 높음 | ❌ 사용자별 관리 필요 | ❌ 관리 오버헤드 | ❌ 기술적 제약 |
| 권장 사례 | 파일 서버 확장 | 단순 백업 | 협업 문서 관리 | 블록 스토리지 전용 |
“온프레미스에서 사용 중인 파일 서버를 클라우드로 확장하려면
AWS Storage Gateway File Gateway를 사용하여
로컬 캐시 성능을 유지하면서 S3에 확장 저장소를 구축하라.”
✅ 정답: B. AWS Storage Gateway File Gateway
☁️ 핵심 개념: 하이브리드 파일 스토리지 확장 + 로컬 캐싱 + S3 연동
VPC(가상 사설 클라우드) 내에 Internet Gateway(IGW)를 추가하는 이유는?
VPC와 인터넷 간의 양방향 통신을 가능하게 하기 위함이다.
| 보기 | 설명 | 왜 틀렸는가 |
| A. To create a VPN connection to the VPC | VPN 연결은 Virtual Private Gateway (VGW) 로 구성 | IGW는 VPN용이 아님 ❌ |
| B. To allow communication between the VPC and the internet | VPC ↔ 인터넷 트래픽 허용 | ✅ 정답 |
| C. To impose bandwidth constraints | 대역폭 제한은 IGW가 아닌 Network ACL, QoS 정책 등에서 설정 | ❌ |
| D. To load balance traffic across EC2 | 로드 밸런싱은 Elastic Load Balancer (ELB) 의 역할 | ❌ |
```mermaid
flowchart TD
%% 🌐 인터넷 영역
subgraph Internet
I["🌍 Internet User"]
end
%% ☁️ VPC 내부 구성
subgraph VPC
IGW["🔗 Internet Gateway"]
E["💻 EC2 Instance<br>Public Subnet"]
end
%% 🔁 연결 관계
I <--> IGW <--> E
%% 💡 설명 노드
N["💡 IGW allows internet access<br>only for resources with Public IPs"]
IGW --- N
```

| 서비스명 | Internet Gateway (IGW) |
| 기능 | VPC 리소스와 인터넷 간 트래픽 중계 |
| 필수 구성요소 | Route Table + 퍼블릭 IP |
| 관련 서비스 비교 | VPN → Virtual Private Gateway / NAT → 사설 서브넷용 인터넷 접근 |
“Internet Gateway는 VPC와 인터넷 간 통신을 가능하게 하는 관문 역할을 한다.”
AWS 클라우드 컴퓨팅에서 “민첩성(Agility)”의 개념은 무엇을 의미하는가?
(정답 2개 선택)
| 선택지 | 설명 |
| A. The speed at which AWS resources are implemented | AWS에서는 리소스를 몇 분 내로 빠르게 구축 및 배포 가능 → 하드웨어 구매/설치 과정 불필요 → 빠른 개발 주기 실현 |
| C. The ability to experiment quickly | 새로운 아이디어나 서비스를 쉽고 빠르게 실험 가능 → 실패 시에도 즉시 리소스 종료(비용 최소화) → 혁신(innovation) 과 직결 |
| 보기 | 내용 | 왜 틀렸는가 |
| B. The speed at which AWS creates new AWS Regions | AWS 자체 인프라 확장 속도 | 고객의 “민첩성”과 관련 없음 ❌ |
| D. The elimination of wasted capacity | 낭비되는 용량 제거는 탄력성(Elasticity) 개념 | ❌ |
| E. The low cost of entry into cloud computing | 진입 비용 절감은 경제성(Economy of Scale) 개념 | ❌ |
| 개념 | 키워드 | 설명 |
| 민첩성 (Agility) | 빠른 구축, 신속한 실험 | 리소스를 빠르게 배포하고, 실험·개발 속도를 높임 |
| 탄력성 (Elasticity) | 자동 확장/축소 | 수요 변화에 맞게 자원 조정 |
| 경제성 (Economy of Scale) | 비용 효율 | 대규모 인프라 운영으로 단가 절감 |
| 확장성 (Scalability) | 성장 대응 | 사용량 증가 시 시스템 확장 가능 |
```mermaid
flowchart TD
A["💡 아이디어 또는<br>요구사항 발생"] --> B["🚀 빠르게 리소스 생성<br>Agility"]
B --> C["🧪 실험 및 테스트"]
C --> D{"❌ 실패?"}
D -->|Yes| E["🛑 즉시 종료하여<br>비용 절감"]
D -->|No| F["✅ 서비스 확장 및 배포"]
```

민첩성(Agility) = “리소스를 빠르게 배포하고, 아이디어를 신속하게 실험할 수 있는 능력”
→ 클라우드가 제공하는 가장 큰 비즈니스 혁신의 기반
A. The speed at which AWS resources are implemented
C. The ability to experiment quickly
한 회사가 AWS 계정에 IAM을 설정하고 있습니다.
다음 중 보안 모범 사례에 해당하는 것은 무엇입니까?
💬 즉, MFA는 “비밀번호 유출 시에도 계정 탈취를 막는 추가 방어선” 역할을 합니다.
| 보기 | 설명 | 왜 틀렸는가 |
| A. Use the account root user access keys for administrative tasks | 루트 사용자로 관리 작업 수행 | 루트 계정은 최소한의 사용만 허용, 접근 키 생성 ❌ |
| B. Grant broad permissions so all employees can access resources | 광범위한 권한 부여 | 원칙 위반 — 최소 권한 부여(Least Privilege Principle) 가 모범 사례 ❌ |
| C. Turn on MFA | 다단계 인증 활성화 | ✅ 정답 — AWS IAM 보안의 핵심 권장 사항 |
| D. Avoid rotating credentials | 자격 증명 순환(교체)을 피하라 | ❌ 잘못된 관행 — 정기적 Credential 회전이 보안 모범 사례 |
| 항목 | 설명 |
| 🔐 MFA 활성화 | 모든 루트 및 관리자 사용자에 MFA 설정 |
| 👥 루트 계정 최소 사용 | 루트 계정은 계정 설정 외엔 사용하지 않기 |
| 🎯 최소 권한 원칙(Least Privilege) | 사용자에게 꼭 필요한 권한만 부여 |
| 🔄 정기적 Credential Rotation | 액세스 키와 암호를 주기적으로 교체 |
| 🧱 IAM Roles 사용 | 애플리케이션 접근은 사용자 키 대신 역할(Role)로 처리 |
```mermaid
flowchart TD
A[🔑 IAM User Login] --> B[🔐 MFA 인증 단계 추가]
B --> C[✅ 로그인 성공]
A -. 비밀번호 유출시 .-> X[❌ 로그인 실패 (MFA 차단)]
```

AWS IAM 보안의 첫 단계는 MFA 활성화,
그 다음은 루트 계정 최소 사용과 최소 권한 원칙 적용입니다.
AWS 클라우드에서 탄력성(Elasticity) 이란 무엇을 의미합니까?
(2개 선택)
B. The ability to rightsize resources as demand shifts
E. How easily resources can be procured when they are needed
| 선택지 | 설명 |
| B. The ability to rightsize resources as demand shifts | 수요(트래픽, 부하 등)에 따라 리소스의 크기나 개수를 자동으로 조정하는 능력. → 오토스케일링(Auto Scaling) 개념과 직결 |
| E. How easily resources can be procured when they are needed | 필요한 시점에 빠르게 리소스를 생성하거나 해제할 수 있는 능력. → 즉시 확장/축소 가능한 클라우드의 장점 |
| 보기 | 설명 | 왜 틀렸는가 |
| A. How quickly an EC2 instance can be restarted | 인스턴스 재시작 속도 | 탄력성과 무관 — 운영 수준의 속도 개념 ❌ |
| C. The maximum amount of RAM an EC2 instance can use | 단일 인스턴스 사양 제한 | 탄력성과 무관 — 리소스 크기 조정이 아님 ❌ |
| D. The pay-as-you-go billing model | 사용량 기반 과금(유연한 과금 모델) | 이는 비용 효율성(Cost Optimization) 관련 개념 ❌ |
| 개념 | 설명 | 관련 서비스 예시 |
| 탄력성 (Elasticity) | 수요 변화에 따라 리소스를 자동 확장/축소 | EC2 Auto Scaling, DynamoDB Auto Scaling |
| 확장성 (Scalability) | 장기적 성장에 따라 리소스 추가 가능 | RDS Read Replica, Load Balancer |
| 민첩성 (Agility) | 리소스를 빠르게 배포하고 실험 가능 | CloudFormation, Lambda |
| 비용 효율성 (Cost Optimization) | 필요한 만큼만 사용하고 지불 | S3, Savings Plans |
```mermaid
flowchart LR
A[📈 수요 증가] --> B[⚙️ Auto Scaling: EC2 인스턴스 추가]
B --> C[💡 성능 유지]
C --> D[📉 수요 감소]
D --> E[⚙️ Auto Scaling: 인스턴스 종료]
E --> F[💰 비용 절감]
```

탄력성(Elasticity) =
“시시각각 변하는 수요에 따라 IT 리소스를 자동으로 확장하거나 축소할 수 있는 능력.”→ 즉, 필요한 만큼만 사용하고, 필요 없으면 자동으로 줄이는 것!
한 회사가 이미지와 비디오를 전 세계 사용자에게 최소한의 지연(latency) 으로 전달해야 합니다.
비용 효율적인 방법으로 이를 달성하기 위해 어떤 접근 방식을 사용해야 할까요?
AWS의 콘텐츠 전송 네트워크(CDN) 서비스입니다.
정적(이미지, 동영상, HTML 등)과 동적 콘텐츠를 전 세계 엣지 로케이션(Edge Location) 에 캐싱하여,
사용자에게 가장 가까운 위치에서 빠르게 제공합니다.
👉 핵심 효과:
| 보기 | 설명 | 왜 틀렸는가 |
| B. Store the content on Amazon S3 and enable cross-region replication | S3 지역 간 복제(CRR)는 백업 및 가용성 향상 목적 | 전송 지연(latency) 개선에는 한계 있음 ❌ |
| C. Implement a VPN across multiple AWS Regions | VPN은 보안 통신 용도로 사용 | 글로벌 콘텐츠 배포와 무관 ❌ |
| D. Deliver through AWS PrivateLink | PrivateLink는 VPC 간 프라이빗 연결 서비스 | 퍼블릭 사용자에게 콘텐츠 전송 불가능 ❌ |
```mermaid
flowchart LR
A[📦 S3 Origin or EC2 Server] --> B[🌍 Amazon CloudFront Edge Locations]
B --> C[👩💻 Global Users]
C -->|요청 시 가장 가까운 Edge에서 제공| B
B -->|Cache 미존재 시 Origin으로 요청| A
```

CloudFront = 전 세계 엣지 로케이션을 활용한 저지연 콘텐츠 전송 서비스
| 항목 | 설명 |
| 🔹 서비스 유형 | CDN (Content Delivery Network) |
| 🔹 주요 기능 | 캐싱, 지연 최소화, 전송 가속 |
| 🔹 연동 서비스 | S3, EC2, ALB, API Gateway |
| 🔹 보안 통합 | AWS WAF, ACM, Shield |
| 🔹 비용 효율성 | 트래픽 기반 과금 (S3보다 저렴한 전송비) |
A. Deliver the content through Amazon CloudFront
| [AWS CLF-C02] Q251 ~ Q300 오답노트 2EA (0) | 2025.10.16 |
|---|---|
| [AWS CLF-C02] Q201 ~ Q250 오답노트 10EA (0) | 2025.10.14 |
| [AWS CLF-C02] Q151 ~ Q200 오답노트 7EA (0) | 2025.10.14 |
| [AWS CLF-C02] Q101 ~ Q150 오답노트 7EA (0) | 2025.10.10 |
| [AWS CLF-C02] Q051 ~ Q100 오답노트 5EA (0) | 2025.10.09 |