[AWS SOA-C02] Q342 ~ Q382 오답노트 7EA

📘 오답노트 - Q342

❓ 문제 요약

• 회사는 EC2에서 HPC(고성능 컴퓨팅) 애플리케이션을 실행 중.
• 두 개 이상의 EC2 인스턴스를 확장해야 함.
• HPC 특성상 짧은 지연 시간, 빠른 속도로 인스턴스 간 통신 필요.
• SysOps 관리자가 해야 할 일은?

---

✅ 정답

A. 클러스터 배치 그룹을 생성하고 EC2 인스턴스를 AMI로 복원하여 그룹에서 시작

• 클러스터 배치 그룹(Cluster Placement Group) 은 HPC 워크로드처럼 인스턴스 간의 저지연, 고대역폭 통신을 제공.
• 같은 가용 영역(AZ)에 인스턴스를 밀집 배치하여 네트워크 성능 극대화.
• 따라서 HPC 애플리케이션 요구사항을 충족하는 유일한 해답.

---

❌ 오답 해설

• B. AMI 생성 후 Auto Scaling
  → Auto Scaling은 가용성/확장성에는 좋지만, 저지연 통신 보장은 불가. HPC 환경 요구사항을 충족하지 못함.
• C. NLB 사용
  → 로드 밸런서는 외부 트래픽 분산용이지, 인스턴스 간 내부 통신 최적화와는 무관.
• D. 동일 AZ 내 복제본 생성
  → 단순히 같은 AZ 내에 있어도 저지연 고속 네트워킹이 보장되지 않음. 반드시 배치 그룹 필요.

---

📊 비교 표

옵션	설명	적합 여부
A	클러스터 배치 그룹 생성 → HPC용 저지연 네트워킹 보장	✅ 정답
B	AMI + Auto Scaling → 확장성 O, HPC 성능 ❌	❌
C	NLB → 외부 트래픽 로드 분산용, HPC 내부 통신 ❌	❌
D	동일 AZ 내 복제본 생성 → 위치만 같음, HPC 성능 ❌	❌

---

📊 HPC 인스턴스 배치 구조 (Mermaid)

```mermaid
graph TD
    subgraph AZ1["🏢 가용 영역: AZ1"]
        EC2A["💻 EC2 인스턴스 A"]
        EC2B["💻 EC2 인스턴스 B"]
        EC2C["💻 EC2 인스턴스 C"]
    end

    EC2A <--> EC2B
    EC2B <--> EC2C
    EC2A <--> EC2C

    AZ1 -.-> Note["⚡ 클러스터 배치 그룹: 저지연 + 고대역폭 네트워킹"]

```

📊 결과 설명

• 🏢 AZ1 내부에 💻 EC2 인스턴스 A, B, C 존재
• 모든 인스턴스 간에 양방향 네트워크 연결 (<-->)
• 점선으로 연결된 설명 노드: ⚡ 클러스터 배치 그룹 (저지연 + 고대역폭)

---

🎯 핵심 개념 정리

• HPC(고성능 컴퓨팅) 워크로드는 인스턴스 간 통신 지연 최소화가 핵심.
• 일반적인 Auto Scaling, NLB, 단순 복제본으로는 해결 불가.
• 해결책 = 클러스터 배치 그룹(Cluster Placement Group).

---

👉 Q342의 포인트는 HPC = Placement Group (Cluster) 이라는 연관성을 기억하는 것입니다.

---

📘 오답노트 - Q344

❓ 문제 요약

• 회사는 us-west-2 리전 ALB 뒤 애플리케이션을 운영 중.
• Route 53 레코드는 app.anycompany.com → us-west-2 ALB.
• 최근 ap-southeast-2 리전 사용자 증가 → 지연 시간(latency) 문제 발생.
• 애플리케이션 사본을 ap-southeast-2에도 배포.
• 목표: URL 변경 없이 가장 낮은 대기 시간의 엔드포인트로 라우팅.

---

✅ 정답

C. 대기 시간 라우팅 정책(Latency Routing Policy)을 사용하도록 기존 별칭 레코드 변경

• Route 53의 Latency-based Routing은 사용자 요청을 지연 시간이 가장 짧은 리전의 리소스로 라우팅.
• 즉, 미국 사용자 → us-west-2, 호주/뉴질랜드 사용자 → ap-southeast-2.
• URL은 그대로 유지되면서 지리적으로 최적화된 접근이 가능.

---

❌ 오답 해설

• A. ap-southeast-2 ALB DNS 이름을 기존 레코드에 추가
  → 단순히 ALB DNS 이름을 추가하면 라운드 로빈처럼 작동. 지연 시간 기반 분산이 아님.
• B. 지리적 위치 라우팅 정책
  → 특정 국가/지역 기반으로만 라우팅. "지연 시간 최적화" 목적에는 맞지 않음.
• D. 다중값 라우팅 정책(Multi-Value Answer)
  → 여러 ALB DNS를 반환 → 클라이언트 단에서 무작위 선택. 지연 시간 보장은 없음.

---

📊 비교 표

옵션	설명	적합 여부
A	단순 DNS 추가 (라운드 로빈)	❌
B	지리 기반 라우팅 (국가 단위)	❌
C	지연 시간 라우팅 → 사용자에게 가장 가까운 리전 선택	✅ 정답
D	다중 DNS 응답 반환 (랜덤성, 지연 최적화 ❌)	❌

---

🌏 Route 53 Latency Routing 동작 구조 (Mermaid)

 

```mermaid
graph TD
    User1["👤 사용자: 미국 서부"] --> Route53["🌐 Amazon Route 53"]
    User2["👤 사용자: 호주"] --> Route53

    Route53 -->|"⚡ 낮은 지연 시간 선택"| ALB_US["⚖️ ALB: us-west-2"]
    Route53 -->|"⚡ 낮은 지연 시간 선택"| ALB_AUS["⚖️ ALB: ap-southeast-2"]
```

📊 결과 설명

• 👤 미국 서부 사용자, 👤 호주 사용자
  → 🌐 Route 53 으로 DNS 요청 전달
• Route 53은 ⚡ 지연 시간이 낮은 리전 선택
  • 미국 서부 → ⚖️ ALB (us-west-2)
  • 호주 → ⚖️ ALB (ap-southeast-2)

---

🎯 핵심 개념 정리

• Latency Routing Policy = "가장 가까운(지연 낮은) 리전"으로 트래픽 라우팅.
• 지리적 라우팅(Geolocation)과는 구별해야 함.
• 멀티 리전 애플리케이션 배포 시 가장 자주 쓰이는 정책.

---

👉 Q344 핵심 포인트는 멀티 리전 사용자 지연 시간 문제 = Route 53 Latency-based Routing이라는 점입니다.

---

📘 오답노트 - Q345

❓ 문제 요약

• 회사는 동일한 리전에 50개의 Amazon S3 버킷을 보유.
• Amazon EC2 인스턴스가 프라이빗 연결을 통해 S3 버킷과 안전하게 통신해야 함.
• 조건: 추가 비용이 없는 솔루션 필요.

---

✅ 정답

C. 모든 S3 버킷에 대해 하나의 게이트웨이 VPC 엔드포인트 생성 후 라우팅 테이블에 추가

• S3용 VPC Gateway Endpoint는 무료로 제공됨.
• 단일 엔드포인트로 리전 내 모든 S3 버킷에 접근 가능.
• 라우팅 테이블에 엔드포인트를 추가하면 EC2 → S3 트래픽이 프라이빗 네트워크 내부에서 안전하게 이동.

---

❌ 오답 해설

• A. 각 S3 버킷마다 개별 VPC Gateway Endpoint 생성
  → 엔드포인트는 S3 전체 서비스 단위로 동작. 버킷별 생성 불필요 + 관리 복잡도 증가.
• B. 각 S3 버킷마다 Interface Endpoint 생성
  → S3는 Interface Endpoint 대신 Gateway Endpoint가 권장됨. 또한 Interface Endpoint는 비용 발생.
• D. 모든 버킷에 대해 단일 Interface Endpoint 생성
  → 가능하나 비용 발생. 문제 조건(“추가 비용 없음”) 위배.

---

📊 비교 표

옵션	설명	비용	적합 여부
A	S3 버킷별 Gateway Endpoint 생성	무료	❌ 불필요/비효율
B	S3 버킷별 Interface Endpoint 생성	유료	❌ 비용 문제
C	단일 Gateway Endpoint 생성 후 라우팅 테이블 추가	무료	✅ 정답
D	단일 Interface Endpoint 생성	유료	❌ 비용 문제

---

🌐 VPC Endpoint 구조 (Mermaid)

```mermaid
graph TD
    EC2["💻 Amazon EC2 인스턴스"] --> VPC_GW["🔗 VPC Gateway Endpoint"]
    VPC_GW --> S3["📦 Amazon S3: 리전 내 모든 버킷"]

    VPC_GW -.-> Note["🔒 트래픽은 인터넷을 거치지 않고 VPC 내부에서 안전하게 전송됨"]

```

📊 결과 설명

• 💻 EC2 인스턴스 → 🔗 VPC Gateway Endpoint → 📦 Amazon S3
• 데이터 전송 시 🔒 인터넷을 거치지 않고 VPC 내부에서 안전하게 처리됨
• 점선 화살표로 보안 관련 부가 설명 강조

---

🎯 핵심 개념 정리

• VPC Endpoint 종류
  • Gateway Endpoint: S3, DynamoDB 전용 / 무료 / 라우팅 테이블 기반.
  • Interface Endpoint: ENI(Elastic Network Interface) 방식 / 대부분의 AWS 서비스 / 비용 발생.
• 문제 조건 "추가 비용 없음" = Gateway Endpoint 선택이 정답.

---

👉 Q345 핵심 포인트는 S3와 DynamoDB는 Gateway VPC Endpoint라는 점을 기억하는 것입니다.

---

📘 오답노트 - Q355

❓ 문제 요약

• 회사는 다수의 Amazon EC2 인스턴스에서 애플리케이션 실행 중.
• 요구사항: EC2 인스턴스 상태 변경(Event) 발생 시 운영팀에게 알림 제공.
• 조건: 가장 운영 효율적인 방법 선택.

---

✅ 정답

B. EC2 인스턴스 상태 변경을 캡처하는 Amazon EventBridge 규칙 생성 후 SNS 주제를 대상으로 설정

• Amazon EventBridge는 AWS 리소스 이벤트(예: EC2 상태 변경)를 자동으로 캡처.
• 이벤트를 Amazon SNS 주제로 전달하면 운영팀에 이메일/메시지 알림 전송 가능.
• 서버리스 + 자동화로 별도의 스크립트나 관리 부담 없음.

---

❌ 오답 해설

• A. 스크립트 + SNS
  → 수동적인 방식이며 EC2 전체에 스크립트를 설치해야 하므로 운영 오버헤드 증가.
• C. EventBridge + SNS + Lambda
  → 동작은 가능하나, 단순 알림만 필요할 때 Lambda는 불필요한 복잡성.
• D. AWS Config + Lambda + SNS
  → Config는 리소스 규정 준수/구성 변경 감시용. 단순 EC2 상태 변경 알림에는 과도한 솔루션.

---

📊 비교 표

옵션	방식	특징	적합 여부
A	스크립트 + SNS	운영자가 직접 스크립트 작성/관리 필요	❌ 비효율
B	EventBridge → SNS	자동화, 서버리스, 운영 부담 최소화	✅ 정답
C	EventBridge → Lambda → SNS	불필요한 Lambda 계층 추가	❌ 과도
D	Config 규칙 + Lambda + SNS	구성 규정 준수 목적, 단순 이벤트엔 과함	❌ 부적절

---

🌐 이벤트 흐름도 (Mermaid)

 

```mermaid
flowchart TD
    EC2["💻 EC2 인스턴스: 상태 변경"] --> EventBridge["🪢 Amazon EventBridge"]
    EventBridge --> SNS["📨 Amazon SNS: 주제"]
    SNS --> OpsTeam["👨‍💻 운영팀 알림: Email / SMS"]

```

 

📊 결과 설명

• 💻 EC2 인스턴스 상태 변경 이벤트 발생
• → 🪢 EventBridge 가 이벤트를 감지 및 전달
• → 📨 SNS 주제로 게시
• → 👨‍💻 운영팀이 Email / SMS로 알림 수신

---

🎯 핵심 개념 정리

• Amazon EventBridge = AWS 이벤트 버스, 리소스 상태 변경 자동 캡처.
• Amazon SNS = 메시지 브로커 서비스, 운영팀 알림 발송.
• 조합하면 "상태 변경 → 자동 알림" 시나리오를 가장 단순하고 효율적으로 구현 가능.

---

👉 Q355의 핵심은 **"EC2 상태 변경 알림은 EventBridge + SNS 조합이 정석"**이라는 점입니다.

---

📘 오답노트 - Q361

❓ 문제 요약

• 환경: ALB 뒤 Amazon EC2 (Auto Scaling 그룹)에서 웹 애플리케이션 실행 중.
• 상황: 의심스러운 트래픽이 단일 공용 IP에서 발생.
• 요구사항: SysOps 관리자는 해당 공용 IP 주소를 차단해야 함.

---

✅ 정답

D. AWS WAF에 설정된 IPSet에 악성 IP 주소를 추가하고, Web ACL을 ALB에 연결하여 차단

• AWS WAF는 웹 애플리케이션 방화벽으로, IP 차단 규칙을 Web ACL에 정의 가능.
• IPSet을 만들어 차단할 IP 주소를 등록.
• Web ACL을 ALB에 연결 → 해당 IP에서 오는 요청 자동 BLOCK.
• 가장 효율적이고 운영 표준에 부합하는 방법.

---

❌ 오답 해설

• A. 보안 그룹 규칙으로 IP 차단
  → 보안 그룹은 L4 수준(인스턴스 레벨) 트래픽 제어 가능.
  하지만 ALB 뒤에 여러 EC2 인스턴스가 Auto Scaling으로 운영되면 개별 인스턴스 제어는 비효율적.
• B. Amazon Detective 사용
  → Detective는 보안 조사 및 포렌식 분석 도구.
  트래픽 차단 기능은 없음.
• C. AWS RAM (Resource Access Manager)
  → 리소스 공유 서비스.
  보안 제어나 IP 차단과는 무관.

---

📊 비교 표

옵션	기능	문제점	적합 여부
A	보안 그룹으로 IP 차단	ALB 앞단에서 처리 불가, 확장성 부족	❌
B	Detective로 위협 분석	분석만 가능, 차단 불가	❌
C	AWS RAM	리소스 공유 서비스	❌
D	WAF Web ACL로 IP 차단	ALB 레벨에서 효율적, 자동 확장 환경 대응	✅ 정답

---

🌐 동작 흐름 (Mermaid)

 

```mermaid
flowchart TD
    Attacker["🚨 악성 IP 트래픽"] --> ALB["⚖️ Application Load Balancer"]
    ALB --> WAF["🛡️ AWS WAF: Web ACL"]

    WAF -->|"⛔ 차단 규칙 적용"| Blocked["❌ 요청 거부"]
    WAF -->|"✅ 정상 요청"| EC2["💻 Amazon EC2 Auto Scaling 그룹"]
```

 

📊 결과 설명

• 🚨 악성 IP 트래픽 → ⚖️ ALB → 🛡️ WAF
• WAF에서
  • ⛔ 차단 규칙이 적용되면 → ❌ 요청 거부
  • ✅ 정상 요청이면 → 💻 EC2 Auto Scaling 그룹 으로 전달

---

🎯 핵심 개념 정리

• 보안 그룹: 인스턴스 레벨 제어 (IP 기반 차단은 가능하나 ALB 레벨에서는 비효율).
• NACL: 서브넷 레벨 제어, 범위가 넓음 → 세밀한 ALB 트래픽 제어에는 불리.
• AWS WAF: ALB, API Gateway, CloudFront 앞단에서 애플리케이션 계층 보안 담당.
• 따라서 "공용 IP 차단"은 WAF + Web ACL이 정답.

---

👉 Q361 핵심은 “IP 기반 차단은 WAF의 Web ACL을 ALB에 연결하는 것이 최적” 이라는 점이에요.

---

📘 오답노트 - Q363

❓ 문제 요약

• 회사는 두 개의 애플리케이션을 연결해야 함.
  • 온프레미스: host1.onprem.private
  • AWS: host1.awscloud.private (EC2 인스턴스에서 실행)
• 온프레미스 ↔ AWS 연결: Site-to-Site VPN.
• 문제: 온프레미스 앱이 EC2 앱에 연결 시 DNS 확인 실패 발생.
• 요구사항: 온프레미스와 AWS 리소스 간 DNS 확인 가능해야 함.

---

✅ 정답

B. Amazon Route 53 인바운드 확인자 엔드포인트를 설정하고, 온프레미스 DNS 확인자와 연결

• Route 53 Resolver 인바운드 엔드포인트: 온프레미스에서 들어오는 DNS 쿼리를 VPC로 전달.
• 온프레미스 DNS 서버가 AWS 내 **사설 호스트 존(private hosted zone)**을 조회할 수 있음.
• 이렇게 하면 awscloud.private DNS를 온프레미스 애플리케이션이 정상적으로 확인 가능.

---

❌ 오답 해설

• A. Route 53 인바운드 확인자 + VPC 연결
  → "onprem.private" 도메인은 온프레미스 DNS에서 관리되므로, 인바운드 엔드포인트만으로는 해결 안 됨.
• C. Route 53 아웃바운드 확인자
  → 아웃바운드 엔드포인트는 AWS → 온프레미스 DNS 쿼리 전달 용도.
  문제는 반대(온프레미스 → AWS)라서 부적절.
• D. Route 53 아웃바운드 확인자 + 온프레미스 DNS 확인자
  → AWS에서 온프레미스 DNS로 쿼리 전달할 때 사용.
  여기서는 온프레미스가 AWS 도메인을 확인해야 하므로 맞지 않음.

---

📊 비교 표

옵션	설명	적합 여부
A	인바운드 확인자 설정, 그러나 온프레미스 도메인 문제는 해결 불가	❌
B	인바운드 확인자 설정 → 온프레미스 DNS가 AWS VPC 도메인 확인 가능	✅ 정답
C	아웃바운드 확인자 → AWS에서 온프레미스로 쿼리 전달	❌
D	아웃바운드 확인자 + 온프레미스 DNS 연동, 방향성 반대	❌

---

🌐 동작 흐름 (Mermaid)

 

```mermaid
flowchart TD
    OnPremApp["🏢 온프레미스 앱"] --> OnPremDNS["🖥️ 온프레미스 DNS"]
    OnPremDNS --> Inbound["🔗 Route 53 인바운드 엔드포인트"]
    Inbound --> VPCDNS["📦 VPC DNS: awscloud.private"]
    VPCDNS --> EC2["💻 Amazon EC2 애플리케이션"]
```

 

📊 결과 설명

• 🏢 온프레미스 앱 → 🖥️ 온프레미스 DNS 쿼리 발생
• 🔗 Route 53 인바운드 엔드포인트가 VPC 내부로 전달
• 📦 VPC DNS (awscloud.private) 에서 이름 해석 수행
• 결과적으로 💻 EC2 애플리케이션에 연결됨

---

🎯 핵심 개념 정리

• Route 53 Resolver 인바운드 엔드포인트: 온프레미스 → AWS DNS 요청 처리.
• Route 53 Resolver 아웃바운드 엔드포인트: AWS → 온프레미스 DNS 요청 처리.
• 문제 상황은 온프레미스 → AWS 방향 DNS 조회 실패 → 따라서 인바운드 엔드포인트 필요.

---

👉 Q363 핵심은 “온프레미스에서 AWS 사설 도메인을 확인해야 할 때는 Route 53 인바운드 엔드포인트” 라는 점이에요.

---

📘 오답노트 - Q381

❓ 문제 요약

• 모든 EC2 인스턴스에 사용자 지정 애플리케이션을 설치해야 함.
• 애플리케이션은 크기가 작고, 자주 업데이트, 자동 설치가 필요.
• 질문: 새로운 EC2 인스턴스에 어떻게 애플리케이션을 배포할 수 있는가?

---

✅ 정답

A. EC2 사용자 데이터(User Data) 스크립트를 사용

• EC2 인스턴스 시작 시 User Data에 스크립트를 지정하면,
  → 인스턴스 부팅 시 자동으로 실행됨.
• 여기서 설치 스크립트를 작성해두면 애플리케이션 자동 다운로드 & 설치 가능.
• 경량 애플리케이션, 자주 업데이트되는 경우 최적.

---

❌ 오답 해설

• B. API Gateway + CloudFormation
  → API Gateway는 API 호출용 서비스, 앱 배포와 직접적 관계 없음.
• C. AMI에 주입
  → AMI(Custom Image) 방식은 애플리케이션 변경이 적고 업데이트가 드문 경우 적합.
  → 문제에서 요구한 "자주 업데이트"와 맞지 않음.
• D. CodePipeline
  → CI/CD 배포 자동화는 가능하지만, 작고 단순한 앱 배포에 비해 오버엔지니어링.
  → 유지보수 비용이 불필요하게 커짐.

---

📊 비교 요약

옵션	설명	적합 여부
A	EC2 User Data 스크립트로 앱 자동 다운로드 & 설치	✅ 정답
B	API Gateway + CloudFormation, 불필요하게 복잡	❌
C	AMI에 앱 포함 (자주 업데이트 어려움)	❌
D	CodePipeline (대규모/복잡 배포에 적합)	❌

---

🌐 동작 흐름 (Mermaid)

 

```mermaid
flowchart TD
    Launch["🚀 EC2 인스턴스 시작"] --> UserData["📜 User Data 스크립트 실행"]
    UserData --> Install["⬇️ 애플리케이션 다운로드 및 설치"]
    Install --> Ready["✅ 애플리케이션 준비 완료 🎉"]
```

 

📊 결과 설명

• 🚀 EC2 인스턴스 시작 → 부팅 시
• 📜 User Data 스크립트 실행 → 초기화 과정
• ⬇️ 애플리케이션 다운로드 및 설치 → 자동 설치 수행
• 마지막에 ✅ 애플리케이션 준비 완료 🎉 → 서비스 시작 가능 상태

---

🎯 핵심 정리

• User Data = EC2 초기 부팅 시 실행되는 스크립트.
• 반복적이고 작은 규모의 애플리케이션 설치/업데이트에 적합.
• 반면, AMI는 업데이트 적고 안정적인 앱에 적합, CodePipeline은 대규모 CI/CD 환경에서 적합.

---

👉 제가 보기엔 Q381은 Q327 (Lambda + NAT 게이트웨이), Q356 (고정 IP + Route 53) 같은 문제랑 묶어서
"최소 노력 & 단순 자동화 방식" 주제로 한 번에 정리해두면 외우기 쉽습니다.