Tu CDN como API gateway

Microservicios, rate limit y rewriting en el edge

Si gestionas una arquitectura de microservicios, probablemente tengas un API gateway delante de ellos. Y, probablemente, también una CDN delante del API gateway. Dos capas, dos despliegues, dos facturas y, sobre todo, dos saltos extra de latencia por cada petición. La pregunta relevante que algún CTO puede llegar a hacerse es: ¿de verdad necesito ambas?

La respuesta corta es fácil: sí. Pero, la respuesta larga viene con sorpresa, porque si tu CDN funciona con VCL, quizás no necesites duplicar recursos. En este post te explicamos cómo la capa que ya tienes en producción puede actuar como API gateway —enrutar microservicios, limitar tráfico, reescribir URLs y aplicar políticas de seguridad— sin un componente adicional.

¿Qué es un application gateway y por qué tu CDN ya puede serlo?

Lo habitual es usar una CDN como proxy intermedio para cachear contenido, acelerar la entrega o añadir una capa extra de seguridad. Pero hay casos de uso menos explotados que resultan especialmente útiles en arquitecturas complejas. Uno de ellos es usar una CDN como gateway de aplicación o proxy a nivel de aplicación.

Una CDN de nueva generación actúa como hub de todas las peticiones que llegan a tu dominio. Eso significa que cualquier decisión de routing, filtrado, service mesh o validación puede tomarse en esa capa. Y si dispones de un lenguaje como VCL (Varnish Configuration Language) para definir esa lógica, las posibilidades para cualquier equipo DevOps son enormes: SSL-offloading, end-to-end SSL, WAF, routing por URL, múltiples backends por criterios arbitrarios, A/B testing, despliegues canary, feature flags vía cabeceras HTTP y mucho más.

En la práctica, la CDN deja de ser sólo un acelerador y pasa a ser un orquestador.

Caso práctico: una API de microservicios bajo un mismo dominio

Imagina una API basada en microservicios distribuidos en distintos hosts. Con un application gateway puedes exponer todos los servicios bajo un único dominio —api.misitio.com— y enrutar internamente cada ruta a su backend correspondiente: /login, /estadisticas, /carrito.

Suponiendo tres backends ya dados de alta en la CDN:

c0_login → login.miempresa.com:8080
c0_stats → 11.22.33.44:80
c0_shopcart → carrito.proveedordeterceros.com:443

La configuración VCL queda así:

sub vcl_recv {
    if (req.url ~ "^/login") {
        set req.backend_hint = c0_login.backend();
    } else if (req.url ~ "^/estadisticas") {
        set req.backend_hint = c0_stats.backend();
    } else if (req.url ~ "^/carrito") {
        set req.backend_hint = c0_shopcart.backend();
    }
}
# Cada oveja con su pareja

Sin tocar DNS, sin coordinar despliegues entre equipos y sin un componente adicional en el path, has unificado tres servicios bajo una sola URL pública. El cliente final ve api.misitio.com; cada equipo de backend sigue desplegando en su propia infraestructura.

Yendo más allá: rate limit, allow-listing por IP y URL rewriting

El ejemplo anterior es la base. A partir de ahí, el VCL puede crecer en complejidad incorporando validaciones, throttling, redirecciones, reescritura de URLs y más. Veamos algunos patrones habituales aplicados al mismo escenario:

sub vcl_recv {
    if (req.url ~ "^/login") {
        set req.backend_hint = c0_login.backend();
        # Sólo permitimos acceder a estas URLs desde la IP de la oficina
        if (! req.http.True-Client-Ip == "12.34.56.78") {
            error 403 "The power of Christ compels you!";
        }
    } else if (req.url ~ "^/estadisticas") {
        set req.backend_hint = c0_stats.backend();
        # Hay mucho forofo de la estadística; limitamos a 30 req/s
        set req.http.x-ratelimit = 30;
    } else if (req.url ~ "^/carrito") {
        set req.backend_hint = c0_shopcart.backend();
        # El carrito es de terceros y tiene una URL que queremos ocultar
        set req.url = "/third-parties/aef5677c321bb761c/";
        # Un poco de A/B testing: si la IP del cliente acaba en 0, 1 o 2,
        # mandamos al backend la cabecera para que devuelva la versión B
        set req.http.abtesting = 0;
        if (req.http.True-Client-IP ~ "[0-2]$") {
            set req.http.abtesting = 1;
        }
    }
}

Lo que acabas de leer cubre, en una veintena de líneas, funciones que en una arquitectura tradicional pedirían:

Un API gateway gestionado para el routing.
Un plugin o servicio aparte para rate limit.
Reglas de firewall o ACL para el allow-listing por IP.
Un proxy adicional para el URL rewriting de proveedores externos.
Un servicio de feature flags o split testing para el A/B.

Todo eso compactado en la misma capa que ya estás pagando por servir contenido.

Cuándo sí y cuándo no usar tu CDN como API gateway

No todo encaja en este patrón. Para que la decisión sea sólida, conviene tener claras las dos caras:

Encaja bien cuando:

Tus microservicios viven en proveedores cloud distintos o están expuestos en hosts heterogéneos.
Necesitas ocultar la topología real del backend al cliente.
Quieres aplicar políticas comunes (rate limit, allowlist, headers de seguridad) sin tocar cada servicio.
Buscas reducir el número de saltos de red y la factura de un API gateway dedicado.
Tu equipo es cómodo con código declarativo y le merece la pena invertir en VCL.

Encaja peor cuando:

Necesitas transformaciones de payload complejas (gRPC ↔ REST, GraphQL federation con resolvers, etc.).
Tu lógica de autenticación requiere mantener estado por usuario más allá de validar un token.
Tienes ya un service mesh interno (Istio, Linkerd) que cubre el routing intra-cluster y sólo te falta exposición externa.

En la mayoría de los casos, la respuesta se ciñe a elegir uno u otro sino dónde mover cada cosa: routing, rate limit y rewriting al edge; lógica de negocio profunda dentro del cluster.

Métricas que conviene vigilar

Antes de migrar reglas a la CDN, define qué vas a medir para validar el cambio:

Latencia p95/p99 por ruta antes y después del cambio.
Tasa de errores 5xx discriminada por backend (el VCL te lo permite etiquetar).
Hit ratio de caché sobre las rutas que ahora pasan por el gateway.
Coste cloud mensual de los componentes que retiras (gateway gestionado, balanceadores intermedios).

Las posibilidades de usar la CDN como application gateway son prácticamente ilimitadas, y cada arquitectura tiene matices propios. Si quieres explorar un caso concreto —de un patrón sencillo a una topología híbrida multi-cloud con feature flags y A/B testing en el edge— escríbenos o consulta la guía completa de Web Application Gateway en nuestra documentación.

Jara Expósito es Chief Communications Manager de Transparent Edge.

Si se te hace difícil pensar cómo sería Mi Pequeño Pony en un departamento de Marketing, es porque no conoces a Jara. Mitad periodista, mitad unicornio. Se encarga de poner luz, alegría, inocencia y nubes de gominola en el equipo, mientras conjura innombrables hechizos de magia negra para que cuadre el presupuesto de Marketing. Sus tablas demuestran cómo ha conseguido no volverse loca entre tanto friki que habla raro.