Kubernetes Ingress
Gateway API
HTTPRoute
API Gateway
Cloud API Gateway
AWS API Gateway
Azure API Management
Service Mesh
Envoy/Istio/Linkerd
NGINX role with service mesh
North-south traffic
East-west traffic

Apakah NGINX Ingress cukup?
Kapan Gateway API lebih tepat daripada Ingress?
Kapan butuh API Gateway?
Kapan service mesh layak digunakan?
Apa beda edge proxy dan sidecar mesh?
Layer mana yang seharusnya menangani auth, rate limit, routing, TLS, observability, dan policy?

1. menggunakan NGINX untuk semua hal sampai menjadi pseudo-API-gateway yang tidak terkendali
2. menambahkan API Gateway/service mesh tanpa kebutuhan jelas dan menambah kompleksitas operasional

Client
DNS
CDN or Front Door
Cloud Load Balancer
API Gateway
NGINX / Ingress Controller
Service Mesh Gateway
Kubernetes Service
Sidecar Proxy
Java/JAX-RS Pod
Database / downstream service

Which layer owns which responsibility?

external client -> platform
partner system -> platform
internet -> Kubernetes
corporate network -> service

DNS
CDN
WAF
cloud load balancer
API Gateway
NGINX Ingress
Gateway API Gateway

quote-service -> catalog-service
order-service -> pricing-service
workflow-service -> notification-service

Kubernetes Service
service mesh sidecar
internal gateway
mTLS
network policy
client library

Do not evaluate NGINX, API Gateway, and service mesh as direct replacements only.
They often solve different traffic directions and policy scopes.

host-based routing
path-based routing
TLS certificate attachment
routing to Kubernetes Service
basic HTTP ingress abstraction

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: quote-api
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - quote.example.company.com
      secretName: quote-api-tls
  rules:
    - host: quote.example.company.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: quote-api
                port:
                  number: 8080

simple HTTP routing
broad ecosystem support
works well for many Kubernetes web/API workloads
native Kubernetes object
controller abstraction

limited expressiveness
annotation-driven extensions
controller-specific behavior
weak cross-namespace delegation model
not ideal for complex multi-team gateway ownership
not a complete API product management layer
not an east-west service policy solution

stable host/path routing
TLS termination
basic proxy behavior
standard timeouts
standard logging
limited per-service override

NGINX-generated server/location/upstream config
annotations for extended behavior
ConfigMap defaults
TLS handling
rewrite behavior
rate limiting options
auth request integration
buffering options
timeout options
canary support depending on controller
metrics/logging integration

Your YAML is Kubernetes Ingress.
Your runtime behavior is NGINX controller-specific.

rewrite annotations
proxy timeout annotations
snippet annotations
backend protocol annotations
canary annotations
CORS annotations
rate limit annotations

If your platform heavily depends on controller-specific annotations, you are not using generic Ingress anymore. You are using an NGINX-specific gateway abstraction.

separate infrastructure ownership from route ownership
make routing resources more expressive
support delegation
support multiple protocols more cleanly
reduce annotation abuse

GatewayClass
Gateway
HTTPRoute
Route delegation
Listener
ParentRef
BackendRef

GatewayClass = type of gateway implementation
Gateway      = actual data-plane entry point/listener managed by platform
HTTPRoute    = app/team-owned routing rules attached to Gateway

Platform team owns Gateway.
Application teams own HTTPRoute within allowed boundaries.

few teams
simple routing
single ingress controller
limited policy variation
platform already standardized around ingress-nginx/NGINX controller

many teams share gateways
platform team needs controlled delegation
routes span namespaces
advanced traffic policy is growing
annotations are becoming unmanageable
multiple protocols/listeners matter

Are we hitting Ingress limitations, or are we just missing governance around existing Ingress usage?

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: quote-route
spec:
  parentRefs:
    - name: shared-public-gateway
  hostnames:
    - quote.example.company.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: quote-api
          port: 8080

The Gateway can be platform-owned.
The HTTPRoute can be application-owned.
The attachment can be controlled.

public hostname
public API path
backend service target
route-level policy
ownership boundary

TLS termination
headers
timeouts
retries
body size
streaming
observability
backend protocol

API product exposure
authentication integration
API key management
OAuth/OIDC integration
rate limiting and quota
consumer management
request/response transformation
versioning
API analytics
developer portal
monetization or subscription model
policy enforcement
WAF integration
schema validation

AWS API Gateway
Azure API Management
Apigee
Kong
MuleSoft
Tyk
NGINX-based API gateway patterns

Reverse proxy routes traffic.
API Gateway governs API consumption.

internal UI
partner systems
B2B clients
batch systems
integration middleware
mobile/web frontend
other internal domains

routing
TLS termination
rate limiting
basic auth
external auth request
header manipulation
request size limits
basic traffic splitting

API lifecycle management
consumer onboarding
API keys/subscriptions
OAuth policy configuration
quota by consumer/app/product
analytics per API consumer
version/deprecation management
developer portal
schema validation
centralized governance UI/API

If the problem is traffic routing, NGINX may be enough.
If the problem is API governance and consumer management, use an API Gateway.

Using dozens of NGINX annotations and snippets to recreate API Gateway behavior without API Gateway governance.

Putting an API Gateway in front of every internal service when simple Ingress routing would be enough.

NGINX should not become the place where complex business authorization rules live.
API Gateway may validate API consumption policy.
Application should still enforce domain authorization.

AWS API Gateway
Azure API Management

managed scaling
managed TLS integration
identity provider integration
API subscriptions
API analytics
quota/rate limit
request validation
transformation
private integration
VPC/VNet integration

APIs are public or partner-facing
consumer onboarding matters
central governance is required
the organization standardizes on cloud-native API management

latency sensitivity is high
local development parity is hard
configuration is split across many systems
cloud-specific lock-in is unacceptable
multi-cloud/on-prem parity is required
complex routing spans Kubernetes and legacy systems

If production spans AWS, Azure, and on-prem, API gateway choice can become a portability and governance decision, not only a traffic decision.

Check whether public/partner APIs go through API Gateway.
Check whether NGINX sits behind or in front of API Gateway.
Check where auth and rate limits are enforced.
Check whether API Gateway forwards original headers correctly.
Check private integration path to Kubernetes.
Check API analytics vs NGINX logs vs app metrics.

Client
-> Azure Front Door
-> Azure API Management
-> Application Gateway or Load Balancer
-> NGINX Ingress Controller
-> AKS Service
-> Java/JAX-RS Pod

subscription keys
OAuth validation
API versioning
quota
policy transformation
consumer analytics

Kubernetes host/path routing
service-level timeout
backend protocol
cluster-local routing
some header normalization

duplicated policy between APIM and NGINX.

APIM rate limit: 100 req/min
NGINX rate limit: 50 req/min
Application rate limit: 200 req/min

Check whether Azure API Management is in path.
Check APIM policies.
Check NGINX annotations for overlapping policy.
Check correlation ID propagation from APIM to NGINX to Java.
Check source IP and forwarded header behavior.
Check private endpoint or VNet integration path.

Client
-> Route 53
-> AWS API Gateway
-> VPC Link / NLB / private integration
-> NGINX Ingress Controller
-> EKS Service
-> Java/JAX-RS Pod

API stages
custom domains
usage plans
API keys
Lambda authorizers or JWT authorizers
request validation
throttling
CloudWatch API metrics

cluster-local routing
path rewrite
backend service selection
timeouts to service
Kubernetes-specific traffic control

API Gateway path mapping and NGINX rewrite can conflict.

API Gateway maps /prod/quote -> /quote
NGINX rewrites /quote -> /
Backend expected /api

404, wrong OpenAPI URL, wrong redirect, or broken auth path.

Check custom domain and base path mapping.
Check VPC Link/NLB integration.
Check API Gateway timeout and throttling.
Check NGINX rewrite annotations.
Check propagated headers and request ID.
Check whether client-visible path equals backend path.

mTLS between services
service identity
traffic policy
retries/timeouts/circuit breaking
load balancing
traffic splitting
observability
policy enforcement
sidecar or ambient data plane

Istio
Linkerd
Consul service mesh
Envoy-based meshes

quote-service -> pricing-service
quote-service -> catalog-service
order-service -> workflow-service

client libraries
application code
Kubernetes Service
network policy
manual TLS
custom retry code

How does external traffic enter the cluster and reach the right service?

How do services talk to each other securely and observably inside the cluster?

Use NGINX Ingress annotations to control deep service-to-service policy.

Use service mesh as external API product gateway without API governance needs being clearly modeled.

service mesh
API gateway
ingress gateway
sidecar proxy
edge proxy

rich traffic policy
mTLS
service identity
telemetry
traffic splitting
policy extensibility

operational complexity
control plane learning curve
resource overhead
harder debugging for app teams

simplicity
mTLS
basic traffic policy
service metrics
lower cognitive load

less extensive policy ecosystem than Istio
less flexible for some advanced traffic management cases

A mesh should be adopted for clear service-to-service requirements, not as a status symbol.

external client -> edge proxy -> internal service

service A -> sidecar A -> sidecar B -> service B

public TLS
public routing
client IP
WAF
internet-facing security
API ingress
external auth
large request handling

service identity
mTLS between workloads
internal retries
timeouts
circuit breaking
internal telemetry
service-to-service policy

A request may fail at edge proxy, ingress proxy, mesh proxy, application, or downstream dependency.

Check whether pods have sidecars.
Check whether ingress traffic enters mesh.
Check whether mTLS is strict/permissive/disabled.
Check whether retries happen at mesh layer.
Check whether NGINX and mesh both enforce timeout.
Check trace propagation through both proxies.

Client -> NGINX Ingress -> Kubernetes Service -> Pod with sidecar -> App

Client -> NGINX -> Mesh Ingress Gateway -> Service mesh -> App

Client -> Cloud LB -> Istio/Envoy Gateway -> Service

Public REST API -> NGINX Ingress -> App
Internal service calls -> Mesh

who owns edge routing
who owns TLS certificates
where WAF lives
where external auth lives
how much policy is needed for ingress traffic
team skills
operational maturity

client
CDN/front door
API Gateway
cloud load balancer
NGINX Ingress
service mesh sidecar
Java HTTP server
Java HTTP client
database driver
message broker client

client SDK
API Gateway
NGINX proxy_next_upstream
service mesh retry policy
Java HTTP client
application logic

Retries enabled at API Gateway, NGINX, service mesh, and Java client.

retry amplification
non-idempotent duplicate operations
thundering herd
masked root cause
higher tail latency

Which layer owns retries, and for which methods/status codes?

POST /orders
POST /quotes/{id}/submit
PATCH /order-lines/{id}

CDN/WAF
API Gateway
NGINX auth_request
service mesh policy
application security filter
JAX-RS resource method/domain logic

API Gateway / edge = authenticate caller and enforce API consumption policy
NGINX Ingress = route and preserve trusted identity context
service mesh = authenticate service identity internally
application = authorize business action

Edge says user is authenticated.
Application assumes user can perform every operation.

Edge validates token.
Application validates permissions for quote/order action.

Check where token validation occurs.
Check where user/tenant identity is derived.
Check where business authorization occurs.
Check whether identity headers are protected from spoofing.
Check whether service-to-service identity differs from end-user identity.

CDN logs
API Gateway analytics
cloud load balancer metrics
NGINX access logs
service mesh telemetry
application logs
OpenTelemetry traces
Kubernetes events

request ID
trace ID
client IP
host
path
method
status
upstream status
upstream latency
response size
caller identity if safe
route/service name
environment

API Gateway reports 504.
NGINX reports 499.
Java service reports success after 90s.
Client reports timeout at 60s.

The request may have continued in backend after client/gateway timeout.

Can one production request be followed across every proxy layer and application logs?

traffic is mostly HTTP/REST
host/path routing is straightforward
TLS termination is simple
API consumers are internal or already governed elsewhere
auth is handled by app or existing gateway
rate limits are simple
few teams share the same gateway
service-to-service traffic does not need mesh-level policy
platform team has strong NGINX operational knowledge

Client -> Cloud LB -> NGINX Ingress -> Java/JAX-RS Service

external API product exposure
partner onboarding
API keys or subscriptions
consumer-specific quota
centralized OAuth/OIDC policy
request/response transformation as product policy
API version lifecycle
API analytics per consumer
schema validation
monetization or commercial API plans
developer portal
central enterprise API governance

Partner Client
-> API Gateway
-> NGINX Ingress
-> Quote/Order Java API

API Gateway owns consumer policy.
NGINX owns Kubernetes ingress routing.
Java service owns business logic and authorization.

API Gateway decides whether the consumer may call the API product.
Application decides whether the authenticated actor may perform the domain action.

many services call each other
mTLS between services is required
service identity is important
internal traffic needs consistent observability
internal retries/timeouts need standardization
traffic splitting between service versions is common
zero-trust internal networking is required
platform can support mesh operational complexity

Client
-> NGINX Ingress
-> quote-service sidecar
-> pricing-service sidecar
-> pricing-service

proxy resource overhead
control plane complexity
debugging complexity
policy learning curve
upgrade coordination
possible latency overhead
application team confusion

Do the east-west traffic requirements justify the operational complexity?

many teams share gateway infrastructure
platform wants explicit route delegation
Ingress annotations are becoming unmanageable
cross-namespace routing needs clearer control
multiple listeners/protocols matter
policy attachment needs structure
future portability is important

Gateway API = Kubernetes resource model for traffic routing
API Gateway = API product/policy management platform

Cloud API Gateway -> Gateway API implementation -> Kubernetes Services

Gateway API replaces classic Ingress inside Kubernetes.
API Gateway remains outside for API management.

No single layer wins everything.
Choose based on ownership, policy scope, traffic direction, and operational maturity.

CDN -> API Gateway -> ALB -> NGINX -> Mesh Gateway -> Sidecar -> App

rate limit at API Gateway
rate limit at NGINX
rate limit in app

custom auth
custom routing
custom headers
custom rate limits
custom transformations

Mesh is deployed, but teams do not understand service ownership, retries, idempotency, or timeouts.

App trusts X-User-ID because NGINX usually sets it.

ApplicationPath
Forwarded header
X-Forwarded-Prefix
OpenAPI server URL
Location response header
redirect behavior

which headers are trusted
which caller identity is end-user
which identity is service identity
where business authorization runs

create quote
submit order
cancel order
change price plan
approve workflow step

request ID
trace ID
public route
internal route
caller identity if safe
upstream/downstream timing

400: client/proxy parsing/app validation?
401: API Gateway, NGINX auth, app auth?
403: WAF, gateway policy, ingress allowlist, app authorization?
404: API Gateway mapping, NGINX route, Kubernetes service, JAX-RS path?
413: CDN, API Gateway, NGINX, app server?
429: API Gateway, NGINX, app limiter?
502: LB, NGINX, mesh gateway, sidecar?
503: no endpoints, upstream unavailable, mesh circuit breaker?
504: API Gateway timeout, LB timeout, NGINX timeout, mesh timeout?

1. identify client-visible status
2. identify which layer emitted it
3. correlate request ID across layers
4. compare proxy logs with app logs
5. check whether backend received request
6. check if failure is routing, auth, TLS, DNS, timeout, body size, or policy

Traffic layers
- What is the full request path from client to Java/JAX-RS pod?
- Which layers exist in AWS, Azure, on-prem, or hybrid environments?
- Are there different paths for public, private, partner, and internal APIs?

Ownership
- Who owns DNS?
- Who owns cloud load balancer?
- Who owns API Gateway?
- Who owns NGINX Ingress?
- Who owns service mesh?
- Who owns app-level auth?

Policy placement
- Where is TLS terminated?
- Where is authentication performed?
- Where is business authorization performed?
- Where is rate limiting performed?
- Where are retries configured?
- Where are timeouts configured?
- Where is CORS handled?

NGINX/Gateway API
- Is classic Ingress still enough?
- Are annotations becoming unmanageable?
- Is Gateway API planned or already used?
- Which controller implements Gateway API?
- Is route delegation needed?

API Gateway
- Are public/partner APIs managed through API Gateway?
- Are API keys, quotas, subscriptions, or developer portal needed?
- Does API Gateway overlap with NGINX policies?

Service Mesh
- Is service mesh installed?
- Are sidecars injected?
- Is mTLS enabled?
- Are retries/timeouts configured in mesh?
- Does ingress traffic enter the mesh?

Observability
- Is request ID propagated across every layer?
- Can one request be traced from gateway to app?
- Are 4xx/5xx attributable to the right layer?
- Are API Gateway, NGINX, mesh, and app dashboards correlated?

Security
- Are identity headers protected?
- Are trust boundaries documented?
- Is internal traffic zero-trust or network-trust based?
- Are public and internal routes separated?

Problem clarity
- What exact problem is being solved?
- Is it routing, API governance, security, observability, or service-to-service policy?

Layer choice
- Why this layer?
- Why not existing NGINX Ingress?
- Why not API Gateway?
- Why not application-level handling?
- Why not service mesh?

Ownership
- Who operates the new layer?
- Who can change routes/policies?
- Who handles incidents?

Failure modes
- What new 4xx/5xx can this layer emit?
- What timeout/retry behavior does it introduce?
- What happens if this layer is down?

Security
- Does it change auth boundary?
- Does it introduce trusted headers?
- Does it terminate TLS?
- Does it expose internal endpoints?

Observability
- Are logs and metrics available?
- Is trace propagation preserved?
- Can status codes be attributed to this layer?

Migration
- Is rollout incremental?
- Is rollback possible?
- Are old and new routes compatible?
- Is client behavior affected?

Use NGINX Ingress when the problem is Kubernetes HTTP ingress routing with manageable policy needs.

Use Gateway API when Ingress ownership, delegation, and expressiveness are becoming limiting factors.

Use API Gateway when the problem is API consumer governance, subscription, quota, analytics, or productized API exposure.

Use service mesh when the problem is service-to-service security, identity, telemetry, and traffic policy at scale.

Do not add a new layer until you know which existing layer cannot solve the problem safely.

Do not duplicate timeout, retry, auth, rate limit, or CORS policies across layers unless the responsibility split is explicit.

NGINX is excellent for reverse proxy and ingress traffic, but it is not automatically a full API management platform.

Kubernetes Ingress is simple and useful, but advanced behavior often becomes annotation-driven and controller-specific.

Gateway API improves routing structure and ownership delegation, but it does not remove the need to understand proxy behavior.

API Gateway is best understood as API product and policy governance, not just traffic forwarding.

Service mesh is primarily about east-west service traffic, identity, mTLS, telemetry, and internal traffic policy.

The hardest enterprise problem is not choosing the most powerful proxy. It is assigning clear responsibility across layers.

For Java/JAX-RS backend systems, traffic architecture directly affects base paths, redirects, auth context, retries, idempotency, observability, and failure semantics.