[AWS Load Balancer] Service vs Ingress 차이점!!

 

핵심 요약

• Service (type=LoadBalancer): Kubernetes 서비스 하나당 AWS 로드밸런서(주로 L4/NLB 또는 설정에 따라 L4/L7)를 직접 생성하여 특정 Pod 집합으로 트래픽을 전달 — 단순·직관적이지만 서비스당 LB가 생겨 비용·관리 부담이 커짐.

• Ingress (ALB via AWS Load Balancer Controller): 클러스터 외부 진입을 하나의 ALB(혹은 소수의 ALB)로 통합해 도메인/경로 기반 L7 라우팅, TLS 종료, WAF, 인증 등 고급 HTTP 기능을 제공 — 여러 서비스 통합 관리에 유리.

---

1) 로드밸런서 타입과 계층 (L4 vs L7)

• Service(type=LoadBalancer)

  • 보통 L4 (TCP/UDP) 중심: NLB 또는 때로는 Classic/Network LB.

  • 예외적으로 NLB에 TLS 리스너(종단 TLS) 구성 가능 → TLS 종료 또는 통과 설정 가능(환경에 따라).

  • 주로 포트 단위로 단순 포워딩(포트 → targetPort).

• Ingress (ALB)

  • L7 (HTTP/HTTPS) 전용: 호스트/경로 기반 라우팅, 리다이렉션, HTTP 헤더 제어, 가중치 기반 라우팅 등.

  • TLS 종료(ACM 연동)로 인증서 관리가 쉬움. WAF/Shield 연동 편리.

---

2) 트래픽 흐름 (실무에서 보는 차이)

• Service LoadBalancer

  • AWS LB → (노드 또는 Pod) → kube-proxy → Pod (또는 직접 Pod IP, targetType=ip 설정 시)

  • 외부 IP 또는 DNS가 서비스마다 생성됨.

• Ingress (ALB)

  • 사용자 → ALB → Listener 규칙(호스트/경로) → 대상 그룹(Target Group) → Service → Pod

  • ALB 하나로 여러 서비스와 경로를 처리.

---

3) 대상(Target) 타입: Instance vs IP vs NodePort

• Service LoadBalancer

  • 기본: LB가 인스턴스(노드) 대상으로 라우팅하고 노드에서 kube-proxy가 Pod로 분발(ClusterIP/NodePort 방식).

  • 또는 annotation으로 target-type=ip를 사용해 LB가 직접 Pod IP로 라우팅(더 낮은 네트워크 홉).

  • externalTrafficPolicy: Local 설정은 원본 클라이언트 IP 보존(하지만 트래픽 분산에 영향).

• ALB via Controller

  • ALB의 Target Group은 IP (pod IP) 또는 instance 중 선택 가능. AWS Load Balancer Controller는 보통 IP 모드로 Pod로 직접 라우팅하는 경우가 많음(더 효율적).

---

4) TLS / HTTPS 처리

• Service (NLB)

  • NLB는 TCP/UDP 기본이지만 TLS 리스너(TLS termination)도 지원. 그러나 HTTPS 레벨의 호스트/경로 라우팅은 불가.

  • TLS를 종단에서 처리하려면 LB에서 인증서(ACM) 설정하거나, Pod 내에서 TLS 처리(종단 통과)할 수 있음.

• Ingress (ALB)

  • ALB에서 **TLS 종료(ACM 연동)**이 쉬움 → 여러 도메인/서브도메인에 대해 한 곳에서 인증서 관리 가능.

  • HTTP→HTTPS 리다이렉션, SNI(도메인별 인증서) 등 지원.

---

5) HTTP 고급 기능(필요시)

• ALB/Ingress: 경로/호스트 기반 라우팅, 가중치 라우팅(A/B), 리다이렉션, 고급 헤더 조작, 리스너 규칙, WebSocket 지원, HTTP/2(종단) 등.

• Service LoadBalancer: 기본 L4 포워딩만(HTTP 고급 기능 제한).

---

6) 스케일링·성능·지연

• NLB (Service)

  • 고성능·저지연, 초당 연결량(throughput) 높음, 정적 IP(Elastic IP) 할당 가능.

  • 유용: TCP 기반 서비스(데이터베이스 프록시, gRPC over TCP, 게임 서버 등).

• ALB (Ingress)

  • HTTP 최적화, L7 처리 오버헤드 있지만 HTTP 기능 최적화로 실무 웹 트래픽에 적합.

  • 복잡한 라우팅 규칙이 많은 경우 관리·운영 이점 큼.

---

7) 비용과 리소스 관점

• Service LoadBalancer

  • 서비스마다 LB가 생성 → 서비스가 많아지면 LB 수 증가 → 비용 증가.

  • 간단한 서비스라면 관리·설정이 빨라 초기엔 편리.

• Ingress (ALB)

  • ALB 하나(또는 소수)로 다수 서비스 처리 → LB 수 감소, 운영비용 절감(특히 많은 서비스의 경우).

  • 단, ALB는 LCU 기반 과금(요청 수·규칙·동시 연결 등) — 요금 구조는 확인 필요.

(요금은 자주 바뀌므로 실제 도입 전 최신 AWS 문서/콘솔에서 확인 권장)

---

8) 보안(회선/ACL/SG/WAF)과 관제

• Service LoadBalancer

  • NLB는 보통 Security Group 처리 방식이 다르므로 설정 유의. NLB → 노드 간 보안그룹 연동 고려 필요.

  • WAF 연동은 ALB와 비교해 번거로움.

• Ingress (ALB)

  • ALB는 AWS WAF, AWS Shield 등과 직접 연동이 쉬움 → 웹 애플리케이션 보호에 유리.

  • ALB 앞단에서 IAM·인증/인가 연계(예: Cognito) 등도 쉬움.

---

9) 실전 설정(예시 YAML) — 빠르게 참고용

• Service (LoadBalancer, NLB, Pod IP target mode)

apiVersion: v1
kind: Service
metadata:
  name: my-tcp-service
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
    service.beta.kubernetes.io/aws-load-balancer-target-type: "ip"   # Pod IP로 직접 라우팅
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports:
    - port: 443
      targetPort: 8443

• Ingress (ALB via AWS Load Balancer Controller)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP":80},{"HTTPS":443}]'
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:...
spec:
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-svc
                port:
                  number: 80
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-svc
                port:
                  number: 80

---

10) 운영·디버깅 차이점 (팁)

• Service LoadBalancer

  • kubectl get svc로 External IP 확인.

  • AWS 콘솔에서 LB → target group → instances/pods 확인.

  • 클라이언트 IP 보존 문제 발생하면 externalTrafficPolicy: Local 확인.

• Ingress (ALB)

  • kubectl describe ingress로 ALB 생성 상태와 이벤트 확인.

  • AWS 콘솔의 ALB Listener/Target Group 규칙이 Ingress 규칙과 매핑되는지 검증.

  • 인증서/Listener 에러는 ALB 이벤트/CloudWatch 로그 확인.

---

11) 언제 무엇을 선택할까? (결정 가이드)

• Service (LoadBalancer) 추천 상황

  • TCP/비-HTTP 트래픽(데이터베이스 프록시, gRPC over TCP, 게임 등) 처리 필요할 때.

  • 극히 단순한 외부 노출 서비스가 소수일 때(단기간 테스트/POC).

  • 초저지연, 고연결성(네트워크 성능)이 최우선일 때 → NLB 유리.

• Ingress (ALB) 추천 상황

  • 웹/HTTP 기반 서비스가 다수이고 도메인/경로 기반 라우팅이 필요한 경우.

  • TLS/ACM, WAF, 인증, 리다이렉트 등 L7 기능을 중앙에서 관리하고 싶을 때.

  • 서비스 수가 많아 LB 갯수 관리를 줄이고 비용·운영 효율을 기대할 때.

• 혼합 운영

  • 보통 실무에서는 ALB(Ingress) 를 웹 트래픽에, NLB(Service) 를 TCP 기반(또는 높은 성능 요구) 서비스에 사용하는 혼합 전략을 택함.

---

12) 체크리스트 (도입 전 점검)

1. 서비스 트래픽 종류: HTTP/HTTPS인가? TCP인가?

2. TLS 인증서 어디서 관리할지(ACM 사용 권장).

3. Pod → LB의 targetType: ip로 직접 라우팅 할지 instance로 할지.

4. 클라이언트 IP 보존 필요성(예: 로그, 인증) → externalTrafficPolicy.

5. 보안: ALB+WAF 연동 필요성, Security Group 설계.

6. 비용 모델 예상: 서비스 수, 요청량, LCU/처리량 차이.

7. 모니터링·로그(CloudWatch, ALB 로그)와 알림 설계.

8. IAM 권한: AWS Load Balancer Controller 설치 시 필요한 권한 확인.