Best API Gateway for .NET Core: 6 Options Compared

If you're asking "what's the best API gateway for .NET Core," the honest answer depends on whether you want something native to the .NET ecosystem or something platform-agnostic that happens to work fine with .NET services. For most greenfield .NET Core projects, YARP (Yet Another Reverse Proxy) or Ocelot are the strongest starting points because they're built in C#, integrate directly with Microsoft.Extensions.DependencyInjection, and don't force you to run a separate runtime or language. For larger organizations already on Azure, Azure API Management is often the pragmatic choice because it's managed and ties into Azure AD out of the box.

There's no single "best" gateway — there's a best fit for your team's stack, ops maturity, and how much control you need over routing logic. This article breaks down the six options .NET teams actually use in production, when each one makes sense, and where a dedicated gateway is overkill compared to a specialized API layer.

What "API gateway" means in a .NET Core context

An API gateway sits in front of your services and handles:

• Routing requests to the right backend based on path, host, or headers
• Authentication/authorization, often via JWT bearer tokens or Azure AD
• Rate limiting and throttling per client or API key
• Aggregation, combining multiple backend calls into one response
• Observability — logging, tracing, and metrics for every request that passes through

In .NET Core specifically, the extra consideration is whether the gateway is a first-class ASP.NET Core middleware pipeline (so you can write custom C# transforms and reuse your existing DI, logging, and auth stack) or an external process you configure via YAML/JSON and treat as a black box.

The main options

1. YARP

YARP is Microsoft's own reverse proxy toolkit, built as a library rather than a standalone binary. You wire it into an ASP.NET Core app with builder.Services.AddReverseProxy(), and routes/clusters can be defined in appsettings.json or entirely in code.

{
  "ReverseProxy": {
    "Routes": {
      "usersRoute": {
        "ClusterId": "usersCluster",
        "Match": { "Path": "/users/{**catch-all}" }
      }
    },
    "Clusters": {
      "usersCluster": {
        "Destinations": {
          "d1": { "Address": "https://users-service.internal/" }
        }
      }
    }
  }
}

Strengths: native .NET performance, full C# extensibility for custom load balancing or header transforms, actively maintained by Microsoft. Weaknesses: you're assembling a gateway from a toolkit, not buying a finished product — things like a management UI or built-in rate-limit dashboards aren't there out of the box.

2. Ocelot

Ocelot was purpose-built as an API gateway for .NET Core microservices, with routing, aggregation, rate limiting, and caching configured declaratively in JSON.

Strengths: faster to get a working gateway with less custom code than YARP; good documentation for common microservices patterns like request aggregation. Weaknesses: smaller community than YARP, and performance under very high load has historically lagged behind a raw YARP setup.

3. Azure API Management (APIM)

A fully managed gateway from Microsoft, configured through the Azure portal, ARM templates, or Bicep. Strong fit if your .NET services already run in Azure and you want policies (auth, throttling, transformation) managed centrally without deploying and patching a gateway yourself.

Strengths: managed infrastructure, built-in developer portal, tight Azure AD/Entra ID integration. Weaknesses: cost scales with tier and volume, and you're now managing gateway logic outside your codebase in XML policies.

4. Kong Gateway

Kong is language-agnostic (built on Nginx/OpenResty with a Lua plugin system) but works well in front of .NET Core services since it just proxies HTTP. Useful if your org runs a polyglot stack and doesn't want a .NET-specific gateway that other teams can't touch.

Strengths: huge plugin ecosystem, strong at scale, good for mixed-language backends. Weaknesses: more moving parts to operate (Kong itself needs a database or DB-less config), and .NET-specific customization requires writing plugins in Lua or Go rather than C#.

5. Traefik

Popular in containerized/Kubernetes environments because it auto-discovers services via Docker labels or Kubernetes ingress annotations. Works well if your .NET Core services are already containerized and you want routing config that lives next to your deployment manifests instead of a separate gateway config file.

Strengths: low-friction service discovery, good dashboard, solid Let's Encrypt integration. Weaknesses: less suited if you need deep request transformation logic in code.

6. Envoy

Envoy is the proxy underneath service meshes like Istio. It's overkill as a standalone API gateway for most .NET Core teams unless you're already running a service mesh, but it's worth knowing if you're heading toward that architecture.

Quick decision guide

| Scenario | Likely best fit | |---|---| | Small team, all .NET, want full code control | YARP | | Need a working gateway fast with declarative config | Ocelot | | Already on Azure, want managed infra | Azure API Management | | Polyglot backend, multiple teams/languages | Kong | | Containerized/Kubernetes-native deployment | Traefik | | Already running or planning a service mesh | Envoy |

When a general gateway isn't the right layer

A reverse-proxy gateway solves routing, auth, and rate limiting for your own services — it doesn't solve the problem of exposing a stable, metered API for a specific external capability, like AI model access. If your .NET Core app calls Claude and you want that call wrapped as an application API key with usage metadata and streaming support rather than routed traffic, that's a narrower problem than what YARP or Kong are designed for.

That's the gap SubToAPI fills: it turns Claude access into a standard HTTPS API with sub_live_... application keys, so your .NET services can call it like any other REST endpoint — behind your existing YARP or Ocelot gateway if you want centralized auth and rate limiting on top. Check the quickstart or the Messages API reference if you're integrating Claude calls into a .NET Core service and want that piece handled separately from your general-purpose gateway.

questions

Is YARP better than Ocelot for .NET Core? YARP generally gives better raw performance and more C#-level extensibility since it's Microsoft's own toolkit, but Ocelot gets you a working gateway with less code because more behavior (rate limiting, aggregation) is configured declaratively out of the box.

Do I need Azure API Management if I already use YARP? Not necessarily — they overlap. Use APIM if you want managed infrastructure and centralized policy management across teams; use YARP if you want the gateway logic to live in your own codebase and deployment pipeline.

Can I use a non-.NET gateway like Kong with a .NET Core backend? Yes. Kong, Traefik, and Envoy are all language-agnostic reverse proxies that work over plain HTTP, so they route to .NET Core services the same way they'd route to any other backend.