CloudOpsGuide
kubernetes

Kubernetes Ingress vs LoadBalancer: Which to Choose?

Intermediate
11 minutes
October 2026
CloudOpsGuide Team

Kubernetes Ingress vs LoadBalancer: Which to Choose?

Detailed comparison of Kubernetes Ingress and LoadBalancer services — when to use each, cost implications, and configuration examples.

Table of Contents

The Quick Answer

  • LoadBalancer: One cloud LB per service — simple but expensive at scale
  • Ingress: One LB, many routes — cheaper, smarter routing, TLS in one place

For anything beyond a few services, use Ingress.

How Each Works

LoadBalancer Service

Each type: LoadBalancer service provisions a real cloud load balancer:

Internet → LB1 → service-a
Internet → LB2 → service-b
Internet → LB3 → service-c

On Azure, each LoadBalancer service gets its own public IP + Azure LB rule. On AWS, an NLB/ALB per service (depending on annotations).

Ingress

One ingress controller (nginx, Traefik, Azure AGIC) sits behind one LoadBalancer and routes by hostname/path:

Internet → ONE LB → Ingress Controller → service-a (host: api.example.com)
                                     → service-b (host: app.example.com)
                                     → service-c (host: example.com/blog)

Side-by-Side Comparison

FeatureLoadBalancerIngress
OSI LayerL4 (TCP/UDP)L7 (HTTP/HTTPS)
RoutingIP:port onlyHost + path based
TLS terminationPer-serviceCentralized
Cloud resources1 LB per service1 LB total
URL rewritingNoYes
Rate limiting/WAFNo (cloud LB dependent)Yes (controller features)
Non-HTTP trafficYesNo (mostly)
ComplexityLowMedium

Configuration Examples

LoadBalancer Service

apiVersion: v1
kind: Service
metadata:
  name: my-app-lb
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports:
    - port: 80
      targetPort: 8080
kubectl get svc my-app-lb
# EXTERNAL-IP shows once Azure provisions the LB

Ingress Setup

Step 1: Install the ingress controller (nginx):

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/cloud/deploy.yaml

On AKS, alternatively enable Application Gateway Ingress Controller (AGIC) or use the managed nginx addon:

az aks enable-addons --addons ingress-appgw \
  --resource-group my-rg --name my-cluster \
  --appgw-name my-appgw --appgw-subnet-id <subnet-id>

Step 2: Create the Ingress resource:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  ingressClassName: nginx
  rules:
    - host: example.com
      http:
        paths:
          - path: /api(/|$)(.*)
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 80
          - path: /(/|$)(.*)
            pathType: Prefix
            backend:
              service:
                name: frontend-service
                port:
                  number: 80
    - host: admin.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: admin-service
                port:
                  number: 8080

Step 3: Add TLS with cert-manager:

spec:
  tls:
    - hosts:
        - example.com
        - admin.example.com
      secretName: app-tls

Cost Analysis

Approximate costs (varies by region/provider):

SetupMonthly Cost
10 LoadBalancer services (Azure)~£150+ (10 public IPs + LB rules)
1 Ingress + 10 routes~£18–25 (1 public IP + controller pods)

At 50+ services, LoadBalancer-per-service becomes genuinely expensive and hits cloud provider limits (e.g., LB rules per LB).

When to Use LoadBalancer

  • Single service that needs direct exposure (e.g., a game server, MQTT broker)
  • Non-HTTP protocols — TCP/UDP that ingress can't route
  • Simplest possible setup for a demo or MVP

When to Use Ingress

  • Multiple HTTP(S) services — the common case
  • Path-based routing (/api → api-svc, / → frontend)
  • Hostname routing (api.example.com, admin.example.com)
  • Centralized TLS via cert-manager + Let's Encrypt
  • Rate limiting, auth, rewrites at the edge

Common Pitfalls

Ingress returns 404 for everything

# Check the ingress got an address
kubectl get ingress

# Check controller logs
kubectl logs -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx

# Common cause: missing ingressClassName
spec:
  ingressClassName: nginx   # required in modern Kubernetes

Health probes failing through ingress

The ingress controller health-checks your service's pods. If readiness probes fail, traffic won't route — check Pod Not Ready guide.

SSL redirect loops

# If terminating TLS at a cloud LB in front of ingress:
annotations:
  nginx.ingress.kubernetes.io/ssl-redirect: "false"   # avoid double-redirect loop

Decision Guide

Need non-HTTP (TCP/UDP)?  ──yes──→ LoadBalancer
        │
        no
        ▼
More than 2-3 services?  ──yes──→ Ingress
        │
        no
        ▼
Quick demo/MVP?          ──yes──→ LoadBalancer
        │
        no
        ▼
                      → Ingress (better long-term)

Related Articles


Last Updated: October 2026
Author: CloudOpsGuide Team
Difficulty: Intermediate
Estimated Reading Time: 11 minutes