📌 AWS 인프라 구성: ELB + NAT + EKS 흐름 정리
🏗️ 구성 가정
- VPC 내부에 퍼블릭 서브넷에는 ELB, NAT Gateway가 존재
- 프라이빗 서브넷에는 EKS 클러스터(노드 및 파드) 존재
- 모든 외부 트래픽은 ELB를 통해 유입됨
1️⃣ 웹 브라우저에서 http://www.example.com 입력 시 흐름
1. DNS 질의
- 브라우저는
www.example.com에 대해 DNS 질의를 수행 - CNAME 또는 A 레코드를 통해 ELB의 퍼블릭 IP/DNS 이름을 얻음
2. HTTP 요청 (포트 80)
- 클라이언트는 ELB로 80번 포트로 요청을 보냄
- ALB의 경우, 리스너에서 HTTPS(443)로 리디렉션(301/302/308) 설정 가능
3. HTTPS 요청 (포트 443)
- 클라이언트는 HTTPS로 재요청
- ALB는 TLS 종료(SSL 인증) 수행 후 내부로 요청 전달
4. Ingress Controller 연동
- ALB는 Ingress Controller를 통해 Kubernetes Ingress 리소스로 트래픽 전달
- Ingress는 HTTP path 또는 호스트명 기준으로 적절한 서비스로 라우팅
5. 서비스 → 파드
- Ingress가 내부 Service (ClusterIP)로 트래픽 전달
- 서비스가 실제 파드(Pod)로 요청을 전달하고, 파드가 index 페이지 또는 API 응답 처리
🔸 AWS에서는 보안 및 관리상의 이유로 NodePort보다 Ingress + ALB 조합을 선호
2️⃣ 서버 간 통신 (Server-to-Server API 요청)
1. 파드에서 외부 API 요청
- 프라이빗 서브넷 내 파드가 외부 주소(예:
https://api.example.com)로 API 요청을 시도
2. NAT Gateway를 통한 아웃바운드
- 프라이빗 서브넷은 직접 인터넷 접근 불가
- 라우팅 테이블을 통해 NAT Gateway로 트래픽 전달
3. NAT Gateway 역할
- 퍼블릭 서브넷에 위치
- 내부 IP를 공인 IP로 변환 (SNAT) 후 인터넷에 요청
- 응답이 돌아오면 원래 요청한 파드에게 전달
🔸 NAT Gateway는 퍼블릭 서브넷에 존재해야 하며, 이를 사용하는 프라이빗 서브넷의 라우팅 테이블에 설정되어 있어야 함
✅ 요약
- HTTP 요청은 HTTPS로 리디렉션, ALB가 TLS 종료 후 Ingress에 전달
- Ingress → Service → Pod의 구조로 트래픽 처리
- 프라이빗 서브넷의 아웃바운드 요청은 NAT Gateway를 통해 인터넷 통신 가능
- 프라이빗 서브넷끼리는 직접 통신 가능 (같은 VPC 내)
.jpg)