Cómo construir tu propia CDN privada en 5 pasos (pensado para administradores de sistemas)

El tráfico web no deja de crecer y, con él, la presión sobre quienes están al otro lado de la consola: los administradores de sistemas. Vídeo en 4K, contenidos interactivos, descargas masivas, picos de tráfico imprevisibles… y una factura de CDN que muchas veces crece más rápido que los ingresos.

En ese contexto, cada vez más organizaciones se plantean algo que hace unos años sonaba a “ligas mayores”: construir su propia CDN privada o híbrida. Gracias a soluciones como Varnish, montar una red de distribución de contenidos propia ha pasado de ser un proyecto de meses a algo que puede estar razonablemente operativo en cuestión de horas, con control total sobre rendimiento, costes y seguridad.

Este artículo está pensado para una web de administradores de sistemas: menos marketing y más arquitectura, decisiones y comandos.

---

Por qué una CDN privada tiene sentido para un sysadmin

Antes de entrar en los pasos, merece la pena entender qué problemas resuelve una CDN privada frente a depender solo de proveedores comerciales.

1. Disponibilidad y control

Cuando una CDN comercial tiene un incidente serio, al usuario le da igual si la culpa es del proveedor: el servicio que “no funciona” es el tuyo. Además, muchos PoPs de CDNs públicas comparten ubicaciones y acuerdos de peering; en momentos de alto tráfico, la congestión afecta a todos a la vez. Con una CDN privada:

• Tú decides dónde poner los PoPs.
• Puedes apuntar capacidad a regiones “secundarias” donde los grandes CDNs no priorizan.
• Tienes más margen para diseñar tus propios planes de contingencia.

2. Rendimiento de verdad, no solo en el papel

Hay varios puntos clave que un admin reconoce enseguida:

• Proximidad real al usuario: servir contenido desde donde están tus audiencias, no solo desde los grandes hubs.
• Contenido dinámico y long-tail: en una red compartida es difícil afinar la caché para contenido muy dinámico o muy diverso. Con Varnish y su lenguaje VCL puedes cachear incluso contenido generado dinámicamente con estrategias avanzadas (prefetch, grace, etc.).
• Latencia controlada: midiendo tú mismo RTT y trazas entre origen, PoPs y usuarios, en lugar de confiar solo en métricas agregadas del proveedor.

3. Costes: el punto que duele

Las CDNs comerciales suelen facturar por GB servidos y número de peticiones. Si estás moviendo cientos de Mbit/s o varios Gbit/s de forma sostenida, la curva se vuelve muy vertical. En cambio, en una CDN privada:

• El coste de hardware, hosting y operación se reparte a medida que el tráfico crece.
• Funcionalidades como TLS, WAF o cifrado avanzado no vienen con suplementos “premium” por cada PoP: forman parte de tu propia pila.

En muchos casos, offloadear el tráfico más pesado a tu red privada reduce sensiblemente la factura mensual de CDN.

4. Seguridad y compliance

En sectores sensibles (media premium, finanzas, administración pública, salud…) no siempre es deseable tener contenido y logs en una plataforma multi-tenant global. Una CDN privada te permite:

• Aislar datos y tráfico en tu propia infraestructura.
• Aplicar políticas de WAF, cifrado de caché y controles de acceso exactamente como exige la organización.
• Reducir superficie de ataque y mejorar visibilidad forense.

5. Flexibilidad para DevOps

Con Varnish + VCL no dependes de un panel genérico: puedes definir lógica en el edge tan compleja como quieras, versionarla en Git, desplegarla con Ansible o Terraform y tratar la CDN como cualquier otra parte de tu infraestructura como código.

---

Arquitectura mental: cómo se ve una CDN privada típica

Piensa en una CDN privada como en una gran caché distribuida:

• Origen: tu(s) servidor(es) de aplicación/almacenamiento.
• Origin shield: capa de Varnish delante del origen para protegerlo y reducir peticiones directas.
• PoPs (Points of Presence): nodos Varnish distribuidos geográficamente.
• Enrutamiento: DNS (GeoDNS) o anycast que envía al usuario al PoP más cercano.
• Capas de seguridad: TLS/SSL, WAF, cifrado de caché, autenticación, etc.

Con eso en mente, vamos a los 5 pasos prácticos.

---

Paso 1: ¿Cloud, on-prem o híbrido?

Primera decisión clave: ¿dónde se va a ejecutar físicamente tu CDN?

Y aquí no hay una única respuesta válida. Tendrás que hacerte la pregunta dos veces:

• Para el origen.
• Para los PoPs.

Criterios para decidir

1. Disponibilidad y cercanía
   • ¿Tu proveedor cloud tiene instancias en las regiones donde tienes usuarios?
   • ¿Tu empresa tiene ya CPDs propios en esas zonas?
2. Rendimiento
   • ¿Necesitas bare-metal para exprimir I/O y ancho de banda?
   • ¿Te basta con instancias cloud optimizadas para red?
3. Costes
   • Capex vs Opex: ¿sale más barato pagar cloud por GB y hora, o amortizar hardware propio?
   • ¿Tienes equipo para operar la capa física o prefieres delegarla?
4. Escalado
   • ¿Preves picos muy irregulares (mejor cloud)?
   • ¿Tienes una base estable de tráfico muy alta (mejor on-prem o housing)?
5. Seguridad y cumplimiento
   • ¿Hay requisitos de residencia de datos por país o región?
   • ¿Necesitas aislar PoPs para ciertos clientes o servicios?

En la práctica, muchas organizaciones terminan con un modelo híbrido: origen y PoP principal en on-prem/housing, PoPs secundarios en cloud donde hace falta abrir mercado rápido.

---

Paso 2: ISP y enrutamiento hasta tus PoPs

Si montas una CDN privada, traes tu propio ISP y routing a la fiesta. Eso te da control, pero también responsabilidad.

Qué mirar en el ISP

• Cobertura geográfica en las regiones clave.
• Capacidad y SLAs para soportar tanto el tráfico medio como los picos.
• Conectividad y peering con otros carriers e IXPs relevantes.
• Modelo de precios (95.º percentil, commit, burst, etc.).

Enrutamiento hacia el PoP adecuado

Como sysadmin tendrás que decidir:

• GeoDNS: resolver cdn.ejemplo.com a diferentes IPs según país/región.
• Anycast: anunciar la misma IP en múltiples PoPs y dejar que BGP decida el camino más corto.
• Reparto interno: balanceadores o routers que lleven el tráfico desde el ISP a los nodos Varnish.

La combinación típica para un primer despliegue: GeoDNS + PoPs regionales, lo bastante simple para operarlo con tu equipo actual.

---

Paso 3: Diseñar origen y PoPs con criterio

Origen y origin shield

• Coloca el origen donde tengas mejor conectividad y donde ya alojas tu backend (por ejemplo, un CPD principal en Londres o Madrid).
• Delante del origen, añade un origin shield con Varnish: una capa de caché que absorbe el tráfico de todos los PoPs y protege al backend de avalanchas.

Elegir PoPs: no es tirar dardos al mapa

Analiza:

1. Dónde está tu audiencia hoy y dónde esperas crecimiento (Europa, LatAm, Norteamérica, Asia, etc.).
2. Latencia entre origen y usuarios, y entre origen y posibles PoPs (mide con traceroute, MTR, datos de RUM si los tienes).
3. Patrones de tráfico: horas pico, tipos de contenido, tamaño medio de objetos.

Ejemplo sencillo:

• Origen y origin shield en Londres.
• PoP A en Frankfurt para servir Europa.
• PoP B en Nueva York para Norteamérica.

Desde ahí, vas añadiendo PoPs según crezca el proyecto.

---

Paso 4: Elegir e instalar el software de CDN privada

Aquí entra en juego Varnish Private CDN, que combina varios componentes pensados justo para este caso de uso:

• Varnish Cache Plus como motor principal.
• Massive Storage Engine (MSE) para caché persistente de cientos de TB.
• Varnish High Availability (VHA) para replicar objetos entre nodos y dar alta disponibilidad.
• TLS/SSL (con Hitch) para tráfico cifrado entrante y saliente.
• Varnish Total Encryption (VTE) para cifrar objetos en caché con claves AES256 únicas.
• Varnish WAF para inspección y bloqueo de tráfico malicioso en el edge.

Ejemplo de configuración básica

Definir backend en default.vcl:

vcl 4.1;

backend origin {
    .host = "10.0.0.10";
    .port = "443";
    .ssl  = 1;
    .ssl_sni = 1;
}

sub vcl_recv {
    # No cachear login ni panel
    if (req.url ~ "^/login" || req.url ~ "^/admin") {
        return (pass);
    }

    # Cachear GET/HEAD anónimos
    if (req.method == "GET" || req.method == "HEAD") {
        return (hash);
    }

    return (pass);
}

sub vcl_backend_response {
    # TTL por defecto para contenido estático
    if (bereq.url ~ "\.(css|js|jpg|jpeg|png|gif|webp|mp4)$") {
        set beresp.ttl = 1h;
    } else {
        set beresp.ttl = 60s;
    }
}
Lenguaje del código: PHP (php)

Configurar MSE como almacenamiento (ejemplo de línea de arranque):

varnishd -a :80 \
  -s mse,/var/lib/varnish/mse/store,/var/lib/varnish/mse/book \
  -f /etc/varnish/default.vcl
Lenguaje del código: JavaScript (javascript)

Y, si quieres cifrado completo de caché, incluir el módulo de Varnish Total Encryption en tu VCL:

include "total-encryption/random_key.vcl";
Lenguaje del código: PHP (php)

Con eso tienes un PoP funcional. Repite el patrón en cada PoP y en el origin shield, integrando VHA para replicación de contenido entre nodos.

---

Paso 5: Configuración avanzada, monitorización y puesta en producción

Una vez que tienes los nodos Varnish desplegados, toca afinarlos como buen sysadmin.

Ajustes básicos que no deberías olvidar

• Puertos y binding: por ejemplo, Varnish escuchando en :80 detrás de un proxy TLS, o directamente en :443 con terminación TLS integrada.
• Logs y observabilidad:
  • Usa varnishstat, varnishlog y varnishncsa.
  • Exporta métricas a Prometheus / Grafana (hit ratio, backend fetches, 4xx/5xx, latencias, etc.).
• Automatización:
  • Gestiona VCL como código: Git + Ansible/Terraform para desplegar en todos los PoPs.
  • Usa pipelines para validar la sintaxis de VCL antes de subirlo.

Buenas prácticas de caché para una CDN privada

• TTL realistas: no todo puede durar días, pero 30-60 segundos ya descargan mucho al origen en contenido dinámico.
• Grace & stale-while-revalidate: servir contenido ligeramente “rancio” mientras se revalida en background mantiene la experiencia fluida incluso si el origen va justo.
• Purgas controladas: diseña mecanismos de purga por URL, por tag o por patrón para no tener que vaciar la caché completa cada vez que hay un despliegue.

Seguridad alineada con tu organización

• TLS en todas partes: entre usuario y PoP, y entre PoPs y origen.
• WAF en el edge: reglas ModSecurity-like para bloquear patrones típicos (SQLi, XSS, etc.).
• Rate limiting: limitar peticiones por IP o token a nivel de edge para frenar scraping agresivo o ataques de fuerza bruta.
• Cifrado de caché con VTE cuando el contenido o los requisitos de compliance lo exijan.

---

Conclusión: una CDN que habla el lenguaje de los sysadmins

Para muchos administradores de sistemas, montar una CDN propia sonaba a proyecto de “grandes ligas” reservado a gigantes como Netflix o Facebook. Hoy, con herramientas como Varnish, buena conectividad y un poco de trabajo de diseño, es perfectamente viable para cualquier organización con volúmenes de tráfico medios-altos.

La clave está en tratar la CDN como lo que realmente es: otra pieza más de tu infraestructura, declarativa, automatizada, observable y bajo tu control. Desde ahí puedes decidir cuánto tráfico dejas en CDNs comerciales y cuánto mueves a tu red privada para optimizar costes, rendimiento y seguridad.

Si ya estás acostumbrado a gestionar clusters, balanceadores y reverse proxies, montar una CDN privada es simplemente el siguiente paso lógico.