💡 탄력성(Elasticity) → 수요 변화에 따라 자동으로 리소스를 확장/축소하는 능력 → AWS Auto Scaling, EC2 Auto Scaling 활용
⚙️ 2️⃣ 컴퓨팅 옵션 비교
유형
설명
특징
🧩 EC2
가상 인스턴스
자유도 높지만 관리 필요
🐳 컨테이너(ECS / EKS)
애플리케이션을 컨테이너로 패키징
관리형 클러스터, 이식성 우수
⚡ 서버리스(Lambda)
서버 관리 불필요
짧은 실행, 이벤트 기반
💬 상황에 따라 선택:
고정된 트래픽 → EC2 + Auto Scaling
이벤트 중심, 비정기적 트래픽 → Lambda
마이크로서비스 구조 → ECS / EKS
🧠 3️⃣ 데이터베이스 설계
서비스
유형
특징
💾 Amazon RDS
관계형 DB
Multi-AZ로 고가용성
⚡ Amazon Aurora
클라우드 네이티브 RDB
고성능, 자동 복제
🌐 Amazon DynamoDB
NoSQL
짧은 지연 시간, 자동 확장
🧮 Amazon Redshift
데이터 웨어하우스
대규모 분석용
✅ 성능 및 복원력 향상
읽기 전용 복제본 (Read Replica) : 읽기 트래픽 분산
Multi-AZ : 고가용성 (Standby 복제)
RDS Proxy : 연결 풀링, 복원력 향상
🚀 4️⃣ 캐싱(Cache) 전략
서비스
역할
특징
🌍 Amazon CloudFront
글로벌 캐시 CDN
정적 콘텐츠 전송
💾 Amazon ElastiCache
인메모리 캐시
Redis / Memcached 지원
⚙️ DAX (DynamoDB Accelerator)
DynamoDB 캐시
밀리초 응답 시간
💡 캐싱은 DB 읽기 부하를 줄이고 응답속도 향상에 핵심 역할
🔒 5️⃣ 엣지 및 전송 서비스
서비스
기능
사용 목적
🌎 Amazon Route 53
DNS 라우팅
가용성 및 트래픽 제어
⚡ AWS Global Accelerator
TCP/UDP 전송 가속
글로벌 성능 최적화
📦 AWS Transfer Family
파일 전송 자동화
SFTP/FTPS 지원, 서버 관리 불필요
🧩 6️⃣ 마이크로서비스 및 분산 시스템 설계
🧱 서비스 지향 아키텍처 (SOA)
구성 요소 간 재사용 가능한 서비스 인터페이스 제공
💬 마이크로서비스 아키텍처
더 작고 독립적인 서비스 단위
API 기반 통신 (REST / GraphQL / gRPC)
💬 이점
독립적 배포 및 확장 가능
장애 격리성 향상
빠른 개발 주기
🔄 7️⃣ 동기 vs 비동기 통합
유형
설명
예시
동기식(Synchronous)
요청-응답 구조로 실시간 상호작용 필요
ALB → EC2, API Gateway → Lambda
비동기식(Asynchronous)
메시지 큐로 구성요소 간 분리
SQS, SNS, EventBridge
💡 비동기 분리는 장애 시에도 시스템의 나머지 부분이 정상 동작 가능
🧩8️⃣ 느슨한 결합(Loose Coupling) 구현 서비스
서비스
역할
설명
📬 Amazon SQS
메시지 큐
컴포넌트 간 비동기 통신
🔔 Amazon SNS
알림/이벤트 브로커
Fan-out 구조 가능
🧩 Amazon EventBridge
이벤트 버스
서비스 간 이벤트 기반 통합
🌀 API Gateway
마이크로서비스 API 통신 허브
Lambda, Fargate 등과 연결
🏗️ 9️⃣ 대표 아키텍처 예시 (Mermaid 다이어그램)
🧭1️⃣0️⃣ 설계 시 고려할 주요 서비스
🏗 Application Load Balancer (ALB) – 트래픽 분산
🐳 AWS Fargate – 서버리스 컨테이너 실행
⚙️ Amazon ECS / EKS – 컨테이너 오케스트레이션
🔐 AWS Secrets Manager – 자격 증명 및 암호 관리
🔄 AWS Lambda – 이벤트 기반 서버리스 컴퓨팅
📡 Amazon API Gateway – API 엔드포인트 관리
✅ 핵심 요약
핵심 요소
주요 포인트
확장성 (Scalability)
Auto Scaling, SQS, Lambda 동시성
느슨한 결합 (Loose Coupling)
SQS, SNS, EventBridge, ALB
복원력 (Resilience)
Multi-AZ, Read Replica, 캐시, 장애 격리
비용 최적화
Auto Scaling, 서버리스, S3 Intelligent-Tiering
🧩 참고 AWS 서비스 맵
컴퓨팅: EC2, Lambda, Fargate
데이터베이스: RDS, DynamoDB, Aurora
스토리지: S3, EFS, FSx
네트워킹: ALB, Route 53, Global Accelerator
통합/메시징: SQS, SNS, EventBridge
보안/관리: Secrets Manager, CloudWatch, CloudTrail
☁️ 영역 2 - 고가용성(HA) 및 내결함성(FT) 아키텍처 설계
🎯 학습 목표
고가용성(High Availability), 내결함성(Fault Tolerance), **재해 복구(Disaster Recovery)**의 차이 이해
AWS 서비스 기반 고가용성 구성 방법 습득
RTO/RPO 및 DR 전략(Active-Passive / Active-Active) 설계
단일 장애 지점(Single Point of Failure, SPOF) 제거
🧱 1️⃣ 고가용성(High Availability, HA)
시스템이 가능한 한 자주 서비스를 **“제공할 수 있는 상태”**를 유지하도록 설계하는 것
🔍 특징
장애 발생 시 자동 복구 또는 빠른 교체
짧은 가동 중단 시간 허용 가능
완전 무중단은 아니지만, 서비스 지속성에 초점
💡 예시
EC2 인스턴스를 1대만 운영 → 장애 시 서비스 중단
Auto Scaling + Multi-AZ 배포 구성 → 한 인스턴스가 중단되면 다른 AZ의 인스턴스로 장애 조치(Failover)
⚙️ 2️⃣ 내결함성(Fault Tolerance, FT)
장애 발생 시에도 서비스가 중단되지 않고 계속 작동하는 설계
🔍 특징
장애 발생 시에도 서비스 무중단 유지
실시간 장애 감지 및 자동 대체
비용은 높지만 가장 높은 복원력(Resilience) 보장
💡 예시
두 서버를 모두 활성(Active-Active) 상태로 운영
한 서버 장애 시 자동 트래픽 전환
사용자는 중단 없이 서비스 이용 가능
🔁 3️⃣ 재해 복구(Disaster Recovery, DR)
예기치 않은 재해(화재, 지진, 시스템 장애) 발생 시 시스템 복원 절차를 설계하는 것
🔍 핵심 요소
항목
설명
🕒 RTO (Recovery Time Objective)
서비스 중단 후 복원까지 허용되는 최대 시간
📅 RPO (Recovery Point Objective)
데이터 손실 허용 가능한 최대 시간 (백업 주기 결정)
💡 DR 전략 유형
전략
설명
비용
복구 속도
🧊 백업 & 복원 (Backup & Restore)
S3/Glacier에 백업, 필요 시 복원
💲 낮음
🕒 느림
🔥 파일럿 라이트 (Pilot Light)
최소 구성만 유지, 필요 시 전체 확장
💲 중간
⚡ 보통
🌡️ 웜 스탠바이 (Warm Standby)
축소된 형태의 운영 환경 유지
💲 중상
⚡ 빠름
💡 액티브-액티브 (Active-Active)
모든 리전에서 동시에 운영
💲 높음
⚡⚡ 매우 빠름
🌍 4️⃣ AWS 글로벌 인프라와 고가용성 설계
📦 AWS 구성 요소 계층
계층
설명
🌐 Region (리전)
지리적으로 독립된 AWS 인프라 단위
🧭 Availability Zone (AZ)
리전 내 독립 전력/네트워크를 가진 데이터센터
🧱 Edge Location
CloudFront, Route 53 캐시를 위한 전 세계 엣지 노드
💡 Multi-AZ 배포는 AZ 장애 시 자동으로 다른 AZ로 장애 조치 💡 Multi-Region 배포는 리전 전체 장애 시 복구 가능 (Active-Passive / Active-Active)
🔒 5️⃣ 데이터베이스의 HA & DR
서비스
기능
특징
💾 Amazon RDS (Multi-AZ)
자동 장애 조치
가용성 중심
⚡ Aurora Global Database
교차 리전 복제
빠른 복구 (1분 미만)
🌐 DynamoDB Global Tables
리전 간 실시간 동기화
내결함성 보장
🧩 RDS Proxy
DB 연결 풀링 및 Failover 단축
장애 조치 시간 66% 단축
🗂️ 6️⃣ 스토리지 및 백업 복원
서비스
역할
특징
🧱 Amazon S3
백업 및 아카이브
11 9s(99.999999999%) 내구성
💾 Amazon EFS / FSx
파일 스토리지
AZ 간 중복 저장
🧊 S3 Glacier
장기 보관
저비용 백업
🧩 AWS Elastic Disaster Recovery (DRS)
온프레미스 ↔ 클라우드 복구 자동화
레거시 지원
⚙️ 7️⃣ AWS 네트워킹 구성과 복원력
서비스
역할
설명
🛰️ Route 53
DNS 기반 장애 조치 라우팅
지연 시간 / 장애 조치 / 가중치 라우팅 지원
⚡ Global Accelerator
TCP/UDP 네트워크 성능 가속
글로벌 사용자 연결 최적화
🔀 Transit Gateway
여러 VPC 간 중앙 라우팅 허브
단일 장애 지점 제거
🔗 Direct Connect / VPN
온프레미스 연결
고속, 안정적 네트워크 통신
🧩 8️⃣ 배포 및 복구 자동화 서비스
서비스
기능
🌱 AWS CloudFormation
인프라 자동 복구 및 프로비저닝
☁️ Elastic Beanstalk
애플리케이션 자동 배포 및 확장
🐳 ECS / EKS (컨테이너)
고가용성 컨테이너 오케스트레이션
🔄 OpsWorks / CodeDeploy
구성 관리 및 자동 롤백
🧠 9️⃣ 모니터링 & 지속 개선
서비스
역할
👁️ Amazon CloudWatch
지표 수집, 알람, 자동화 트리거
🔍 AWS X-Ray
애플리케이션 요청 추적 (분산 추적)
🧠 Amazon Inspector
취약점 스캔 및 보안 진단
🤖 Amazon CodeGuru
코드 품질 분석 및 성능 개선
🧩 Amazon EventBridge
실시간 이벤트 기반 자동 대응
🗣️ 1️⃣0️⃣ AI 기반 고가용성 활용 예시
서비스
역할
사용 예시
🗣️ Amazon Polly
텍스트 → 음성 변환
고객센터, 셀프 서비스 음성 안내
🧠 Amazon Comprehend
자연어 분석
IT 서비스 요청 자동 분류
💡 예시: Comprehend로 요청 카테고리 자동 분류 → Polly가 음성으로 안내 → Connect가 셀프 서비스 제공
🧩1️⃣1️⃣고가용성 아키텍처 예시 (Mermaid)
🧾 1️⃣2️⃣ 핵심 요약
항목
설명
고가용성(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️⃣ 자동화된 복구 프로세스 구성
☁️ 영역 2 복습 - 확장 가능하고 복원력 있는 아키텍처 설계
🎯 핵심 목표
확장성(Scalability) 과 탄력성(Elasticity) 이해
고가용성(High Availability) 과 내결함성(Fault Tolerance) 차이 구분
AWS 글로벌 인프라 기반 복원력 설계
재해 복구(Disaster Recovery, DR) 전략 이해
워크로드 모니터링 & 자가 복구 환경 구축
🚀 1️⃣ AWS 클라우드의 핵심 이점
항목
설명
🧠 용량 추측 불필요
필요한 만큼 자동 확장 / 축소
💰 비용 효율성
사용한 만큼만 지불 (Pay-as-you-go)
⚙️ 자동화된 확장성
Auto Scaling / Elastic Load Balancing
🌎 글로벌 인프라
다중 AZ & 다중 리전 기반 복원력
🧩 2️⃣ 고가용성(HA) vs 내결함성(FT)
구분
고가용성 (High Availability)
내결함성 (Fault Tolerance)
🧱 정의
장애 발생 시 빠르게 복구하여 서비스 지속
장애 발생 중에도 시스템이 중단 없이 동작
⏱ 중단 시간
약간의 중단 허용
무중단 (Zero downtime)
💰 비용
중간
높음
⚙️ 예시
Multi-AZ RDS, Auto Scaling, ALB
Active-Active Aurora Global DB
🧭 3️⃣ AWS 글로벌 인프라 활용
계층
설명
🌐 Region
지리적으로 분리된 AWS 데이터센터 그룹
🏢 Availability Zone (AZ)
독립된 전원·네트워크를 가진 가용 단위
📍 Edge Location
CloudFront, Route 53 등 엣지 네트워크
💡 Multi-AZ + Multi-Region 설계는 서버, 스토리지, DB 장애에도 중단 없는 서비스를 제공하도록 돕습니다.
⚙️ 4️⃣ 자가 복구(Self-Healing) 환경을 위한 핵심 서비스
서비스
역할
⚖️ Elastic Load Balancing (ELB)
여러 인스턴스 간 트래픽 분산 및 장애 감지
📈 Amazon EC2 Auto Scaling
인스턴스 자동 추가/제거, 비정상 인스턴스 교체
🛰️ Route 53 (Failover Routing)
리전 단위 장애 발생 시 다른 리전으로 트래픽 전환
🌍 AWS Global Accelerator
TCP/UDP 트래픽 지연 최소화 및 글로벌 복원력 향상
🔁 5️⃣ 재해 복구(Disaster Recovery) 전략 비교
전략
설명
비용 💰
복구 속도 ⚡
🧊 백업 & 복원
S3, Glacier에 백업 후 필요 시 복원
낮음
느림
🔥 파일럿 라이트
핵심 구성만 유지 후 필요 시 확장
중간
보통
🌡️ 웜 스탠바이
축소된 프로덕션 환경 유지
중상
빠름
💡 액티브-액티브
모든 리전 동시 운영
높음
매우 빠름
💡 RTO(복구시간목표) & RPO(복구시점목표)를 기준으로 선택해야 함.
🧠 6️⃣ AWS 서비스별 복원력 내장 기능
서비스
내장 복원력 기능
사용 예시
💻 EC2 Auto Scaling
인스턴스 자동 교체 / 증감
트래픽 급증 시 수평 확장
⚖️ Elastic Load Balancer
트래픽 자동 분산
웹 서버 장애 시 자동 우회
🧾 RDS Multi-AZ
자동 장애 조치(Failover)
DB 가용성 확보
⚡ Aurora Global DB
교차 리전 복제
리전 장애 대비
📬 SQS / SNS / EventBridge
비동기 메시징
서비스 간 결합도 최소화
🐳 ECS / Fargate
자동 리스타트, 헬스체크
컨테이너 복원력
🧠 Lambda
서버리스 확장성
짧은 처리 이벤트 기반 애플리케이션
🧱 7️⃣ 상태(State) 관리 전략
유형
설명
예시
⚙️ Stateless (비상태)
인스턴스 교체 시 데이터 의존 없음
웹 서버, Lambda 함수
💾 Stateful (상태 유지)
인스턴스에 데이터 저장
RDS, EFS, 세션 유지
💡 Stateless 아키텍처는 확장성과 복원력 측면에서 유리 💡 Stateful 컨테이너는 EFS, FSx 등 외부 스토리지 연결로 해결 가능
🧰 8️⃣ 세션 관리와 로드 밸런싱
Application Load Balancer (ALB) 기본 라우팅 → 요청을 무작위로 배분
스티키 세션(Sticky Session) → 사용자를 특정 인스턴스에 고정
세션 유지가 필요한 로그인 기반 애플리케이션에 유용
단, 인스턴스 장애 시 세션 손실 위험 있음
⚡ 9️⃣ 캐싱 & 읽기 부하 분산 전략
서비스
역할
특징
🧠 Amazon ElastiCache (Redis/Memcached)
데이터 캐싱
DB 쿼리 부하 감소
⚡ DynamoDB Accelerator (DAX)
NoSQL 캐시
밀리초 응답 시간
🧩 RDS Read Replica
읽기 부하 분산
읽기 성능 향상 (복제 기반)
💡 캐싱은 지연 시간 단축 + 비용 절감 + DB 부하 감소의 핵심 전략
🔍1️⃣0️⃣ 모니터링 & 가시성 확보
서비스
기능
설명
👁️ Amazon CloudWatch
지표 수집 & 알람
인스턴스/서비스 상태 모니터링
🕵️ AWS X-Ray
분산 추적
요청 흐름 분석 및 병목 탐지
💡 CloudWatch 알람 + Auto Scaling 정책 = 자가 복구(Self-healing) 시스템 구축
🧩 1️⃣1️⃣ 복원력 있는 아키텍처 예시
✅ 1️⃣2️⃣ 핵심 정리 요약
핵심 주제
주요 포인트
확장성 (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 클라우드의 자동 확장 + 복원력 + 관리형 서비스 조합은 기존 인프라 대비 가용성과 효율성을 극대화합니다.
시험에서는 다음과 같은 포인트를 명확히 구분해야 합니다. 1️⃣ Auto Scaling vs Elastic Load Balancing 2️⃣ Stateless vs Stateful 3️⃣ RDS Multi-AZ vs Read Replica 4️⃣ Route 53 Failover vs Global Accelerator
✅ 이 문제는 AWS Config의 대표적인 사용 목적(컴플라이언스 및 구성 변경 추적)을 정확히 묻고 있습니다.
📘 Q612
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 서비스를 사용해야 합니까?
✅ 정답: A. AWS Config
🧠 해설:
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 공통 문제입니다.
📘 Q619
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?
✅ 정답: C. Reliability (안정성)
🧠 해설:
**Reliability Pillar (안정성 기둥)**은 워크로드가 의도된 기능을 올바르게 수행하고, 장애가 발생하더라도 복구(resilience)와 일관성(consistency) 을 유지하도록 하는 것을 목표로 합니다.
완전관리형(fully managed) NoSQL DB 서비스 = Amazon DynamoDB
✅ 이 문제는 EC2 인스턴스 구매 옵션(Purchasing Options) 의 특징을 이해하는 문제입니다. AWS Certified Cloud Practitioner (CLF-C02)와 Solutions Architect Associate (SAA-C03) 시험에서 자주 출제되는 핵심 유형이에요.
📘 Q684
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 구매 옵션이 가장 비용 효율적으로 이 요구사항을 충족할까요?
✅ 정답: A. Standard Reserved Instances
🧠 해설
**Standard Reserved Instances (RI)**는 1년 또는 3년 동안 지속적인 사용(steady-state usage) 을 약정함으로써 On-Demand 대비 최대 72%까지 절감할 수 있는 비용 효율적인 옵션입니다.
이 문제에서 핵심 키워드는 👇
"without interruption" (= 항상 실행되어야 함) → 즉, 중단이 없어야 하는 상시 워크로드 → 따라서 Reserved Instance (RI) 가 정답입니다.
⚙️ EC2 인스턴스 구매 옵션 비교표
구매 옵션
설명
비용 절감률 (대비)
중단 가능성
주요 사용 사례
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 입니다.
✅ 이 문제는 온프레미스의 MariaDB 데이터베이스를 AWS로 이전할 때, 운영 오버헤드(Operational Overhead) 가 가장 적은 서비스를 묻고 있습니다.
📘 Q503.
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 서비스는 무엇입니까?
✅ 정답: A. Amazon RDS
💡 해설
🔹 Amazon RDS (Relational Database Service)
Amazon RDS는 AWS에서 제공하는 완전관리형 관계형 데이터베이스 서비스로, 데이터베이스의 프로비저닝, 패치, 백업, 복제, 장애 조치 등을 자동화하여 운영자의 부담을 최소화합니다.
AWS Database Migration Service (DMS) 를 사용하여 온프레미스 DB → RDS로 마이그레이션 가능
이후 자동 백업 + 모니터링 + 장애조치 지원으로 관리 부담 최소화
❌ 오답 해설
보기
설명
오답 이유
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 선택지입니다.
📘 Q527.
Which statements accurately describe the relationships among components of AWS global infrastructure? (Choose two)
AWS 글로벌 인프라 구성 요소 간의 관계를 정확히 설명한 것은 무엇입니까? (2개 선택)
✅ 정답: B, E
💡 해설
AWS 글로벌 인프라(Global Infrastructure)는 다음과 같은 계층 구조로 구성됩니다.
🌍 AWS Global Infrastructure
├── 🌎 Region (리전)
│ ├── 🏢 Availability Zone (가용 영역)
│ └── 🗄️ Local Zone (로컬 영역)
└── 🌐 Edge Location (엣지 로케이션)
✅ B. There are more edge locations than AWS Regions.
✔️ 정답
AWS의 엣지 로케이션(Edge Location) 은 CloudFront, Route 53, Global Accelerator 등의 콘텐츠 전송 및 네트워크 최적화용 인프라입니다.
엣지 로케이션은 전 세계 수백 개 이상 존재하며, 리전(Region) 은 상대적으로 수십 개 수준입니다. → 예: 2025년 기준
약 33개 리전
약 100개 이상 AZ
약 600개 이상 엣지 로케이션
✅ E. There are more Availability Zones than AWS Regions.
✔️ 정답
각 Region 은 2개 이상의 Availability Zone (AZ) 으로 구성됩니다.
따라서 가용 영역(AZ) 의 개수가 리전보다 많을 수밖에 없습니다.
예시 📍
RegionAZ 개수
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 보안 서비스를 사용해야 하는지를 묻고 있습니다.
📘 Q546.
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) 으로 필터링 및 제어하고자 합니다.
✅ 정답: B. AWS WAF (Web Application Firewall)
💡 해설
🔹 AWS WAF (Web Application Firewall)
AWS WAF는 웹 애플리케이션을 보호하기 위한 방화벽 서비스로, HTTP/HTTPS 트래픽을 사용자 정의 조건(Custom Rules) 으로 필터링할 수 있습니다.
✅ 주요 기능
기능
설명
⚙️ 트래픽 필터링
IP, 쿼리 문자열, URI, HTTP 헤더 등 조건 기반 필터링
🧩 규칙 기반 보안
SQL Injection, XSS, 악성 요청 등을 자동 차단
🔄 통합 서비스
ALB, CloudFront, API Gateway, App Runner와 통합 가능
📊 모니터링
CloudWatch를 통한 트래픽 로깅 및 분석
💡 Custom Rule 가능
특정 국가, IP, 경로 기반 허용/차단 조건 정의 가능
⚙️ 아키텍처 예시
WAF는 ALB 앞단 또는 CloudFront 앞단에서 동작하며 애플리케이션으로 들어오기 전 트래픽을 필터링합니다.
❌ 오답 해설
보기
설명
오답 이유
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 연동이 가능한 최소 비용 플랜을 묻는 문제입니다.
📘 Q567.
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이 이 요구사항을 가장 비용 효율적으로 충족할까요?
✅ 정답: B. AWS Developer Support
💡 해설
🔹 AWS 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/월부터
✅ Developer Support가 정답인 이유
AWS Support API는 Developer, Business, Enterprise 플랜에서만 사용 가능
Basic Plan은 API 연동 불가능
따라서 가장 저렴하면서도 API 호출이 가능한 옵션은 → Developer Support Plan입니다.
✅ Developer Support 주요 특징
항목
설명
💬 기술 지원 채널
이메일 기반 기술 지원 (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 포함
✅ 되지만 가장 비쌈
🔧 참고: Support API 사용 예시
AWS Support API를 사용하면 프로그래밍 방식으로 지원 케이스를 조회/생성 가능:
aws support describe-cases --language en
이 기능은 Developer Support 이상 플랜이 필요합니다.
📗 한 줄 요약
💡 AWS Support API를 사용하려면 최소 Developer Support 플랜이 필요하며, 이 플랜이 가장 저렴하게(API 연동 포함) 요구사항을 충족합니다.
✅ 이 문제는 AWS CloudTrail의 핵심 개념을 묻는 전형적인 문제입니다.
📘 Q586
A company needs an event history of which AWS resources the company has created. Which AWS service will provide this information?
회사는 회사에서 만든 AWS 리소스에 대한 이벤트 내역이 필요합니다. 어떤 AWS 서비스가 이 정보를 제공합니까?
✅ 정답: B. AWS CloudTrail
🧠 해설:
AWS CloudTrail은 AWS 계정 내에서 발생하는 모든 API 호출 및 이벤트 활동을 기록하는 서비스입니다.
즉, 누가 언제 어떤 리소스를 만들었고 (예: EC2, S3, IAM 등) 어떤 작업(예: Create, Delete, Modify)을 수행했는지 이벤트 히스토리(Event History) 형태로 제공합니다.
🔍 CloudTrail의 주요 기능:
기능
설명
🗂 이벤트 기록 (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을 사용합니다.
Which statements represent the cost-effectiveness of the AWS Cloud? (Choose two)
AWS 클라우드의 비용 효율성을 나타내는 설명은 무엇입니까? (2개 선택)
✅ 정답: A. Users can trade fixed expenses for variable expenses.
✅ 정답: E. Users benefit from economies of scale.
💡 해설
🧮 A. Users can trade fixed expenses for variable expenses
온프레미스 환경에서는 서버, 스토리지, 네트워크 장비 등을 미리 구입해야 하는 고정비용(CapEx) 이 필요합니다.
반면 AWS는 필요할 때만 리소스를 사용하고 그만큼만 비용을 지불하는 변동비용(OpEx) 구조입니다.
📊 예시:
기존: 서버 10대를 선구매(수천만 원의 초기 비용)
AWS: 실제 사용 시간만큼만 과금 (예: 2시간만 EC2 인스턴스 실행)
👉 즉, “고정비를 변동비로 전환”함으로써 초기 투자 부담 없이 클라우드 도입이 가능합니다.
💡 E. Users benefit from economies of scale
AWS는 전 세계 수백만 고객의 인프라 사용량을 기반으로 규모의 경제(economies of scale) 를 실현합니다.
대규모 인프라 운영으로 인해 AWS는 더 낮은 단가로 컴퓨팅 파워, 스토리지, 네트워크 서비스를 제공할 수 있습니다.
📉 효과:
AWS의 고객이 많아질수록 단가가 낮아지고,
그 혜택이 다시 사용자에게 가격 인하(Price Reduction) 형태로 돌아옵니다.
🏷️ 실제로 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)
```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)”
📘 Q406.
A company needs to consolidate the billing for multiple AWS accounts.
여러 AWS 계정의 결제를 통합해야 한다면 어떤 서비스를 사용해야 할까요?
✅ 정답: B. AWS Organizations
💡 정답 해설
🔹 AWS Organizations란?
AWS Organizations는 여러 AWS 계정을 중앙에서 관리하고, 청구서 통합(Consolidated Billing) 및 정책 제어(Service Control Policies, SCPs) 를 수행할 수 있는 서비스입니다.
✅ 핵심 기능
기능
설명
🧾 Consolidated Billing (통합 청구)
여러 AWS 계정을 하나의 “Payer Account(결제 계정)” 아래 묶어 단일 청구서로 관리 가능
💰 비용 절감 효과 (Savings)
모든 계정의 사용량이 합산되어 볼륨 할인과 Savings Plan/RI 할인을 함께 적용받음
🔒 Policy Control (SCP)
멤버 계정이 수행할 수 있는 서비스나 리소스를 조직 단위로 제한 가능
🧑💼 조직 구조 관리
OU(Organizational Units)를 사용해 부서, 팀, 프로젝트별 계정 그룹화 가능
⚙️ 자동 계정 생성 및 초대
새로운 계정을 자동으로 생성하거나 기존 계정을 조직에 초대 가능
🧮 Consolidated Billing 예시
계정
EC2 사용료
합산 할인율
총 비용
A (개발팀)
$100
B (운영팀)
$200
✅ 10% 할인 적용 (300달러 단위)
💵 $270
총합
$300
통합 청구 + 할인 적용
✅ 더 적은 총 비용
즉, 개별 계정이 아닌 조직 전체 사용량을 기준으로 할인율이 적용되어 비용 효율성이 증가합니다.
❌ 오답 해설
보기
설명
오답 이유
A. AWS Trusted Advisor
보안, 비용, 성능, 서비스 한도 관련 권장사항 제공
❌ 결제 통합 기능 없음
C. AWS Budgets
예산 한도 및 초과 시 알림 설정 기능 제공
❌ “알림” 기능이지, 결제 통합은 불가
D. AWS Service Catalog
승인된 서비스 템플릿을 카탈로그 형태로 배포
❌ 결제 관리와 무관
🧩 시각 요약 (Mermaid)
```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 네이티브 보안 리소스를 묻는 문제입니다.
📘 Q413.
Which AWS service or feature will meet this requirement?
특정 EC2 인스턴스 간의 네트워크 트래픽을 제어하기 위한 AWS 기본 보안 기능은 무엇입니까?
✅ 정답: D. Security groups
💡 해설
🔹 Security Group이란?
AWS의 가상 방화벽(Virtual Firewall) 역할을 하는 인스턴스 수준 보안 제어(Instance-level security control) 기능입니다.
VPC 내의 개별 EC2 인스턴스 간 트래픽을 허용하거나 차단할 수 있습니다.
✅ 주요 특징
항목
설명
적용 수준
인스턴스 수준 (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) 사이에만 통신을 허용하고 싶을 때:
EC2-2(DB) 인스턴스의 Security Group에서
Inbound 규칙: EC2-1의 Security Group ID로부터만 3306(MySQL) 포트 허용
```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) 으로 수행하며, 이는 인스턴스 수준의 상태 저장형 방화벽입니다.
📘 Q426.
Which AWS service should the company use to meet these requirements?
전 세계 사용자에게 웹사이트를 빠르고 효율적으로 전달하려면 어떤 서비스를 사용해야 할까요?
✅ 정답: B. Amazon CloudFront
💡 해설
🔹 Amazon CloudFront란?
Amazon CloudFront는 AWS의 글로벌 콘텐츠 전송 네트워크(CDN, Content Delivery Network) 서비스입니다. 전 세계 600개 이상의 Edge Location(엣지 로케이션) 을 통해 콘텐츠를 캐싱하고, 사용자에게 가장 가까운 위치에서 데이터를 전송함으로써 지연시간(Latency) 을 최소화합니다.
✅ CloudFront의 주요 역할
기능
설명
🌍 글로벌 엣지 네트워크 제공
사용자와 가장 가까운 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
서버리스 컴퓨팅 서비스
❌ 웹 콘텐츠 전송 및 캐싱 기능 없음
🧩 CloudFront의 장점 정리
항목
설명
🌍 전 세계 커버리지
글로벌 엣지 네트워크로 사용자와 물리적 거리 최소화
🚀 성능 향상
데이터 전송 속도 개선, 지연시간 감소
💰 비용 절감
원본 서버 부하 및 데이터 전송 비용 절감
🔒 보안 강화
DDoS 보호(AWS Shield), HTTPS 통신, WAF 통합
📗 한 줄 요약
⚡ 전 세계 사용자에게 빠르고 안전하게 웹사이트를 전달하려면 Amazon CloudFront (CDN) 를 사용하세요.
📘 Q435.
Which AWS service should the company use to identify who accessed an AWS service and what action was performed?
✅ 정답: B. AWS CloudTrail
💡 해설
🔹 AWS CloudTrail이란?
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 버킷을 삭제했는지” 확인해야 한다면?
CloudTrail 콘솔 → Event history(이벤트 기록) 로 이동
Event Name = DeleteBucket 검색
결과에서 userIdentity 필드를 확인 → 해당 작업을 수행한 사용자 또는 IAM Role을 확인 가능
위 로그에서 누가(userName), 언제(eventTime), 어떤 서비스(eventSource) 에서 어떤 행동(eventName) 을 수행했는지를 알 수 있습니다.
❌ 오답 해설
보기
설명
오답 이유
A. Amazon CloudWatch
성능 모니터링 및 메트릭 수집 서비스
❌ API 호출 기록 불가 (리소스 상태만 모니터링)
C. AWS Security Hub
보안 상태 종합 관리 대시보드
❌ CloudTrail, GuardDuty 등에서 받은 데이터를 종합 분석
D. Amazon Inspector
애플리케이션 취약점 및 보안 평가 서비스
❌ API 활동 추적 기능 없음
🧩 시각 요약 (Mermaid)
```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 네트워크 서비스를 묻고 있습니다.
📘 Q445.
Which AWS service can the company use as a cloud router to simplify peering relationships?
여러 VPC와 온프레미스 네트워크를 연결하고 라우팅을 단순화하기 위해 사용할 수 있는 AWS 서비스는 무엇입니까?
✅ 정답: B. AWS Transit Gateway
💡 해설
🔹 AWS Transit Gateway란?
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)를 운영하며 온프레미스 데이터센터와 연결할 때,
Before (VPC Peering)
VPC 간 개별 Peering (A↔B, B↔C, A↔C...)
관리 복잡도 ↑
After (Transit Gateway)
모든 VPC가 Transit Gateway에 연결
라우팅 중앙 관리, 트래픽 제어 단순화 ✅
❌ 오답 해설
기능
설명
오답 이유
A. AWS Direct Connect
온프레미스 ↔ AWS 간 전용 네트워크 연결
❌ 피어링 단순화 기능 없음
C. Amazon Connect
고객센터용 클라우드 콜센터 서비스
❌ 네트워크와 무관
D. Amazon Route 53
DNS 관리 및 도메인 라우팅 서비스
❌ 네트워크 피어링이나 라우팅 허브 기능 없음
📗 한 줄 요약
🔄 여러 VPC와 온프레미스 네트워크를 하나의 중앙 허브로 연결하려면 AWS Transit Gateway를 사용합니다 — “Cloud Router” 역할을 수행합니다.
온프레미스 시스템에 대한 저지연(로우 레이턴시) 접근과 데이터 상주(Data Residency) 요구사항을 동시에 충족해야 하는 상황을 묻고 있습니다.
📘 Q459.
Which AWS service should the company use to design a solution that meets these requirements?
“로우 레이턴시(저지연) + 데이터 상주(데이터가 회사 내에 머무를 것)” 👉 어떤 AWS 서비스를 사용해야 할까요?
✅ 정답: D. AWS Outposts
💡 해설
🔹 AWS Outposts란?
AWS Outposts는 AWS 인프라, 서비스, API, 툴을 고객의 온프레미스 데이터센터 또는 로컬 환경에 물리적으로 설치하여 AWS 클라우드와 동일한 경험을 제공하는 하이브리드 클라우드 솔루션입니다.
즉,
“온프레미스에서 AWS를 그대로 사용하는 서비스” 입니다.
✅ Outposts의 주요 특징
항목
설명
⚙️ 온프레미스 설치형 AWS 인프라
AWS에서 제공하는 하드웨어 랙을 고객 데이터센터에 직접 설치
🔁 AWS와 완전 통합
EC2, EBS, ECS, EKS, RDS 등 AWS 리소스를 로컬에서 실행
⚡ 로우 레이턴시(Local Processing)
AWS 리전을 거치지 않고 온프레미스 내부에서 요청 처리
🧭 데이터 상주(Residency)
데이터가 물리적으로 고객 환경에 저장됨 (규제 및 보안 요구 충족)
☁️ 하이브리드 아키텍처 구성 가능
Outposts ↔ AWS 리전 간 네트워킹 및 백업 연동 가능
📦 아키텍처 예시
📍 결과:
데이터는 회사 내(On-prem)에 상주
AWS API, 관리 콘솔, 서비스는 그대로 사용 가능
로컬 처리로 짧은 지연시간 보장
🧠 사용 사례
시나리오
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 요청을 감시하고 차단하는 서비스를 묻는 문제입니다.
📘 Q468.
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)을 탐지하고 차단하기 위해 어떤 서비스를 사용해야 할까요?
✅ 정답: C. AWS WAF (Web Application Firewall)
💡 해설
🔹 AWS WAF란?
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 공격을 받는다면?
CloudFront에 AWS WAF를 연결하면, 공격 트래픽은 엣지 로케이션(Edge Location) 단계에서 즉시 차단됨.
AWS Shield와 함께 사용하면 DDoS 방어도 강화 가능.
❌ 오답 해설
보기
설명
오답 이유
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에 접근할 수 있도록 하는 서비스”를 묻고 있습니다.
📘 Q477.
A company uses a third-party identity provider (IdP). Which AWS service will meet this requirement?
회사에서 외부 IdP(예: Azure AD, Okta, Google Workspace 등)를 사용 중이며, 직원들이 별도의 로그인 자격 증명 없이 AWS 리소스에 접근할 수 있도록 해야 합니다.
✅ 정답: B. Amazon Cognito
💡 해설
🔹 Amazon Cognito란?
Amazon Cognito는 사용자 인증(Authentication), 권한 부여(Authorization), 그리고 사용자 관리(User Management)를 제공하는 ID 관리 서비스입니다.
특히,
외부 IdP(Identity Provider) 와의 통합 인증 (Federation) 기능을 제공하므로,
사용자는 기존 회사 계정 (예: Google, SAML, Azure AD) 으로 로그인할 수 있습니다.
즉,
“AWS 리소스 접근 시 새로운 로그인 정보 없이 기존 계정으로 인증할 수 있다” 👉 바로 Cognito Federated Identity 기능입니다.
✅ Cognito의 두 가지 주요 구성요소
구성 요소
설명
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 서비스를 묻고 있습니다.
📘 Q487.
Which AWS service gives users the ability to deploy highly repeatable infrastructure configurations?
반복적이고 예측 가능한 방식으로 인프라를 배포하려면 어떤 AWS 서비스를 사용해야 할까요?
✅ 정답: A. AWS CloudFormation
💡 해설
🔹 AWS CloudFormation이란?
AWS CloudFormation은 인프라를 코드로 관리 (IaC, Infrastructure as Code) 할 수 있는 서비스입니다. 즉, YAML 또는 JSON 템플릿을 통해 AWS 리소스를 반복적이고 일관되게 배포할 수 있습니다.
개발팀, 테스트팀, 운영팀이 동일한 아키텍처를 각각의 환경에 구축해야 할 때 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 서비스를 묻고 있습니다.
📘 Q488.
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 서비스를 사용해야 할까요?
✅ 정답: B. Amazon Connect
💡 해설
🔹 Amazon Connect란?
Amazon Connect는 클라우드 기반 컨택 센터(Contact Center) 서비스로, 음성 통화, 채팅, 상담 워크플로우를 손쉽게 구성할 수 있는 AWS 서비스입니다.
즉, 고객이 전화나 채팅으로 문의할 때 상담원과 연결해주는 콜센터 솔루션을 AWS에서 완전관리형(fully managed) 형태로 제공합니다.
✅ Amazon Connect의 주요 특징
기능
설명
☎️ 음성 통화 (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) 수준의 방화벽 역할을 하는 기능을 묻고 있습니다.
📘 Q493.
Which AWS tool or feature acts as a VPC firewall at the subnet level? 서브넷 수준에서 VPC 방화벽 역할을 하는 AWS 도구 또는 기능은 무엇입니까?
✅ 정답: B. Network ACL
💡 해설
🔹 Network ACL (NACL, Network Access Control List)
Network ACL은 서브넷(Subnet) 수준에서 트래픽을 제어하는 방화벽 역할을 합니다.
VPC의 각 서브넷(Subnet) 에 적용되며,
들어오는(Inbound) 및 나가는(Outbound) 트래픽을 허용(Allow) 또는 거부(Deny) 규칙으로 제어합니다.
✅ 주요 특징 비교
항목
Network ACL (NACL)
Security Group (보안 그룹)
적용 수준
서브넷(Subnet) 수준
인스턴스(EC2) 수준
상태 저장 여부
❌ 비상태 저장 (Stateless) → Inbound/Outbound 규칙 모두 설정 필요
✅ 상태 저장 (Stateful) → 한쪽만 설정해도 반대 방향 자동 허용
규칙 평가 방식
번호 순서대로(낮은 번호 우선) 평가
모든 규칙이 동시에 평가됨
허용/거부
허용(Allow) + 거부(Deny) 모두 가능
허용(Allow)만 가능
기본 설정
모든 트래픽 허용
모든 트래픽 거부
⚙️ 동작 흐름 예시
트래픽이 서브넷에 들어오거나 나갈 때 Network ACL이 검사합니다.
따라서, 보안 그룹보다 먼저 트래픽을 필터링할 수 있습니다.
🧠 예시 시나리오
회사가 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로 이전하는 전략을 묻고 있습니다.
📘 Q500.
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) 하려고 합니다. 어떤 마이그레이션 전략을 사용해야 할까요?
✅ 정답: D. Refactor (리팩터링)
💡 해설
🔹 Refactor란?
Refactor (또는 Re-architect) 는 애플리케이션 아키텍처를 근본적으로 재설계하여 클라우드 네이티브 기능과 확장성을 극대화하는 가장 현대적인 마이그레이션 전략입니다.
✅ Refactor의 핵심 개념
항목
설명
🎯 목적
기존 애플리케이션의 구조와 코드를 변경하여 클라우드 최적화
🧩 예시
모놀리식 앱 → 마이크로서비스 아키텍처 (MSA) 로 전환
⚙️ 적용 서비스 예시
Amazon ECS / EKS / Lambda / API Gateway / DynamoDB 등
💪 장점
확장성(Scalability), 탄력성(Elasticity), 비용 효율성, 배포 자동화
⏳ 단점
높은 개발 리소스와 시간이 필요 (코드 변경 많음)
⚙️ 예시 시나리오
기존의 한 덩어리 애플리케이션(모놀리식)을 여러 개의 독립적인 서비스(마이크로서비스) 로 나누고 AWS의 컨테이너(ECS, EKS) 나 서버리스(Lambda) 기반으로 재구성합니다.
❌ 오답 해설
보기
설명
오답 이유
A. Rehost (재호스팅)
“Lift & Shift” 방식 — 코드를 변경하지 않고 AWS로 옮김
❌ 현대화나 MSA 분리 불가능
B. Repurchase (환매)
SaaS 솔루션으로 교체 (예: CRM → Salesforce)
❌ 자체 애플리케이션 코드 유지 불가
C. Replatform (플랫폼 교체)
일부 수정만 하여 클라우드로 이전 (예: DB를 RDS로 변경)
❌ 아키텍처 변경이 아닌 최소 수정 수준
✅ D. Refactor (리팩터링)
애플리케이션 구조를 완전히 재설계하여 마이크로서비스로 전환
✅ 현대화(modernization) 목적에 가장 적합
🧠 7R Migration Strategies 요약표
전략
설명
코드 수정 정도
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의 클라우드 네이티브 기능을 최대한 활용하는 현대화 전략입니다.
- 조직 역량과 클라우드 목표를 정렬 - 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 다이어그램)
```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 인스턴스 접속 방식을 묻는 대표적인 기초 실무형 문제
📘 Q346.
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개 선택)
✅ 정답: A. Use Amazon EC2 Instance Connect
✅ 정답: D. Use AWS Systems Manager Session Manager
💡 정답 해설
1️⃣ Amazon EC2 Instance Connect
Amazon Linux 2 또는 Ubuntu 등 지원되는 AMI에서 SSH 접속을 대신해주는 AWS 기능.
브라우저 기반 SSH 접속 기능으로, AWS 콘솔에서 바로 접속 가능.
키 페어 없이도 일시적(temporary) 공개키를 전송해 연결 가능.
전제 조건:
EC2 인스턴스에 EC2 Instance Connect 패키지 설치
인바운드 22번 포트(SSH) 열려 있어야 함
IAM 권한: ec2-instance-connect:SendSSHPublicKey
2️⃣ AWS Systems Manager Session Manager
EC2 인스턴스에 Session Manager 에이전트(SSM Agent) 가 설치되어 있으면 브라우저 기반 터미널 접속 가능.
SSH 포트(22) 가 열려 있지 않아도 안전하게 접속 가능.
VPC 내 비공개 인스턴스(Private Subnet) 도 연결 가능.
필요 조건:
EC2에 SSM Agent 설치
IAM 역할에 SSM 관련 권한 부여 (AmazonSSMManagedInstanceCore)
AWS Systems Manager 서비스 활성화
❌ 오답 해설
보기
설명
오답 이유
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)
```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 (지속 가능성 기둥) 의 핵심 원칙을 묻는 문제입니다.
최근 시험에서 자주 등장하는 유형
📘 Q358.
Which design principles should a company apply to AWS Cloud workloads to maximize sustainability and minimize environmental impact? (Choose two)
AWS 클라우드 워크로드의 지속 가능성을 극대화하고 환경적 영향을 최소화하기 위한 설계 원칙은 무엇입니까? (2개 선택)
✅ 정답: A. Maximize utilization of Amazon EC2 instances
✅ 정답: E. Reduce the need for users to reinstall applications
💡 정답 해설
AWS Sustainability Pillar 의 목표는
“최소한의 리소스로 최대의 성능을 달성하여 탄소 배출량과 낭비를 줄이는 것” 입니다 🌱
즉, 효율을 극대화하고, 중복 리소스 및 불필요한 작업을 줄이는 것이 핵심이에요.
✅ A. Maximize utilization of Amazon EC2 instances
사용 중인 인스턴스의 활용도를 극대화하여 낭비되는 컴퓨팅 자원을 줄임
예:
워크로드에 맞는 적절한 인스턴스 크기 선택
Auto Scaling 사용
Serverless나 container 기반 아키텍처 활용
📈 → 더 높은 리소스 효율성과 낮은 전력 소비로 지속 가능성 향상
✅ E. Reduce the need for users to reinstall applications
사용자가 애플리케이션을 자주 재설치하거나 중복 실행하지 않도록 설계
예:
중앙 집중 배포(Auto-deploy pipelines)
캐싱 및 자동 복원 기능 적용
지속 가능한 유지보수 설계
♻️ → 재작업을 줄여 불필요한 컴퓨팅, 스토리지 사용, 네트워크 부하 감소
❌ 오답 해설
보기
설명
이유
B. Minimize utilization of Amazon EC2 instances
리소스를 적게 쓰는 게 아니라, 효율적으로 쓰는 것이 중요
❌ EC2를 무조건 줄이면 성능 저하 및 낭비 발생 가능
C. Minimize usage of managed services
관리형 서비스는 효율을 높여 오히려 탄소 절감을 도와줌
❌ 잘못된 접근
D. Force frequent application reinstallations by users
재설치 과정이 오히려 에너지 낭비
❌ 비효율적, 지속 가능성과 반대
🌍 AWS Sustainability 설계 원칙 요약
원칙
설명
1️⃣ Region 선택 최적화
에너지 효율이 높은 리전 선택 (예: 재생 에너지 비율 높은 리전)
2️⃣ 리소스 활용률 극대화
Idle 상태 최소화, 오토스케일링 적용
3️⃣ 고효율 서비스 사용
Serverless, Managed Service 활용
4️⃣ 데이터 이동 최소화
전송 에너지 절감
5️⃣ 아키텍처 효율적 설계
캐싱, 압축, 병렬 처리 최적화
6️⃣ 재작업 최소화
자동화로 불필요한 재처리 방지
📊 시각 요약 (Mermaid)
```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 지속 가능성의 핵심은 **“적게 쓰는 것”이 아니라, “효율적으로 쓰는 것”**입니다.
📘 Q359.
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개 선택)
✅ 정답: A. AWS replaces upfront capital expenditures with pay-as-you-go costs.
✅ 정답: D. AWS uses economies of scale to continually reduce prices.
💡 정답 해설
AWS는 비용 구조 혁신(Cost Model Innovation) 을 통해 온프레미스 대비 TCO(총소유비용, Total Cost of Ownership) 를 획기적으로 낮출 수 있습니다. 그 핵심은 다음 두 가지입니다 👇
✅ A. AWS replaces upfront capital expenditures with pay-as-you-go costs
온프레미스 환경에서는 서버, 네트워크, 스토리지 등의 초기 자본 지출(CapEx) 이 필요합니다.
반면 AWS는 운영비용(OpEx) 모델, 즉 사용한 만큼 지불(Pay-as-you-go) 방식을 제공합니다.
즉, 초기 투자 없이도 즉시 인프라 사용 가능 → 비용 효율성과 확장성 향상
📈 효과:
초기 하드웨어 구매, 설치, 유지보수 비용 제거
불필요한 용량 계획(capacity planning) 불필요
사용량에 따른 유연한 지출 구조
✅ D. AWS uses economies of scale to continually reduce prices
AWS는 전 세계 수백만 고객의 수요를 기반으로 규모의 경제(Economies of Scale) 를 실현합니다.
대규모 인프라 운영을 통해 단가를 낮출 수 있고, 그 절감된 비용을 고객에게 지속적인 가격 인하 형태로 환원합니다.
📊 예시:
AWS는 지난 10년간 100회 이상 공식 가격 인하(Price Reduction) 발표
클라우드 전체 인프라 효율이 향상될수록 고객의 단위당 비용도 절감
❌ 오답 해설
보기
설명
이유
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)
```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(로드 밸런서) 등의 기능을 혼동하지 않도록 정확히 구분해야 합니다.
📘 Q365.
What does Amazon CloudFront provide?
Amazon CloudFront는 무엇을 제공합니까?
✅ 정답: B. Secure delivery of data, videos, applications, and APIs to users globally with low latency
전 세계 사용자에게 짧은 지연시간(low latency) 과 보안성 높은 콘텐츠 전송을 제공합니다.
💡 정답 해설
🧭 Amazon CloudFront란?
AWS의 글로벌 콘텐츠 전송 네트워크(CDN, Content Delivery Network) 서비스입니다.
데이터를 가까운 엣지 로케이션(Edge Location) 에 캐싱하여 전 세계 사용자에게 더 빠르고 안전하게 콘텐츠를 전달합니다.
✅ 주요 기능
기능
설명
콘텐츠 캐싱(Content Caching)
엣지 로케이션에 정적/동적 콘텐츠를 저장하여 지연시간 단축
보안 강화(Security)
AWS Shield, WAF, SSL/TLS 통합 지원
글로벌 분산 전송(Global Distribution)
100개 이상의 엣지 로케이션에서 콘텐츠 제공
통합 보호
S3, ALB, EC2, API Gateway 등과 직접 통합되어 콘텐츠 배포
Low Latency + High Transfer Speed
사용자 위치 기반 자동 라우팅으로 빠른 응답 제공
📦 대표적인 CloudFront 사용 예시
시나리오
설명
🎬 미디어 스트리밍
전 세계에 고화질 비디오를 빠르게 전송 (예: 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)
```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)을 묻는 문제입니다.
📘 Q387.
Which AWS Cloud Adoption Framework (AWS CAF) capabilities belong to the governance perspective? (Choose two)
거버넌스 관점에 속하는 AWS Cloud Adoption Framework(AWS CAF) 기능은 무엇입니까? (2개 선택)
✅ 정답: A. Program and project management
✅ 정답: D. Risk management
💡 해설
🔹 AWS CAF (Cloud Adoption Framework)란?
AWS CAF는 조직이 클라우드 도입(Cloud Adoption)을 체계적으로 계획하고 실행할 수 있도록 6가지 관점(perspective)으로 나누어 제시하는 프레임워크입니다.
🧭 AWS CAF 6가지 관점 요약
관점 (Perspective)
주요 목표
대표 Capabilities (핵심 기능)
Business (비즈니스)
비즈니스 전략 정렬 및 재무 효과 분석
IT Investment Portfolio Management, Business Case Development
People (인적자원)
인력, 기술, 문화 변화 관리
Workforce Transformation, Training and Readiness
Governance (거버넌스)
위험, 정책, 포트폴리오 관리 및 프로젝트 통제
✅ Program & Project Management, ✅ Risk Management, Portfolio Management
✅ 인프라 관리 부담 감소 (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를 사용해 사업부별로 계정을 분리하면, 자동으로 비용이 구분되고, 운영 오버헤드를 최소화할 수 있습니다.
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)
```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["🗄️ 클라이언트 측 암호화, 백업, 보안 그룹 구성"]
```
💬 구성 설명
☁️ AWS Responsibility (Security of the Cloud)
🏗️ 데이터센터, 네트워크, 하드웨어 → 물리적 보안 및 글로벌 인프라 관리
🌎 리전, AZ, 엣지 로케이션 관리 → 안정적 서비스 제공을 위한 인프라 계층 운영
👤 Customer Responsibility (Security in the Cloud)
🔒 리소스 보안 → IAM, 접근 제어, 암호화 설정 관리
💾 데이터 관리 → 백업, 클라이언트 암호화, 보안 그룹 구성
✅ 핵심 정리
구분
책임
주체 예시
Security of the Cloud
AWS
리전, AZ, 엣지 로케이션, 하드웨어, 네트워크
Security in the Cloud
고객
IAM, 데이터 암호화, 보안 그룹, 애플리케이션 설정
📗 한 줄 요약
AWS는 “클라우드의 보안”을, 고객은 “클라우드 안의 보안”을 책임진다. 즉, IAM과 데이터 암호화는 고객의 몫입니다. 🔒
📘 Q106.
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 보안 모범 사례 (Best Practices)
항목설명
🧱 루트 계정 최소화
루트 계정은 오직 결제나 초기 설정용으로만 사용
🔑 IAM 사용자/역할(Role) 사용
개별 IAM 사용자 생성, 필요시 역할 기반 접근 부여
⚙️ 최소 권한 부여 (Least Privilege)
업무 수행에 꼭 필요한 권한만 부여
🔒 MFA(Multi-Factor Authentication)
루트 계정 및 중요 IAM 사용자에 다중 인증 적용
🔐 비밀번호 정책 설정
최소 길이, 복잡도, 주기적 변경 등 적용
📊 CloudTrail 활성화
모든 IAM/API 활동 로깅 및 감사 추적 유지
🧠 시각 요약 (Mermaid)
```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 계정 🔒
📘 Q128.
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)
```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” 조합이 가장 경제적이다.
📘 Q131.
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)
```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["💰 비용 통합 관리 및 청구 보고"]
```
💬 구성 설명
🏢 회사 계정 구조 (Organization) AWS Organizations 기반으로 전체 계정 구조 관리
🧾 Payer Account (Consolidated Billing) 모든 부서 계정의 비용을 통합 청구 및 관리
📂 Dept A / B / C Accounts 각 부서별로 독립적인 AWS 리소스 운영 (R&D, Marketing, Finance 등)
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)
```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 전략! 💪
📘 Q82. Consolidated Billing — 통합 결제의 이점
❓ 문제 요약
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)
```mermaid
flowchart TD
A1[👥 여러 AWS 계정] --> B1[🏢 AWS Organizations]
B1 --> C1[💳 Consolidated Billing]
C1 --> D1[🧾 하나의 청구서로 통합 관리]
C1 --> E1[💰 합산 사용량 기준으로 Volume Discount 적용]
```
AWS 클라우드의 가장 큰 장점은 “비용 효율성(Pay-as-you-go)” + “유연한 확장성(Elastic Capacity)” 입니다. 🌩️
📘 Q97. How does AWS Cloud computing help businesses reduce costs?
❓ 문제 요약
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)
```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) 을 극대화합니다. 🚀
📘 Q99. Responsibility of AWS when using AWS services
❓ 문제 요약
AWS 서비스를 사용할 때, AWS가 책임지는 영역은 무엇입니까?
✅ 정답: C. Maintenance of physical and environmental controls
💡 정답 해설
AWS와 고객은 보안 책임을 공유(Shared Responsibility) 합니다. AWS는 클라우드 “안의” 보안(Security of the Cloud) 을, 고객은 클라우드 “내의” 보안(Security in the Cloud) 을 담당합니다.
✅ AWS의 책임 (Security of the Cloud)
영역
설명
🏗️ 물리적 보안 (Physical Security)
데이터센터 출입 통제, 감시 시스템, 전력 공급, 냉각 등
🌎 환경적 제어 (Environmental Controls)
화재 감지, 냉각, 전력 이중화 등 인프라 유지
🧱 하드웨어 및 네트워크 인프라 관리
서버, 스토리지, 네트워크 장비 유지 및 보안
🧩 하이퍼바이저 및 물리적 호스트 관리
EC2, EBS, RDS 등을 구동하는 인프라 계층 운영
✅ 고객의 책임 (Security in the Cloud)
영역
설명
👤 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)
```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)” 을 관리해야 합니다. 🔒
✅ 정답:B. Configure and deploy an AWS Storage Gateway file gateway.
💡 정답 해설
🔹 선택지 B: AWS Storage Gateway –File Gateway
온프레미스 환경에서 사용하는파일 서버와 AWS S3를 연결하는 서비스.
사용자는 로컬 네트워크의SMB/NFS 공유 방식으로 파일에 접근.
백엔드에서는 자동으로S3에 업로드/저장, 자주 쓰는 파일은 로컬 캐시에 남겨 빠른 액세스 가능.
결과적으로온프레미스의 성능 + 클라우드의 확장성을 모두 얻을 수 있음.
운영 효율성(Operation Efficiency)이 가장 높음 ✅
❌ 오답 해설
보기설명틀린 이유
A. Amazon S3 버킷을 사용자별로 생성
각 사용자가 직접 S3 버킷을 마운트
관리 복잡성 높고, 로컬 캐싱 없음 → 비효율적 ❌
C. Amazon WorkSpaces + WorkDocs
클라우드 기반 가상 데스크탑 & 문서 협업 서비스
단순 파일 저장/공유 시 오버엔지니어링 ❌
D. EC2 + EBS 공유
EBS를 EC2에 연결해 네트워크 공유
EBS는 인스턴스 전용 스토리지로 여러 사용자 공유 불가 ❌
📊 비교 요약
항목AWS Storage GatewayS3 직접 마운트WorkSpaces/WorkDocsEC2 + EBS
로컬 접근 속도
✅ 빠름 (캐시)
❌ 느림
⚙️ 제한적
⚙️ 제한적
AWS 확장성
✅ 자동 확장
✅ 자동 확장
⚙️ 문서 중심
⚙️ 제한적
운영 효율성
✅ 가장 높음
❌ 사용자별 관리 필요
❌ 관리 오버헤드
❌ 기술적 제약
권장 사례
파일 서버 확장
단순 백업
협업 문서 관리
블록 스토리지 전용
🔍 핵심 요약
“온프레미스에서 사용 중인 파일 서버를 클라우드로 확장하려면 AWS Storage Gateway File Gateway를 사용하여 로컬 캐시 성능을 유지하면서 S3에 확장 저장소를 구축하라.”
🧩 구조 시각화
flowchart LR A[On-Premise Users] -->|SMB/NFS Access| B[File Gateway] B -->|Cache & Upload| C[(Amazon S3 Bucket)] C --> D[Scalable Cloud Storage] B -.->|Local Cache| E[Fast Local Performance]
✅정답: B. AWS Storage Gateway File Gateway ☁️핵심 개념:하이브리드 파일 스토리지 확장 + 로컬 캐싱 + S3 연동
📘 Q24. Internet Gateway의 역할
❓ 문제 요약
VPC(가상 사설 클라우드)내에 Internet Gateway(IGW)를 추가하는 이유는?
✅ 정답:B. To allow communication between the VPC and the Internet
VPC와 인터넷 간의 양방향 통신을 가능하게 하기 위함이다.
💡 정답 해설
🔹 Internet Gateway란?
AWS VPC 내부 리소스(예: EC2 인스턴스)가인터넷과 통신할 수 있도록 연결해주는출입문 역할
양방향 트래픽허용:
Outbound:EC2 → 인터넷
Inbound:인터넷 → EC2 (보안 그룹에서 허용 시)
IGW를 연결하고,Route Table에 0.0.0.0/0 → IGW 경로를 추가해야 외부 통신 가능
❌ 오답 해설
보기
설명
왜 틀렸는가
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와 인터넷 간 통신을 가능하게 하는 관문 역할을 한다.”
📘 Q34. AWS Cloud에서의 민첩성(Agility) 개념
❓ 문제 요약
AWS 클라우드 컴퓨팅에서 “민첩성(Agility)”의 개념은 무엇을 의미하는가? (정답 2개 선택)
✅ 정답:A, C
💡 정답 해설
선택지
설명
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)
```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
📘 Q39. IAM 보안 모범 사례 (IAM Security Best Practice)
❓ 문제 요약
한 회사가 AWS 계정에 IAM을 설정하고 있습니다. 다음 중보안 모범 사례에 해당하는 것은 무엇입니까?
✅ 정답:C. Turn on multi-factor authentication (MFA) for added security during the login process
💡 정답 해설
🔹 MFA(Multi-Factor Authentication)
IAM 보안의기본이자 핵심 모범 사례✅
비밀번호 외에도추가 인증 요소(예: OTP, 하드웨어 토큰, 앱 인증)를 요구하여 보안을 강화
루트 계정 및 관리자 계정은 반드시MFA 활성화권장
💬 즉, 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 회전이 보안 모범 사례
📊 IAM 보안 모범 사례 요약
항목
설명
🔐MFA 활성화
모든 루트 및 관리자 사용자에 MFA 설정
👥루트 계정 최소 사용
루트 계정은 계정 설정 외엔 사용하지 않기
🎯최소 권한 원칙(Least Privilege)
사용자에게 꼭 필요한 권한만 부여
🔄정기적 Credential Rotation
액세스 키와 암호를 주기적으로 교체
🧱IAM Roles 사용
애플리케이션 접근은 사용자 키 대신 역할(Role)로 처리
🧩 구조 시각화 (Mermaid)
```mermaid
flowchart TD
A[🔑 IAM User Login] --> B[🔐 MFA 인증 단계 추가]
B --> C[✅ 로그인 성공]
A -. 비밀번호 유출시 .-> X[❌ 로그인 실패 (MFA 차단)]
```
🧠 핵심 요약
AWS IAM 보안의 첫 단계는MFA 활성화, 그 다음은루트 계정 최소 사용과최소 권한 원칙 적용입니다.
📘 Q40. Elasticity in AWS Cloud
❓ 문제 요약
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)
```mermaid
flowchart LR
A[📈 수요 증가] --> B[⚙️ Auto Scaling: EC2 인스턴스 추가]
B --> C[💡 성능 유지]
C --> D[📉 수요 감소]
D --> E[⚙️ Auto Scaling: 인스턴스 종료]
E --> F[💰 비용 절감]
```
🧠 핵심 요약
탄력성(Elasticity)= “시시각각 변하는 수요에 따라 IT 리소스를 자동으로 확장하거나 축소할 수 있는 능력.”
→ 즉, 필요한 만큼만 사용하고, 필요 없으면 자동으로 줄이는 것!
📘 Q49. Global Content Delivery — CloudFront
❓ 문제 요약
한 회사가 이미지와 비디오를전 세계 사용자에게 최소한의 지연(latency)으로 전달해야 합니다. 비용 효율적인 방법으로 이를 달성하기 위해 어떤 접근 방식을 사용해야 할까요?
✅ 정답:A. Deliver the content through Amazon CloudFront
💡 정답 해설
🔹Amazon CloudFront
AWS의콘텐츠 전송 네트워크(CDN)서비스입니다. 정적(이미지, 동영상, HTML 등)과 동적 콘텐츠를전 세계 엣지 로케이션(Edge Location)에 캐싱하여, 사용자에게가장 가까운 위치에서 빠르게 제공합니다.
👉 핵심 효과:
🌎 글로벌 전송 속도 향상 (지연 최소화)
💰 S3나 EC2와 연동 시비용 절감
🔒 SSL/TLS, WAF 등 보안 기능 통합 가능
❌ 오답 해설
보기
설명
왜 틀렸는가
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)
```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
```
요구사항: 특정 승인된 AWS 계정만 해당 AMI를 안전하게 사용할 수 있도록 공유해야 함.
✅ 정답
B. AMI가 생성된 계정에서 고객 관리형 KMS 키를 생성하고, 키 정책을 수정해 다른 AWS 계정에 권한을 부여한 뒤, 복사본 AMI를 생성하여 공유 계정 번호를 지정한다.
KMS 키로 암호화된 AMI를 다른 계정과 공유하려면:
KMS 키 정책 수정 → 대상 계정에 kms:DescribeKey, kms:ReEncrypt*, kms:CreateGrant, kms:Decrypt 권한 부여.
AMI 권한 수정 및 복사본 생성 → 공유하려는 계정 번호 지정.
이 방식이 가장 안전하고 AWS 권장 방식.
❌ 오답 해설
A. 단순히 AMI 권한만 수정 → KMS 키 권한 부여가 빠져있음. 암호화된 AMI는 키 권한 없이는 공유 계정에서 사용할 수 없음.
C. 복사본 AMI 생성 후 공개 → “공개”로 만들면 모든 계정이 접근 가능 → 보안 위협. 승인된 계정만 접근해야 한다는 조건 위배.
D. AWS 관리형 키 사용 → 관리형 키는 다른 계정과 직접 공유 불가. 반드시 고객 관리형 KMS 키를 사용해야 함.
📊 비교 요약
옵션
설명
적합 여부
A
AMI 권한만 수정
❌ 키 권한 누락
B
KMS 키 정책 수정 + 복사본 AMI 공유
✅ 정답
C
AMI 공개
❌ 보안 위협
D
AWS 관리형 키 사용
❌ 공유 불가
🎯 핵심 정리
암호화된 AMI 공유 = KMS 키 정책 수정 + AMI 권한 수정 두 단계가 필요.
AWS 관리형 키(X), 고객 관리형 KMS 키(O).
📘 오답노트 - Q278
❓ 문제 요약
SysOps 관리자는 Auto Scaling 그룹의 EC2 인스턴스에 애플리케이션을 배포해야 함.
애플리케이션 업데이트는 매주 발생.
AMI 생성 시 취약점 검사도 필요.
요구사항: 효율적이고 자동화된 업데이트 및 배포.
✅ 정답
C. 사용자 지정 레시피와 함께 EC2 Image Builder를 사용하여 애플리케이션과 해당 종속성을 설치한다.
EC2 Image Builder는
OS 및 애플리케이션 패치를 자동화,
AMI 생성 및 업데이트 자동화,
취약점 검사(Security Scan) 지원.
운영 효율성과 보안 요구를 동시에 충족.
❌ 오답 해설
A. Packer 사용 → 가능은 하지만 서드파티 도구. AWS 네이티브 서비스보다 관리 오버헤드 큼.
B. EC2 인스턴스에 직접 설치 후 AMI 생성 → 수동 작업으로 운영 효율성 낮음. 자동화 및 취약점 검사 부족.
D. EventBridge + CreateImage API 호출 → 단순 자동화는 가능하나, 취약점 검사나 종속성 설치 관리 기능 없음.
📊 비교 요약
옵션
설명
적합 여부
A
Packer 스크립트 기반 이미지 생성
❌ (서드파티, 오버헤드)
B
인스턴스에서 직접 설치 후 AMI 생성
❌ (비효율적, 자동화 부족)
C
EC2 Image Builder → 자동화 + 보안 검사 + 종속성 관리
✅ 정답
D
EventBridge로 CreateImage API 호출
❌ (단순 자동화, 보안 기능 없음)
🌐 동작 원리 (Mermaid)
```mermaid
flowchart TD
Update["📅 매주 애플리케이션 업데이트"] --> ImageBuilder["🏗️ EC2 Image Builder"]
ImageBuilder --> Recipe["📜 사용자 지정 레시피 + 🔒 보안 스캔"]
Recipe --> AMI["📦 최신 보안 적용 AMI 생성"]
AMI --> AutoScaling["⚖️ Auto Scaling 그룹에 배포"]
AutoScaling --> UpdatedEC2["💻 최신 애플리케이션 설치된 EC2 인스턴스"]
```
📊 결과 설명
📅 매주 애플리케이션 업데이트 시작
→ 🏗️ EC2 Image Builder 를 사용
→ 📜 사용자 지정 레시피 + 🔒 보안 스캔 적용
→ 📦 최신 보안 적용 AMI 생성
→ ⚖️ Auto Scaling 그룹에 배포
→ 최종적으로 💻 최신 애플리케이션 설치된 EC2 인스턴스 실행
🎯 핵심 정리
문제의 요구사항은 매주 업데이트 + 취약점 검사 + 운영 효율성.
이 조건을 모두 만족하는 AWS 네이티브 서비스는 EC2 Image Builder.
따라서 정답은 C. EC2 Image Builder 사용.
📘 오답노트 - Q279
❓ 문제 요약
CloudFormation 템플릿으로 RDS 인스턴스를 생성.
스택이 삭제되더라도 RDS의 데이터는 보존해야 함.
요구사항: 안정적이고 효율적으로 데이터 보호.
✅ 정답
C. RDS 인스턴스의 CloudFormation 템플릿 정의에서 스냅샷 삭제 정책을 사용한다.
CloudFormation에서는 리소스 삭제 시 행동을 제어하는 DeletionPolicy 속성이 있음.
DeletionPolicy: Snapshot을 사용하면 스택 삭제 시 RDS 인스턴스 자체는 삭제되지만 스냅샷이 자동으로 남아 데이터 보존 가능.
운영 효율성과 안정성을 동시에 충족.
❌ 오답 해설
A. 5분마다 스크립트로 백업 → 불필요하게 비효율적이며, 자동화된 CloudFormation 기능을 활용하지 않음.
B. Lambda 함수로 스택 삭제 전 스냅샷 생성 → 가능하지만 불필요하게 복잡하고, CloudFormation 네이티브 방식보다 운영 오버헤드 큼.