정답 · 해설

해설

【핵심 용어】 \n ▸ 프라이빗 VIF — 온프레미스↔AWS 직접 연결\n ▸ S3 Interface 엔드포인트 — VPC 내 프라이빗 S3 접근\n ▸ 로그 전송 — 개인 연결 요구\n\n 【정답 포인트】 \n ▸ 데이터 센터 → S3: Direct Connect 프라이빗 경로\n ▸ 프라이빗 VIF → S3로의 개인 연결\n ▸ Gateway 엔드포인트 (라우트 기반) vs Interface 엔드포인트 (DNS 기반)\n ▸ Interface 엔드포인트가 프라이빗 VIF와 더 호환성 좋음\n\n 【오답 체크】 \n (A) 공개 VIF → 인터넷 경유 (보안 위험)\n (B) Gateway 엔드포인트 + 프라이빗 VIF → 라우팅 미지원\n (D) 공개 VIF → 인터넷 기반 (로그 전송 부적절)\n\n 【시험 포인트】 \n ▸ Direct Connect VIF 타입: 공개 vs 프라이빗\n ▸ S3 엔드포인트: Gateway vs Interface의 선택\n ▸ 개인 연결 아키텍처 설계

해설

【핵심 용어】 ▸ DNSSEC — DNS 포이즈닝 방지 (도메인 시작점) ▸ 공개 인증서 — 브라우저 신뢰 기반 ▸ NAPTR — DNS 서비스 검색 (인증서 무관) 【정답 포인트】 ▸ DNS 포이즈닝 → DNSSEC 사용 (NAPTR 아님) ▸ 브라우저 신뢰 인증 → 공개 CA 인증서 필수 (자체 서명 불가) ▸ DNSSEC + 공개 CA 인증서 = 두 보안 요구사항 동시 충족 【오답 체크】 (A) 자체 서명 인증서 → 브라우저 경고, 신뢰 미지원 (B) NAPTR → DNS 포이즈닝 방지 안 함 (D) NAPTR + 자체 서명 → 둘 다 불적절 【시험 포인트】 ▸ DNSSEC = DNS 보안 (NAPTR 아님) ▸ 브라우저 신뢰 = 공개 CA 인증서 ▸ 보안 요구사항별 AWS 서비스 선택

해설

【핵심 용어】 ▸ Transit Gateway Connect — GRE 터널 기반 VRF 지원 ▸ 겹치는 주소 공간 → VRF 격리로 해결 ▸ MPLS VPN 매핑 → Transit Gateway 라우트 테이블 매핑 【정답 포인트】 ▸ Transit Gateway Connect 사용 → 온프레미스 MPLS VPN별 독립 연결 ▸ GRE 터널 기반 → 라우터와의 직접 매핑 ▸ VRF 격리 → 겹치는 주소 공간 지원 ▸ 라우트 테이블 매핑 → MPLS VPN별 정책 적용 ▸ 확장성 높음 → 운영 오버헤드 최소 【오답 체크】 (A) SD-WAN → 복잡, 추가 어플라이언스 (B) IPsec VPN별 Site-to-Site VPN → 확장성 낮음, 많은 연결 (C) VPC 기반 → VPC마다 구성, 중복 비용 【시험 포인트】 ▸ Transit Gateway Connect의 역할 = MPLS VPN 마이그레이션 ▸ VRF 격리 메커니즘 이해 ▸ 대규모 MPLS 환경의 AWS 마이그레이션 ▸ 겹치는 CIDR 지원 아키텍처

해설

【핵심 용어】 ▸ 리전 간 피어링 — 두 리전 Transit Gateway 연결 ▸ 양쪽 VPC에서 트래픽 시작 필요 【정답 포인트】 ▸ Prod A의 라우트 테이블 → Prod B (10.1.0.0/16) CIDR로의 경로 필요 ▸ 더 넓은 범위 (10.0.0.0/8) 추가 → 사유: 다른 리전의 VPC도 포함 ▸ Transit Gateway를 대상 지정 → 리전 간 피어링 경유 ▸ 양 방향 모두 필요 (Prod A ↔ Prod B) ▸ 정적 라우트 = VPC 라우팅 테이블에 명시적 정의 【오답 체크】 (A) 피어링 IP 범위 수정 → 이미 구성된 것으로 가정, 원인 아님 (B) 라우트 전파 → 피어링 연결이 먼저 라우트 광고 필요 (D) 프로덕션 계정 라우트 테이블 수정 → 이미 정적 라우트 구성됨 【시험 포인트】 ▸ 리전 간 피어링 = 양쪽 VPC에서 명시적 라우트 필요 ▸ 넓은 범위 (10.0.0.0/8) 사용 이유 → 다른 VPC 확장성 ▸ VPC 라우팅 테이블 vs Transit Gateway 라우팅 테이블 구분

해설

【핵심 용어】 ▸ ALB 액세스 로그 — 응답 코드, 지연시간, 클라이언트 IP 포함 ▸ 응용계층 데이터 — VPC 흐름 로그는 미포함 【정답 포인트】 ▸ 서버 응답 코드, 요청 경로, 지연시간 → ALB 액세스 로그에만 있음 ▸ 클라이언트 IP → ALB 로그에 기록 ▸ S3 저장 → 장기 보관 및 비용 효율 ▸ Athena 쿼리 → SQL로 분석 가능 【오답 체크】 (A) VPC 흐름 로그 → L3/L4 정보만 (응답 코드, 경로 미포함) (B) VPC Traffic Mirroring → 모니터링 어플라이언스 비용, 복잡 (C) CloudWatch → 애플리케이션 메트릭 (ALB 액세스 로그 아님) 【시험 포인트】 ▸ ALB 액세스 로그의 포함 정보 ▸ VPC 흐름 로그 vs ALB 액세스 로그 구분 ▸ 응용계층 분석 = ALB 액세스 로그

해설

【핵심 용어】 ▸ 겹치는 IP 공간 — VPC 피어링 불가 ▸ VPC 엔드포인트 서비스 — IP 변환 불필요 【정답 포인트】 ▸ B: 파트너가 NLB 기반 엔드포인트 서비스 제공 → 전용 인터페이스 ▸ C: VPC-A에서 엔드포인트 서비스 소비 → 겹치는 IP 우회 ▸ 엔드포인트 서비스의 이점: IP 주소 충돌 없이 접근 【오답 체크】 (A) VPC 피어링 → 같은 IP 범위 불가능 (D) 보조 CIDR + NAT → 복잡, 기존 환경 변경 (E) VPN → IP 충돌 해결 안 함 【시험 포인트】 ▸ 겹치는 주소 공간의 해결책 = VPC 엔드포인트 서비스 ▸ NLB 기반 엔드포인트 = PrivateLink ▸ 기존 환경 미영향 = VPC 엔드포인트 활용

해설

【핵심 용어】 ▸ MACsec — L2 선 암호화 (대역폭 손실 최소) ▸ VPN — L3 기반 암호화 (오버헤드 증가) 【정답 포인트】 ▸ MACsec은 Direct Connect 포트 수준 암호화 ▸ 대역폭 용량 유지 → VPN보다 효율적 ▸ 새로운 Direct Connect 연결 → MACsec 지원 필수 ▸ 기존 VIF를 새 연결로 연결 → 재구성 미니멀 【오답 체크】 (A) 공개 VIF + VPN → 인터넷 경유, 낮은 성능 (B) 기존 포트에 MACsec → MACsec 미지원 연결은 지원 안 함 (D) 프라이빗 IP VPN → VPN 오버헤드로 대역폭 감소 【시험 포인트】 ▸ MACsec = 라인 레이트 암호화 (Direct Connect에 최적) ▸ 대역폭 보존 → 암호화 오버헤드 없음 ▸ Direct Connect 보안 옵션 이해

해설

【핵심 용어】 ▸ VPC Traffic Mirroring — 네트워크 트래픽을 캡처하여 검사 엔드포인트로 전송하는 기능 ▸ Network Load Balancer — 레이어 4에서 작동하는 로드밸런서 【정답 포인트】 ▸ 트래픽 미러링 대상으로 NLB 사용 가능 → NLB를 직접 선택하지 않고 NLB 뒤의 EC2 인스턴스를 대상으로 함 ▸ UDP 리스너 필요 → VPC Traffic Mirroring은 UDP 포트 4789(VXLAN)를 사용하여 캡슐화된 트래픽 전달 ▸ NLB는 트래픽 미러링의 대상 인터페이스로 작동하려면 UDP 리스너가 필요 【오답 체크】 (A) NLB를 소스로 선택할 수 없음. 미러링은 EC2 인스턴스나 ENI에서 시작 (B) TCP와 UDP 모두 필요 없음. UDP만 필요 (C) TCP 리스너만으로는 부족. 트래픽 미러링은 UDP VXLAN 캡슐화 사용 【시험 포인트】

해설

【핵심 용어】 ▸ Appliance Mode — Transit Gateway의 기능으로, 트래픽이 항상 같은 경로로 돌아오도록 강제하여 대칭 라우팅 보장 ▸ Transit Gateway Peering — 여러 리전의 TGW 간 연결 【정답 포인트】 ▸ 리전 간 통신 실패 원인 → 트래픽이 origin region의 검사 VPC를 통과하지만, 응답이 destination region의 검사 VPC를 통과하려고 시도 → 비대칭 라우팅 발생 ▸ Appliance Mode 활성화 → 검사 VPC의 ENI에서 모든 트래픽이 동일 경로로 반환되도록 강제 → 요청과 응답이 동일한 검사 VPC를 통과하도록 보장 【오답 체크】 (A) OSPF는 라우팅 문제 해결 못함. Transit Gateway Peering이 이미 경로 전파 (B) RAM 공유는 통신 대칭 문제 해결 못함 (C) 설명은 맞지만, 실제 구현은 Appliance Mode를 통함 【시험 포인트】

해설

【핵심 용어】 ▸ VPC Peering — 두 VPC 간의 직접 네트워크 연결, 데이터 전송 비용 없음 ▸ Virtual Private Gateway — VPN 연결용 AWS 끝점 【정답 포인트】 ▸ 비용 분석 필수 → VPC 간 트래픽(50TB/월) 매우 많음 → VPC Peering 사용 시 데이터 전송 비용 약 4배 절감 ▸ VPN을 통한 리전 간 통신 비용이 높음 → 온프레미스 방화벽이 라우터 역할 → VPC Peering으로 직접 연결 권장 ▸ 온프레미스 연결(10TB/월)은 VPN으로 충분 【오답 체크】 (A) Transit Gateway Peering도 비용 발생. VPC Peering보다 비쌈 (B) 온프레미스 방화벽을 라우터로 사용하면 모든 VPC 간 트래픽이 VPN 통과 → 비용 증가 (D) VPG 간 VPN은 불가능. VPC Peering으로 대체 필요 【시험 포인트】

해설

【핵심 용어】 ▸ Route Propagation — VPC의 CIDR 범위를 자동으로 라우팅 테이블에 전파하는 기능 ▸ BGP — 동적 라우팅 프로토콜 ▸ Transit Gateway — 중앙 라우팅 허브 【정답 포인트】 ▸ 동적 라우팅이 이미 구성됨 → BGP가 VPN 연결에서 활성화됨 ▸ Route Propagation 활성화 → Transit Gateway는 자동으로 VPC의 CIDR 범위 변경을 감지하고 라우트 전파 ▸ 향후 유지보수 불필요 → 운영 효율성 최고 【오답 체크】 (B) 수동 업데이트는 매번 필요. 운영 효율성 낮음 (C) (D) EventBridge/CloudWatch 및 Lambda로 자동화하지만, 복잡성 증가. Route Propagation이 더 간단하고 효율적 【시험 포인트】

해설

【핵심 용어】 ▸ MACsec — Media Access Control Security, Direct Connect의 계층 2 암호화 기술 ▸ CKN/CAK — MACsec 인증서 키 쌍 【정답 포인트】 ▸ Direct Connect 자체 암호화 → MACsec 포트를 요청하여 물리적 포트 레벨에서 암호화 활성화 (A) ▸ CKN/CAK 생성 및 관련 → 각 연결에 고유의 키 쌍 할당으로 암호화 설정 (B) ▸ 온프레미스 라우터 구성 → 라우터도 동일한 MACsec 및 CKN/CAK 쌍으로 구성하여 양쪽 암호화 일치 【오답 체크】 (D) (E) (F) IPsec은 Direct Connect의 표준 암호화가 아님. MACsec이 권장됨. IPsec은 VPN용이고, Direct Connect는 MACsec으로 암호화 【시험 포인트】

해설

【핵심 용어】 ▸ NLB Target — IP 또는 인스턴스 ID로 등록 가능 ▸ VPC Peering — 다른 VPC의 인스턴스를 대상으로 사용 시 IP 기반 등록 필요 ▸ Network ACL — 서브넷 수준의 상태 비저장 방화벽 【정답 포인트】 ▸ VPC Peering을 통한 등록 → IP 주소 기반 등록 필수 (인스턴스 ID는 같은 VPC 내에서만 작동) (B) ▸ NLB 가용 영역 설정 → 새 애플리케이션이 있는 AZ에 NLB 활성화 필요 (C) ▸ Network ACL 규칙 → 인바운드(응답) 및 아웃바운드(요청) 모두 허용 필요 (F) 【오답 체크】 (A) 인스턴스 ID는 VPC Peering 대상으로 작동 안 함 (D) Zonal Shift는 이 시나리오에 불필요. AZ 활성화가 필요 (E) 아웃바운드만으로는 부족. 인바운드도 필요 【시험 포인트】

해설

【핵심 용어】 ▸ Transit Gateway — 여러 VPC를 중앙으로 연결 ▸ Direct Connect Gateway — 여러 리전의 DX 연결을 중앙화 ▸ Private VIF — 비공개 IP 사용 ▸ Transit VIF — Transit Gateway 연결용 【정답 포인트】 ▸ 중앙 집중식 아키텍처 → Transit Gateway와 DX Gateway 조합으로 15개 VPC를 효율적으로 관리 (A) ▸ 프라이빗 IP CIDR 블록 → Transit Gateway 자체의 프라이빗 IP 주소 공간 필요 (C) ▸ Transit VIF 생성 → DX Gateway와 Transit Gateway 간의 연결 (E) ▸ 프라이빗 IP VPN → 공개 IP 피함 【오답 체크】 (B) 각 VPC마다 VIF를 생성하면 운영 오버헤드 증가 (D) 공개 IP는 요구사항에 위배 (F) 공개 VIF와 공개 IP VPN은 금지됨 【시험 포인트】

해설

【핵심 용어】 ▸ S3 Gateway Endpoint — 라우트 테이블 기반, VPC 내 EC2용, 비용 무료 ▸ S3 Interface Endpoint — ENI 기반, VPC 외부 접근 가능, 비용 발생 【정답 포인트】 ▸ 온프레미스 서버 접근 → VPN을 통해 S3에 접근. Gateway Endpoint는 VPC 내만 지원 → Interface Endpoint 필요 (B) ▸ EC2 인스턴스 접근 → Gateway Endpoint가 비용 효율적이고 성능 우수 (A) ▸ 조합 활용 → Interface Endpoint(온프레미스용) + Gateway Endpoint(EC2용)로 가장 비용 효율적 【오답 체크】 (A) Gateway Endpoint만으로는 온프레미스 서버 불가능. VPN 트래픽은 Gateway Endpoint를 통과하지 않음 (B) Interface Endpoint만 사용하면 비용이 높음 (D) 프록시 서버 플릿은 비용과 복잡성 증가 【시험 포인트】

해설

【핵심 용어】 ▸ Resource Group — 태그 기반으로 AWS 리소스를 그룹화 ▸ Network Firewall Stateful Rule — 지속적인 상태를 유지하는 방화벽 규칙 ▸ Auto Scaling — 동적 인스턴스 생성/제거 【정답 포인트】 ▸ Resource Group ARN 참조 → Network Firewall 규칙이 동적으로 Resource Group의 멤버를 인식 ▸ Auto Scaling 자동 추적 → EC2 인스턴스가 시작/종료될 때 태그에 따라 Resource Group 자동 업데이트 ▸ 최소 관리 노력 → Lambda 함수나 manual update 불필요. 완전 자동화 【오답 체크】 (A) Network ACL은 동적 멤버십 지원 안 함 (B) Prefix List도 수동 업데이트 필요 (C) Lambda 함수는 지속적 관리 필요. 이벤트 기반 실행도 복잡 【시험 포인트】

해설

【핵심 용어】 ▸ Accelerated VPN — Transit Gateway 기반의 성능 최적화 VPN ▸ Global Accelerator — 전역 네트워크 최적화 (하지만 VPN에는 미지원) ▸ Transit Gateway — 중앙 라우팅 허브 【정답 포인트】 ▸ Virtual Private Gateway 제약 → 성능 최적화 부족. Legacy 솔루션 ▸ Accelerated VPN 필요 → Transit Gateway 기반으로 AWS의 글로벌 네트워크 인프라 활용 → 지연 시간 대폭 감소 ▸ 성능 개선 최고 → Accelerated VPN이 목표 달성 【오답 체크】 (A) Global Accelerator는 VPN 최적화 지원 안 함 (C) IPv6으로 변경해도 성능 개선 안 됨 (D) PrivateLink는 VPN 대체 불가능 【시험 포인트】

해설

【핵심 용어】 ▸ Flow Log — 네트워크 트래픽의 메타데이터 기록 ▸ Network ACL — 서브넷 수준의 상태 비저장 방화벽 ▸ Dropped Traffic — Transit Gateway에서 거부된 트래픽 【정답 포인트】 ▸ 트래픽 차단 목표 → VPC를 떠나는 트래픽 차단 ▸ 아웃바운드 규칙 필요 → VPC 내부에서 외부로 나가는 트래픽 차단 ▸ 대상 IP 주소 사용 → 차단하려는 외부 대상의 IP를 식별 필요 【오답 체크】 (B) 인바운드 규칙은 VPC로 들어오는 트래픽 차단 (C) 소스 IP는 VPC 내 발신지. 외부 대상 IP가 아님 (D) 인바운드 규칙으로 아웃바운드 트래픽 차단 불가 【시험 포인트】

해설

【핵심 용어】 ▸ DNS64 — IPv6 클라이언트가 IPv4 주소를 IPv6 형식으로 변환 ▸ NAT64 — VPC 수준의 IPv6-to-IPv4 변환 (커뮤니티 기능 필요) ▸ Egress-only IGW — IPv6 전용 아웃바운드 게이트웨이 【정답 포인트】 ▸ DNS64 활성화 → IPv6 인스턴스가 IPv4 서비스를 IPv6 형식으로 액세스 가능하게 함 ▸ NAT Gateway 라우팅 → Route Table에서 NAT Gateway로 트래픽 전송하여 실제 NAT 처리 ▸ 표준 솔루션 → AWS에서 권장하는 IPv6-to-IPv4 통신 방식 【오답 체크】 (B) NAT64는 VPC 레벨에서 지원 안 함. 기존 NAT Gateway도 IPv6 지원 안 함 (C) DNS64만으로는 부족. NAT 처리 필요. Egress-only IGW는 IPv6 전용 (D) 각 라우트에 NAT64 불가. NAT Gateway도 IPv6 전용 지원 안 함 【시험 포인트】

해설

【핵심 용어】 ▸ Direct Connect — 전용 네트워크 연결, 높은 성능 및 일관된 대역폭 ▸ Site-to-Site VPN — 공개 인터넷 기반 암호화 연결 ▸ BGP — Border Gateway Protocol, 동적 라우팅 ▸ OSPF — Open Shortest Path First, 라우팅 프로토콜 【정답 포인트】 ▸ 운영 오버헤드 최소화 → BGP 동적 라우팅이 자동으로 경로 학습 및 장애 조치 ▸ VPN 충분성 → 800Mbps는 VPN으로 가능 (1Gbps 이상 권장) ▸ 정적 경로의 단점 → VPC CIDR 변경 시 수동 업데이트 필요 ▸ 운영 효율성 → BGP가 자동 경로 관리로 최적 【오답 체크】 (A) (B) Direct Connect는 2Gbps 비용이 높음. VPN으로 충분하고 비용 저렴 (A) 정적 경로는 수동 관리 필요 (B) OSPF도 작동하지만, VPN은 BGP 기본 지원 【시험 포인트】