This is an automated email from the ASF dual-hosted git repository.
baoyuan pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/apisix-website.git
The following commit(s) were added to refs/heads/master by this push:
new d21398b3643 feat(seo): add 5 Learning Center articles and SEO
contributing guide (P3) (#2027)
d21398b3643 is described below
commit d21398b36439ac63dd70645cc955dcf98e33fb31
Author: Ming Wen <[email protected]>
AuthorDate: Thu Apr 16 10:11:23 2026 +0800
feat(seo): add 5 Learning Center articles and SEO contributing guide (P3)
(#2027)
---
CONTRIBUTING-SEO.md | 140 +++++++++++++++++++++
website/learning-center/api-gateway-security.md | 131 +++++++++++++++++++
website/learning-center/apisix-vs-kong.md | 131 +++++++++++++++++++
website/learning-center/mcp-protocol-ai-gateway.md | 124 ++++++++++++++++++
4 files changed, 526 insertions(+)
diff --git a/CONTRIBUTING-SEO.md b/CONTRIBUTING-SEO.md
new file mode 100644
index 00000000000..fa1e47c6c94
--- /dev/null
+++ b/CONTRIBUTING-SEO.md
@@ -0,0 +1,140 @@
+# SEO Guidelines for Apache APISIX Website Contributors
+
+This document provides SEO best practices for anyone contributing content to
the Apache APISIX website, documentation, or blog. Following these guidelines
ensures that our content ranks well in both traditional search engines and
AI-powered search (Google AI Overviews, ChatGPT, Perplexity).
+
+## Frontmatter Requirements
+
+Every Markdown page (blog post, doc page, learning center article) **must**
include:
+
+```yaml
+---
+title: "Human-Readable Title - Primary Keyword | Apache APISIX"
+description: "120-160 character description that accurately summarizes the
page content and includes the primary keyword naturally."
+---
+```
+
+### Title Rules
+
+- **Length**: 50-60 characters (Google truncates longer titles in SERPs)
+- **Format**: `Primary Topic - Modifier | Apache APISIX`
+- **Keyword placement**: Put the primary keyword near the front
+- **Human-readable**: Write for humans, not bots. No keyword stuffing.
+- **Plugin pages**: Use the human-readable name, not just the code identifier
+ - Good: `Rate Limiting Plugin (limit-req) | Apache APISIX`
+ - Bad: `limit-req | Apache APISIX`
+
+### Description Rules
+
+- **Length**: 120-160 characters
+- **Content**: Describe the page honestly and include the main topic naturally
+- **Action-oriented**: Start with a verb when possible ("Learn how to...",
"Configure...", "Compare...")
+
+## Content Structure
+
+### Answer-First Writing
+
+Place the primary answer or definition in the **first 40-60 words** of the
page. AI search engines preferentially extract opening paragraphs.
+
+```markdown
+## What is an API Gateway?
+
+An API gateway is a server that sits between clients and backend
+services, acting as the single entry point for all API traffic.
+It handles authentication, rate limiting, and routing so that
+individual services don't need to implement these concerns.
+
+[Rest of the detailed content follows...]
+```
+
+### Heading Hierarchy
+
+- **One H1 per page** (the `title` in frontmatter)
+- Use H2 for major sections, H3 for subsections
+- Headings should match developer search queries when possible
+ - Good: `## How to Configure Rate Limiting in APISIX`
+ - Bad: `## Configuration`
+- Never skip heading levels (H1 → H3 without H2)
+
+### Statistics and Data
+
+Include **at least one statistic or data point every 150-200 words**. Concrete
numbers make content more authoritative and more likely to be cited by AI
engines.
+
+Examples:
+
+- "Apache APISIX processes 18,000 requests per second per core with 0.2ms
latency"
+- "Over 147,000 deployments across 5,200+ companies"
+- "100+ built-in plugins covering authentication, security, and traffic
control"
+
+Always cite the source when referencing external statistics.
+
+### Internal Linking
+
+- Every page should include **at least 2 internal links** to related content
+- Use descriptive anchor text, not "click here" or "learn more"
+ - Good: `[rate limiting plugin
documentation](/docs/apisix/plugins/limit-req/)`
+ - Bad: `[click here](/docs/apisix/plugins/limit-req/)`
+- Link from new pages to relevant existing content
+- Use relative paths for internal links
+
+### FAQ Sections
+
+For Learning Center articles, include a FAQ section at the end with 3-5
questions:
+
+```markdown
+## Frequently Asked Questions
+
+### What is the difference between an API gateway and a load balancer?
+
+[Concise, direct answer in 2-3 sentences]
+
+### Do I need an API gateway for microservices?
+
+[Concise, direct answer]
+```
+
+FAQ content is highly valued by AI search engines and can appear as rich
results in Google SERPs.
+
+## Images
+
+- **Alt text is mandatory**: Every image must have descriptive alt text
+ - Good: `alt="Apache APISIX architecture diagram showing request flow from
client through gateway to upstream services"`
+ - Bad: `alt="diagram"` or `alt=""`
+- Include explicit `width` and `height` attributes
+- Use `loading="lazy"` for below-the-fold images
+- Use WebP or AVIF formats when possible
+
+## Blog Posts
+
+### Evergreen Content
+
+- Avoid time-relative phrases like "recently" or "last month"
+- Use absolute dates: "In March 2026" instead of "last quarter"
+- Update posts when information becomes outdated (and update the `date` in
frontmatter)
+
+### Blog Post Metadata
+
+```yaml
+---
+title: "Descriptive Title With Primary Keyword"
+authors:
+ - name: Author Name
+description: "120-160 character description"
+tags: [relevant, tags]
+image: /path/to/og-image.png # Required for social sharing
+---
+```
+
+## Technical SEO Checklist
+
+Before submitting a PR that adds or modifies content pages:
+
+- [ ] Title tag is 50-60 characters with primary keyword near the front
+- [ ] Meta description is 120-160 characters and accurately describes the page
+- [ ] Only one H1 per page
+- [ ] Heading hierarchy is logical (H1 > H2 > H3, no skipped levels)
+- [ ] At least 2 internal links to related content
+- [ ] All images have descriptive alt text
+- [ ] Opening paragraph directly answers the page topic (answer-first)
+- [ ] At least 1 statistic or data point per 200 words
+- [ ] No duplicate content with existing pages
+- [ ] Blog posts have an `image` field for social sharing
diff --git a/website/learning-center/api-gateway-security.md
b/website/learning-center/api-gateway-security.md
new file mode 100644
index 00000000000..8a064dd685b
--- /dev/null
+++ b/website/learning-center/api-gateway-security.md
@@ -0,0 +1,131 @@
+---
+title: "API Gateway Security: Threats, Best Practices & Implementation"
+description: "Learn how to secure your API gateway against common threats.
Covers authentication, authorization, rate limiting, WAF, IP filtering, and
zero-trust architecture."
+slug: api-gateway-security
+date: 2026-04-14
+tags: [security, api-gateway, best-practices]
+hide_table_of_contents: false
+---
+
+API gateway security is the practice of protecting your API infrastructure at
the edge by enforcing authentication, authorization, rate limiting, and traffic
filtering before requests reach backend services. A properly secured gateway
reduces attack surface, prevents data breaches, and ensures compliance across
every API endpoint in your organization.
+
+## Why API Gateway Security Matters
+
+APIs have become the primary attack vector for modern applications. According
to the OWASP API Security Top 10 (2023 edition), broken object-level
authorization and broken authentication remain the two most critical API
vulnerabilities, affecting organizations across every industry. The explosive
growth of API-first architectures has created an equally explosive growth in
API-targeted attacks.
+
+The cost of getting API security wrong is substantial, as breaches involving
API vulnerabilities tend to take longer to identify and contain and carry
significant financial impact. The API gateway sits at a unique vantage point:
it processes every inbound request, making it the single most effective
location to enforce security policies consistently.
+
+## Common API Threats
+
+Understanding the threat landscape is essential for building an effective
defense. The following categories represent the most frequent and damaging
attack patterns targeting APIs today.
+
+### Broken Object-Level Authorization (BOLA)
+
+BOLA attacks exploit weak authorization checks to access resources belonging
to other users. An attacker modifies object identifiers in API requests (for
example, changing `/users/123/orders` to `/users/456/orders`) to retrieve
unauthorized data. BOLA remains one of the most exploited API vulnerability
classes, particularly in organizations where API management and authorization
enforcement have not kept pace with API proliferation.
+
+### Injection Attacks
+
+SQL injection, NoSQL injection, and command injection remain persistent
threats. Attackers embed malicious payloads in query parameters, headers, or
request bodies. Despite being a well-known vulnerability class, injection
attacks continue to appear frequently in web application security assessments.
+
+### Broken Authentication
+
+Weak or improperly implemented authentication mechanisms allow attackers to
assume legitimate user identities. Common failures include missing token
validation, weak password policies, credential stuffing vulnerabilities, and
improper session management. Credential stuffing attacks account for billions
of login attempts monthly across the internet.
+
+### Excessive Data Exposure
+
+APIs frequently return more data than the client needs, relying on the
frontend to filter sensitive fields. Attackers bypass the frontend and consume
raw API responses directly, gaining access to data never intended for display.
This over-exposure is especially dangerous in mobile applications where API
traffic is easily intercepted.
+
+### Rate Limit Bypass
+
+Without proper rate limiting, attackers can launch brute-force attacks,
denial-of-service campaigns, and credential enumeration at scale. Automated bot
traffic constitutes a significant portion of all internet traffic, and much of
it targets API endpoints specifically.
+
+## Security Layers at the Gateway
+
+A defense-in-depth approach applies multiple security controls at the gateway
layer, each addressing a distinct category of risk.
+
+### Authentication
+
+The gateway should verify identity before any request reaches a backend
service. Common mechanisms include JWT validation, OAuth 2.0 token
introspection, API key verification, and mutual TLS (mTLS) for
service-to-service communication. Centralizing authentication at the gateway
eliminates the risk of inconsistent enforcement across individual services.
+
+### Authorization
+
+Beyond verifying identity, the gateway must enforce access control. Role-based
access control (RBAC), attribute-based access control (ABAC), and scope-based
authorization ensure that authenticated users can only access resources and
operations they are permitted to use. Fine-grained authorization at the gateway
prevents BOLA vulnerabilities at scale.
+
+### Rate Limiting and Throttling
+
+Rate limiting protects backend services from abuse and ensures fair resource
allocation. Effective rate limiting operates at multiple granularities: per
consumer, per route, per IP address, and globally. A substantial share of
traffic on the average website comes from bots, and rate limiting is the first
line of defense against automated abuse.
+
+### IP Restriction
+
+IP allowlists and denylists provide coarse-grained access control. While not
sufficient as a sole security measure, IP restriction is valuable for
restricting administrative endpoints, limiting partner API access to known
address ranges, and blocking traffic from regions associated with attack
activity.
+
+### WAF and CORS
+
+A Web Application Firewall (WAF) at the gateway layer inspects request
payloads for known attack patterns. CORS policies prevent unauthorized
cross-origin requests from browser-based clients. Together, they address both
server-side injection attacks and client-side cross-origin abuse.
+
+### TLS Termination
+
+TLS termination at the gateway ensures that all client-to-gateway traffic is
encrypted. The gateway handles certificate management, cipher suite
configuration, and protocol version enforcement, relieving backend services of
this operational burden. The vast majority of web traffic now uses HTTPS, and
TLS is considered a baseline requirement for any production API.
+
+### Request Validation
+
+Schema-based request validation rejects malformed or oversized payloads before
they reach backend services. Validating request structure, data types, and
content length at the gateway prevents injection attacks and reduces the attack
surface of downstream services.
+
+## Zero-Trust API Architecture
+
+Zero-trust architecture assumes that no request is inherently trustworthy,
regardless of its origin. Every API call must be authenticated, authorized, and
validated, whether it arrives from the public internet, an internal service, or
a trusted partner.
+
+At the gateway layer, zero-trust principles translate into several concrete
practices. Every request carries verifiable identity credentials. Authorization
is evaluated per request rather than per session. Network location (internal
vs. external) does not confer implicit trust. All traffic is encrypted,
including east-west service-to-service communication.
+The API gateway enables zero-trust by serving as a policy enforcement point.
It validates tokens, checks permissions, and applies security policies
uniformly across all traffic, creating a consistent security boundary
regardless of the underlying network topology.
+
+## Security Best Practices
+
+The following practices represent a comprehensive approach to API gateway
security that organizations should adopt incrementally based on risk profile.
+
+1. **Enforce authentication on every endpoint.** No API route should be
accessible without verified identity. Use JWTs with short expiration times and
validate signatures on every request.
+
+2. **Implement least-privilege authorization.** Grant the minimum permissions
required for each consumer. Default to deny and require explicit grants for
sensitive operations.
+
+3. **Apply rate limiting at multiple levels.** Configure per-consumer,
per-route, and global rate limits. Use sliding window algorithms to prevent
burst abuse while accommodating legitimate traffic spikes.
+
+4. **Validate all request inputs.** Enforce request schema validation at the
gateway. Reject payloads that exceed expected sizes, contain unexpected fields,
or fail type checks.
+
+5. **Use mutual TLS for service-to-service calls.** Encrypt and authenticate
all internal traffic. Rotate certificates automatically and enforce certificate
validation on every connection.
+
+6. **Enable WAF rules for known attack patterns.** Deploy rulesets targeting
SQL injection, XSS, and command injection. Update rules regularly to address
emerging attack vectors.
+
+7. **Log and audit all security events.** Capture authentication failures,
authorization denials, rate limit triggers, and WAF blocks. Feed security logs
into a SIEM for correlation and alerting.
+
+8. **Rotate credentials and secrets regularly.** Automate API key rotation,
certificate renewal, and token signing key rotation. Never embed secrets in
client-side code or version control.
+
+9. **Restrict administrative API access.** Protect management APIs with strong
authentication, IP restrictions, and separate credentials from data-plane APIs.
+
+10. **Conduct regular security assessments.** Perform API-specific penetration
testing, not just general web application assessments. The OWASP API Security
Testing Guide provides a structured methodology.
+
+## How Apache APISIX Secures APIs
+
+Apache APISIX provides a comprehensive set of security plugins that implement
each layer of the defense-in-depth model described above.
+
+For **IP-based access control**, the [ip-restriction
plugin](/docs/apisix/plugins/ip-restriction/) supports allowlists and denylists
at the route level, enabling fine-grained control over which addresses can
reach specific endpoints.
+
+**Cross-origin resource sharing** is managed through the [CORS
plugin](/docs/apisix/plugins/cors/), which configures allowed origins, methods,
and headers to prevent unauthorized cross-origin requests from browser clients.
+
+**CSRF protection** is available through the [CSRF
plugin](/docs/apisix/plugins/csrf/), which generates and validates CSRF tokens
to prevent cross-site request forgery attacks on state-changing API operations.
+
+For **mutual TLS**, APISIX supports [mTLS configuration](/docs/apisix/mtls/)
for both client-to-gateway and gateway-to-upstream connections, ensuring
encrypted and mutually authenticated communication at every hop.
+
+APISIX also supports JWT authentication, key authentication, OpenID Connect,
rate limiting with multiple algorithms, and request body validation. The plugin
architecture enables security policies to be composed per route, allowing teams
to apply exactly the controls each endpoint requires without over- or
under-securing traffic.
+
+## FAQ
+
+### What is the difference between API gateway security and API security?
+
+API security is the broad discipline of protecting APIs across their entire
lifecycle, including design, development, testing, and runtime. API gateway
security specifically refers to the security controls enforced at the gateway
layer during runtime, such as authentication, rate limiting, and input
validation. The gateway is one component of a comprehensive API security
strategy, not a replacement for secure coding practices and security testing.
+
+### Should I terminate TLS at the API gateway or at the backend service?
+
+Terminate TLS at the gateway for client-facing connections. This centralizes
certificate management and offloads cryptographic processing from backend
services. For traffic between the gateway and upstream services, use mTLS to
maintain encryption and mutual authentication throughout the request path. This
approach balances operational simplicity with end-to-end security.
+
+### How many rate limiting layers should an API gateway enforce?
+
+Apply at least three layers: a global rate limit to protect overall
infrastructure capacity, a per-consumer limit to prevent any single client from
monopolizing resources, and per-route limits for endpoints with expensive
backend operations. Use sliding window or leaky bucket algorithms rather than
fixed windows to provide smoother throttling behavior and prevent burst abuse
at window boundaries.
diff --git a/website/learning-center/apisix-vs-kong.md
b/website/learning-center/apisix-vs-kong.md
new file mode 100644
index 00000000000..cea0502eef8
--- /dev/null
+++ b/website/learning-center/apisix-vs-kong.md
@@ -0,0 +1,131 @@
+---
+title: "Apache APISIX vs Kong: Feature Comparison & Performance Benchmarks"
+description: "Detailed comparison of Apache APISIX and Kong API Gateway.
Covers architecture, performance, plugin ecosystem, Kubernetes support, and
when to choose each."
+slug: apisix-vs-kong
+date: 2026-04-14
+tags: [comparison, apisix, kong, api-gateway]
+hide_table_of_contents: false
+---
+
+Apache APISIX and Kong are the two most widely adopted open-source API
gateways, both built on NGINX and Lua. APISIX differentiates itself with a
fully dynamic architecture powered by etcd, higher single-core throughput, and
a broader protocol support matrix, while Kong offers a mature enterprise
ecosystem with extensive third-party integrations and a large plugin
marketplace.
+
+## Overview
+
+Both projects serve as high-performance, extensible API gateways for
microservices architectures. Kong was open-sourced in 2015 and has built a
substantial commercial ecosystem around Kong Gateway Enterprise, Kong Konnect,
and the Kong Plugin Hub. Apache APISIX entered the Apache Software Foundation
incubator in 2019 and graduated as a top-level project in 2020, with rapid
community growth.
+
+Both projects are recognized as production-grade gateways and see active
production deployments worldwide.
+
+## Architecture Comparison
+
+The architectural differences between APISIX and Kong are fundamental and
affect day-to-day operations, scalability, and deployment complexity.
+
+### Apache APISIX Architecture
+
+APISIX uses NGINX as its data plane with Lua plugins running in the request
lifecycle. Configuration is stored in **etcd**, a distributed key-value store
that pushes changes to all gateway nodes in real time via watch mechanisms.
This architecture means that route changes, plugin updates, and upstream
modifications take effect within milliseconds without requiring restarts or
reloads. There is no relational database dependency.
+
+The etcd-based design gives APISIX a stateless data plane: any node can be
added or removed without migration steps or database schema changes. This makes
horizontal scaling straightforward and reduces operational overhead
significantly in Kubernetes environments where pods are ephemeral.
+
+### Kong Architecture
+
+Kong also uses NGINX and Lua for its data plane. Configuration is stored in
**PostgreSQL** or **Cassandra** (though Cassandra support has been deprecated
in newer versions). Kong's DB-mode requires database migrations when upgrading,
and configuration changes propagate through a polling mechanism with a
configurable cache TTL, which introduces a delay between API calls to the Admin
API and actual enforcement at the proxy layer.
+
+Kong also offers a DB-less mode where configuration is loaded from a
declarative YAML file, which eliminates the database dependency but sacrifices
the ability to modify configuration dynamically through the Admin API at
runtime. Kong's commercial offering, Konnect, provides a managed control plane
that addresses many of these operational concerns.
+
+## Performance Benchmarks
+
+Performance characteristics matter at scale, where even small per-request
overhead compounds into significant infrastructure costs.
+
+Key architectural differences that affect performance:
+
+- **Route matching**: APISIX uses a radix tree-based routing algorithm. Kong
uses a different matching approach. The routing algorithm affects lookup time
as the number of routes grows.
+- **Configuration propagation**: APISIX pushes configuration changes from etcd
to all nodes in real time. Kong's DB-mode polls the database on a configurable
interval, introducing a delay between configuration changes and enforcement.
+- **Memory model**: Both use NGINX's event-driven architecture, but their
plugin execution models differ in per-request allocation patterns.
+
+We recommend benchmarking both gateways with your actual workload, plugin
chain, and hardware to get meaningful performance comparisons. Vendor-published
benchmarks often test under ideal conditions that may not reflect your
production environment.
+
+For many production deployments, both gateways provide sufficient throughput,
and the choice often depends on factors beyond raw performance such as
ecosystem maturity, plugin availability, and operational familiarity.
+
+## Feature Comparison
+
+| Feature | Apache APISIX | Kong (OSS) |
+|---------|--------------|-------------|
+| Plugin count (built-in) | 80+ | 40+ (OSS), 200+ (Enterprise) |
+| Protocol support | HTTP/1.1, HTTP/2, HTTP/3, gRPC, WebSocket, TCP/UDP, MQTT,
Dubbo | HTTP/1.1, HTTP/2, gRPC, WebSocket, TCP/UDP |
+| Dashboard | Apache APISIX Dashboard (OSS) | Kong Manager (Enterprise only) |
+| Admin API | Full REST API, fully dynamic | REST API, DB-mode or DB-less |
+| Service discovery | Nacos, Consul, Eureka, DNS, Kubernetes | DNS, Consul
(others via plugins) |
+| Kubernetes ingress | APISIX Ingress Controller (CRD-based) | Kong Ingress
Controller (KIC) |
+| AI gateway capabilities | ai-proxy plugin, multi-LLM routing | AI Gateway
plugins (Enterprise) |
+| Multi-language plugin support | Go, Java, Python, Wasm, Lua | Go,
JavaScript, Python (PDK) |
+| Configuration storage | etcd (distributed, real-time) | PostgreSQL (requires
migrations) |
+| Canary/traffic splitting | Built-in traffic-split plugin | Canary plugin
(Enterprise) |
+
+Both gateways support core functionality like rate limiting, authentication
(JWT, OAuth 2.0, API key, LDAP), load balancing, health checks, and circuit
breaking. The primary differences lie in the breadth of built-in features
available in the open-source edition versus features gated behind enterprise
licensing.
+
+## Plugin Ecosystem
+
+APISIX ships with over 80 built-in plugins covering authentication, security,
traffic management, observability, and protocol transformation. Notably,
plugins for serverless functions (running custom Lua, Java, or Go code inline),
AI proxy routing, and advanced traffic management are available in the
open-source edition.
+
+Kong's open-source edition includes approximately 40 built-in plugins, with a
substantial number of additional plugins available through Kong Plugin Hub and
the enterprise edition. Kong's plugin marketplace includes many third-party and
partner-contributed plugins, giving it a broader ecosystem for specific vendor
integrations like Datadog, PagerDuty, and Moesif.
+
+For custom plugin development, APISIX supports external plugins via gRPC-based
plugin runners in Go, Java, and Python, as well as Wasm-based plugins that run
in a sandboxed environment. Kong offers a Plugin Development Kit (PDK)
supporting Go, JavaScript, and Python alongside native Lua plugins. Both
projects accept community-contributed plugins, and their ecosystems continue to
grow.
+
+## Kubernetes Integration
+
+Both gateways offer mature Kubernetes ingress controllers, though they differ
in design philosophy.
+
+The **APISIX Ingress Controller** supports both custom resource definitions
(CRDs) specific to APISIX and standard Kubernetes Ingress resources. It
communicates with the APISIX data plane through the Admin API and supports
Gateway API, the emerging Kubernetes standard for traffic management.
Configuration changes propagate instantly through etcd.
+
+The **Kong Ingress Controller (KIC)** also supports CRDs and standard
Kubernetes Ingress resources, with Kong-specific annotations for extended
functionality. KIC translates Kubernetes resources into Kong configuration,
applying them through the Admin API. KIC has a longer track record in
production Kubernetes environments and benefits from extensive documentation
and community resources.
+
+Both controllers are actively maintained and see regular releases aligned with
Kubernetes version updates.
+
+## Community and Ecosystem
+
+| Metric | Apache APISIX | Kong |
+|--------|--------------|------|
+| License | Apache 2.0 | Apache 2.0 (OSS) |
+| Governance | Apache Software Foundation | Kong Inc. |
+| First release | 2019 | 2015 |
+
+APISIX benefits from Apache Software Foundation governance, which ensures
vendor-neutral development and community-driven roadmap decisions. Kong
benefits from the backing of Kong Inc., which provides dedicated engineering
resources, enterprise support, and a commercial ecosystem that many large
organizations value.
+
+Both projects maintain active community forums, Slack channels, and regular
release cadences. Kong's longer market presence gives it an advantage in terms
of available tutorials, third-party integrations, and consultant familiarity.
+
+## When to Choose Apache APISIX
+
+APISIX is the stronger choice when your requirements include:
+
+- **Dynamic configuration at scale:** Environments where routes and plugins
change frequently benefit from etcd-based instant propagation without restarts.
+- **Maximum open-source functionality:** Teams that need advanced features
like traffic splitting, AI proxy, and multi-protocol support without enterprise
licensing.
+- **High-performance requirements:** Workloads where per-request latency and
single-core throughput directly impact infrastructure costs.
+- **Kubernetes-native deployments:** Organizations adopting Gateway API and
wanting tight integration with cloud-native service discovery (Nacos, Consul,
Eureka).
+- **Vendor-neutral governance:** Teams that prefer Apache Software Foundation
stewardship over single-vendor control.
+
+## When to Choose Kong
+
+Kong is the stronger choice when your requirements include:
+
+- **Mature enterprise ecosystem:** Organizations that need commercial support,
SLA guarantees, and a proven enterprise deployment track record.
+- **Extensive third-party integrations:** Environments with specific vendor
integration needs covered by Kong's plugin marketplace.
+- **Existing Kong investment:** Teams already running Kong in production where
migration cost outweighs technical advantages.
+- **Managed control plane:** Organizations that prefer a SaaS-managed control
plane (Kong Konnect) to reduce operational burden.
+- **Broad hiring market:** Teams that can more easily find engineers with Kong
experience due to its longer market presence.
+
+## FAQ
+
+### Can APISIX and Kong run side by side during a migration?
+
+Yes. Both gateways can operate in parallel by splitting traffic at the load
balancer level. A common migration strategy routes new services through APISIX
while existing services continue running through Kong. Gradual traffic shifting
with health checks ensures zero-downtime migration. The timeline depends on the
number of routes, custom plugins, and testing requirements.
+
+### Is APISIX harder to operate because it requires etcd?
+
+etcd adds a dependency compared to Kong's DB-less mode, but in practice, etcd
is a well-understood, battle-tested component already present in most
Kubernetes clusters (it is the backing store for Kubernetes itself). Operating
etcd requires standard distributed systems practices: run an odd number of
nodes (3 or 5), monitor disk latency, and maintain regular snapshots. For teams
already running Kubernetes, etcd operational knowledge is typically already
available. The operational cost of [...]
+
+### Which gateway has better AI and LLM support?
+
+Both gateways are investing in AI gateway capabilities, but they approach it
differently. APISIX provides the ai-proxy plugin in its open-source edition,
supporting multi-model routing, token-based rate limiting, and prompt
transformation for major LLM providers. Kong offers AI Gateway plugins
primarily through its enterprise edition and Konnect platform. For teams
building AI-powered applications on an open-source budget, APISIX currently
provides more built-in AI functionality without [...]
+
+### How do the two gateways compare on gRPC and streaming support?
+
+APISIX provides native gRPC proxying, gRPC-Web transcoding, and HTTP-to-gRPC
transformation out of the box, along with support for HTTP/3 (QUIC), Dubbo, and
MQTT protocols. Kong supports gRPC proxying and gRPC-Web through plugins, with
HTTP/2 support on both client and upstream connections. For teams heavily
invested in gRPC or multi-protocol architectures, APISIX's broader built-in
protocol support reduces the need for custom plugins or sidecars.
diff --git a/website/learning-center/mcp-protocol-ai-gateway.md
b/website/learning-center/mcp-protocol-ai-gateway.md
new file mode 100644
index 00000000000..6f01a46ac95
--- /dev/null
+++ b/website/learning-center/mcp-protocol-ai-gateway.md
@@ -0,0 +1,124 @@
+---
+title: "MCP Protocol & AI Gateways: Managing AI Agent Traffic at Scale"
+description: "Learn about the Model Context Protocol (MCP), how AI gateways
manage LLM and AI agent traffic, and how Apache APISIX bridges MCP servers with
enterprise infrastructure."
+slug: mcp-protocol-ai-gateway
+date: 2026-04-14
+tags: [mcp, ai-gateway, ai-agents, llm]
+hide_table_of_contents: false
+---
+
+An AI gateway is a specialized API gateway that manages traffic between
applications and large language models (LLMs), enforcing token-based rate
limiting, model routing, cost controls, and content safety policies. As AI
agents adopt the Model Context Protocol (MCP) to interact with external tools
and data sources, AI gateways become essential infrastructure for securing,
observing, and scaling these interactions in production environments.
+
+## What is an AI Gateway
+
+An AI gateway sits between your applications and AI model providers (OpenAI,
Anthropic, Google, open-source models), routing requests, enforcing policies,
and providing observability across all AI interactions. Unlike traditional API
gateways that focus on REST and gRPC traffic patterns, AI gateways understand
LLM-specific concerns: token consumption, prompt structure, model-specific rate
limits, and response streaming.
+
+The market for AI infrastructure is expanding rapidly, with enterprise
adoption of generative AI APIs and models accelerating across industries. This
growth creates urgent demand for infrastructure that manages AI traffic with
the same rigor applied to traditional API traffic. For more on AI gateway
capabilities, see the [APISIX AI Gateway overview](/ai-gateway/).
+
+## The Rise of AI Agents and LLM Traffic
+
+AI agents represent a shift from simple prompt-response interactions to
autonomous, multi-step workflows where LLMs invoke tools, query databases,
browse the web, and orchestrate complex tasks. Unlike a single chatbot API
call, an agent workflow may generate dozens of LLM invocations, tool calls, and
data retrievals to complete a single user request.
+
+Much of the economic value from generative AI will flow through agentic AI
systems that operate autonomously on behalf of users and organizations.
Developer adoption of AI agent frameworks has accelerated rapidly, as reflected
in growing open-source activity and ecosystem investment.
+
+This growth in agentic AI creates a traffic management challenge. A single
agent interaction might produce 10-50 API calls across multiple model providers
and tool servers. Without gateway-level management, organizations face
unpredictable costs, security blind spots, and no centralized observability
over AI operations.
+
+## What is MCP (Model Context Protocol)
+
+The Model Context Protocol (MCP) is an open standard introduced by Anthropic
that defines how AI assistants connect to external tools, data sources, and
services. MCP provides a standardized interface that replaces the fragmented,
vendor-specific tool integration patterns that emerged as AI agents
proliferated.
+
+Before MCP, every AI application needed custom integration code for each tool
and data source. An agent that needed to query a database, search documents,
and call an API required three separate integration implementations, each with
its own authentication, error handling, and data formatting logic. MCP
standardizes this interaction into a single protocol that any AI assistant can
use with any MCP-compatible server.
+
+The protocol draws inspiration from the Language Server Protocol (LSP), which
standardized how code editors communicate with language-specific tooling. Just
as LSP eliminated the need for every editor to implement every language's
features independently, MCP aims to eliminate the need for every AI application
to implement every tool integration independently. Since its release, MCP
adoption has grown significantly, with a large number of community-built MCP
servers available and major AI [...]
+
+## MCP Architecture
+
+MCP follows a client-server architecture with clear separation of concerns
across four components.
+
+### Host
+
+The host is the AI application that initiates interactions. It could be a
desktop AI assistant, an IDE with AI capabilities, a chatbot platform, or any
application that leverages LLMs. The host creates and manages MCP client
instances and controls which servers the AI model can access, enforcing
security boundaries.
+
+### Client
+
+The MCP client is a protocol handler embedded within the host application.
Each client maintains a one-to-one connection with a single MCP server. The
client handles protocol negotiation, capability discovery, and message routing
between the host and the server.
+
+### Server
+
+MCP servers expose tools, resources, and prompts to AI clients through a
standardized interface. A server might wrap a database, a file system, a web
API, a code repository, or any other data source or capability. Servers declare
their capabilities during an initialization handshake, allowing clients to
discover available tools dynamically.
+
+### Transport
+
+MCP supports multiple transport mechanisms. The **stdio** transport
communicates through standard input/output streams, suitable for local server
processes. The **Streamable HTTP** transport (which supersedes the earlier
SSE-based transport) uses HTTP for remote server communication, enabling
servers to run as network services accessible across infrastructure boundaries.
In production environments, the HTTP-based transport is widely preferred for
its flexibility in distributed deployments.
+
+## Why AI Traffic Needs Gateway Management
+
+AI traffic introduces challenges that traditional API management was not
designed to handle.
+
+### Security
+
+AI agents with tool access can potentially reach sensitive systems. Without
centralized policy enforcement, an agent might access production databases,
execute privileged operations, or leak sensitive data through prompts sent to
third-party model providers. Data leakage is widely cited as a primary security
concern among organizations deploying AI agents.
+
+### Rate Limiting
+
+LLM providers impose rate limits measured in tokens per minute and requests
per minute. These limits differ by model, tier, and provider. An AI gateway
tracks token consumption across all applications and enforces limits before
requests are rejected by upstream providers, preventing cascading failures.
+
+### Cost Control
+
+LLM API costs scale with token consumption, and agentic workflows can generate
substantial token volumes. A single complex agent task might consume 100,000
tokens across multiple model calls. Without gateway-level cost tracking and
budget enforcement, organizations frequently discover unexpected AI spending.
+
+### Observability
+
+Debugging agentic AI workflows requires end-to-end visibility across model
calls, tool invocations, and data retrievals. Traditional logging captures
individual HTTP requests but misses the logical flow of an agent's reasoning
chain. AI gateways correlate related requests into coherent traces, making it
possible to understand why an agent made specific decisions.
+
+### Multi-Provider Routing
+
+Organizations increasingly use multiple model providers to optimize for cost,
latency, and capability. An AI gateway routes requests to the appropriate
provider based on model availability, cost thresholds, latency requirements,
and task complexity, functioning as an intelligent load balancer for AI traffic.
+
+## Key AI Gateway Features
+
+Modern AI gateways provide capabilities specifically designed for LLM and
agent traffic patterns.
+
+**LLM load balancing** distributes requests across multiple model endpoints,
providers, or self-hosted instances. This includes weighted routing, failover,
and least-latency selection. Organizations running self-hosted models alongside
commercial APIs use load balancing to optimize cost and performance
simultaneously.
+
+**Token-based rate limiting** tracks consumption in tokens rather than simple
request counts. Since a single LLM request can consume anywhere from 100 to
100,000 tokens depending on context length, request-based rate limiting is
insufficient. Token-aware rate limiting provides accurate cost and capacity
management.
+
+**Prompt caching** stores responses for repeated or similar prompts, reducing
latency and cost for common queries. Semantic caching extends this by matching
prompts based on meaning rather than exact text. Effective prompt caching
strategies can meaningfully reduce both latency and cost for common queries.
+
+**Model fallback** automatically redirects traffic to alternative models when
a primary provider experiences outages, rate limit exhaustion, or elevated
latency. Fallback chains can be configured with degradation policies (for
example, falling back from GPT-4 to GPT-3.5 with a user notification).
+
+**Content moderation** inspects prompts and responses for policy violations,
sensitive data, prompt injection attempts, and harmful content. Gateway-level
moderation ensures consistent enforcement regardless of which application or
agent generates the traffic.
+
+## How APISIX Supports AI Workloads
+
+Apache APISIX provides AI gateway capabilities through its plugin
architecture, enabling organizations to manage LLM traffic alongside
traditional API traffic within a single gateway infrastructure.
+
+The [ai-proxy plugin](/docs/apisix/plugins/ai-proxy/) provides a unified
interface for routing requests to multiple LLM providers including OpenAI,
Anthropic, Azure OpenAI, and self-hosted models. It handles provider-specific
authentication, request format translation, and response normalization,
allowing applications to switch between providers without code changes.
+
+APISIX supports **token-based rate limiting** through its rate limiting
plugins configured with token consumption metrics, enabling organizations to
enforce per-consumer and per-route token budgets. Combined with the logging and
metrics plugins, this provides complete visibility into AI spending across all
applications and teams.
+
+For **MCP-to-HTTP bridging**, APISIX can proxy traffic between MCP clients
using Streamable HTTP transport and backend MCP servers, applying the same
authentication, rate limiting, and observability policies that govern
traditional API traffic. This enables organizations to expose MCP servers
through a managed gateway layer rather than allowing direct network access from
AI agents to tool servers.
+
+APISIX's dynamic configuration through etcd is particularly valuable for AI
workloads where model endpoints, rate limits, and routing rules change
frequently as new models are released, pricing changes, and usage patterns
evolve. Configuration changes take effect in milliseconds without gateway
restarts, enabling rapid response to provider outages or cost threshold
breaches.
+
+## Future of AI Infrastructure
+
+The convergence of AI gateways and traditional API gateways is accelerating.
As AI capabilities become embedded in every application, the distinction
between "AI traffic" and "regular API traffic" will blur. Gateways that manage
both traffic types within a unified policy framework will have a significant
advantage over point solutions.
+
+MCP adoption is likely to grow as more AI platforms and tool providers
implement the protocol, creating demand for infrastructure that can manage MCP
traffic at enterprise scale. The protocol's evolution toward more sophisticated
transport mechanisms, authentication models, and capability negotiation will
require gateway-level support to handle securely.
+
+As worldwide spending on AI infrastructure continues to grow rapidly, a
meaningful portion will flow through AI gateway infrastructure that provides
the security, observability, and cost management enterprises require before
deploying AI agents in production environments.
+
+## FAQ
+
+### What is the difference between an AI gateway and a traditional API gateway?
+
+An AI gateway extends traditional API gateway capabilities with LLM-specific
features: token-based rate limiting, prompt inspection, model routing, cost
tracking, and response streaming support. A traditional API gateway manages
REST and gRPC traffic with request-based rate limiting, authentication, and
load balancing. Modern platforms like Apache APISIX blur this distinction by
supporting both traditional and AI-specific traffic management within a single
gateway, eliminating the need f [...]
+
+### How does MCP relate to function calling and tool use in LLMs?
+
+Function calling (also called tool use) is the LLM capability to generate
structured outputs that invoke external functions. MCP standardizes the
infrastructure layer that connects these function calls to actual tool
implementations. Where function calling defines *what* the model wants to do,
MCP defines *how* the request reaches the tool server and *how* results return
to the model. MCP is complementary to function calling, not a replacement.
+
+### Can I use an AI gateway without adopting MCP?
+
+Yes. AI gateways manage all types of AI traffic, including direct LLM API
calls that do not use MCP. Most organizations start with basic LLM proxy and
rate limiting features before adopting MCP for tool integration. The gateway
provides value regardless of whether your AI applications use MCP, custom tool
integrations, or simple prompt-response patterns.
