AWS 네트워크를 OSI 계층으로 읽는 법: ALB·NLB·WAF·VPC의 역할

AWS 네트워크 서비스를 OSI 7계층에 하나씩 끼워 맞추면 처음에는 이해하기 쉽다. 그러나 실제 장애를 분석할 때는 이 대응표를 정답처럼 쓰면 안 된다. 하나의 관리형 서비스가 여러 계층의 정보를 이용할 수 있고, 콘솔에 보이는 구성 요소 수와 패킷이 지나간 홉 수도 같지 않기 때문이다.

실무에서는 그 서비스가 어떤 정보를 보고 어떤 결정을 내리는가를 먼저 확인하는 편이 정확하다.

먼저 답부터 정리하면

확인하려는 것	주로 보는 계층	AWS에서 살펴볼 대상
HTTP 호스트·경로·헤더에 따른 라우팅	애플리케이션 계층	ALB, AWS WAF, API Gateway
TCP·UDP 연결을 어느 대상으로 보낼지	전송 계층	NLB의 리스너와 대상 그룹
목적지 IP가 어느 경로로 갈지	네트워크 계층	VPC 라우팅 테이블, Internet Gateway, NAT Gateway
워크로드에 어떤 IP와 보안 정책이 붙는지	네트워크 인터페이스 관점	ENI, 보안 그룹
노드 안에서 Service 트래픽을 Pod로 전달하는지	Linux·Kubernetes 데이터 경로	kube-proxy, iptables 또는 IPVS, CNI

이 표는 사고를 돕는 지도다. 예를 들어 ALB는 HTTP 요청을 이해하지만, 그 아래에서는 TCP 연결과 IP 통신도 함께 사용한다. TLS도 ‘6계층 서비스’ 하나로 고정하기보다 어디서 종료되는지를 확인해야 한다.

ALB·NLB·WAF는 무엇을 보고 판단할까

ALB

Application Load Balancer는 HTTP와 HTTPS 요청을 대상으로 호스트, 경로, 헤더, 메서드 같은 애플리케이션 정보를 이용해 라우팅할 수 있다. “L7 로드밸런서”라는 표현은 이 판단 기준을 가리킨다.

NLB

Network Load Balancer는 TCP·UDP·TLS 등 연결과 흐름을 대상으로 동작한다. 단순히 ‘포트만 보고’ 대상을 고르는 것은 아니다. TCP 연결은 프로토콜, 출발지·목적지 IP와 포트, TCP 시퀀스 번호를 포함한 흐름 해시를 사용하며 한 연결은 수명 동안 같은 대상으로 전달된다.

AWS WAF

AWS WAF는 연결된 리소스로 들어오는 웹 요청의 조건을 검사한다. ALB나 CloudFront 같은 리소스 앞에 독립된 네트워크 홉 하나가 더 생긴다고 단정하기보다, 연결한 리소스에서 HTTP 요청을 평가하는 정책 계층으로 이해하는 편이 안전하다.

EKS에서는 대상 유형에 따라 경로가 달라진다

NLB에서 EKS Pod까지 가는 길을 하나의 고정된 화살표로 그릴 수 없는 가장 큰 이유는 대상 유형이다.

instance 대상 유형

클라이언트
  → NLB 리스너
  → 워커 노드의 NodePort
  → kube-proxy가 구성한 Service 경로
  → Pod

로드밸런서는 워커 노드와 NodePort를 대상으로 등록한다. 노드가 트래픽을 처리한 뒤 Pod로 전달하므로, 선택 결과에 따라 다른 노드의 Pod로 한 번 더 이동할 수 있다.

ip 대상 유형

클라이언트
  → NLB 리스너
  → 대상으로 등록된 Pod IP

IP 대상 유형에서는 로드밸런서가 Pod IP로 직접 전달한다. instance 유형의 NodePort와 Service 전달 단계를 우회하므로 경로와 문제 지점도 달라진다.

‘몇 홉인가’보다 구성을 먼저 확인해야 한다

콘솔에서 Internet Gateway → NLB → Node → Pod처럼 네 개의 상자를 세었다고 해서 traceroute에 네 홉이 나타나는 것은 아니다. 관리형 로드밸런서의 내부 노드, VPC의 논리적 라우팅 구성 요소, Linux 노드에서의 전달은 서로 다른 관찰 수준에 있다.

따라서 홉 수를 고정해서 외우기보다 다음 순서로 범위를 좁힌다.

1. 로드밸런서가 인터넷용인지 내부용인지 확인한다.
2. 리스너 프로토콜과 TLS 종료 위치를 확인한다.
3. 대상 그룹 유형이 instance, ip, alb 중 무엇인지 확인한다.
4. EKS라면 Service와 AWS Load Balancer Controller 설정을 확인한다.
5. 보안 그룹·네트워크 ACL·라우팅 테이블을 경로별로 확인한다.
6. 노드를 지나는 구성에서만 kube-proxy 규칙과 conntrack 상태를 함께 본다.

NAT와 conntrack을 AWS 관리형 서비스 내부 구조로 단정하지 않기

SNAT은 출발지 주소를, DNAT은 목적지 주소를 바꾸는 동작이다. Linux의 netfilter 경로에서는 conntrack이 연결 상태와 NAT 변환을 추적할 수 있다. 다만 이 설명을 그대로 가져와 “NLB 내부에서도 Linux iptables와 conntrack이 이렇게 동작한다”고 말할 근거는 없다.

관찰 가능한 범위에서 판단해야 한다.

• 노드를 통과한다면 해당 노드의 iptables·IPVS·conntrack을 조사한다.
• IP 대상으로 바로 보낸다면 NodePort 경로를 전제로 하지 않는다.
• 클라이언트 IP 보존 여부는 대상 유형, 프로토콜과 대상 그룹 속성을 확인한다.
• 주소가 바뀌어 보인다면 캡처 위치를 함께 기록한다.

장애 분석에 쓸 한 문장

AWS 서비스를 OSI 계층에 대응시키는 것은 출발점일 뿐이다. 실제 경로는 리스너 프로토콜, 대상 유형, 주소 보존 설정, Kubernetes 데이터 경로를 확인한 뒤 그려야 한다. 그래야 ‘고정 홉 수’, ‘항상 두 번 NAT’, ‘NLB 내부 conntrack’ 같은 과도한 단정을 피할 수 있다.

참고한 공식 문서

• AWS: Network Load Balancer 개요
• AWS EKS 모범 사례: Load Balancing
• AWS: VPC 라우팅 테이블
• AWS WAF 작동 방식