What is an API gateway?

APIs (Application Programming Interfaces) are the building blocks of modern business, but a single API is rarely the only part of the story. Enterprises build an architecture around their APIs to ensure their quality and consistency. Here’s a look at one piece of that architecture, the API gateway: what it is, what it does — or what it should do — and why it’s especially important for securing, monitoring, and scaling your APIs.

What is an API gateway?

API gateways are API proxies that are put between the API Provider and the API Consumer. At its heart, an API gateway is a façade that provides an API interface to your complex subsystem.

An API gateway is programming that sits in front of an API and is the single-entry point for defined back-end APIs and microservices (which can be both internal and external). The gateway acts as a protector, enforcing security and ensuring scalability and high availability. To put it simply, the API gateway takes all API requests from a client, determines which services are needed, and combines them into a unified experience for the user.

The “front-end APIs” act as the “front door” for all your applications that have access to data, business logic, or functionality from your backend services. It decouples the interface that your clients see (in this case, API consumers that could be mobile apps, thin clients) from the actual underlying implementation.

Why do you need an API gateway?

You need an API gateway because direct, unmediated access to your backend services is a security, performance, and governance liability. Every API you expose (internally or externally) carries valuable data that has to be authenticated, rate-limited, observed, and routed consistently. A gateway is the single control plane that applies those policies in one place, instead of forcing every team to reimplement them per service.

APIs have become a strategic necessity for businesses, but exposing them without a gateway leaves you reinventing security, throttling, and monitoring at every endpoint. The gateway exists so the rest of your engineering organization does not have to.

Gartner predicted that API abuses would be the most frequent attack vector for enterprise web application data breaches in 2022. And analysts find in a new report that “unmanaged and unsecured APIs create vulnerabilities that could accelerate multimillion-dollar security incidents.”

So what do you do? You invest in the right API gateway to make sure that things happening outside your enterprise are not breaking things within your enterprise.

Furthermore, an API is useless unless it is delivered with consistent quality, and someone actually uses it. A gateway is critical to help ensure great performance, high availability, and elastic scalability of APIs by enabling enterprises to initiate delivery with uniform supporting services, including traffic management, transformation, and system integration.

Related: Axway achieves Common Criteria EAL4+ certification for API Gateway

Gateways are part of an API architecture

Let’s take a quick step back to understand how an API gateway fits into an API architecture.

First, what’s an API architecture? Unlike API design, which focuses on why the API is being created, the outcome, and how it will be executed, API architecture is defining the entire methodology and process for running and exposing APIs.

It encompasses the API gateway (and how API security, caching, orchestration will work), developing an API portal for API analysis, API documentation, marketing APIs, making sure they work with web/mobile applications, and defining how they are exposed to internal, partner, and third-party developers.

Having a complete API architecture will help your business with the entire API lifecycle management process.

API gateways are core infrastructure

Think of an API gateway platform as an application server, but for APIs. It is seen as the API runtime environment, and provides these core services:

• API security
• API protocol connectivity
• API virtualization
• API scalability and elasticity
• High availability
• Manageability
• Development simplicity

Since the core API infrastructure is provided, developers can focus on providing the application logic, and no longer need to build these services into their application.

API gateway vs ingress controller, service mesh, and API management

A common source of confusion in modern architectures is where the API gateway ends and other infrastructure begins. Here is the distinction in plain terms.

• API gateway vs ingress controller. An ingress controller (in Kubernetes) routes north-south HTTP traffic into the cluster based on hostname and path. An API gateway also does that, but adds API-specific concerns like authentication, rate limiting, payload transformation, response caching, developer-portal publishing, and API key issuance. If all you need is request routing into a cluster, an ingress controller is enough. If you need to monetize, secure, observe, or productize APIs, you need a gateway.
• API gateway vs service mesh. A service mesh (Istio, Linkerd) governs east-west traffic between microservices inside the cluster, mostly transparently to application code. An API gateway governs north-south traffic from external clients into your APIs. The two are complementary, not competing. A mature architecture often runs both: the gateway at the edge for external consumers, the mesh inside for service-to-service.
• API gateway vs API management platform. The gateway is the runtime, the data plane that actually intercepts and processes API calls. An API management platform is the broader control plane that includes the gateway plus a developer portal, an API catalog, analytics, policy authoring, lifecycle versioning, and (in federated platforms like Amplify Fusion) the ability to govern multiple gateways from multiple vendors. The gateway is one component of API management, not all of it.
• API gateway vs load balancer. A load balancer (Layer 4 or Layer 7) distributes traffic across backend instances based on health and capacity. A gateway distributes and processes traffic based on API semantics (method, path, headers, auth claims). You typically run a load balancer in front of the gateway, not instead of it.

The short version: a load balancer moves bytes, an ingress controller routes HTTP, a service mesh secures service-to-service traffic, an API gateway processes APIs as products, and an API management platform governs the whole estate.

How does an API gateway work?

An API gateway works by intercepting every API request before it reaches a backend service, applying a configured chain of policies (authentication, authorization, rate limiting, transformation, caching, logging), then routing the processed request to the right backend and returning the response to the client. Because the policy chain runs at the gateway instead of in each backend, you get consistent enforcement across every API you expose, regardless of which language or framework powers the backend.

By acting as a central interface for clients using APIs, an API gateway acts as the single entryway into a system allowing multiple APIs or microservices to act cohesively and provide a uniform experience to your users. An API gateway plays an important role in ensuring the reliable processing of every API call.

As the diagram recommends, all your policies should be enforced at the API gateway. Do not depend on your back-end APIs and certainly not on your front-end applications to build the right level of security to protect your APIs. All your API security challenges can and should be delegated to API gateway because you don’t have to write any code, it’s all about configuration.

Who is responsible for the platform and how is it administered?

The API gateway is typically owned by a platform team (sometimes called API platform engineering, integration platform, or developer experience team) that runs it as shared infrastructure for the rest of the organization. Day-to-day administration falls into three roles: platform engineers who run the gateway runtime and keep it patched, API producers who publish and version their APIs through the gateway, and API consumers who subscribe to APIs through the developer portal. A well-run gateway gives each role a self-service path so the platform team is not a bottleneck for every new API.

There are two teams responsible for managing the platform: the operations team and the architecture team. Operations handles runtime management of message traffic, logs and alerts, and high availability. The security and systems architects define and manage the design-time policy, which determines the behavior of the API gateway platform.

There are five main stages in an API gateway administration lifecycle:

1. Planning an API gateway system
2. Installing API gateway components
3. Configuring a domain
4. Operating and managing the API gateway
5. Upgrading the API gateway

API gateways in Kubernetes and microservices architectures

In a microservices estate, the API gateway plays a different role than it did for a monolithic application. Each microservice exposes its own internal API, and a client (browser, mobile app, partner system) should never have to know about that internal topology. The gateway is the seam that hides it.

Three Kubernetes-specific patterns matter in practice:

• Backend-for-Frontend (BFF). A dedicated gateway per client type (web, mobile, partner) shapes responses for that consumer instead of forcing every service to support every payload format. This pattern keeps backend services focused on business logic and pushes the format-shifting work to the edge.
• Gateway-aggregator pattern. A single gateway request fans out to multiple microservices and stitches their responses into a unified payload. This collapses what would otherwise be 5 or 6 client round-trips into one, which matters for mobile clients on high-latency networks.
• Gateway-as-policy-enforcement-point. Rather than letting each microservice implement its own authentication, throttling, and audit logging, the gateway enforces those policies centrally. Service code stays small; security and compliance posture stays consistent across the estate.

Production Kubernetes deployments typically run an ingress controller for raw traffic entry, an API gateway above it for API-specific policy, and a service mesh inside for east-west service traffic. Amplify Fusion is designed to govern API gateways across all the major Kubernetes-native runtimes (AWS API Gateway, Azure APIM, Kong, Apigee, Istio, Mulesoft) from one control plane, so a multi-cluster, multi-cloud microservices estate stays under unified governance.

Key aspects every API gateway should address

Every production-grade API gateway has to cover six core capabilities or you will outgrow it within a year: authentication and authorization (OAuth 2, OpenID Connect, JWT, mTLS), traffic control (rate limiting, quotas, circuit breakers), transformation (request and response shaping across REST, SOAP, GraphQL), observability (metrics, distributed tracing, structured access logs), developer experience (API catalog, interactive docs, self-service onboarding), and lifecycle management (versioning, deprecation policies, schema validation). Anything that misses one of these forces your platform team to bolt the missing capability on top, which is exactly the sprawl problem an API gateway is supposed to prevent.

Here are some essential features to look for in an API gateway solution.

1. API Security

Access control is the number-one security driver for an API gateway technology. It serves as a governor of sorts, so an organization can manage who can access an API and establish rules around how data requests are handled. Authentication and Authorization are of primary importance. My colleague Dave McKenna shares a great analogy from a favorite movie that explains the capabilities of an API gateway.

An API gateway should ensure only authenticated users can access the backend APIs by providing an authentication layer. The API gateway should be able to integrate with existing and custom authentication providers. This ensures the back-end APIs doesn’t have to implement this logic and any changes to the authentication schemes require no changes to the backend.

Once Authenticated, the API gateway then authorizes “what” the authenticated user has access to. With Authorization, an API gateway should be able to abstract common complexities from back-end APIs. This avoids the back-end API having to maintain this logic and any subsequent changes to it.

An API gateway should be able to work with existing authorization mechanisms. It should also be able to provide fine-grained, centrally managed access rights to each individual method of an API.

In a nutshell, API security is about authentication and authorization. The effective implementation of a gateway “should be able to absorb all of that, so backend services don’t have to deal with authorization anymore.” This simplifies access rule configuration and, potentially, dealing with complex authorization logic.

Learn more from Forbes on why you need to pay attention to API security.

2. Rate-Limiting

An API gateway should help with reducing the load on backend APIs and prevent misuse. Rate-limiting provides restricted access to APIs by permitting only a certain number of requests. By exposing APIs to third-party consumers, this also could provide a revenue stream by opening up the possibilities of higher rate limits.

3. API Monitoring and Logging

An API gateway should provide default monitoring across all APIs and have the ability to track requests/response time is taken, SLA, etc. It should be able to integrate with a full-featured monitoring solution to help track this information.

Since it sits between the consumers and APIs, API gateways should provide default logging capabilities. API gateways help provide unified logging capabilities to all APIs. To help analyze multiple APIs together, the gateway should be able to provide a co-relation ID into their request headers, so backend APIs, front-end Apps can also include this ID into their logging activities.

4. Threat Protection

APIs are the gateways for enterprises to connect digitally with the world. Unfortunately, there are malicious users out there, waiting to gain access to enterprise backend systems. An API gateway needs to provide threat protection against potential hackers, malware, and/or anonymous outsiders to prevent against DDoS or SQL Injection attacks amongst others.

5. API Transformation

An API gateway should provide the capabilities to transform requests/response payloads. As organizations move from a legacy-based SOAP-based architecture to a more modern REST-base architecture and need a quick time-to-market strategy, payload transformation becomes an integral component of this requirement.

6. Scaling

As the API gateway sits between the consumers and backend APIs, it’s also in the unique position to determine any high or low activities based on the monitoring that’s enabled. Even though the gateway may not be expected to provide auto-scaling out of the box, it should be able to integrate with services that provide this capability.

An API gateway must support scalability and high availability, load balancing, shared state without compromising performance. It should provide linear scalability and fault tolerance on hardware or cloud infrastructure for mission-critical data. It should also support replicating across multiple data centers and providing lower latency for your consumers.

As the API market matures, so does the increase in security breaches. As decision-makers, you want assurances that exposing enterprise data via APIs will not create undue risk. The API gateway provides the ability to securely publish APIs in an automated manner, ensuring high availability so that developers can quickly and easily find and use them to deliver business value for your organization while ensuring integrity and confidentiality.