Descubre cómo Akamai y otros CDN se mantienen relevantes al ir más allá del almacenamiento en caché hacia la seguridad y la computación en el borde, y qué significa ese cambio para las aplicaciones modernas.
Durante años, mucha gente al oír “Akamai” pensaba en “sitios más rápidos”. Eso sigue siendo cierto, pero ya no es toda la historia. Los mayores problemas que enfrentan los equipos hoy no son solo la velocidad. Son mantener servicios disponibles durante picos de tráfico, detener el abuso automatizado, proteger APIs y apoyar de forma segura aplicaciones modernas que cambian semanalmente (o a diario).
Este cambio importa porque el “borde” —el lugar cercano a los usuarios y al tráfico entrante— se convirtió en el punto más práctico para manejar tanto rendimiento como riesgo. Cuando ataques y solicitudes de usuarios llegan por la misma puerta, es eficiente inspeccionarlas, filtrarlas y acelerarlas en un solo lugar en vez de añadir herramientas separadas después.
Esto es una visión práctica de por qué Akamai evolucionó de una red de entrega centrada en el almacenamiento en caché a una plataforma de borde más amplia que combina entrega, seguridad y computación en el borde. No es un discurso de proveedor y no necesitas ser especialista en redes para seguirlo.
Si eres alguno de los siguientes, esta evolución afecta tus decisiones diarias:
Mientras lees, piensa en el cambio de Akamai en tres partes conectadas:
El resto del artículo desglosa cómo encajan esas columnas —y los trade-offs que los equipos deben considerar.
Una red de entrega de contenidos (CDN) es un conjunto distribuido de Puntos de Presencia (PoPs) —centros de datos colocados cerca de los usuarios finales. Dentro de cada PoP hay servidores en el borde que pueden servir el contenido de tu sitio sin tener que volver siempre al origen (tu servidor web principal o almacenamiento en la nube).
Cuando un usuario solicita un archivo, el borde comprueba si ya tiene una copia fresca:
El cacheo se popularizó porque mejora de forma fiable lo básico:
Esto es especialmente efectivo para activos “estáticos”: imágenes, JavaScript, CSS, descargas —donde los mismos bytes se reusan entre muchos visitantes.
Las webs y apps modernas son cada vez más dinámicas por defecto:
El resultado: el rendimiento y la fiabilidad no pueden depender solo de las tasas de aciertos en la caché.
Los usuarios esperan que las apps se sientan instantáneas en todas partes y que permanezcan disponibles incluso durante caídas o ataques. Eso empuja a las CDNs más allá de “páginas más rápidas” hacia entrega siempre activa, manejo de tráfico más inteligente y seguridad cerca de donde llegan las solicitudes.
Cachear archivos estáticos sigue siendo útil, pero ya no es el centro de gravedad. La forma en que la gente usa internet y la forma en que los atacantes lo apuntan han cambiado. Por eso empresas como Akamai ampliaron su función de “hacerlo más rápido” a “hacerlo seguro, disponible y adaptable en el borde”.
Una parte creciente del tráfico viene ahora de apps móviles y APIs en vez de cargas de páginas en el navegador. Las apps llaman constantemente a servicios backend para feeds, pagos, búsqueda y notificaciones.
Streaming e interacciones en tiempo real suman otra variable: segmentos de vídeo, eventos en vivo, chat, gaming y experiencias “siempre activas” crean demanda sostenida y picos repentinos. Gran parte de ese contenido es dinámico o personalizado, por lo que hay menos que simplemente cachear y olvidar.
Los atacantes confían cada vez más en la automatización: credential stuffing, scraping, creación de cuentas falsas y abuso de checkout. Los bots son baratos de ejecutar y pueden imitar usuarios normales.
Los ataques DDoS también evolucionaron: a menudo mezclados con presión a nivel de aplicación (no solo “llenar el pipe”, sino “estresar el endpoint de login”). El resultado es que problemas de rendimiento, disponibilidad y seguridad aparecen juntos.
Los equipos ahora operan en entornos multi-cloud e híbridos, con cargas de trabajo repartidas entre proveedores y regiones. Eso hace más difícil aplicar controles consistentes: políticas, límites de tasa y reglas de identidad deben seguir el tráfico, no un único centro de datos.
Mientras tanto, el impacto en el negocio es inmediato: el uptime afecta ingresos y conversión, los incidentes dañan la confianza de la marca y las expectativas de cumplimiento aumentan. La velocidad sigue importando, pero importa más la velocidad segura.
Una forma simple de entender el cambio de Akamai es dejar de pensar en ella como “una caché delante de tu web” y empezar a verla como “una plataforma distribuida que se sienta junto a tus usuarios y a los atacantes.” El borde no se movió: lo que las empresas esperan de él sí.
Al principio, la misión era sencilla: acercar archivos estáticos a la gente para que las páginas cargaran más rápido y los orígenes no colapsaran.
A medida que el tráfico creció y los ataques escalaron, las CDNs se convirtieron en el lugar natural para absorber abuso y filtrar solicitudes malas —porque ya manejaban grandes volúmenes y estaban delante del origen.
Luego las aplicaciones cambiaron otra vez: más APIs, más contenido personalizado, más scripts de terceros y más bots. “Solo cachearlo” dejó de ser suficiente, así que el borde se amplió hacia la aplicación de políticas y la lógica de aplicación ligera.
Una característica de CDN con un solo propósito resuelve un problema (p. ej., cachear imágenes). Pensar en plataforma trata entrega, seguridad y computación como partes conectadas de un mismo flujo de trabajo:
Esto importa operativamente: los equipos quieren menos piezas móviles, menos traspasos y cambios que sean más seguros de desplegar.
Para soportar este rol más amplio, los grandes proveedores ampliaron sus portafolios con el tiempo —mediante desarrollo interno y, en algunos casos, adquisiciones— añadiendo más controles de seguridad y capacidades en el borde bajo un mismo paraguas.
La dirección de Akamai refleja una tendencia de mercado: las CDNs evolucionan hacia plataformas de borde porque las apps modernas necesitan rendimiento, protección y control programable en el mismo cuello de botella —justo donde entra el tráfico.
Cuando un servicio es atacado, el primer problema a menudo no es “¿podemos bloquearlo?” sino “¿podemos absorberlo el tiempo suficiente para seguir online?” Por eso la seguridad se acercó a donde entra el tráfico en internet: al borde.
Los proveedores en el borde ven la realidad desordenada del tráfico de internet antes de que llegue a tus servidores:
Bloquear o filtrar tráfico cerca de su origen reduce la carga en todas partes:
En la práctica, “cerca de los usuarios” significa “antes de que llegue a tu infraestructura”, en puntos de presencia globales donde el tráfico puede inspeccionarse y actuarse rápidamente.
La protección en el borde típicamente combina:
La seguridad en el borde no es "configurar y olvidar":
Antes se juzgaba una CDN principalmente por la rapidez en entregar páginas cacheadas. Hoy, la “carga de trabajo” en el borde significa cada vez más filtrar tráfico hostil y proteger la lógica de la aplicación antes de que llegue al origen.
Un WAF se coloca delante de tu sitio o app e inspecciona solicitudes HTTP/S. La protección tradicional se basa en reglas y firmas (patrones conocidos para ataques como inyección SQL). Los WAFs modernos también añaden detección conductual —buscando secuencias sospechosas, uso anómalo de parámetros o tasas de solicitud que no coinciden con usuarios normales. El objetivo no es solo bloquear, sino reducir falsos positivos para que los clientes legítimos no sean desafiados.
Para muchas empresas, las APIs son el producto. La seguridad de APIs va más allá de las comprobaciones clásicas de WAF:
Como las APIs cambian a menudo, este trabajo necesita visibilidad de qué endpoints existen y cómo se usan.
Los bots incluyen buscadores y monitores de uptime (buenos), pero también scalpers, scrapers y herramientas de takeover (malos). La gestión de bots se centra en distinguir humanos de automatización usando señales como huellas de dispositivo/navegador, patrones de interacción y reputación —y luego aplicar la acción correcta: permitir, limitar, desafiar o bloquear.
Cuando entrega y seguridad comparten la misma huella en el borde, pueden usar telemetría y políticas compartidas: los mismos identificadores de solicitud, geolocalización, datos de tasa y señales de amenaza informan tanto decisiones de cacheo como de protección. Ese bucle cerrado es por qué la seguridad se volvió una característica central de la CDN, no un complemento.
Computación en el borde significa ejecutar pequeñas piezas de lógica de aplicación en servidores que están cerca de tus usuarios —en los mismos nodos distribuidos que ya manejan entrega y enrutamiento de tráfico. En lugar de que cada petición viaje hasta los servidores origen (tus servidores de app, APIs, bases de datos), algunas decisiones y transformaciones ocurren “en el borde”.
Piénsalo como mover código ligero a la puerta de entrada de tu app. El borde recibe una petición, ejecuta una función y luego responde de inmediato o reenvía una petición modificada al origen.
La computación en el borde brilla cuando necesitas lógica rápida y repetible aplicada a muchas solicitudes:
Al tomar decisiones más cerca del usuario, la computación en el borde puede reducir viajes de ida y vuelta, disminuir tamaños de payload (por ejemplo, eliminar encabezados innecesarios) y bajar la carga en el origen evitando que solicitudes no deseadas o mal formadas lleguen a tu infraestructura.
La computación en el borde no reemplaza por completo tu backend:
Los mejores resultados suelen venir de mantener las funciones en el borde pequeñas, deterministas y centradas en el “pegamento” de solicitud/respuesta más que en la lógica de negocio principal.
“El acceso seguro” trata de garantizar que las personas y sistemas correctos alcancen las apps y APIs correctas —y que todos los demás queden fuera. Eso suena básico, pero se complica cuando tus aplicaciones viven en varias nubes, los empleados trabajan de forma remota y los socios integran mediante APIs.
Zero Trust es una mentalidad: no asumas que algo es seguro solo porque está “dentro de la red”. En su lugar:
Esto cambia la seguridad de “proteger el edificio” a “proteger cada puerta”.
SASE (Secure Access Service Edge) agrupa funciones de red y seguridad en un servicio entregado desde la nube. La idea es aplicar reglas de acceso cerca de donde entra el tráfico —cerca de usuarios, dispositivos e internet— en vez de reenviar todo a un centro de datos central.
Por eso los bordes de red se convirtieron en bordes de seguridad: el borde es donde puedes inspeccionar solicitudes, aplicar políticas y detener ataques antes de que toquen tu app.
Las plataformas de borde modernas se sitúan directamente en la ruta del tráfico, lo que las hace útiles para controles estilo Zero Trust:
La plataforma de borde de Akamai es menos “activar cache” y más operar un plano de control distribuido. La recompensa es protección y consistencia a escala —pero solo si los equipos pueden gestionar reglas, ver lo que pasa y desplegar cambios de forma segura.
Cuando entrega, seguridad y computación en el borde se configuran en lugares separados, aparecen huecos: una ruta cacheada pero no protegida, un endpoint de API protegido pero que rompe rendimiento, o una regla de bots que bloquea tráfico legítimo del checkout.
Una plataforma en el borde fomenta un enfoque de política unificada: enrutamiento coherente, ajustes TLS, límites de tasa, controles de bots y protecciones de API —más cualquier lógica en el borde— aplicados de forma coherente a los mismos flujos de tráfico. Prácticamente, eso significa menos “casos especiales” y una respuesta más clara a “qué pasa cuando una solicitud llega a /api/login?”.
Si el borde es ahora la puerta de entrada para la mayor parte del tráfico, necesitas visibilidad que abarque tanto el borde como el origen:
La meta no es “más dashboards”. Es respuestas más rápidas a preguntas comunes: ¿esta caída es del origen o del borde? ¿una regla de seguridad causó la caída en conversiones? ¿estamos siendo atacados o lanzó marketing una campaña?
Como la configuración en el borde afecta todo, el control de cambios importa. Busca flujos de trabajo que soporten:
Los equipos que triunfan suelen definir valores por defecto seguros (por ejemplo, modo solo-logging para reglas nuevas) y promover cambios gradualmente en vez de hacer un gran interruptor global.
Operar una plataforma en el borde funciona mejor cuando app, plataforma y seguridad comparten un proceso común de cambios: SLAs acordados para revisiones, un único lugar para documentar intenciones y responsabilidades claras durante incidentes. Esa colaboración convierte el borde de un cuello de botella en una superficie de despliegue confiable —donde rendimiento, protección y funcionalidad pueden mejorar juntos.
El giro de Akamai de “cachea mi sitio” a “ejecuta y protege mis apps en el borde” trae beneficios claros —pero también cambia lo que estás comprando. Las compensaciones importan menos en rendimiento bruto y más en economía, operaciones y lo estrechamente que fijas sistemas críticos a un proveedor.
Una plataforma integrada puede desplegarse rápido: un conjunto de controles para entrega, DDoS, WAF, gestión de bots y protección de APIs. La otra cara es la dependencia. Si tus políticas de seguridad, señales de bots y lógica en el borde quedan profundamente adaptadas a una plataforma, migrar después puede implicar reimplementar configuraciones y revalidar comportamientos.
Los costes suelen expandirse más allá del tráfico CDN base:
Los proveedores globales son resilientes, pero no inmunes a caídas o errores de configuración. Considera rutas de failover (estrategia DNS, fallback al origen), controles seguros de cambios y si necesitas multi-CDN para propiedades críticas.
Seguridad y computación en el borde significan más procesamiento fuera de tus servidores. Aclara dónde se procesan y almacenan logs, encabezados, tokens e identificadores de usuarios —y qué controles existen para retención y acceso.
Antes de comprometerte, pregunta:
Ver “entrega + seguridad + computación” en una página de producto es una cosa. El valor práctico aparece cuando los equipos usan esas piezas juntas para reducir riesgo y mantener apps responsivas bajo condiciones reales.
Objetivo: Mantener a los clientes reales en los flujos de login y compra mientras se bloquea el abuso automatizado que provoca takeovers y pruebas de tarjetas.
Controles en el borde usados: Señales de gestión de bots (patrones conductuales, consistencia de dispositivo/navegador), reglas WAF específicas para endpoints sensibles y limitación de tasa en login, recuperación de contraseña y checkout. Muchos equipos añaden desafíos escalonados solo cuando el riesgo es alto, para no penalizar a usuarios regulares.
Métricas de éxito: Menos intentos sospechosos llegan a la aplicación, reducción de fraude y tickets de soporte, tasas de conversión estables y menor carga en servicios de autenticación.
Objetivo: Seguir online durante ventas flash, noticias de última hora o tráfico hostil —sin tirar abajo APIs centrales.
Controles en el borde usados: Protección DDoS para absorber picos volumétricos, cacheo y coalescencia de solicitudes para respuestas cacheables, y protecciones de API como validación de esquema, aplicación de autenticación y limitación por cliente. Shielding del origen ayuda a que los servicios backend no se sobrecarguen.
Métricas de éxito: Disponibilidad de API, reducción de errores en el origen, tiempos de respuesta consistentes en endpoints críticos y menos cambios de emergencia durante incidentes.
Objetivo: Dirigir usuarios a la mejor región o desplegar funciones con seguridad sin despliegues frecuentes al origen.
Controles en el borde usados: Funciones en el borde para enrutar por geografía, checks de salud o cohorte; flags de características basados en encabezados/cookies; y salvaguardas como listas blancas y fallback cuando una región degrada.
Métricas de éxito: Mitigación de incidentes más rápida, reversiones más limpias, menos redirecciones completas y mejor consistencia de experiencia entre regiones.
El cacheo hoy es lo básico. Lo que separa a una plataforma de borde de otra es qué tan bien reduce el riesgo (DDoS, abuso de apps y APIs, bots) y qué tan fácil permite ejecutar la lógica adecuada cerca de los usuarios sin complicar las operaciones.
Empieza con un inventario, no con funciones de proveedor. Lista tus sitios orientados a clientes, APIs y apps internas críticas —luego anota dónde corren (cloud/on‑prem), cómo es el tráfico (regiones, picos) y qué se rompe con más frecuencia.
Después, construye un modelo ligero de amenazas. Identifica tus riesgos top (credential stuffing, scraping, abuso de API, DDoS L7, fuga de datos) y tus rutas “debe proteger” como login, checkout, reset de contraseña y endpoints de API de alto valor.
Luego ejecuta un piloto con un servicio de alto impacto. Busca un experimento que incluya entrega + seguridad y, opcionalmente, un caso pequeño de computación en el borde (por ejemplo: enrutamiento de solicitudes, normalización de encabezados o personalización simple). Mantén el piloto acotado en el tiempo (2–6 semanas) y define el éxito antes de empezar.
Si tu organización también acelera la entrega con desarrollo asistido por IA (por ejemplo, construyendo frontends React y backends Go + PostgreSQL vía una plataforma de codificación asistida tipo Koder.ai), la necesidad de guardarraíles en el borde típicamente aumenta —no disminuye. Ciclos de iteración más rápidos hacen que los despliegues por etapas, reversiones rápidas y protección consistente de APIs en el borde sean aún más valiosos.
Elige métricas que puedas medir ahora y comparar después:
Asigna dueños (App, Seguridad, Red/Plataforma), acuerda un cronograma y decide dónde vivirán las políticas (Git, tickets o un portal). Crea un scorecard simple para el piloto y una fecha para la reunión de go/no-go.
Si necesitas ayuda para dimensionar un piloto o comparar opciones, usa /contact. Para preguntas sobre empaquetado y coste, consulta /pricing, y para guías relacionadas, revisa /blog.
Akamai empezó como una forma de entregar contenido cacheado desde puntos de presencia (PoPs) cercanos, lo que mejoraba los tiempos de carga y reducía la carga sobre el origen. Pero las aplicaciones modernas dependen en gran medida de APIs dinámicas, respuestas personalizadas y funciones en tiempo real que no se pueden cachear por mucho tiempo. Al mismo tiempo, el abuso automatizado y los ataques DDoS golpean la misma “puerta de entrada” que los usuarios reales, por lo que el borde se convirtió en el lugar práctico para combinar entrega y protección.
Un cache hit significa que el borde ya tiene una copia válida del contenido solicitado y puede servirla de inmediato. Un cache miss significa que el borde debe recuperar el contenido del origen, devolverlo al usuario y posiblemente guardarlo para la próxima vez.
En la práctica, los activos estáticos (imágenes, JS, CSS, descargas) tienden a producir más cache hits, mientras que páginas personalizadas y APIs suelen producir más misses.
El cacheo falla cuando las respuestas difieren por solicitud o deben estar extremadamente frescas. Ejemplos comunes:
Aún puedes cachear cierta parte del contenido dinámico con reglas cuidadosas, pero el rendimiento y la fiabilidad no pueden depender solo de la tasa de aciertos de caché.
Parar ataques en el borde ayuda porque el tráfico malicioso se filtra antes de que consuma tu ancho de banda, límites de conexión o capacidad de aplicación. Eso normalmente significa:
En esencia es “resolverlo en la puerta de entrada”, no después de que llegue a tu infraestructura.
Un WAF inspecciona solicitudes HTTP/S para detectar y bloquear ataques web comunes (por ejemplo, intentos de inyección) y comportamientos sospechosos. La seguridad de APIs suele ir más allá al centrarse en riesgos específicos de APIs, como:
Para muchos equipos, las APIs son la superficie de mayor valor y la más atacada.
Los bots no siempre son malos (rastreadores de búsqueda y monitores de disponibilidad pueden ser legítimos). El objetivo es separar la automatización deseable de la abusiva y aplicar el control más ligero efectivo.
Acciones comunes:
El equilibrio a gestionar es minimizar falsos positivos y fricción para el usuario, especialmente en login y checkout.
La computación en el borde ejecuta lógica pequeña y rápida cerca de los usuarios, a menudo en la misma infraestructura distribuida que entrega y protege el tráfico. Es más útil para “pegamento” de solicitud/respuesta, como:
Normalmente no reemplaza sistemas backend principales: los runtimes están limitados y manejar estado en el borde es complejo.
Zero Trust significa no asumir que el tráfico es seguro solo porque está “dentro” de una red; verificas identidad y contexto y aplicas privilegios mínimos. SASE entrega funciones de red y seguridad desde los bordes en la nube para que el tráfico no tenga que volver a un centro de datos central.
En la práctica, una plataforma en el borde puede ayudar a aplicar políticas de acceso cerca de donde entran usuarios y solicitudes, usando señales de identidad y riesgo para decidir quién puede alcanzar qué aplicaciones.
Dado que la configuración en el borde afecta tráfico global, los cambios necesitan controles. Prácticas útiles incluyen:
También hay que planear observabilidad que conecte las acciones del borde (bloqueado/desafiado/cacheado) con el comportamiento del origen (latencia, 5xx, saturación).
Una evaluación práctica comienza con tu inventario y riesgos, no con listas de funciones:
Durante la evaluación, revisa explícitamente compensaciones como costos adicionales, manejo de datos/retención de logs y lo difícil que sería migrar configuraciones más tarde.
