[AWS SOA-C02] Q430 ~ Q478 오답노트 3EA

📘 오답노트 - Q430

❓ 문제 요약

• 회사는 기존 Amazon Route 53 프라이빗 호스팅 영역을
  새로 생성한 VPC에 적용하려고 함.
• 목표: VPC 내부에서 사용자 정의 리소스 이름을 확인 가능하게 만드는 것.

---

✅ 정답

A. Route 53 프라이빗 호스팅 영역을 VPC와 연결한다.

• 프라이빗 호스팅 영역은 해당 VPC 내부에서만 DNS 쿼리를 처리 가능.
• 따라서, 단순히 새 VPC를 생성하는 것만으로는 동작하지 않고
  → 반드시 호스팅 영역을 VPC와 연결(Associate) 해야 함.

---

❌ 오답 해설

• B. Resolver에 대한 보안 그룹 규칙 생성
  → Route 53 Resolver는 프라이빗 호스팅 영역 사용과 직접적 관련 없음.
• C. VPC ACL 확인
  → ACL은 네트워크 트래픽 제어용이며, DNS 이름 확인 기능을 제공하지 않음.
• D. 라우팅 테이블 경로 확인
  → 경로(Route)는 IP 트래픽 전달 제어이지, DNS 이름 확인과 무관.

---

📊 비교 요약

옵션	설명	적합 여부
A	프라이빗 호스팅 영역을 VPC에 연결 (DNS 질의 허용)	✅ 정답
B	Resolver 보안 그룹 규칙 (관련 없음)	❌
C	네트워크 ACL 설정 (DNS 이름 확인과 무관)	❌
D	라우팅 테이블 경로 확인 (IP 기반 트래픽 관련, DNS 아님)	❌

---

🌐 동작 흐름 (Mermaid)

```mermaid
flowchart TD
    CreateVPC["🆕 새 VPC 생성"] --> Associate["🔗 Route 53 Private Hosted Zone 연결"]
    Associate --> DNSQuery["🔍 VPC 내부 DNS 쿼리 가능"]
    DNSQuery --> Success["✅ 사용자 정의 리소스 이름 확인 성공 🎉"]

```

📊 결과 설명

• 🆕 새 VPC 생성 → 🔗 Route 53 Private Hosted Zone 연결
• 연결 후 🔍 VPC 내부에서 DNS 쿼리 가능
• 최종적으로 ✅ 사용자 정의 리소스 이름 확인 성공 🎉

---

🎯 핵심 정리

• Route 53 프라이빗 호스팅 영역은 반드시 VPC와 연결해야 DNS 질의 처리 가능.
• 네트워크 ACL / 라우팅 테이블 / 보안 그룹은 네트워크 계층 트래픽 제어용이지, DNS와 직접적인 관계 없음.

---

👉 이 문제는 Q200, Q363 같이 VPC + Route 53 DNS Resolver 관련 문제와 묶어두면,
“DNS 이름 확인을 위해서는 → 프라이빗 호스팅 영역 연결 or Resolver 엔드포인트 구성 필요” 라는 패턴으로 정리하기 좋습니다.

---

📘 오답노트 - Q434

❓ 문제 요약

• 회사는 MariaDB 다중 AZ 배포의 Amazon RDS 사용 중.
• 계획된 유지 관리 이벤트(예: 패치, 장애 조치) 시 몇 분 동안 DB 장애가 발생하여 애플리케이션 사용 불가.
• 목표: 애플리케이션의 자동 중지 시간을 최소화.

---

✅ 정답

D. 데이터베이스와 연결된 RDS 프록시를 생성한다.

• RDS Proxy는 DB와 애플리케이션 사이에서 연결 풀을 관리.
• 장애 조치(Failover) 발생 시, 애플리케이션 연결을 유지하고 새로운 DB 인스턴스로 빠르게 전환 가능.
• 따라서 자동 중지 시간(다운타임) 단축에 최적.

---

❌ 오답 해설

• A. 여러 라이터 인스턴스 MariaDB RDS 생성
  → MariaDB는 기본적으로 단일 라이터 구조. Aurora와 달리 Multi-Master를 지원하지 않음.
• B. 유휴 연결 풀링 설정
  → 단순 풀링은 DB 연결 유지에는 도움이 되지만, 장애 조치 시 연결 자동 전환 불가.
• C. ElastiCache 캐시 구성
  → 읽기 성능 개선에는 유효하지만, DB 장애 조치 시 중지 시간을 줄이는 데는 직접적인 도움 없음.

---

📊 비교 요약

옵션	설명	적합 여부
A	MariaDB에 Multi-Master RDS 생성 (Aurora만 해당, 불가)	❌
B	유휴 연결 풀링 (Failover 처리 불가)	❌
C	ElastiCache로 캐싱 (성능 개선, 다운타임 해결 아님)	❌
D	RDS Proxy 사용 (Failover 시 연결 유지, 다운타임 최소화)	✅ 정답

---

🌐 동작 흐름 (Mermaid)

 

```mermaid
flowchart TD
    App["💻 애플리케이션"] --> Proxy["🔗 RDS Proxy: 연결 풀 관리"]
    Proxy --> DB1["🗄️ DB 인스턴스 A"]
    Proxy --> DB2["🗄️ DB 인스턴스 B: Failover"]
    DB1 -.->|"⚠️ Failover 발생"| DB2
    Proxy --> AppResponse["✅ 연결 유지, 다운타임 최소화 🎉"]
```

📊 결과 설명

• 💻 애플리케이션 → 🔗 RDS Proxy 를 통해 DB 연결 관리
• RDS Proxy는 🗄️ DB 인스턴스 A (기본)와 🗄️ DB 인스턴스 B (Failover용) 을 연결
• ⚠️ Failover 발생 시 A → B 로 전환
• 최종적으로 ✅ 연결 유지, 다운타임 최소화 🎉

---

🎯 핵심 정리

• RDS Proxy는 장애 조치 시 연결 풀을 관리하여 애플리케이션 다운타임을 최소화한다.
• ElastiCache는 읽기 성능 향상 목적이지, 장애 조치 복구와는 별개.
• MariaDB 다중 AZ 환경에서 자동 중지 시간 최소화 문제 → RDS Proxy가 정답.

---

📘 오답노트 - Q453

❓ 문제 요약

• 회사는 AWS 계정 지출을 추적해야 함.
• 실제 비용이나 예상 비용이 특정 임계값 초과 시 알림을 받아야 함.
• 조건: 운영 오버헤드가 가장 적은 솔루션 필요.

---

✅ 정답

D. AWS 예산(Budgets)에서 반복 비용 예산을 작성하고, 실제/예상 비용에 대한 알림을 구성한다.

• AWS Budgets는 비용과 사용량에 대해 임계값 기반 알림을 제공.
• SNS(Amazon Simple Notification Service)와 연계해 이메일/SMS/주제 구독 형태로 알림 발송 가능.
• 운영 오버헤드가 가장 낮고 AWS에서 권장하는 솔루션.

---

❌ 오답 해설

• A. IAM 역할 + Cost Explorer 모니터링
  → Cost Explorer는 분석/리포트 용도이며 실시간 알림 제공 불가.
• B. Predict + Lambda
  → Amazon Predict는 오래된 서비스이며 비용 추적과는 관련 없음. 과도한 복잡성.
• C. 비용 보고서 + SNS 예약
  → 비용 및 사용 보고서는 CSV 형태 리포트이며 실시간 알림 불가. SNS로 직접 알림 연동도 안 됨.

---

📊 비교 요약

옵션	설명	적합 여부
A	Cost Explorer 보고서 기반 확인, 알림 기능 없음	❌
B	예측 + Lambda, 불필요하게 복잡	❌
C	비용 보고서 작성 + SNS 예약, 실시간 아님	❌
D	AWS Budgets에서 비용 임계값 설정 + SNS 알림 연동	✅ 정답

---

🌐 동작 흐름 (Mermaid)

```mermaid
flowchart TD
    Cost["💰 AWS 비용 및 예상 비용 추적"] --> Budgets["📊 AWS Budgets: 예산 임계값 설정"]
    Budgets -->|"⚠️ 임계값 초과"| SNS["📨 Amazon SNS: 알림 전송"]
    SNS --> Email["📧 이메일 / SMS 알림 수신"]
```

📊 결과 설명

• 💰 비용 및 예상 비용 추적
• → 📊 AWS Budgets 에서 임계값 설정
• → ⚠️ 임계값 초과 시 📨 SNS 알림 전송
• → 최종적으로 📧 이메일/SMS로 알림 수신

---

🎯 핵심 정리

• 비용 임계값 초과 시 자동 알림 = AWS Budgets + SNS 연계가 정답.
• Cost Explorer/보고서 기반은 수동 확인 용도.
• 운영 오버헤드 최소화, 실시간 알림 필요 → Budgets 사용이 Best Practice.

---