Ingress, Istio Service Mesh and API Gateway Explained: What Each Does and When to Use It

Why These Get Confused

All three of these route HTTP traffic, can terminate TLS, can do retries and can enforce some kind of policy. Vendors keep adding features that overlap with the others. So teams end up asking "do we need Istio or an API gateway?" when they're really solving different problems.

The simplest way to keep them straight is to ask which traffic each one is responsible for:

• API Gateway: traffic from external clients to your APIs, treated as a product.
• Ingress: traffic from outside the cluster into services inside a Kubernetes cluster.
• Service mesh (Istio): traffic between services inside your platform ("east-west").

             Internet / partners / mobile apps
                          │
                 ┌────────▼────────┐
                 │   API Gateway   │  auth, keys, rate limits, usage plans,
                 └────────┬────────┘  versioning, developer portal
                          │
                 ┌────────▼────────┐
                 │ Ingress/Gateway │  L7 routing into the cluster, TLS
                 └────────┬────────┘
                          │
        ┌─────────────────┼─────────────────┐
   ┌────▼────┐       ┌────▼────┐       ┌────▼────┐
   │ orders  │◄─────►│payments │◄─────►│ catalog │   service mesh:
   └─────────┘       └─────────┘       └─────────┘   mTLS, retries, traffic
                                                     shifting, telemetry

Kubernetes Ingress

What it is

An Ingress is a Kubernetes resource that describes how HTTP(S) traffic from outside the cluster reaches Services inside it: which hostnames and paths go to which service, and which TLS certificate to use. On its own it does nothing; an Ingress controller (NGINX, Traefik, HAProxy, the AWS Load Balancer Controller, Contour and others) watches those resources and configures a real proxy or load balancer.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop
spec:
  ingressClassName: traefik
  tls:
    - hosts: [shop.example.com]
      secretName: shop-tls
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend: { service: { name: api, port: { number: 80 } } }
          - path: /
            pathType: Prefix
            backend: { service: { name: web, port: { number: 80 } } }

The Gateway API

The Ingress resource is deliberately minimal, which led to a mess of controller-specific annotations. The Kubernetes Gateway API is its successor: GatewayClass, Gateway and HTTPRoute resources with proper support for header-based routing, traffic splitting, cross-namespace delegation and role separation between platform and application teams. Most controllers, and Istio itself, now support it. For new clusters, I'd start with the Gateway API.

When to use it

Any time you run HTTP workloads on Kubernetes and need them reachable from outside the cluster. It's table stakes, not an architectural decision.

Service Mesh (Istio)

What it is

A service mesh puts a proxy in the path of every service-to-service call, and a control plane configures all of those proxies centrally. Istio historically used Envoy sidecars in every pod; its newer ambient mode uses a per-node proxy for L4 (mTLS) and optional "waypoint" proxies for L7 features, which removes most of the sidecar overhead.

What it gives you

• Mutual TLS everywhere, automatically. Every service gets an identity and all traffic between services is encrypted and authenticated without application changes. This is often the reason regulated organisations adopt a mesh.
• Authorisation policies between services. "Only orders may call payments on POST /charges."
• Traffic management. Retries, timeouts, circuit breaking, canary releases by percentage, header-based routing, fault injection for testing.
• Uniform telemetry. Request metrics, traces and service maps for every call, in every language, without instrumenting each service.

What it costs you

• Operational complexity. Istio is a distributed system in its own right. Upgrades, certificate rotation and debugging "why is this 503 coming from the proxy?" need real expertise.
• Resource overhead and latency (much reduced in ambient mode, but not zero).
• Cognitive load. Engineers now need to understand VirtualService, DestinationRule, AuthorizationPolicy and friends.

When to use it

• You have many services (think dozens, not five) in multiple languages and need consistent security and resilience.
• You have a compliance requirement for encryption in transit and service identity inside the cluster.
• You have a platform team to own it.

If you have a handful of services in one language, a good HTTP client library with sensible timeouts and retries, plus OpenTelemetry, gives you most of the benefit with none of the overhead. Linkerd is also worth a look if you want a mesh that's simpler to operate.

API Gateway

What it is

An API gateway is the front door for your APIs as consumed by external clients: mobile apps, partners, third-party developers, or your own web front end. Examples include Amazon API Gateway, Kong, Apigee, Tyk, Azure API Management and Envoy-based gateways.

What it gives you

• Authentication and authorisation at the edge. JWT validation, OAuth scopes, API keys, Cognito or custom authorisers.
• Rate limiting, quotas and usage plans. Per client, per key, per plan.
• Request/response transformation and versioning. Present a stable public contract while the services behind it evolve.
• Developer experience. Documentation, developer portals, key self-service, monetisation.
• Serverless integration. With Amazon API Gateway, routes can invoke Lambda directly, with no cluster involved at all.

When to use it

• You expose APIs to external consumers (partners, public developers, mobile apps) and need keys, quotas and a stable contract.
• You're serverless and need HTTP in front of Lambda functions.
• You want one place to enforce authentication and rate limits across many backend services.

A pattern I recommend: run a dedicated external API gateway for partner integrations, separate from internal service traffic, so that partner-facing concerns (keys, throttling, contract stability) don't leak into how services talk to each other.

Side-by-Side

How They Fit Together

In a typical mature setup, a request from a partner looks like this:

1. API gateway authenticates the partner's key, applies their rate limit, and forwards to the platform.
2. Ingress / Gateway (often a Gateway API implementation, possibly Istio's own ingress gateway) routes it to the right service in the cluster.
3. Service mesh secures and observes every internal call that service makes to fulfil the request.

The overlap is real: Istio's ingress gateway can act as your ingress, and some API gateways run inside the cluster. That's fine. Pick one tool per job and write down which one owns what.

By Stage

Startup: A managed load balancer plus a simple Gateway API implementation or a maintained Ingress controller (or no Kubernetes at all, just Amazon API Gateway in front of Lambda). No mesh.

Scaleup: Gateway API for ingress, an API gateway for partner and public APIs, OpenTelemetry for tracing. Consider a mesh only when a compliance requirement or the number of services forces the question.

Enterprise: API gateway for all external APIs with a developer portal and governance; Gateway API for cluster ingress; a service mesh (Istio ambient or Linkerd) owned by a platform team for zero-trust networking between services.

The Takeaway

Ingress gets traffic into your cluster. A service mesh governs traffic between your services. An API gateway manages your APIs as a product for the people consuming them. Start with the first, add the third when you have external consumers, and adopt the second only when you have the scale, compliance need and team to justify it.