API Gateway vs Ingress: Which Edge Layer Do You Need?
An ingress routes HTTP traffic into a cluster, while an API gateway manages API consumers. Compare their scope, ownership, and failure modes before choosing.
Definition
An ingress is a cluster-level HTTP router that maps host and path rules to internal services and terminates TLS. An API gateway is a product-facing edge that authenticates callers, enforces quotas, versions contracts, and observes API usage. They overlap at routing but differ in scope, owning team, and lifecycle.
Context and scope
Teams often run both, with the ingress treated as infrastructure and the gateway as an application platform component. Confusing the two leads to policy gaps or duplicated edge logic.
Common misconceptions
- An ingress can replace an API gateway — ingress controllers rarely handle consumer identity, quotas, or API contracts
- A gateway makes an ingress unnecessary — gateways still need a stable way to reach cluster services
- Both are just reverse proxies — the difference is the policy surface each one owns
Anti-patterns
- Terminating authentication at the ingress and trusting any internal caller
- Duplicating rate limits in both layers with different thresholds
- Letting application teams hand-edit shared ingress rules without review
Related concepts
Related examples
Authoritative source
https://kubernetes.io/docs/concepts/services-networking/ingress/
Two layers, two jobs
An ingress answers one question: which internal service should receive this HTTP request? It matches host and path rules, terminates TLS, and forwards traffic. It knows nothing about who the caller is, what plan they bought, or how many calls their contract allows.
An API gateway answers a different question: may this consumer call this API, at what rate, and under which contract? It authenticates, applies quotas, translates between public and internal schemas, and emits per-consumer analytics. For example, a mobile client may call /v1/orders while three internal services sit behind that route.
Where they overlap
Both terminate TLS, route by path, and may retry. That overlap tempts teams to collapse them into one component, and small platforms often should. The risk appears when the ingress starts carrying business policy: consumer tiers, API keys, and per-tenant quotas become cluster configuration owned by a platform team that does not know the product.
Ownership is the real boundary
An ingress is infrastructure, versioned with the cluster and owned by the platform or network team. A gateway sits closer to the product: its routes, plans, and contracts change when the API changes, usually weekly. Even when one team owns both, keep the responsibilities separate, because their change cadence and blast radius differ.
Choosing
Use an ingress when you need HTTP routing into a cluster and TLS termination, nothing more. Add an API gateway when external consumers need identity, quotas, contract versioning, or usage analytics. Compared to running only a gateway, the split keeps cluster networking boring while product policy evolves quickly. Most mature platforms run both, with the gateway in front and the ingress behind it.