[AWS CLF-C02] Q401 ~ Q500 오답노트 13EA

📘 Q403.

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) 포트 허용
  • 다른 트래픽은 모두 차단

 

Inbound Rule: Type: MySQL/Aurora (3306) Source: sg-0a1b2c3d4e5f (웹서버 SG)

✅ 이렇게 하면 DB 인스턴스는 지정된 웹 서버 SG에서 오는 요청만 수락합니다.

---

❌ 오답 해설

보기	설명	오답 이유
A. Network ACLs	서브넷 단위(Subnet-level) 트래픽 제어, Stateless 방식	❌ 인스턴스 간 세부 제어 불가능
B. AWS WAF	웹 애플리케이션 계층(7계층)에서 HTTP/HTTPS 요청 필터링	❌ EC2 간 내부 네트워크 제어와 무관
C. Amazon GuardDuty	위협 탐지(Threat Detection) 서비스로, 트래픽 제어 불가능	❌ 모니터링 용도일 뿐 제어 불가
D. Security groups	✅ 인스턴스 수준에서 트래픽 제어 (정답)	✅

---

🧩 시각 요약 (Mermaid)

 

```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 버킷을 삭제했는지” 확인해야 한다면?

1. CloudTrail 콘솔 → Event history(이벤트 기록) 로 이동
2. Event Name = DeleteBucket 검색
3. 결과에서 userIdentity 필드를 확인
   → 해당 작업을 수행한 사용자 또는 IAM Role을 확인 가능

---

📦 로그 저장 구조 (예시)

 

{
  "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)

 

```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 리소스를 반복적이고 일관되게 배포할 수 있습니다.

---

✅ 핵심 개념

개념	설명
📄 템플릿(Template)	EC2, VPC, S3, RDS 등 리소스 정의를 코드로 기술
🧱 스택(Stack)	템플릿을 실행해 실제로 생성된 리소스 묶음
🔁 반복 가능성(Repeatability)	동일한 템플릿으로 여러 환경(Dev/Test/Prod)을 일관되게 배포 가능
💥 자동 롤백	배포 실패 시 이전 상태로 자동 복구
🔐 버전 관리 및 협업 가능	GitHub 등과 연동하여 IaC 파이프라인 구축 가능

---

⚙️ 예시 (CloudFormation 템플릿 - YAML)

 

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 서비스를 묻고 있습니다.

---

📘 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의 클라우드 네이티브 기능을 최대한 활용하는 현대화 전략입니다.

---