Most API gateways stop at the perimeter. Sensitive service calls and privileged tokens still move east-west behind them.
The right design combines edge policy with workload identity and authorization. The true risk is trusting internal traffic without checking it.
What an API gateway secures at the edge
An API gateway secures north-south traffic. This is traffic from browsers, mobile apps, partners, or public internet clients.
It can validate JWTs, enforce rate limits, route requests, and create audit records. These checks happen before traffic reaches an application.
It does not automatically control calls between internal workloads.
An API gateway is a policy enforcement point for incoming API traffic, not a complete Zero Trust Architecture.
The request path it controls
A common path is client → DNS or CDN → WAF → gateway. Then traffic goes to a load balancer or Kubernetes ingress, and finally a service.
The gateway centralizes shared authentication, API key management, request limits, and threat protection. Each backend then needs less duplicate edge code.
East-west traffic moves between workloads in cloud networks, Kubernetes clusters, and data centers. It stays inside systems your team may call trusted.
A compromised pod, virtual machine, or service account can abuse that trust. Sensitive calls need workload identity and least-privilege authorization.
Gateway vs proxy, load balancer, and ingress
An API gateway enforces API identity and policy. A reverse proxy routes requests, a load balancer spreads traffic, and ingress exposes Kubernetes services.
| Control | Main job | Identity policy | Best fit | Typical US cost signal |
|---|
| API gateway | API routing and policy | JWT, OAuth 2.0, quotas | Public or partner APIs | Managed request fees often range from $1 to $3.50 per million requests |
| Reverse proxy | TLS and path routing | Usually basic or add-on | Simple web applications | Compute and support time |
| Load balancer | Health-based distribution | Limited by design | High availability | Hourly capacity plus data processing |
| Ingress controller | Kubernetes entry rules | Varies by controller | Cluster service exposure | Cluster compute and operations |
The listed range reflects common published United States cloud pricing patterns. It does not show the complete bill.
Data transfer, WAF inspection, logs, support, and idle capacity may cost more. Model those costs before you choose a provider.
A reverse proxy can fit one internal application with one backend and low traffic. It can also fit teams with no public API consumers.
It falls short when clients need OAuth 2.0 or OIDC. It also falls short with separate quotas, versioned APIs, and shared audit events.
Ingress maps hosts and paths to Kubernetes services. It does not automatically give tenant-aware authorization or per-consumer rate limits.
A load balancer selects a healthy target. Authorization decides whether an identity may take an action.
Traffic flow: Client → CDN/WAF → API gateway checks token and quota → ingress or load balancer selects a healthy target → orders service → mTLS-authenticated call to inventory service → filtered response returns through the edge.
Build zero trust beyond the API edge
A safe design checks user identity at entry. It checks workload identity and permissions again between services.
For POST /orders, the gateway should verify the OAuth 2.0 access token through OIDC. It should check the JWT signature, issuer, audience, expiry, and orders.write scope.
It should also apply tenant and client limits. Then orders-api should use mTLS and service authorization for inventory or payment calls.
The error most teams make is trusting service calls after the first token check.
Check tokens before routing
JWT validation must check the expected issuer and audience. A valid signature alone is not enough.
Authentication proves who called. Authorization decides what that caller may do for a resource or tenant.
Give workloads their own identity
Mutual TLS, or mTLS, makes both sides prove identity with certificates. Think of it as checking badges at both ends of a locked door.
orders-api should get only stock-reservation rights. It should not get broad payment-record access or unrelated namespace access.
Put rate limits in two places
Edge limits protect against abusive clients and public demand. Internal limits contain retry storms, code errors, and noisy services.
Use separate global, route, tenant, burst, and concurrency controls. One limit cannot protect every failure mode.
A full gateway is often unnecessary for one internal application with one backend, low traffic, no public API, and no shared policy needs. A lightweight reverse proxy or native ingress may be sufficient. It is never a substitute for application-level authorization or workload identity.
A provider-neutral route shows how these controls work together. POST /v1/orders can require an OAuth 2.0 access token.
Its JWT check should verify issuer, audience, expiry, and orders.write before routing. The gateway can then send the request to orders-api.
The gateway can limit each client to 60 requests per minute. It can return 429 Too Many Requests with retry information when that limit is exceeded.
Before forwarding, it can remove client-controlled identity headers. It can add a verified tenant ID or request ID.
If orders-api calls inventory and payment services, those calls should use mTLS and workload identity. The gateway can hide internal fields and normalize error messages.
It should return only the order status and identifier.
Choose a gateway that survives failure
Choose a gateway your team can run during traffic spikes, key rotation, failed releases, and regional faults. Feature lists matter less than failure handling.
Managed, open source, and cloud options
Managed gateways from AWS, Google Cloud, Microsoft Azure, Cloudflare, Apigee, or MuleSoft reduce infrastructure work. They can raise platform coupling and traffic-based costs.
Kong, NGINX, Envoy, and Traefik offer portability and deeper control. Your team must handle upgrades, patches, logs, and configuration review.
Test availability before choosing
Test real token checks, route rules, and rate limits. Also test bad signing keys, identity-provider delays, upstream timeouts, and rollback.
Internet-facing APIs should span at least 2 to 3 availability zones. Use health checks, autoscaling, version-controlled configuration, and request IDs at every hop.
The right choice depends on the environment, not a universal checklist. A startup with one public API may favor a managed gateway.
That choice cuts patching, scaling, and certificate work. Request-based charges may still rise as traffic grows.
A Kubernetes microservices platform may prefer Envoy-based tools, Kong, NGINX, or Traefik. These tools support cluster-native routing and policy near workloads.
Multicloud teams should favor portable configuration and identity integration. Public partner APIs need strong API key management, quotas, analytics, and versioning.
Legacy systems can benefit from protocol translation. A gateway can translate REST or JSON requests into SOAP, XML, or private backend protocols.
Gateway selection must include the operating model and protocol features. Managed cloud gateways often fit teams needing integrated IAM and regional availability.
They also fit teams that want less infrastructure maintenance. Still, model request, data-transfer, logging, WAF, and support costs at peak traffic.
Kong can fit organizations that need broad plugin control and deployment portability. NGINX often fits high-performance reverse-proxy and routing work.
Envoy fits platforms already using service mesh or xDS configuration. Traefik can fit teams that value Kubernetes discovery and simpler operations.
Every option adds latency, so measure p50, p95, and p99 with authentication enabled. Use multiple replicas and multi-zone placement to avoid one failure point.
Add health checks, configuration rollback, and a tested identity-provider outage plan. Failure tests reveal gaps that product demos hide.
Questions & answers
What does an API gateway do?
An API gateway routes incoming API requests and can enforce authentication, authorization, rate limits, and logging. It does not secure internal calls unless teams protect those calls deliberately.
What is the difference between an API and an API gateway?
An API exposes application functions, while an API gateway controls client access to one or more APIs. POST /orders is an API operation.
The gateway checks its token and forwards it to the order service.
Is an API gateway the same as a load balancer?
No. A load balancer sends traffic to healthy targets, while a gateway applies API policy.
A health check cannot decide whether a JWT scope permits a refund.
Secure the edge and every service call
Treat the gateway as the front door. Use mTLS, workload identity, and service authorization for the rooms behind it.
- What matters: Use the gateway for incoming API identity, routing, quotas, and audit records.
- What it cannot do alone: Secure east-west calls inside Kubernetes, a VPC, or a legacy network.
- What to test: Measure latency, rejected-token behavior, rate-limit accuracy, multi-zone failover, and rollback.
- What to buy: Choose managed or self-managed controls based on operating ownership and total cost, not a feature list.
Which API gateway should I choose for Kubernetes?
Choose based on identity needs, traffic volume, operator skills, and failure testing. Kong, Envoy, NGINX, and Traefik are common choices.
Cloud gateways can fit cloud-led platforms.
Related sources
These articles can help you explore the topic in more depth:
